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

[Marco Atzeri <marco_atzeri at yahoo dot it>]

--- 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.
> > >
> > >MAXNUM{F} is only used to construct the return
> value in case of an
> > >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>
> 
> > >AFAICS, glibc returns NAN values in real and/or
> > >imaginary part of the number, depending on the
> problem.
> > >
> > >So, for a start I agree that we should drop
> MAXNUM/MAXNUMF in favor of
> > >using DBL_MAX/FLT_MAX.
> > 
> > Fine with me.
> 
> Maybe we should rather use HUGE_VAL instead, just like the
> XSI option
> to the tan function suggests for the overflow case.
> 
> > > But wouldn't it make more sense to use nan/nanf,
> > >like glibc?
> > I am inclined to agree.
> 
> 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.

> 
> 
> Corinna
> 

Marco