Re: [Numpy-discussion] Why do mgrid and meshgrid not return broadcast arrays?

Ah, fantastic, thanks Per! I'd still be interested to hear from the core devs as to why this isn't the default, both with meshgrid and mgrid... Juan. On 9 Mar 2017, 6:29 PM +1100, per.brodtk...@ffi.no, wrote: > Hi, Juan. > > Meshgrid can actually give what you want, b

Re: [Numpy-discussion] Why do mgrid and meshgrid not return broadcast arrays?

, 4, 4]]) In [180]: a0.strides Out[180]: (40, 8) In [181]: a1.strides Out[181]: (8, 0) On 9 Mar 2017, 2:05 PM +1100, Warren Weckesser , wrote: > > > > On Wed, Mar 8, 2017 at 9:48 PM, Juan Nunez-Iglesias > > wrote: > > > I was a bit surprised to discover that bot

[Numpy-discussion] Why do mgrid and meshgrid not return broadcast arrays?

, :512] 100 loops, best of 3: 4.84 ms per loop Is there a conscious design decision as to why this isn’t what meshgrid/mgrid do already? Or would a PR be welcome to do this? Thanks, Juan. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org

Re: [Numpy-discussion] ANN: NumExpr3 Alpha

anyone explored the possibility of using Python 3.6's frame evaluation API to do this? I remember a vague discussion on this list a while back but I don't know whether anything came of it. Thanks! Juan. On 18 Feb 2017, 3:42 AM +1100, Robert McLeod , wrote: > Hi David, > &g

Re: [Numpy-discussion] Deprecating matrices.

Hi all! I've been lurking on this discussion, and don't have too much to add except to encourage a fast deprecation: I can't wait for sparse matrices to have an element-wise multiply operator. On 7 Jan 2017, 7:52 PM +1100, Ralf Gommers , wrote: > > > On Sat, Jan 7, 2017 at 9:39 PM, Nathaniel Smi

Re: [Numpy-discussion] how to name "contagious" keyword in np.ma.convolve

+1 for propagate_mask. That is the only proposal that immediately makes sense to me. "contagious" may be cute but I think approximately 0% of users would guess its purpose on first use. Can you elaborate on what happens with the masks exactly? I didn't quite get why propagate_mask=False was uni

Re: [Numpy-discussion] Numpy set_printoptions, silent failure, bug?

https://github.com/numpy/numpy/issues From: John Ladasky Reply: Discussion of Numerical Python Date: 20 July 2016 at 7:49:10 AM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Numpy set_printoptions, silent failure, bug? Hi Robert, > > Thanks for your reply. If no one

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

at_leastnd would be useful for nd image processing in a very analogous way to how at_least2d is used by scikit-image, assuming it prepends. The at_least3d choice is baffling, seems analogous to the 0.5-based indexing presented at PyCon, and should be "fun" to deprecate. =P On 6 July 2016 at 2:57

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

the described behavior of np.at_least3d, which came as a surprise. I certainly would expect the “at_least” family to all work in the same way as broadcasting, ie prepending singleton dimensions. Prepend/append behavior can be controlled either by keyword or simply by using .T, I don’t mind either way. J

Re: [Numpy-discussion] Picking rows with the first (or last) occurrence of each key

On 4 July 2016 at 7:27:47 PM, Skip Montanaro (skip.montan...@gmail.com) wrote: Hashing it probably wouldn't work, too great a chance for collisions. If the string is ASCII, you can always interpret the bytes as part of an 8 byte integer. Or, you can map unique values to consecutive integers. ___

Re: [Numpy-discussion] Picking rows with the first (or last) occurrence of each key

On 4 July 2016 at 7:38:48 PM, Skip Montanaro (skip.montan...@gmail.com) wrote: Oh, cool. Precisely the sort of solution I was hoping would turn up. Except it doesn’t seem to meet your original spec, which retrieved the first item of each *run* of an index value? _

Re: [Numpy-discussion] Picking rows with the first (or last) occurrence of each key

to get either the first or last occurrence of each run. Juan. On 2 July 2016 at 10:10:16 PM, Skip Montanaro (skip.montan...@gmail.com) wrote: (I'm probably going to botch the description...) Suppose I have a 2D array of Python objects, the first n elements of each row form a key, the re

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

+1 to Alan's point. Having different type behaviour depending on the values of x and y for np.arange(x) ** y would be awful, and it would also be awful to have to worry about overflow here... ... Having said that, it would be equally annoying to not have a way to define integer powers... From:

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

Todd, Would you consider a 1D array to be a row vector or a column vector for the purposes of transposition? The "correct" answer is not clear to me. Juan. On Wed, Apr 6, 2016 at 12:26 PM, Alan Isaac wrote: > On 4/5/2016 10:11 PM, Todd wrote: > >> When you try to transpo

Re: [Numpy-discussion] Make np.bincount output same dtype as weights

Thanks for clarifying, Jaime, and fwiw I agree with Josef: I would expect np.bincount to behave like np.sum with regards to promoting weights dtypes. Including bool. On Sun, Mar 27, 2016 at 1:58 PM, wrote: > On Sat, Mar 26, 2016 at 9:54 PM, Joseph Fox-Rabinovitz > wrote: > > Would it make sense

Re: [Numpy-discussion] Make np.bincount output same dtype as weights

Just to clarify, this will only affect weighted bincounts, right? I can't tell you in how many places my code depends on the return type being integer!!! On 27 Mar 2016, 7:16 AM +1100, Jaime Fernández del Río, wrote: > Hi all, > > I have just submitted a PR (#7464(https://github.com/numpy/num

Re: [Numpy-discussion] 100 numpy exercises (80/100)

Thanks for this fantastic resource, Nicolas! I also had never heard of argpartition and immediately know of many places in my code where I can use it. I also learned that axis= can take a tuple as an argument. On Wed, Mar 9, 2016 at 7:18 AM, Nicolas P. Rougier wrote: > > Hi all, > > I've just ad

Re: [Numpy-discussion] making "low" optional in numpy.randint

Ah! Touché! =) My last and admittedly weak defense is that I've been writing numpy since before 1.7. =) On Thu, Feb 18, 2016 at 11:08 AM, Alan Isaac wrote: > On 2/17/2016 7:01 PM, Juan Nunez-Iglesias wrote: > >> Notice the limitation "1D array-like". >> > &

Re: [Numpy-discussion] making "low" optional in numpy.randint

Notice the limitation "1D array-like". On Thu, Feb 18, 2016 at 10:59 AM, Alan Isaac wrote: > On 2/17/2016 6:48 PM, Juan Nunez-Iglesias wrote: > >> Also fwiw, I think the 0-based, half-open interval is one of the best >> features of Python indexing and yes, I do

Re: [Numpy-discussion] making "low" optional in numpy.randint

een deprecated in favor of randint. > > On Wed, Feb 17, 2016 at 11:48 PM, Juan Nunez-Iglesias > wrote: > >> Also fwiw, I think the 0-based, half-open interval is one of the best >> features of Python indexing and yes, I do use random integers to index into >> my a

Re: [Numpy-discussion] making "low" optional in numpy.randint

Also fwiw, I think the 0-based, half-open interval is one of the best features of Python indexing and yes, I do use random integers to index into my arrays and would not appreciate having to litter my code with "-1" everywhere. On Thu, Feb 18, 2016 at 10:29 AM, Alan Isaac wrote: > On 2/17/2016 3

Re: [Numpy-discussion] julia - Multidimensional algorithms and iteration

Nice. I particularly liked that indices are just arrays, so you can do array arithmetic on them. I spend a lot of time converting tuples-to-array-to-tuples. If I understand correctly, indexing-with-arrays is overloaded in NumPy so the tuple syntax isn't going away any time soon, is it? On Wed, Feb

Re: [Numpy-discussion] Make as_strided result writeonly

I agree that it's not ideal that the return value of as_strided is writable. However, to be clear, this *would* break the API, which should not happen between minor releases when using semantic versioning. Even with a deprecation cycle, for libraries such as scikit-image that want to maintain broad

Re: [Numpy-discussion] Make as_strided result writeonly

is that unless someone has been bitten by this (?), the benefit does not outweigh the cost of deprecation. Perhaps something to push to 2.0? On Sun, Jan 24, 2016 at 8:17 PM, Sebastian Berg wrote: > On So, 2016-01-24 at 13:00 +1100, Juan Nunez-Iglesias wrote: > > I've used as

Re: [Numpy-discussion] Make as_strided result writeonly

I've used as_strided before to create an "endless" output array when I didn't care about the result of an operation, just the side effect. See eg here . So I would certainly like option to remain to get a wri

Re: [Numpy-discussion] deprecating assignment to ndarray.data

Does this apply in any way to the .data attribute in scipy.sparse matrices? I fiddle with that quite often! On Fri, Jan 22, 2016 at 11:21 AM, Nathaniel Smith wrote: > So it turns out that ndarray.data supports assignment at the Python > level, and what it does is just assign to the ->data field

Re: [Numpy-discussion] Why does np.repeat build a full array?

On Tue, Dec 15, 2015 at 8:29 PM, Sebastian Berg wrote: > Actually, your particular use-case is covered by the new `broadcast_to` > function. > So it is! Fascinating, thanks for pointing that out! =) ___ NumPy-Discussion mailing list NumPy-Discussion@sc

[Numpy-discussion] Why does np.repeat build a full array?

rs of elements using sparse.coo_matrix. It occurred to me that numpy might have a similar function, and found np.repeat. But it seems that repeat actually creates the full, replicated array, rather than using stride tricks to keep it small. Is there any reason for this? Thanks!

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

Hey Nathaniel, Fascinating! Thanks for the primer! I didn't know that it would check dtype of values in the whole array. In that case, I would agree that it would be bad to infer it magically from just the first value, and this can be left to the users. Thanks! Juan. On Sat, Dec 12, 2015

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

actly the expected result for np.array('foo'), but I guess that's just me. Juan. On Sat, Dec 12, 2015 at 10:12 AM, Nathaniel Smith wrote: > Constructing an array from an iterator is fundamentally different from > constructing an array from an in-memory data structure li

Re: [Numpy-discussion] Proposal for a new function: np.moveaxis

I'm just a lowly user, but I'm a fan of this. +1! On Thu, Nov 5, 2015 at 6:42 PM, Stephan Hoyer wrote: > I've put up a pull request implementing a new function, np.moveaxis, as an > alternative to np.transpose and np.rollaxis: > https://github.com/numpy/numpy/pull/6630 > This functionality has b

Re: [Numpy-discussion] [announce] matplotlib 1.5.0 released

Yay! I have been eagerly awaiting this! =D Thank you everyone! On Fri, Oct 30, 2015 at 2:44 PM, Thomas Caswell wrote: > Hey all, > We are pleased to finally announce the release of matplotlib 1.5.0! It has > been over a year since the last feature release and we have had over 230 > people contr

Re: [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

Thanks, Jerome! I’ve added it to my to-watch list. It sounds really useful! Juan. On Wed, Oct 28, 2015 at 6:36 PM, Jerome Kieffer wrote: > On Tue, 27 Oct 2015 15:35:50 -0700 (PDT) > "Juan Nunez-Iglesias" wrote: >> Can someone here who understands more about distribut

Re: [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

Thanks Ralf! The pointer to Python Packaging User Guide is already gold! (But a wider discussion e.g. in the NumPy repo, mirroring the docstring conventions, would also be good!) On Wed, Oct 28, 2015 at 10:02 AM, Ralf Gommers wrote: > On Tue, Oct 27, 2015 at 11:35 PM, Juan Nunez-Igles

Re: [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

to learn can get quick pointers. Since there is a *ton* of material online telling us *to use* python setup.py install, all the time, it would be extremely helpful for the community if discussions such as this one helped to bubble up the Right Way of doing Python packaging and distribution. Th

Re: [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

Is there a pip equivalent of "python setup.py develop"? On Tue, Oct 27, 2015 at 5:33 PM Charles R Harris wrote: > On Tue, Oct 27, 2015 at 12:08 AM, Nathaniel Smith wrote: > >> On Mon, Oct 26, 2015 at 11:03 PM, Charles R Harris >> wrote: >> > >> [...] >> > I gave it a shot the other day. Pip ke

Re: [Numpy-discussion] Nansum function behavior

is None:         return np.nanmean(ar)     else:         return np.nanmean(ar, axis=axis) * ar.shape[axis] nanmean _consistently_ returns nans when encountering nan-only values because the mean of nothing is nan (the sum of nothing divided by the length of nothing, ie 0/0). Hope this helps...

Re: [Numpy-discussion] Fwd: Numpy for data manipulation

It will still have to a nice png, but you get an interactive figure when it is live. You just blew my mind. =D +1 to Python 3 and aliasing numpy as np.___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/list

Re: [Numpy-discussion] Change default order to Fortran order

o think of your images as (plane, row, column) instead of (x, y, z). The syntax actually becomes friendlier too. For example, to do something to each slice of data, you do: for plane in image: plane += foo instead of for z in image.shape[2]: image[:, :, z] += foo for example. Juan.

Re: [Numpy-discussion] Extracting individual columns in Numpy (suchith)

[3]: a = np.array([[1,2,3],[4,5,6],[7,8,9]]) In [4]: a[0][:] Out[4]: array([1, 2, 3]) In [5]: a[:][0] Out[5]: array([1, 2, 3]) In [6]: a[0,:] Out[6]: array([1, 2, 3]) In [7]: a[:,0] Out[7]: array([1, 4, 7]) Syntax is different for numpy arrays. Regards, Juan

Re: [Numpy-discussion] ANN: SciPy 0.13.0 release

istian Brueffer + * Lars Buitinck * Evgeni Burovski + * Tim Cera * Lawrence Chan + * David Cournapeau * Draz?en Luc?anin + * Alexander J. Dunlap + * endolith * André Gaul + * Christoph Gohlke * Ralf Gommers * Alex Griffing + * Blake Griffith + * Charles Harris * Bob Helmbold + * Andreas Hilboll * Ka

Re: [Numpy-discussion] Deprecation of financial routines

(being on a subpackage or not) and attract people to actually use them (I would bet very few are doing so as of now), then great! My proposal is moving them to a separate subpackage as a first step to their disappearance. Maybe when someone sees the move and/or the deprecation not

[Numpy-discussion] Are NEPs still a thing?

The subject speaks for itself, I was diving into NumPy source code and saw some NEPs, and I wonder if there still function as a mechanism to propose changes to NumPy, and if it is documented somewhere. ___ NumPy-Discussion mailing list NumPy-Discussion@

Re: [Numpy-discussion] Right way to build Fortran 90 module using numpy.distutils

El 27/08/2013 21:21, "Kyle Mandli" escribió: > > On Tue, Aug 27, 2013 at 1:26 PM, Juan Luis Cano wrote: >> >> >> El 27/08/2013 17:27, "Kyle Mandli" escribió: >> >> >> > >> > On Tue, Aug 27, 2013 at 6:46 AM, Juan Luis Ca

Re: [Numpy-discussion] Right way to build Fortran 90 module using numpy.distutils

El 27/08/2013 17:27, "Kyle Mandli" escribió: > > On Tue, Aug 27, 2013 at 6:46 AM, Juan Luis Cano wrote: >> >> I'm having some problems to properly build a module written in Fortran >> 90 using numpy.distutils. It only contains one subroutine, but: >>

[Numpy-discussion] Right way to build Fortran 90 module using numpy.distutils

(part of the rewrite of odeint I'm doing in SciPy). Regards Juan Luis Cano ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Deprecation of financial routines

[clip] On 08/19/2013 01:34 PM, Alan G Isaac wrote: > On 8/19/2013 2:37 AM, Juan Luis Cano wrote: >> https://github.com/numpy/numpy/issues/2880 >> >> it was suggested that we deprecate and eventually remove the financial >> functions in NumPy > > It seems tha

[Numpy-discussion] Deprecation of financial routines

As now master is open for 1.9, following the discussion opened here https://github.com/numpy/numpy/issues/2880 it was suggested that we deprecate and eventually remove the financial functions in NumPy, because they pollute the main namespace and some are unimplemented. We could put them in a se

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On 05/01/2013 04:14 PM, Daπid wrote: > On 1 May 2013 03:36, Benjamin Root wrote: >> Are there any other functions that others feel are "missing" from numpy and >> would like to see for v1.8? Let's discuss them here. > I would like to have sincos, to compute sin and cos of the same number > faster

Re: [Numpy-discussion] Purpose of this list

On 02/15/2013 06:29 PM, Robert Kern wrote: > On Fri, Feb 15, 2013 at 3:58 PM, Juan Luis Cano wrote: >> Hello all, I have a brief question about the general purpose of >> Numpy-discussion. I suscribed a month ago more or less to keep an eye on >> NumPy development (and

[Numpy-discussion] Purpose of this list

arrive through the list are related to support. Whats is actually the scope/purpose of the list? I am not critizicing anyone, just asking for a clarification on this point, to manage my mail client filters etc. Best regards, Juan Luis Cano ___ NumPy

Re: [Numpy-discussion] f2py and openmp on mac os x with gfortran

Hi Brandt, I am on linux and see the same problem. It is solved (at least here) if you add at the end the library libgomp, i.e: f2py -c -m play play.f90 --fcompiler=gfortran --f90flags="-fopenmp" -lgomp Hope it helps, Juan > Hello, > I'm struggling to create ope

Re: [Numpy-discussion] saving incrementally numpy arrays

Thanks David, I'll look into it now. Regarding the allocation/deallocation times I think that is not an issue for me. The chunks are generated by a fortran routine that takes several minutes to run (I am collecting a few thousand points before saving to disk). They are approximately the same siz

Re: [Numpy-discussion] saving incrementally numpy arrays

nd all the rows without iterating over the numpy array. Someone knows what would be the "right" approach? I am looking for something simple, I do not need to keep the piece of table after I put into the h5file. Thanks in advance and regards, Juan --- On Tue, 8/11/09, Citi, Luca wrote:

Re: [Numpy-discussion] saving incrementally numpy arrays

Hi, again, I can confirm that you have to load multiple times. Also I do not see differences if using or not the f.seek line The following snippet gives the expected result. The problem is that that way I have to load as many times as I wrote. Besides that, it works. Thanks, Juan

Re: [Numpy-discussion] saving incrementally numpy arrays

les. Thanks and Best regards, Juan --- On Tue, 8/11/09, Keith Goodman wrote: > From: Keith Goodman > Subject: Re: [Numpy-discussion] saving incrementally numpy arrays > To: "Discussion of Numerical Python" > Date: Tuesday, August 11, 2009, 7:46 PM > On Tue, Aug 11, 2009 at

[Numpy-discussion] saving incrementally numpy arrays

e but building up a file of several Gbytes. I do not want to put into memory all previous data each time. Also I cannot wait until the program finishes, I must save partial results periodically. Thanks, any help will be appreciated Juan ___