On Mon, Nov 14, 2016 at 3:42 PM, Mikhail V <mikhail...@gmail.com> wrote:
> On 14 November 2016 at 19:57, Nick Timkovich <prometheus...@gmail.com> > wrote: > > Currently, Numpy takes advantage of __iadd__ and friends by performing > the > > operation in-place; there is no copying or other object created. Numpy is > > very thinly C, for better and worse (which is also likely where the += > > syntax came from). If you're doing vast amounts of numeric computation, > it > > quickly pays off to learn a little about how C likes to store arrays in > > memory and that doing things like creating a whole new array of the same > > size and having to free up the old one for every operation isn't a great > > idea. I strongly dislike the notion that I'd have to use arbitrary > function > > calls to add one to an entire array, or multiply it by 2, or add it to > > another array, etc. > > > > As a minor nit, np.vectorize doesn't make in-place functions, it simply > > makes a naive, element-wise function act as though it was vectorized. The > > name is unfortunate, because it does nothing to speed it up, and it > usually > > slows it down (because of that layer). Reworking code to avoid copying > large > > arrays by doing in-place operations is the preferred method, though not > > always possible. > > > > Nick > > I can understand you good. But imagine, if Numpy would allow you to > simply write: > A = A + 1 > Which would bring you directly to same internal procedure as A += 1. > So it does not currently, why? > First, because the language doesn't allow it. But more fundamentally, sometimes we don't want A = A + 1 to be the same as A += 1. Making a copy is sometimes what you want. Having both versions lets you control when you make a copy rather than being forced to always make a copy or always not. > I never would. Also I think to implement this syntax would be almost > trivial, it should > just take the A = A part and do the rest as usual. > The Python language doesn't allow it. numpy can only work with the information provided to it be the language, and the information needed to do that sort of thing is not provided to classes. Nor should it in my opinion, this is one of those fundamental operations that I think absolutely must be consistent. What you are talking about is an enormous backwards-compatibility break. It is simply not going to happen, it would break every mutable class. And you still have not provided any reason we should want to do it this way.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
