Does posix say anything about the sign in NaNs ?

[Bruce Evans]

On Thu, 25 Dec 2014, Pedro Giffuni wrote:

> On 12/25/14 14:35, Warner Losh wrote:
>>> On Dec 25, 2014, at 7:53 AM, Pedro Giffuni <pfg at freebsd.org> wrote:
>>>> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans <brde at optusnet.com.au> 
>>>> ha scritto:
>>>> ...
>>>> The library intentionally suppresses the sign for NaNs on output.
>>>> This is consistent with it ignororing the sign for NaNs on input.
>>> 
>>> Interesting and pretty much the reason why I wanted to discuss the change.
>>> 
>>> I can see the sign information is important for infinity but indeed it 
>>> makes
>>> very little sense (if any) for NaN. OTOH, we are doing an extra assignment
>>> to hide something the standard permits. If we are ignoring the sign of 
>>> NaNs
>>> on input there should be no such sign information in the first place and
>>> ignoring the value is unnecessary.

The sign is for debugging, but not very useful without all the NaN bits.

>>> While I am tempted to follow the change, I think it is pretty much 
>>> innocuous
>>> as no reasonably correct program should depend on the sign of NaN.

>> My only concern with this change is that numeric programs might actually 
>> break because they know this implementation detail. Its here some way to 
>> discover if things my pysci or R have any change in behavior here? In 
>> addition to the standard, numerical methods have much apocrypha associated 
>> with them.

> Well, you should only get a NaN when you did something wrong in your 
> calculation
> and that's pretty much the end of it.

No, it is valid to generate NaNs intentionally (in C99 with Annex F).  Then
yo need to debug them.

> Googling around, it appears glibc did a 
> similar
> change, and it did cause issues to someone:
>
> http://stackoverflow.com/questions/3772835/getting-a-negative-nan-on-g-4-4-3-is-this-standard

Interesting.  The application parsed "nan", but couldn't handle "-nan".

This is an application bug.  Any valid inport should be accepted, and
that includes "-nan" and also "NAN" and other variations ending in
"-nan(n-char-sequence)" if you are producing the output using C.
But it is not very useful to generate

I think the application used a simple text parser.  awk(1) accepts
"nan(any)" + 0, as a NaN, but it has a buggy parser since it also
accepts "nanany(any)" + 0 as a NaN.  Parsing C output using C input
routines hopefully works more correctly.

> Given it's implementation dependent I now think it is better to keep the 
> historical
> behavior consistent so I won't be committing the change.

Good.

Bruce