Menu
▾
▴
numpy-discussion
|
From: Dr. S. O. <set...@gm...> - 2006-09-19 00:52:00
|
Hi Numpyers, I recently sent the message below to the MMTK mailing list, but it's really a problem with LinearAlgebra.py. The routine LinearAlgebra.eigenvectors() never stops, even when I try to diagonalize a very simple 2x2 matrix. I've tried this on two machines with completely standard FC4 and FC5 installations using the default libraries and atlas libraries downloaded and installed via yum. Does anyone on this list have any experience with this problem? Cheers, Seth ---------- Forwarded message ---------- From: Dr. Seth Olsen <set...@gm...> Date: Sep 19, 2006 10:38 AM Subject: Re: Collection.findTransformation() never stops To: mm...@py..., mm...@st... Hi MMTKers, The problem with Collection.findTransformation() that I reported earlier is due to a problem with LinearAlgebra.eigenvectors(). This algortithm does not seem to stop - it can't even manage to find the eigenvectors of the 2x2 square matrix [[2,1],[1,2]]. Asking for this causes a long wait followed by CPU overheat warnings. Moreover, I have recompiled Numeric23.8 with newly installed atlas libraries, but it still won't work. I have had this problem now on 2 machines (one running FC4 with , the other FC5, both pentium 4 machines), with atlas lapack/blas libraries installed freshly via yum and linked as per the recommendations found in setup.py. THE FEDORA INSTALLATIONS ON BOTH MACHINES IS STANDARD - everything has been downloaded and installed via the fedora yum repositories. As the eigenvectors() routine in LinearAlgebra.py is obviously going to be a heavily used algorithm (not just in MMTK), is it really possible that no one has had this problem before? Cheers, Seth On 9/18/06, Dr. Seth Olsen <set...@gm...> wrote: > > > Hi MMTKers, > > I'm having a bit of trouble with MMTK.Collection.findTransformation. When > I use this member function, the computer never stops thinking until I kill > the process. I've waited a couple of hours and still nothing. I get the > same thing if I try to take a step back and use > Collection.findTransformationAsQuaternion. Has anyone had this problem > before? > > Cheers, > > Seth > > -- > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > 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.o...@uq... > Web: www.ccms.uq.edu.au > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > The opinions expressed here are my own and do not reflect the positions of > the University of Queensland. > -- ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms 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.o...@uq... Web: www.ccms.uq.edu.au ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms The opinions expressed here are my own and do not reflect the positions of the University of Queensland. -- ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms 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.o...@uq... Web: www.ccms.uq.edu.au ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms The opinions expressed here are my own and do not reflect the positions of the University of Queensland. |
|
From: Dr. S. O. <set...@gm...> - 2006-09-19 07:26:14
|
Hi Travis, 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... Cheers, Seth On 9/19/06, Travis Oliphant <oli...@ie...> 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, > > -Travis > > > ------------------------------------------------------------------------- > 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 > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > -- ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms 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.o...@uq... Web: www.ccms.uq.edu.au ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms The opinions expressed here are my own and do not reflect the positions of the University of Queensland. |
|
From: Travis O. <oli...@ie...> - 2006-09-19 08:44:30
|
Dr. Seth Olsen wrote: > > Hi Travis, > > I would very happily accept the Scientific and MMTK patches. Thank > you very much for the offer. Look at http://www.scipy.org/Porting_to_NumPy for information (and patches) on how to convert ScientificPython and MMTK to use NumPy. I managed to get the codes to build and install but they are not tested. Any problems you encounter would be useful to know about. You can patch the code by changing to the top-level directory and entering patch -p1 < patch_file If it works for you, please email the developers and let them know how easy it can be (hopefully). Best, -Travis |
|
From: Piotr L. S <lus...@cs...> - 2006-09-19 14:22:04
|
Seth, this problem is most likely related to LAPACK's SLAMCH and DLAMCH routines. If these routines get translated with f2c the compiler can optimize things away and create infinite loops. This functions get called when you start using singular and eigenvalue routines. It's because Fortran 77 didn't have a way to specify "volatile" storage. In any case, you can avoid the problem by linking different SLAMCH and DLAMCH routines. I'm attaching two possible impementations that use C99 and Fortran 95. Probably you'll have to ensure that name mangling occurs correctly (rename slamch to slamch_ and dlamch to dlamch_). Piotr On Tuesday 19 September 2006 03:26, Dr. Seth Olsen wrote: > Hi Travis, > > 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... > > Cheers, > > Seth > > On 9/19/06, Travis Oliphant <oli...@ie...> 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, > > > > -Travis > > > > > > ------------------------------------------------------------------- > >------ 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 > > Num...@li... > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion |
|
From: Christopher B. <Chr...@no...> - 2006-09-19 16:48:40
|
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.
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:
Effort to write the "numerix" compatibility layer
Effort to support problems people have with incompatibility
Effort to build binaries that support all the packages
Effort to do extra testing to determine whether a given problem is
caused by a different numerix back-end.
This really adds up!
Because of this, it IS a pressing need to get as much stuff converted as
possible.
In addition, as I understand it, MMTK was NOT working fine for the OP.
this is also the case for a variety of other codes that depend on
Numeric. 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.
This is also a great time to get help with porting issues -- see Travis'
recent message.
-Chris
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.
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
|
|
From: <kon...@la...> - 2006-09-20 07:41:26
|
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... --------------------------------------------------------------------- |
|
From: Travis O. <oli...@ie...> - 2006-09-19 18:42:46
|
Konrad Hinsen wrote: > On Sep 19, 2006, at 5:11, Dr. Seth Olsen wrote: > > >> Bill's answer to my inquiry about the problem I'm having with >> Collection.findTransformation() (and also, incidentally, with the >> dgesvd call in Subspace.getBasis(), has convinced me that I can no >> long use MMTK without changing some of the code over to numpy. I >> have already been able to determine that invoking >> numpy.oldnumeric.alter_code1.convertall() over the MMTK directory >> tree is not the answer. Has anyone on either of these lists ever >> tried this before and, if so, can it be done (without destroying my >> sanity)? >> > > Adapting MMTK to NumPy is likely to be a major effort, in particular > for the C modules. Well, I got both ScientificPython and MMTK to compile and import using the steps outlined on http://www.scipy.org/Porting_to_NumPy in about 1 hour (including time to fix alter_code1 to make the process even easier). C-modules are actually easier to port because the Numeric C-API is totally supported. > A lot ot testing would also be required. If anyone > wants to tackle this, > I'd be happy to see the results. Great. I can totally understand people not having the time, but it is fantastic to hear that the willingness to accept patches is there. I was able to install ScientificPython and MMTK for NumPy on my system using the patches provided on that page. Is there a test suite that can be run? Users of MMTK could really help out here. -Travis |
|
From: <kon...@la...> - 2006-09-20 07:45:32
|
On 19.09.2006, at 20:42, Travis Oliphant wrote: > Well, I got both ScientificPython and MMTK to compile and import =20 > using > the steps outlined on http://www.scipy.org/Porting_to_NumPy in =20 > about 1 > hour (including time to fix alter_code1 to make the process even =20 > easier). Could you please send me those versions? I'd happily put them on my =20 Web site for volunteers to test. > I was able to install ScientificPython and MMTK for NumPy on my system > using the patches provided on that page. Is there a test suite that > can be run? Not much yet, unfortunately. There is a minuscule test suite for =20 ScientificPython in the latest release, and an even more miniscule =20 one for MMTK that I didn't even publish yet because it doesn't test =20 more than that everything can be imported. > Users of MMTK could really help out here. I hope so! 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... --------------------------------------------------------------------- |
|
From: Bill B. <wb...@gm...> - 2006-09-19 01:34:53
|
Hey there,
I don't see anything called "LinearAlgegra.eigenvectors()". Do you
maybe mean numpy.linalg.eig?
Which version of numpy are you using?
The latest release is 1.0b5.
>>> import numpy
>>> numpy.__version__
'1.0b5'
>>> numpy.linalg.eig([[2,1],[1,2]])
(array([ 3., 1.]),
array([[ 0.70710678, -0.70710678],
[ 0.70710678, 0.70710678]]))
I'm on WindowsXP, though.
Regards,
Bill
On 9/19/06, Dr. Seth Olsen <set...@gm...> wrote:
>
> Hi Numpyers,
>
> I recently sent the message below to the MMTK mailing list, but it's really
> a problem with LinearAlgebra.py. The routine LinearAlgebra.eigenvectors()
> never stops, even when I try to diagonalize a very simple 2x2 matrix. I've
> tried this on two machines with completely standard FC4 and FC5
> installations using the default libraries and atlas libraries downloaded and
> installed via yum. Does anyone on this list have any experience with this
> problem?
>
> Cheers,
>
> Seth
>
> ---------- Forwarded message ----------
> From: Dr. Seth Olsen <set...@gm... >
> Date: Sep 19, 2006 10:38 AM
> Subject: Re: Collection.findTransformation() never stops
> To: mm...@py..., mm...@st...
>
>
> Hi MMTKers,
>
> The problem with Collection.findTransformation() that I reported earlier is
> due to a problem with LinearAlgebra.eigenvectors(). This algortithm does
> not seem to stop - it can't even manage to find the eigenvectors of the 2x2
> square matrix [[2,1],[1,2]]. Asking for this causes a long wait followed by
> CPU overheat warnings. Moreover, I have recompiled Numeric23.8 with newly
> installed atlas libraries, but it still won't work. I have had this problem
> now on 2 machines (one running FC4 with , the other FC5, both pentium 4
> machines), with atlas lapack/blas libraries installed freshly via yum and
> linked as per the recommendations found in setup.py. THE FEDORA
> INSTALLATIONS ON BOTH MACHINES IS STANDARD - everything has been downloaded
> and installed via the fedora yum repositories.
>
> As the eigenvectors() routine in LinearAlgebra.py is obviously going to be a
> heavily used algorithm (not just in MMTK), is it really possible that no one
> has had this problem before?
>
> Cheers,
>
> Seth
>
>
> On 9/18/06, Dr. Seth Olsen <set...@gm...> wrote:
> >
> >
> > Hi MMTKers,
> >
> > I'm having a bit of trouble with
> MMTK.Collection.findTransformation. When I use this member
> function, the computer never stops thinking until I kill the process. I've
> waited a couple of hours and still nothing. I get the same thing if I try
> to take a step back and use
> Collection.findTransformationAsQuaternion. Has anyone had
> this problem before?
> >
> > Cheers,
> >
> > Seth
> >
> > --
> >
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> >
> > 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.o...@uq...
> > Web: www.ccms.uq.edu.au
> >
> >
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > The opinions expressed here are my own and do not reflect the positions of
> the University of Queensland.
>
>
>
> --
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
>
> 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.o...@uq...
> Web: www.ccms.uq.edu.au
>
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> The opinions expressed here are my own and do not reflect the positions of
> the University of Queensland.
>
> --
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
>
> 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.o...@uq...
> Web: www.ccms.uq.edu.au
>
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> The opinions expressed here are my own and do not reflect the positions of
> the University of Queensland.
> -------------------------------------------------------------------------
> 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
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>
|
|
From: Dr. S. O. <set...@gm...> - 2006-09-19 02:06:29
|
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. Cheers, Seth On 9/19/06, Bill Baxter <wb...@gm...> wrote: > > Hey there, > I don't see anything called "LinearAlgegra.eigenvectors()". Do you > maybe mean numpy.linalg.eig? > Which version of numpy are you using? > The latest release is 1.0b5. > > >>> import numpy > >>> numpy.__version__ > '1.0b5' > > >>> numpy.linalg.eig([[2,1],[1,2]]) > (array([ 3., 1.]), > array([[ 0.70710678, -0.70710678], > [ 0.70710678, 0.70710678]])) > > I'm on WindowsXP, though. > Regards, > Bill > > On 9/19/06, Dr. Seth Olsen <set...@gm...> wrote: > > > > Hi Numpyers, > > > > I recently sent the message below to the MMTK mailing list, but it's > really > > a problem with LinearAlgebra.py. The routine LinearAlgebra.eigenvectors > () > > never stops, even when I try to diagonalize a very simple 2x2 > matrix. I've > > tried this on two machines with completely standard FC4 and FC5 > > installations using the default libraries and atlas libraries downloaded > and > > installed via yum. Does anyone on this list have any experience with > this > > problem? > > > > Cheers, > > > > Seth > > > > ---------- Forwarded message ---------- > > From: Dr. Seth Olsen <set...@gm... > > > Date: Sep 19, 2006 10:38 AM > > Subject: Re: Collection.findTransformation() never stops > > To: mm...@py..., mm...@st... > > > > > > Hi MMTKers, > > > > The problem with Collection.findTransformation() that I reported earlier > is > > due to a problem with LinearAlgebra.eigenvectors(). This algortithm > does > > not seem to stop - it can't even manage to find the eigenvectors of the > 2x2 > > square matrix [[2,1],[1,2]]. Asking for this causes a long wait > followed by > > CPU overheat warnings. Moreover, I have recompiled Numeric23.8 with > newly > > installed atlas libraries, but it still won't work. I have had this > problem > > now on 2 machines (one running FC4 with , the other FC5, both pentium 4 > > machines), with atlas lapack/blas libraries installed freshly via yum > and > > linked as per the recommendations found in setup.py. THE FEDORA > > INSTALLATIONS ON BOTH MACHINES IS STANDARD - everything has been > downloaded > > and installed via the fedora yum repositories. > > > > As the eigenvectors() routine in LinearAlgebra.py is obviously going to > be a > > heavily used algorithm (not just in MMTK), is it really possible that no > one > > has had this problem before? > > > > Cheers, > > > > Seth > > > > > > On 9/18/06, Dr. Seth Olsen <set...@gm...> wrote: > > > > > > > > > Hi MMTKers, > > > > > > I'm having a bit of trouble with > > MMTK.Collection.findTransformation. When I use this member > > function, the computer never stops thinking until I kill the > process. I've > > waited a couple of hours and still nothing. I get the same thing if I > try > > to take a step back and use > > Collection.findTransformationAsQuaternion. Has anyone had > > this problem before? > > > > > > Cheers, > > > > > > Seth > > > > > > -- > > > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > > > > 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.o...@uq... > > > Web: www.ccms.uq.edu.au > > > > > > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > The opinions expressed here are my own and do not reflect the > positions of > > the University of Queensland. > > > > > > > > -- > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > > 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.o...@uq... > > Web: www.ccms.uq.edu.au > > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > The opinions expressed here are my own and do not reflect the positions > of > > the University of Queensland. > > > > -- > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > > 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.o...@uq... > > Web: www.ccms.uq.edu.au > > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > The opinions expressed here are my own and do not reflect the positions > of > > the University of Queensland. > > > ------------------------------------------------------------------------- > > 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 > > Num...@li... > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > > > > > > ------------------------------------------------------------------------- > 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 > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > -- ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms 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.o...@uq... Web: www.ccms.uq.edu.au ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms The opinions expressed here are my own and do not reflect the positions of the University of Queensland. |
|
From: Dr. S. O. <set...@gm...> - 2006-09-19 03:11:40
|
Hi MMTKers and NUMPYers, Bill's answer to my inquiry about the problem I'm having with Collection.findTransformation() (and also, incidentally, with the dgesvd call in Subspace.getBasis(), has convinced me that I can no long use MMTK without changing some of the code over to numpy. I have already been able to determine that invoking numpy.oldnumeric.alter_code1.convertall() over the MMTK directory tree is not the answer. Has anyone on either of these lists ever tried this before and, if so, can it be done (without destroying my sanity)? Cheers, Seth On 9/19/06, Dr. Seth Olsen <set...@gm...> 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. > > Cheers, > > Seth > > > On 9/19/06, Bill Baxter <wb...@gm...> wrote: > > > > Hey there, > > I don't see anything called "LinearAlgegra.eigenvectors()". Do you > > maybe mean numpy.linalg.eig? > > Which version of numpy are you using? > > The latest release is 1.0b5. > > > > >>> import numpy > > >>> numpy.__version__ > > '1.0b5' > > > > >>> numpy.linalg.eig([[2,1],[1,2]]) > > (array([ 3., 1.]), > > array([[ 0.70710678, -0.70710678], > > [ 0.70710678, 0.70710678]])) > > > > I'm on WindowsXP, though. > > Regards, > > Bill > > > > On 9/19/06, Dr. Seth Olsen <set...@gm...> wrote: > > > > > > Hi Numpyers, > > > > > > I recently sent the message below to the MMTK mailing list, but it's > > really > > > a problem with LinearAlgebra.py. The routine > > LinearAlgebra.eigenvectors() > > > never stops, even when I try to diagonalize a very simple 2x2 > > matrix. I've > > > tried this on two machines with completely standard FC4 and FC5 > > > installations using the default libraries and atlas libraries > > downloaded and > > > installed via yum. Does anyone on this list have any experience with > > this > > > problem? > > > > > > Cheers, > > > > > > Seth > > > > > > ---------- Forwarded message ---------- > > > From: Dr. Seth Olsen <set...@gm... > > > > Date: Sep 19, 2006 10:38 AM > > > Subject: Re: Collection.findTransformation() never stops > > > To: mm...@py..., mm...@st... > > > > > > > > > Hi MMTKers, > > > > > > The problem with Collection.findTransformation() that I reported > > earlier is > > > due to a problem with LinearAlgebra.eigenvectors(). This algortithm > > does > > > not seem to stop - it can't even manage to find the eigenvectors of > > the 2x2 > > > square matrix [[2,1],[1,2]]. Asking for this causes a long wait > > followed by > > > CPU overheat warnings. Moreover, I have recompiled Numeric23.8 with > > newly > > > installed atlas libraries, but it still won't work. I have had this > > problem > > > now on 2 machines (one running FC4 with , the other FC5, both pentium > > 4 > > > machines), with atlas lapack/blas libraries installed freshly via yum > > and > > > linked as per the recommendations found in setup.py . THE FEDORA > > > INSTALLATIONS ON BOTH MACHINES IS STANDARD - everything has been > > downloaded > > > and installed via the fedora yum repositories. > > > > > > As the eigenvectors() routine in LinearAlgebra.py is obviously going > > to be a > > > heavily used algorithm (not just in MMTK), is it really possible that > > no one > > > has had this problem before? > > > > > > Cheers, > > > > > > Seth > > > > > > > > > On 9/18/06, Dr. Seth Olsen < set...@gm...> wrote: > > > > > > > > > > > > Hi MMTKers, > > > > > > > > I'm having a bit of trouble with > > > MMTK.Collection.findTransformation . When I use this member > > > function, the computer never stops thinking until I kill the > > process. I've > > > waited a couple of hours and still nothing. I get the same thing if I > > try > > > to take a step back and use > > > Collection.findTransformationAsQuaternion. Has anyone had > > > this problem before? > > > > > > > > Cheers, > > > > > > > > Seth > > > > > > > > -- > > > > > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > > > > > > 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.o...@uq... > > > > Web: www.ccms.uq.edu.au > > > > > > > > > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > > The opinions expressed here are my own and do not reflect the > > positions of > > > the University of Queensland. > > > > > > > > > > > > -- > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > > > > 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.o...@uq... > > > Web: www.ccms.uq.edu.au > > > > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > The opinions expressed here are my own and do not reflect the > > positions of > > > the University of Queensland. > > > > > > -- > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > > > > 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.o...@uq... > > > Web: www.ccms.uq.edu.au > > > > > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > The opinions expressed here are my own and do not reflect the > > positions of > > > the University of Queensland. > > > > > ------------------------------------------------------------------------- > > > 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 > > > Num...@li... > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > 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 > > Num...@li... > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > > > > -- > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > 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.o...@uq... > Web: www.ccms.uq.edu.au > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > The opinions expressed here are my own and do not reflect the positions of > the University of Queensland. > -- ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms 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.o...@uq... Web: www.ccms.uq.edu.au ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms The opinions expressed here are my own and do not reflect the positions of the University of Queensland. |
|
From: Travis O. <oli...@ie...> - 2006-09-19 05:12:03
|
Dr. Seth Olsen wrote: > > Hi MMTKers and NUMPYers, > > Bill's answer to my inquiry about the problem I'm having with > Collection.findTransformation() (and also, incidentally, with the > dgesvd call in Subspace.getBasis(), has convinced me that I can no > long use MMTK without changing some of the code over to numpy. I have > already been able to determine that invoking > numpy.oldnumeric.alter_code1.convertall() over the MMTK directory tree > is not the answer. Why not? It should be. That is the recommended way to begin porting code. If we need to improve alter_code, we cannot do it unless we receive bug reports. Please tell us what difficulty you had. -Travis |
|
From: Konrad H. <kon...@la...> - 2006-09-19 16:05:49
|
On Sep 19, 2006, at 5:11, Dr. Seth Olsen wrote: > Bill's answer to my inquiry about the problem I'm having with =20 > Collection.findTransformation() (and also, incidentally, with the =20 > dgesvd call in Subspace.getBasis(), has convinced me that I can no =20 > long use MMTK without changing some of the code over to numpy. I =20 > have already been able to determine that invoking =20 > numpy.oldnumeric.alter_code1.convertall() over the MMTK directory =20 > tree is not the answer. Has anyone on either of these lists ever =20 > tried this before and, if so, can it be done (without destroying my =20= > sanity)? Adapting MMTK to NumPy is likely to be a major effort, in particular =20 for the C modules. A lot ot testing would also be required. If anyone =20= wants to tackle this, I'd be happy to see the results. Personally, I =20 don't expect to find time for this soon. MMTK works fine with Numeric 23.x (and probably many other versions), =20= so I don't see a pressing need to change to NumPy. 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... --------------------------------------------------------------------- |
|
From: Travis O. <oli...@ie...> - 2006-09-19 06:43:03
|
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, -Travis |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X