[Numpy-discussion] Ransom Proposals
Tim Hochberg
tim.hochberg at cox.net
Mon Mar 27 14:45:03 CST 2006
Charles R Harris wrote:
>
>
> On 3/27/06, *Tim Hochberg* <tim.hochberg at cox.net
> <mailto:tim.hochberg at cox.net>> wrote:
>
> Charles R Harris wrote:
> [CHOP]
>
> >
> > How about functions always return a copy unless they are carefully
> > documented interface helper functions like asarray. That's how I
> > generally think of them anyway.
>
> I don't really care as long as they (a) stop being evil and (b)
> there's
> some way to do stuff efficiently. Functions that always return copies
> seem sort of useless to me, but I'd be happy to move to methods if
> that
> was the case. However, I suspect you won't make much headway with this
> since my impression is that many of the people who do care about
> functions also care passionately about efficiency as well.
>
> > Of course, the main virtue of asarray is that it helps write
> functions
> > that do precisely what Tim is arguing against: mixing list and array
> > types and returning copies in the first case, views in the
> second. So
> > if we throw out functions we should throw out asarray also and
> make a
> > rule that numpy functions don't take lists.
>
> This isn't right. I think it's perfectly fine, desirable in fact, for
> functions to operate on both list and array types. The problem only
> arises when you return ether a view or copy of one of the original
> inputs depending on what it was. In my experience, this is relatively
> hard to do in all but the most trivial of functions since most
> operations return a new array. However, it is true that I think people
> should be strongly discouraged from doing this. For example:
>
> def add(a, b):
> a = asarray(a)
> b = asarray(b)
> return a + b
>
> is fine, but:
>
> def iadd(a, b):
> a = asarray(a)
> b = asarray(b)
> a += b
> return a
>
> is not and should be rewritten. Possibly like:
>
> def iadd(a, b):
> if not isinstance(a, ndarray): raise TypeError("'a' must be an
> array")
> b = asarray(b)
> a += b
> return a
>
> since += is a bit squirley. (Try somelist += somearray, to see
> what I mean).
>
>
> It's a syntax error, which I believe is the right thing.
Really? If so, this is a version thing. This is what I get running on
Python 2.4.1 and current numpy SVN (0.9.7.2286):
>>> l = list(a)
>>> l
[999, 1, 2, 3, 4, 5, 6, 7, 8]
>>> a
array([999, 1, 2, 3, 4, 5, 6, 7, 8])
>>> l += a
>>> l
array([1998, 2, 4, 6, 8, 10, 12, 14, 16])
>>> a
array([999, 1, 2, 3, 4, 5, 6, 7, 8])
>
> > And then there are scalars...
>
> I'm curious what problems you forsee with scalars.
>
>
> There was/is the whole problem of when to return scalars and if they
> should be python scalars. The problem arises from trying to be
> compatible with normal python stuff. Matlab got around this by making
> everything 1) an array, and 2) double precision. On the other hand,
> Matlab is not nearly is easy to use for nonstandard types. \
I think most of this problem will go away in Python with the
introduction of the __index__ protocol, so for the moment at least I'm
not worried about it.
Regards,
-tim
More information about the Numpy-discussion
mailing list