[Numpy-discussion] Assigning complex value to real array

[Christopher Barker]

First:

Wow! what a rude post. I'm not a significant contributer to numpy, but 
that was really offensive to me.

Most of the features of numpy were in fact carefully designed for good 
reason -- they may not match your use case well, but that does not mean 
that they are not good design decisions.

Other features of numpy were perhaps the result of something simply 
being overlooked -- it is continually improving as Anne and Chuck mentioned.

As for your issue -- I've deleted your original post, so I lost your 
specific use/test case, but a note about numpy design:

numpy allows the use of various data types, of various levels of 
precision -- this is a very powerful feature. And while python is a 
dynamic language, numpy tries to not upcast arrays unless specifically 
asked to:

In [22]: a = np.array((5,6), dtype=np.int32)

In [26]: a += 1.2

In [27]: a
Out[27]: array([6, 7])

In [28]: a[0] = 4.5

In [29]: a
Out[29]: array([4, 7])

Would you have wanted your array to be upcast to a float?

In [50]: a
Out[50]: array([5, 6], dtype=uint8)

In [51]: a+=3000

In [52]: a
Out[52]: array([189, 190], dtype=uint8)

or upcast to a bigger int type?

In short -- numpy gives you some real power and flexibility that Matlab, 
for instance, does not, but it does require you to think about what 
dtype you want to use ahead of time.

> You wouldn't want to rewrite any of numpy, just add a new class.

If you understood what the issue was, you'd know it isn't that simple. 
You could, in fact, write array class that stored the real and imaginary 
parts in separate numpy arrays, but it would still be a lot of work to 
get that to all work smoothly with the rest of numpy, and you'd get a 
major performance hit, and it would be hard to interface with C libs.

> By having this behavior, Python is filtering out a lot of potential 
> users. So you will not get a lot of complaints - because people will 
> just walk away and use Matlab, Scilab, or R, etc.

Ha! I walked away from Matlab years ago -- and having control over 
datatypes was one major reason.

> Given this behavior 
> one is strongly tempted to declare everything complex and deprecate the 
> reals.

For some uses, that's a fine idea.

> Well, who needs physics and  electrical engineering.

Anyone competent doing calculations for physics and engineering darn 
well better know when to expect complex numbers.

> I agree it will not be done, but mainly because people who are in a 
> position to do it will find an excuse to not do it, not for any better 
> reason.

no one needs an excuse not to implement something -- "none of us has the 
time" or "it's not important enough to me to want to do it" are fine. 
There are plenty of good suggestions made on this list that don't get 
implemented for those sorts of reasons.

> But it is important to inform everyone that it is not for lack 
> of a better alternative that we have this problem. It is for lack of 
> effort. Let's just fess up about why it's not going to be done.

I think it's not going to be done because you're too lazy to do it -- 
this is an open source project, you are free to contribute. If you are 
so convinced that you're right -- put your code where your mouth is.


By the way, if Matlab or Scilab or R is a better tool for your work, go 
ahead and use it -- it makes no difference to us what you use.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov