![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Please help the developers by responding to a few questions. 1) Have you transitioned or started to transition to NumPy (i.e. import numpy)? 2) Will you transition within the next 6 months? (if you answered No to #1) 3) Please, explain your reason(s) for not making the switch. (if you answered No to #2) 4) Please provide any suggestions for improving NumPy. Thanks for your answers. NumPy Developers
![](https://secure.gravatar.com/avatar/915f9e3213021d75d43bb4262167b067.jpg?s=120&d=mm&r=g)
pyOpenGL is one project that hasn't upgraded to numpy yet. http://pyopengl.sourceforge.net/ I think the issue is just that noone is really maintaining it, rather than any difficulty in porting to numpy. Since he's probably not reading this list, might be a good idea to send the project admin a copy of the survey: mcfletch at users.sourceforge.net --bb On 5/31/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
-- William V. Baxter III OLM Digital Kono Dens Building Rm 302 1-8-8 Wakabayashi Setagaya-ku Tokyo, Japan 154-0023 +81 (3) 3422-3380
![](https://secure.gravatar.com/avatar/837d314801b4f1400d6eabc767ca2cac.jpg?s=120&d=mm&r=g)
I am a Numeric user. On 5/30/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
Started transition. Most applications were easily ported to Numpy. I am still deciding whether or not support both Numpy and Numeric during the transition period.
2) Will you transition within the next 6 months? (if you answered No to #1)
Yes, as soon as numpy 1.0 is released.
4) Please provide any suggestions for improving NumPy.
That's a big topic! Without expanding on anything: - optimized array of interned strings (compatible with char** at the C level) - optimized array of arrays (a restriction of dtype=object array) - use BLAS in umath
![](https://secure.gravatar.com/avatar/135b00c97cc7af2e25f4f23b10e02d48.jpg?s=120&d=mm&r=g)
We use Numeric in NetEpi Analysis (www.netepi.org).
No.
2) Will you transition within the next 6 months? (if you answered No to #1)
Unknown - someone will have to fund the work.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
NetEpi Analysis implements C extensions to do fast set options on integer Numeric arrays, as well as to support mmap'ed Numeric arrays. I haven't looked at what is required to port these to Numpy (or replace with native Numpy features). NetEpi Analysis also uses rpy, which will potentially need to be updated to support Numpy. We're also concerned about speed - but I haven't done any testing against the latest Numpy. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
![](https://secure.gravatar.com/avatar/802b07155a8ab3996b825eca778f770e.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Travis Oliphant wrote: Numeric user since 1998. Writing commercial application software for control of machines. The machine is sold with the application software, closed source. | 1) Have you transitioned or started to transition to NumPy (i.e. import | numpy)? No | 2) Will you transition within the next 6 months? (if you answered No to #1) Maybe. | 3) Please, explain your reason(s) for not making the switch. (if you | answered No to #2) We are by now late adopters of everything. Everything else we use (we use about 30 non-GPL opensource packages in our development environment, some of which are using Numeric themselves) will need to migrate as well. Our own code is interspersed with Numeric calls, and amounts to about 200k lines... Rob - -- Rob W.W. Hooft || rob@hooft.net || http://www.hooft.net/people/rob/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEfR/fH7J/Cv8rb3QRAvbjAKCCMLpbBbWSBDsRZZzL0+p4HTqcLACbBwiB YLFwX1oEULCH068j2I7ZoDg= =0gj8 -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/968b818b9553fbf74f79cf4b1db725a2.jpg?s=120&d=mm&r=g)
We use Numeric for our "Atomic Simulation Environment" and for a Density Functional Theory code: http://wiki.fysik.dtu.dk/ASE http://wiki.fysik.dtu.dk/gridcode
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
No.
2) Will you transition within the next 6 months? (if you answered No to #1)
Yes. Only problem is that ASE relies on Konrad Hinsen's Scientific.IO.NetCDF module which is still a Numeric thing. I saw recently that this module has been converted to numpy and put in SciPy/sandbox. What is the future of this module?
4) Please provide any suggestions for improving NumPy.
Can't think of anything! Jens Jørgen Mortensen
![](https://secure.gravatar.com/avatar/fd2f4a8c073258ba5e271a16bad7f7c8.jpg?s=120&d=mm&r=g)
On May 31, 2006, at 8:13, Jens Jørgen Mortensen wrote:
Martin Wiechert recently sent me his adaptation to Numpy. I integrated his patches checking for nothing else but that it doesn't break the Numeric interface. I then checked that it compiles and runs the demo script correctly. I am happy to send this version to anyone who wants to test-drive it. Personally I cannot really test it as all my application code that is based on it requires Numeric. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: konrad.hinsen@cea.fr ---------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/9887fc565eeb83dacd53019357109ba0.jpg?s=120&d=mm&r=g)
Le Mercredi 31 Mai 2006 04:53, Travis Oliphant a écrit :
Please help the developers by responding to a few questions.
I am a numarray user
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
no I tried to install numpy but the installation failed.
2) Will you transition within the next 6 months? (if you answered No to #1)
no, (hm, but if numarray will be prohibited, ...)
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
numarray works and works fine (from version number 0.8 to 1.5)
-- René Bastian http://www.musiques-rb.org http://pythoneon.musiques-rb.org
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
Hi Travis, Here you have the answers for PyTables project (www.pytables.org). A Dimecres 31 Maig 2006 04:53, Travis Oliphant va escriure:
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
Not yet, although suport for it is in-place through the use of the array protocol.
2) Will you transition within the next 6 months? (if you answered No to #1)
We don't know, but other projects in our radar make us to think that we will not be able to do that in this timeframe.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
As I said before, it is mainly a matter of priorities. Also, numarray works very well for PyTables usage, and besides, NumPy 1.0 is not yet there.
4) Please provide any suggestions for improving NumPy.
You are already doing a *great* work. Perhaps pushing numexpr in NumPy would be nice. Also working in introducing a simple array class in Python core and using the array protocol to access the data would be very good. Cheers, --
![](https://secure.gravatar.com/avatar/c248bc10c66731ecd789b0135b635329.jpg?s=120&d=mm&r=g)
On 31/05/2006, at 4:53 AM, Travis Oliphant wrote:
Please help the developers by responding to a few questions.
I've ported my code to NumPy. But I have some suggestions for improving NumPy. I've now entered them as these tickets: Improvements for NumPy's web presence: http://projects.scipy.org/scipy/numpy/ticket/132 Squeeze behaviour for 1d and 0d arrays: http://projects.scipy.org/scipy/numpy/ticket/133 Array creation from sequences: http://projects.scipy.org/scipy/numpy/ticket/134 -- Ed
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Ed Schofield wrote:
Improvements for NumPy's web presence: http://projects.scipy.org/scipy/numpy/ticket/132
From that page: NumPy's web presence could be improved by: 2. Pointing www.numpy.org to numeric.scipy.org instead of the SF page I don't like this. *numpy is not scipy*. It should have it's own page (which would refer to scipy). That page should be something better than the raw sourceforge page, however. A lot of us use numpy without anything else from the scipy project, and scipy is still a major pain in the *&&^* to build. Can you even build it with gcc 4 yet? I like the other ideas. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 5/31/06, Christopher Barker <Chris.Barker@noaa.gov> wrote:
Well, ipython is not scipy either, and yet its homepage is ipython.scipy.org. I think it's simply a matter of convenience that the Enthought hosting infrastructure is so much more pleasant to use than SF, that other projects use scipy.org as an umbrella. In that sense, I think it's fair to say that numpy is part of the 'scipy family'. I don't know, at least this doesn't particularly bother me.
I built it on a recent ubuntu not too long ago, without any glitches. I can check again tonitght on a fresh Dapper with up-to-date SVN if you want. Cheers, f
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Fernando Perez wrote:
2. Pointing www.numpy.org to numeric.scipy.org instead of the SF page
Pardon me for being a lazy idiot. numeric.scipy.org is a fine place for it. I was reacting to a post a while back that suggested pointing people searching for numpy to the main scipy page, which I did not think was a good idea. Objection withdrawn.
Can you even build it with gcc 4 yet?
Well, I need FC4 (and soon 5) as well as OS-X, so I'll try again when I get the chance. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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
![](https://secure.gravatar.com/avatar/747dbe713fc00913cb5e798754feae7f.jpg?s=120&d=mm&r=g)
[CB]: I was reacting to a post a while back that suggested pointing people [CB]: searching for numpy to the main scipy page, which I did not think was a [CB]: good idea. That would be my post :o) The reasons why I suggested this are 1) www.scipy.org is at the moment the most informative site on numpy 2) of all sites www.scipy.org looks currently most professional 3) a wiki-style site where everyone can contribute is really great 4) I like information to be centralized. Having to check pointers, docs and cookbooks on two different sites is inefficient 5) Two different sites inevitably implies some duplication of the work Just as you, I am not (yet) a scipy user, I only have numpy installed at the moment. The principal reason is the same as the one you mentioned. But for me this is an extra motivation to merge scipy.org and numpy.org: 6) merging scipy.org and numpy.org will hopefully lead to a larger SciPy community and this in turn hopefully leads to user-friendly installation procedures. Cheers, Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
![](https://secure.gravatar.com/avatar/5c85708f2eed0869671a7d303ca55b85.jpg?s=120&d=mm&r=g)
On Fri, 2 Jun 2006 10:27:45 +0200 Joris De Ridder <joris@ster.kuleuven.be> wrote:
My only concern with this is numpy is positioned for a wider audience: everybody who needs arrays, and the extra speed that numpy gives, but doesn't need what scipy gives. So merging the two could lead to confusion on what provides what, and what you need to do which. For instance, I don't want potential numpy users to be directed to scipy.org, and be turned off with all the extra stuff it seems to have (that scipy, not numpy, provides). But I think this can be handled if we approach scipy.org as serving both purposes. But I think is this the best option, considering how much crossover there is. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca
![](https://secure.gravatar.com/avatar/7d25e66cab04d869b99bf41281f11d07.jpg?s=120&d=mm&r=g)
Numeric user since somewhere near "the beginning" (~1996-7?).
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
No. Just dabbling so far.
2) Will you transition within the next 6 months? (if you answered No to #1)
Depends.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
(i) Numpy out-of-the-box build failed on my linux boxes, and I will need to upgrade linux and Windoze simultaneously. (ii) So far, Numeric is still working for me. (iii) Time ... I also have ~200k lines of code to convert. (iv) Like others, I guess I'm waiting for NumPy 1.0 to take a stab.
4) Please provide any suggestions for improving NumPy.
Gary
![](https://secure.gravatar.com/avatar/1bc8694bf55c688b2aa2075eedf9b4c6.jpg?s=120&d=mm&r=g)
We (Enthought) have started.
2) Will you transition within the next 6 months? (if you answered No to #1)
We have a number of deployed applications that use Numeric heavily. Much of our code is now NumPy/Numeric compatible, but it is not well tested on NumPy. That said, a recent large project will be delivered on NumPy this summer, and we are releasing an update to a legacy app using NumPy in the next month or so. Pearu, Travis, and the Numeric->NumPy conversion scripts have been very helpful in this respect. It has been (and remains) a big effort to get the ship turned in the direction of NumPy, but we're committed to it. We are very much looking forward to using its new features.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
Just time right now. We have noticed one major slow down in code, but it is a known issue (scalar math). This was easily fixed with a little weave code in the time being (so now we're actually 2-3 times faster than the old Numeric code. :-)
4) Please provide any suggestions for improving NumPy.
No strong opinions here yet as I (sadly) haven't gotten to use it much yet. The scalar math speed hit us once, so others will probably hit it as well. Thanks again for all the amazing work on this stuff. It has already had an amazing impact on the community involvement and growth. From my own experience, I understand why others are slow to convert. Enthought has wanted to be an early adopter from the beginning, and we are still not there because of the effort involved in conversion and testing along with time pressures from other projects. Still, there is a nice feed back loop that happens here. As scipy/numpy continue to improve (more functionality, 64-bit stability, etc.) and more projects convert over, there are more reasons for people to update their code to the latest and greatest. My bet is it'll take 2-3 more years for the transition to run its course. see ya, eric
![](https://secure.gravatar.com/avatar/38d5ac232150013cbf1a4639538204c0.jpg?s=120&d=mm&r=g)
Hi, On 5/30/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
Yes and No
2) Will you transition within the next 6 months? (if you answered No to #1)
Probably for new code only. Having ported numarray code to NumPy there are too many quirks that need to be found.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
Hopefully 1.0 will be out by then :-). Also bugs and performance will at a similar level to numeric and numarray.
4) Please provide any suggestions for improving NumPy.
The main one at present is to provide a stable release that can serve as a reference point for users. This is more a reflection of having a stable version of numpy for reference rather than having to check the svn for an appropriate version. Bruce
![](https://secure.gravatar.com/avatar/ccb440c822567bba3d49d0ea2894b8a1.jpg?s=120&d=mm&r=g)
In article <447D051E.9000709@ieee.org>, Travis Oliphant <oliphant.travis@ieee.org> wrote:
No, not beyond installing it to see if it works.
2) Will you transition within the next 6 months? (if you answered No to #1)
I expect to start to transition within a few months of both numpy and pyfits-with-numpy being released and being reported as stable and fast.
4) Please provide any suggestions for improving NumPy.
Please improve notification of documentation updates. I keep seeing complaints from folks who've bought the numpy documentation that they get no notification of updates. That makes me very reluctant to buy the documentation myself. I wish that full support for masked arrays had made it in (i.e. masked arrays are first class citizens that are accepted by all functions). The inability in numeric to apply 2d filters on masked image arrays is the main thing missing for me in numarray. -- Russell
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 5/31/06, Alan G Isaac <aisaac@american.edu> wrote:
I'll add my voice on this front. When I've needed a special update (for a workshop, where I needed to print out hardcopies as up-to-date as possible), Travis was very forthcoming and gave me quickly his most recent copy. So while a few weeks ago a couple of emails may not have been replied quite on the spot, overall I don't feel in any way slighted by his handling of the doc system, quite the opposite. And he also indicated he was in the process of setting up a more automated system. To be honest, I'd rather wait for a manual upate than see Travis devote one or two evenings to configuring something of this nature when he could be coding for numpy :) Cheers, f
![](https://secure.gravatar.com/avatar/fd2f4a8c073258ba5e271a16bad7f7c8.jpg?s=120&d=mm&r=g)
On May 31, 2006, at 4:53, Travis Oliphant wrote:
No.
2) Will you transition within the next 6 months? (if you answered No to #1)
I would like to, but I am not sure to find the time. I am not in a hurry either, as Numeric continues to work fine.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
Lack of time. Some of the changes from Numeric are subtle and require a careful analysis of the code, and then careful testing. For big applications, that's a lot of work. There are also modules (I am thinking of RNG) that have been replaced by something completely different that needs to be evaluated first. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: konrad.hinsen@cea.fr ---------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/f351f66930a1449592dd11b288e95cb8.jpg?s=120&d=mm&r=g)
On 10.06.2006, at 01:57, Travis Oliphant wrote:
Thanks, that will facilitate the transition. Is this just a compatible interface, or actually the same algorithm as in the original RNG module? Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: hinsen@cnrs-orleans.fr ---------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/764323a14e554c97ab74177e0bce51d4.jpg?s=120&d=mm&r=g)
konrad.hinsen@laposte.net wrote:
Just the interface. Do you actually want to use the old algorithm, or are you primarily concerned about matching old test results? The old algorithms are not very good, so I really don't want to put them back into numpy. It should be easy to roll out a separate RNG module that simply uses numpy instead of Numeric, though. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
konrad.hinsen@laposte.net wrote:
If I understand your question correctly, then it's just a compatibility interface. I'm not sure which part of the original algorithm you are referring to. The random numbers are generated by the Mersenne Twister algorithm in mtrand. Each generator in numpy.random.oldrng creates a new RandomState for generation using that algorithm. The density function calculations were taken from RNG, but the random-number generators themselves are methods of the RandomState. -Travis
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 5/30/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
Please help the developers by responding to a few questions.
Sorry for not replying before, I wanted a more complete picture before answering.
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
The day this email came in, I had just started to look into porting our major research code. I actually did the work 2 weeks ago, and it went remarkably well. It took a single (marathon) day, about 14 hours of solid work, to go through the old codebase and convert it. This project had a mix of legacy Fortran wrapped via f2py, hand-written C extensions using Numeric, a fair bit of weave.inline() and pure python. It uses matplotlib, PyX and Mayavi for various visualization tasks. There are some 40k loc in the Fortran sources (2/3 of that auto-generated in python from Mathematica computations), and about 13k loc in the C and python sources. This codebase is heavily unit-tested, which was critical for the port. For this kind of effort, unittests make an enormous difference, as they guide you directly to all the problematic spots. Without unittests, this kind of port would have been a nightmare, and I would have never known whether things were actually finished or not. Most of my changes had to do with explicit uses of 'typecode=' which became dtype, and uses of .flat, which used to return a normal array and is now an iterator. I haven't benchmarked things right away, because I expect the numpy-based code to take quite a hit. In this code, I've heavily abused arrays for very trivial 2 and 3-element arithmetic operations, but that means that I create literally millions of extremely small arrays. Even with Numeric, this overhead was already measurable, and I imagine it will get worse with numpy. But since this was silly anyway, and I need to use these little arrays as dictionary keys, instead of doing lots of tuple(array()) all the time, I'm using David Cooke's Vector as a template for a hand-written mini-array class that will do exactly what I need with as little overhead as possible. If for any reason you do want to see actual benchmarks, I can try to run some with the codebases immediately before and after the Numeric->numpy change and report back.
2) Will you transition within the next 6 months? (if you answered No to #1)
That's it: by now we've moved all of our code and it doesn't really work with Numeric anymore, so we're committed :) Again, many thanks for the major improvements that numpy brings! Cheers, f
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 5/30/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
4) Please provide any suggestions for improving NumPy.
Well, if I can beg for one thing, it would be fixing dot(): http://projects.scipy.org/scipy/numpy/ticket/156 This bug is currently stalling us pretty badly, since dot() is at the core of everything we do. While the codebase I alluded to in my previous message is fine, a project that sits on top of it is blocked from moving on due to this particular problem. If it's a problem on our side, I'll gladly correct it, but it does seem like a bug to me (esp. with Stefan's test of r2651 which passes). If there's any extra info that you need from me, by all means let me know an I'll be happy to provide it. If you have a feel for where the problem may be but don't have time to fix it right now, I can look into it myself, if you can point me in the right direction. Cheers, f
![](https://secure.gravatar.com/avatar/915f9e3213021d75d43bb4262167b067.jpg?s=120&d=mm&r=g)
pyOpenGL is one project that hasn't upgraded to numpy yet. http://pyopengl.sourceforge.net/ I think the issue is just that noone is really maintaining it, rather than any difficulty in porting to numpy. Since he's probably not reading this list, might be a good idea to send the project admin a copy of the survey: mcfletch at users.sourceforge.net --bb On 5/31/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
-- William V. Baxter III OLM Digital Kono Dens Building Rm 302 1-8-8 Wakabayashi Setagaya-ku Tokyo, Japan 154-0023 +81 (3) 3422-3380
![](https://secure.gravatar.com/avatar/837d314801b4f1400d6eabc767ca2cac.jpg?s=120&d=mm&r=g)
I am a Numeric user. On 5/30/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
Started transition. Most applications were easily ported to Numpy. I am still deciding whether or not support both Numpy and Numeric during the transition period.
2) Will you transition within the next 6 months? (if you answered No to #1)
Yes, as soon as numpy 1.0 is released.
4) Please provide any suggestions for improving NumPy.
That's a big topic! Without expanding on anything: - optimized array of interned strings (compatible with char** at the C level) - optimized array of arrays (a restriction of dtype=object array) - use BLAS in umath
![](https://secure.gravatar.com/avatar/135b00c97cc7af2e25f4f23b10e02d48.jpg?s=120&d=mm&r=g)
We use Numeric in NetEpi Analysis (www.netepi.org).
No.
2) Will you transition within the next 6 months? (if you answered No to #1)
Unknown - someone will have to fund the work.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
NetEpi Analysis implements C extensions to do fast set options on integer Numeric arrays, as well as to support mmap'ed Numeric arrays. I haven't looked at what is required to port these to Numpy (or replace with native Numpy features). NetEpi Analysis also uses rpy, which will potentially need to be updated to support Numpy. We're also concerned about speed - but I haven't done any testing against the latest Numpy. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
![](https://secure.gravatar.com/avatar/802b07155a8ab3996b825eca778f770e.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Travis Oliphant wrote: Numeric user since 1998. Writing commercial application software for control of machines. The machine is sold with the application software, closed source. | 1) Have you transitioned or started to transition to NumPy (i.e. import | numpy)? No | 2) Will you transition within the next 6 months? (if you answered No to #1) Maybe. | 3) Please, explain your reason(s) for not making the switch. (if you | answered No to #2) We are by now late adopters of everything. Everything else we use (we use about 30 non-GPL opensource packages in our development environment, some of which are using Numeric themselves) will need to migrate as well. Our own code is interspersed with Numeric calls, and amounts to about 200k lines... Rob - -- Rob W.W. Hooft || rob@hooft.net || http://www.hooft.net/people/rob/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEfR/fH7J/Cv8rb3QRAvbjAKCCMLpbBbWSBDsRZZzL0+p4HTqcLACbBwiB YLFwX1oEULCH068j2I7ZoDg= =0gj8 -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/968b818b9553fbf74f79cf4b1db725a2.jpg?s=120&d=mm&r=g)
We use Numeric for our "Atomic Simulation Environment" and for a Density Functional Theory code: http://wiki.fysik.dtu.dk/ASE http://wiki.fysik.dtu.dk/gridcode
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
No.
2) Will you transition within the next 6 months? (if you answered No to #1)
Yes. Only problem is that ASE relies on Konrad Hinsen's Scientific.IO.NetCDF module which is still a Numeric thing. I saw recently that this module has been converted to numpy and put in SciPy/sandbox. What is the future of this module?
4) Please provide any suggestions for improving NumPy.
Can't think of anything! Jens Jørgen Mortensen
![](https://secure.gravatar.com/avatar/fd2f4a8c073258ba5e271a16bad7f7c8.jpg?s=120&d=mm&r=g)
On May 31, 2006, at 8:13, Jens Jørgen Mortensen wrote:
Martin Wiechert recently sent me his adaptation to Numpy. I integrated his patches checking for nothing else but that it doesn't break the Numeric interface. I then checked that it compiles and runs the demo script correctly. I am happy to send this version to anyone who wants to test-drive it. Personally I cannot really test it as all my application code that is based on it requires Numeric. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: konrad.hinsen@cea.fr ---------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/9887fc565eeb83dacd53019357109ba0.jpg?s=120&d=mm&r=g)
Le Mercredi 31 Mai 2006 04:53, Travis Oliphant a écrit :
Please help the developers by responding to a few questions.
I am a numarray user
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
no I tried to install numpy but the installation failed.
2) Will you transition within the next 6 months? (if you answered No to #1)
no, (hm, but if numarray will be prohibited, ...)
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
numarray works and works fine (from version number 0.8 to 1.5)
-- René Bastian http://www.musiques-rb.org http://pythoneon.musiques-rb.org
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
Hi Travis, Here you have the answers for PyTables project (www.pytables.org). A Dimecres 31 Maig 2006 04:53, Travis Oliphant va escriure:
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
Not yet, although suport for it is in-place through the use of the array protocol.
2) Will you transition within the next 6 months? (if you answered No to #1)
We don't know, but other projects in our radar make us to think that we will not be able to do that in this timeframe.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
As I said before, it is mainly a matter of priorities. Also, numarray works very well for PyTables usage, and besides, NumPy 1.0 is not yet there.
4) Please provide any suggestions for improving NumPy.
You are already doing a *great* work. Perhaps pushing numexpr in NumPy would be nice. Also working in introducing a simple array class in Python core and using the array protocol to access the data would be very good. Cheers, --
![](https://secure.gravatar.com/avatar/c248bc10c66731ecd789b0135b635329.jpg?s=120&d=mm&r=g)
On 31/05/2006, at 4:53 AM, Travis Oliphant wrote:
Please help the developers by responding to a few questions.
I've ported my code to NumPy. But I have some suggestions for improving NumPy. I've now entered them as these tickets: Improvements for NumPy's web presence: http://projects.scipy.org/scipy/numpy/ticket/132 Squeeze behaviour for 1d and 0d arrays: http://projects.scipy.org/scipy/numpy/ticket/133 Array creation from sequences: http://projects.scipy.org/scipy/numpy/ticket/134 -- Ed
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Ed Schofield wrote:
Improvements for NumPy's web presence: http://projects.scipy.org/scipy/numpy/ticket/132
From that page: NumPy's web presence could be improved by: 2. Pointing www.numpy.org to numeric.scipy.org instead of the SF page I don't like this. *numpy is not scipy*. It should have it's own page (which would refer to scipy). That page should be something better than the raw sourceforge page, however. A lot of us use numpy without anything else from the scipy project, and scipy is still a major pain in the *&&^* to build. Can you even build it with gcc 4 yet? I like the other ideas. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 5/31/06, Christopher Barker <Chris.Barker@noaa.gov> wrote:
Well, ipython is not scipy either, and yet its homepage is ipython.scipy.org. I think it's simply a matter of convenience that the Enthought hosting infrastructure is so much more pleasant to use than SF, that other projects use scipy.org as an umbrella. In that sense, I think it's fair to say that numpy is part of the 'scipy family'. I don't know, at least this doesn't particularly bother me.
I built it on a recent ubuntu not too long ago, without any glitches. I can check again tonitght on a fresh Dapper with up-to-date SVN if you want. Cheers, f
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Fernando Perez wrote:
2. Pointing www.numpy.org to numeric.scipy.org instead of the SF page
Pardon me for being a lazy idiot. numeric.scipy.org is a fine place for it. I was reacting to a post a while back that suggested pointing people searching for numpy to the main scipy page, which I did not think was a good idea. Objection withdrawn.
Can you even build it with gcc 4 yet?
Well, I need FC4 (and soon 5) as well as OS-X, so I'll try again when I get the chance. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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
![](https://secure.gravatar.com/avatar/747dbe713fc00913cb5e798754feae7f.jpg?s=120&d=mm&r=g)
[CB]: I was reacting to a post a while back that suggested pointing people [CB]: searching for numpy to the main scipy page, which I did not think was a [CB]: good idea. That would be my post :o) The reasons why I suggested this are 1) www.scipy.org is at the moment the most informative site on numpy 2) of all sites www.scipy.org looks currently most professional 3) a wiki-style site where everyone can contribute is really great 4) I like information to be centralized. Having to check pointers, docs and cookbooks on two different sites is inefficient 5) Two different sites inevitably implies some duplication of the work Just as you, I am not (yet) a scipy user, I only have numpy installed at the moment. The principal reason is the same as the one you mentioned. But for me this is an extra motivation to merge scipy.org and numpy.org: 6) merging scipy.org and numpy.org will hopefully lead to a larger SciPy community and this in turn hopefully leads to user-friendly installation procedures. Cheers, Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
![](https://secure.gravatar.com/avatar/5c85708f2eed0869671a7d303ca55b85.jpg?s=120&d=mm&r=g)
On Fri, 2 Jun 2006 10:27:45 +0200 Joris De Ridder <joris@ster.kuleuven.be> wrote:
My only concern with this is numpy is positioned for a wider audience: everybody who needs arrays, and the extra speed that numpy gives, but doesn't need what scipy gives. So merging the two could lead to confusion on what provides what, and what you need to do which. For instance, I don't want potential numpy users to be directed to scipy.org, and be turned off with all the extra stuff it seems to have (that scipy, not numpy, provides). But I think this can be handled if we approach scipy.org as serving both purposes. But I think is this the best option, considering how much crossover there is. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca
![](https://secure.gravatar.com/avatar/7d25e66cab04d869b99bf41281f11d07.jpg?s=120&d=mm&r=g)
Numeric user since somewhere near "the beginning" (~1996-7?).
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
No. Just dabbling so far.
2) Will you transition within the next 6 months? (if you answered No to #1)
Depends.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
(i) Numpy out-of-the-box build failed on my linux boxes, and I will need to upgrade linux and Windoze simultaneously. (ii) So far, Numeric is still working for me. (iii) Time ... I also have ~200k lines of code to convert. (iv) Like others, I guess I'm waiting for NumPy 1.0 to take a stab.
4) Please provide any suggestions for improving NumPy.
Gary
![](https://secure.gravatar.com/avatar/1bc8694bf55c688b2aa2075eedf9b4c6.jpg?s=120&d=mm&r=g)
We (Enthought) have started.
2) Will you transition within the next 6 months? (if you answered No to #1)
We have a number of deployed applications that use Numeric heavily. Much of our code is now NumPy/Numeric compatible, but it is not well tested on NumPy. That said, a recent large project will be delivered on NumPy this summer, and we are releasing an update to a legacy app using NumPy in the next month or so. Pearu, Travis, and the Numeric->NumPy conversion scripts have been very helpful in this respect. It has been (and remains) a big effort to get the ship turned in the direction of NumPy, but we're committed to it. We are very much looking forward to using its new features.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
Just time right now. We have noticed one major slow down in code, but it is a known issue (scalar math). This was easily fixed with a little weave code in the time being (so now we're actually 2-3 times faster than the old Numeric code. :-)
4) Please provide any suggestions for improving NumPy.
No strong opinions here yet as I (sadly) haven't gotten to use it much yet. The scalar math speed hit us once, so others will probably hit it as well. Thanks again for all the amazing work on this stuff. It has already had an amazing impact on the community involvement and growth. From my own experience, I understand why others are slow to convert. Enthought has wanted to be an early adopter from the beginning, and we are still not there because of the effort involved in conversion and testing along with time pressures from other projects. Still, there is a nice feed back loop that happens here. As scipy/numpy continue to improve (more functionality, 64-bit stability, etc.) and more projects convert over, there are more reasons for people to update their code to the latest and greatest. My bet is it'll take 2-3 more years for the transition to run its course. see ya, eric
![](https://secure.gravatar.com/avatar/38d5ac232150013cbf1a4639538204c0.jpg?s=120&d=mm&r=g)
Hi, On 5/30/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
Yes and No
2) Will you transition within the next 6 months? (if you answered No to #1)
Probably for new code only. Having ported numarray code to NumPy there are too many quirks that need to be found.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
Hopefully 1.0 will be out by then :-). Also bugs and performance will at a similar level to numeric and numarray.
4) Please provide any suggestions for improving NumPy.
The main one at present is to provide a stable release that can serve as a reference point for users. This is more a reflection of having a stable version of numpy for reference rather than having to check the svn for an appropriate version. Bruce
![](https://secure.gravatar.com/avatar/ccb440c822567bba3d49d0ea2894b8a1.jpg?s=120&d=mm&r=g)
In article <447D051E.9000709@ieee.org>, Travis Oliphant <oliphant.travis@ieee.org> wrote:
No, not beyond installing it to see if it works.
2) Will you transition within the next 6 months? (if you answered No to #1)
I expect to start to transition within a few months of both numpy and pyfits-with-numpy being released and being reported as stable and fast.
4) Please provide any suggestions for improving NumPy.
Please improve notification of documentation updates. I keep seeing complaints from folks who've bought the numpy documentation that they get no notification of updates. That makes me very reluctant to buy the documentation myself. I wish that full support for masked arrays had made it in (i.e. masked arrays are first class citizens that are accepted by all functions). The inability in numeric to apply 2d filters on masked image arrays is the main thing missing for me in numarray. -- Russell
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 5/31/06, Alan G Isaac <aisaac@american.edu> wrote:
I'll add my voice on this front. When I've needed a special update (for a workshop, where I needed to print out hardcopies as up-to-date as possible), Travis was very forthcoming and gave me quickly his most recent copy. So while a few weeks ago a couple of emails may not have been replied quite on the spot, overall I don't feel in any way slighted by his handling of the doc system, quite the opposite. And he also indicated he was in the process of setting up a more automated system. To be honest, I'd rather wait for a manual upate than see Travis devote one or two evenings to configuring something of this nature when he could be coding for numpy :) Cheers, f
![](https://secure.gravatar.com/avatar/fd2f4a8c073258ba5e271a16bad7f7c8.jpg?s=120&d=mm&r=g)
On May 31, 2006, at 4:53, Travis Oliphant wrote:
No.
2) Will you transition within the next 6 months? (if you answered No to #1)
I would like to, but I am not sure to find the time. I am not in a hurry either, as Numeric continues to work fine.
3) Please, explain your reason(s) for not making the switch. (if you answered No to #2)
Lack of time. Some of the changes from Numeric are subtle and require a careful analysis of the code, and then careful testing. For big applications, that's a lot of work. There are also modules (I am thinking of RNG) that have been replaced by something completely different that needs to be evaluated first. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: konrad.hinsen@cea.fr ---------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/f351f66930a1449592dd11b288e95cb8.jpg?s=120&d=mm&r=g)
On 10.06.2006, at 01:57, Travis Oliphant wrote:
Thanks, that will facilitate the transition. Is this just a compatible interface, or actually the same algorithm as in the original RNG module? Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: hinsen@cnrs-orleans.fr ---------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/764323a14e554c97ab74177e0bce51d4.jpg?s=120&d=mm&r=g)
konrad.hinsen@laposte.net wrote:
Just the interface. Do you actually want to use the old algorithm, or are you primarily concerned about matching old test results? The old algorithms are not very good, so I really don't want to put them back into numpy. It should be easy to roll out a separate RNG module that simply uses numpy instead of Numeric, though. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
konrad.hinsen@laposte.net wrote:
If I understand your question correctly, then it's just a compatibility interface. I'm not sure which part of the original algorithm you are referring to. The random numbers are generated by the Mersenne Twister algorithm in mtrand. Each generator in numpy.random.oldrng creates a new RandomState for generation using that algorithm. The density function calculations were taken from RNG, but the random-number generators themselves are methods of the RandomState. -Travis
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 5/30/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
Please help the developers by responding to a few questions.
Sorry for not replying before, I wanted a more complete picture before answering.
1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?
The day this email came in, I had just started to look into porting our major research code. I actually did the work 2 weeks ago, and it went remarkably well. It took a single (marathon) day, about 14 hours of solid work, to go through the old codebase and convert it. This project had a mix of legacy Fortran wrapped via f2py, hand-written C extensions using Numeric, a fair bit of weave.inline() and pure python. It uses matplotlib, PyX and Mayavi for various visualization tasks. There are some 40k loc in the Fortran sources (2/3 of that auto-generated in python from Mathematica computations), and about 13k loc in the C and python sources. This codebase is heavily unit-tested, which was critical for the port. For this kind of effort, unittests make an enormous difference, as they guide you directly to all the problematic spots. Without unittests, this kind of port would have been a nightmare, and I would have never known whether things were actually finished or not. Most of my changes had to do with explicit uses of 'typecode=' which became dtype, and uses of .flat, which used to return a normal array and is now an iterator. I haven't benchmarked things right away, because I expect the numpy-based code to take quite a hit. In this code, I've heavily abused arrays for very trivial 2 and 3-element arithmetic operations, but that means that I create literally millions of extremely small arrays. Even with Numeric, this overhead was already measurable, and I imagine it will get worse with numpy. But since this was silly anyway, and I need to use these little arrays as dictionary keys, instead of doing lots of tuple(array()) all the time, I'm using David Cooke's Vector as a template for a hand-written mini-array class that will do exactly what I need with as little overhead as possible. If for any reason you do want to see actual benchmarks, I can try to run some with the codebases immediately before and after the Numeric->numpy change and report back.
2) Will you transition within the next 6 months? (if you answered No to #1)
That's it: by now we've moved all of our code and it doesn't really work with Numeric anymore, so we're committed :) Again, many thanks for the major improvements that numpy brings! Cheers, f
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 5/30/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
4) Please provide any suggestions for improving NumPy.
Well, if I can beg for one thing, it would be fixing dot(): http://projects.scipy.org/scipy/numpy/ticket/156 This bug is currently stalling us pretty badly, since dot() is at the core of everything we do. While the codebase I alluded to in my previous message is fine, a project that sits on top of it is blocked from moving on due to this particular problem. If it's a problem on our side, I'll gladly correct it, but it does seem like a bug to me (esp. with Stefan's test of r2651 which passes). If there's any extra info that you need from me, by all means let me know an I'll be happy to provide it. If you have a feel for where the problem may be but don't have time to fix it right now, I can look into it myself, if you can point me in the right direction. Cheers, f
participants (24)
-
Alan G Isaac
-
Andrew McNamara
-
Bill Baxter
-
Bruce Southey
-
Christopher Barker
-
David M. Cooke
-
Ed Schofield
-
eric
-
Fernando Perez
-
Francesc Altet
-
Gary Strangman
-
Jens Jørgen Mortensen
-
Jonathan Taylor
-
Joris De Ridder
-
Konrad Hinsen
-
konrad.hinsen@laposte.net
-
Pujo Aji
-
René Bastian
-
Rob Hooft
-
Robert Kern
-
Russell E. Owen
-
Sasha
-
Travis Oliphant
-
Travis Oliphant