[Numpy-discussion] Oddity with numpy.int64 integer division

[Timothy Hochberg]

On 4/24/07, Alan G Isaac <aisaac at american.edu> wrote:
>
> On Tue, 24 Apr 2007, Timothy Hochberg apparently wrote:
> > Personally I'd opt for completely following Python here,
> > with the C-like integer division and mod operators
> > available as appropriately named ufuncs somewhere. It's
> > a backwards incompatible change though, so it'd have to
> > wait till at least a minor realease.
>
> This is one of those places where looking forward appears to
> produce a different suggestion than looking backward.
>
> That is, looking backward, we emphasize compatability with
> extant code.  Looking forward we put more weight on removing
> "gotcha" features from numpy, with an eye on an expanding
> user base.
>
> In my opinion, opting to maintain backward compatability
> here is opting to retain a "gotcha".  I hope Tim's
> suggestion is realized, and that backward compatability is
> again enabled through the compatability module.  I'm happy
> that Travis appears amenable to this.


 Let me add that there are some factors that make this more compelling
looking forward than it did in the past. The root of these is the changing
meaning of "/" and the introduction of floor division "//". Eventually, the
integer division meaning of "/" will go away and the result of "a / b" is
always going to be a float or complex. You can get that behaviour now by
using "from __future__ import division". Therefore, the interesing behaviour
is what does '"//" do. SInce "//" is pronounced "floor division" it pretty
much has to round towards negative infinity if we are to avoid massive
confusion.  If we support this, as I believe we eventually must, then this
results in following python practice for '%' as well in order to maintain
our invariant.

I worry less about speed here than I used to since my experience is that
moving bits around is more often a bottleneck than the FPU and this doesn't
move any extra bits. Also, we should provide ufuncs (c_int_divide and
c_int_mod or some such) for those that are need the speed and know that
truncation to zero isn't going to bite them.



-- 

//=][=\\

tim.hochberg at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20070425/3a16dd94/attachment.html>