Why `divmod(float('inf'), 1) == (float('nan'), float('nan'))`

wxjmfauth at gmail.com wxjmfauth at gmail.com
Fri Sep 19 02:48:04 EDT 2014


Le jeudi 18 septembre 2014 18:36:03 UTC+2, chris.... at noaa.gov a écrit :
> On Wednesday, September 17, 2014 11:22:42 PM UTC-7, wxjm... at gmail.com wrote:
>> > >>> 1e300*1e300
>> > 
>> > inf
>> > 
>> > >>> exp(1e300)
>> > 
>> > Traceback (most recent call last):
>> > 
>> > File "<eta last command>", line 1, in <module>
>> > 
>> > OverflowError: math range error
>>>> FWIW, numpy is a bit more consistent:
>>>> In [89]: numpy.exp(1e300)
>> Out[89]: inf
>>>> This is more critical in numpy, because that result may have been one of a big huge array of values -- you really don't want the entire array operation to raise and Exception because of one odd value.
>>>> It's be nice if Python's math module did more than simply wrap the default i implementation of the underlying C lib -- it's gotten better over the years (Inf and NaN used to be really hard to get), but still not quite what it could be.
>Silly argument. One single "inf" may be enough to
not pursuit any further calculations. So the only
way is to always test if one get "valid" values (values
which have a "sense")-
Example:
2-dimensional Fourier transormation. If the transformation
of the first raw (columns) return one single such value,
it's not worth to continue to calculate in "vacuum".
As I already said, this "not finite arithmetic" may
look very appealing, in many cases, it is an annoying
double sword.
Note: I wrote "Numerical Recipes" in Python. This kind
of problem is particulary accute in "linear algebra".
jmf
PS math.isinf() --> has_array_inf() ?!


More information about the Python-list mailing list

AltStyle によって変換されたページ (->オリジナル) /