[Numpy-discussion] Ransom Proposals

[Tim Hochberg]

Tim Hochberg 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])


Let me add that I think that this is pretty dubious, so if this is a new 
feature, perhaps we should revert it before it becomes entrenched.


Regards,

-tim

>
>>
>>     > 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.
>