[Numpy-discussion] What type should / return in python 3k when applied to two integer types?

[josef.pktd at gmail.com]

On Fri, Aug 28, 2009 at 12:46 PM, Charles R
Harris<charlesr.harris at gmail.com> wrote:
>
>
> On Fri, Aug 28, 2009 at 8:08 AM, <josef.pktd at gmail.com> wrote:
>>
>> On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanen<pav at iki.fi> wrote:
>> > Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
>> >
>> >> Robert Kern wrote:
>> >>
>> >>> On Thu, Aug 27, 2009 at 14:22, Christopher
>> >>> Barker<Chris.Barker at noaa.gov> wrote:
>> >>>
>> >>>> By the way -- is there something about py3k that changes all this? Or
>> >>>> is this just an opportunity to perhaps make some
>> >>>> backward-incompatible
>> >>>> changes to numpy?
>> >>>
>> >>> Python 3 makes the promised change of int/int => float.
>> >>
>> >> Does that mean that we want numpy to do the same?  I'm not so sure.
>> >> Sounds like opening a can of worms (numpy has more types to worry about
>> >> than just int and float.  If we start playing strange games we may
>> >> regret it.)
>> >
>> > I believe we want to. This is not really a strange trick: it's just that
>> > in Python 3, the operator / is true_division, and // is floor_division.
>> > I believe any worms released by this are mostly small and tasty...
>> >
>> > The main issue is probably just choosing an appropriate float return
>> > type, and personally I believe this should be same as numpy's default
>> > float.
>>
>> and getting the infs and nans as in true float division not as in
>> np.true_divide
>
> Note that currently true_divide returns zeros in these cases and attempts --
> unsuccessfully -- to raise a zero division error; that is what python does.
> So if we make this change there will be a divergence from python behaviour.
> However, arrays are different from scalars and I think we should make this
> change.

The difference is already now in the floating point operations.

Since python doesn't know about inf and nans, I was switching
functions to use the numpy version for floating point operations to
have robust results instead of exceptions (in stats.distributions)

>>> 0.**(-1)
Traceback (most recent call last):
  File "<pyshell#17>", line 1, in <module>
    0.**(-1)
ZeroDivisionError: 0.0 cannot be raised to a negative power

>>> np.power(0., -1)
inf
>>> np.array(0.)**(-1)
inf

and I would expect that a numpy "/" follows the numpy floating point
definitions ( and not the missing inf and nan behavior of python)

Josef



>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>