[Numpy-discussion] Ransom Proposals

[Tim Hochberg]

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