Mailman 3 March 2015 - NumPy-Discussion

Pandas v0.16.0 release candidate 1
by Jeff Reback 13 Mar '15

13 Mar '15

Hi, I'm pleased to announce the availability of the first release candidate of Pandas 0.16.0. Please try this RC and report any issues here: Pandas Issues <https://github.com/pydata/pandas/issues> We will be releasing officially in 1 week or so. This is a major release from 0.15.2 and includes a small number of API changes, several new features, enhancements, and performance improvements along with a large number of bug fixes. We recommend that all users upgrade to this version. - Highlights include: - DataFrame.assign method, see *here* <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0160…> - Series.to_coo/from_coo methods to interact with scipy.sparse, see *here* <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0160…> - Backwards incompatible change to Timedelta to conform the .seconds attribute with datetime.timedelta, see *here* <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0160…> - Changes to the .loc slicing API to conform with the behavior of .ix see *here <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#indexing-chan…>* - Changes to the default for ordering in the Categorical constructor, see *here <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0160…>* Here are the full whatsnew and documentation links: v0.16.0 Whatsnew <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html> Source tarballs, windows builds, and mac wheels are available here: Pandas v0.16.0rc1 Release <https://github.com/pydata/pandas/releases> A big thank you to everyone who contributed to this release! Jeff

2 1

argument handling by uniform
by Alan G Isaac 13 Mar '15

13 Mar '15

Today I accidentally wrote `uni = np.random.uniform((-0.5,0.5),201)`, supply a tuple instead of separate low and high values. This gave me two draws (from [0..201] I think). My question: how were the arguments interpreted? Thanks, Alan Isaac

4 4

Re: [Numpy-discussion] Numpy where
by John Kirkham 13 Mar '15

13 Mar '15

Hey Everyone, I felt like I should add to the mix. I added the issue ( https://github.com/numpy/numpy/issues/5679 ) to tie these options together. My main concern is that both wheres behave the same. As far as using a scalar as the first argument, it was an easy example. We could have used actual arrays and we would have had arrays full of Nones. Though I do see this point of "why should we have indices returned for a scalar". This means nonzero should change, as well. I agree with Chuck on case 4. If we already allow all other scalars, None should be no different. Plus, I would rather have a breaking change in the ma module than in core. Best, John >> > I think the question is if scalars should be acceptable for the first >> > argument, not if it should be for the 2nd and 3rd argument. >> > >> > If scalar can be given for the first argument, the the first three makes >> > sense. Although, I have no clue why we would allow that. >> > >> > Ben Root >> > On Mar 12, 2015 9:25 PM, "Nathaniel Smith" <njs(a)pobox.com> wrote: >> >> > On Mar 12, 2015 5:02 PM, "Charles R Harris" <charlesr.harris(a)gmail.com> >> > wrote: >> > > >> > > Hi All, >> > > >> > > This is apropos gh-5582 dealing with some corner cases of np.where. The >> > following are the current behavior >> > > >> > > >>> import numpy >> > > >>> numpy.where(True) # case 1 >> > > ... (array([0]),) >> > > >>> numpy.where(True, None, None) # case 2 >> > > ... array(None, dtype=object) >> > > >>> numpy.ma.where(True) # case 3 >> > > ... (array([0]),) >> > > >>> numpy.ma.where(True, None, None) # case 4 >> > > ... (array([0]),) >> > > >> > > The question is, what exactly should be done in these cases? I'd be >> > inclined to raise an error for cases 1 and 3. Case two looks correct to me >> > if we agree that scalar inputs are acceptable. Case 4 looks wrong. >> > >> > I can't think of any reason scalars wouldn't be acceptable. So everything >> > you suggest sounds right to me. >> > >> > -n >> > Hi All, >> > >> > This is apropos gh-5582 <https://github.com/numpy/numpy/pull/5582> >> > dealing with some corner cases of np.where. The following are the current >> > behavior >> > >> > >>> import numpy >> > >>> numpy.where(True) # case 1 >> > ... (array([0]),) >> > >>> numpy.where(True, None, None) # case 2 >> > ... array(None, dtype=object) >> > >>> numpy.ma.where(True) # case 3 >> > ... (array([0]),) >> > >>> numpy.ma.where(True, None, None) # case 4 >> > ... (array([0]),) >> > >> > The question is, what exactly should be done in these cases? I'd be >> > inclined to raise an error for cases 1 and 3. Case two looks correct to me >> > if we agree that scalar inputs are acceptable. Case 4 looks wrong. >> > >> > Thoughts? >> > >> > Chuck >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion(a)scipy.org >> > http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion(a)scipy.org >> > http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > >> >

1 0

Numpy 1.10
by Charles R Harris 13 Mar '15

13 Mar '15

Hi All, Time to start thinking about numpy 1.10. At the moment there are 21 blockers and 93 PRs. it would be good if we could prioritize the blockers and the PRs. It might be a good idea to also look at closing some of the aging PRs. These days it seems to be normal to have 20 or so PRs in progress, it it would be nice if we could get the total down around 40-50. I don't see a numpy 1.10 before July, but it is going to take a few months to get things in order, so now is a good time to start. Chuck

4 7

tie breaking for max, min, argmax, argmin
by Johannes Kulick 12 Mar '15

12 Mar '15

Hello, I wonder if it would be worth to enhance max, min, argmax and argmin (more?) with a tie breaking parameter: If multiple entries have the same value the first value is returned by now. It would be useful to have a parameter to alter this behavior to an arbitrary tie-breaking. I would propose, that the tie-breaking function gets a list with all indices of the max/mins. Example: >>> a = np.array([ 1, 2, 5, 5, 2, 1]) >>> np.argmax(a, tie_breaking=random.choice) 3 >>> np.argmax(a, tie_breaking=random.choice) 2 >>> np.argmax(a, tie_breaking=random.choice) 2 >>> np.argmax(a, tie_breaking=random.choice) 2 >>> np.argmax(a, tie_breaking=random.choice) 3 Especially for some randomized experiments it is necessary that not always the first maximum is returned, but a random optimum. Thus I end up writing these things over and over again. I understand, that max and min are crucial functions, which shouldn't be slowed down by the proposed changes. Adding new functions instead of altering the existing ones would be a good option. Are there any concerns against me implementing these things and sending a pull request? Should such a function better be included in scipy for example? Best, Johannes

3 2

SIMD programming in Cython
by Sturla Molden 11 Mar '15

11 Mar '15

So I just learned a new trick. This is a very nice one which can be nice to know about, so I thought I should share this: https://groups.google.com/forum/#!msg/cython-users/nTnyI7A6sMc/a6_GnOOsLuQJ Regards, Sturla

1 0

Would like to patch docstring for numpy.random.normal
by Daniel Sank 10 Mar '15

10 Mar '15

Dear numpy users, I would like to clarify the docstring for numpy.random.normal. I submitted a patch but it was rejected because it breaks the tests. Unfortunately, the development workflow page does not explain how to run the tests (in fact it doesn't mention them at all). I am therefore writing to discuss my proposed change and find out how to run the tests so that I can make it compatible with the existing code. The current form of the docstring for numpy.random.normal is as follows: """ normal(loc=0.0, scale=1.0, size=None) <snip> Parameters ---------- loc : float Mean ("centre") of the distribution. scale : float Standard deviation (spread or "width") of the distribution. size : tuple of ints Output shape. If the given shape is, e.g., ``(m, n, k)``, then ``m * n * k`` samples are drawn. <snip> Notes ----- The probability density for the Gaussian distribution is .. math:: p(x) = \frac{1}{\sqrt{ 2 \pi \sigma^2 }} e^{ - \frac{ (x - \mu)^2 } {2 \sigma^2} }, where :math:`\mu` is the mean and :math:`\sigma` the standard deviation. The square of the standard deviation, :math:`\sigma^2`, is called the variance. """ It seems unnecessarily convoluted to name the input arguments "loc" and "scale", then immediately define them as the "mean" and "standard deviation" in the Parameters section, and then again rename them as "mu" and "sigma" in the written formula. I propose to simply change the argument names to "mean" and "sigma" to improve consistency. I tried fixing this via a pull request [1] but it was closed because my change broke the tests. Unfortunately, the development workflow section of the web page doesn't explain how to run the tests (in fact it doesn't even mention them). How can I make the proposed change without breaking the tests, or equivalently how do I find out how to run the tests myself so I can find an acceptable way of making the change on my own? [1] https://github.com/numpy/numpy/pull/5607#issuecomment-76114282 -- Daniel Sank

6 9

MKL ValueError: On entry to DLASCL parameter number 5 had an illegal value
by josef.pktd＠gmail.com 10 Mar '15

10 Mar '15

I got a illegal value message using MKL on Windows 64 while running the statsmodels test suite. Kevin is getting the same with more information, which indicates that it might be numpy.linalg.svd https://github.com/statsmodels/statsmodels/issues/2308#issuecomment-78086656 Is this serious? I'm just setting up a new computer and haven't investigated yet. Given the name of the test class, this might be a warning for an inf or nan, then it would be our problem in statsmodels Josef

2 2

DePy 2015
by Massimo DiPierro 09 Mar '15

09 Mar '15

Hello everybody, We are organizing a new conference on Python in Chicago (May 29-30) with focus on Numerical Applications, Machine Learning and Web: http://mdp.cdm.depaul.edu/DePy2015/default/index We are looking for participants, speakers, and sponsors. Please register and submit a submit a talk/tutorial proposal. Massimo

1 0

numpy array casting ruled not safe
by Dinesh Vadhia 08 Mar '15

08 Mar '15

This was originally posted on SO (https://stackoverflow.com/questions/28853740/numpy-array-casting-ruled-not-…) and it was suggested it is probably a bug in numpy.take. Python 2.7.8 |Anaconda 2.1.0 (32-bit)| (default, Jul 2 2014, 15:13:35) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. >>> import numpy >>> numpy.__version__ '1.9.2' >>> a = numpy.array([9, 7, 5, 4, 3, 1], dtype=numpy.uint32) >>> b = numpy.array([1, 3], dtype=numpy.uint32) >>> c = a.take(b) Traceback (most recent call last): File "<pyshell#5>", line 1, in <module> c = a.take(b) TypeError: Cannot cast array data from dtype('uint32') to dtype('int32') according to the rule 'safe'

5 5