Mailman 3 June 2002 - SciPy-Dev

scipy on irix -- problems with bsplines
by eric jones 04 Jul '02

04 Jul '02

SciPy builds failed in the signal module when trying to build on an SGI system. Has anyone seen the following error when building something on IRIX with gcc 2.95.2? 25 sgi> gcc -c C_bspline_util.c C_bspline_util.c: In function `C_IIR_order1': C_bspline_util.c:28: Unable to access real part of complex value in a hard register on this target 26 sgi> gcc -c Z_bspline_util.c 27 sgi> It happens in several of the bspline files for complex values, but not for double complex. The relevant lines of code from bspline_util.c are: 21 void 22 C_IIR_order1 (a1, a2, x, y, N, stridex, stridey) 23 __complex__ float a1; 24 __complex__ float a2; 25 __complex__ float *x; 26 __complex__ float *y; 27 int N, stridex, stridey; 28 { 29 __complex__ float *yvec = y+stridey; 30 __complex__ float *xvec = x+stridex; 31 int n; 32 33 for (n=1; n < N; n++) { 34 *yvec = *xvec * a1 + *(yvec-stridey) * a2; 35 yvec += stridey; 36 xvec += stridex; 37 } 38 } The only references I saw on the net were to previous problems when building libstdc++ with 2.95.1 on SGI and ALPHA machines. The good news is, other than this problem, SciPy builds on IRIX using gcc and linking to the blas and scs(lapack) platform specific libraries. I also tried building python with MIPSPro C compiler and then SciPy using The MIPSPro compiler suite. The python build worked fine after getting readline issues sorted out, and it appeared to work fine. However, python core dumped in the middle of building the flapack wrappers with f2py, so it looks like something is working quite right in the python build. I'd like to get this working, so if anyone has built SciPy/Python entirely with MIPSPro, fill me in on the secrets. Thanks, eric

2 6

Install fails on Solaris 5.7
by Tom Loredo 28 Jun '02

28 Jun '02

Hi folks- Just downloaded the latest snapshot: SciPy-0.2.0_alpha_103.3567. The install chugs along fine until it reaches fastumath: scipy_base.fastumath fastumath needs fortran libraries 0 0 building 'scipy_base.fastumath' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/home/laplace/include/python2.2 -c /home/laplace/src/python/SciPy-0.2.0_alpha_103.3567/scipy_base/fastumathmodule.c -o build/temp.solaris-2.7-sun4u-2.2/fastumathmodule.o /home/laplace/src/python/SciPy-0.2.0_alpha_103.3567/scipy_base/fastumathmodule.c:24:36: fastumath_nounsigned.inc: No such file or directory /home/laplace/include/python2.2/Numeric/arrayobject.h:275: warning: `PyArray_API' defined but not used /home/laplace/include/python2.2/Numeric/ufuncobject.h:131: warning: `PyUFunc_API' defined but not used error: command 'gcc' failed with exit status 1 I can't find any .inc files anywhere in the snapshot; I don't know if that's what's causing the failure or not. Any hints? Thanks, Tom

2 1

adding LAPACK and BLAS to the source code
by eric jones 25 Jun '02

25 Jun '02

Hey group, Apologies if you get this twice -- we had a mail list hiccup earlier this week, and I don't think this went out correctly. We just had the unpleasant experience of getting SciPy to build on the Sun architecture. In the end, it didn't prove that hard -- it was all the mis-steps that were painful. Most of SciPy builds without a hitch -- it is only the LAPACK and BLAS stuff that causes major problems. The issue is that many LAPACK's are built with vendor specific compilers instead of g77, so getting the correct libraries to link in when compiling with distutils is a major headache. And, once the link works, the headaches continue with chasing down random seg-faults that appear to come from incompatible library ABI issues. We worked with ATLAS for a while, but finally backed off to working with just the standard LAPACK and BLAS. The result was a pain free build because gcc and g77 were used all the way through. I expect building everything with the Sun compilers would also go fairly smoothly using this approach. It seems like most of the questions we get on building SciPy have to do with ATLAS and linear algebra. On windows and Linux, we about have this problem licked. But its still difficult on platforms with multiple compilers. So, I am planning to put LAPACK and BLAS into the SciPy CVS so that they are built with the same compiler as the rest of SciPy and no longer have to be built separately. This will increase the repository size substantially (LAPACK is big), but has little other side effects. We'll set up the building of LAPACK and BLAS so that they are optional -- if you have ATLAS or other LAPACK libraries you'd like to use, you can specify them in the site.cfg package -- or at least specify that system_info should search for them. This search will be turned off by default, however, so that incompatible lapack/blas/atlas libraries are not found. I think this will ease the build process for everyone and still allows for using the optimized libraries. If there are no major objections, please let me know. If not, I'll make the addition Tuesday or Wednesday. Eric

5 12

[ANN] SciPy '02 - Python for Scientific Computing Workshop
by Travis N. Vaught 25 Jun '02

25 Jun '02

Apologies if you are receiving this a second time. (mailing list problems should be fixed now) ---------------------------------------- Python for Scientific Computing Workshop ---------------------------------------- CalTech, Pasadena, CA Septemer 5-6, 2002 http://www.scipy.org/site_content/scipy02 This workshop provides a unique opportunity to learn and affect what is happening in the realm of scientific computing with Python. Attendees will have the opportunity to review the available tools and how they apply to specific problems. By providing a forum for developers to share their Python expertise with the wider industrial, academic, and research communities, this workshop will foster collaboration and facilitate the sharing of software components, techniques and a vision for high level language use in scientific computing. The two-day workshop will be a mix of invited talks and training sessions in the morning. The afternoons will be breakout sessions with the intent of getting standardization of tools and interfaces. The cost of the workshop is $50.00 and includes 2 breakfasts and 2 lunches on Sept. 5th and 6th, one dinner on Sept. 5th, and snacks during breaks. There is a limit of 50 attendees. Should we exceed the limit of 50 registrants, the 50 persons selected to attend will be invited individually by the organizers. Discussion about the conference may be directed to the SciPy-user mailing list: mailto:scipy-user@scipy.org http://www.scipy.org/MailList ------------- Co-Hosted By: ------------- The National Biomedical Computation Resource (NBCR, SDSC, San Diego, CA) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ http://nbcr.sdsc.edu The mission of the National Biomedical Computation Resource at the San Diego Supercomputer Center is to conduct, catalyze, and enable biomedical research by harnessing advanced computational technology. The Center for Advanced Computing Research (CACR, CalTech, Pasadena, CA) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ http://nbcr.sdsc.edu CACR is dedicated to the pursuit of excellence in the field of high-performance computing, communication, and data engineering. Major activities include carrying out large-scale scientific and engineering applications on parallel supercomputers and coordinating collaborative research projects on high-speed network technologies, distributed computing and database methodologies, and related topics. Our goal is to help further the state of the art in scientific computing. Enthought, Inc. (Austin, TX) ^^^^^^^^^^^^^^^ http://enthought.com Enthought, Inc. provides business and scientific computing solutions through software development, consulting and training. Enthought also fosters the development of SciPy, an open source library of scientific tools for Python.

2 2

adding LAPACK and BLAS to the source code
by Chuck Harris 24 Jun '02

24 Jun '02

> > We're not really forking since I doubt we make any > modifications -- its > purely a logistical issue. We already have code from > FFTPACK, ODEPACK, > FITPACK, cephes, amos, etc. in SciPy. We have made a few > modifications > in these to get them working on newer compilers, etc., but nothing to > major. There kept there just to make building SciPy easier. LAPACK > would be included for the same reason. > > Eric > Perhaps prebuilt libraries could be made available for optional download. They are already available on the net, but it can be a pain chasing them down and getting them installed. And maybe they still don't work. At least links to working versions would be helpful. Chuck > _______________________________________________ > Scipy-dev mailing list > Scipy-dev(a)scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev >

1 0

Test - please ignore
by adam＠scipy.com 22 Jun '02

22 Jun '02

Hi folks, I'm running some tests on the scipy mailing lists, as we've had a couple of problems with bounces lately. Please pardon my dust. Thank you, Adam

1 0

adding LAPACK and BLAS to the source code
by eric jones 21 Jun '02

21 Jun '02

Hey group, We just had the unpleasant experience of getting SciPy to build on the Sun architecture. In the end, it didn't prove that hard -- it was all the mis-steps that were painful. Most of SciPy builds without a hitch -- it is only the LAPACK and BLAS stuff that causes major problems. The issue is that many LAPACK's are built with vendor specific compilers instead of g77, so getting the correct libraries to link in when compiling with distutils is a major headache. And, once the link works, the headaches continue with chasing down random seg-faults. These appear to come from the library issues. We worked with ATLAS for a while, but finally backed off to working with just the standard LAPACK and BLAS. The result was a pain free build because gcc and g77 were used all the way through. I expect building everything with the Sun compilers would also go fairly smoothly using this approach. It seems like most of the questions we get on building SciPy have to do with ATLAS and linear algebra. On windows and Linux, we about have this problem licked. But its still difficult on platforms with multiple compilers. So, I am planning to put LAPACK and BLAS into the SciPy CVS so that they are built with the same compiler as the rest of SciPy and no longer have to be built separately. This will increase the repository size substantially (LAPACK is big), but has little other side effects. We'll set up the building of LAPACK and BLAS so that they are optional -- if you have ATLAS or other LAPACK libraries you'd like to use, you can specify them in the site.cfg package -- or at least specify that system_info should search for them. This search will be turned off by default, however, so that incompatible lapack/blas/atlas libraries are not found. I think this will ease the build process for everyone and still allows for using the optimized libraries. If there are no major objections, please let me know. If not, I'll make the addition Tuesday or Wednesday. Eric

1 0

ADV: Direct email blaster, email addresses extractor, maillist verify, maillist manager...........
by targetemailextractor＠btamail.net.cn 21 Jun '02

21 Jun '02

1 0

Virus Alert
by Engineering Staff 20 Jun '02

20 Jun '02

The mail message (file: rights.pif) you sent to wrseay(a)cwnetdg.io contains a virus (WORM_KLEZ.H). (on DGAccess)

1 0

[ANN] SciPy '02 - Python for Scientific Computing Workshop
by Travis N. Vaught 17 Jun '02

17 Jun '02

---------------------------------------- Python for Scientific Computing Workshop ---------------------------------------- CalTech, Pasadena, CA Septemer 5-6, 2002 http://www.scipy.org/site_content/scipy02 This workshop provides a unique opportunity to learn and affect what is happening in the realm of scientific computing with Python. Attendees will have the opportunity to review the available tools and how they apply to specific problems. By providing a forum for developers to share their Python expertise with the wider industrial, academic, and research communities, this workshop will foster collaboration and facilitate the sharing of software components, techniques and a vision for high level language use in scientific computing. The two-day workshop will be a mix of invited talks and training sessions in the morning. The afternoons will be breakout sessions with the intent of getting standardization of tools and interfaces. The cost of the workshop is $50.00 and includes 2 breakfasts and 2 lunches on Sept. 5th and 6th, one dinner on Sept. 5th, and snacks during breaks. There is a limit of 50 attendees. Should we exceed the limit of 50 registrants, the 50 persons selected to attend will be invited individually by the organizers. Discussion about the conference may be directed to the SciPy-user mailing list: mailto:scipy-user@scipy.org http://www.scipy.org/MailList ------------- Co-Hosted By: ------------- The National Biomedical Computation Resource (NBCR, SDSC, San Diego, CA) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ http://nbcr.sdsc.edu The mission of the National Biomedical Computation Resource at the San Diego Supercomputer Center is to conduct, catalyze, and enable biomedical research by harnessing advanced computational technology. The Center for Advanced Computing Research (CACR, CalTech, Pasadena, CA) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ http://nbcr.sdsc.edu CACR is dedicated to the pursuit of excellence in the field of high-performance computing, communication, and data engineering. Major activities include carrying out large-scale scientific and engineering applications on parallel supercomputers and coordinating collaborative research projects on high-speed network technologies, distributed computing and database methodologies, and related topics. Our goal is to help further the state of the art in scientific computing. Enthought, Inc. (Austin, TX) ^^^^^^^^^^^^^^^ http://enthought.com Enthought, Inc. provides business and scientific computing solutions through software development, consulting and training.

1 0