Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.fortran
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Transfer and variables that don't use all their storage space.
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Richard Maine  
View profile  
 More options Apr 8 2007, 9:39 pm
Newsgroups: comp.lang.fortran
From: nos...@see.signature (Richard Maine)
Date: Sun, 8 Apr 2007 18:39:43 -0700
Local: Sun, Apr 8 2007 9:39 pm
Subject: Re: Transfer and variables that don't use all their storage space.
Print | View thread | Show original | Report this message | Find messages by this author

Brooks Moses <bmoses-nos...@cits1.stanford.edu> wrote:
> I'm working on implementing compile-time handling of the transfer
> intrinsic for GFortran, and have a couple of edge-case questions about
> the standard that I'm hoping someone here can comment on.

Edge cases of TRANSFER are a mess. I'm convinced the standard is
inconsistent about some of them.  Anyway...

> The Fortran 2003 standard states that TRANSFER(TRANSFER(E,D),E) should
> result in E, if D and E are scalar variables and the physical
> representation of D is as long as or longer than that of E.  (Section
> 13.7.121, lines 30-32.)

That's one part I'm sure is inconsistent. That can't realistically be
expected to work in all cases. I think that whoever wrote those words
just didn't think of the edge cases at all. Consider a scalar of a type
that has allocatable components (perhaps multiple of them, at multiple
depths). I really don't think that the standard envisions going through
and doing all the allocations that would be needed to make that work;
and I sure don't know what the intermediate bits would be.

That's without even thinking of issues like hardware locations that just
don't allow some bit patterns - fortunately that's not a typical
situation for today's machines.

> Now, consider a processor which supports 4-byte LOGICAL and INTEGER
> variables, and suppose that D is a LOGICAL and E is an INTEGER.
> Further, suppose that the canonical representations of 4-byte logicals
> in this processor are to flip the 1-bit to either 1 or 0, and leave the
> rest zero.

> A naive reading of the double-transfer requirement would claim that, if
> E is some number other than 1 or 0, then the processor is required to
> feed that into D's storage space and leave it there, so that it can then
> be converted back into the same number by the outer transfer statement.
>   In particular, according to this reading, the inner transfer statement
> cannot "normalize" the bit representation into one of the canonical
> LOGICAL forms, because then the outer transfer statement would return
> either 1 or 0, neither of which is equal to E.

I think I agree with that. I'm not sure what is naive about it. It is
pretty explicit that all transfer does is copy bits - not convert them.
The bit that you quoted about transfer(transfer(e,d),e) is more of an
elaboration of what you'd expect (in simple cases) to result from
transfering the bits. I think it belongs as a note instead of as
normative text. (And it probably should be corrected with
qualifications, even as a note.)

> I would contend that this reading is incorrect -- that, in particular,
> if E has a bit representation that is not one of the canonical bit
> representations for a logical variable, then the inner transfer
> statement is illegal according to the comments in the beginning of
> section 13.7 which state that a program is not allowed to invoke an
> intrinsic with arguments that produce out-of-range results.  And further
> that the double-transfer identity requirement obviously is only meant to
> apply when both transfer calls, taken independently, are legal.

I agree, except with your comment that the para before is incorrect.
These two paras don't seem inconsistent to me. I think *BOTH* of them
are right. The first para describes what the standard requires to happen
(that the bits just get copied without change). The second para
correctly (in my view) notes that this requires disallowed behavior in
some cases. I agree with the conclusion that the code is illegal on
machines where the resulting bit pattern is an invalid one.

> Further, a strictly literal reading of the beginning of section 13.7
> would suggest that when transferring a value to a real number, NaN
> should be returned if the bit representation is not a legal real number.

I don't see that. As mentioned above, the essential definition of
TRANSFER is that is just copies the bits. I don't think it ever does any
kind of manipulation of them, such as normalizing, generating NaNs or
anything of the sort. You just get the bits as is. If those bits aren't
valid for any reason, then the code is illegal. Note that assignment can
do things like normalize, so the result of

  somevariable = transfer(something,somevariable)

might end up with somevariable being normalized, even though the
transfer intrinsic didn't do it.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google