Re: [Numpy-discussion] How to find indices of values in an array (indirect in1d) ?

On Mi, 2015-12-30 at 20:21 +0100, Nicolas P. Rougier wrote: > In the end, I’ve only the list comprehension to work as expected > > A = [0,0,1,3] > B = np.arange(8) > np.random.shuffle(B) > I = [list(B).index(item) for item in A if item in B] > > > But Mark's and Sebastian's methods do not seem t

Re: [Numpy-discussion] How to find indices of values in an array (indirect in1d) ?

On Mi, 2015-12-30 at 17:12 +0100, Nicolas P. Rougier wrote: > Thanks for the quick answers. I think I will go with the .index and > list comprehension. > But if someone finds with a vectorised solution for the numpy 100 > exercises... > Yeah, I doubt you can get very pretty, though maybe there is

Re: [Numpy-discussion] Dynamic array list implementation

On Mi, 2015-12-23 at 00:34 -0800, Stephan Hoyer wrote: > We have a type similar to this (a typed list) internally in pandas, > although it is restricted to a single dimension and far from feature > complete -- it only has .append and a .to_array() method for > converting to a 1d numpy array. Our ve

Re: [Numpy-discussion] numpy.power -> numpy.random.choice Probabilities don't sum to 1

On Sa, 2015-12-19 at 06:55 -0600, Andy Ray Terrel wrote: > A simple fix would certainly by pass the check in random.choice, but I > don't know how to get that. So let's focus on the summation. > > > I believe you are hitting an instability in summing small numbers as a > power to 10th order would

[Numpy-discussion] Introducing outer/orthonongal indexing to numpy

Hello all, sorry for cross posting (discussion should go to the numpy list). But I would like to get a bit of discussion on the introduction of (mostly) two new ways to index numpy arrays. This would also define a way for code working with different array-likes, some of which implement outer index

Re: [Numpy-discussion] array_equal too strict?

On Do, 2015-12-17 at 13:43 +, Nico Schlömer wrote: > Hi everyone, > > > I noticed a funny behavior in numpy's array_equal. The two arrays > ``` > a1 = numpy.array( > [3.14159265358979320], > dtype=numpy.float64 > ) > a2 = numpy.array( > [3.14159265358979329], > dtype=numpy

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

On Di, 2015-12-15 at 08:56 +0100, Sebastian Berg wrote: > On Di, 2015-12-15 at 17:49 +1100, Juan Nunez-Iglesias wrote: > > Hi, > > > > > > I've recently been using the following pattern to create arrays of a > > specific repeating value: > >

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

On Di, 2015-12-15 at 17:49 +1100, Juan Nunez-Iglesias wrote: > 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=

Re: [Numpy-discussion] Memory mapping and NPZ files

On Mi, 2015-12-09 at 15:51 +0100, Mathieu Dubois wrote: > Dear all, > > If I am correct, using mmap_mode with Npz files has no effect i.e.: > f = np.load("data.npz", mmap_mode="r") > X = f['X'] > will load all the data in memory. > My take on it is, that no, I do not want implicit extraction/cop

Re: [Numpy-discussion] Inconsistent/unexpected indexing semantics

On Mo, 2015-11-30 at 18:42 +0100, Lluís Vilanova wrote: > Hi, > > TL;DR: There's a pending pull request deprecating some behaviour I find >unexpected. Does anyone object? > > Some time ago I noticed that numpy yields unexpected results in some very > specific cases. An array can be used t

Re: [Numpy-discussion] Indexing NEP draft

- Sebastian [1] Modulo possible bugs, there is not test suit yet On Mi, 2015-11-11 at 11:02 +0100, Sebastian Berg wrote: > Hi all, > > at scipy discussing with Nathaniel and others, we thought that maybe we > can push for orthogonal type indexing into numpy. Now with the ne

Re: [Numpy-discussion] understanding buffering done when broadcasting

On Di, 2015-11-24 at 16:49 -0800, Eli Bendersky wrote: > > > On Mon, Nov 23, 2015 at 2:09 PM, Sebastian Berg > wrote: > On Mo, 2015-11-23 at 13:31 -0800, Eli Bendersky wrote: > > Hello, > > > > > > I'm trying t

Re: [Numpy-discussion] understanding buffering done when broadcasting

On Mo, 2015-11-23 at 13:31 -0800, Eli Bendersky wrote: > Hello, > > > I'm trying to understand the buffering done by the Numpy iterator > interface (the new post 1.6-one) when running ufuncs on arrays that > require broadcasting. Consider this simple case: > > In [35]: m = np.arange(16).reshape(

Re: [Numpy-discussion] reshaping array question

On Di, 2015-11-17 at 13:49 -0500, Neal Becker wrote: > Robert Kern wrote: > > > On Tue, Nov 17, 2015 at 3:48 PM, Neal Becker wrote: > >> > >> I have an array of shape > >> (7, 24, 2, 1024) > >> > >> I'd like an array of > >> (7, 24, 2048) > >> > >> such that the elements on the last dimension are

Re: [Numpy-discussion] reshaping array question

On Di, 2015-11-17 at 10:48 -0500, Neal Becker wrote: > I have an array of shape > (7, 24, 2, 1024) > > I'd like an array of > (7, 24, 2048) > > such that the elements on the last dimension are interleaving the elements > from the 3rd dimension > Which basically means you want to reshape with t

Re: [Numpy-discussion] loadtxt and usecols

On Di, 2015-11-10 at 17:39 +0100, Irvin Probst wrote: > On 10/11/2015 16:52, Daπid wrote: > > 42, is exactly the same as (42,) If you want a tuple of > > tuples, you have to do ((42,),), but then it raises: TypeError: list > > indices must be integers, not tuple. > > My bad, I wrote tha

[Numpy-discussion] Indexing NEP draft

= The current NEP draft: == Implementing intuitive and full featured advanced indexing ====== :Author: Sebastian Berg :Date: 2015-08-27 :Status: draft Executive summary = Advanced indexing with multiple a

Re: [Numpy-discussion] loadtxt and usecols

d only suggest that you also accept buffer interface objects or array_interface stuff. Which in this case is really unnecessary I think. - Sebastian > > Ben Root > > > On Tue, Nov 10, 2015 at 10:07 AM, Irvin Probst > wrote: > On 10/11/2015 14:17, Sebastian Berg

Re: [Numpy-discussion] loadtxt and usecols

On Di, 2015-11-10 at 10:24 +0100, Irvin Probst wrote: > On 10/11/2015 09:19, Sebastian Berg wrote: > > since a scalar row (so just one row) is read and not a 2D array. I tend > > to say it should be an array-like argument and not a generalized > > sequence argument, just wante

Re: [Numpy-discussion] loadtxt and usecols

On Mo, 2015-11-09 at 20:36 +0100, Ralf Gommers wrote: > > > On Mon, Nov 9, 2015 at 7:42 PM, Benjamin Root > wrote: > My personal rule for flexible inputs like that is that it > should be encouraged so long as it does not introduce > ambiguity. Furthermore, Allowing a scal

Re: [Numpy-discussion] isfortran compatibility in numpy 1.10.

I bet it has all been said already, but to note just in case. In numpy itself we use it mostly to determine the memory order of the *output* and not for safty purpose. That is the macro of course and I think yelling people to use flags.fnc in python is better. - Sebastian On Mon Nov 2 08:52:

Re: [Numpy-discussion] Commit rights for Jonathan J. Helmus

Congrats, both of you ;). On Sun Nov 1 04:30:27 2015 GMT+0330, Jaime Fernández del Río wrote: > "Gruetzi!", as I just found out we say in Switzerland... > On Oct 30, 2015 8:20 AM, "Jonathan Helmus" wrote: > > > On 10/28/2015 09:43 PM, Allan Haldane wrote: > > > On 10/28/2015 05:27 PM, Nathanie

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mo, 2015-10-19 at 01:34 -0400, josef.p...@gmail.com wrote: > > > It looks like in 1.9 it depends on the order of the 2-d arrays, which > it didn't do in 1.6 > Yes, it uses concatenate, and concatenate probably changed in 1.7 to use "K" (since "K" did not really exists before 1.7 IIRC). N

Re: [Numpy-discussion] Numpy 1.10.0 release

On Di, 2015-10-06 at 07:53 -0400, Neal Becker wrote: > 1 test failure: > > FAIL: test_blasdot.test_blasdot_used > -- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTe

Re: [Numpy-discussion] Sign of NaN

On Mi, 2015-09-30 at 09:11 -0700, Chris Barker wrote: > On Tue, Sep 29, 2015 at 6:35 PM, Charles R Harris > wrote: > For this, and other use-cases, special casing > Numpy arrays stored in object arrays does make > sense: >

Re: [Numpy-discussion] Sign of NaN

On Mi, 2015-09-30 at 00:01 -0700, Nathaniel Smith wrote: > On Tue, Sep 29, 2015 at 2:07 PM, Sebastian Berg > wrote: > > On Di, 2015-09-29 at 11:16 -0700, Nathaniel Smith wrote: > [...] > >> In general I'm not a big fan of trying to do all kinds of guessing > >&

Re: [Numpy-discussion] Sign of NaN

On Di, 2015-09-29 at 11:16 -0700, Nathaniel Smith wrote: > On Sep 29, 2015 8:25 AM, "Anne Archibald" wrote: > > > > IEEE 754 has signum(NaN)->NaN. So does np.sign on floating-point > arrays. Why should it be different for object arrays? > > The argument for doing it this way would be that arbitra

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

On Fr, 2015-09-25 at 14:15 +, Thomas Caswell wrote: > To respond to the devils advocate: > > > Creating this organizational framework is a one time boot-strapping > event. You could use wording like "The initial council will include > those who have made significant contributions to numpy i

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

On Mi, 2015-09-23 at 19:48 -0500, Travis Oliphant wrote: > > > On Wed, Sep 23, 2015 at 6:19 PM, Charles R Harris > wrote: > > > On Wed, Sep 23, 2015 at 3:42 PM, Chris Barker > wrote: > On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant >

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

On Do, 2015-09-24 at 10:03 -0700, Nathaniel Smith wrote: > On Sep 24, 2015 4:14 AM, "Sebastian Berg" > wrote: > > > > On Do, 2015-09-24 at 03:26 -0700, Stefan van der Walt wrote: > > > On 2015-09-24 00:17:33, Jens Jørgen Mortensen > wrote: > > &

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

On Do, 2015-09-24 at 10:45 +0200, Sebastian Berg wrote: > On Do, 2015-09-24 at 00:22 -0700, Nathaniel Smith wrote: > > On Wed, Sep 23, 2015 at 3:12 PM, Travis Oliphant > > wrote: > > >> > > >> Here is a list of the current Contributors to the main NumPy

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

On Do, 2015-09-24 at 13:14 +0200, Sebastian Berg wrote: > On Do, 2015-09-24 at 03:26 -0700, Stefan van der Walt wrote: > > On 2015-09-24 00:17:33, Jens Jørgen Mortensen wrote: > > > jensj@jordan:~$ python > > > Python 2.7.9 (default, Apr 2 2015, 15:33:21) > > &

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

ess feature maybe, since we can point to `.reshape(-1)` as well for those who do not care. As far as I can see a contiguous output was not guaranteed for "keeporder", but nobody probably ever used keeporder - Sebastian > > commit 44877b36870ec2a0505c536a30b9fbf06a414c17 >

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

should then be ravelled, so this is indeed a bug. > > If I bisected correctly, the problematic change is this one: > Yeah, vdot uses `ravel`. That is correct, but it should only use it after making sure the input is C-order, or make sure the output of ravel is C-order (vdot was changed t

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

On Mi, 2015-09-23 at 17:08 -0600, Charles R Harris wrote: > > > On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant > wrote: > > > Regarding the seed council, I just tried to pick an > objective > criterion and an arbitrary d

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

On Do, 2015-09-24 at 00:22 -0700, Nathaniel Smith wrote: > On Wed, Sep 23, 2015 at 3:12 PM, Travis Oliphant wrote: > >> > >> Here is a list of the current Contributors to the main NumPy repository: > >> > >> To become eligible to join the Steering Council, an individual must be a > >> Project Con

Re: [Numpy-discussion] Governance model request

On Wed Sep 23 12:39:59 2015 GMT+0200, Francesc Alted wrote: > Hi Fernando, > > I am happy that you decided to chime in here. This thread derailed in a > bad way and I hope that your wise words will help to redress the situation. > > In fact, I would like to propose you having part of a future st

[Numpy-discussion] Steering Committee Size

Hi, Trying to figure out at least a bit from the discussions. While I am happy with the draft, I wonder if someone has some insights about some questions: 1. How large crowds have examples of working well with apache style voting? 2. How large do we expect numpy steering council to be (I have a

Re: [Numpy-discussion] Governance model request

On Di, 2015-09-22 at 05:44 -0500, Travis Oliphant wrote: > > > On Tue, Sep 22, 2015 at 2:33 AM, Nathaniel Smith > wrote: > Hi Bryan, > > I understand where you're coming from, but I'd appreciate it > if we > could keep the discussion on a less visceral le

Re: [Numpy-discussion] Governance model request

On Mo, 2015-09-21 at 11:32 +0200, Sebastian Berg wrote: > On So, 2015-09-20 at 11:20 -0700, Travis Oliphant wrote: > > After long conversations at BIDS this weekend and after reading the > > entire governance document, I realized that the steering council is > > very large a

Re: [Numpy-discussion] Governance model request

On So, 2015-09-20 at 11:20 -0700, Travis Oliphant wrote: > After long conversations at BIDS this weekend and after reading the > entire governance document, I realized that the steering council is > very large and I don't agree with the mechanism by which it is > chosen. > Hmmm, well I never ha

Re: [Numpy-discussion] feature request - increment counter on write check

On Fr, 2015-09-11 at 06:00 -0700, Daniel wrote: > >...you would have to "notify" the array itself that it has changed.. > > I don't get what you mean..or maybe I do...? Do you mean that if there are > two arrays with non-overlapping views of the same data then modifying one > will change the mutab

Re: [Numpy-discussion] feature request - increment counter on write check

On Fr, 2015-09-11 at 13:10 +, Daniel Manson wrote: > Originally posted as issue 6301 on github. > > > Presumably any block of code that modifies an ndarray's buffer is > wrapped in a (thread safe?) check of the writable flag. Would it be > possible to hold a counter rather than a simple bool

Re: [Numpy-discussion] np.sign and object comparisons

On Mo, 2015-08-31 at 10:23 -0700, Stephan Hoyer wrote: > On Mon, Aug 31, 2015 at 1:23 AM, Sebastian Berg > wrote: > That would be my gut feeling as well. Returning `NaN` could > also make > > sense, but I guess we run into problems si

Re: [Numpy-discussion] np.sign and object comparisons

On So, 2015-08-30 at 21:09 -0700, Jaime Fernández del Río wrote: > There's been some work going on recently on Py2 vs Py3 object > comparisons. If you want all the background, see gh-6265 and follow > the links there. > > > There is a half baked PR in the works, gh-6269, that tries to unify > beh

Re: [Numpy-discussion] Numpy FFT.FFT slow with certain samples

If you don't mind the extra dependency or licensing and this is an issue for you, you can try pyfftw (there are likely other similar projects) which wraps fftw and does not have this problem as far as I know. It exposes a numpy-like interface. - sebastian On Fr, 2015-08-28 at 19:13 +, Joseph

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Fr, 2015-08-28 at 09:46 +0100, Matthew Brett wrote: > Hi, > > On Fri, Aug 28, 2015 at 5:59 AM, Jaime Fernández del Río > wrote: > > On Thu, Aug 27, 2015 at 11:06 AM, Matthew Brett > > wrote: > >> > >> Hi, > >> > >> On Thu, Aug 27, 2015 at 6:23 PM, wrote: > >> > > >> > > >> > On Thu, Aug 27,

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Do, 2015-08-27 at 12:34 -0700, Stefan van der Walt wrote: > On 2015-08-27 11:06:10, Matthew Brett > wrote: > > So, in the spirit of fruitful discussion, can I ask what y'all > > consider to be the current problems with working on numpy (other > > than the technical ones). What is numpy doi

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Do, 2015-08-27 at 17:22 +0100, Matthew Brett wrote: > Hi > > On Thu, Aug 27, 2015 at 5:11 PM, wrote: > > > > > > On Thu, Aug 27, 2015 at 11:04 AM, Matthew Brett > > wrote: > >> > >> Hi, > >> > >> On Thu, Aug 27, 2015 at 3:34 PM, wrote: > >> [snip] > >> > I don't really see a problem with "

Re: [Numpy-discussion] 1.10.0rc1

bit more clear if you like I guess). - Sebastian > > Ben Root > > > On Thu, Aug 27, 2015 at 10:44 AM, Sebastian Berg > wrote: > On Do, 2015-08-27 at 08:04 -0600, Charles R Harris wrote: > > > > >

Re: [Numpy-discussion] 1.10.0rc1

On Do, 2015-08-27 at 08:04 -0600, Charles R Harris wrote: > > > On Thu, Aug 27, 2015 at 7:52 AM, Benjamin Root > wrote: > > > Ok, I tested matplotlib master against numpy master, and there > were no errors. I did get a bunch of new deprecation warnings >

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Do, 2015-08-27 at 10:45 +0100, Matthew Brett wrote: > Hi, > > On Thu, Aug 27, 2015 at 10:35 AM, Bryan Van de Ven > wrote: > > > >> On Aug 27, 2015, at 10:22 AM, Matthew Brett > >> wrote: > >> > >> In the case of the 'core' model, we have some compelling testimony > >> from someone with a gr

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

On Mi, 2015-08-26 at 00:05 -0700, Nathaniel Smith wrote: > On Tue, Aug 25, 2015 at 5:53 PM, David Cournapeau wrote: > > Thanks for the good summary Nathaniel. > > > > Regarding dtype machinery, I agree casting is the hardest part. Unless the > > code has changed dramatically, this was the main rea

Re: [Numpy-discussion] Numpy helper function for __getitem__?

On So, 2015-08-23 at 11:08 -0700, Stephan Hoyer wrote: > I don't think NumPy has a function like this (at least, not exposed to > Python), but I wrote one for xray, "expanded_indexer", that you are > welcome to borrow: > https://github.com/xray/xray/blob/v0.6.0/xray/core/indexing.py#L10 > > Yeah

Re: [Numpy-discussion] Numpy 1.11

On So, 2015-08-16 at 14:04 -0600, Charles R Harris wrote: > Hi All, > > > While waiting for Christoph to drop the other shoe on 1.10.0b1, I > thought I'd try again to start a discussion on the 1.11 release. If we > want to get the next release out in a timely manner there should be > some advance

Re: [Numpy-discussion] Multiarray API size mismatch 301 302?

So as Julian helped me, it was the wrong style of the function, the curly bracket has to go on the next line for the API generation to pick it up. - Sebastian On Do, 2015-08-13 at 20:42 +0200, Sebastian Berg wrote: > On Do, 2015-08-13 at 14:36 -0400, Benjamin Root wrote: > > Did you

Re: [Numpy-discussion] Multiarray API size mismatch 301 302?

On Do, 2015-08-13 at 14:36 -0400, Benjamin Root wrote: > Did you do a "git clean -fxd" before re-installing? > Yup. > > On Thu, Aug 13, 2015 at 2:34 PM, Sebastian Berg > wrote: > Hey, > > just for hacking/

[Numpy-discussion] Multiarray API size mismatch 301 302?

Hey, just for hacking/testing, I tried to add to shape.c: /*NUMPY_API * * Checks if memory overlap exists */ NPY_NO_EXPORT int PyArray_ArraysShareMemory(PyArrayObject *arr1, PyArrayObject *arr2, int work) { return solve_may_share_memory(arr1, arr2, work); } and to numpy_api.py: #

Re: [Numpy-discussion] Development workflow (not git tutorial)

On Do, 2015-08-13 at 15:52 +, Anne Archibald wrote: > Hi, > > > What is a sensible way to work on (modify, compile, and test) numpy? > > > There is documentation about "contributing to numpy" at: > http://docs.scipy.org/doc/numpy-dev/dev/index.html > > and: > http://docs.scipy.org/doc/num

Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

On Mi, 2015-08-12 at 01:07 -0700, Nathaniel Smith wrote: > On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg > wrote: > > On Mi, 2015-08-12 at 09:41 +0200, Jens Jørgen Mortensen wrote: > >> On 08/11/2015 11:23 PM, Charles R Harris wrote: > >> > Hi All, > >&

Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

On Mi, 2015-08-12 at 09:41 +0200, Jens Jørgen Mortensen wrote: > On 08/11/2015 11:23 PM, Charles R Harris wrote: > > Hi All, > > > > give this release a whirl and report any problems either on the > > numpy-discussion list or by opening an issue on github. > > > > I'm pleased to announce the firs

Re: [Numpy-discussion] np.in1d() & sets, bug?

On Mo, 2015-08-10 at 12:09 -0400, Benjamin Root wrote: > Just came across this one today: > > >>> np.in1d([1], set([0, 1, 2]), assume_unique=True) > array([ False], dtype=bool) > > >>> np.in1d([1], [0, 1, 2], assume_unique=True) > > array([ True], dtype=bool) > > > I am assuming this has somet

Re: [Numpy-discussion] Shared memory check on in-place modification.

is not an easy problem. > On Tuesday, July 28, 2015, Sebastian Berg > wrote: > > > > On Mon Jul 27 22:51:52 2015 GMT+0200, Sturla Molden wrote: > > On 27/07/15 22:10, Anton Akhmerov wrote: > > > Hi everyone, > > &g

Re: [Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

On Di, 2015-08-04 at 05:57 -0400, josef.p...@gmail.com wrote: > > > On Tue, Aug 4, 2015 at 4:39 AM, Sebastian Berg > wrote: > On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > > On 03/08/15 20:51, Chris Barker wrote: > > >

Re: [Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > On 03/08/15 20:51, Chris Barker wrote: > > > well, IIUC, np.int is the python integer type, which is > > a C long in all the implemtations of cPython that I know about -- but is > > that a guarantee?in the future as well? >

Re: [Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > On 03/08/15 20:51, Chris Barker wrote: > > > well, IIUC, np.int is the python integer type, which is > > a C long in all the implemtations of cPython that I know about -- but is > > that a guarantee?in the future as well? >

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

On Mon Aug 3 16:26:10 2015 GMT+0200, Matthew Brett wrote: > Hi, > > On Mon, Aug 3, 2015 at 3:13 PM, Gregory Lee wrote: > > I agree that often you don't need to worry about the memory order. However, > > it is not uncommon in medical imaging to go back and forth between a 2D or > > 3D image repre

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

On Mon Aug 3 10:49:35 2015 GMT+0200, Matthew Brett wrote: > Hi, > > On Mon, Aug 3, 2015 at 8:09 AM, Nathaniel Smith wrote: > > On Aug 2, 2015 11:06 PM, "Kang Wang" wrote: > >> > >> This is very good discussion. Thank you all for replying. > >> > >> I can see the fundamental difference is that I

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

Well, numpy has a tendency to prefer C order. There is nothing you can do about that really. But you just cannot be sure what you get in some cases. Often you need something specific for interfaceing other code. But in that case quite often you also do not need to fear the copy. - Sebastian

Re: [Numpy-discussion] np.nonzero - order guarantees?

On Tue Jul 28 18:18:01 2015 GMT+0200, Matthew Brett wrote: > On Tue, Jul 28, 2015 at 4:45 PM, Sebastian Berg > wrote: > > Yes, I think it is guaranteed C order in the results. > > > > > > On Mon Jul 27 14:05:01 2015 GMT+0200, Matthew Brett wrote: > >> Hi, &

Re: [Numpy-discussion] Shared memory check on in-place modification.

On Mon Jul 27 22:51:52 2015 GMT+0200, Sturla Molden wrote: > On 27/07/15 22:10, Anton Akhmerov wrote: > > Hi everyone, > > > > I have encountered an initially rather confusing problem in a piece of > > code that attempted to symmetrize a matrix: `h += h.T` > > The problem of course appears due to

Re: [Numpy-discussion] np.nonzero - order guarantees?

Yes, I think it is guaranteed C order in the results. On Mon Jul 27 14:05:01 2015 GMT+0200, Matthew Brett wrote: > Hi, > > `np.nonzero` for a 2D array `A` returns: > > row_inds, col_inds = np.nonzero(A) > > I notice that `row_inds` appears to be sorted by value, and `col_inds` > appears to be

Re: [Numpy-discussion] floats for indexing, reshape - too strict ?

On Mi, 2015-07-01 at 10:05 -0400, josef.p...@gmail.com wrote: > About the deprecation warning for using another type than integers, in > ones, reshape, indexing and so on: > > > Wouldn't it be nicer to accept floats that are equal to an integer? > Hmmm, the biggest point was that the old soluti

Re: [Numpy-discussion] I can't tell if Numpy is configured properly with show_config()

On Fr, 2015-06-19 at 16:19 -0500, Elliot Hallmark wrote: > Debian Sid, 64-bit. I was trying to fix the problem of np.dot running > very slow. > > > I ended up uninstalling numpy, installing libatlas3-base through > apt-get and re-installing numpy. The performance of dot is greatly > improved!

Re: [Numpy-discussion] Flag for np.tile to use as_strided to reduce memory

On Fr, 2015-06-19 at 10:06 +0200, Freddy Rietdijk wrote: > Hi, > > > Having read that it is possible to basically 'copy' elements along an > axis without actually copying the values by making use of the strides, > I wonder whether it is possible to add this as an option to np.tile. > No, what t

Re: [Numpy-discussion] Python 3 and isinstance(np.int64(42), int)

In some cases calling operator.index(n) may yield the desired result. I like operator.index, but maybe it is just me :). That uses duck typing instead of instance checking to ask if it represents an integer. But it also has some awkward corner cases in numpy, since arrays with a single element (dep

Re: [Numpy-discussion] Open CV 3.0 + NPY_RELAXED_STRIDES

On Mi, 2015-06-10 at 21:03 -0600, Charles R Harris wrote: > > > > > * Relaxed stride checking will be the default in 1.10.0 > Is this still the plan? > > > Yes, but it won't be quite the same as the master branch. Currently > an unusual value for the st

Re: [Numpy-discussion] DEP: Deprecate boolean array indices with non-matching shape #4353

On Fr, 2015-06-05 at 08:36 -0400, josef.p...@gmail.com wrote: > > > What is actually being deprecated? > It looks like there are different examples. > > > wrong length: Nathaniels first example above, where the mask is not > broadcastable to original array because mask is longer or shorter tha

Re: [Numpy-discussion] variable end border in arrays

On Fr, 2015-06-05 at 15:17 +0800, Pablo wrote: > Hi, > If I want to remove 1 element in the beginning and the end of a numpy > array "x" we do: > > x[1:-1] > > Now, if we have a border variable, and borders are allowed to be zero > (which means no border), numpy syntax is inconvenient. For exam

Re: [Numpy-discussion] DEP: Deprecate boolean array indices with non-matching shape #4353

On Do, 2015-06-04 at 18:04 -0700, Nathaniel Smith wrote: > On Thu, Jun 4, 2015 at 5:57 PM, Nathaniel Smith wrote: > > So specifically the question is -- if you have an array with five > items, and > > a Boolean array with three items, then currently you can use the > later to > > index the former:

Re: [Numpy-discussion] Chaining apply_over_axis for multiple axes.

On Mo, 2015-05-25 at 21:02 +1000, Andrew Nelson wrote: > I have a function that operates over a 1D array, to return an array of > a similar size. To use it in a 2D fashion I would have to do > something like the following: > > > for row in range(np.size(arr, 0): > arr_out[row] = func(arr[row

Re: [Numpy-discussion] Should ndarray subclasses support the keepdims arg?

On Di, 2015-05-05 at 11:13 -0400, Allan Haldane wrote: > Hello all, > > A question: > > Many ndarray methods (eg sum, mean, any, min) have a "keepdims" keyword > argument, but ndarray subclass methods sometimes don't. The 'matrix' > subclass doesn't, and numpy functions like 'np.sum' intentionall

Re: [Numpy-discussion] performance of numpy.array()

There was a major improvement to np.array in some cases. You can probably work around this by using np.concatenate instead of np.array in your case (depends on the usecase, but I will guess you have code doing: np.array([arr1, arr2, arr3]) or similar. If your use case is different, you may be ou

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fr, 2015-04-17 at 15:18 -0400, josef.p...@gmail.com wrote: > On Fri, Apr 17, 2015 at 2:56 PM, Sebastian Berg > > Hehe, yeah, that difference. But if you really want that, you can > > usually do a1[0, 1, ...] if you don't mind the ugliness. > > I'm not sure wh

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fr, 2015-04-17 at 20:56 +0200, Sebastian Berg wrote: > On Fr, 2015-04-17 at 12:40 -0400, josef.p...@gmail.com wrote: > > On Fri, Apr 17, 2015 at 12:16 PM, Neil Girdhar > > wrote: > > > > > > > > > On Fri, Apr 17, 2015 at 12:09 PM, wrote: > >

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

>> > > >> > > >> > On Fri, Apr 17, 2015 at 10:47 AM, wrote: > >> >> > >> >> On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg > >> >> wrote: > >> >> > On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wro

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fr, 2015-04-17 at 10:47 -0400, josef.p...@gmail.com wrote: > On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg > wrote: > > On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wrote: > >> Hi, > >> > > > >> > >> So, how about a slight modific

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wrote: > Hi, > > > So, how about a slight modification of your proposal? > > 1) Raise deprecation warning for np.outer for non 1D arrays for a few > versions, with depraction in favor of np.multiply.outer, then > 2) Raise error for np.outer on non

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

Just a general thing, if someone has a few minutes, I think it would make sense to add the ufunc.reduce thing to all of these functions at least in the "See Also" or "Notes" section in the documentation. These special attributes are not that well known, and I think that might be a nice way to make

Re: [Numpy-discussion] Non-meta indexing improvements discussion

On Do, 2015-04-09 at 08:50 +0200, Sebastian Berg wrote: > Hi all, > > Let me take a shot at summing up some suggestions to make the indexing > less surprising, and maybe we can gather some more in a more > concentrated way now. > Did not want to comment on the first ma

Re: [Numpy-discussion] On responding to dubious ideas (was: Re: Advanced indexing: "fancy" vs. orthogonal)

On Do, 2015-04-09 at 02:22 -0400, Nathaniel Smith wrote: > On Wed, Apr 8, 2015 at 4:02 PM, Alan G Isaac wrote: > > 1. I use numpy in teaching. > > I have never heard a complaint about its indexing behavior. > > Have you heard such complaints? > > Some observations: > > 1) There's an unrelated th

[Numpy-discussion] Non-meta indexing improvements discussion

Hi all, Let me take a shot at summing up some suggestions to make the indexing less surprising, and maybe we can gather some more in a more concentrated way now. 1. Implement something like `arr.fancy_index[...]` and `arr.ortho_index[...]` (i.e. Jaimes PR is the start for trying this) 2. Add war

[Numpy-discussion] SIAM meeting in Snowbird anyone?

Hey, since I am not in the US often and the SIAM conference is pretty large, I was wondering if some more of our community will be at the SIAM conference in Snowbird around May 17th-21st and would like to meet up then. - Sebastian signature.asc Description: This is a digitally signed message pa

Re: [Numpy-discussion] Multidimensional Indexing

On Di, 2015-04-07 at 00:49 +0100, Nicholas Devenish wrote: > With the indexing example from the documentation: > > y = np.arange(35).reshape(5,7) > > Why does selecting an item from explicitly every row work as I’d expect: > >>> y[np.array([0,1,2,3,4]),np.array([0,0,0,0,0])] > array([ 0, 7, 14,

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On So, 2015-04-05 at 14:13 +0200, Sebastian Berg wrote: > On So, 2015-04-05 at 00:45 -0700, Jaime Fernández del Río wrote: > > On Fri, Apr 3, 2015 at 10:59 AM, Jaime Fernández del Río > > > > > > > A PR it is, #5749 to be precise. I think it has all the be

Re: [Numpy-discussion] NPY_SEPARATE_COMPILATION and RELAXED_STRIDES_CHECKING

On So, 2015-04-05 at 07:08 -0600, Charles R Harris wrote: > > > On Sun, Apr 5, 2015 at 4:37 AM, Sebastian Berg > wrote: > On Fr, 2015-04-03 at 21:00 -0600, Charles R Harris wrote: > > Hi All, > > > > > > Just to

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On So, 2015-04-05 at 00:45 -0700, Jaime Fernández del Río wrote: > On Fri, Apr 3, 2015 at 10:59 AM, Jaime Fernández del Río > > > A PR it is, #5749 to be precise. I think it has all the bells and > whistles: integers, boolean and integer 1-D arrays, slices, ellipsis, > and even newaxis, both fo

Re: [Numpy-discussion] NPY_SEPARATE_COMPILATION and RELAXED_STRIDES_CHECKING

On Fr, 2015-04-03 at 21:00 -0600, Charles R Harris wrote: > Hi All, > > > Just to raise the question if these two options should be removed at > some point? The current default value for both is 0, so we have > separate compilation and relaxed strides checking by default. > I still have some sm

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Do, 2015-04-02 at 01:29 -0700, Stephan Hoyer wrote: > On Wed, Apr 1, 2015 at 7:06 AM, Jaime Fernández del Río > wrote: > Is there any other package implementing non-orthogonal > indexing aside from numpy? > > > I think we can safely say that NumPy's implementation of broadcast

Re: [Numpy-discussion] How to Force Storage Order

On Di, 2015-03-31 at 07:11 +, Ian Henriksen wrote: > On Tue, Mar 31, 2015, 12:50 AM Klemm, Michael > wrote: > > > Dear all, > > I have found a bug in one of my codes and the way it passes a > Numpy matrix to MKL's dgemm routine. Up to now I was assuming >

<    1   2   3   4   5   >