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 [email protected] _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
