[Numpy-discussion] Fwd: Collection.findTransformation() never stops
Dr. Seth Olsen
seth.olsen at gmail.com
Tue Sep 19 02:26:08 CDT 2006
I would very happily accept the Scientific and MMTK patches. Thank you very
much for the offer.
I hadn't thought much about it until very recently, when the advent of a new
IT structure in our laboratory forced me to upgrade my existing software.
It was then that it became obvious that the LAPACK routines called by
Numeric and MMTK were refusing to work. I've spent the day trying to
wrestle with the problem (I am by no means an expert). I finally decided to
get around the problems by altering the problem-solving routines in MMTK by
using routines from numpy and then immediately applying a=Numeric.array(
a.tolist()), which has stopped my script from gagging (although I have still
to demonstrate to myself that everything is working). The uses to which I
apply MMTK usually mean that the matrices in question are pretty small, so I
don't have to worry too much about speed.
I was suprised to note, however, that a straightforward application of F2PY
to some fresh downloaded LAPACK F77 code did not work, and sent my machine
into a similar endless whirr as I had seen at the beginning of the day.
Apparently there's something sinister going on...
On 9/19/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
> Dr. Seth Olsen wrote:
> > Hi Bill,
> > MMTK has not made the conversion over to the new numpy module. It is
> > built against the old Numeric code, and the word from its developers
> > is that changing to numpy cannot be a priority now.
> My suggestion is to *kindly* put pressure on them.
> I've spent at least a hundred hours making it easy for people to port
> Numeric and Numarray-built code to NumPy. Because of this, I'm a
> little bit frustrated by this kind of response. I understand it will
> take time for people to migrate, but it really does not take that long
> to port code to use NumPy.
> I've offered to do it for any open source code. In fact, I just spent
> 30 minutes and ported both Scientific Python and MMTK to use numpy.
> I'll send you a patch if you want. It is true, that the result needs
> to be better tested, but I'm confident that any errors which might
> remain in the compatibility layer will be easily fixable (and we need
> people who are willing to do the tests to fix them).
> I'd rather not do this, but if necessary we can easily create an SVN
> tree of third-party packages ported to use NumPy if the package-owners
> are not willing to do it. Keeping Numeric packages around except for
> legacy systems will only make things harder.
> I'll repeat the same offer I've made before: I will gladly give my book
> and my help to any open source library author who will make porting to
> NumPy a priority for their package. Note, however, my (free) ports to
> use NumPy do not use any "numerix-style" layer. The library is
> converted to work with NumPy alone. In other words, I won't spend any
> more "spare" time supporting 3 array packages.
> Best regards,
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> opinions on IT & business topics through brief surveys -- and earn cash
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
Dr Seth Olsen, PhD
Postdoctoral Fellow, Biomolecular Modeling Group
Centre for Computational Molecular Science
Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
The University of Queensland
Qld 4072, Brisbane, Australia
tel (617) 3346 3976
fax (617) 33654623
email: s.olsen1 at uq.edu.au
The opinions expressed here are my own and do not reflect the positions of
the University of Queensland.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion