On 8/29/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
That sounds like a good idea. One could keep the present behaviour in most cases by supplying a default value, although the out keyword might need a None value to indicate "copy" and a 'Self' value that means in place, or something like that, and then have all reasonable methods return values. That way the change would be transparent. The changes to the sort method would all be upper level, the low level sorting routines would remain unchanged.
Methods are new, so code that needs to be changed is code specifically written for Numpy and now is the time to make these sort of decisions.
Chuck
Charles R Harris wrote:
>
>
> On 8/29/06, *Tim Hochberg* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED] >> wrote:
>
> Charles R Harris wrote:
> > Hi,
> >
> > On 8/29/06, *Tim Hochberg* <[EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED] >>>
> wrote:
> >
> >
> > -0.5 from me if what we're talking about here is having mutating
> > methods
> > return self rather than None. Chaining stuff is pretty, but
> having
> > methods that mutate self and return self looks like a source of
> > elusive
> > bugs to me.
> >
> > -tim
> >
> >
> > But how is that any worse than the current mutating operators? I
> think
> > the operating principal is that methods generally work in place,
> > functions make copies. The exceptions to this rule need to be noted.
> Is that really the case? I was more under the impression that there
> wasn't much rhyme nor reason to this. Let's do a quick dir(somearray)
> and see what we get (I'll strip out the __XXX__ names):
>
> 'all', 'any', 'argmax', 'argmin', 'argsort', 'astype', 'base',
> 'byteswap', 'choose', 'clip', 'compress', 'conj', 'conjugate', 'copy',
> 'ctypes', 'cumprod', 'cumsum', 'data', 'diagonal', 'dtype', 'dump',
> 'dumps', 'fill', 'flags', 'flat', 'flatten', 'getfield', 'imag',
> 'item',
> 'itemsize', 'max', 'mean', 'min', 'nbytes', 'ndim', 'newbyteorder',
> 'nonzero', 'prod', 'ptp', 'put', 'putmask', 'ravel', 'real',
> 'repeat',
> 'reshape', 'resize', 'round', 'searchsorted', 'setfield', 'setflags',
> 'shape', 'size', 'sort', 'squeeze', 'std', 'strides', 'sum',
> 'swapaxes',
> 'take', 'tofile', 'tolist', 'tostring', 'trace', 'transpose',
> 'var', 'view'
>
>
> There are certainly many methods where inplace operations make no
> sense. But for such things as conjugate and clip I think it should be
> preferred. Think of them as analogs of the "+=" operators that allow
> memory efficient inplace operations. At the moment there are too few
> such operators, IMHO, and that makes it hard to write memory efficient
> code when you want to do so. If you need a copy, the functional form
> should be the preferred way to go and can easily be implement by
> constructions like a.copy().sort().
So let's make this clear; what you are proposing is more that just
returning self for more operations. You are proposing changing the
meaning of the existing methods to operate in place rather than return
new objects. It seems awfully late in the day to be considering this
being that we're on the edge of 1.0 and this would could break any
existing numpy code that is out there.
Just for grins let's look at the operations that could potentially
benefit from being done in place. I think they are:
byteswap
clip
conjugate
round
sort
Of these, clip, conjugate and round support an 'out' argument like that
supported by ufunces; byteswap has a boolean argument telling it
whether to perform operations in place; and sort always operates in
place. Noting that the ufunc-like methods (max, argmax, etc) appear to
support the 'out' argument as well although it's not documented for most
of them, it looks to me as if the two odd methods are byteswap and sort.
The method situation could be made more consistent by swapping the
boolean inplace flag in byteswapped with another 'out' argument and also
having sort not operate in place by default, but also supply an out
argument there. Thus:
b = a.sort() # Returns a copy
a.sort(out=a) # Sorts a in place
a.sort(out=c) # Sorts a into c (probably just equivalent to c = a.sort()
in this case since we don't want to rewrite the sort routines)
On the whole I think that this would be an improvement, but it may be
too late in the day to actually implement it since 1.0 is coming up.
There would still be a few methods (fill, put, etc) that modify the
array in place and return None, but I haven't heard any complaints about
those.
That sounds like a good idea. One could keep the present behaviour in most cases by supplying a default value, although the out keyword might need a None value to indicate "copy" and a 'Self' value that means in place, or something like that, and then have all reasonable methods return values. That way the change would be transparent. The changes to the sort method would all be upper level, the low level sorting routines would remain unchanged.
Methods are new, so code that needs to be changed is code specifically written for Numpy and now is the time to make these sort of decisions.
-tim
Chuck
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
