Re: Integers and standard
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: Fri, 08 Aug 2008 14:15:43 -0800
Steven G. Kargl wrote:
(snip)
<insert>
13.7.97 REAL (A [, KIND])
...
Case (iii): If A is a boz-literal-constant, the value of the result
is equal to the value that a variable of the same type and
kind type parameters as the result would have if its value
were the bit pattern specified by the boz-literal-constant.
The interpretation of the value of the bit pattern is
processor dependent.
Permitting BOZ in these intrinsics has solved nothing. What value
is assigned to x in
real x
x = real(Z'F')
end
A Fortran processor is free to intrepret Z'F' as Z'0000000F' or Z'F0000000'
or any other convenient bit pattern for the unspecified bits. One should
also note that the above is silent on too many digits.
</insert>
Notice the phrase "The interpretation of the value of the bit pattern
is processor dependent." The standard refers to a bit pattern. If you write Z'F', you've specified only 8 bits. Period. For a 32-bit
REAL type, you have 24 unspecified bits. The standard does not say
anything about where to put the 8 bits and what values to choose for
the unspecified bits.
There are a few different things that go into that "processor
dependent bit pattern" comment. First, floating point formats
can be processor dependent. (Less so with the popularity
of IEEE 754-1985, but then again new IEEE standards may
come along.) Given the floating point format, the byte
order may be different for floating point and integer values.
(Even if it isn't, the best way to specify the bit pattern
might be different.) And finally, there is the question of
an underspecified or overspecified number of bits.
(Note that specifying exactly 32 bits in octal is difficult.)
The nonportability of BOZ as an argument to REAL (and the related
problems with TRANSFER) could have been avoided if the Standard
defined a set on intrinsics similar to IBSET and friends.
The ability to specify bit patterns INTEGER or other types
can be useful in many cases when portability isn't the
most important requirement. As the number of bits in
a REAL variable is system dependent, one can't expect
the bit patterns, or even their length, to be any
less system dependent. I don't believe that should
exclude them from being part of the standard.
It should probably be a compilation error to specify
the wrong number of digits. That would seem within
the 'processor dependent' clause. (With allowances
for incommensurate word width.)
----------------------------------------------------------
If you want something portable, it should be a binary,
octal or hex representation of a floating point value.
That is, a significand in the appropriate base, possibly
with a radix point, and an exponent indicating how for to
shift said radix point.
The digits of pi could be specified, for example, as
3.243F6A8885A308D313198A2E03707344A4093822299F31D008Z0, or
3243F6A8885A308D313198A2E03707344A4093822299F31D008Z-50,
(Possibly with some changes to avoid some ambiguous values.)
See http://www.super-computing.org/pi-hexa_current.html
-- glen
.
- References:
- Re: Integers and standard
- From: Jan Vorbrüggen
- Re: Integers and standard
- From: Steven G. Kargl
- Re: Integers and standard
- Prev by Date: Re: Fortran and Python
- Next by Date: Re: Integers and standard
- Previous by thread: Re: Integers and standard
- Next by thread: specification-stmt
- Index(es):
Relevant Pages
|
