On futher contemplation, and hearing others' arguments, I'm changing my
vote. Make it compatible with python.
w
On Tue, 24 Apr 2007, Warren Focke wrote:
>
>
> On Tue, 24 Apr 2007, Timothy Hochberg wrote:
>
> > On 4/24/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> > >
> > > Christian Marquardt wr
On 4/24/07, Alan G Isaac <[EMAIL PROTECTED]> 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 inco
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 til
On Apr 23, 2007, at 21:35 , David M. Cooke wrote:
Python defines x // y as returning the floor of the division, and x
% y has the same sign as y. However, in C89, it is implementation-
defined (i.e., portability-pain-in-the-ass) whether the floor or
ceil is used when the signs of x and y di
>
> 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.
I'm supportive of follow
On Tue, 24 Apr 2007, Timothy Hochberg wrote:
> On 4/24/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> >
> > Christian Marquardt wrote:
>
>
>
> > > Restore the invariant, and follow python.
>
>
> This seems to imply that once upon a time numpy/numeric/numarray followed
> python here, but as far as
On Tue, April 24, 2007 23:31, Christian Marquardt wrote:
> On Tue, April 24, 2007 23:08, Robert Kern wrote:
>> Christian Marquardt wrote:
>>> Restore the invariant, and follow python.
>>>
>>> This
>>>
>>>>>> -5 // 6
>>>-1
>>>
>>> and
>>>
>>>>>> array([-5])[0] // 6
>>>0
>>>
>>> simpl
On 4/24/07, Robert Kern <[EMAIL PROTECTED]> wrote:
Christian Marquardt wrote:
> Restore the invariant, and follow python.
This seems to imply that once upon a time numpy/numeric/numarray followed
python here, but as far as I can recall that was never the case. Instead
they followed C com
On Tue, April 24, 2007 23:08, Robert Kern wrote:
> Christian Marquardt wrote:
>> Restore the invariant, and follow python.
>>
>> This
>>
>>>>> -5 // 6
>>-1
>>
>> and
>>
>>>>> array([-5])[0] // 6
>>0
>>
>> simply doesn't make sense - in any language, you would expect that
>> all basi
Christian Marquardt wrote:
> Restore the invariant, and follow python.
>
> This
>
>>>> -5 // 6
>-1
>
> and
>
>>>> array([-5])[0] // 6
>0
>
> simply doesn't make sense - in any language, you would expect that
> all basic operators provide you with the same same answer when
> app
Restore the invariant, and follow python.
This
>>> -5 // 6
-1
and
>>> array([-5])[0] // 6
0
simply doesn't make sense - in any language, you would expect that
all basic operators provide you with the same same answer when
applied to the same number, no?
Christian.
On Tue, Apri
Do restore the invariant.
Behave completely like Python if not too costly,
otherwise follow C89.
A user's view,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Apr 23, 2007, at 22:04 , Warren Focke wrote:
But even C89 required that x == (x/y)*y + (x%y), and that's not the
case
here.
Missed that. You're right. We pull the same trick Python does with %
so that the sign of x % y agrees with the sign of y, but we don't
follow Python in guarantee
But even C89 required that x == (x/y)*y + (x%y), and that's not the case
here.
w
On Mon, 23 Apr 2007, David M. Cooke wrote:
> On Apr 23, 2007, at 16:41 , Christian Marquardt wrote:
> > On Mon, April 23, 2007 22:29, Christian Marquardt wrote:
> >> Actually,
> >>
> >> it happens for normal integer
On Apr 23, 2007, at 16:41 , Christian Marquardt wrote:
On Mon, April 23, 2007 22:29, Christian Marquardt wrote:
Actually,
it happens for normal integers as well:
n = np.array([-5, -100, -150])
n // 100
array([ 0, -1, -1])
-5//100, -100//100, -150//100
(-1, -1, -2)
and finally:
n
Hmmm,
On Mon, April 23, 2007 22:29, Christian Marquardt wrote:
> Actually,
>
> it happens for normal integers as well:
>
>>>> n = np.array([-5, -100, -150])
>>>> n // 100
>array([ 0, -1, -1])
>>>> -5//100, -100//100, -150//100
>(-1, -1, -2)
and finally:
>>> n % 100
arra
Actually,
it happens for normal integers as well:
>>> n = np.array([-5, -100, -150])
>>> n // 100
array([ 0, -1, -1])
>>> -5//100, -100//100, -150//100
(-1, -1, -2)
On Mon, April 23, 2007 22:20, Christian Marquardt wrote:
> Dear all,
>
> this is odd:
>
>>>> import numpy as np
Dear all,
this is odd:
>>> import numpy as np
>>> fact = 2825L * 86400L
>>> nn = np.array([-20905000L])
>>> nn
array([-20905000], dtype=int64)
>>> nn[0] // fact
0
But:
>>> long(nn[0]) // fact
-1L
Is this a bug in numpy, or in python's implementation of longs? I w
18 matches
Mail list logo
