I am a Numeric user. On 5/30/06, Travis Oliphant wrote:

Please help the developers by responding to a few questions.

1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?

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

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

On 5/31/06, Travis Oliphant wrote:

Please help the developers by responding to a few questions.

I'm a Numeric user.

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) No

3) Please, explain your reason(s) for not making the switch. (if you answered No to #2) Numeric is ok and the conversion somehow make my unittest fail.....

4) Please provide any suggestions for improving NumPy.

I think the conversion between Numpy and numeric should be compatible......

Thanks for your answers.

NumPy Developers

------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion

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

Please help the developers by responding to a few questions.

1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?

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

Thanks for your answers.

NumPy Developers

------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion

In article <447D051E.9000709@ieee.org>, Travis Oliphant wrote:

Please help the developers by responding to a few questions.

1) Have you transitioned or started to transition to NumPy (i.e. import numpy)?

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

On 5/30/06, Travis Oliphant 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