Re: [Numpy-discussion] Integers to integer powers, let's make a decision
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
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
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
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
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
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
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
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
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
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
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
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
> > +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
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
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
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
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
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
+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
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
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