Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Charles R Harris]

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 result is still integer. I would like more input from
> users than we have seen so far...
>
> Just to highlight this, if anyone wants to strengthen the argument for
> switching to float then this is something you can literally do: tweak a
> local checkout of numpy to return float from int**int and
> array-of-int**array-of-int, and then try running the test suites of
> projects like scikit-learn, astropy, nipy, scikit-image, ...
>
> (The reason I'm phrasing this as something that people who like the float
> idea should do is that generally when proposing a risky
> compatibility-breaking change, the onus is on the ones proposing it to
> demonstrate that the risk is ok.)
>

I was tempted for a bit, but I think the biggest compatibility problem is
not current usage, but the fact that code written assuming float results
will not work for earlier versions of numpy, and that would be a nasty
situation. Given that integers raised to negative integer powers is already
pretty much broken, making folks write around an exception will result in
code compatible with previous numpy versions.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Nathaniel Smith]

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 seen so far...

Just to highlight this, if anyone wants to strengthen the argument for
switching to float then this is something you can literally do: tweak a
local checkout of numpy to return float from int**int and
array-of-int**array-of-int, and then try running the test suites of
projects like scikit-learn, astropy, nipy, scikit-image, ...

(The reason I'm phrasing this as something that people who like the float
idea should do is that generally when proposing a risky
compatibility-breaking change, the onus is on the ones proposing it to
demonstrate that the risk is ok.)

-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Charles R Harris]

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 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-incompatible change that I'm not sure how we could actually
>> make the transition without first making it an error for a while.
>>
>
> AFAIU, only the dtype for int**int would change. So, what would be the
> problem with FutureWarnings as with other dtype changes that were done in
> recent releases.
>
>
 The main problem I see with that is that numpy integers would behave
 differently than Python integers, and the difference would be silent. With
 option 1 it is possible to write code that behaves the same up to overflow
 and the error message would supply a warning when the exponent should be
 float. One could argue that numpy scalar integer types could be made to
 behave like python integers, but then their behavior would differ from
 numpy arrays and numpy scalar arrays.

>>>
>>> I'm not sure I understand.
>>>
>>> Do you mean
>>>
>>> np.arange(5)**2 would behave differently than np.arange(5)**np.int_(2)
>>>
>>> or 2**2 would behave differently than np.int_(2)**np.int(2)
>>>
>>
>> The second case. Python returns ints for non-negative integer powers of
>> ints.
>>
>>
>>>
>>> ?
>>>
>>>
>>> AFAICS, there are many cases where numpy scalars don't behave like
>>> python scalars. Also, does different behavior mean different type/dtype or
>>> different numbers.  (The first I can live with, the second requires human
>>> memory usage, which is a scarce resource.)
>>>
>>> >>> 2**(-2)
>>> 0.25
>>>
>>>
>> But we can't mix types in np.arrays and we can't depend on the element
>> values of arrays in the exponent, but only on their type, so 2 ** array([1,
>> -1]) must contain a single type and making that type float would surely
>> break code.  Scalar arrays, which are arrays, have the same problem. We
>> can't do what Python does with ndarrays and numpy scalars, and it would be
>> best to be consistent. Division was a simpler problem to deal with, as
>> there were two operators, `//` and `/`. If there were two exponential
>> operators life would be simpler.
>>
>
> What bothers me with the entire argument is that you are putting higher
> priority on returning a dtype than on returning the correct numbers.
>

Overflow in integer powers would be correct in modular arithmetic, at least
for unsigned. Signed is a bit trickier. But overflow is a known property of
numpy integer types. If we raise an exception for the negative exponents we
at least aren't returning incorrect numbers.


>
> Reverse the argument: Because we cannot make the return type value
> dependent we **have** to return float, in order to get the correct number.
> (It's an argument not what we really have to do.)
>

>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.


>
>
> Which code really breaks, code that gets a float instead of an int, and
> with some advance warning users that really need to watch their memory can
> use np.power.
>
> My argument before was that I think a simple operator like `**` should
> work for 90+% of the users and match their expectation, and the users that
> need to watch dtypes can as well use the function.
>
> (I can also live with the exception from case 1., but I really think this
> is like the python 2 integer division "surprise")
>

Well, that is why we would raise an exception, making it less surprising ;)

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 seen so far...

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[josef . pktd]

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 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 actually
> make the transition without first making it an error for a while.
>

 AFAIU, only the dtype for int**int would change. So, what would be the
 problem with FutureWarnings as with other dtype changes that were done in
 recent releases.


>>> The main problem I see with that is that numpy integers would behave
>>> differently than Python integers, and the difference would be silent. With
>>> option 1 it is possible to write code that behaves the same up to overflow
>>> and the error message would supply a warning when the exponent should be
>>> float. One could argue that numpy scalar integer types could be made to
>>> behave like python integers, but then their behavior would differ from
>>> numpy arrays and numpy scalar arrays.
>>>
>>
>> I'm not sure I understand.
>>
>> Do you mean
>>
>> np.arange(5)**2 would behave differently than np.arange(5)**np.int_(2)
>>
>> or 2**2 would behave differently than np.int_(2)**np.int(2)
>>
>
> The second case. Python returns ints for non-negative integer powers of
> ints.
>
>
>>
>> ?
>>
>>
>> AFAICS, there are many cases where numpy scalars don't behave like python
>> scalars. Also, does different behavior mean different type/dtype or
>> different numbers.  (The first I can live with, the second requires human
>> memory usage, which is a scarce resource.)
>>
>> >>> 2**(-2)
>> 0.25
>>
>>
> But we can't mix types in np.arrays and we can't depend on the element
> values of arrays in the exponent, but only on their type, so 2 ** array([1,
> -1]) must contain a single type and making that type float would surely
> break code.  Scalar arrays, which are arrays, have the same problem. We
> can't do what Python does with ndarrays and numpy scalars, and it would be
> best to be consistent. Division was a simpler problem to deal with, as
> there were two operators, `//` and `/`. If there were two exponential
> operators life would be simpler.
>

What bothers me with the entire argument is that you are putting higher
priority on returning a dtype than on returning the correct numbers.

Reverse the argument: Because we cannot make the return type value
dependent we **have** to return float, in order to get the correct number.
(It's an argument not what we really have to do.)


Which code really breaks, code that gets a float instead of an int, and
with some advance warning users that really need to watch their memory can
use np.power.

My argument before was that I think a simple operator like `**` should work
for 90+% of the users and match their expectation, and the users that need
to watch dtypes can as well use the function.

(I can also live with the exception from case 1., but I really think this
is like the python 2 integer division "surprise")

Josef


>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Charles R Harris]

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. 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 while.

>>>
>>> AFAIU, only the dtype for int**int would change. So, what would be the
>>> problem with FutureWarnings as with other dtype changes that were done in
>>> recent releases.
>>>
>>>
>> The main problem I see with that is that numpy integers would behave
>> differently than Python integers, and the difference would be silent. With
>> option 1 it is possible to write code that behaves the same up to overflow
>> and the error message would supply a warning when the exponent should be
>> float. One could argue that numpy scalar integer types could be made to
>> behave like python integers, but then their behavior would differ from
>> numpy arrays and numpy scalar arrays.
>>
>
> I'm not sure I understand.
>
> Do you mean
>
> np.arange(5)**2 would behave differently than np.arange(5)**np.int_(2)
>
> or 2**2 would behave differently than np.int_(2)**np.int(2)
>

The second case. Python returns ints for non-negative integer powers of
ints.


>
> ?
>
>
> AFAICS, there are many cases where numpy scalars don't behave like python
> scalars. Also, does different behavior mean different type/dtype or
> different numbers.  (The first I can live with, the second requires human
> memory usage, which is a scarce resource.)
>
> >>> 2**(-2)
> 0.25
>
>
But we can't mix types in np.arrays and we can't depend on the element
values of arrays in the exponent, but only on their type, so 2 ** array([1,
-1]) must contain a single type and making that type float would surely
break code.  Scalar arrays, which are arrays, have the same problem. We
can't do what Python does with ndarrays and numpy scalars, and it would be
best to be consistent. Division was a simpler problem to deal with, as
there were two operators, `//` and `/`. If there were two exponential
operators life would be simpler.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PyArray_Scalar should not use memcpy

[Nathaniel Smith]

On Jun 4, 2016 13:58, "Matti Picus"  wrote:
>
> Hi. This is a heads up and RFC about a pull request I am preparing for
PyArray_Scalar, within the framework of getting NumPy working properly on
PyPy. For those who don't know, the numpy HEAD builds and runs on PyPy2.7
HEAD (otherwise known as nightly default). However there are a number of
test failures, some are caused by (ab)use of memcpy on c-level pointers
obtained from Py*_FromString().
>
> I am currently rewriting PyArray_Scalar to not use memcpy, and wondering
how deep of a refactoring would be acceptable by the maintainers in a
single pull request? Should I just stick to small changes to eliminate the
two calls to memcpy, or clean up and restructure the entire function around
a more switch(type_num) programming style?

I don't think anyone is particularly attached to the current internal
structure of the numpy scalars. Beyond that it's hard to say in the
abstract... a small change will certainly be easier and quicker to merge
than a big change, but if you have a good clean up then it'd certainly be
welcome :-). You know better than us how easy it would be to split up the
changes. Two things to watch out for in general are that numpy can be
rather picky about abi compatibility and performance regressions. (The
scalar code is definitely performance-sensitive.)

-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[josef . pktd]

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 '**'
>>>
>>> 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 while.
>>>
>>
>> AFAIU, only the dtype for int**int would change. So, what would be the
>> problem with FutureWarnings as with other dtype changes that were done in
>> recent releases.
>>
>>
> The main problem I see with that is that numpy integers would behave
> differently than Python integers, and the difference would be silent. With
> option 1 it is possible to write code that behaves the same up to overflow
> and the error message would supply a warning when the exponent should be
> float. One could argue that numpy scalar integer types could be made to
> behave like python integers, but then their behavior would differ from
> numpy arrays and numpy scalar arrays.
>

I'm not sure I understand.

Do you mean

np.arange(5)**2 would behave differently than np.arange(5)**np.int_(2)

or 2**2 would behave differently than np.int_(2)**np.int(2)

?


AFAICS, there are many cases where numpy scalars don't behave like python
scalars. Also, does different behavior mean different type/dtype or
different numbers.  (The first I can live with, the second requires human
memory usage, which is a scarce resource.)

>>> 2**(-2)
0.25

Josef



>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Charles R Harris]

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-incompatible change that I'm not sure how we could actually
>> make the transition without first making it an error for a while.
>>
>
> AFAIU, only the dtype for int**int would change. So, what would be the
> problem with FutureWarnings as with other dtype changes that were done in
> recent releases.
>
>
The main problem I see with that is that numpy integers would behave
differently than Python integers, and the difference would be silent. With
option 1 it is possible to write code that behaves the same up to overflow
and the error message would supply a warning when the exponent should be
float. One could argue that numpy scalar integer types could be made to
behave like python integers, but then their behavior would differ from
numpy arrays and numpy scalar arrays.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[josef . pktd]

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 actually
> make the transition without first making it an error for a while.
>

AFAIU, only the dtype for int**int would change. So, what would be the
problem with FutureWarnings as with other dtype changes that were done in
recent releases.

Josef



>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Nathaniel Smith]

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 while.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[V. Armando Sole]

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.
AFAICT, the two proposals are

* Integers to negative integer powers raise an error.
* Integers to integer powers always results in floats.

My own sense is that 1. would be closest to current behavior and
using a float exponential when a float is wanted is an explicit
way to indicate that desire. OTOH, 2. would be the most convenient
default for everyday numerical computation, but I think would more
likely break current code. I am going to come down on the side of
1., which I don't think should cause too many problems if we start
with a {Future, Deprecation}Warning explaining the workaround.


I'm in favor of 2.  always float for `**`
I don't see enough pure integer usecases to throw away a nice
operator.



___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] PyArray_Scalar should not use memcpy

[Matti Picus]

Hi. This is a heads up and RFC about a pull request I am preparing for 
PyArray_Scalar, within the framework of getting NumPy working properly 
on PyPy. For those who don't know, the numpy HEAD builds and runs on 
PyPy2.7 HEAD (otherwise known as nightly default). However there are a 
number of test failures, some are caused by (ab)use of memcpy on c-level 
pointers obtained from Py*_FromString().


I am currently rewriting PyArray_Scalar to not use memcpy, and wondering 
how deep of a refactoring would be acceptable by the maintainers in a 
single pull request? Should I just stick to small changes to eliminate 
the two calls to memcpy, or clean up and restructure the entire function 
around a more switch(type_num) programming style?


Thanks,
Matti
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Peter Creasey]

>
> +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 is that 1. would be closest to current behavior and using a
>> float exponential when a float is wanted is an explicit way to indicate that
>> desire. OTOH, 2. would be the most convenient default for everyday numerical
>> computation, but I think would more likely break current code. I am going to
>> come down on the side of 1., which I don't think should cause too many
>> problems if we start with a {Future, Deprecation}Warning explaining the
>> workaround.
>>
>> Chuck
>>


+1 (grudgingly)

My thoughts on this are:
(i) Intuitive APIs are better, and power(a,b) suggests to a lot of
(most?) readers that you are going to invoke a function like the C
pow(double x, double y) on every element. Doing positive integer
powers with the same function name suggests a correspondence that is
in practice not that helpful. With a time machine I’d suggest a
separate function for positive integer powers, however...
(ii) I think that ship has sailed, and particularly with e.g. a**3 the
numpy conventions are backed up by quite a bit of code, probably too
much to change without a lot of problems. So I’d go with integer ^
negative integer is an error.

Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[josef . pktd]

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 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 is that 1. would be closest to current behavior and using
> a
> >>> float exponential when a float is wanted is an explicit way to
> indicate that
> >>> desire. OTOH, 2. would be the most convenient default for everyday
> numerical
> >>> computation, but I think would more likely break current code. I am
> going to
> >>> come down on the side of 1., which I don't think should cause too many
> >>> problems if we start with a {Future, Deprecation}Warning explaining the
> >>> workaround.
> >
> >
> > I'm in favor of 2.  always float for `**`
> > I don't see enough pure integer usecases to throw away a nice operator.
>
> I can't make sense of 'throw away a nice operator' - you still have
> arr ** 2.0 if you want floats.
>


but if we have x**y, then we always need to check the dtype. If we don't we
get RuntimeErrors or overflow, where we might have forgotten to include the
relevant cases in the unit tests.

numpy has got pickier with using only integers in some areas (index, ...).
Now we have to watch out that we convert back to floats for power.

Not a serious problem for a library with unit tests and enough users who
run into the dtype issues and report them.
But I'm sure I will have to fix any scripts or interactive work that I'm
writing.
It's just another thing to watch out for, after we managed to get rid of
integer division 1/2=?.

Josef




>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Matthew Brett]

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 are
>>>
>>> Integers to negative integer powers raise an error.
>>> Integers to integer powers always results in floats.
>>>
>>> My own sense is that 1. would be closest to current behavior and using a
>>> float exponential when a float is wanted is an explicit way to indicate that
>>> desire. OTOH, 2. would be the most convenient default for everyday numerical
>>> computation, but I think would more likely break current code. I am going to
>>> come down on the side of 1., which I don't think should cause too many
>>> problems if we start with a {Future, Deprecation}Warning explaining the
>>> workaround.
>
>
> I'm in favor of 2.  always float for `**`
> I don't see enough pure integer usecases to throw away a nice operator.

I can't make sense of 'throw away a nice operator' - you still have
arr ** 2.0 if you want floats.

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[josef . pktd]

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 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
>> float exponential when a float is wanted is an explicit way to indicate
>> that desire. OTOH, 2. would be the most convenient default for everyday
>> numerical computation, but I think would more likely break current code. I
>> am going to come down on the side of 1., which I don't think should cause
>> too many problems if we start with a {Future, Deprecation}Warning
>> explaining the workaround.
>>
>
I'm in favor of 2.  always float for `**`
I don't see enough pure integer usecases to throw away a nice operator.

Josef



>
> Note that current behavior in 1.11 is such a mess
> ```
> In [5]: array([0], dtype=int64) ** -1
> Out[5]: array([-9223372036854775808])
>
> In [6]: array([0], dtype=uint64) ** -1
> Out[6]: array([ inf])
> ```
> That the simplest approach might be to start by raising an error rather
> than by trying to maintain current behavior and issuing a warning.
>
> Chuck
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Charles R Harris]

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 own sense is that 1. would be closest to current behavior and using a
> float exponential when a float is wanted is an explicit way to indicate
> that desire. OTOH, 2. would be the most convenient default for everyday
> numerical computation, but I think would more likely break current code. I
> am going to come down on the side of 1., which I don't think should cause
> too many problems if we start with a {Future, Deprecation}Warning
> explaining the workaround.
>

Note that current behavior in 1.11 is such a mess
```
In [5]: array([0], dtype=int64) ** -1
Out[5]: array([-9223372036854775808])

In [6]: array([0], dtype=uint64) ** -1
Out[6]: array([ inf])
```
That the simplest approach might be to start by raising an error rather
than by trying to maintain current behavior and issuing a warning.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Matthew Brett]

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.
>> Integers to integer powers always results in floats.
>>
>> My own sense is that 1. would be closest to current behavior and using a
>> float exponential when a float is wanted is an explicit way to indicate that
>> desire. OTOH, 2. would be the most convenient default for everyday numerical
>> computation, but I think would more likely break current code. I am going to
>> come down on the side of 1., which I don't think should cause too many
>> problems if we start with a {Future, Deprecation}Warning explaining the
>> workaround.

I agree - error for negative integer powers seems like the safest option.

Cheers,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[Nathaniel Smith]

+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 is that 1. would be closest to current behavior and using a
> float exponential when a float is wanted is an explicit way to indicate that
> desire. OTOH, 2. would be the most convenient default for everyday numerical
> computation, but I think would more likely break current code. I am going to
> come down on the side of 1., which I don't think should cause too many
> problems if we start with a {Future, Deprecation}Warning explaining the
> workaround.
>
> Chuck
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Integers to integer powers, let's make a decision

[Charles R Harris]

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
float exponential when a float is wanted is an explicit way to indicate
that desire. OTOH, 2. would be the most convenient default for everyday
numerical computation, but I think would more likely break current code. I
am going to come down on the side of 1., which I don't think should cause
too many problems if we start with a {Future, Deprecation}Warning
explaining the workaround.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Integers to integer powers

[Charles R Harris]

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, one warning per instantiation (Py2.7):
>
> >>> import numpy
> >>> a=numpy.arange(100)**5
> :1: RuntimeWarning: invalid value encountered in power
> >>> a=numpy.arange(100)**5.
> >>> b=numpy.arange(100.)**5
> >>> a==b
> array([ True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True,  True,  True,  True,  True,  True,  True,  True,  True,
> True], dtype=bool)
> >>> numpy.arange(100)**5
> array([  0,   1,  32, 243,1024,
>   3125,7776,   16807,   32768,   59049,
> 10,  161051,  248832,  371293,  537824,
> 759375, 1048576, 1419857, 1889568, 2476099,
>320, 4084101, 5153632, 6436343, 7962624,
>9765625,11881376,14348907,17210368,20511149,
>   2430,28629151,33554432,39135393,45435424,
>   52521875,60466176,69343957,79235168,90224199,
>  10240,   115856201,   130691232,   147008443,   164916224,
>  184528125,   205962976,   229345007,   254803968,   282475249,
>  31250,   345025251,   380204032,   418195493,   459165024,
>  503284375,   550731776,   601692057,   656356768,   714924299,
>  77760,   844596301,   916132832,   992436543,  1073741824,
> 1160290625,  1252332576,  1350125107,  1453933568,  1564031349,
> 168070,  1804229351,  1934917632,  2073071593, -2147483648,
>-2147483648, -2147483648, -2147483648, -2147483648, -2147483648,
>-2147483648, -2147483648, -2147483648, -2147483648, -2147483648,
>-2147483648, -2147483648, -2147483648, -2147483648, -2147483648,
>-2147483648, -2147483648, -2147483648, -2147483648, -2147483648,
>-2147483648, -2147483648, -2147483648, -2147483648, -2147483648])
> >>>
> >>> numpy.arange(100, dtype=numpy.int64)**5
> array([ 0,  1, 32,243,   1024,
>  3125,   7776,  16807,  32768,  59049,
>10, 161051, 248832, 371293, 537824,
>759375,1048576,1419857,1889568,2476099,
>   320,4084101,5153632,6436343,7962624,
>   9765625,   11881376,   14348907,   17210368,   20511149,
>  2430,   28629151,   33554432,   39135393,   45435424,
>  52521875,   60466176,   69343957,   79235168,   90224199,
> 10240,  115856201,  130691232,  147008443,  164916224,
> 184528125,  205962976,  229345007,  254803968,  282475249,
> 31250,  345025251,  380204032,  418195493,  459165024,
> 503284375,  550731776,  601692057,  656356768,  714924299,
> 77760,  844596301,  916132832,  992436543, 1073741824,
>1160290625, 1252332576, 1350125107, 1453933568, 1564031349,
>168070, 1804229351, 1934917632, 2073071593, 2219006624,
>2373046875, 2535525376, 2706784157, 2887174368, 3077056399,
>327680, 3486784401, 3707398432, 3939040643, 4182119424,
>4437053125, 4704270176, 4984209207, 5277319168, 5584059449,
>590490, 6240321451, 6590815232, 6956883693, 7339040224,
>7737809375, 8153726976, 8587340257, 9039207968, 9509900499],
> dtype=int64)
>

That is the Python default. To always see warnings do
`warnings.simplefilter('always')` before running.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion