[Numpy-discussion] Time for beta1 of NumPy 1.0 (original) (raw)

Jonathan Taylor jonathan.taylor at utoronto.ca
Fri Jun 30 14:42:33 EDT 2006

+1 for some sort of float. I am a little confused as to why Float64 is a particularly good choice. Can someone explain in more detail? Presumably this is the most sensible ctype and translates to a python float well?

In general though I agree that this is a now or never change. I suspect we will change a lot of matlab -> Numeric/numarray transitions into matlab -> numpy transitions with this change.

I guess it will take a little longer for 1.0 to get out though :( Ah well.

Cheers. Jon.

On 6/30/06, Travis Oliphant <oliphant at ee.byu.edu> wrote:

Jon,

Thanks for the great feedback. You make some really good points. > > >Having {pointer + dimensions + strides + type} in the python core would >be an incredible step forward - this is far more important than changing >my python code to do functionally the same thing with numpy instead of >Numeric. > Guido has always wanted consensus before putting things into Python. We need to rally behind NumPy if we are going to get something of it's infrastructure into Python itself. >As author of a (fairly obscure) secondary dependency package it is not >clear that this is right time to convert. I very much admire the >matplotlib approach of using Numerix and see this as a better solution >than switching (or indeed re-writing in java/c++ etc). > I disagree with this approach. It's fine for testing and for transition, but it is a headache long term. You are basically supporting three packages. The community is not large enough to do that. I also think it leads people to consider adopting that approach instead of just switching. I'm not particularly thrilled with strategies that essentially promote the existence of three different packages. >However, looking >into the matplotlib SVN I see: > >image.cpp 2420 4 weeks cmoad applied Andrew Straw's >numpy patch >numerix/spimports.py 2478 2 weeks teoliphant Make >recent changes backward compatible with numpy 0.9.8 >numerix/linearalgebra/init.py 2474 2 weeks teoliphant > Fix import error for new numpy > >While I didn't look at either the code or the diff the comments clearly >read as: "DON'T SWITCH YET". > I don't understand why you interpret it that way? When I moved old-style names to numpy.oldnumeric for SVN numpy, I needed to make sure that matplotlib still works with numpy 0.9.8 (which has the old-style names in the main location). Why does this say "DON'T SWITCH"? If anything it should tell you that we are conscious of trying to keep things working together and compatible with current releases of NumPy. >Get the basearray into the python core and >for sure I will be using that, whatever it is called. I was tempted to >switch to numarray in the past because of the ndimage, but I don't see >that in numpy just yet? > > It is in SciPy where it belongs (you can also install it as a separate package). It builds and runs on top of NumPy just fine. In fact it was the predecessor to the now fully-capable-but-in-need-of-more-testing numarray C-API that is now in NumPy. >I am very supportive of the work going on but have some technical >concerns about switching. To pick some examples, it appears that >numpy.lib.functionbase.median makes a copy, sorts and picks the middle >element. > I'm sure we need lots of improvements in the code-base. This has always been true. We rely on the ability of contributors which doesn't work well unless we have a lot of contributors which are hard to get unless we consolidate around a single array package. Please contribute a fix. >single one routine out, I was also saddened to find both Numeric and >numpy use double precision lapack routines for single precision >arguments. > The point of numpy.linalg is to provide the functionality of Numeric not extend it. This is because SciPy provides a much more capable linalg sub-package that works with single and double precision. It sounds like you want SciPy. >For numpy to really be better than Numeric I would like to find >algorithm selections according to the array dimensions and type. > These are good suggestions but for SciPy. The linear algebra in NumPy is just for getting your feet wet and having access to basic functionality. >Getting >the basearray type into the python core is the key - then it makes sense >to get the best of breed algorithms working as you can rely on the >basearray being around for many years to come. > >Please please please get basearray into the python core! How can we help >with that? > > There is a PEP in SVN (see the array interface link at http://numeric.scipy.org) Karol Langner is a Google summer-of-code student working on it this summer. I'm not sure how far he'll get, but I'm hopeful. I could spend more time on it, if I had funding to do it, but right now I'm up against a wall. Again, thanks for the feedback. Best, -Travis

Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list