[Numpy-discussion] Time for beta1 of NumPy 1.0
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/_sp_imports.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 nd_image, 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.function_base.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