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:
> > > >
> > > >
> > > >
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
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
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.
>>
>>
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
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
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
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) )
>>
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
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
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
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:
>>>
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,
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
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
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
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
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
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
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
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
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
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
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
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".
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
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
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,
> >>
> >>
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
n@scipy.org>
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 user hat on I'd be incredibly surprised / confused /
> annoyed if an innocent-looking expression like
>
> np.arange(10
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
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
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
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
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
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
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
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
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
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 <
>>>
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,
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
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
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
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
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
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
>
> +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
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
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
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
>>
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
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
+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
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
On Tue, May 24, 2016 at 2:33 PM, R Schumacher wrote:
> At 01:15 PM 5/24/2016, you wrote:
>
> On 5/24/2016 3:57 PM, Eric Moore wrote:
>
> Changing np.arange(10)**3 to have a non-integer dtype seems like a big
> change.
>
>
>
> What about np.arange(100)**5?
>
>
> Interesting,
At 01:15 PM 5/24/2016, you wrote:
On 5/24/2016 3:57 PM, Eric Moore wrote:
Changing np.arange(10)**3 to have a non-integer dtype seems like a
big change.
What about np.arange(100)**5?
Interesting, one warning per instantiation (Py2.7):
>>> import numpy
>>> a=numpy.arange(100)**5
:1:
On 5/24/2016 3:57 PM, Eric Moore wrote:
Changing np.arange(10)**3 to have a non-integer dtype seems like a big change.
What about np.arange(100)**5?
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
Yes, I'm fully aware of that. I'm speaking toward changing the default
result dtype. Raising an error for negative exponents is a fine idea.
Changing np.arange(10)**3 to have a non-integer dtype seems like a big
change.
Speaking of this, that some of the integer array operation errors can be
On Tue, May 24, 2016 at 10:36 AM, Eric Moore wrote:
> I'd say the most compelling case for it is that is how it has always
worked.
> How much code will break if we make that change? (Or if not break, at
least
> have a change in dtype?) Is that worth it?
The current
On 5/24/2016 1:41 PM, Matthew Brett wrote:
It's a well-understood promise though - you always have to be careful
of integer overflow.
Of course. But **almost all** cases overflow.
And "well understood" assume a certain sophistication
of the user, while `arange` will certainly be used
by
On 5/24/2016 1:36 PM, Eric Moore wrote:
How much code will break if we make that change?
Since even arange(10)**10 is already broken,
there will probably not be much new breakage.
But under any of the new proposals, *something* will break.
So the question is, which shows the most foresight?
On Tue, May 24, 2016 at 1:31 PM, Alan Isaac wrote:
> On 5/24/2016 1:19 PM, Stephan Hoyer wrote:
>>
>> the int ** 2 example feels quite compelling to me
>
>
>
> Yes, but that one case is trivial: a*a
Right, but you'd have to know to change your code when numpy makes
this
On Tue, May 24, 2016 at 10:31 AM, Alan Isaac wrote:
> Yes, but that one case is trivial: a*a
an_explicit_name ** 2 is much better than an_explicit_name *
an_explicit_name, though.
___
NumPy-Discussion mailing list
I'd say the most compelling case for it is that is how it has always
worked. How much code will break if we make that change? (Or if not break,
at least have a change in dtype?) Is that worth it?
Eric
On Tue, May 24, 2016 at 1:31 PM, Alan Isaac wrote:
> On 5/24/2016
On 5/24/2016 1:19 PM, Stephan Hoyer wrote:
the int ** 2 example feels quite compelling to me
Yes, but that one case is trivial: a*a
And at least as compelling is not have a**-2 fail
and not being tricked by say np.arange(10)**10.
The latter is a promise of hidden errors.
Alan
On Tue, May 24, 2016 at 9:41 AM, Alan Isaac wrote:
> What exactly is the argument against *always* returning float
> (even for positive integer exponents)?
>
If we were starting over from scratch, I would agree with you, but the int
** 2 example feels quite compelling to
On 5/24/2016 10:03 AM, Marten van Kerkwijk wrote:
The error on int ** (-int) is OK with me too (even though I prefer just
returning floats).
What exactly is the argument against *always* returning float
(even for positive integer exponents)? Relevant context is:
- int ** int will often
The error on int ** (-int) is OK with me too (even though I prefer just
returning floats).
Having a `floor_pow` function may still be good with this solution too.
-- Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On Thu, 19 May 2016 20:30:40 -0700
Nathaniel Smith wrote:
>
> Given these immutable and contradictory constraints, the last bad
> option IMHO would be that we make int ** (negative int) an error in
> all cases, and the error message can suggest that instead of writing
>
>
On Fri, May 20, 2016 at 6:54 PM, Nathaniel Smith wrote:
> On May 20, 2016 12:44 PM, wrote:
> [...]
> >
> > can numpy cast to float by default for power or **?
>
> Maybe? The question is whether there are any valid use cases for getting
> ints back:
>
> >>>
On May 20, 2016 12:44 PM, wrote:
[...]
>
> can numpy cast to float by default for power or **?
Maybe? The question is whether there are any valid use cases for getting
ints back:
>>> np.array([1, 2, 3]) ** 2
array([1, 4, 9])
It's not 100% obvious to me but intuitively
Yes, I was referring to `pow`,
but I had in mind the C++ version,
which is overloaded:
http://www.cplusplus.com/reference/cmath/pow/
Cheers,
Alan
On 5/20/2016 4:27 PM, Warren Weckesser wrote:
C doesn't have an exponentiation operator. The C math library has pow, powf
and powl, which (like
Hi All,
As a final desired state, always returning float seems the best idea. It
seems quite similar to division in this regard, where integer division
works for some values, but not for all. This means not being quite
consistent with python, but as Nathan pointed out, one cannot have
On Fri, May 20, 2016 at 4:27 PM, Warren Weckesser <
warren.weckes...@gmail.com> wrote:
>
>
> On Fri, May 20, 2016 at 4:22 PM, Alan Isaac wrote:
>
>> On 5/19/2016 11:30 PM, Nathaniel Smith wrote:
>>
>>> the last bad
>>> option IMHO would be that we make int ** (negative int)
On Fri, May 20, 2016 at 4:22 PM, Alan Isaac wrote:
> On 5/19/2016 11:30 PM, Nathaniel Smith wrote:
>
>> the last bad
>> option IMHO would be that we make int ** (negative int) an error in
>> all cases, and the error message can suggest that instead of writing
>>
>>
On 5/19/2016 11:30 PM, Nathaniel Smith wrote:
the last bad
option IMHO would be that we make int ** (negative int) an error in
all cases, and the error message can suggest that instead of writing
np.array(2) ** -2
they should instead write
np.array(2) ** -2.0
(And similarly for
On Fri, May 20, 2016 at 3:23 PM, Charles R Harris wrote:
>
>
> On Fri, May 20, 2016 at 1:15 PM, Nathaniel Smith wrote:
>
>> On Fri, May 20, 2016 at 11:35 AM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Thu, May 19, 2016 at
On Fri, May 20, 2016 at 1:15 PM, Nathaniel Smith wrote:
> On Fri, May 20, 2016 at 11:35 AM, Charles R Harris
> wrote:
> >
> >
> > On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote:
> >>
> >> So I guess what makes this tricky is
On Fri, May 20, 2016 at 11:35 AM, Charles R Harris
wrote:
>
>
> On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote:
>>
>> So I guess what makes this tricky is that:
>>
>> - We want the behavior to the same for multiple-element arrays,
>>
On Fri, May 20, 2016 at 12:35 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
> On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote:
>
>> So I guess what makes this tricky is that:
>>
>> - We want the behavior to the same for multiple-element arrays,
>>
On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote:
> So I guess what makes this tricky is that:
>
> - We want the behavior to the same for multiple-element arrays,
> single-element arrays, zero-dimensional arrays, and scalars -- the
> shape of the data shouldn't affect the
So I guess what makes this tricky is that:
- We want the behavior to the same for multiple-element arrays,
single-element arrays, zero-dimensional arrays, and scalars -- the
shape of the data shouldn't affect the semantics of **
- We also want the numpy scalar behavior to match the Python scalar
On Thu, May 19, 2016 at 10:16 PM, wrote:
>
>
> On Thu, May 19, 2016 at 5:37 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> There are currently several pull requests apropos integer arrays/scalars
>> to integer powers and, because the area is
On Thu, May 19, 2016 at 5:37 PM, Charles R Harris wrote:
> Hi All,
>
> There are currently several pull requests apropos integer arrays/scalars
> to integer powers and, because the area is messy and involves tradeoffs,
> I'd like to see some discussion here on the
Hi All,
There are currently several pull requests apropos integer arrays/scalars to
integer powers and, because the area is messy and involves tradeoffs, I'd
like to see some discussion here on the list before proceeding.
*Scalars in 1.10*
In [1]: 1 ** -1
Out[1]: 1.0
In [2]: int16(1) ** -1
90 matches
Mail list logo