[patch,complex] Replace hard-coded constants
Howland Craig D (Craig)
Tue Nov 30 05:09:00 GMT 2010
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
>>>> 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
>> So why is that missing in the descriptions of the complex
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,
>different questions, which currently are not entirely clear to me.
>Please find enclosed a version of the patch, now using HUGE_VAL instead
From one of Corinna's questions at the end of last week, with a response
>> 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.
More information about the Newlib