Home > Archive > Fortran > July 2006 > Viewing Double Prescision reals as Integers
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Viewing Double Prescision reals as Integers
|
|
| ferrad 2006-07-25, 7:00 pm |
| Say I have a common:
double precision r1
common /doubint/ r1
and another common elsewhere:
integer i1, i2
common /doubint/ i1, i2
Then will the two halves of the variable r1 always translate into valid
integers in i1 and i2? Or are there 'NaN' equivalents in the integer
world?
| |
| David Flower 2006-07-25, 7:00 pm |
|
ferrad wrote:
> Say I have a common:
>
> double precision r1
> common /doubint/ r1
>
> and another common elsewhere:
>
> integer i1, i2
> common /doubint/ i1, i2
>
> Then will the two halves of the variable r1 always translate into valid
> integers in i1 and i2? Or are there 'NaN' equivalents in the integer
> world?
Normally, you can determine this from the valid values for am integer.
Foer example, a two byte INTEGER can normally have values in the
inclusive range:
-32768 to 32767 which comprises 2**16 numbers.
It follows that all bit patterns must represent valid numbers.
Note however that Salford compilers use all bytes set to 80 Hex to
specify numbers as 'undefined'
Dave Flower
| |
|
|
ferrad wrote:
> Say I have a common:
>
> double precision r1
> common /doubint/ r1
>
> and another common elsewhere:
>
> integer i1, i2
> common /doubint/ i1, i2
>
> Then will the two halves of the variable r1 always translate into valid
> integers in i1 and i2? Or are there 'NaN' equivalents in the integer
> world?
The two integers will always be valid integers, but their value will be
whatever the bit pattern represents if stored via as floating point
value.
Of course, if you try to operate arithmetically on those integers you
could easily get integer overflow or other symptoms at that point...
| |
| Rich Townsend 2006-07-25, 7:00 pm |
| David Flower wrote:
> ferrad wrote:
>
> Normally, you can determine this from the valid values for am integer.
>
> Foer example, a two byte INTEGER can normally have values in the
> inclusive range:
> -32768 to 32767 which comprises 2**16 numbers.
>
> It follows that all bit patterns must represent valid numbers.
I disagree. As per the discussion of number models in Metcalf & Reid, the range
of valid numbers for Fortran INTEGERs is symmetric. Hence, not all specific bit
patterns are valid.
In the specific case of two-byte, two's complement integers you discuss, the
maximum possible range of valid values is -32767 -> 32767. Hence, -32768 is
always invalid.
I believe that this issue has cropped up a few times before on c.l.f.
cheers,
Rich
| |
| Steven G. Kargl 2006-07-25, 7:00 pm |
| In article <ea5r5m$1ml$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
> David Flower wrote:
>
> I disagree. As per the discussion of number models in Metcalf & Reid,
> the range of valid numbers for Fortran INTEGERs is symmetric. Hence,
> not all specific bit patterns are valid.
The model numbers only apply to
13.7 Numeric manipulation and inquiry functions
The numeric manipulation and inquiry functions are described in terms
of a model for the representation and behavior of numbers on a processor.
The model has parameters which are determined so as to make the model
best fit the machine on which the program is executed.
> In the specific case of two-byte, two's complement integers you discuss, the
> maximum possible range of valid values is -32767 -> 32767.
For model number, the above is correct.
> Hence, -32768 is always invalid.
No. It is not invalid.
i = -32768 ! Prefectly valid for some processor.
i = iabs(i) ! This is invalid bacause a numeric manipulation function
! would have to return an out-of-range number.
One other item. All of the compilers I have tried, do gradual
underflow. You need subnormal numbers for this, which are not
representable as real model numbers.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Rich Townsend 2006-07-25, 7:00 pm |
| Steven G. Kargl wrote:
> In article <ea5r5m$1ml$1@scrotar.nss.udel.edu>,
> Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
>
> The model numbers only apply to
>
> 13.7 Numeric manipulation and inquiry functions
> The numeric manipulation and inquiry functions are described in terms
> of a model for the representation and behavior of numbers on a processor.
> The model has parameters which are determined so as to make the model
> best fit the machine on which the program is executed.
>
>
>
> For model number, the above is correct.
>
>
> No. It is not invalid.
>
> i = -32768 ! Prefectly valid for some processor.
> i = iabs(i) ! This is invalid bacause a numeric manipulation function
> ! would have to return an out-of-range number.
>
>
> One other item. All of the compilers I have tried, do gradual
> underflow. You need subnormal numbers for this, which are not
> representable as real model numbers.
>
>
I stand corrected -- thanks for the clarification.
cheers,
Rich
| |
|
|
"ferrad" <acfer@hotmail.com> wrote in message
news:1153851375.239353.139070@m73g2000cwd.googlegroups.com...
> Say I have a common:
>
> double precision r1
> common /doubint/ r1
>
> and another common elsewhere:
>
> integer i1, i2
> common /doubint/ i1, i2
>
> Then will the two halves of the variable r1 always translate into valid
> integers in i1 and i2? Or are there 'NaN' equivalents in the integer
> world?
>
I suppose one could; however, the result may be less than useful.
First of all, the binary point (shows where the exponent starts and the
mantissa begins) is located somewhere in i1. Hence, i2 may not contain all
of the mantissa.
So, in order to create a full mantissa, you would need to concatenate all of
i2 with part of i1 paying attention to how the ieee specifies a possible
hidden bit.
All in all, this seems like a curiosity than anything else to me.
Jim
| |
| glen herrmannsfeldt 2006-07-25, 7:00 pm |
| Rich Townsend wrote:
> David Flower wrote:
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
I believe the result is the same, as far as the standard, as using
EQUIVALENCE.
I believe the standard requires the size of a default integer to be
the same as the size of a default real, and a double precision to
be twice the size.
The standard does not require all storage bits to be value bits
(I believe that is the C explanation, but it is also true for Fortran).
The IBM 704 has 36 bit words, but 16 bit integers. As far as I know,
even in that case an assignment will transfer all the bits, but you
can't extract them using integer arithmetic operations.
I believe some CDC machines will use all bits for add/subtract,
but fewer bits for multiply/divide.
For those reasons, or others, the standard makes no guarantee of
the result of EQUIVALENCE (including COMMON) for this operation.
(Note that the JVM processor forbids even looking at the bits
this way, and the verifier will refuse to load programs that do
it. I don't know if there is a Fortran compiler targeting
JVM, though.)
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> I disagree. As per the discussion of number models in Metcalf & Reid,
> the range of valid numbers for Fortran INTEGERs is symmetric. Hence, not
> all specific bit patterns are valid.
> In the specific case of two-byte, two's complement integers you discuss,
> the maximum possible range of valid values is -32767 -> 32767. Hence,
> -32768 is always invalid.
Well, ones complement or sign magnitude with a negative zero is one
possible complication. It might be that an assignment would transfer
the bits without converting a negative zero to a positive zero.
More important, the standard allows padding bits, that is, bits within
the word that don't represent the numeric value.
However, for the popular machines and compilers there is a very good
chance that it will work.
-- glen
| |
| John Harper 2006-07-25, 7:00 pm |
| In article <ea5r5m$1ml$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
>
> As per the discussion of number models in Metcalf & Reid, the range
> of valid numbers for Fortran INTEGERs is symmetric.
But this program:
INTEGER:: bigneg = -huge(1)
PRINT*,'-huge(1) =', bigneg
PRINT*,'-huge(1)-1 =', bigneg-1
END
prints this output with g95 and Sun, NAG and Compaq f95:
-huge(1) = -2147483647
-huge(1)-1 = -2147483648
I don't think I need to complain to either the 4 compiler suppliers
or to Metcalf, Reid and Cohen. Their "Fortran 95/2003 Explained"
does indeed (p.166) define a symmetric integer model, but it goes on
to say (p.166-167) that there may be some machine numbers that lie
outside the model. For example, many computers represent the integer
-r**q [although the largest positive integer is r**q - 1 if q is
digits(1) and the radix r is 2].
Does anything in the f95 or f2003 standard prohibit that?
The only thing I found in f2003 about machine-representable numbers
that weren't model numbers actually concerns reals not integers. Far
from prohibiting them, Note 13.16 says:
Unlike other floating-point manipulation functions, NEAREST
operates on machine-representable numbers rather than model
numbers. On many systems there are machine-representable numbers
that lie between adjacent model numbers.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| John Harper 2006-07-25, 10:00 pm |
| In article <ea5teu$lc4$1@gnus01.u.washington.edu>,
Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>
>For model number, the above is correct.
>
>
>No. It is not invalid.
>
> i = -32768 ! Prefectly valid for some processor.
> i = iabs(i) ! This is invalid bacause a numeric manipulation function
> ! would have to return an out-of-range number.
Sorry I didn't see that before sending my previous posting on this
topic. I tried that iabs for default integers with 4 compilers that
all have huge(1)==2147483647. Compaq f95 reported integer overflow,
but g95, Sun and NAG f95 all happily gave the answer -2147483648.
I'm not convinced that any of the compilers have a bug here!
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| Steven G. Kargl 2006-07-25, 10:00 pm |
| In article <1153876371.184098@bats.mcs.vuw.ac.nz>,
harper@mcs.vuw.ac.nz (John Harper) writes:
> In article <ea5teu$lc4$1@gnus01.u.washington.edu>,
> Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>
> Sorry I didn't see that before sending my previous posting on this
> topic. I tried that iabs for default integers with 4 compilers that
> all have huge(1)==2147483647. Compaq f95 reported integer overflow,
> but g95, Sun and NAG f95 all happily gave the answer -2147483648.
gfortran also gives -2147483648.
> I'm not convinced that any of the compilers have a bug here!
I would need to go read section 13 of the standard. Strictly
speaking I believe these are all nonconforming. However, the
standard does not require an error, so the implementations can
do whatever they want (including the wrap around overflow).
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| John Harper 2006-07-25, 10:00 pm |
| In article <ea6ggq$68a$1@gnus01.u.washington.edu>,
Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>
>gfortran also gives -2147483648.
>
>
>I would need to go read section 13 of the standard. Strictly
>speaking I believe these are all nonconforming. However, the
>standard does not require an error, so the implementations can
>do whatever they want (including the wrap around overflow).
Hmmm. The f2003 standard seems not to clarify this. Section 13.7
says among other things
A program is prohibited from invoking an intrinsic procedure under
circumstances where a value to be returned in a subroutine argument
or function result is outside the range of values representable by
objects of the specified type and type parameters, unless the intrinsic
module IEEE_ARITHMETIC (section 14) is accessible and there is support
for an infinite or a NaN result, as appropriate.
That says
the range of values representable by objects of the specified type
and type parameters
where it could have said
the range of values in the model for objects of the specified type
and type parameters
or some such wording. If a processor allows a representation of the
integer -huge(1)-1 it would seem that that's inside the relevant range
of values, so the section 13.7 prohibition does not apply, even though
-huge(1)-1 would overflow the standard's integer model.
F95 section 13.14 says the same thing but omits the f2003 clause
about IEEE arithmetic. IMHO that clause doesn't apply to integers
anyway, because section 14 is about real and complex IEEE arithmetic.
There is of course the corresponding puzzle with real underflowing
numbers, where IEEE_ARITHMETIC may be relevant.
A related issue is ACHAR(i) where i is an integer < 0 or > 127.
Both f95 and f2003 then say the result is processor dependent.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| glen herrmannsfeldt 2006-07-26, 4:01 am |
| John Harper wrote:
(snip)
> That says
> the range of values representable by objects of the specified type
> and type parameters
> where it could have said
> the range of values in the model for objects of the specified type
> and type parameters
> or some such wording. If a processor allows a representation of the
> integer -huge(1)-1 it would seem that that's inside the relevant range
> of values, so the section 13.7 prohibition does not apply, even though
> -huge(1)-1 would overflow the standard's integer model.
I would be very surprised if the standard allowed ones complement and
disallowed twos complement arithmetic. So would all the people
building twos complement machines.
-- glen
| |
| Steven G. Kargl 2006-07-26, 7:01 pm |
| In article <1153885672.675633@bats.mcs.vuw.ac.nz>,
harper@mcs.vuw.ac.nz (John Harper) writes:
> In article <ea6ggq$68a$1@gnus01.u.washington.edu>,
> Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>
> Hmmm. The f2003 standard seems not to clarify this. Section 13.7
> says among other things
>
> A program is prohibited from invoking an intrinsic procedure under
> circumstances where a value to be returned in a subroutine argument
> or function result is outside the range of values representable by
> objects of the specified type and type parameters, unless the intrinsic
> module IEEE_ARITHMETIC (section 14) is accessible and there is support
> for an infinite or a NaN result, as appropriate.
>
> That says
> the range of values representable by objects of the specified type
> and type parameters
> where it could have said
> the range of values in the model for objects of the specified type
> and type parameters
> or some such wording. If a processor allows a representation of the
> integer -huge(1)-1 it would seem that that's inside the relevant range
> of values, so the section 13.7 prohibition does not apply, even though
> -huge(1)-1 would overflow the standard's integer model.
>
> F95 section 13.14 says the same thing but omits the f2003 clause
> about IEEE arithmetic. IMHO that clause doesn't apply to integers
> anyway, because section 14 is about real and complex IEEE arithmetic.
>
> There is of course the corresponding puzzle with real underflowing
> numbers, where IEEE_ARITHMETIC may be relevant.
>
> A related issue is ACHAR(i) where i is an integer < 0 or > 127.
> Both f95 and f2003 then say the result is processor dependent.
John,
You found the revelant passages in both f95 and f2003. The key
issue is representable values of a data type can be (and usually
are) different than the model numbers. The standard does not
say it, but I suppose one can think of the model numbers as a
subset of the representable values. The (my) confusion comes up
from Section 13.7 of f95, which quoted previously
"The numeric manipulation and inquiry functions are described in terms
of a model for the representation and behavior of numbers on a processor.
The model has parameters which are determined so as to make the model
best fit the machine on which the program is executed."
In reading parts of Section 13, the above applies to the, inquiry
functions (e.g., RADIX, etc.), bit manipulation function (e.g., IBSET,
etc.), and the floating point manipulation functions (e.g., SCALE, etc.).
All other intrinsic procedure can return a "representable value" that
is not a model number.
Richard Maine must be on vacation (or at least off ot the net). He
normally corrects my interpretations of the standard. ;-)
--
Steve
http://troutmask.apl.washington.edu/~kargl/
|
|
|
|
|