Release of SciPy Core 0.4 (Beta)
![](https://secure.gravatar.com/avatar/4d021a1d1319f36ad861ebef0eb5ba44.jpg?s=120&d=mm&r=g)
This is to announce the release of SciPy Core 0.4.X (beta) It is available at sourceforge which you can access by going to http://numeric.scipy.org Thanks to all who helped me with this release, especially Robert Kern Pearu Peterson Now, let's start getting this stable.... -Travis Oliphant
![](https://secure.gravatar.com/avatar/8185be81060345a47ca63640f135529c.jpg?s=120&d=mm&r=g)
On Fri, 30 Sep 2005 00:59:22 -0600 Travis Oliphant <oliphant@ee.byu.edu> wrote:
I have found two problems: (1) scipy_core-0.4.1 does not compile on this system without ATLAS, because there are missing files: ... creating build/temp.linux-i686-2.4/lapack_lite compile options: '-Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/usr/include/python2.4 -c' gcc: scipy/corelib/lapack_lite/lapack_litemodule.c gcc: lapack_lite/dlapack_lite.c gcc: lapack_lite/dlapack_lite.c: No such file or directory gcc: no input files gcc: lapack_lite/dlapack_lite.c: No such file or directory gcc: no input files error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro-g -fPIC -Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/usr/include/python2.4 -c lapack_lite/dlapack_lite.c -o build/temp.linux-i686-2.4/lapack_lite/dlapack_lite.o" failed with exit status 1 [packer@titan scipy_core-0.4.1]$ (2) when building scipy_core from SVN the header files do not get installed. The install section from my RPM SPEC file reads: %install rm -rf %{buildroot} python setup.py install --root=%{buildroot} # The API headers do not get installed mkdir -p %{buildroot}/%{_includedir}/python%{pyver}/scipy/ for header in scipy/base/include/scipy/*object.h ; do install -m 644 $header %{buildroot}/%{_includedir}/python%{pyver}/scipy/ done # The generated API headers and config.h do not get installed either for header in build/src/scipy/base/*.h ; do install -m 644 $header %{buildroot}/%{_includedir}/python%{pyver}/scipy/ done # Mandrake 10.2 needs this: %multiarch_includes %{buildroot}/%{_includedir}/python%{pyver}/scipy/config.h %clean #rm -rf %{buildroot} Regards -- Gerard
![](https://secure.gravatar.com/avatar/b3dbda7788e037c64a7c37a504d6ec09.jpg?s=120&d=mm&r=g)
OK, I am giving this a go. I seem to be not setting a flag about some math functions availability. Here are the details (aorry about the length of it but I snipped a lot!): OSX 10.3.9, Python 2.4.1 Installed g77v3.4-bin.tar.gz from http://hpc.sourceforge.net/ as described into /usr/local/... Installed fftw-3.0.1-fma.tar.gz from http://www.fftw.org/download.html into ~/Documents/local/... where I have other libraries I have installed. Got scipy_core-0.4.1.tar.gz from http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=6222, wanted to try out the new replacement for Numeric tar -zxvf scipy_core-0.4.1.tar.gz cd scipy_core-0.4.1 python setup.py build Assuming default configuration (scipy/distutils/command/{setup_command,setup}.py was not found) Appending scipy.distutils.command configuration to scipy.distutils Assuming default configuration (scipy/distutils/fcompiler/{setup_fcompiler,setup}.py was not found) ... Appending scipy.base configuration to scipy blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/vecLib.framework/Headers'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] Appending scipy.lib configuration to scipy Assuming default configuration (scipy/fftpack/{setup_fftpack,setup}.py was not found) ... scipy_core version 0.4.1 running build running config_fc running build_src building extension "scipy.base.multiarray" sources creating build creating build/src creating build/src/scipy creating build/src/scipy/base Generating build/src/scipy/base/config.h customize NAGFCompiler customize AbsoftFCompiler customize IbmFCompiler Could not locate executable f77 customize GnuFCompiler customize GnuFCompiler ... compiling C sources gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes' creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base/src compile options: '-Ibuild/src/scipy/base/src -Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c' gcc: build/src/scipy/base/src/umathmodule.c In file included from build/src/scipy/base/src/umathmodule.c:8: scipy/base/include/scipy/arrayobject.h:84: warning: redefinition of `ushort' /usr/include/sys/types.h:82: warning: `ushort' previously declared here scipy/base/include/scipy/arrayobject.h:85: warning: redefinition of `uint' /usr/include/sys/types.h:83: warning: `uint' previously declared here build/src/scipy/base/src/umathmodule.c: In function `nc_floor_quotl': build/src/scipy/base/src/umathmodule.c:1257: warning: implicit declaration of function `floorl' build/src/scipy/base/src/umathmodule.c: In function `nc_sqrtl': build/src/scipy/base/src/umathmodule.c:1269: warning: implicit declaration of function `sqrtl' ... build/src/scipy/base/__umath_generated.c:171: error: initializer element is not constant build/src/scipy/base/__umath_generated.c:171: error: (near initialization for `arccosh_data[2]') error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dy namic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Ibuild/src/scipy/base/src -Iscipy/base/include -Ibuild/s rc/scipy/base -Iscipy/base/src -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c b uild/src/scipy/base/src/umathmodule.c -o build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base /src/umathmodule.o" failed with exit status 1 At 12:59 AM -0600 9/30/05, Travis Oliphant wrote:
-- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808
![](https://secure.gravatar.com/avatar/f5a9f2a5315a7d654fc18e3264afe4e9.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
Great work, and we are much relieved that NumPy has a firm future (albeit under a different name). However, can I ask if there are plans to add Masked Arrays to SciPy Core? If not, we'll have to stick with NumPy - missing values are ubiquitous in the biological sciences and any package which can't handle them isn't, to put it bluntly, of much use. We are happy to help test MA for SciPy Core, and our project (www.netepi.org) has over a thousand unit tests which give the basics of NumPy and MA a good work-out - so if/when we convert to SciPy Core the unit tests will be helpful. However we are not familiar enough with how SciPy Core differs from NumPy to help with the porting, I'm afraid. Tim C
![](https://secure.gravatar.com/avatar/f5a9f2a5315a7d654fc18e3264afe4e9.jpg?s=120&d=mm&r=g)
Paul F. Dubois wrote:
I was going to see if I could port MA. It is pure Python so shouldn't be too hard.
That would eb a most welcome development. If you are in the mood for some minor extensions to MA (you probably aren't, but just on the off-chance...), then support for multiple masking values would be great. In other words, instead of the mask just taking the values zero or one, it can also take 2, 3, etc (within the constraints of the Int8 data type), where any non-zero value means masked. That would allow the reason why a value in an array is masked to be neatly encoded, not just the fact that it is masked (missing). For example, in (human) survey data, a scalar value (eg age at menopasue) may be missing because the respondent did not meet the precondition(s) for the question (eg sex not female), or because they have not yet undergone menopause, or because they refuse to answer, or because they don't know or don't recall. That's at least 4 different reasons why the value may be missing (masked). But don't ask me the the mask value should be when you multiply a masked-because-not-asked value by a masked-because-refused-to-answer value. Perhaps a reasonable rule would be max(mask0,mask1)? Tim C
![](https://secure.gravatar.com/avatar/f5a9f2a5315a7d654fc18e3264afe4e9.jpg?s=120&d=mm&r=g)
Stephen Walton wrote:
Yes, but the wish is that NumPy, or rather, SciPy Core, treats any mask value other than zero the same - that is, that the mask value doesn't have to be one. Teh machinery to attach meaning to mask values is indeed situation-specific and shouldn't be part of SciPy Core (what is the handy abbreviation of SciPy Core, BTW?). Tim C
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
MA is great, but I wonder if many of the simple "missing value" use cases could be covered by robust handling of NaNs. Which brings up the question: How does scipy_core handle NaN and the other IEEE special values? This was a major weakness in Numeric for me. -Chris -- 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 Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/f5a9f2a5315a7d654fc18e3264afe4e9.jpg?s=120&d=mm&r=g)
Chris Barker wrote:
Most.
Which brings up the question: How does scipy_core handle NaN and the other IEEE special values? This was a major weakness in Numeric for me.
MA is indeed very flexible, well-designed and easy to use, but its weakness is that it is slow - necessarily so due to its "add-on" design - every operation is at least twice as slow as the equivalent oepration on a Numeric array. The mask arrays also eat some additional memory, which is sometimes an issue (untill everyone moves to 64 bit systems). Tim C
![](https://secure.gravatar.com/avatar/8185be81060345a47ca63640f135529c.jpg?s=120&d=mm&r=g)
On Fri, 30 Sep 2005 00:59:22 -0600 Travis Oliphant <oliphant@ee.byu.edu> wrote:
I have found two problems: (1) scipy_core-0.4.1 does not compile on this system without ATLAS, because there are missing files: ... creating build/temp.linux-i686-2.4/lapack_lite compile options: '-Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/usr/include/python2.4 -c' gcc: scipy/corelib/lapack_lite/lapack_litemodule.c gcc: lapack_lite/dlapack_lite.c gcc: lapack_lite/dlapack_lite.c: No such file or directory gcc: no input files gcc: lapack_lite/dlapack_lite.c: No such file or directory gcc: no input files error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro-g -fPIC -Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/usr/include/python2.4 -c lapack_lite/dlapack_lite.c -o build/temp.linux-i686-2.4/lapack_lite/dlapack_lite.o" failed with exit status 1 [packer@titan scipy_core-0.4.1]$ (2) when building scipy_core from SVN the header files do not get installed. The install section from my RPM SPEC file reads: %install rm -rf %{buildroot} python setup.py install --root=%{buildroot} # The API headers do not get installed mkdir -p %{buildroot}/%{_includedir}/python%{pyver}/scipy/ for header in scipy/base/include/scipy/*object.h ; do install -m 644 $header %{buildroot}/%{_includedir}/python%{pyver}/scipy/ done # The generated API headers and config.h do not get installed either for header in build/src/scipy/base/*.h ; do install -m 644 $header %{buildroot}/%{_includedir}/python%{pyver}/scipy/ done # Mandrake 10.2 needs this: %multiarch_includes %{buildroot}/%{_includedir}/python%{pyver}/scipy/config.h %clean #rm -rf %{buildroot} Regards -- Gerard
![](https://secure.gravatar.com/avatar/b3dbda7788e037c64a7c37a504d6ec09.jpg?s=120&d=mm&r=g)
OK, I am giving this a go. I seem to be not setting a flag about some math functions availability. Here are the details (aorry about the length of it but I snipped a lot!): OSX 10.3.9, Python 2.4.1 Installed g77v3.4-bin.tar.gz from http://hpc.sourceforge.net/ as described into /usr/local/... Installed fftw-3.0.1-fma.tar.gz from http://www.fftw.org/download.html into ~/Documents/local/... where I have other libraries I have installed. Got scipy_core-0.4.1.tar.gz from http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=6222, wanted to try out the new replacement for Numeric tar -zxvf scipy_core-0.4.1.tar.gz cd scipy_core-0.4.1 python setup.py build Assuming default configuration (scipy/distutils/command/{setup_command,setup}.py was not found) Appending scipy.distutils.command configuration to scipy.distutils Assuming default configuration (scipy/distutils/fcompiler/{setup_fcompiler,setup}.py was not found) ... Appending scipy.base configuration to scipy blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/vecLib.framework/Headers'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] Appending scipy.lib configuration to scipy Assuming default configuration (scipy/fftpack/{setup_fftpack,setup}.py was not found) ... scipy_core version 0.4.1 running build running config_fc running build_src building extension "scipy.base.multiarray" sources creating build creating build/src creating build/src/scipy creating build/src/scipy/base Generating build/src/scipy/base/config.h customize NAGFCompiler customize AbsoftFCompiler customize IbmFCompiler Could not locate executable f77 customize GnuFCompiler customize GnuFCompiler ... compiling C sources gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes' creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base/src compile options: '-Ibuild/src/scipy/base/src -Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c' gcc: build/src/scipy/base/src/umathmodule.c In file included from build/src/scipy/base/src/umathmodule.c:8: scipy/base/include/scipy/arrayobject.h:84: warning: redefinition of `ushort' /usr/include/sys/types.h:82: warning: `ushort' previously declared here scipy/base/include/scipy/arrayobject.h:85: warning: redefinition of `uint' /usr/include/sys/types.h:83: warning: `uint' previously declared here build/src/scipy/base/src/umathmodule.c: In function `nc_floor_quotl': build/src/scipy/base/src/umathmodule.c:1257: warning: implicit declaration of function `floorl' build/src/scipy/base/src/umathmodule.c: In function `nc_sqrtl': build/src/scipy/base/src/umathmodule.c:1269: warning: implicit declaration of function `sqrtl' ... build/src/scipy/base/__umath_generated.c:171: error: initializer element is not constant build/src/scipy/base/__umath_generated.c:171: error: (near initialization for `arccosh_data[2]') error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dy namic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Ibuild/src/scipy/base/src -Iscipy/base/include -Ibuild/s rc/scipy/base -Iscipy/base/src -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c b uild/src/scipy/base/src/umathmodule.c -o build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base /src/umathmodule.o" failed with exit status 1 At 12:59 AM -0600 9/30/05, Travis Oliphant wrote:
-- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808
![](https://secure.gravatar.com/avatar/f5a9f2a5315a7d654fc18e3264afe4e9.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
Great work, and we are much relieved that NumPy has a firm future (albeit under a different name). However, can I ask if there are plans to add Masked Arrays to SciPy Core? If not, we'll have to stick with NumPy - missing values are ubiquitous in the biological sciences and any package which can't handle them isn't, to put it bluntly, of much use. We are happy to help test MA for SciPy Core, and our project (www.netepi.org) has over a thousand unit tests which give the basics of NumPy and MA a good work-out - so if/when we convert to SciPy Core the unit tests will be helpful. However we are not familiar enough with how SciPy Core differs from NumPy to help with the porting, I'm afraid. Tim C
![](https://secure.gravatar.com/avatar/f5a9f2a5315a7d654fc18e3264afe4e9.jpg?s=120&d=mm&r=g)
Paul F. Dubois wrote:
I was going to see if I could port MA. It is pure Python so shouldn't be too hard.
That would eb a most welcome development. If you are in the mood for some minor extensions to MA (you probably aren't, but just on the off-chance...), then support for multiple masking values would be great. In other words, instead of the mask just taking the values zero or one, it can also take 2, 3, etc (within the constraints of the Int8 data type), where any non-zero value means masked. That would allow the reason why a value in an array is masked to be neatly encoded, not just the fact that it is masked (missing). For example, in (human) survey data, a scalar value (eg age at menopasue) may be missing because the respondent did not meet the precondition(s) for the question (eg sex not female), or because they have not yet undergone menopause, or because they refuse to answer, or because they don't know or don't recall. That's at least 4 different reasons why the value may be missing (masked). But don't ask me the the mask value should be when you multiply a masked-because-not-asked value by a masked-because-refused-to-answer value. Perhaps a reasonable rule would be max(mask0,mask1)? Tim C
![](https://secure.gravatar.com/avatar/f5a9f2a5315a7d654fc18e3264afe4e9.jpg?s=120&d=mm&r=g)
Stephen Walton wrote:
Yes, but the wish is that NumPy, or rather, SciPy Core, treats any mask value other than zero the same - that is, that the mask value doesn't have to be one. Teh machinery to attach meaning to mask values is indeed situation-specific and shouldn't be part of SciPy Core (what is the handy abbreviation of SciPy Core, BTW?). Tim C
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
MA is great, but I wonder if many of the simple "missing value" use cases could be covered by robust handling of NaNs. Which brings up the question: How does scipy_core handle NaN and the other IEEE special values? This was a major weakness in Numeric for me. -Chris -- 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 Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/f5a9f2a5315a7d654fc18e3264afe4e9.jpg?s=120&d=mm&r=g)
Chris Barker wrote:
Most.
Which brings up the question: How does scipy_core handle NaN and the other IEEE special values? This was a major weakness in Numeric for me.
MA is indeed very flexible, well-designed and easy to use, but its weakness is that it is slow - necessarily so due to its "add-on" design - every operation is at least twice as slow as the equivalent oepration on a Numeric array. The mask arrays also eat some additional memory, which is sometimes an issue (untill everyone moves to 64 bit systems). Tim C
participants (7)
-
Chris Barker
-
Gerard Vermeulen
-
Paul F. Dubois
-
Rob Managan
-
Stephen Walton
-
Tim Churches
-
Travis Oliphant