[Numpy-discussion] Ransom Proposals

[Charles R Harris]

Hmm,

On 3/27/06, Charles R Harris <charlesr.harris at gmail.com> wrote:
>
>
>
> 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.
>
> It was pilot error. On the other hand:
>>> b = [1,2,3]
>>> b += b
>>> b

[1, 2, 3, 1, 2, 3]

Which makes sense from the list perspective. From what Travis says, += is
actually a phony in place operator, so if [1,2,3] + array([1,2,3]) is
supported and returns an array, the result is a given. This is what comes
from mixing types and trying to treat them all as interconvertable. Lists
aren't arrays, they are just a convenient way to specify the array entries
for initialization. I think in these cases one should be forced to be
explicit.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20060327/a4eae7bf/attachment-0001.html