Re: [Numpy-discussion] Re: Purchasing Documentation

[Francesc A. <fa...@ca...>]

A Divendres 07 Octubre 2005 14:51, Perry Greenfield va escriure:
> Our basic position has been and continues to be that if scipy_core provid=
es
> all the capabilities that we need, we will switch to it. We have been
> involved in installing it on the platforms we need it for (namely Solaris,
> which has proven difficult to build on) and testing it (which is ongoing).
> So far things look pretty promising and barring any unforseen problems, we
> will likely begin porting recarray to it next week. As Travis has already
> mentioned, the whole point of scipy_core was to unify the two existing
> projects, not introduce a 3rd. I have been involved all along in design a=
nd
> interface discussions with Travis on this
> project.

Ok. That's clear enough and satifies my curiosity, thank you. I must
confess, though, that I'm a bit disappointed becuase I was hoping that
numarray, now that has arrived to maturity, was going to stay for long
time (as any other good piece of software deserves). Anyway, as a
long-time user of numarray I can't express enough my gratitude towards
you and your team for suporting and enhancing a beast like numarray,
that introduced a lot of new features that missed Numeric and that
without it all of our current projects (and I guess many others around
the world) simply would not have been possible.

> We will maintain numarray until the point at which we switch all of our
> code to scipy_core (i.e., all libraries and applications that depend on
> it). This may take several months for some (likely the most work is for C
> extensions that use the numarray C-API).

Yeah, I do think so. However, what it worries me is, in my (limited)
experience, that substituting large packages like Numeric or numarray,
is not a trivial task at all (after all, how much time took until
numarray was able to be a good substitute of Numeric?). So, I forsee a
transitional time no shorter than a year before arriving to the high
standards of quality that numarray has nowadays. This is why I'm not
precisely eager to quickly switch to scipy_core until it has proven to
be, at least, as solid as it is numarray.

Having said that, we are in the mood of offering our implementation of
a NestedRecArray class that allows nested fields in RecArray objects.
This class has been included in PyTables for some months and has
proven to be stable, comes with a nice set of unit tests, and is
highly efficient (at least, as much as RecArray for most operations).

Also, until ready-for-production scipy_core arrives, I'd ask you (and
the maintainers of scipy_core) to provide an array protocol to share
data as efficiently as possible between numarray and scipy_core, just
to easy the transition between the packages. If you want, we will be
happy to collaborate on that area as well.

> While I appreciate the pain that this may cause those who have written
> C-extensions for numarray, it's hard to deny that unification will bring
> great benefits. It's as much pain for us as anyone.

Sure, but migration work is not the biggest problem (hopefully) for
us. As I said before, the key point to migrate to scipy_core is to
make sure that is stable enough, featured enough, coner-cases-proof
enough and well-documented enough as it is numarray now.

Thanks again for all your work in numarray,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"