[Numpy-discussion] Ransom Proposals

[Charles R Harris]

On 3/27/06, Tim Hochberg <tim.hochberg at cox.net> wrote:
>
> 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])


Ugh. IMHO, this should throw an error. For these sort of assignment
operators I think the right hand side should be cast to the type of the
left, which I think of as some sort of fancy register variable. If anything,
the list should be appended to. I'll have to try the latest SVN just to
appreciate this.


> -tim
>
> Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20060327/c637c01e/attachment.html>