# [Numpy-discussion] Assigning complex value to real array

Christopher Barker Chris.Barker@noaa....
Thu Oct 7 15:50:10 CDT 2010

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

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@noaa.gov
```