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

Hi Kang, Feel free to come chat about your application on the scikit-image list [1]! I'll note that we've been through the array order discussion many times there and even have a doc page about it [2]. The short version is that you'll save yourself a lot of pain by starting to think of your

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

Re: [Numpy-discussion] Nansum function behavior

Hi Charles, Just providing an outsider's perspective... Your specific use-case doesn't address the general definition of nansum: perform a sum while ignoring nans. As others have pointed out, (especially in the linked thread) the sum of nothing is 0. Although the current behaviour of

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

Can someone here who understands more about distribution maybe write a blog post detailing: - why these setup.py commands are bad - which alternative corresponds to each command and why it's better - where to find information about this For example, I had never heard of "twine", and

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

11:35 PM, Juan Nunez-Iglesias <jni.s...@gmail.com> > wrote: >> Can someone here who understands more about distribution maybe write a >> blog post detailing: >> >> - why these setup.py commands are bad >> - which alternative corresponds to each command and why

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 <jerome.kief...@esrf.fr> wrote: > On Tue, 27 Oct 2015 15:35:50 -0700 (PDT) > "Juan Nunez-Iglesias" <jni.s...@gmail.com> wrote: >>

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

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

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

Hi, I've recently been using the following pattern to create arrays of a specific repeating value: from numpy.lib.stride_tricks import as_strided value = np.ones((1,), dtype=float) arr = as_strided(value, shape=input_array.shape, strides=(0,)) I can then use arr e.g. to count certain pairs of

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

Nathaniel, > IMO this is better than making np.array(iter) internally call list(iter) or equivalent Yeah but that's not the only option: from itertools import chain def fromiter_awesome_edition(iterable): elem = next(iterable) dtype = whatever_numpy_does_to_infer_dtypes_from_lists(elem)

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

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

:00 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Fri, Dec 11, 2015 at 11:32 PM, Juan Nunez-Iglesias > <jni.s...@gmail.com> wrote: > > Nathaniel, > > > >> IMO this is better than making np.array(iter) internally call list(iter) > >> or equiva

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] 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,

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

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

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

Re: [Numpy-discussion] Make as_strided result writeonly

hat 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 <sebast...@sipsolutions.net> wrote: > On So, 2016-01-24 at 13:00 +1100, Juan Nunez-Iglesias wrote: >

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

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

ode-base. > However, it has been deprecated in favor of randint. > > On Wed, Feb 17, 2016 at 11:48 PM, Juan Nunez-Iglesias <jni.s...@gmail.com> > wrote: > >> Also fwiw, I think the 0-based, half-open interval is one of the best >> features of Python indexing and y

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 <alan.is...@gmail.com> 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

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 <alan.is...@gmail.com> wrote: > On 2/17/2016 7:01 PM, Juan Nunez-Iglesias wrote: > >> Notice the limitation "1D array

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:

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

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 >

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

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

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

We use np.at_least2d extensively in scikit-image, and I also use it in a *lot* of my own code now that scikit-learn stopped accepting 1D arrays as feature vectors. > what is the advantage of np.at_leastnd` over `np.array(a, copy=False, ndim=n)` Readability, clearly. My only concern is the

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

Hey Skip, Any way that you can make your keys numeric? Then you can run np.diff on that first column, and use the indices of nonzero entries (np.flatnonzero) to know where values change. With a +1/-1 offset (that I am too lazy to figure out right now ;) you can then index into the original rows

Re: [Numpy-discussion] ANN: NumExpr3 Alpha

Hi everyone, Thanks for this. It looks absolutely fantastic. I've been putting off using numexpr but it looks like I don't have a choice anymore. ;) Regarding feature requests, I've always found it off putting that I have to wrap my expressions in a string to speed them up. Has anyone explored

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

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

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 <warren.weckes...@gmail.com>, wrote: > > > > On Wed, Mar 8, 2017 at 9:48 PM, Juan Nunez-Iglesias <jni.s...@gmail.com> > > wrot

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

I was a bit surprised to discover that both meshgrid nor mgrid return fully instantiated arrays, when simple broadcasting (ie with stride=0 for other axes) is functionally identical and happens much, much faster. I wrote my own function to do this: def broadcast_mgrid(arrays):     shape =

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

gt; > In [9]: %timeit np.meshgrid(np.arange(512), np.arange(512), copy=False, > indexing='ij') > 1 loops, best of 3: 23 µs per loop > > Best regards > Per A. Brodtkorb > > From: NumPy-Discussion [mailto:numpy-discussion-boun...@scipy.org] On Behalf > Of Juan Nunez-Igles