[Numpy-discussion] (no subject)

Jonathan Helmus jjhelmus at gmail.com
Thu Sep 18 15:30:33 EDT 2014

On 09/18/2014 12:44 PM, Petr Viktorin wrote:
> On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus <jjhelmus at gmail.com> wrote:
>> On 09/18/2014 12:01 PM, Chris Barker wrote:
>> Well,
>> First of all, numpy and the python math module have a number of differences
>> when it comes to handling these kind of special cases -- and I think that:
>> 1) numpy needs to do what makes the most sense for numpy and NOT mirror the
>> math lib.
> Sure.
>> 2) the use-cases of the math lib and numpy are different, so they maybe
>> _should_ have different handling of this kind of thing.
> If you have a reason for the difference, I'd like to hear it.
>> 3) I'm not sure that the core devs think these kinds of issues are "wrong"
>> 'enough to break backward compatibility in subtle ways.
> I'd be perfectly fine with it being documented and tested (in CPython)
> as either a design mistake or design choice.
>> But it's a fun topic in any case, and maybe numpy's behavior could be
>> improved.
>>> My vote is that NumPy is correct here. I see no reason why
>>>>>> float('inf') / 1
>>> and
>>>>>> float('inf') // 1
>>> should return different results.
>> Well, one argument is that "floor division" is supposed to return an integer
>> value, and that inf is NOT an integer value. The integral part of infinity
>> doesn't exist and thus is Not a Number.
>> But nan is not an integer value either:
>>>>> float('inf') // 1
>> nan
>>>>> int(float('inf') // 1)
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in <module>
>> ValueError: cannot convert float NaN to integer
>> Perhaps float('inf') // 1 should raise a ValueError directly since there is
>> no proper way perform the floor division on infinity.
> inf not even a *real* number; a lot of operations don't make
> mathematical sense on it. But most are defined anyway, and quite
> sanely.

But in IEEE-754 inf is a valid floating point number (where-as NaN is 
not) and has well defined arithmetic, specifically inf / 1 == inf and 
RoundToIntergral(inf) == inf.  In the numpy example, the 
numpy.array(float('inf')) statement creates an array containing a 
float32 or float64 representation of inf.  After this I would expect a 
floor division to return inf since that is what IEEE-754 arithmetic 

For me the question is if the floor division should also perform a cast 
to an integer type. Since inf cannot be represented in most common 
integer formats this should raise an exception.  Since // does not 
normally perform a cast, for example type(float(5) // 2) == float, the 
point is mute.

The real question is if Python floats follows IEEE-754 arithmetic or 
not.  If they do not what standard are they going to follow?

     - Jonathan Helmus

More information about the NumPy-Discussion mailing list