On Tue, 2018-06-26 at 22:26 -0700, Robert Kern wrote:
> On Tue, Jun 26, 2018 at 10:21 PM Juan Nunez-Iglesias com> wrote:
> > Let me start by thanking Robert for articulating my viewpoints far
> > better than I could have done myself. I want to explicitly flag the
> > following statements for endor
On Tue, Jun 26, 2018 at 10:22 PM Robert Kern wrote:
> We certainly could make the conservative choice of only adopting 4 for now
>> and leaving further cleanup for later. I guess this uncertainty about
>> whether direct indexing should be more like vindex[] or oindex[] in the
>> long term is a go
On Tue, Jun 26, 2018 at 10:21 PM Juan Nunez-Iglesias
wrote:
> Let me start by thanking Robert for articulating my viewpoints far better
> than I could have done myself. I want to explicitly flag the following
> statements for endorsement:
>
> *I would still reserve warnings and deprecation for th
On Tue, Jun 26, 2018 at 9:50 PM Stephan Hoyer wrote:
> On Tue, Jun 26, 2018 at 12:46 AM Robert Kern
> wrote:
>
>> I think having more self-contained descriptions of the semantics of each
>> of these would be a good idea. The current description of `.vindex` spends
>> more time talking about what
Let me start by thanking Robert for articulating my viewpoints far
better than I could have done myself. I want to explicitly flag the
following statements for endorsement:
> *I would still reserve warnings and deprecation for the cases where
> the current behavior gives us something that no one wa
On Tue, Jun 26, 2018 at 12:46 AM Robert Kern wrote:
> I think having more self-contained descriptions of the semantics of each
> of these would be a good idea. The current description of `.vindex` spends
> more time talking about what it doesn't do, compared to the other methods,
> than what it d
On Tue, Jun 26, 2018 at 6:47 PM Stephan Hoyer wrote:
>
> On Tue, Jun 26, 2018 at 6:39 PM Robert Kern wrote:
>
>> I'd still prefer not talking deprecation, per se, in this NEP (but my
>> objection is weaker). I would definitely start adding in informative, noisy
>> warnings in these cases, though
On Tue, Jun 26, 2018 at 6:39 PM Robert Kern wrote:
> I'd still prefer not talking deprecation, per se, in this NEP (but my
> objection is weaker). I would definitely start adding in informative, noisy
> warnings in these cases, though. Along the lines of, "Hey, this is a dodgy
> construction that
On Tue, Jun 26, 2018 at 6:14 PM Stephan Hoyer wrote:
> On Tue, Jun 26, 2018 at 4:34 PM Robert Kern wrote:
>
>> I maintain that considering deprecation is premature at this time. Please
>> take it out of this NEP. Let us get a feel for how people actually use
>> .oindex/.vindex. Then we can talk
On Tue, Jun 26, 2018 at 9:38 AM Eric Wieser
wrote:
> We can expose some of the internals
>
> These could be expressed as methods on the internal indexing objects I
> proposed in the first reply to this thread, which has seen no responses.
>
> I think Hameer Abbasi is looking for something like
>
On Tue, Jun 26, 2018 at 4:34 PM Robert Kern wrote:
> I maintain that considering deprecation is premature at this time. Please
> take it out of this NEP. Let us get a feel for how people actually use
> .oindex/.vindex. Then we can talk about deprecation. This NEP gets my
> enthusiastic approval,
On Tue, Jun 26, 2018 at 3:50 AM Sebastian Berg
wrote:
>
> On Tue, 2018-06-26 at 02:27 -0700, Robert Kern wrote:
> > On Tue, Jun 26, 2018 at 1:36 AM Sebastian Berg > s.net> wrote:
> > > On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote:
> > > > On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg
>
We can expose some of the internals
These could be expressed as methods on the internal indexing objects I
proposed in the first reply to this thread, which has seen no responses.
I think Hameer Abbasi is looking for something like
OrthogonalIndexer(...).to_vindex()
-> VectorizedIndexer such that
On Tue, 2018-06-26 at 04:01 -0400, Hameer Abbasi wrote:
> I second this design. If we were to consider the general case of a
> tuple `idx`, then we’d not be moving forward at all. Design changes
> would be impossible. I’d argue that this newer model would be easier
> for library maintainers overall
This seems like progress and a clear method to outer indexing will help many
users.
As for names, I prefer .ox and .vx for shorthand of .oindex and .vindex. I
don’t like the .ox_ or .o_ syntax.
Before any deprecation warnings or any other warnings are added it would be
helpful to have some wa
On Tue, 2018-06-26 at 02:27 -0700, Robert Kern wrote:
> On Tue, Jun 26, 2018 at 1:36 AM Sebastian Berg s.net> wrote:
> > On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote:
> > > On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg
> > > wrote:
> >
> >
> >
> > > >
> > > > Yes, that is true, but
On Tue, Jun 26, 2018 at 1:36 AM Sebastian Berg
wrote:
> On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote:
> > On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg
> > wrote:
>
>
>
> > >
> > > Yes, that is true, but I doubt you will find a lot of code path
> > > that
> > > need the current indexi
On Tue, Jun 26, 2018 at 1:49 AM Hameer Abbasi
wrote:
>
> On 26. Jun 2018 at 10:33, Robert Kern wrote:
>
> > I'd suggest that the NEP explicitly disclaim deprecating current
behavior. Let the NEP just be about putting the new features out there.
Once we have some experience with them for a year or
I would disagree here. For libraries like Dask, XArray, pydata/sparse,
XND, etc., it would be bad for them if there was continued use of “weird”
indexing behaviour (no warnings means more code written that’s… well… not
exactly the best design). Of course, we could just choose to not support
it. Bu
On Tue, 2018-06-26 at 04:23 -0400, Hameer Abbasi wrote:
> > Boolean indices are not supported. All indices must be integers,
> integer arrays or slices.
>
> I would hope that there’s at least some way to do boolean indexing. I
> often find myself needing it. I realise that
> `arr.vindex[np.nonzero
On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote:
> On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg
> wrote:
> >
> > Yes, that is true, but I doubt you will find a lot of code path
> > that
> > need the current indexing as opposed to vindex here,
>
> That's probably true! But I think it's
I actually had to think a lot, read docs, use SO and so on to realise what
those meant the first time around, I didn’t understand them on sight.
And I had to keep coming back to the docs from time to time as I wasn’t
exactly using them too much (for exactly this reason, when some problems
could be
On Tue, Jun 26, 2018 at 1:26 AM Travis Oliphant
wrote:
> I like the proposal generally. NumPy could use a good orthogonal indexing
> method and a vectorized-indexing method is fine too.
>
> Robert Kern is spot on with his concerns as well. Please do not change
> what arr[idx] does except to pro
Another thing I’d say is arr.?index should be replaced with arr.?idx.
Or perhaps arr.o_[] and arr.v_[], to match the style of our existing
np.r_, np.c_, np.s_, etc?
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mai
I like the proposal generally. NumPy could use a good orthogonal indexing
method and a vectorized-indexing method is fine too.
Robert Kern is spot on with his concerns as well. Please do not change
what arr[idx] does except to provide warnings and perhaps point people to
new .oix and .vix method
> Boolean indices are not supported. All indices must be integers, integer
arrays or slices.
I would hope that there’s at least some way to do boolean indexing. I often
find myself needing it. I realise that
`arr.vindex[np.nonzero(boolean_idx)]` works, but it is slightly too verbose
for my liking
On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg
wrote:
> On Tue, 2018-06-26 at 17:30 +1000, Andrew Nelson wrote:
> > On Tue, 26 Jun 2018 at 17:12, Eric Wieser > m> wrote:
> > > > I don't think it should be relegated to the "officially
> > > discouraged" ghetto of `.legacy_index`
> > >
> > > The
I second this design. If we were to consider the general case of a tuple
`idx`, then we’d not be moving forward at all. Design changes would be
impossible. I’d argue that this newer model would be easier for library
maintainers overall (who are the kind of people using this), reducing
maintenance
On Tue, 2018-06-26 at 17:30 +1000, Andrew Nelson wrote:
> On Tue, 26 Jun 2018 at 17:12, Eric Wieser m> wrote:
> > > I don't think it should be relegated to the "officially
> > discouraged" ghetto of `.legacy_index`
> >
> > The way I read it, the new spelling lof that would be the explicit
> > but
On Tue, Jun 26, 2018 at 12:46 AM Robert Kern wrote:
> On Tue, Jun 26, 2018 at 12:13 AM Eric Wieser
> wrote:
>
>> > I would reserve warnings for the cases where the current behavior is
>> something no one really wants, like mixing slices and integer arrays.
>>
>> These are the cases that would on
On Tue, Jun 26, 2018 at 12:13 AM Eric Wieser
wrote:
> > I don't think it should be relegated to the "officially discouraged"
> ghetto of `.legacy_index`
>
> The way I read it, the new spelling lof that would be the explicit but not
> discouraged `image.vindex[rr, cc]`.
>
Okay, I missed that the
On Tue, 26 Jun 2018 at 17:12, Eric Wieser
wrote:
> > I don't think it should be relegated to the "officially discouraged"
> ghetto of `.legacy_index`
>
> The way I read it, the new spelling lof that would be the explicit but not
> discouraged `image.vindex[rr, cc]`.
>
If I'm understanding correc
> I don't think it should be relegated to the "officially discouraged"
ghetto of `.legacy_index`
The way I read it, the new spelling lof that would be the explicit but not
discouraged `image.vindex[rr, cc]`.
> I would reserve warnings for the cases where the current behavior is
something no one r
On Mon, Jun 25, 2018 at 11:29 PM Andrew Nelson wrote:
> On Tue, 26 Jun 2018 at 16:24, Juan Nunez-Iglesias
> wrote:
>
>> > Plain indexing arr[...] should return an error for ambiguous cases.
>> [...] This includes every use of vectorized indexing with multiple integer
>> arrays.
>>
>> This line c
On Tue, 26 Jun 2018 at 16:24, Juan Nunez-Iglesias
wrote:
> > Plain indexing arr[...] should return an error for ambiguous cases.
> [...] This includes every use of vectorized indexing with multiple integer
> arrays.
>
> This line concerns me. In scikit-image, we often do:
>
> rr, cc = coords.T #
> Plain indexing arr[...] should return an error for ambiguous cases.
> [...] This includes every use of vectorized indexing with multiple
> integer arrays.
This line concerns me. In scikit-image, we often do:
rr, cc = coords.T # coords is an (n, 2) array of integer coordinates
values = image[rr,
Generally +1 on this, but I don’t think we need
To ensure that existing subclasses of ndarray that override indexing
do not inadvertently revert to default behavior for indexing attributes,
these attribute should have explicit checks that disable them if
__getitem__ or __setitem__ has been overrid
Sebastian and I have revised a Numpy Enhancement Proposal that he started
three years ago for overhauling NumPy's advanced indexing. We'd now like to
present it for official consideration.
Minor inline comments (e.g., typos) can be added to the latest pull request
(https://github.com/numpy/numpy/p
38 matches
Mail list logo
