Mailman 3 February 2005 - NumPy-Discussion

It's so *quiet* I'm testing numpy-discussion
by Todd Miller Feb. 16, 2005

Feb. 16, 2005

If this message actually gets posted, well, sorry. It's been so quiet on the list I thought I'd better check it. Todd

4 3

Numeric3
by René Bastian Feb. 11, 2005

Feb. 11, 2005

Hello, >From a user point of view, in the types module of Python I wish someting like : from types import * .... if type(a)==NumarrayType : ... -- René Bastian http://www.musiques-rb.org : Musique en Python

1 0

calcul of phase (dividing by 0)
by Jean-Luc Menut Feb. 10, 2005

Feb. 10, 2005

Hello, I'm want to have the modulus and the phase of a fourier transform of 2D array, so I use the numarray FFT to compute the FT of the array (let's call it ff) and I use abs(ff) for the modulus and atan(ff.imag/ff.real) for the phase. My problem comes when ff.real = 0, I have either inf or nan as result (which is perfectly good and useful). I looking for a function which replace atan(ff.imag/ff.real) by 0 when ff.real is 0. I'm currently using a loop, and I think it's not very good (I call this function very often). Since the determination of the phase is something really useful and often used, I think there is probably a lot of people who had the same problem. So what solutions do you use? Thanks, Jean-Luc Menut

6 5

Numeric3
by Travis Oliphant Feb. 10, 2005

Feb. 10, 2005

John Hunter wrote: >>>>>> "konrad" == konrad hinsen <konrad.hinsen(a)laposte.net> writes: >>>>>> >>>>> > > konrad> I agree completely. In addition, there is compatibilty: > konrad> lots of code out there uses the FFT and LinearAlgebra > konrad> interfaces that have been part of Numeric for many > konrad> years. numarray has them as well (it just requires a > konrad> change in the import statements). > > I too would be *very disappointed* to see LinearAlgebra, RandomArray > and FFT leave Numeric. matplotlib requires all three. Numeric is > lightweight and easy to install, and although the scipy install is > significantly easier than it was in yesteryear, it still has higher > barrier to entry. I am much happier requiring only Numeric than > Numeric and scipy. > > This is all a matter of semantics and packaging. My point is that it is silly to have a really nice wrapping of fft, linear algebra, and random number routines in SciPy and then repeat them somewhat for Numeric (or vice-versa). So to satisfy this complaint, the standard Numeric3 install is actually a "slimmed-down" scipy. > As for the change in import statements, one thing that would be nice > to see in Numeric3 is a package structure for these extra modules that > mirrors numarray's. > This is what the matplotlib numerix module > currently does, and the in the various __init__ files imports either > the Numeric or numarray symbols depending on the configuration > settings. This seems most sensible since the longer term goal is > integration. > > I'm not that concerned about what names we give things, but why not the names that scipy has. Or scipy should change it's names. There was some discussion about this on the scipy list. Nobody had a clear winner in terms of "naming" conventions. SciPy's stated goals for some time have been to provide numerical operations for arrays. If you want to call this super-structure numerix, then fine. SciPy adjusted for those that don't want to install everything. It is very easy to pick and choose the packages you want to install. There appears to be a hesitancy on the part of some to adopt something like scipy. I'm not sure whether it's scipy itself, or just the idea of scipy, that some people find difficult to adjust to. We talk about some version of the arrayobject getting into the core. Guido is not going to accept FFT's and LinearAlgebra (or maybe not even ufuncs). Towards this end, I prefer to separate the ideas of the arrayobject from the things you can do with it, which is why I believe scipy (with appropriate slimmed down versions) is a better place to discuss fft's, linear algebra, and the like. Old code can be handled with compatibility layers. -Travis

20 85

Re: [Python-Dev] Clarification sought about including a multidimensional array object into Python core
by Travis Oliphant Feb. 10, 2005

Feb. 10, 2005

David Ascher wrote: >I've not followed the num* discussion in quite a while, but my >impression back then was that there wasn't "one" such community. >Instead, the technical differences in the approaches required in >specific fields, regarding things like the relative importance of >memory profiles, speed, error handling, willingness to require modern >C++ compilers, etc. made practical compromises quite tricky. > > I really appreciate comments from those who remember some of the old discussions. There are indeed some different needs. Most of this, however, is in the ufunc object (how do you do math with the arrays). And, a lot of this has been ameliorated with the new concepts of error modes that numarray introduced. There is less argumentation over the basic array object as a memory structure. The biggest argument right now is the design of the object: i.e. a mixture of Python and C (numarray) versus a C-only object (Numeric3). In other words, what I'm saying is that in terms of how the array object should be structure, a lot is known. What is more controversial is should the design be built upon Numarray's object structure (a mixture of Python and C), or on Numeric's --- all in C -Travis

10 13

Numeric vs numarray?
by Andrew McNamara Feb. 10, 2005

Feb. 10, 2005

I know this is a loaded question, but what does numarray offer that Numeric does not (as they stand today)? A cleaner implementation? -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/

5 8

logical priority
by Stephen Walton Feb. 10, 2005

Feb. 10, 2005

A probably bonehead question: is it a known feature of Python that, in a logical operation, & has a higher priority than > or < ? Or is it a quirk of numarray? In [126]: a = arange(25) In [127]: v=(a>9) & (a<13) In [128]: v=a>9 & a<13 --------------------------------------------------------------------------- exceptions.RuntimeError Traceback (most recent call last) /home/swalton/research/foukal/<console> /usr/lib/python2.3/site-packages/numarray/generic.py in __nonzero__(self) 475 476 def __nonzero__(self): --> 477 raise RuntimeError("An array doesn't make sense as a truth value. Use any(a) or all(a).") 478 479 def __copy__(self): RuntimeError: An array doesn't make sense as a truth value. Use any(a) or all(a).

7 13

[Python-Dev] Clarification sought about including a multidimensional array object into Python core
by Travis Oliphant Feb. 9, 2005

Feb. 9, 2005

There has recently been some much-needed discussion on the numpy-discussions list run by sourceforge regarding the state of the multidimensional array objects available for Python. It is desired by many that there be a single multidimensional array object in the Python core to facilitate data transfer and interfacing between multiple packages. I am a co-author of the current PEP regarding inclusion of the multidimensional array object into the core. However, that PEP is sorely outdated. Currently there are two multidimensional array objects that are in use in the Python community: Numeric --- original arrayobject created by Jim Hugunin and many others. Has been developed and used for 10 years. An upgrade that adds the features of numarray but maintains the same basic structure of Numeric called Numeric3 is in development and will be ready for more wide-spread use in a couple of weeks. Numarray --- in development for about 3 years. It was billed by some as a replacement for Numeric,. While introducing some new features, it still has not covered the full feature set that Numeric had making it impossible for all Numeric users to use it. In addition, it is still unacceptably slow for many operations that Numeric does well. Scientific users will always have to install more packages in order to use Python for their purposes. However, there is still the desire that the basic array object would be common among all Python users. To assist in writing a new PEP, we need clarification from Guido and others involved regarding 1) What specifically about Numeric prevented it from being acceptable as an addition to the Python core. 2) Are there any fixed requirements (other than coding style) before an arrayobject would be accepted into the Python core. Thanks for your comments. I think they will help the discussion currently taking place. -Travis Oliphant _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/oliphant%40ee.byu.edu --------------080004070407050603040506--

2 1

[Fwd: [Python-Dev] Clarification sought about including a multidimensional array object into Python core]
by Travis Oliphant Feb. 9, 2005

Feb. 9, 2005

1 0

[Fwd: Re: [Python-Dev] Clarification sought about including a multidimensional array object into Python core]
by Travis Oliphant Feb. 9, 2005

Feb. 9, 2005

1 0