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

[konrad.hinsen at laposte.net]

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  
uses software. For me, a pressing need is to finish the two  
publications I am working on. Next come various administrational  
tasks that have a deadline. On the third place, there's work on a new  
research project that I started recently. Software development is at  
best on position number 4, but in that category my personal  
priorities are adding more unit tests and reworking the MMTK  
documentation system, the old one being unusable because various  
pieces of code it relied on are no longer supported.

As with many other scientific software projects, MMTK development is  
completely unfunded and even hardly recognized by my employer's  
evaluation committees. Any work on MMTK that does not help me in a  
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  
> accommodate  it. If you consider matplotlib alone:

I completely agree. The existence of a third choice (NumPy) just  
makes it worse. For client code like mine there is little chance to  
escape from the split issues. Even if I had the resources to adapt  
all my code to NumPy immediately, I'd still have to support Numeric  
because that's what everyone is using at the moment, and many users  
can't or won't switch immediately. Since the APIs are not fully  
compatible, I either have to support two versions in parallel, or  
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  
solutions (i.e. reinstall using a more recent version and appropriate  
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  
> trying
> to fix or work around Numeric issues.

In the long run, I agree. But on the time scale on which is what my  
work conditions force me to plan, it is less work for me to provide  
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 --  
> 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  
nice to have - but they don't write themselves, unfortunately.

Konrad.
--
---------------------------------------------------------------------
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: hinsen at cnrs-orleans.fr
---------------------------------------------------------------------