Re: [Numpy-discussion] My GSoC Proposal to Implement a Subset of NumPy for PyPy
Hi Dan, On Sat, Apr 17, 2010 at 1:50 PM, Dan Roberts ademan...@gmail.com wrote: Hello NumPy Users, Hi everybody, my name is Dan Roberts, and my Google Summer of Code proposal was categorized under NumPy rather than PyPy, so it will end up being reviewed by mentors for the NumPy project. I'd like to take this chance to introduce myself and my proposal. Thanks for proposing a NumPy-related project ! Finally, I'd like to ask all of you: what features are most important to you? It's not practical, wise, or even possible for me to reimpliment more than a small portion of NumPy, but if I can address the most important parts, maybe I can make this project useful enough for some of you to use, and close enough for the rest of you that I can drum up some support for more development in the future. First, an aside: with the recent announcement from pypy concerning the new way of interfacing with C, wouldn't it make more sense to go the other way around - i.e. starting from full numpy, and replace some parts in rpython ? Of course, this assumes that numpy can work with pypy using the new C API emulation, but this may not be a lot of work. This would gives the advantage of having something useful from the start. I think this project is extremely interesting in nature, and the parts which are the most interesting to implement are (IMHO of course): - indexing, fancy indexing - broadcasting - basic ufunc support, although I am not sure how to plug this with the C math library for math functions (cos, log, etc...) Especially for indexing and broadcasting, even if your project fails, having a pure, reference python implementation would be tremendously useful - in particular for the use in sparse arrays as mentioned by Stefan. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] My GSoC Proposal to Implement a Subset of NumPy for PyPy
su, 2010-04-18 kello 19:05 +0900, David Cournapeau kirjoitti: [clip] First, an aside: with the recent announcement from pypy concerning the new way of interfacing with C, wouldn't it make more sense to go the other way around - i.e. starting from full numpy, and replace some parts in rpython ? Of course, this assumes that numpy can work with pypy using the new C API emulation, but this may not be a lot of work. This would gives the advantage of having something useful from the start. I think this project is extremely interesting in nature, and the parts which are the most interesting to implement are (IMHO of course): - indexing, fancy indexing - broadcasting - basic ufunc support, although I am not sure how to plug this with the C math library for math functions (cos, log, etc...) I agree here: if it's possible to supplement the existing Numpy code base by interpreter-level (JIT-able) support for indexing, fancy indexing, and broadcasting, this would reduce the roadblock in writing effective algorithms without using vectorization. Also, if you can incrementally replace parts of Numpy, the code could be immediately usable in real world, being less of a proof-of-concept subset. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] np.mean and np.std performances
Hi all, I noticed some performance problems with np.mean and np.std functions. Here is the console output in ipython: # make some test data : a = np.arange(80*64, dtype=np.float64).reshape(80, 64) : c = np.tile( a, [1, 1, 1]) : timeit np.mean(c, axis=0) 1 loops, best of 3: 2.09 s per loop But using reduce is much faster: def mean_reduce(c): return reduce(lambda som, array: som+array, c) / c.shape[0] :timeit mean_reduce(c) 1 loops, best of 3: 355 ms per loop The same applies to np.std(): # slighlty smaller c matrix (too much memory is used) : c = np.tile( a, [7000, 1, 1]) : timeit np.std(c, axis=0) 1 loops, best of 3: 3.73 s per loop With the reduce version: def std_reduce(c): c -= mean_reduce(c) return np.sqrt( reduce(lambda som, array: som + array**2, c ) / c.shape[0] ) : timeit std_reduce(c) 1 loops, best of 3: 1.18 s per loop For the std function also look at the memory usage during the execution of the function. The functions i gave here can be easily modified to accept an axis option and other stuff needed. Is there any drawback of using them? Why np.mean and np.std are so slow? I'm sure I'm missing something. Cheers Davide ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in numpy.fix(): broken for scalar arguments
On Sat, Apr 17, 2010 at 4:16 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Apr 17, 2010 at 2:01 PM, Eric Firing efir...@hawaii.edu wrote: np.fix() no longer works for scalar arguments: In [1]:import numpy as np In [2]:np.version.version Out[2]:'2.0.0.dev8334' In [3]:np.fix(3.14) --- TypeError Traceback (most recent call last) /home/efiring/ipython console in module() /usr/local/lib/python2.6/dist-packages/numpy/lib/ufunclike.pyc in fix(x, y) 46 if y is None: 47 y = y1 --- 48 y[...] = nx.where(x = 0, y1, y2) 49 return y 50 TypeError: 'numpy.float64' object does not support item assignment Looks like r8293. Darren? Thanks, I'm looking into it. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in numpy.fix(): broken for scalar arguments
On Sun, Apr 18, 2010 at 9:08 AM, Darren Dale dsdal...@gmail.com wrote: On Sat, Apr 17, 2010 at 4:16 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Apr 17, 2010 at 2:01 PM, Eric Firing efir...@hawaii.edu wrote: np.fix() no longer works for scalar arguments: In [1]:import numpy as np In [2]:np.version.version Out[2]:'2.0.0.dev8334' In [3]:np.fix(3.14) --- TypeError Traceback (most recent call last) /home/efiring/ipython console in module() /usr/local/lib/python2.6/dist-packages/numpy/lib/ufunclike.pyc in fix(x, y) 46 if y is None: 47 y = y1 --- 48 y[...] = nx.where(x = 0, y1, y2) 49 return y 50 TypeError: 'numpy.float64' object does not support item assignment Looks like r8293. Darren? Thanks, I'm looking into it. The old np.fix behavior is different from np.floor and np.ceil. np.fix(3.14) would return array(3.0), while np.floor(3.14) would return 3.0. Shall I fix it to conform with the old but inconsistent behavior of fix? Darren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Math Library
On Tue, Apr 13, 2010 at 12:29 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Apr 12, 2010 at 4:19 PM, Travis Oliphant oliph...@enthought.com wrote: On Apr 11, 2010, at 4:17 PM, Sebastian Walter wrote: Ermm, the reply above is quite poor, sorry about that. What I meant to say is the following: If there is going to be a discussion about creating a pure C numpy library I'd like to join ;) Great. I would really like to get the discussion going. In an ideal world we can finish any kind of significant re-factoring in time for SciPy this year. It actually feels like the kind of thing that can motivate NumPy 2.0 a bit better. It sounds to me like nobody will be opposed as long as there is continuity to the project and current code still works without disruption (i.e. the current C-API for Python extensions is available). I am interested in re-factoring in such a way to create minimal impact on current NumPy C-API users, but improve maintainability going forward and the ability for other projects to use NumPy. My own thoughts were to have a lowlevel 'loop' library that worked with strided memory, and an intermediate level above that for buffer objects. Numpy ufuncs would be a level above that and implement policy type things like casting, kinds, etc. Then there is the lowlevel c-library for the functions. I don't think we should aim at duplicating commonly available functions like sin and exp, but rather that subset that are sometimes unavailable. In particular, I would like to get away from having to use double versions of functions instead of type specific versions. This sounds reasonable. However, I'm not sure that I understand exactly what the consequences would be. Maybe it would be a good idea that one writes down prototypical examples that should be supported by the new code? Sebastian Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in numpy.fix(): broken for scalar arguments
On Sun, Apr 18, 2010 at 9:28 AM, Darren Dale dsdal...@gmail.com wrote: On Sun, Apr 18, 2010 at 9:08 AM, Darren Dale dsdal...@gmail.com wrote: On Sat, Apr 17, 2010 at 4:16 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Apr 17, 2010 at 2:01 PM, Eric Firing efir...@hawaii.edu wrote: np.fix() no longer works for scalar arguments: In [1]:import numpy as np In [2]:np.version.version Out[2]:'2.0.0.dev8334' In [3]:np.fix(3.14) --- TypeError Traceback (most recent call last) /home/efiring/ipython console in module() /usr/local/lib/python2.6/dist-packages/numpy/lib/ufunclike.pyc in fix(x, y) 46 if y is None: 47 y = y1 --- 48 y[...] = nx.where(x = 0, y1, y2) 49 return y 50 TypeError: 'numpy.float64' object does not support item assignment Looks like r8293. Darren? Thanks, I'm looking into it. The old np.fix behavior is different from np.floor and np.ceil. np.fix(3.14) would return array(3.0), while np.floor(3.14) would return 3.0. Shall I fix it to conform with the old but inconsistent behavior of fix? I think this is the underlying issue: np.floor(np.array(3.14)) returns 3.0, not array(3.14). The current implementation of fix had already taken care to ensure that it was working with an array for the input. What is numpy's policy here? np.fix returned a len-0 ndarray even for scalar input, floor and ceil return scalars even for len-0 ndarrays. This inconsistency makes it difficult to make even small modifications to the numpy codebase. r8351 includes a one-line change that addresses Eric's report and is commensurate with the previous behavior of fix. Darren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy compilation error
Hi, how do I figure where did my numpy got installed to? I downloaded a tar.gz file and then unzipped it at /nfs/carv/d1/people/pradeep/src/numpy-1.3.0/. I didn't do any additional installation steps. Also, just fyi, I don't have root access to this system. Thanks 2010/4/16 Robert Kern robert.k...@gmail.com On Fri, Apr 16, 2010 at 20:56, josef.p...@gmail.com wrote: On Fri, Apr 16, 2010 at 9:47 PM, Pradeep Jha jh...@utias.utoronto.ca wrote: Hi, before running the make command, it asks me to run the preconfig file. When I run preconfig, I get the following warning message during the run: checking for python2... /usr/bin/python2 Python command set by configure to /usr/bin/python2 WARNING: NUMPY include dir /nfs/carv/d1/people/pradeep/src/numpy-1.3.0//include/python does not exist. setting NUMPY_INC_DIR to /nfs/carv/d1/people/pradeep/src/numpy-1.3.0//include/python Is duplicate forward-slash legal in a Linux path? Yes. It is ignored. You need to set NUMPY_INC_DIR to $PYTHON_SITE_PACKAGES/numpy/core/include where $PYTHON_SITE_PACKAGES is the site-packages/ directory where your installation of numpy got installed to. Note that this is not /nfs/carv/d1/people/pradeep/src/numpy-1.3.0/. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy compilation error
Hi,
I am running python 2.4.4. I installed numpy using the command*
*
*python setup.py install --prefix=$HOME/**bin*
my site-packages directory got installed to the following address:*
/nfs/carv/d1/people/pradeep/bin/lib/python2.4*
in my preconfig file I changed the path to the following as you recommended
*
# If numpy was installed using the --home option, set this to the
# home directory for numpy. This will be needed for all numpy installations
# that don't put the include files into python's native include directory.
NUMPY_HOME=${NUMPY_HOME:=/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include}
*
I still get the following warning message when I run the preconfig file:*
checking for python2... /usr/bin/python2
Python command set by configure to /usr/bin/python2
WARNING: NUMPY include dir
/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include/include/python
does not exist.
setting NUMPY_INC_DIR to
/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include/include/python
*
Whats going wrong? The warning is right, as there is no directory
called *python
*on that address.
Just to give you the structure of the installed packages, I am attaching the
output to the cd and ls commands:
*[prad...@scaramanga lib]$ls
python2.4
[prad...@scaramanga lib]$cd python2.4/
[prad...@scaramanga python2.4]$ls
site-packages
[prad...@scaramanga python2.4]$cd site-packages/
[prad...@scaramanga site-packages]$ls
numpy
[prad...@scaramanga site-packages]$cd numpy/
[prad...@scaramanga numpy]$ls
add_newdocs.py __config__.pyc DEV_README.txt dual.pyc
_import_tools.pyc lib matlib.py random setupscons.py
tests
add_newdocs.pyc coredistutils f2py
__init__.pyLICENSE.txt matlib.pyc README.txt setupscons.pyc
THANKS.txt
COMPATIBILITYctypeslib.pydoc fft
__init__.pyc linalg numarraysetup.pysite.cfg.example
version.py
__config__.pyctypeslib.pyc dual.py _import_tools.py
INSTALL.txtma oldnumeric setup.pyc testing
version.pyc
[prad...@scaramanga numpy]$cd core/
[prad...@scaramanga core]$ls
arrayprint.py defmatrix.pyc include _internal.py
numeric.pyrecords.pycsetup_common.pyc _sort.so
arrayprint.pycfromnumeric.py info.py _internal.pyc
numeric.pyc scalarmath.so setup.py tests
defchararray.py fromnumeric.pyc info.pyc memmap.py
numerictypes.py scons_support.py setup.pyc umath.so defchararray.pyc
generate_numpy_api.py __init__.py memmap.pyc numerictypes.pyc
scons_support.pyc setupscons.py umath_tests.so defmatrix.py
generate_numpy_api.pyc __init__.pyc multiarray.so records.py
setup_common.pysetupscons.pyc
[prad...@scaramanga core]$cd include/
[prad...@scaramanga include]$ls
numpy
[prad...@scaramanga include]$cd numpy/
[prad...@scaramanga numpy]$ls
arrayobject.h mingw_amd64_fenv.h multiarray_api.txt noprefix.h
npy_cpu.h npy_interrupt.h numpyconfig.h oldnumeric.h ufunc_api.txt
utils.h arrayscalars.h __multiarray_api.h ndarrayobject.h
npy_common.h npy_endian.h npy_math.h old_defines.h __ufunc_api.h
ufuncobject.h
*
Thanks
2010/4/18 Pradeep Jha jh...@utias.utoronto.ca
Hi,
how do I figure where did my numpy got installed to? I downloaded a tar.gz
file and then unzipped it at
/nfs/carv/d1/people/pradeep/src/numpy-1.3.0/.
I didn't do any additional installation steps. Also, just fyi, I don't have
root access to this system.
Thanks
2010/4/16 Robert Kern robert.k...@gmail.com
On Fri, Apr 16, 2010 at 20:56, josef.p...@gmail.com wrote:
On Fri, Apr 16, 2010 at 9:47 PM, Pradeep Jha jh...@utias.utoronto.ca
wrote:
Hi,
before running the make command, it asks me to run the preconfig file.
When
I run preconfig, I get the following warning message during the run:
checking for python2... /usr/bin/python2
Python command set by configure to /usr/bin/python2
WARNING: NUMPY include dir
/nfs/carv/d1/people/pradeep/src/numpy-1.3.0//include/python does not
exist.
setting NUMPY_INC_DIR to
/nfs/carv/d1/people/pradeep/src/numpy-1.3.0//include/python
Is duplicate forward-slash legal in a Linux path?
Yes. It is ignored.
You need to set NUMPY_INC_DIR to
$PYTHON_SITE_PACKAGES/numpy/core/include where $PYTHON_SITE_PACKAGES
is the site-packages/ directory where your installation of numpy got
installed to. Note that this is not
/nfs/carv/d1/people/pradeep/src/numpy-1.3.0/.
--
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
Re: [Numpy-discussion] Numpy compilation error
On Sun, Apr 18, 2010 at 13:32, Pradeep Jha jh...@utias.utoronto.ca wrote:
Hi,
I am running python 2.4.4. I installed numpy using the command
python setup.py install --prefix=$HOME/bin
That's not a good prefix. --prefix=$HOME would be better. It will
create, if necessary, bin/ and lib/ underneath that.
my site-packages directory got installed to the following address:
/nfs/carv/d1/people/pradeep/bin/lib/python2.4
in my preconfig file I changed the path to the following as you recommended
# If numpy was installed using the --home option, set this to the
# home directory for numpy. This will be needed for all numpy installations
# that don't put the include files into python's native include directory.
NUMPY_HOME=${NUMPY_HOME:=/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include}
I still get the following warning message when I run the preconfig file:
checking for python2... /usr/bin/python2
Python command set by configure to /usr/bin/python2
WARNING: NUMPY include dir
/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include/include/python
does not exist.
setting NUMPY_INC_DIR to
/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include/include/python
Whats going wrong? The warning is right, as there is no directory called
python on that address.
You need to set the variable NUMPY_INC_DIR to
'/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include/'
or the equivalent if you decide to fix the --prefix as above.
--
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy compilation error
Hi,
I am setting NUMPY_INC_DIR to what you said but still am getting the same
error. Basically,
there is no directory path like ***/include/python/*** anywhere in the
installed numpy directory. whatever I am setting in my NUMPY_INC_DIR, the
preconfig file tries to add a /include/python to that string and tries to
locate that path, but fails.
2010/4/18 Robert Kern robert.k...@gmail.com
On Sun, Apr 18, 2010 at 13:32, Pradeep Jha jh...@utias.utoronto.ca
wrote:
Hi,
I am running python 2.4.4. I installed numpy using the command
python setup.py install --prefix=$HOME/bin
That's not a good prefix. --prefix=$HOME would be better. It will
create, if necessary, bin/ and lib/ underneath that.
my site-packages directory got installed to the following address:
/nfs/carv/d1/people/pradeep/bin/lib/python2.4
in my preconfig file I changed the path to the following as you
recommended
# If numpy was installed using the --home option, set this to the
# home directory for numpy. This will be needed for all numpy
installations
# that don't put the include files into python's native include
directory.
NUMPY_HOME=${NUMPY_HOME:=/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include}
I still get the following warning message when I run the preconfig file:
checking for python2... /usr/bin/python2
Python command set by configure to /usr/bin/python2
WARNING: NUMPY include dir
/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include/include/python
does not exist.
setting NUMPY_INC_DIR to
/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include/include/python
Whats going wrong? The warning is right, as there is no directory called
python on that address.
You need to set the variable NUMPY_INC_DIR to
'/nfs/carv/d1/people/pradeep/bin/lib/python2.4/site-packages/numpy/core/include/'
or the equivalent if you decide to fix the --prefix as above.
--
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy compilation error
On Sun, Apr 18, 2010 at 19:49, Pradeep Jha jh...@utias.utoronto.ca wrote: Hi, I am setting NUMPY_INC_DIR to what you said but still am getting the same error. Basically, there is no directory path like ***/include/python/*** anywhere in the installed numpy directory. This is correct. No such directory should exist. whatever I am setting in my NUMPY_INC_DIR, the preconfig file tries to add a /include/python to that string and tries to locate that path, but fails. I am not familiar with the Cantera build process. You will probably need to ask the Cantera developers. You could probably replace the line in setup.py.in (sorry if this is not exactly right; I only downloaded the 1.7.0 sources, which still uses numarray): numpy_incl = @NUMPY_INC_DIR@ to: import numpy numpy_incl = numpy.get_include() Then the value of NUMPY_INC_DIR will not matter. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] My GSoC Proposal to Implement a Subset of NumPy for PyPy
On Apr 18, 2010 6:46 PM, Dan Roberts ademan...@gmail.com wrote: I've been trying my best to take my time formulating my replies but I need to respond eventually. :-) This is embarassing, but I'm actually not sure where I talked about an interface specifically. I did rather nebulously talk about interfacing with C code and LAPACK and the interfaces there would be provided by the respective code and consumed by micronumpy, at least as I currently see it. I haven't consulted maciej about this yet, but I think working backwards from a complete C NumPy depends on a great deal of ifs, many of which I think aren't satisfied. I need to look into this, but I assume NumPy operates on array structures directly, rather than through an interface. If it's through an interface, there's a real possibility that approach is possible, though it would require me to write some adaptors, I think it would be ok, and a low enough time investment. Like I said I'm currently speaking from ignorance so I need to look into it and get back to you. Cheers, Dan P.S. I agree about the sparse matrices, I've bugged fijal a small bit about that. P.P.S. Forgot to CC the mailing list... assumed this mail client would do it for me.. lol On Apr 17, 2010 12:25 AM, Stéfan van der Walt ste...@sun.ac.za wrote: Hi Dan On 17 April 2010 06:50, Dan Roberts ademan...@gmail.com wrote: Hi everybody, my name is Dan... Thanks for the introduction, and welcome to NumPy! I hadn't prepared for review by the NumPy mentors, but this can make my proposal stronger t... This proposal builds a bridge between two projects, so even if it technically falls under the... Why should we bother reimplimenting anything? PyPy, for those who are unfamiliar, has the ... Your code has a fairly specialised application and it's worth discussing exactly where it wou... ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Release candidate 3 for NumPy 1.4.1 and SciPy 0.7.2
Hi, I am pleased to announce the third release candidate of both Scipy 0.7.2 and NumPy 1.4.1. Please test, and report any problems on the NumPy or SciPy list. Binaries, sources and release notes can be found at https://sourceforge.net/projects/numpy/files/ https://sourceforge.net/projects/scipy/files/ Changes from RC2 == SciPy: warnings about possible binary incompatibilities with numpy have been suppressed NumPy: - fixed compatibility with Python 2.7b1 - marked test for complex log as a known failure NumPy 1.4.1 == The main change over 1.4.0 is that datetime support has been removed. This fixes the binary incompatibility issues between NumPy and other libraries like SciPy and Matplotlib. There are also a number of other bug fixes, and no new features. Binaries for Python 2.5 and 2.6 are available for both Windows and OS X. SciPy 0.7.2 = The only change compared to 0.7.1 is that the C sources for Cython code have been regenerated with Cython 0.12.1. This ensures that SciPy 0.7.2 will work with NumPy 1.4.1, while also retaining backwards compatibility with NumPy 1.3.0. Note that the 0.7.x branch was created in January 2009, so a lot of fixes and new functionality in current trunk is not present in this release. Binaries for Python 2.6 are available for both Windows and OS X. Due to the age of the code no binaries for Python 2.5 are available. On behalf of the NumPy and SciPy developers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
