This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]