Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Jonathan T. <jon...@ut...>]

+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 <oli...@ee...> 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
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>