On 6/20/2016 5:59 PM, Nathaniel Smith wrote:
If you have the time to check for existing bug reports about this, and
file a new bug if you don't find one, then it'd be appreciated.
https://github.com/numpy/numpy/issues/7770
Alan
___
NumPy-Discussion
On Mo, 2016-06-20 at 15:15 -0700, Nathaniel Smith wrote:
> On Mon, Jun 20, 2016 at 3:09 PM, wrote:
> >
> > On Mon, Jun 20, 2016 at 4:31 PM, Alan Isaac
> > wrote:
> > >
> > > On 6/13/2016 1:54 PM, Marten van Kerkwijk wrote:
> > > >
> > > >
> > > > 1. What in principle is the best return type
On Mon, Jun 20, 2016 at 3:09 PM, wrote:
> On Mon, Jun 20, 2016 at 4:31 PM, Alan Isaac wrote:
>> On 6/13/2016 1:54 PM, Marten van Kerkwijk wrote:
>>>
>>> 1. What in principle is the best return type for int ** int (which
>>> Josef I think most properly rephrased as whether `**` should be
>>> thou
On Mon, Jun 20, 2016 at 4:31 PM, Alan Isaac wrote:
> On 6/13/2016 1:54 PM, Marten van Kerkwijk wrote:
>>
>> 1. What in principle is the best return type for int ** int (which
>> Josef I think most properly rephrased as whether `**` should be
>> thought of as a float operator, like `/` in python3 a
On Mon, Jun 20, 2016 at 2:11 PM, Alan Isaac wrote:
> On 6/10/2016 8:28 PM, Allan Haldane wrote:
>>
>> My understanding is that numpy never upcasts based on the values, it
>> upcasts based on the datatype ranges.
>>
>> http://docs.scipy.org/doc/numpy-1.10.1/reference/ufuncs.html#casting-rules
>
>
>
On 6/10/2016 8:28 PM, Allan Haldane wrote:
My understanding is that numpy never upcasts based on the values, it
upcasts based on the datatype ranges.
http://docs.scipy.org/doc/numpy-1.10.1/reference/ufuncs.html#casting-rules
>>> (np.int64(2**6)*np.arange(5,dtype=np.int8)).dtype
dtype('int8')
On 6/13/2016 1:54 PM, Marten van Kerkwijk wrote:
1. What in principle is the best return type for int ** int (which
Josef I think most properly rephrased as whether `**` should be
thought of as a float operator, like `/` in python3 and `sqrt` etc.);
Perhaps the question is somewhat different.
On Jun 13, 2016 10:54 AM, "Marten van Kerkwijk"
wrote:
>
> Hi All,
>
> I think we're getting a little off the rails, perhaps because two
questions are being conflated:
>
> 1. What in principle is the best return type for int ** int (which Josef
I think most properly rephrased as whether `**` shou
Hi All,
I think we're getting a little off the rails, perhaps because two
questions are being conflated:
1. What in principle is the best return type for int ** int (which Josef I
think most properly rephrased as whether `**` should be thought of as a
float operator, like `/` in python3 and `sqr
On 06/13/2016 05:05 AM, V. Armando Solé wrote:
> On 11/06/2016 02:28, Allan Haldane wrote:
>>
>> So as an extra twist in this discussion, this means numpy actually
>> *does* return a float value for an integer power in a few cases:
>>
>> >>> type( np.uint64(2) ** np.int8(3) )
>> numpy.flo
On Mon, Jun 13, 2016 at 12:07 PM, wrote:
>
>
> On Mon, Jun 13, 2016 at 11:51 AM, wrote:
>
>>
>>
>> On Mon, Jun 13, 2016 at 11:25 AM, Antoine Pitrou
>> wrote:
>>
>>> On Mon, 13 Jun 2016 10:49:44 -0400
>>> josef.p...@gmail.com wrote:
>>> >
>>> > My argument is that `**` is like integer division a
On Mon, Jun 13, 2016 at 11:51 AM, wrote:
>
>
> On Mon, Jun 13, 2016 at 11:25 AM, Antoine Pitrou
> wrote:
>
>> On Mon, 13 Jun 2016 10:49:44 -0400
>> josef.p...@gmail.com wrote:
>> >
>> > My argument is that `**` is like integer division and sqrt where the
>> domain
>> > where integer return are t
On Mon, Jun 13, 2016 at 11:25 AM, Antoine Pitrou
wrote:
> On Mon, 13 Jun 2016 10:49:44 -0400
> josef.p...@gmail.com wrote:
> >
> > My argument is that `**` is like integer division and sqrt where the
> domain
> > where integer return are the correct numbers is too small to avoid
> > headaches by
On Mon, 13 Jun 2016 10:49:44 -0400
josef.p...@gmail.com wrote:
>
> My argument is that `**` is like integer division and sqrt where the domain
> where integer return are the correct numbers is too small to avoid
> headaches by users.
float64 has less integer precision than int64:
>>> math.pow(3,
On Mon, Jun 13, 2016 at 10:05 AM, Alan Isaac wrote:
> On 6/13/2016 4:47 AM, Antoine Pitrou wrote:
>
>> Currently, the choice is simple: if you want an int output,
>> have an int input; if you want a float output, have a float output.
>>
>
>
> That is a misunderstanding, which may be influencing t
On Mon, 13 Jun 2016 10:05:08 -0400
Alan Isaac wrote:
>
> That is a misunderstanding, which may be influencing the discussion.
> Examples of complications:
>
> >>> type(np.int8(2)**2)
>
> >>> type(np.uint64(2)**np.int8(2))
>
The `uint64 x int8 -> float64` is IMHO an abberration in Numpy's
ty
On 6/13/2016 4:47 AM, Antoine Pitrou wrote:
Currently, the choice is simple: if you want an int output,
have an int input; if you want a float output, have a float output.
That is a misunderstanding, which may be influencing the discussion.
Examples of complications:
>>> type(np.int8(2)**2)
On 11/06/2016 02:28, Allan Haldane wrote:
So as an extra twist in this discussion, this means numpy actually
*does* return a float value for an integer power in a few cases:
>>> type( np.uint64(2) ** np.int8(3) )
numpy.float64
Shouldn't that example end up the discussion? I find th
On Fri, 10 Jun 2016 20:28:30 -0400
Allan Haldane wrote:
>
> Also, I like to think of numpy as having quite C-like behavior, allowing
> you to play with the lowlevel bits and bytes. (I actually wish its
> casting behavior was more C-like). I suspect that people working with
> uint8 arrays might be
On Fr, 2016-06-10 at 20:16 +, Ian Henriksen wrote:
> On Fri, Jun 10, 2016 at 12:01 PM Nathaniel Smith
> wrote:
> > On Jun 10, 2016 10:50, "Alan Isaac" wrote:
> > >
> > > On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
> > >>
> > >> You keep pounding on this example. It's a fine example, but,
> >
I do think one of the main arguments for returning float remains the
analogy with division. I don't know about the rest of you, but it has been
such a relief not to have to tell students any more "you should add a ".",
otherwise it does integer division". For most purposes, it simply shouldn't
matt
On 06/10/2016 03:38 PM, Alan Isaac wrote:
np.find_common_type([np.int8],[np.int32])
> dtype('int8')
(np.arange(10,dtype=np.int8)+np.int32(2**10)).dtype
> dtype('int16')
>
> And so on. If these other binary operators upcast based
> on the scalar value, why wouldn't exponentiation?
> I su
On Fri, Jun 10, 2016 at 12:01 PM Nathaniel Smith wrote:
> On Jun 10, 2016 10:50, "Alan Isaac" wrote:
> >
> > On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
> >>
> >> You keep pounding on this example. It's a fine example, but, c'mon. **2
> is probably at least 100x more common in real source code.
On 06/10/2016 01:50 PM, Alan Isaac wrote:
> Again, **almost all** integer combinations overflow: that's the point.
Don't almost all integer combinations overflow for multiplication as well?
I estimate that for unsigned 32 bit integers, only roughly 1 in 2e8
combinations don't overflow.
The fract
I guess I have one more question; sorry.
Suppose we stipulate that `np.int_(9)**np.int__(10)` should
just overflow, since that appears to be the clear intent of
the (informed) user.
When a Python 3 user writes `np.arange(10)**10`,
how are we to infer the intended type of the output?
(I specify P
On Fri, Jun 10, 2016 at 2:00 PM, Nathaniel Smith wrote:
> On Jun 10, 2016 10:50, "Alan Isaac" wrote:
> >
> > On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
> >>
> >> You keep pounding on this example. It's a fine example, but, c'mon. **2
> is probably at least 100x more common in real source code.
On Jun 10, 2016 10:50, "Alan Isaac" wrote:
>
> On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
>>
>> You keep pounding on this example. It's a fine example, but, c'mon. **2
is probably at least 100x more common in real source code. Maybe 1000x more
common. Why should we break the
>> common case for y
On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
You keep pounding on this example. It's a fine example, but, c'mon. **2 is
probably at least 100x more common in real source code. Maybe 1000x more
common. Why should we break the
common case for your edge case?
It is hardly an "edge case".
Again,
On 6/10/2016 1:20 PM, Allan Haldane wrote:
numpy users have to be aware of
overflow issues in lots of other (simple) cases anyway, eg plain
addition and multiplication.
This is not comparable because *almost all* integer combinations
overflow for exponentiation. See the discussion at
https://
On Jun 10, 2016 05:11, "Alan Isaac" wrote:
>
> On 6/10/2016 2:42 AM, Nathaniel Smith wrote:
>>
>> I dunno, with my user hat on I'd be incredibly surprised / confused /
>> annoyed if an innocent-looking expression like
>>
>> np.arange(10) ** 2
>>
>> started returning floats... having exact ints i
On 6/10/2016 1:20 PM, Ian Henriksen wrote:
forcing float output for people who actually want integers is not at all ideal
Yes, there definitely should be a function supporting this.
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On Fri, Jun 10, 2016 at 12:42 AM Nathaniel Smith wrote:
> On Mon, Jun 6, 2016 at 1:17 PM, Charles R Harris
> wrote:
> >
> >
> >
> > On Mon, Jun 6, 2016 at 2:11 PM, Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
> >>
> >> Hi Chuck,
> >>
> >> I consider either proposal an improvement, b
On 06/10/2016 08:10 AM, Alan Isaac wrote:
> Is np.arange(10)**10 also "innocent looking" to a Python user?
This doesn't bother me much because numpy users have to be aware of
overflow issues in lots of other (simple) cases anyway, eg plain
addition and multiplication.
I'll add my +1 for integer p
From: Alan Isaac
Reply: Discussion of Numerical Python
Date: 10 June 2016 at 5:10:57 AM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Integers to integer powers, let's make a
decision
On 6/10/2016 2:42 AM, Nathaniel Smith wrote:
>
> I dunno, with my us
On 6/10/2016 2:42 AM, Nathaniel Smith wrote:
I dunno, with my user hat on I'd be incredibly surprised / confused /
annoyed if an innocent-looking expression like
np.arange(10) ** 2
started returning floats... having exact ints is a really nice feature
of Python/numpy as compared to R/Javascri
On Fri, Jun 10, 2016 at 7:42 AM, Nathaniel Smith wrote:
> On Mon, Jun 6, 2016 at 1:17 PM, Charles R Harris
> wrote:
>>
>> ...
>>
>> It looks to me like users want floats, while developers want the
>> easy path of raising an error. Darn those users, they just make
>> life sooo difficult...
>
> I d
On Mon, Jun 6, 2016 at 1:17 PM, Charles R Harris
wrote:
>
>
>
> On Mon, Jun 6, 2016 at 2:11 PM, Marten van Kerkwijk
> wrote:
>>
>> Hi Chuck,
>>
>> I consider either proposal an improvement, but among the two I favour
>> returning float for `**`, because, like for `/`, it ensures one gets closes
On Mon, Jun 6, 2016 at 2:11 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Chuck,
>
> I consider either proposal an improvement, but among the two I favour
> returning float for `**`, because, like for `/`, it ensures one gets
> closest to the (mathematically) true answer in most
Hi Chuck,
I consider either proposal an improvement, but among the two I favour
returning float for `**`, because, like for `/`, it ensures one gets
closest to the (mathematically) true answer in most cases, and makes
duck-typing that much easier -- I'd like to be able to do x** y without
having t
Charles R Harris wrote:
>1. Integers to negative integer powers raise an error.
>2. Integers to integer powers always results in floats.
2
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/num
On 6/4/2016 10:23 PM, Charles R Harris wrote:
From my point of view, backwards compatibility is the main reason for
choosing 1, otherwise I'd pick 2. If it weren't so easy to get
floating point by using floating exponents I'd probably choose
differently.
As an interested user, I offer a summary
On Sat, Jun 4, 2016 at 9:26 PM, Nathaniel Smith wrote:
> On Jun 4, 2016 7:23 PM, "Charles R Harris"
> wrote:
> >
> [...]
> > We could always try the float option and see what breaks, but I expect
> there is a fair amount of code using small exponents like 2 or 3 where it
> is expected that the r
On Jun 4, 2016 7:23 PM, "Charles R Harris"
wrote:
>
[...]
> We could always try the float option and see what breaks, but I expect
there is a fair amount of code using small exponents like 2 or 3 where it
is expected that the result is still integer. I would like more input from
users than we have
On Sat, Jun 4, 2016 at 7:54 PM, wrote:
>
>
> On Sat, Jun 4, 2016 at 9:16 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Sat, Jun 4, 2016 at 6:17 PM, wrote:
>>
>>>
>>>
>>> On Sat, Jun 4, 2016 at 8:07 PM, Charles R Harris <
>>> charlesr.har...@gmail.com> wrote:
>>>
>
On Sat, Jun 4, 2016 at 9:16 PM, Charles R Harris
wrote:
>
>
> On Sat, Jun 4, 2016 at 6:17 PM, wrote:
>
>>
>>
>> On Sat, Jun 4, 2016 at 8:07 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Jun 4, 2016 at 5:27 PM, wrote:
>>>
On Sat, Jun 4, 2016 at
On Sat, Jun 4, 2016 at 6:17 PM, wrote:
>
>
> On Sat, Jun 4, 2016 at 8:07 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Sat, Jun 4, 2016 at 5:27 PM, wrote:
>>
>>>
>>>
>>> On Sat, Jun 4, 2016 at 6:10 PM, Nathaniel Smith wrote:
>>>
On Sat, Jun 4, 2016 at 2:07 PM, V.
On Sat, Jun 4, 2016 at 8:07 PM, Charles R Harris
wrote:
>
>
> On Sat, Jun 4, 2016 at 5:27 PM, wrote:
>
>>
>>
>> On Sat, Jun 4, 2016 at 6:10 PM, Nathaniel Smith wrote:
>>
>>> On Sat, Jun 4, 2016 at 2:07 PM, V. Armando Sole wrote:
>>> > Also in favor of 2. Always return a float for '**'
>>>
>>>
On Sat, Jun 4, 2016 at 5:27 PM, wrote:
>
>
> On Sat, Jun 4, 2016 at 6:10 PM, Nathaniel Smith wrote:
>
>> On Sat, Jun 4, 2016 at 2:07 PM, V. Armando Sole wrote:
>> > Also in favor of 2. Always return a float for '**'
>>
>> Even if we did want to switch to this, it's such a major
>> backwards-inc
On Sat, Jun 4, 2016 at 6:10 PM, Nathaniel Smith wrote:
> On Sat, Jun 4, 2016 at 2:07 PM, V. Armando Sole wrote:
> > Also in favor of 2. Always return a float for '**'
>
> Even if we did want to switch to this, it's such a major
> backwards-incompatible change that I'm not sure how we could actua
On Sat, Jun 4, 2016 at 2:07 PM, V. Armando Sole wrote:
> Also in favor of 2. Always return a float for '**'
Even if we did want to switch to this, it's such a major
backwards-incompatible change that I'm not sure how we could actually
make the transition without first making it an error for a whi
Also in favor of 2. Always return a float for '**'
On 04.06.2016 21:47, josef.p...@gmail.com wrote:
On Sat, Jun 4, 2016 at 3:43 PM, Charles R Harris
wrote:
On Sat, Jun 4, 2016 at 11:22 AM, Charles R Harris
wrote:
Hi All,
I've made a new post so that we can make an explicit decision.
AFAIC
>
> +1
>
> On Sat, Jun 4, 2016 at 10:22 AM, Charles R Harris
> wrote:
>> Hi All,
>>
>> I've made a new post so that we can make an explicit decision. AFAICT, the
>> two proposals are
>>
>> Integers to negative integer powers raise an error.
>> Integers to integer powers always results in floats.
>
On Sat, Jun 4, 2016 at 3:49 PM, Matthew Brett
wrote:
> On Sat, Jun 4, 2016 at 12:47 PM, wrote:
> >
> >
> > On Sat, Jun 4, 2016 at 3:43 PM, Charles R Harris <
> charlesr.har...@gmail.com>
> > wrote:
> >>
> >>
> >>
> >> On Sat, Jun 4, 2016 at 11:22 AM, Charles R Harris
> >> wrote:
> >>>
> >>> Hi
On Sat, Jun 4, 2016 at 12:47 PM, wrote:
>
>
> On Sat, Jun 4, 2016 at 3:43 PM, Charles R Harris
> wrote:
>>
>>
>>
>> On Sat, Jun 4, 2016 at 11:22 AM, Charles R Harris
>> wrote:
>>>
>>> Hi All,
>>>
>>> I've made a new post so that we can make an explicit decision. AFAICT,
>>> the two proposals ar
On Sat, Jun 4, 2016 at 3:43 PM, Charles R Harris
wrote:
>
>
> On Sat, Jun 4, 2016 at 11:22 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> I've made a new post so that we can make an explicit decision. AFAICT,
>> the two proposals are
>>
>>
>>1. Integers to negat
On Sat, Jun 4, 2016 at 11:22 AM, Charles R Harris wrote:
> Hi All,
>
> I've made a new post so that we can make an explicit decision. AFAICT, the
> two proposals are
>
>
>1. Integers to negative integer powers raise an error.
>2. Integers to integer powers always results in floats.
>
> My
On Sat, Jun 4, 2016 at 10:45 AM, Nathaniel Smith wrote:
> +1
>
> On Sat, Jun 4, 2016 at 10:22 AM, Charles R Harris
> wrote:
>> Hi All,
>>
>> I've made a new post so that we can make an explicit decision. AFAICT, the
>> two proposals are
>>
>> Integers to negative integer powers raise an error.
>>
+1
On Sat, Jun 4, 2016 at 10:22 AM, Charles R Harris
wrote:
> Hi All,
>
> I've made a new post so that we can make an explicit decision. AFAICT, the
> two proposals are
>
> Integers to negative integer powers raise an error.
> Integers to integer powers always results in floats.
>
> My own sense
Hi All,
I've made a new post so that we can make an explicit decision. AFAICT, the
two proposals are
1. Integers to negative integer powers raise an error.
2. Integers to integer powers always results in floats.
My own sense is that 1. would be closest to current behavior and using a
floa
59 matches
Mail list logo
