Re: [Numpy-discussion] [MMTK] Re: Fwd: Collection.findTransformation() never stops

[<kon...@la...>]

On 19.09.2006, at 18:48, Christopher Barker wrote:

> Konrad Hinsen wrote:
>> MMTK works fine with Numeric 23.x (and probably many other versions),
>> so I don't see a pressing need to change to NumPy.
>
> Pressing is in the eye of the beholder.

Obviously. It also depends on the context in which one develops or =20
uses software. For me, a pressing need is to finish the two =20
publications I am working on. Next come various administrational =20
tasks that have a deadline. On the third place, there's work on a new =20=

research project that I started recently. Software development is at =20
best on position number 4, but in that category my personal =20
priorities are adding more unit tests and reworking the MMTK =20
documentation system, the old one being unusable because various =20
pieces of code it relied on are no longer supported.

As with many other scientific software projects, MMTK development is =20
completely unfunded and even hardly recognized by my employer's =20
evaluation committees. Any work on MMTK that does not help me in a =20
research project can therefore not be a priority for me.

> However: I don't think we should underestimate the negative impact of
> the Numeric/numarray split on the usability and perception of the
> community. Also the impact on how much work has been done to =20
> accommodate  it. If you consider matplotlib alone:

I completely agree. The existence of a third choice (NumPy) just =20
makes it worse. For client code like mine there is little chance to =20
escape from the split issues. Even if I had the resources to adapt =20
all my code to NumPy immediately, I'd still have to support Numeric =20
because that's what everyone is using at the moment, and many users =20
can't or won't switch immediately. Since the APIs are not fully =20
compatible, I either have to support two versions in parallel, or =20
introduce my own compatibility layer.

> In addition, as I understand it, MMTK was NOT working fine for the OP.

The issues he had were already solved, he just had to apply the =20
solutions (i.e. reinstall using a more recent version and appropriate =20=

compilation options).

> As robust as they (and Numeric) might be, when you need to run
> something on a new platform (OS-X - Intel comes to mind), or use a new
> LAPACK, or whatever, there are going to be (and have been) issues that
> need to be addressed. No one is maintaining Numeric, so it makes much
> more sense to put your effort into porting to numpy, rather than =20
> trying
> to fix or work around Numeric issues.

In the long run, I agree. But on the time scale on which is what my =20
work conditions force me to plan, it is less work for me to provide =20
patches for Numeric as the need arises.

> PS: this really highlights the strength of having good unit tests: as
> far as i can tell, it's really not that much work to do the port -- =20=

> the
> work is in the testing. Comprehensive units tests would make that part
> trivial too.

Yes, testing is the bigger chunk of the work. And yes, unit tests are =20=

nice to have - but they don't write themselves, unfortunately.

Konrad.
--
---------------------------------------------------------------------
Konrad Hinsen
Centre de Biophysique Mol=E9culaire, CNRS Orl=E9ans
Synchrotron Soleil - Division Exp=E9riences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: hi...@cn...
---------------------------------------------------------------------