[Numpy-discussion] indexed increment (was Re: Pull Requests I'm planning to merge)
Thu Jul 19 08:48:54 CDT 2012
On Jul 19, 2012, at 4:56 AM, Nathaniel Smith wrote:
> On Thu, Jul 19, 2012 at 6:04 AM, Frédéric Bastien <email@example.com> wrote:
>> On Tue, Jul 17, 2012 at 10:20 PM, Travis Oliphant <firstname.lastname@example.org> wrote:
>>> I will hold off on this one, but only because you raised your objection to -1 (instead of -0.5). But, I disagree very strongly with you that it is "sub-optimal" in the context of NumPy. I actually think it is a very reasonable solution. He has re-used the MapIter code correctly (which is the only code that *does* fancy indexing). The author has done a lot of work to support multiple data-types and satisfy an often-requested feature in a very reasonable way. Your objection seems to be that you would prefer that it were a method on ufuncs. I don't think this will work without a *major* refactor. I'm not sure it's even worth it then either.
>> Due to Travis comments, I expect the "better" solution won't be done
>> in the short time. So blocking a feature requeted frequently because
>> we could do sometimes in an unknow futur something better is not a
>> good idea. (if I get it wrong on the expectation, please, correct me!)
> Really I'm making two points:
> 1- this design smells just "off" enough that we should discuss it to
> figure out whether or not it's actually the best way forward.
> 2- such discussions are too important to just skip whenever a release
> is imminent. there will be another release...
>> Also, if we decide to change the interface, we could do it for NumPy
>> 2, so I don't see a need for an infinit time support of this API.
> The "NumPy 2" idea is not very realistic IMHO, and shouldn't be used
> as an excuse for being sloppy. We're never going to be able to go
> through and make all the APIs perfect in one release cycle. Especially
> if we keep deferring all hard questions until then.
>> So in conclusion, can we say that when John will have make is PR work
>> with all dtype, we merge it?
> Well, we'll come up with something :-). (Assuming that people stay
> interested, which seems likely since this is such a common problem
> people have.) But I'm not sure what. Making the PR work with all
> dtypes is exactly what Travis is arguing is too much work.
I don't think that's what I was arguing would be too much work exactly. I must have mis-communicated. What I was saying was trying to use the ufunc mechanism to do this would be too much work at this point. Having the PR work with all dtypes (that support addition) should be done (and I believe with the exception of long double dtypes it has been done).
More information about the NumPy-Discussion