RE: [patch,complex] Replace hard-coded constants

["Howland Craig D (Craig)" <howland at LGSInnovations dot com>]

Ralf Corsepius wrote on Sunday, November 28, 2010 8:01 AM
>> --- Sab 27/11/10, Corinna Vinschen  ha scritto:
>>>> error.  SUSv4 does not indicate what values have to be returned
when a
>>>> math error occurs.
>>>Yes, unfortunately they are pretty vague.
>> Quite in contrast to the description of the real number functions.
>>  Just have a look into the "RETURN VALUE" section of the tan
functions
>> here:
http://www.opengroup.org/onlinepubs/9699919799/functions/tan.html
>> So why is that missing in the descriptions of the complex
>> functions?

Annex G of the C standard (ISO/IEC 9899), "IEC 60559-compatible complex
arithmetic," does specify return values for exceptional conditions.
Since Newlib nominally generally does support 60559 (better known as
IEEE 754), these are a good way to go.  And they are not vague.  (I
don't know why POSIX does not take a moment to mention them,  but given
their deferral to the C standard, POSIX implicitly requires them when
60559 is used.)

>>> Marco, since you added these functions, do you have a
>>> decided opinion?
>>
>> at first glance HUGE_VAL, HUGE_VALF, should be better,
>> bit I need to better check this problem.
>
>Provided what opengroup says about HUGE_VAL wrt. "tan" and when looking
>at this issue and implementation from a technical POV, I don't see much
>reasons for not using HUGE_VAL.
>
>It at least resolves the compilation/portability issues I am facing,
>without changing the general working principle of the code.
>
>Whether this is mathematically correct and technically 100% correct,
are
>different questions, which currently are not entirely clear to me.
>
>Please find enclosed a version of the patch, now using HUGE_VAL instead
>of MAXNUM.

From one of Corinna's questions at the end of last week, with a response
from Ralf:
>>  But wouldn't it make more sense to use nan/nanf, like glibc?
> I am inclined to agree.
 
I did not look at all of the details, but C Annex G does have some
cases where either or both parts can be returned as NAN for the 4
functions under consideration.  Updating to these returns at some time
would appear to be in order.  However, the present solution of HUGE_VAL
is certainly a good first step.

Craig