getting numPy happening for sciPy
Hello There, I'm pretty new to Python, picking it up recently in order to begin to experiment with Csound / Python interconnectivity (generating scores, GUI elements, using Vpython to model mechanical "systems"... that sort of thing...) Have so far written about 500 lines of Python code (over the last few weeks) to do various housekeeping of of my Csound .sco's & beginning to play with some Python / Csound score generative stuff. Sowhen it comes to Python i'm a novice, but with some grasp of the basics. Anyway, I wanted to "beef up" my python arsenal with some of the SciPY stuff - initially a wider & more solid range of random number generators, histograms & statistical packages etc. So it is with some regret that i see at present that it is not possible to build SciPy on top of the standard "out the box" NumPy installation? I am not an experienced programmer, so the idea of building NumPy from the "bleeding edge" repository is beyond my capability, as there appears to be no specific instructions for how to do this (that don't assume you have some degree of experience at what your doing anyway.. ) So I guess my question is 1) can i get an idiots guide to what's required to get the current NumPy installation happening in order to host SciPy on top of it? 2) if 1) involves a whole lot of faffing about & acquiring a whole heap of new skill set (that only really has limited long term relevance to me, & isn't likely to stick in my head very long anyway) - how long do I have to wait before i can just run a new NumPy installer, followed by a SciPy installer, & get the full kit & kaboodle happening? Regrettably, I'm on Win XP. Thanks for any help or advice. Can't imaging i'll be having too much of a contribution to this community, but will be interested to see what sort of topics float through the NumPY world.... with thanks Tim - Adelaide, Australia.
Hi Tim On Mon, Jul 23, 2007 at 08:20:24PM +0930, Tim Mortimer wrote:
I am not an experienced programmer, so the idea of building NumPy from the "bleeding edge" repository is beyond my capability, as there appears to be no specific instructions for how to do this (that don't assume you have some degree of experience at what your doing anyway.. )
So I guess my question is
1) can i get an idiots guide to what's required to get the current NumPy installation happening in order to host SciPy on top of it?
One way is to use Enthoughts egg installer: http://code.enthought.com/enstaller/ That way, you won't have linear algebra routines optimised specifically for your platform, but you'll have a fully functional numpy, scipy (and optionally matplotlib etc.) installation. Regards Stéfan
Tim Mortimer wrote:
Anyway, I wanted to "beef up" my python arsenal with some of the SciPY stuff - initially a wider & more solid range of random number generators, histograms & statistical packages etc.
So it is with some regret that i see at present that it is not possible to build SciPy on top of the standard "out the box" NumPy installation?
I am not an experienced programmer, so the idea of building NumPy from the "bleeding edge" repository is beyond my capability, as there appears to be no specific instructions for how to do this (that don't assume you have some degree of experience at what your doing anyway.. )
So I guess my question is
1) can i get an idiots guide to what's required to get the current NumPy installation happening in order to host SciPy on top of it?
2) if 1) involves a whole lot of faffing about & acquiring a whole heap of new skill set (that only really has limited long term relevance to me, & isn't likely to stick in my head very long anyway) - how long do I have to wait before i can just run a new NumPy installer, followed by a SciPy installer, & get the full kit & kaboodle happening?
Regrettably, I'm on Win XP.
G'day Tim: I don't know of any simple build instructions for Windows, but if you're patient, there will probably be updated packaged releases of SciPy + NumPy that play well together "real soon now". Regards, Steve
Steven H. Rogers wrote:
I don't know of any simple build instructions for Windows, but if you're patient, there will probably be updated packaged releases of SciPy + NumPy that play well together "real soon now".
We'll need a volunteer release manager for that, or it won't happen. Most of the principals are very busy right now. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
2007/7/23, Les Schaffer <schaffer@optonline.net>:
Robert Kern wrote:
We'll need a volunteer release manager for that, or it won't happen. Most of the principals are very busy right now.
will it compile with Visual C++ 2005 Express? if so, i'd give it a try.
Windows binaries must be compiled with the same compiler as Python, so it is (sadly IMHO) Visual 2003. Well in fact, I could install one if needed (I have a licence) Matthieu
Matthieu Brucher wrote:
Windows binaries must be compiled with the same compiler as Python, so it is (sadly IMHO) Visual 2003. Well in fact, I could install one if needed (I have a licence)
i am going to see if my department can grab a license. if so, i would be willing to collaborate to keep Numpy/Scipy current on Windows. even though i prefer linux for my own work, i find my physics students haven't all made the switch to the light side. Les
Robert Kern wrote:
Steven H. Rogers wrote:
I don't know of any simple build instructions for Windows, but if you're patient, there will probably be updated packaged releases of SciPy + NumPy that play well together "real soon now".
We'll need a volunteer release manager for that, or it won't happen. Most of the principals are very busy right now.
I thought I saw signs that something would be happening soon. What would be the scope of this release manager's responsibilities? # Steve
Steven H. Rogers wrote:
Robert Kern wrote:
Steven H. Rogers wrote:
I don't know of any simple build instructions for Windows, but if you're patient, there will probably be updated packaged releases of SciPy + NumPy that play well together "real soon now".
We'll need a volunteer release manager for that, or it won't happen. Most of the principals are very busy right now.
I thought I saw signs that something would be happening soon.
Real life got in the way.
What would be the scope of this release manager's responsibilities?
1) Make a numpy 1.0.3.1 point release. Some changes in 1.0.3-2 which should have only made changes to the files included in the numpy source tarball also seem to impair building scipy. We would need to branch from the 1.0.3 tag to fix this. I don't think the changes to numpy.distutils in the trunk have been vetted enough for making a numpy 1.0.4 release. Here is some information on the mechanics of this: http://projects.scipy.org/scipy/numpy/wiki/MakingReleases 2) Make a scipy 0.5.3 release. Deciding what goes in is mostly a matter of announcing a cutoff date to make sure people don't have half of a refactoring in. 3) The release manager will need to make sure that the releases build and run their test suite on at least the Big Three: Windows, some kind of Linux, and Mac OS X. Usually, they will need to delegate for some of these platforms. The binary builds for Windows should be provided for download along with the source. 4) Binaries: Windows binaries are pretty much necessary. If possible, try to use an ATLAS library that does *not* use SSE2 instructions. We have had problems with people getting segfaults on older hardware. scipy binaries should *not* include FFTW or UMFPACK since they are GPLed. I can help with OS X binaries now that I've finally figured out how to get scipy to link statically against the gfortran runtime. 5) The tarballs and binaries should be uploaded to the Sourceforge site. The Cheeseshop records should be updated to record the new versions. An announcement should be made to python-announce and the relevant mailing lists. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
Steven H. Rogers wrote:
Robert Kern wrote:
Steven H. Rogers wrote:
I don't know of any simple build instructions for Windows, but if you're patient, there will probably be updated packaged releases of SciPy + NumPy that play well together "real soon now".
We'll need a volunteer release manager for that, or it won't happen. Most of the principals are very busy right now.
I thought I saw signs that something would be happening soon.
Real life got in the way.
Yes, life happens.
What would be the scope of this release manager's responsibilities?
1) Make a numpy 1.0.3.1 point release. Some changes in 1.0.3-2 which should have only made changes to the files included in the numpy source tarball also seem to impair building scipy. We would need to branch from the 1.0.3 tag to fix this. I don't think the changes to numpy.distutils in the trunk have been vetted enough for making a numpy 1.0.4 release. Here is some information on the mechanics of this:
http://projects.scipy.org/scipy/numpy/wiki/MakingReleases
2) Make a scipy 0.5.3 release. Deciding what goes in is mostly a matter of announcing a cutoff date to make sure people don't have half of a refactoring in.
3) The release manager will need to make sure that the releases build and run their test suite on at least the Big Three: Windows, some kind of Linux, and Mac OS X. Usually, they will need to delegate for some of these platforms. The binary builds for Windows should be provided for download along with the source.
4) Binaries: Windows binaries are pretty much necessary. If possible, try to use an ATLAS library that does *not* use SSE2 instructions. We have had problems with people getting segfaults on older hardware. scipy binaries should *not* include FFTW or UMFPACK since they are GPLed. I can help with OS X binaries now that I've finally figured out how to get scipy to link statically against the gfortran runtime.
5) The tarballs and binaries should be uploaded to the Sourceforge site. The Cheeseshop records should be updated to record the new versions. An announcement should be made to python-announce and the relevant mailing lists.
Unfortunately, I can't see committing to something like this now. I might be able to start in November if no one else volunteers.
Steven H. Rogers wrote:
Robert Kern wrote:
Steven H. Rogers wrote:
Robert Kern wrote:
Steven H. Rogers wrote:
I don't know of any simple build instructions for Windows, but if you're patient, there will probably be updated packaged releases of SciPy + NumPy that play well together "real soon now".
We'll need a volunteer release manager for that, or it won't happen. Most of the principals are very busy right now.
I thought I saw signs that something would be happening soon.
Real life got in the way.
Yes, life happens.
What would be the scope of this release manager's responsibilities?
1) Make a numpy 1.0.3.1 point release. Some changes in 1.0.3-2 which should have only made changes to the files included in the numpy source tarball also seem to impair building scipy. We would need to branch from the 1.0.3 tag to fix this. I don't think the changes to numpy.distutils in the trunk have been vetted enough for making a numpy 1.0.4 release. Here is some information on the mechanics of this:
http://projects.scipy.org/scipy/numpy/wiki/MakingReleases
2) Make a scipy 0.5.3 release. Deciding what goes in is mostly a matter of announcing a cutoff date to make sure people don't have half of a refactoring in.
3) The release manager will need to make sure that the releases build and run their test suite on at least the Big Three: Windows, some kind of Linux, and Mac OS X. Usually, they will need to delegate for some of these platforms. The binary builds for Windows should be provided for download along with the source.
4) Binaries: Windows binaries are pretty much necessary. If possible, try to use an ATLAS library that does *not* use SSE2 instructions. We have had problems with people getting segfaults on older hardware. scipy binaries should *not* include FFTW or UMFPACK since they are GPLed. I can help with OS X binaries now that I've finally figured out how to get scipy to link statically against the gfortran runtime.
5) The tarballs and binaries should be uploaded to the Sourceforge site. The Cheeseshop records should be updated to record the new versions. An announcement should be made to python-announce and the relevant mailing lists.
I am willing to volunteer for the scipy part: I have quite extensive experience with building on linux now, and I can now build on windows without too much difficulties (I mean hardware-wise).
Concerning the release date: it basically means giving enough time to solve the current bugs, right ? I solved a few bugs from the 0.5.3 milestone, but some of them are outside my knowledge (weave, linalg bugs which depend on fortran code). David
David Cournapeau wrote:
I am willing to volunteer for the scipy part: I have quite extensive experience with building on linux now, and I can now build on windows without too much difficulties (I mean hardware-wise).
Concerning the release date: it basically means giving enough time to solve the current bugs, right ?
There are too many. Build bugs should be fixed and anything that impairs the functioning of whole packages. Incorporating patches already submitted would be the next priority. Fixing isolated little bugs can be pushed back.
I solved a few bugs from the 0.5.3 milestone, but some of them are outside my knowledge (weave, linalg bugs which depend on fortran code).
You're much too modest. That was hardly "a few bugs." You've been a great help. Thank you. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
David Cournapeau wrote:
I am willing to volunteer for the scipy part: I have quite extensive experience with building on linux now, and I can now build on windows without too much difficulties (I mean hardware-wise).
Concerning the release date: it basically means giving enough time to solve the current bugs, right ?
There are too many. Build bugs should be fixed and anything that impairs the functioning of whole packages. Incorporating patches already submitted would be the next priority. Fixing isolated little bugs can be pushed back.
I thought that releasing something before the end of summer would be a good release date: a new release is available before the beginning of the new "university" year. Would you agree on a date like end of august ? (if I become the release manager, this is also more compatible with my schedule). For the bugs, I was not talking about all the bugs in trac, but the ones in 0.5.3 milestone (10-11 bugs, I think). David
David Cournapeau wrote:
Robert Kern wrote:
David Cournapeau wrote:
I am willing to volunteer for the scipy part: I have quite extensive experience with building on linux now, and I can now build on windows without too much difficulties (I mean hardware-wise).
Concerning the release date: it basically means giving enough time to solve the current bugs, right ?
There are too many. Build bugs should be fixed and anything that impairs the functioning of whole packages. Incorporating patches already submitted would be the next priority. Fixing isolated little bugs can be pushed back.
I thought that releasing something before the end of summer would be a good release date: a new release is available before the beginning of the new "university" year. Would you agree on a date like end of august ? (if I become the release manager, this is also more compatible with my schedule).
For the bugs, I was not talking about all the bugs in trac, but the ones in 0.5.3 milestone (10-11 bugs, I think).
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Actually 8 tickets http://projects.scipy.org/scipy/scipy/query?status=new&status=assigned&status=reopened&milestone=0.5.3+Release Ticket #389 can be closed. It's already fixed. AFAIK Dmitrey is working on ticket #464. I didn't check the patch by bart for ticket #360. IMHO ticket #406 is not so important for 0.5.3 release. I cannot reproduce the problem concerning #401. It is Mac specific problem. Am I missing something ? Nils
On Jul 27, 2007, at 2:42 AM, Nils Wagner wrote:
I cannot reproduce the problem concerning #401. It is Mac specific problem. Am I missing something ?
I can't reproduce this problem either. I just yesterday built scipy from SVN on two different OS X 10.4.10 boxes, one using the fortran compiler from hpc.sourceforge.net (not the latest 2007 release, but the december 2006 one), and the other using the compiler from r.research.att.com/tools. Everything else was similar, and everything worked fine with regard to ticket 401. On the other hand, when I tried to compile scipy using the latest (2007-05) gfortran from hpc.sourceforge.net, I got bizarre link errors about MACOSX_DEPLOYMENT_TARGET being set incorrectly. (See previous email here http://projects.scipy.org/pipermail/scipy-user/ 2007-June/012542.html ). Interestingly, with the earlier version of gfortran from hpc.sourceforge.net, and with the r.research.att.com/ tools version, this problem does not arise. Anyhow, my point is that there are still odd linker errors (as in ticket 401) lurking that may or may not have anything to do with scipy per se, but might have to do with odd and perhaps buggy builds of gfortran. Feh -- I wish Apple would just start including a fortran compiler with the rest of their dev tools. The situation otherwise is not good. Zach
participants (9)
-
David Cournapeau -
Les Schaffer -
Matthieu Brucher -
Nils Wagner -
Robert Kern -
Stefan van der Walt -
Steven H. Rogers -
Tim Mortimer -
Zachary Pincus