[Numpy-discussion] (no subject)

[Ian Henriksen]

On Thu, Sep 18, 2014 at 1:30 PM, Jonathan Helmus <jjhelmus at gmail.com> wrote:

> 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
> 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

Agreed. It's definitely best to follow the IEEE conventions. That will be
the most commonly expected behavior, especially in ambiguous cases like
this.
-Ian Henriksen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140918/9298eac5/attachment.html>