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: [EMAIL PROTECTED] --------------------------------------------------------------------- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion