numpy magic: cast scalar returns auto to python types float & int ?

[robert]

Robert Kern wrote:
> robert wrote:
> 
>> Didn't find the relevant reasoning within time. Yet guess the reason is isolated-module-centric. 
> 
> I gave you a brief rundown on this list already.
> 
>   http://mail.python.org/pipermail/python-list/2006-October/411145.html

think I took this into account already for this discussion.

>>> array([1.,.0,4,4,],float32)
array([ 1.,  0.,  4.,  4.], dtype=float32)
>>> a=_
>>> a+3
array([ 4.,  3.,  7.,  7.], dtype=float32)
>>> a+3.0
array([ 4.,  3.,  7.,  7.], dtype=float32)
>>> 3+a
array([ 4.,  3.,  7.,  7.], dtype=float32)
>>> 3.0+a
array([ 4.,  3.,  7.,  7.], dtype=float32)
>>> 3.0*a
array([  3.,   0.,  12.,  12.], dtype=float32)


numpy does anyway not force the precision upwards for float32 x python-float. ( what is good so).

There remains the argument, that (float64,int32) scalars coming out should - by default - support the array interface. 
How many people are there to expect and use this? I'd have never noticed it, if it wouldn't have been mentioned here. Have never seen such code nor seen somewhere or felt myself such a requirement. Thats very special an maybe can be turned on by a global option - if there is more than a handful of users for that.
I still think this is over-design and that it brings much much more disadvantages than advantages to let these beasts out by default into a general purpose language like python. The target area for numpy output is much bigger than that e.g. for matlab script someone uses in a rush to create a paper. Maybe for users who want to make an alt-matlab-only box out of python there could be a global switch somewhere or a enforcing versions of the data types ...

Seeing the speed impact and pickle-problems now everywere on post-computations upon numpy out, its a critical decision to migrate code to numpy. Almost a killer. Even if I spread float()-casts everywhere, this cost a lot of speed, makes code ugly etc., and its an holey sieve.

I think I'll stay as a voice to vote heavily against that scheme of numpy scalar types. 11 on a scale from 0 to 10 :-)


> And yet again, the best place for numpy questions is the numpy mailing list, not
> here. Here, you will get maybe one or two people responding to you, usually me,
> and I'm a cranky SOB. There you will get much nicer people answering your
> questions and more fully.
> 
>   http://www.scipy.org/Mailing_Lists

Maybe once I take the hurdle to use this. Access and searching on such lists is somewhat proprietry. Numerics is a major field in Python land. There are also lots of cross relations to other libs and techniques.  Maybe there could be a nntp-comfortable comp.lang.python.numeric for users - and also a comp.lang.python.net, comp.lang.python.ui. I think that would greatly strentghen Pythons "marketing" in the numerics domain. main clp's posting frequency is too high anyway meanwhile.


Robert