Re: strtod ("nan") returns negative NaN

[Heavenly Avenger <avenger@avenger.ws>]

On 8/14/2018 10:23 AM, Corinna Vinschen wrote:
> On Aug 14 21:17, Masamichi Hosoda wrote:
>>> On Aug 14 11:56, Corinna Vinschen wrote:
>>>> On Aug 14 13:45, Masamichi Hosoda wrote:
>>>>> >From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
>>>>> From: Masamichi Hosoda <trueroad@trueroad.jp>
>>>>> Date: Tue, 14 Aug 2018 12:50:32 +0900
>>>>> Subject: [PATCH] Fix strtod ("nan") returns qNaN
>>>>>
>>>>> The definition of qNaN for x86_64 and x86 was wrong.
>>>>> So strtod ("nan") returned sNaN instead of qNaN.
>>>>>
>>>>> Furthermore, it was inverted the sign bit with the presence of `-` character.
>>>>> So strtod ("-nan") returned qNaN.
>>>>>
>>>>> This commit fixes definition of qNaN
>>>>> and removes the sign bit inversion when evaluating "nan".
>>>>> ---
>>>>>   newlib/libc/stdlib/gd_qnan.h | 8 ++++----
>>>>>   newlib/libc/stdlib/strtod.c  | 1 +
>>>>>   2 files changed, 5 insertions(+), 4 deletions(-)
>>>> [...]
>>> With your patch, strtold looks more correct, but it still prints the
>>> sign of NaN:
>>>
>>>    strtod ("nan", NULL) = nan
>>>    strtod ("-nan", NULL) = nan
>>>    strtold ("nan", NULL) = nan
>>>    strtold ("-nan", NULL) = -nan
>>>    nan ("") = nan
>>>
>>> Question: What's wrong with that?  Wouldn't it be more correct if
>>> strtod returns -NaN for "-nan" as well?
>> In my investigate,
>> strtold sets sign bit when parameter has '-' character.
>> The wrong long double NaN definition is negative NaN that is set sign bit.
>> So without my patch, both strtold ("nan") and
>> strtold ("-nan") return negative NaN.
>>
>> On the other hand, strtod inverts the sign when parameter has '-' character.
>> The wrong double NaN definition is negative NaN.
>> So without my patch, strtod ("nan") returns negative NaN
>> and strtod ("-nan") returns positive NaN.
> Your patch improves the situation, that's a sure thing and I did not
> question that.
>
> I just wonder why returning -NaN when the input is "-nan" isn't the
> better approach.  After all:
>
>    printf ("nan (\"\") = %f\n", nan (""));
>    printf ("-nan (\"\") = %f\n", -nan (""));
>
> ==>
>
>    nan ("") = nan
>    -nan ("") = -nan
>
> So, shouldn't the ideal outcome be this:
>
>    strtod ("nan", NULL) = nan
>    strtod ("-nan", NULL) = -nan
>    strtold ("nan", NULL) = nan
>    strtold ("-nan", NULL) = -nan
>
> ?
>
> Corinna
>
I'd say it is not the better/best approach as, even though it makes 
sense, all other implementations or linux distributions treat it as a 
plain "nan". So anything written for linux will potentially break on 
cygwin, I am not sure this is the idea behind cygwin, right?

Besides, it only adds complexity when checking for nans, if string 
comparison is relied upon, as an additional character may show up.

As NaN is essentially not a number, what is not a number can't be said 
as positive or negative. Then we get to a whole philosophical level. It 
can, but we can't guarantee a cow (which is not a number) can be seen 
with a "positive cow". A mood (which is not a number), can be seen as 
positive or negative. Yet it will depend on your concept of a positive 
or negative mood... so... well, better not leave the algebra sign to 
this. As 0 is equal to -0. Does -0 exist? :)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple