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
robert wrote:
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
robert wrote:
Turning algs for old NumPy modules into numpy code I suffer from this:
Upon further processing of returns of numpy calculations, lots of data in an
apps object tree will become elementary numpy types.
First there is some inefficiency in calculations. And then you get data
Tim Hochberg wrote:
robert wrote:
To avoid this you'd need a type cast in Python code everywhere you get
scalars from numpy into a python variable. Error prone task. Or
check/re-render your whole object tree.
Wouldn't it be much better if numpy would return Python scalars for
float64
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
And I'll note again that a fuller discussion is given in
