Fortran / IEEE 754: MAXVAL and INF, NaN
Tobias Burnus
assume a Fortran 2003 compiler which supports all of IEEE 754 (i.e.
IEEE_SUPPORT_*(x) == .TRUE.). What values are then expected for the
following? (Required by the standard or, if not defined, expected by
you as a user.)
(In terms of processors, I assume in the following x86, x86-64,
PowerPC and similar; however, answers which go beyond these, e.g.
regarding computers which have numbers to the base of 10 instead of 2
are welcome as well.)
real :: x, INF, NAN
INF = IEEE_VALUE(x, IEEE_POSITIVE_INF)
NAN = IEEE_VALUE(x, IEEE_QUIET_NAN)
a) MAXVAL( [ huge(x), NaN ] )
b) MAXVAL( [ huge(x), NaN, INF ] )
c) MAXVAL( [ NaN ] )
d) MAXVAL( [ ] )
Following IEEE's max(), I'd expect that (a) returns HUGE(x), (b) INF,
and (c) NaN.
For (d) the Fortran standard says "the result has the value of the
negative number of the largest magnitude supported by the processor
for numbers of the type", which would be probably -HUGE(x).
Questions:
- To (d) can one also return -INF? This is the most negative number
possible though one can argue that -INF is not a "normal" number
contrary to -huge(x).
- To (c): Does maxval need to return NAN or would be -INF/-HUGE
possible as well?
Looking at several compilers,
MAXVAL( [INF] ) returns often +HUGE(x) and not +INF
MAXVAL( [NAN] ) returns +HUGE(X) or +INF or NAN or -NAN (SIC!)
(And similarly for MINVAL, though some compilers return INF for maxval
and NaN for minval or similar non-consistent results.)
Tobias
PS: The question was motivated by the gfortran bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
Chip Coldwell
> Hello,
>
> assume a Fortran 2003 compiler which supports all of IEEE 754 (i.e.
> IEEE_SUPPORT_*(x) == .TRUE.). What values are then expected for the
> following? (Required by the standard or, if not defined, expected by
> you as a user.)
>
> (In terms of processors, I assume in the following x86, x86-64,
> PowerPC and similar; however, answers which go beyond these, e.g.
> regarding computers which have numbers to the base of 10 instead of 2
> are welcome as well.)
>
> real :: x, INF, NAN
> INF = IEEE_VALUE(x, IEEE_POSITIVE_INF)
> NAN = IEEE_VALUE(x, IEEE_QUIET_NAN)
>
> a) MAXVAL( [ huge(x), NaN ] )
> b) MAXVAL( [ huge(x), NaN, INF ] )
> c) MAXVAL( [ NaN ] )
> d) MAXVAL( [ ] )
>
> Following IEEE's max(), I'd expect that (a) returns HUGE(x), (b) INF,
> and (c) NaN.
> For (d) the Fortran standard says "the result has the value of the
> negative number of the largest magnitude supported by the processor
> for numbers of the type", which would be probably -HUGE(x).
Interesting. Well, quoting from the 1985 IEEE-754 standard:
"Infinity arithmetic shall be construed as the limiting case of real
arithmetic with operands of arbitrarily large magnitude, when such a
limit exists. Infinites shall be interpreted in the affine sense, that
is, −∞<(every finite number)<+∞."
and
"Every operation involving one or two input NaNs, none of them
signaling, shall signal no exception but, if a floating point result
is to be delivered, shall deliver as its result a quiet NaN, which
should be one of the input NaNs."
so I would say the standard requires
a) NAN
b) NAN
c) NAN
d) INF
Chip
--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
Somerville, Massachusetts, New England
Chip Coldwell
Oooh, but there's more to it:
"5.7 Comparison
.... Four mutually exclusive relations are possible: less than, equal,
greater than, and unordered. The last case arises when at least one
operand is NaN. Every NaN shall compare unordered with everything,
including itself....
In addition to the true-false response, an invalid operation exception
(7.1) shall be signaled when, as indicated in Table 4, last column,
unordered operands are compared using one of the predicates involving
< or > but not ? (Here the symbol ? signifies unordered)."
and also
"7.1 Invalid Operation
The invalid operation exception is signaled if an operand is invalid
for the operation to be performed. The result, when the exception
occurs without a trap, shall be a quiet NaN (6.2) provided the
destination has a floating-point format."
Now IEEE Std 754-1985 was written for folks implementing FPUs, not
Fortran intrinsics, so the operations considered are fine grained
(less than, greater than, etc) than Fortran intrinsics (MAXVAL,
MINVAL). Probably if you turned on FPU traps you would discover that
you were taking floating-point exceptions in the intrinsic when you
passed in a NaN.
Craig Dedo
news:rzp4pgo...@bogart.boston.redhat.com...
I disagree with Chip's answer in (d). I agree with him for (a), (b), and
(c). Some other parts of the IEEE standard and the Fortran 2003 standard are
relevant.
Fortran 2003 sec. 13.7.74 covers MAXVAL(). In part, the normative text
says:
Result Value.
Case (i): ... If ARRAY has size zero and type integer or real, the result
has the value of the negative number of the largest magnitude supported by the
processor for numbers of the type and kind type parameter of ARRAY. ...
Case (i) covers calls to MAXVAL without either the MASK or DIM arguments.
Thus, by this language, (d) should return -HUGE(0.0), i.e., the most
negative number for default REAL, since you have an empty array constructor and
no kind type parameter is specified. Arguably, it could return -INF.
Also, there are additional sections of IEC 60559 1989-01 that are relevant
for (a), (b), and (c). Section 7.1(8) specifies that an invalid operation
includes, "comparison via predicates involving '<' and '>' without '?' when the
operands are unordered (see 5.7, Table 4)". Section 5.7, par. 1 specifies,
"Every NaN shall compare 'unordered' with everything, including itself".
Section 6.2, par. 4 specifies, in part, "Every operation involving one or two
input Nans, none of them signalling, shall signal no exception, but if a
floating-point result is to be delivered, shall deliver as its result a quiet
Nan, which should be one of the input NaNs.".
Thus, by the combination of these sections, (a), (b), and (c) should all
deliver NaN as the return value for MAXVAL.
Comments, anyone?
--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cd...@wi.rr.com> or <cr...@ctdedo.com>
Chip Coldwell
Yes, you're right. I suppose the Fortran 2003 standard trumps
IEEE-754 for purposes of Fortran intrinsics.
> Also, there are additional sections of IEC 60559 1989-01 that are
> relevant for (a), (b), and (c). Section 7.1(8) specifies that an
> invalid operation includes, "comparison via predicates involving '<'
> and '>' without '?' when the operands are unordered (see 5.7, Table
> 4)". Section 5.7, par. 1 specifies, "Every NaN shall compare
> unordered' with everything, including itself". Section 6.2, par. 4
> specifies, in part, "Every operation involving one or two input Nans,
> none of them signalling, shall signal no exception, but if a
> floating-point result is to be delivered, shall deliver as its result
> a quiet Nan, which should be one of the input NaNs.".
>
> Thus, by the combination of these sections, (a), (b), and (c)
> should all deliver NaN as the return value for MAXVAL.
In particular, a quiet NaN. But I think doing a comparison with a
quiet NaN does raise an invalid operation exception (section 7.1 of
IEEE Std 754-1985).
The question that sticks in my mind is does any of this apply to a
Fortran MAXVAL intrinsic? After all, the floating point standars are
meant to guide the design of floating point processors, not language
intrinsics. I just don't know, but my bias would be to return a quiet
NaN from MAXVAL and trap an invalid operation exception if enabled.
Tobias Burnus
> "Chip Coldwell" <coldw...@gmail.invalid> wrote in message
> > so I would say the standard requires
> >
> > a) NAN
> > b) NAN
> > c) NAN
> > d) INF
>
> (c). Some other parts of the IEEE standard and the Fortran 2003 standard are
> relevant.
Hmm, regarding (a) to (c) I was thinking that NaN should be handled in
MAXVAL equivalently to IEEE's MAX which has in IEEE 754r (2006-09-17;
sorry, I don't have IEEE 754 itself at hand) the following:
"sourceFormat maxNum(source, source)
[...]
maxNum(x,y) is y if x < y, x if y < x, the floating-point number if
one operand is a floating-point
number and the other a NaN. Otherwise it is either x or y."
(It might well be that this part is not in IEEE 754-1985.)
And therefore, I assumed:
>> a) MAXVAL( [ huge(x), NaN ] )
>> b) MAXVAL( [ huge(x), NaN, INF ] )
>> c) MAXVAL( [ NaN ] )
gives the result: HUGE(x), INF, NaN (i.e. MAXVAL implementation using
IEEE's MAX); if one implements MAXVAL using "<" etc. directly, I come
also to the result NaN for (a) and (b).
Tobias
Craig Dedo
news:1192723970....@v29g2000prd.googlegroups.com...
Fortran 2003, section 1.9, references IEC 60559 (1989-01), "Binary
Floating-point Arithmetic for Microprocessor Systems", as the normative
reference for IEEE arithmetic. The same section also says that IEC 60559 was
originally IEEE 754-1985 and "this standard refers to it as the IEEE
International Standard". The phrase "IEEE International Standard" occurs
extensively throughout section 14, which defines the IEEE arithmetic and
exception handling facilities of Fortran 2003.
As far as I know, the 1989-01 version is still in effect; it has not been
superseded. Someone please correct me if I am wrong about this.
James Giles
...
>> Tobias Burnus <bur...@net-b.de> writes:
...
>>> a) MAXVAL( [ huge(x), NaN ] )
>>> b) MAXVAL( [ huge(x), NaN, INF ] )
>>> c) MAXVAL( [ NaN ] )
>>>
>>> Following IEEE's max(), I'd expect that (a) returns HUGE(x), (b)
>>> INF, and (c) NaN.
> Thus, by the combination of these sections, (a), (b), and (c)
> should all deliver NaN as the return value for MAXVAL.
This issue has come up on this forum before (I can't remember
exactly when). I agreed with the reasoning that Craig (and others)
in this thread use. I think the answer ought to be NaN in all the
first three cases. Unfortunately proposed new the IEEE standard
(754r) adds new operations MIN and MAX. The relevant part
of that standard is:
> An implementation shall provide operations to find the minimum
> and maximum of two floating-point values. These operations are
> unexceptional. If both operands are NaN, see section 6.2. If
> only one operand is NaN, these operations return the numerical
> operand. [...]
and later:
> [RATIONALE for min and max:
>
> max(x,y) is defined as that value for which the following is true
> for every z:
> z <= max(x,y) iff z <=x OR z <=y .
> As a consequence of this definition, max(5,NaN) is 5.
The same reasoning (with reverse order) would of course apply
to MIN. Only if all the operands are NaN do the MIN and MAX
functions return NaN (that's what the section 6.2 stuff says).
So, generalizing this to multi-argument versions of MIN and MAX,
the answer should be whatever would be chosen if the NaNs weren't
present, except for the case where all the operands are NaNs.
IEEE functions always have two arguments, so it doesn't directly
say what the result for an N-ary MIN or MAX should be if there
are no operands at all.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
Craig Dedo
news:waNRi.234407$ax1.1...@bgtnsc05-news.ops.worldnet.att.net...
Two observations.
1. This definition of MIN and MAX directly contradicts the rules of the
1989-01 version. If the IEEE, IEC, and ISO persist with this definition, then
they will create an upward incompatibility.
2. Has this new proposed version been ratified yet? If not, when is the
public comment period? If so, when was it published?
James Giles
> "James Giles" <james...@worldnet.att.net> wrote in message
> news:waNRi.234407$ax1.1...@bgtnsc05-news.ops.worldnet.att.net...
>> So, generalizing this to multi-argument versions of MIN and MAX,
>> the answer should be whatever would be chosen if the NaNs weren't
>> present, except for the case where all the operands are NaNs.
>> IEEE functions always have two arguments, so it doesn't directly
>> say what the result for an N-ary MIN or MAX should be if there
>> are no operands at all.
> Two observations.
>
> 1. This definition of MIN and MAX directly contradicts the rules
> of the 1989-01 version. If the IEEE, IEC, and ISO persist with this
> definition, then they will create an upward incompatibility.
That's what I thought. But, being really pedantic in language lawyer
mode the proponents point out that these new definitions *don't*
contradict the earlier version. The earlier version, when it referred
to "all operations involving one or more NaNs" was talking about
operations defined as part of that version of the standard and not about
any operations that had yet to be standardized. So it's not incompatible.
Whether you buy into that or not, I can actually see some value in their
position. It really is useful for MAN and MIN to preserve certain
identities that are true for ordinary numbers. Of course, it's also
useful to preserve the identity that any operation whose operands are
NaN should return NaN. It's certainly likely to be addressed in their
public review.
> 2. Has this new proposed version been ratified yet? If not, when
> is the public comment period? If so, when was it published?
My last information (and it's quite old - months) is that their public
review was announced and then withdrawn. The was some reserved
celebration (at least that how it seemed to me) among the J3 crowd
that maybe that meant the new proposal would be itself withdrawn.
But, as I understood it, the snag in their public review was purely
administrative and that the proposal is still alive and well.
Since I didn't actually see the original announcement for public review,
I obvously don't look the right places. So, when it's again sent out for
publiic review I'll probably miss that one too. I only heard about the
last one because of that (jubilant?) discussion of it in the J3 mailing
list.
Maybe it's already back out for review now.
Dan Nagle
I'm not tracking 754r especially closely, but ...
James Giles wrote:
> My last information (and it's quite old - months) is that their public
> review was announced and then withdrawn.
There were hundreds of comments on each of the three previous ballots.
Simply, it's not a happy consensus.
> The was some reserved
> celebration (at least that how it seemed to me) among the J3 crowd
> that maybe that meant the new proposal would be itself withdrawn.
J3 is concerned that 754r won't be approved in time for f08.
We have work items dependent upon 754r, and we'll be forced
to withdraw them if 754r isn't done when f08 is. This has been
discussed within J3 as a contingency with which we must cope.
At least some other language committees feel the same way.
> But, as I understood it, the snag in their public review was purely
> administrative and that the proposal is still alive and well.
Alive and well is a judgment call, but needing three ballots
and receiving hundreds of comments on each ballot isn't good.
The latest objection was strictly procedural (no change bars
in the draft, it was impossible to add them because there were
too many overlapping changes), but the fact of the objection means that
not everyone is happy. That's not a good sign for timely progress.
I wouldn't bet even money that 754r will be published anytime soon.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
Chip Coldwell
> Craig Dedo wrote:
>> "James Giles" <james...@worldnet.att.net> wrote in message
>> news:waNRi.234407$ax1.1...@bgtnsc05-news.ops.worldnet.att.net...
> ...
>>> So, generalizing this to multi-argument versions of MIN and MAX,
>>> the answer should be whatever would be chosen if the NaNs weren't
>>> present, except for the case where all the operands are NaNs.
>>> IEEE functions always have two arguments, so it doesn't directly
>>> say what the result for an N-ary MIN or MAX should be if there
>>> are no operands at all.
> ...
>> Two observations.
>>
>> 1. This definition of MIN and MAX directly contradicts the rules
>> of the 1989-01 version. If the IEEE, IEC, and ISO persist with this
>> definition, then they will create an upward incompatibility.
>
> That's what I thought. But, being really pedantic in language lawyer
> mode the proponents point out that these new definitions *don't*
> contradict the earlier version. The earlier version, when it referred
> to "all operations involving one or more NaNs" was talking about
> operations defined as part of that version of the standard and not about
> any operations that had yet to be standardized. So it's not incompatible.
I disagree. They state that comparisons (<,>,>=,<=) with NaNs in
either operand return quiet NaNs and invalid operand exceptions. How
do you reconcile that with max(NaN,number) = number?
> Whether you buy into that or not, I can actually see some value in their
> position. It really is useful for MAN and MIN to preserve certain
> identities that are true for ordinary numbers. Of course, it's also
> useful to preserve the identity that any operation whose operands are
> NaN should return NaN.
Indeed. Otherwise, a NaN generated in one part of a computation could
become "hidden" later. The result is a completely bogus result,
instead of NaN.
I think this is a Bad Idea.
James Giles
> "James Giles" <james...@worldnet.att.net> writes:
...
>> That's what I thought. But, being really pedantic in language lawyer
>> mode the proponents point out that these new definitions *don't*
>> contradict the earlier version. The earlier version, when it
>> referred to "all operations involving one or more NaNs" was
>> talking about operations defined as part of that version of the
>> standard and not about any operations that had yet to be standardized.
>> So it's not incompatible.
>
> I disagree. They state that comparisons (<,>,>=,<=) with NaNs in
> either operand return quiet NaNs and invalid operand exceptions. How
> do you reconcile that with max(NaN,number) = number?
Well, not all comparisons generate exceptions (==, /=, for example),
and none of them return NaNs (the return type is boolean/logical,
whatever your language calls it). And they recommended additional
operations that don't generate exceptions even when operands are
NaN. For example, an operator that tests for NOT(?>=) actually
tests for less-than, but doesn't generate exceptions (it returns false
if either operand is NaN).
> Indeed. Otherwise, a NaN generated in one part of a computation could
> become "hidden" later. The result is a completely bogus result,
> instead of NaN.
>
> I think this is a Bad Idea.
Often. On the other hand there are problem domains where NaN actually
means "don't care" and the programmer wants quite explicitly no to be
bothered with them. Data bases was mentioned the last time this was
discussed. I'm rather of your opinion on this. But you won't will by
arguing the point about concictency with the language lawyers of the
committee.
I think maybe the best solution is to make the choice explicit by having
two versions of each of MAX and MIN, one of which ignores NaNs
and the other of which doesn't. Of course, that would probably lead
to a long argument about what to name them.
john.c...@simcon.uk.com
which does not, by
default, trap with a useful diagnostic any arithmetic use of NaN is
unacceptable in our
environment - design of commercial aircraft, of nuclear power-plant
and of other engineering
systems.
What are the requirements in the Fortran standard to trap exceptions?
What should they be?
Best wishes,
John.
Wade Ward
"James Giles" <james...@worldnet.att.net> wrote in message
news:waNRi.234407$ax1.1...@bgtnsc05-news.ops.worldnet.att.net...
I'm not sure what you mean here with respect to order. If it applies to:
>> z <= max(x,y) iff z <=x OR z <=y .
, then you'd revesre the inequalities, but if it applies to:
max(5,NaN)
being different than
max(NaN,5)
, then I don't see a difference.
For my two cents, I would want a) b) and c) to come back as NaN.
--
wade ward
"Nicht verzagen, Bruder Grinde fragen."
Pierre Asselin
> Whether you buy into that or not, I can actually see some value in their
> position. It really is useful for MAN and MIN to preserve certain
> identities that are true for ordinary numbers.
Yeah, but which ones ? Should MAX preserve
z <= MAX(x,y) iff z <= x or z <= y
or
MAX(x,y) <= z iff x <= z and y <= z
Sounds like they are trying to justify their MAX(x,Nan) a posteriori.
--
pa at panix dot com
ejk...@gmail.com
> With respect to the academic interest of the question, any system
> which does not, by
> default, trap with a useful diagnostic any arithmetic use of NaN is
> unacceptable in our
> environment - design of commercial aircraft, of nuclear power-plant
> and of other engineering
> systems.
Infinity and NaN arithmetic can be quite useful in the application
areas that you cite. For example, the fastest known algorithm for
computing eigenvectors of a general matrix can generate such results;
if NaNs are always trapped, then one must use a slower algorithm
(typically half as fast).
The same applies for common operations, such normalizing a vector,
where one wants a fast but robust method (e.g., one that can correctly
handle vectors with large elements). Ditto for Newton's method.
The original Cray supercomputers always trapped on overflow.
Because every such error was fatal, general-purpose mathematical
library routines had to go to great effort to avoid them, even if
they weren't likely to occur for most inputs. Such checking is
estimated to have reduced overall performance by a factor of 2 to 4
for commonly used linear algebra routines - very expensive for
a multimillion-dollar platform, particularly since such routines
were often in the innermost loops of many simulations.
Of course, NaNs can also result from program bugs. So a compromise
is finer-grained control - turn on trapping where NaNs imply bugs
and off where NaNs are harmless. Fortran 2003 provides standardized
facilities for this. For more information about the Fortran
facilities, consult Chapter 11 of Metcalf, Reid, and Cohen,
"Fortran 95/2003 Explained". To learn more about the role of
NaN arithmetic in scientific and engineering code, see James Demmel's
article, "Faster Numerical Algorithms via Exception Handling",
IEEE Trans. on Computers 43 (1994), 983-992.
--Eric
Craig Dedo
news:1192743251.4...@z24g2000prh.googlegroups.com...
> With respect to the academic interest of the question, any system
> which does not, by
> default, trap with a useful diagnostic any arithmetic use of NaN is
> unacceptable in our
> environment - design of commercial aircraft, of nuclear power-plant
> and of other engineering
> systems.
>
> What are the requirements in the Fortran standard to trap exceptions?
>
> What should they be?
>
> Best wishes,
>
> John.
There is nothing in the Fortran standard that requires a Fortran processor
to trap exceptions. Among other exclusions, Section 1.4, "Exclusions", says,
"1.4 Exclusions
This standard does not specify ...
(4) The program and processor behavior when this standard fails to establish an
interpretation except for the processor detection and reporting requirements in
items (2) through (8) of 1.5,"
The first three sentences of the first paragraph of section 14 state:
The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and IEEE_FEATURES
provide support for exceptions and IEEE arithmetic. Whether the modules are
provided is processor dependent. If the module IEEE_FEATURES is provided, which
of the named constants defined in this standard are included is processor
dependent.
The second paragraph lists several other exceptions to complete coverage.
The third paragraph of section 14 starts with this sentence:
If a scoping unit does not access IEEE_FEATURES, IEEE_EXCEPTIONS, or
IEEE_ARITHMETIC, the level of support is processor dependent, and need not
include any support for any exceptions.
The reasons for this great amount of flexibility in coverage is explained in
Note 14.3. Not all processors support IEEE arithmetic. Some platforms can have
very good support for some parts of IEEE, have inefficient support for other
parts, and have little or no support for still other parts of IEEE.
Should Fortran trap all exceptions? Since Fortran is designed to run on
both IEEE and non-IEEE platforms, it is hard for me to see how Fortran could be
required to trap all exceptions.
--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cd...@wi.rr.com> or <cr...@ctdedo.com>
> On Oct 18, 9:19 am, Tobias Burnus <bur...@net-b.de> wrote:
Chip Coldwell
> Chip Coldwell wrote:
>> "James Giles" <james...@worldnet.att.net> writes:
> ...
>>> That's what I thought. But, being really pedantic in language lawyer
>>> mode the proponents point out that these new definitions *don't*
>>> contradict the earlier version. The earlier version, when it
>>> referred to "all operations involving one or more NaNs" was
>>> talking about operations defined as part of that version of the
>>> standard and not about any operations that had yet to be standardized.
>>> So it's not incompatible.
>>
>> I disagree. They state that comparisons (<,>,>=,<=) with NaNs in
>> either operand return quiet NaNs and invalid operand exceptions. How
>> do you reconcile that with max(NaN,number) = number?
>
> Well, not all comparisons generate exceptions (==, /=, for example),
> and none of them return NaNs (the return type is boolean/logical,
> whatever your language calls it).
True. Previously, the standard had required behavior such that all
such comparisons would return false if either operand were a NaN:
1.0E0 > NaN is false
1.0E0 < NaN is false
1.0E0 = NaN is false
and even
NaN = Nan is false
the logic being that NaN is an unordered value. Chapter and verse is
section 5.17 of IEEE 754-1985:
"Comparisons are exact and never overflow nor underflow. Four mutually
exclusive relations are possible: less than, equal, greater than, and
unordered. The last case arises when at least one operand is
NaN. Every NaN shall compare unordered with everything, including
itself."
> And they recommended additional operations that don't generate
> exceptions even when operands are NaN. For example, an operator
> that tests for NOT(?>=) actually tests for less-than, but doesn't
> generate exceptions (it returns false if either operand is NaN).
The "NOT(?>=)" operation is meant to explicity check if an operand is
unordered. There are a set of such operations in the standard, the
corresponding Fortran operations are listed as ".UG.", ".UGE.",
".UL.", ".ULE." and ".UE." by which are meant "unordered or greater
than", etc. These return true if an operand is NaN. I don't know of
any implementations of these.
> Often. On the other hand there are problem domains where NaN actually
> means "don't care" and the programmer wants quite explicitly no to be
> bothered with them. Data bases was mentioned the last time this was
> discussed.
Balderdash. Databases have "NULL" to represent "don't care" for
values of any type, not just floating point. They don't need NaN for
this.
> I'm rather of your opinion on this.
Has William Kahan expressed an opinion?
> I think maybe the best solution is to make the choice explicit by having
> two versions of each of MAX and MIN, one of which ignores NaNs
> and the other of which doesn't.
The original 754 standard called for comparisons that would test for
unordered (NaN) operands (".UG." and friends). So these could be
implemented, and then a UMAX and UMIN implemented in terms of them.
However, according to the standard, they would behave in surprising
ways. If
UMAX(X,Y)
is implemented as
IF (X .UG. Y) THEN
UMAX = X
ELSE
UMAX = Y
END IF
Then UMAX(1.0E0,NaN) equals 1.0E0 but UMAX(NaN,1.0E0) equals NaN.
Chip Coldwell
> With respect to the academic interest of the question, any system
> which does not, by
> default, trap with a useful diagnostic any arithmetic use of NaN is
> unacceptable in our
> environment - design of commercial aircraft, of nuclear power-plant
> and of other engineering
> systems.
>
> What are the requirements in the Fortran standard to trap exceptions?
>
> What should they be?
This gets back to my earlier question of how relevant IEEE 754 (or any
similar standard) is to a discussion of Fortran. IEEE 754 is meant to
guide FPU implementations, not programming languages, so it is not
obvious that requiring IEEE 754 behavior has anything to do with
Fortran standards.
Having said that, I will point out that Fortran 2003 introduced the
"ieee_features" and "ieee_exceptions" modules, and these can be used
to configure your floating point environment such that your process
(on Unix) will be delivered a fatal SIGFPE when you attempt to use
NaN. I believe the correct syntax is
use ieee_exceptions
call ieee_set_halting_mode(ieee_invalid, .true.)
I haven't tried it; none of my compilers support these F2003 features.
Chip Coldwell
>
> Having said that, I will point out that Fortran 2003 introduced the
> "ieee_features" and "ieee_exceptions" modules, and these can be used
> to configure your floating point environment such that your process
> (on Unix) will be delivered a fatal SIGFPE when you attempt to use
> NaN. I believe the correct syntax is
>
> use ieee_exceptions
> call ieee_set_halting_mode(ieee_invalid, .true.)
>
> I haven't tried it; none of my compilers support these F2003 features.
Oh, I should mention that requiring precise float-point exceptions has
a deadly negative impact on performance on some architectures (notably
Alpha).
Dick Hendrickson
> Chip Coldwell <cold...@gmail.invalid> writes:
>
>> Having said that, I will point out that Fortran 2003 introduced the
>> "ieee_features" and "ieee_exceptions" modules, and these can be used
>> to configure your floating point environment such that your process
>> (on Unix) will be delivered a fatal SIGFPE when you attempt to use
>> NaN. I believe the correct syntax is
>>
>> use ieee_exceptions
>> call ieee_set_halting_mode(ieee_invalid, .true.)
There are also two predefined array constants that can be arguments to
ieee_set_halting_mode. ieee_usual and ieee_all to try and cover the
common cases.
The initial halting mode is processor dependent. However, the processor
isn't allowed to change the halting mode during execution (other than by
things like ieee_set_halting_mode ) and must save/restore it across
procedure calls. So, with a little practice, you can set up a global
halting status and do fine control for operations, like eigenvectors,
that are likely to generate faults in unusual cases.
Technically, the standard says halting is imprecise. In theory, a
processor could merely print out a retrospective summary after
program completion (what could be more imprecise?). In practice,
processors usually detect faults within a few cycles.
>>
>> I haven't tried it; none of my compilers support these F2003 features.
>
> Oh, I should mention that requiring precise float-point exceptions has
> a deadly negative impact on performance on some architectures (notably
> Alpha).
>
That's the nub of the reason for the large number of options in the 3
IEEE modules. In the 90s it wasn't obvious that all processors would
be IEEE processors and many important processors weren't even close.
Dick Hendrickson
> Chip
>
Gordon Sande
> Chip Coldwell wrote:
>> Chip Coldwell <cold...@gmail.invalid> writes:
>>
>>> Having said that, I will point out that Fortran 2003 introduced the
>>> "ieee_features" and "ieee_exceptions" modules, and these can be used
>>> to configure your floating point environment such that your process
>>> (on Unix) will be delivered a fatal SIGFPE when you attempt to use
>>> NaN. I believe the correct syntax is
>>>
>>> use ieee_exceptions
>>> call ieee_set_halting_mode(ieee_invalid, .true.)
>
> There are also two predefined array constants that can be arguments to
> ieee_set_halting_mode. ieee_usual and ieee_all to try and cover the
> common cases.
>
> The initial halting mode is processor dependent. However, the processor
> isn't allowed to change the halting mode during execution (other than by
> things like ieee_set_halting_mode ) and must save/restore it across
> procedure calls. So, with a little practice, you can set up a global
> halting status and do fine control for operations, like eigenvectors,
> that are likely to generate faults in unusual cases.
>
> Technically, the standard says halting is imprecise. In theory, a
> processor could merely print out a retrospective summary after
> program completion (what could be more imprecise?). In practice,
> processors usually detect faults within a few cycles.
Even more imprecise would be to only notice that some program in
a multiprogramming environment raised the condition at about the
time that the program was executing.
When CDC6600s were the state of the art and imprecise interupts were a
new notion I had a colleague who was a bit fussed by it all. He claimed
he fully expected to see a line at the end of his listing saying
"Would the following group of users please get together over coffee
and discuss the fact that one of them divided by zero."
Richard Maine
> Chip Coldwell wrote:
> > Oh, I should mention that requiring precise float-point exceptions has
> > a deadly negative impact on performance on some architectures (notably
> > Alpha).
>
> That's the nub of the reason for the large number of options in the 3
> IEEE modules. In the 90s it wasn't obvious that all processors would
> be IEEE processors and many important processors weren't even close.
And the Alpha in particular was a major influence. Since the Alpha was
an architecture of one of the most influential Fortran vendors, there
was no way that a Fortran standard was going to pass if it trashed
performance on an Alpha. I heard numbers like a factor of 100
performance cost. Those numbers might well have been exagerated for
debate purposes - I never tested - but I'm sure that the impact would
have been bad.
Thus the standard was written so that users could choose between
1.Leaving it up to the compiler, how much support to activate.
Presumably the compiler would activate only the "inexpensive bits".
2.Insist that features are really required, no matter what the cost. If
the compiler doesn't support them, then fail compilation.
Providing those options make that part of the standard quite a lot more
complicated than it otherwise would have been. But it made
implementation on systems like the Alpha viable, which was a requirement
for anything to have a chance of passing.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Richard Maine
> When CDC6600s were the state of the art and imprecise interupts were a
> new notion I had a colleague who was a bit fussed by it all. He claimed
> he fully expected to see a line at the end of his listing saying
>
> "Would the following group of users please get together over coffee
> and discuss the fact that one of them divided by zero."
Well, at least that would tie it down to a divide by zero. :-)
In my (quite a bit) younger days, I used to dread seeing the message
"Job not run. JCL error." on my outputs from running on IBM mainframes.
That left me to guess what kind of error I might have made.
I later figured out that there actually was more information (of sorts)
buried in the JCL output listing. But that listing was just a page (or
more) of gibberish to me. The only part I could understand at the time
was that last line, with the above-cited message.
Chip Coldwell
Tobias Burnus <bur...@net-b.de> writes:
I am cross-posting on comp.arch.arithmetic in the hopes that someone
there can shed some light on this issue. To summarize, the question
is whether
max(x,NaN)
should return x or NaN. The IEEE 754r standard clearly states that it
should return x; there seems to be a growing consensus on c.l.f that
this is completely bogus. Personally, I am of the opinion that any
operation that returns a floating point value should return NaN if any
operand is NaN -- NaN is like a trap door that once you have fallen in
you cannot come back out. Otherwise, the possibility exists that a
calculation will have gone off course undetectably.
Comments from c.a.a?
Nick Maclaren
In article <rzpabqf...@bogart.boston.redhat.com>,
Chip Coldwell <cold...@gmail.invalid> writes:
|>
|> I am cross-posting on comp.arch.arithmetic in the hopes that someone
|> there can shed some light on this issue. To summarize, the question
|> is whether
|>
|> max(x,NaN)
|>
|> should return x or NaN. The IEEE 754r standard clearly states that it
|> should return x; there seems to be a growing consensus on c.l.f that
|> this is completely bogus. Personally, I am of the opinion that any
|> operation that returns a floating point value should return NaN if any
|> operand is NaN -- NaN is like a trap door that once you have fallen in
|> you cannot come back out. Otherwise, the possibility exists that a
|> calculation will have gone off course undetectably.
Let's ignore the politics, which means that I can't explain the history
and background, either.
Yes, it is a catastrophe. I have a document on this area, which I can
send to interested people. The summary is that there are many types
of "not a number", of which IEEE 754 generally selects the one that
means "a value which indicates the result of an erroneous operation".
With that meaning, 'max(x,NaN) = NaN'.
The meaning where 'max(x,NaN) = x' is where a NaN is a missing value,
which was introduced into statistical packages in the 1960s. Now, if
you look a bit deeper into that, you discover three things:
1) In fact, statistical calculations need 'max(x,NaN) = NaN' in
all calculations EXCEPT vector reductions, because operations like
'max(variate,variate,...) = variate' (variate = vector, here) need
'max(x,NaN) = NaN'. It is only 'max(variate) = scalar' that doesn't.
2) It isn't true that the cost of 'max(x,NaN) = NaN' is too high;
indeed, it is completely wrong. No realistic statistical program
(or any program) is dominated by this operation, and 'max(x,NaN) = x'
forces extra code for the other, more common, case.
3) In statistical calculations, the order of reductions is well
known, and is roughly:
count(variate) - by far the most common and not provided by
IEEE754R, in any form.
sum(variate) - by far the second most common, and not provided
by IEEE754R in the 'missing value' form.
var(variate) |
max/min(variate) | in some order, depending on your statistics
product(variate) |
and then other, more specialised, ones.
Regards,
Nick Maclaren.
Steven G. Kargl
> there can shed some light on this issue. To summarize, the question
> is whether
>
> max(x,NaN)
>
> should return x or NaN. The IEEE 754r standard clearly states that it
> should return x; there seems to be a growing consensus on c.l.f that
> this is completely bogus. Personally, I am of the opinion that any
> operation that returns a floating point value should return NaN if any
> operand is NaN -- NaN is like a trap door that once you have fallen in
> you cannot come back out. Otherwise, the possibility exists that a
> calculation will have gone off course undetectably.
>
> Comments from c.a.a?
Check out the description of hypot() from the C standard.
hypot(+Inf,y) = hypot(-Inf,y) = +Inf, even if y = NaN.
Nick Maclaren
In article <ffasq1$uic$1...@gnus01.u.washington.edu>,
That's nothing :-( Look at pow:
pow(NaN,0) = 1
pow(+-inf,0) is unspecified
pow(-inf,y) returns +inf for y > 0 and not an odd integer.
and more.
Regards,
Nick Maclaren.
glen herrmannsfeldt
(snip)
> Personally, I am of the opinion that any
> operation that returns a floating point value should return NaN if any
> operand is NaN -- NaN is like a trap door that once you have fallen in
> you cannot come back out. Otherwise, the possibility exists that a
> calculation will have gone off course undetectably.
The possibly also exists that at went NaN needlessly.
I would say that, at least for some operations, the programmer
should have the choice.
For comparison, consider compilers that give up on the first
syntax error and those that try to keep compiling to give the
programmer the most information per compilation run.
There must be at least some cases where some result is better
than all NaN at the end of a long calculation.
Also, as Nick mentions, NaN isn't the best choice for a missing
value in many statistical calculations, but it is used because
it is there. Maybe a new type of NaN for statistical calculation
could be added?
-- glen
Chip Coldwell
Right, but IMHO the brokenness of the C standard has nothing to do
with the brokenness of IEEE 754. The latter is intended for FPU
implementors more than it is intended for language implementors.
If you want "max(x,NaN) = x", then
float max(float x, float y)
{
if (isnan(x))
return y;
else if (isnan(y))
return x;
else return (x > y ? x : y);
}
and we're done, right? We have a broken programming language
intrinsic built upon flawless hardware. Testing for NaN is not an
expensive operation, as was already pointed out in this thread. The
question in my mind is what should the behavior of the IEEE 754/854
compliant FPU (or vector coprocessor, e.g. SSE) be?
Chip Coldwell
> Chip Coldwell wrote:
> (snip)
>
>> Personally, I am of the opinion that any
>> operation that returns a floating point value should return NaN if any
>> operand is NaN -- NaN is like a trap door that once you have fallen in
>> you cannot come back out. Otherwise, the possibility exists that a
>> calculation will have gone off course undetectably.
>
> The possibly also exists that at went NaN needlessly.
>
> I would say that, at least for some operations, the programmer
> should have the choice.
>
> For comparison, consider compilers that give up on the first
> syntax error and those that try to keep compiling to give the
> programmer the most information per compilation run.
>
> There must be at least some cases where some result is better
> than all NaN at the end of a long calculation.
NaN already does this. You have always had the option of trapping
floating point exceptions such that your process halts on the first
invalid operand (e.g. max(x,NaN)) or continues with NaN plugged in
where there cannot be a more meaningful number (e.g. log(0)). At the
end of hours of computation, maybe some of your results are
meaningful, but at least the ones that are not are clearly marked as
such.
Getting back to Nick's point, the question is what does NaN mean? If
it means "invalid operand" such as sqrt(-1) or log(0), then I can
think of no reason why max(x,sqrt(-1)) should be anything other than
NaN. If it means "no value was supplied", well that's different, but
that's a new meaning to attach to NaN than I ever heard previously.
> Also, as Nick mentions, NaN isn't the best choice for a missing
> value in many statistical calculations, but it is used because
> it is there. Maybe a new type of NaN for statistical calculation
> could be added?
Well, let's call it NaV ("not a value"). Then
max(x,NaV) = x
min(x,NaV) = x
(x > NaV) is true (to be consistent with max)
(x < NaV) is true (to be consistent with min)
(NaV > NaV) is ?
(NaV == NaV) is ?
There are spare bits in the NaN representation that could be used to
differentiate between NaN and NaV at the risk of breaking backward
combatibility.
Nick Maclaren
In article <rzpir52...@bogart.boston.redhat.com>,
Chip Coldwell <cold...@gmail.invalid> writes:
|>
|> Well, let's call it NaV ("not a value"). Then
|>
|> max(x,NaV) = x
|> min(x,NaV) = x
|> (x > NaV) is true (to be consistent with max)
|> (x < NaV) is true (to be consistent with min)
|> (NaV > NaV) is ?
|> (NaV == NaV) is ?
Not really. In the traditional and mathematically consistent model,
NaVs percolate much like NaNs, but are subordinate to them. E.g.
NaV+NaN = NaN. The ONLY difference is in reduction operations.
In those, only non-NaVs are considered. count() gives the count of
non-NaVs. Most others return a NaN (sic) if there are only NaVs,
and use only the non-NAVs otherwise. var() requires two non-NAVs.
Etc.
|> There are spare bits in the NaN representation that could be used to
|> differentiate between NaN and NaV at the risk of breaking backward
|> combatibility.
Yes. But, given the degree of brokenness in current software support,
I doubt that many people would notice.
Regards,
Nick Maclaren.
glen herrmannsfeldt
(snip)
> If you want "max(x,NaN) = x", then
> float max(float x, float y)
> {
> if (isnan(x))
> return y;
> else if (isnan(y))
> return x;
> else return (x > y ? x : y);
> }
> and we're done, right? We have a broken programming language
> intrinsic built upon flawless hardware. Testing for NaN is not an
> expensive operation, as was already pointed out in this thread. The
> question in my mind is what should the behavior of the IEEE 754/854
> compliant FPU (or vector coprocessor, e.g. SSE) be?
Can it be done with conditional load on processors that
do that? max is easy to implement with conditional load, load
the first value, then conditional load the second if it is
greater (and maybe if equal) to the first. It gets a lot
more complicated if you want NaN to work out right.
Note that C89 doesn't even have max, but expects:
#define MAX(a,b) ((a)>(b)?(a):(b))
-- glen
Greg Lindahl
Chip Coldwell <cold...@gmail.invalid> wrote:
> Testing for NaN is not an
> expensive operation, as was already pointed out in this thread.
It would make max() significantly slower, which is why few (or no?)
compilers do it that way. And, you know, we had this entire
conversation at least once before.
-- greg
Chip Coldwell
Nick Maclaren
If you are allowed to get the wrong answer, you can make programs
run arbitrarily fast.
While it does make the cases where it is the correct action faster,
it makes the more common ones where it is the wrong one slower.
What sort of code do YOU favour?
#define bluemax(x,y) (isnan(x)||isnan(y)?NAN:max((x),(y))
#define bygraves(x,y) ((x)>=(y)?(x):((x)<(y)?(y):NAN))
or what?
Regards,
Nick Maclaren.
Terje Mathisen
> I am cross-posting on comp.arch.arithmetic in the hopes that someone
> there can shed some light on this issue. To summarize, the question
> is whether
>
> max(x,NaN)
>
> should return x or NaN. The IEEE 754r standard clearly states that it
> should return x; there seems to be a growing consensus on c.l.f that
> this is completely bogus.
We discussed this issue a while ago, mostly we seemed to agree with you.
The key problem is that some people would like NaN to mean:
"There is no value here, nothing to see. Please move on!"
and this is a more or less orthogonal issue to the Not a Number which is
the result of several undefined mathematical operations.
Trying to make NaN ("because it is what we have") do something which it
was never designed for is a stupid idea, imho.
Personally, I am of the opinion that any
> operation that returns a floating point value should return NaN if any
> operand is NaN -- NaN is like a trap door that once you have fallen in
> you cannot come back out. Otherwise, the possibility exists that a
> calculation will have gone off course undetectably.
Exactly the way I believe NaN should work.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Chip Coldwell
> Chip Coldwell wrote:
>> I am cross-posting on comp.arch.arithmetic in the hopes that someone
>> there can shed some light on this issue. To summarize, the question
>> is whether
>>
>> max(x,NaN)
>>
>> should return x or NaN. The IEEE 754r standard clearly states that it
>> should return x; there seems to be a growing consensus on c.l.f that
>> this is completely bogus.
>
> We discussed this issue a while ago, mostly we seemed to agree with you.
Yes, I found some of this here
> The key problem is that some people would like NaN to mean:
>
> "There is no value here, nothing to see. Please move on!"
>
> and this is a more or less orthogonal issue to the Not a Number which
> is the result of several undefined mathematical operations.
>
> Trying to make NaN ("because it is what we have") do something which
> it was never designed for is a stupid idea, imho.
Yes. What they want is some other sentinel value. Unfortunately,
IIUC, all the possibilities are spoken for.
For an example of current practice, take the Intel SIMD MAXPD (Return
Maximum Packed Double-Precision Floating Point Values) instruction.
Here's what it says:
"If a value in the second operand [source] is an SNaN, that SNaN is
forwarded unchaged to the destination (that is, a QNaN version of the
SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the
second operand (source operand), either a NaN or a valid
floating-point value, is written to the result. If instead of this
behavior, it is required that the NaN source operand (from either the
first or second operand) be returned, the action of the MAXPD can be
emulated using a sequence of instructions, such as, a comparison
followed by AND, ANDN and OR."
I think they've managed to violate all the published standards with
that one.
robert....@sun.com
wrote:
> > 2. Has this new proposed version been ratified yet?
No.
> If not, when is the public comment period?
The 1.5 draft is currently up for ballot. The ballot
period ends Nov. 10, 2007. If you know a member of
the ballot group, you can have him submit comments for
you.
Bob Corbett
Terje Mathisen
> For an example of current practice, take the Intel SIMD MAXPD (Return
> Maximum Packed Double-Precision Floating Point Values) instruction.
> Here's what it says:
I have actually read all of those manuals, x86 asm being almost a way of
life for me.
>
> "If a value in the second operand [source] is an SNaN, that SNaN is
> forwarded unchaged to the destination (that is, a QNaN version of the
> SNaN is not returned).
>
> If only one value is a NaN (SNaN or QNaN) for this instruction, the
> second operand (source operand), either a NaN or a valid
> floating-point value, is written to the result. If instead of this
> behavior, it is required that the NaN source operand (from either the
> first or second operand) be returned, the action of the MAXPD can be
> emulated using a sequence of instructions, such as, a comparison
> followed by AND, ANDN and OR."
>
> I think they've managed to violate all the published standards with
> that one.
The MAXPD opcode description sounds more like a "This is what we managed
to implement within the transistor/time budget. Deal with it!" than a
useful standard.
When I read that description the first time, I concluded that what they
meant to say was "We don't handle NaN's here, so don't write code that
depends on them."
...
Actually, there is a useful way to use this opcode safely, and that is
for a saturating range check, where the first operand is the limit to be
tested against:
I.e. SIMD code like this
;; xmm0 has the pair of results from a series of calculations,
;; now bracket them:
movapd xmm1,[lower_limit]
maxpd xmm1, xmm0
movapd xmm0,[higher_limit]
minpd xmm0, xmm1
This sequence will leave any incoming NaNs in xmm0, all other values
will be brought into the [lower_limit..higher_limit] range.
With working opcodes, or no NaN handling, the code would be simpler &
faster:
maxpd xmm0,[lower_limit]
minpd xmm0,[higher_limit]