468,463 Members | 2,030 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,463 developers. It's quick & easy.

max(NaN,0) should be NaN

After tracking down a bug in my Fortran program, I found that it
assumed
max(NaN,0.) = 0.

This makes no sense, as the outcome of the operation is undefined and
should be NaN.
max(NaN,0.) = NaN

After researching, it appears the first outcome is accepted behavior,
and might be included in the revised IEEE 754 standard, which affects
not only Fortran. The discussion posted at
http://www.cs.berkeley.edu/~ejr/Proj...21.html#minmax
suggests that "There is no mathematical reason to prefer one reason to
another."

But I think otherwise, for the following reason. Suppose the NaN is
produced by x/y, where x=0 came from an underflow and y=0 came from an
underflow. Then x/y would be a well-defined number that could be
postive or negative. The convetion max(NaN,0.) = 0. is wrong at least
half the time.

Aug 28 '06
61 7709

In article <92************@osl016lin.hda.hydro.com>,
Terje Mathisen <te************@hda.hydro.comwrites:
|>
|You always complain about people who quote you selectively! In this case
|you have snipped the paragraph where I agree with you, specifically that
|dropping NaN information is a _very_ surprising behavior.

Mea culpa. I apologise.

I did actually read what you said, and misunderstood it.
Regards,
Nick Maclaren.
Sep 7 '06 #51

Nick Maclaren wrote:
In article <11*********************@m73g2000cwd.googlegroups. com>,
"William Hughes" <wp*******@hotmail.comwrites:
|js*****@ecn.ab.ca wrote:
| Steven G. Kargl wrote:
| In article <11*********************@m73g2000cwd.googlegroups. com>,
| no***@yahoo.com writes:
|
| This makes no sense, as the outcome of the operation is undefined and
| should be NaN.
| max(NaN,0.) = NaN
|
| Why?
|
| Well, because a NaN *could* be plus infinity, or a number too large to
| be represented.
|
| If one wants to *implement* NaNs *at all*, one's _reason_ for doing so
| is because one wants computer arithmetic to produce accurate results -
| rather than just plugging in the best representable number that fits,
| and then giving a result that may not be valid.
|
| So going to the trouble of bothering with NaNs, and then deciding that
| treating them pessimistically is just too much bother in a few cases,
| vitiates the entire enterprise!
|>
|And you join the list of people who are willing to state on the
|basis of a few minutes thought and no research whatsoever, that the
|people behind the IEEE 754 standard are idiots.

You are wrong on three counts:

max/min are not part of IEEE 754, and are not even in the appendix;
they are proposed as part of IEEE 754R.
A quibble.
He did not state that they were idiots - merely misguided
More quibbling. He said that the proposed approach
"vitiates the entire enterprise". This is a lot stronger than
"misguided".
- and you
have no evidence that he has done no research.
Since he has no idea of why NAN's are used
and is incorrect about the reasons behind
the proposed behaviour of max(NAN,0.) , I concluded he
has done no research.
>
I am pretty sure that he knows of my analysis of the matter (and
document on it),
I see no evidence of this other than he agrees in conclusion.
How do you account for his lack of knowledge if he is familiar
with your analysis.
>where I do explain why he is correct and the IEEE 754R
people are wrong. And, in THIS respect, I believe that I have more
experience than any of the people on that group.

OK?
Beside the point. Your opinion is obviously informed and I have
not claimed otherwise. However, I stongly suspect that the
opinions of other IEEE 754R people are also informed.
-William Hughes

Sep 7 '06 #52
In article <11*********************@m73g2000cwd.googlegroups. com>,
William Hughes <wp*******@hotmail.comwrote:
>js*****@ecn.ab.ca wrote:
>Steven G. Kargl wrote:
In article <11*********************@m73g2000cwd.googlegroups. com>,
no***@yahoo.com writes:
This makes no sense, as the outcome of the operation is undefined and
should be NaN.
max(NaN,0.) = NaN
Why?
>Well, because a NaN *could* be plus infinity, or a number too large to
be represented.
>If one wants to *implement* NaNs *at all*, one's _reason_ for doing so
is because one wants computer arithmetic to produce accurate results -
rather than just plugging in the best representable number that fits,
and then giving a result that may not be valid.
>So going to the trouble of bothering with NaNs, and then deciding that
treating them pessimistically is just too much bother in a few cases,
vitiates the entire enterprise!
>And you join the list of people who are willing to state on the
basis of a few minutes thought and no research whatsoever, that the
people behind the IEEE 754 standard are idiots.
One can see that problems that something can cause almost
immediately, and without doing any real "research".

I would say that the ones who produced that standard did
not fully examine the adverse consequences that their
actions could cause, even when they were pointed out to
them.

This applies to other standards as well; those who think
they can provide "what is necessary or appropriate" are
only fooling themselves, and often harming others.

--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hr****@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558
Sep 7 '06 #53

Herman Rubin wrote:
In article <11*********************@m73g2000cwd.googlegroups. com>,
William Hughes <wp*******@hotmail.comwrote:
js*****@ecn.ab.ca wrote:
Steven G. Kargl wrote:
In article <11*********************@m73g2000cwd.googlegroups. com>,
no***@yahoo.com writes:
This makes no sense, as the outcome of the operation is undefined and
should be NaN.
max(NaN,0.) = NaN
Why?
Well, because a NaN *could* be plus infinity, or a number too large to
be represented.
If one wants to *implement* NaNs *at all*, one's _reason_ for doing so
is because one wants computer arithmetic to produce accurate results -
rather than just plugging in the best representable number that fits,
and then giving a result that may not be valid.
So going to the trouble of bothering with NaNs, and then deciding that
treating them pessimistically is just too much bother in a few cases,
vitiates the entire enterprise!

And you join the list of people who are willing to state on the
basis of a few minutes thought and no research whatsoever, that the
people behind the IEEE 754 standard are idiots.

One can see that problems that something can cause almost
immediately, and without doing any real "research".
Yes, but one may not be able to see problems that a change
would cause without doing research. In this case it is clear that
setting max(NAN,0.)=0. will cause problems. It is less clear why
setting max(NAN,0.)=NAN will cause problems. It is not at all
clear which solution should be preferred. John Savard seems to
have based his conclusion only on the fact that setting
max(NAN,0.)=0. will cause problems.
I would say that the ones who produced that standard did
not fully examine the adverse consequences that their
actions could cause, even when they were pointed out to
them.
Perhaps, and perhaps not. Since we have little information
about the consequences of setting max(NAN,0.)=0 (and John
Savard appears to have none) how do you justify this statment.
This applies to other standards as well; those who think
they can provide "what is necessary or appropriate" are
only fooling themselves, and often harming others.
I agree, but you have set up a straw man. Yes, those
who think they can provide "what is necessary or appropriate"
are only fooling themselves, but no, I don't put automatically
put people who create standards in this catagory.

Normally, there is no "what is necessary or appropriate"
to be provided, tradeoffs and compromises must be made.
Despite this standards are very useful. Problems arise when
people believe that no compromises are necessary.
They then note of some standard that it
causes some specific problem and conclude that
the people who created the standard were incompetent because
they did not notice this.

This is very different from knowing the background of the
compromise and deciding that the wrong choice was made
(e.g. your complaint about speed being unduly emphasized at
the expense of accuracy)
-William Hughes

Sep 7 '06 #54
In comp.lang.fortran Jan Vorbr?ggen <jv**********@not-mediasec.dewrote:
(snip)
Clearly, there are two current interpretations of the semantics of NaN:
one is that a NaN means some prior computation yielded a non-representable
and exceptional result, the other is that this data value should be ignored.
Note that the S and R languages used in statistics have both NA and NaN.
NA for data that should be ignored, usually data that didn't exist in
the input data set, such as someone not answering a survey question.

As an interpreted language it is fairly easy to do, though I believe
they use an IEEE NaN value with different values in the low order bits.

It might be an interesting feature to add to other languages and/or
hardware.

-- glen
Sep 7 '06 #55
Nick Maclaren wrote:
In article <92************@osl016lin.hda.hydro.com>,
Terje Mathisen <te************@hda.hydro.comwrites:
|>
|You always complain about people who quote you selectively! In this case
|you have snipped the paragraph where I agree with you, specifically that
|dropping NaN information is a _very_ surprising behavior.

Mea culpa. I apologise.

I did actually read what you said, and misunderstood it.
OK, no problem.

OTOH, having a standard which requires silent removal of NaNs _is_ a
problem. :-(

Terje

--
- <Te************@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Sep 8 '06 #56
William Hughes wrote:
>
In this case it is clear that setting max(NAN,0.)=0. will cause
problems. It is less clear why setting max(NAN,0.)=NAN will cause
problems. It is not at all clear which solution should be preferred.
As I understand Nick's point, the problem is the conflation of two
meanings for NaN, so it wouldn't be at all surprising to me if there
were *no* definite right answer for max(NaN,0).

Now, I probably have less experience and knowledge in this area than
anyone who has so far contributed to this thread, but if I may be
indulged a little, what is wrong with...

max(QNaN,0) = 0
max(SNaN,0) = SNaN
Sep 8 '06 #57

In article <kt************@osl016lin.hda.hydro.com>,
Terje Mathisen <te************@hda.hydro.comwrites:
|>
|OTOH, having a standard which requires silent removal of NaNs _is_ a
|problem. :-(

I quite agree. C99 Annex F - just say "no".
Regards,
Nick Maclaren.
Sep 8 '06 #58

In article <ed*******************@news.demon.co.uk>,
Ken Hagan <K.*****@thermoteknix.co.ukwrites:
|>
|As I understand Nick's point, the problem is the conflation of two
|meanings for NaN, so it wouldn't be at all surprising to me if there
|were *no* definite right answer for max(NaN,0).

There IS a definite right answer, using the meaning of NaN that is implied
by IEEE 754, and it is NaN. To get the other answer, you need a meaning
of NaNs that is not currently in IEEE 754.

|Now, I probably have less experience and knowledge in this area than
|anyone who has so far contributed to this thread, but if I may be
|indulged a little, what is wrong with...
|>
| max(QNaN,0) = 0
| max(SNaN,0) = SNaN

BAD idea. Sorry. Firstly, IEEE 754 requires max(SNaN,0) to raise the
invalid exception, secondly, that would imply that QNaN+0.0 = 0.0 and,
thirdly, the only languages that 'support' IEEE 754 use only QNaNs.
Regards,
Nick Maclaren.
Sep 8 '06 #59
hi

Had the inspiration when doing data bases a while back, that as well as
null, void is also needed.

null=unknown quantity
void=no quantity

max(null,0)=null
max(void,0)=0

NaN appears like a null so max(nan,0)=nan ;-) curry shop ahoy!!

NaD would be Not a Datum

cheers.

jacko

Sep 8 '06 #60

Terje Mathisen wrote:
There is at least one good reason for the current standard behavior:

It maintains the maximum amount of information.
...

OTOH there is an equally good reason for requiring the opposite
behavior, i.e. max(...) is NaN if any input value is NaN:
This is why 754R specifies two separate functions, max() and maxnum()
(and similarly for min() , maxmag() and minmag()).

Michel.

Sep 8 '06 #61

Nick Maclaren wrote:
In article <kt************@osl016lin.hda.hydro.com>,
Terje Mathisen <te************@hda.hydro.comwrites:
|>
|OTOH, having a standard which requires silent removal of NaNs _is_ a
|problem. :-(

I quite agree. C99 Annex F - just say "no".
Both of you should have participated in the 754R discussions, which are
winding down now -- but the official IEEE ballotting will start later
this year, and perhaps you should join the IEEE SA (Standards
Association) if you have not done so already (deadline Sept 28), so you
can comment when the draft is published for review in a month or so.

The standard deliberately avoids assigning meaning to NaN payloads, but
from various discussions about the distinction between "missing data"
and "invalid data" it seems to me that defining a particular NaNcode
(other than the machine default) for "missing" would have been quite
valuable. I'm just afraid of bringing it up so late in the game...
Interestingly IBM's "High Level Assembler" does support defining two
kinds of quiet NaN in floating-point constants: (NAN) implies machine
default (double 0x7ff80000...) and (QNAN) implies 0x7ffc0000... but I
don't know of any software that exploits this.

Michel.

Sep 8 '06 #62

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.