On 09/18/2014 12:44 PM, Petr Viktorin wrote:
> On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus <jjhel...@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
specifies.
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
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
