transfer from real to logical
in [Fortran]
|
From: Tim Prince on 3 Dec 2009 09:34 glen herrmannsfeldt wrote: > Frank <frank(a)example.invalid> wrote: >> On Wed, 02 Dec 2009 20:12:17 -0800, Tim Prince wrote: > > (snip) >> This is what I was looking at: > >> 8.217 TRANSFER ? Transfer bit patterns > >> Description: >> Interprets the bitwise representation of SOURCE in memory as if it is >> the representation of a variable or array of the same type and type >> parameters as MOLD. > >> This is approximately equivalent to the C concept of >> casting one type to another. > > C casts do the appropriate conversion. If you want to see the > bits through casts you have to dereference a pointer cast to > a pointer to a different type, though in that case the standard > does not guarantee the result. > > To do it following the standard (at least C90), you cast a > pointer to (unsigned char *), memcpy() the bits to a variable > through a pointer also cast to (unsigned char *). > > -- glen Anyway, a C cast doesn't broadcast a scalar across an array, which Frank requires to make TRANSFER "work." Frank's undefined concept of "the C" probably is not intended to correspond with any standard C, so it's not likely to be widely accepted as a model for Fortran. 2 replies already pointed out that the most readily available textbooks state explicitly that TRANSFER array elements beyond the SIZE of the source are "processor dependent" (undefined, in C terminology). I guess that may be stated in Frank's reference, a few words beyond where he chose to stop quoting. The commonly used web reference is giving me a long delay, then Adobe message "file is damaged and could not be repaired." Analogous to Glen's suggestion about memcpy(), C memset() broadcasts a char across an array of char[]. C++ fill() broadcasts a variety of data types, but I wouldn't have much confidence in arbitrary mixtures of types which violate C and C++ standards (unlike "the C"). Of course, it would only require assigning a scalar value to an entire array to accomplish the broadcast which Frank wants. Maybe, by stopping reading of the standard at an arbitrary point, it's possible to infer Frank's interpretation.
From: frank on 4 Dec 2009 15:23 On Wed, 02 Dec 2009 22:54:09 -0800, m_b_metcalf wrote: > Think of transfer as pouring bits from source to the function result. As > you're pouring 32 bits of source into 32**2 bits of target, only the > first 32 bits, i.e. a(1), get defined. The other 31 elements have > processor-dependent values. If you want to unpack bits, try: > > write(*, '(B32.32)') x > forall(i=0:31) a(i+1) = btest(x, i) Ok. I was missing the part in the introduction to 8.8 that had the bit model going from 0 to wordsize - 1 and right to left. I think that I've peeled the bits out of this correctly now: program z integer :: x = 2143289344 logical, dimension(0:31) :: a integer, dimension(0:31) :: b write(*, '(B32.32)') x forall(i=0:31) a(i) = btest(x, 31 -i) print *, a forall(i=0:31) b(i) = transfer(a(31 -i), x) do i = 0, 31 print *, " bit ", i, " is ", b(i) end do end program z ! gfortran dw2.f90 -Wall -Wextra -o out output: dan(a)dan-desktop:~/source$ ./out 01111111110000000000000000000000 F T T T T T T T T T F F F F F F F F F F F F F F F F F F F F F F bit 0 is 0 bit 1 is 0 bit 2 is 0 bit 3 is 0 bit 4 is 0 bit 5 is 0 bit 6 is 0 bit 7 is 0 bit 8 is 0 bit 9 is 0 bit 10 is 0 bit 11 is 0 bit 12 is 0 bit 13 is 0 bit 14 is 0 bit 15 is 0 bit 16 is 0 bit 17 is 0 bit 18 is 0 bit 19 is 0 bit 20 is 0 bit 21 is 0 bit 22 is 1 bit 23 is 1 bit 24 is 1 bit 25 is 1 bit 26 is 1 bit 27 is 1 bit 28 is 1 bit 29 is 1 bit 30 is 1 bit 31 is 0 dan(a)dan-desktop:~/source$ Does that look right? > > where you should also note the form of the edit descriptor that allows > you to see leading zeros. ok. Thx. -- frank "Guns: yes, they are harmful."
From: frank on 4 Dec 2009 15:33 On Thu, 03 Dec 2009 06:34:34 -0800, Tim Prince wrote: > Anyway, a C cast doesn't broadcast a scalar across an array, which Frank > requires to make TRANSFER "work." Frank's undefined concept of "the C" > probably is not intended to correspond with any standard C, so it's not > likely to be widely accepted as a model for Fortran. 2 replies already > pointed out that the most readily available textbooks state explicitly > that TRANSFER array elements beyond the SIZE of the source are > "processor dependent" (undefined, in C terminology). I guess that may > be stated in Frank's reference, a few words beyond where he chose to > stop quoting. The commonly used web reference is giving me a long > delay, then Adobe message "file is damaged and could not be repaired." > Analogous to Glen's suggestion about memcpy(), C memset() broadcasts a > char across an array of char[]. C++ fill() broadcasts a variety of data > types, but I wouldn't have much confidence in arbitrary mixtures of > types which violate C and C++ standards (unlike "the C"). Of course, it > would only require assigning a scalar value to an entire array to > accomplish the broadcast which Frank wants. Maybe, by stopping reading > of the standard at an arbitrary point, it's possible to infer Frank's > interpretation. Frank's interpretation relies on a lot of confusion using syntax he hadn't before. I don't think I quoted poorly: http://gcc.gnu.org/onlinedocs/gfortran/TRANSFER.html I'm curious what you mean by "broadcasting." MM used the term "pouring," and I used the word "populating." Are these all synonyms? -- frank "Guns: yes, they are harmful."
From: Dan Nagle on 4 Dec 2009 17:16 Hello, On 2009-12-04 15:23:47 -0500, frank <frank(a)example.invalid> said: <snip bits from a logical> > Does that look right? It's either right or wrong, depending. Logicals have two values, true and false. These may be encoded at the processor's whim. I have seen zero v nonzero, positive v negative, even v odd, and probably something else I can't recall. Others have, no doubt, seen other encodings. That way are dragons. -- Cheers! Dan Nagle
From: Frank on 7 Dec 2009 03:13
On Fri, 4 Dec 2009 17:16:19 -0500, Dan Nagle wrote: > Hello, > > On 2009-12-04 15:23:47 -0500, frank <frank(a)example.invalid> said: > > <snip bits from a logical> > >> Does that look right? > > It's either right or wrong, depending. > > Logicals have two values, true and false. > These may be encoded at the processor's whim. > > I have seen zero v nonzero, positive v negative, > even v odd, and probably something else I can't recall. > > Others have, no doubt, seen other encodings. > > That way are dragons. This shakes my faith a little bit. Do C and Fortran have the same bit model for a float/default real? -- frank "Ben Bernanke talks of repealing social security instead of corporate welfare. What a schmutz." |