[patch,complex] Replace hard-coded constants

[Ralf Corsepius]

On 11/27/2010 05:35 PM, Marco Atzeri wrote:
> --- Sab 27/11/10, Corinna Vinschen  ha scritto:
>
>> Data: Sabato 27 novembre 2010, 14:56
>> On Nov 26 14:18, Ralf Corsepius
>> wrote:
>>> On 11/26/2010 11:19 AM, Corinna Vinschen wrote:
>>>> On Nov 26 09:08, Ralf Corsepius wrote:
>>>>> Hi,
>>>>>
>>>>> The functions in ctan.c, ctanf.c, catan.c and
>> catanf.c apply
>>>>> hard-coded constants which are out of range
>> (i.e. they cause
>>>>> compilation warnings and likely will cause
>> run-time failures) on
>>>>> some (e.g. 16bit) targets and likely are
>> incorrect on all targets.
>>>>
>>>> Indeed, these values are potentially incorrect for
>> some targets.
>>>> However, they are used on BSD this way.
>>>>
>>>>> The patch below tries to replace these
>> hard-coded constants with
>>>>> [FLT|DBL_MAX] from<float.h>, when these
>> defines are available and
>>>>> tries to fall back to the original constants
>> if these are not
>>>>> available.
>>>>>
>>>>> Ralf
>>>>>
>>>>> PS.: IMO, due to the fact<float.h>
>> and [FLT|DBL]_MAX are POSIX and
>>>>> thus should be available in any current
>> compiler, it's likely safe
>>>>> to completely remove the hard-coded constants
>> and to directly use
>>>>> [FLT|DBL]_MAX.

>> 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>

>> Are there any mathematicians here who would like to provide
>> their
>> point of view to this problem?
[...]

>> 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.

Ralf
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: newlib-complex.diff
URL: <http://sourceware.org/pipermail/newlib/attachments/20101129/adc38563/attachment.ksh>