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

Attachment: newlib-complex.diff
Description: Text document


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