[Python-Dev] HUGE_VAL and INFINITY
Jack Jansen
Jack.Jansen@oratrix.com
Tue, 2 Jul 2002 22:32:33 +0200
On dinsdag, juli 2, 2002, at 05:28 , Tim Peters wrote:
> [Jack Jansen]
>> I think there is a problem with the way pyport.h treats HUGE_VAL and
>> INFINITY.
>
> I'm afraid there are necessarily problems there, since this stuff is
> insufficiently standardized.
I found a couple of references to INFINITY being a float. Here's
one (no idea as to it's status, though, that's why I asked for
help of a standards guru):
http://www.opengroup.org/onlinepubs/007904975/basedefs/math.h.html
(googling for "INFINITY math.h" will find many more).
> #define Py_HUGE_VAL ((double)INFINITY)
Is the intention of this define that it would first convert the
constant "1e50" to an IEEE float "Infinity", and that this float
would then be promoted to a double "Infinity"? If it is indeed
stated somewhere in the C standard that this is the course of
action to take then the compiler is wrong, because what it
actually seems to be doing is parsing the "1e50" as a double
because of the cast (speculating here, but this is consistent
with the results).
If you happen to have a reference then I can post a bug report.
>> I have a patch that will fix this problem for my specific case, but I
>> have the feeling that it may be the pyport.h logic that is at fault
>> here. If no-one jumps in I'll commit my fix in a few days time.
>
> Don't check in a change here without review.
The patch is a simple
#ifdef __APPLE__
#undef INFINITY
#endif
I'll post a sourceforge bug tomorrow and assign it to you. Feel
free to completely ignore it and do the config magic to handle
the Cray case specially, though.
--
- Jack Jansen <Jack.Jansen@oratrix.com>
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution --
Emma Goldman -