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 -
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4