Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
03.04.2015, 04:09, josef.p...@gmail.com kirjoitti: [clip] I think numpy indexing is not too difficult and follows a consistent pattern, and I completely avoid mixing slices and index arrays with ndim 2. I think it should be DOA, except as a discussion topic for numpy 3000. If you change how Numpy indexing works, you need to scrap a nontrivial amount of existing code, at which point everybody should just go back to Matlab, which at least provides a stable API. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
I have an all-Pyhton implementation of an OrthogonalIndexer class, loosely based on Stephan's code plus some axis remapping, that provides all the needed functionality for getting and setting with orthogonal indices. Would those interested rather see it as a gist to play around with, or as a PR adding an orthogonally indexable `.ix_` argument to ndarray? Jaime -- (\__/) ( O.o) ( ) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Fri, Apr 3, 2015 at 10:59 AM, Jaime Fernández del Río jaime.f...@gmail.com wrote: I have an all-Pyhton implementation of an OrthogonalIndexer class, loosely based on Stephan's code plus some axis remapping, that provides all the needed functionality for getting and setting with orthogonal indices. Awesome, thanks! Would those interested rather see it as a gist to play around with, or as a PR adding an orthogonally indexable `.ix_` argument to ndarray? My preference would be for a PR (even if it's purely a prototype) because it supports inline comments better than a gist. Stephan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On 2015/04/03 7:59 AM, Jaime Fernández del Río wrote: I have an all-Pyhton implementation of an OrthogonalIndexer class, loosely based on Stephan's code plus some axis remapping, that provides all the needed functionality for getting and setting with orthogonal indices. Excellent! Would those interested rather see it as a gist to play around with, or as a PR adding an orthogonally indexable `.ix_` argument to ndarray? I think the PR would be easier to test. Eric Jaime -- (\__/) ( O.o) ( ) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NPY_SEPARATE_COMPILATION and RELAXED_STRIDES_CHECKING
On Fri, Apr 3, 2015 at 9:00 PM, Charles R Harris charlesr.har...@gmail.com 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. Oops, default value is 1, not 0. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Apr 1, 2015 2:17 AM, R Hattersley rhatters...@gmail.com wrote: There are two different interpretations in common use of how to handle multi-valued (array/sequence) indexes. The numpy style is to consider all multi-valued indices together which allows arbitrary points to be extracted. The orthogonal style (e.g. as provided by netcdf4-python) is to consider each multi-valued index independently. For example: type(v) type 'netCDF4.Variable' v.shape (240, 37, 49) v[(0, 1), (0, 2, 3)].shape (2, 3, 49) np.array(v)[(0, 1), (0, 2, 3)].shape Traceback (most recent call last): File stdin, line 1, in module IndexError: shape mismatch: indexing arrays could not be broadcast together with shapes (2,) (3,) In a netcdf4-python GitHub issue the authors of various orthogonal indexing packages have been discussing how to distinguish the two behaviours and have currently settled on a boolean __orthogonal_indexing__ attribute. I guess my feeling is that this attribute is a fine solution to the wrong problem. If I understand the situation correctly: users are writing two copies of their indexing code to handle two different array-duck-types (those that do broadcasting indexing and those that do Cartesian product indexing), and then have trouble knowing which set of code to use for a given object. The problem that __orthogonal_indexing__ solves is that it makes easier to decide which code to use. It works well for this, great. But, the real problem here is that we have two different array duck types that force everyone to write their code twice. This is a terrible state of affairs! (And exactly analogous to the problems caused by np.ndarray disagreeing with np.matrix scipy.sparse about the the proper definition of *, which PEP 465 may eventually alleviate.) IMO we should be solving this indexing problem directly, not applying bandaids to its symptoms, and the way to do that is to come up with some common duck type that everyone can agree on. Unfortunately, AFAICT this means our only options here are to have some kind of backcompat break in numpy, some kind of backcompat break in pandas, or to do nothing and continue indefinitely with the status quo where the same indexing operation might silently return different results depending on the types passed in. All of these options have real costs for users, and it isn't at all clear to me what the relative costs will be when we dig into the details of our various options. So I'd be very happy to see worked out proposals for any or all of these approaches. It strikes me as really premature to be issuing proclamations about what changes might be considered. There is really no danger to *considering* a proposal; the worst case is that we end up rejecting it anyway, but based on better information. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal
On Fri, Apr 3, 2015 at 4:54 PM, Nathaniel Smith n...@pobox.com wrote: Unfortunately, AFAICT this means our only options here are to have some kind of backcompat break in numpy, some kind of backcompat break in pandas, or to do nothing and continue indefinitely with the status quo where the same indexing operation might silently return different results depending on the types passed in. For what it's worth, DataFrame.__getitem__ is also pretty broken in pandas (even worse than in NumPy). Not even the pandas devs can keep straight how it works! https://github.com/pydata/pandas/issues/9595 So we'll probably need a backwards incompatible switch there at some point, too. That said, the issues are somewhat different, and in my experience the strict label and integer based indexers .loc and .iloc work pretty well. I haven't heard any complaints about how they do cartesian indexing rather than fancy indexing. Stephan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] NPY_SEPARATE_COMPILATION and RELAXED_STRIDES_CHECKING
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. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NPY_SEPARATE_COMPILATION and RELAXED_STRIDES_CHECKING
IIRC there allegedly exist platforms where separate compilation doesn't work right? I'm happy to get rid of it if no one speaks up to defend such platforms, though, we can always add it back later. One case was for statically linking numpy into the interpreter, but I'm skeptical about how much we should care about that case, since that's already a hacky kind of process and there are simple alternative hacks that could be used to strip the offending symbols. Depends on how much it lets us simplify things, I guess. Would we get to remove all the no-export attributes on everything? On Apr 3, 2015 8:01 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Fri, Apr 3, 2015 at 9:00 PM, Charles R Harris charlesr.har...@gmail.com 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. Oops, default value is 1, not 0. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
