[Python-Dev] HUGE_VAL and INFINITY

[Tim Peters]

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

> But as this whole area is a great can of worms I'd like someone with
> more knowledge of C standards and floating point and such to ponder it,
> please.

Let's look at the code:

"""
/* According to
 * http://www.cray.com/swpubs/manuals/SN-2194_2.0/html-SN-2194_2.0/x3138.htm
 * on some Cray systems HUGE_VAL is incorrectly (according to the C std)
 * defined to be the largest positive finite rather than infinity.  We
 * need the std-conforming infinity meaning (provided the platform has
 * one!).
 *
 * Then, according to a bug report on SourceForge, defining Py_HUGE_VAL as
 * INFINITY caused internal compiler errors under BeOS using some version
 * of gcc.  Explicitly casting INFINITY to double made that problem go
 * away.
 */
#ifdef INFINITY
#define Py_HUGE_VAL ((double)INFINITY)
#else
#define Py_HUGE_VAL HUGE_VAL
#endif
"""

> If both INFINITY and HUGE_VAL are defined then INFINITY takes
> precedence.

Right, and the comment explains why (a broken Cray system).

> However, all references I've seen to INFINITY seem to indicate that
> this is a float value, not a double value, according to the C99 standard.

It is a float value, but is explicitly cast to double in the above.

> And I've now come across a platform where HUGE_VAL==1e500 and
> INFINITY==HUGE_VALF==1e50, and these latter values are not infinite for
> doubles (I assume they are infinite for floats, but I haven't checked).

The platform's header files are braindead.  That doesn't mean we shouldn't
try to survive despite them, but you should file a bug report with whoever
supplies this C.  If (double)INFINITY isn't a double-precision infinity,
their definition of INFINITY is hosed (the C89 std doesn't say anything
useful about this, it's a matter of respecting the spirit of IEEE-754 and
that C didn't bother to define a double-precision version of the INFINITY
macro -- that means a *useful* float INFINITY has to be defined in such a
way that it can do double-duty).

> 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.  Why are you keeping "the fix"
secret?  At this point, I'd be happy to drop the hack-around for the broken
Cray, and reduce the whole mess to:

#ifndef Py_HUGE_VAL
#define Py_HUGE_VAL HUGE_VAL
#endif

Then someone on a broken box can #define their own Py_HUGE_VAL in their own
stinkin' config file.