I'm pleased to announce the first beta release of SciPy 0.7.0.
SciPy is a package of tools for science and engineering for Python.
It includes modules for statistics, optimization, integration, linear
algebra, Fourier transforms, signal and image processing, ODE solvers,
This beta release comes almost one year after the 0.6.0 release and
contains many new features, numerous bug-fixes, improved test
coverage, and better documentation. Please note that SciPy 0.7.0b1
requires Python 2.4 or greater and NumPy 1.2.0 or greater.
For information, please see the release notes:
You can download the release from here:
Thank you to everybody who contributed to this release.
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
I'm running on a 64-bit machine, and see the following:
Is there any function/setting to make these default to 32-bit types
except where necessary? I don't mean by specifying dtype=numpy.float32
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Using numpy 1.2.1 on a mac os 10.5
I admit the user was sort of stretching the limits but (on his machine)
failed with some malloc error:
python(435) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Since there's no mask I don't really see how much more memory it's
using. Beside changing 16800 to 15800 still fails (and now that should
be using much less memory)
Anyhow I would expect i nicer error than a bus error :)
After dealing with another issue, I realized that the names of inverse
trigonometrical/hyperbolic functions in NumPy don't follow the main
standards in computer science. For example, where Python writes:
asin, acos, atan, asinh, acosh, atanh
arcsin, arccos, arctan, arcsinh, arccosh, arctanh
And not only Python, the former also seems to be the standard in
computer science. Quoting:
The usual abbreviations for them in mathematics are arsinh, arcsinh (in
the USA) or asinh (in computer science).
The acronyms arcsinh, arccosh etc. are commonly used, even though they
are misnomers, since the prefix arc is the abbreviation for arcus,
while the prefix ar stands for area.
So, IMHO, I think it would be better to rename the inverse trigonometric
functions from ``arc*`` to ``a*`` prefix. Of course, in order to do
that correctly, one should add the new names and add a
``DeprecationWarning`` informing that people should start to use the
new names. After two or three NumPy versions, the old function names
can be removed safely.
What people think?
Following the discussion on python 2.6 support for numpy, I tried last
svn on mac os X, and I get a number of failures which I don't
understand, which seem to be linked to dtype code, more exactly to
FAIL: test_basic (test_multiarray.TestClip)
Traceback (most recent call last):
line 677, in test_basic
line 671, in _clip_type
line 183, in assert_equal
Items are not equal:
FAIL: test_binary (test_multiarray.TestFromstring)
Traceback (most recent call last):
line 120, in test_binary
line 303, in assert_array_equal
verbose=verbose, header='Arrays are not equal')
line 295, in assert_array_compare
Arrays are not equal
x: array([ 4.60060299e-41, 8.96831017e-44, 2.30485571e-41,
y: array([1, 2, 3, 4])
Does anyone have a clue about where to look at ? I am wondering why it
only appears on Mac OS X,
Attached here my cython implementation of the bilateral filter, which is
my first cython program. I would ask for the following:
1. Is there any way to speed up the code just by "cosmetic"
2. In particular I use the unportable gcc function __builtin_abs:
Is there any way to access this in a portable way?
3. I would like to donate this code to scipy or any other suitable
project. What can/should I do to realise it?
The code contains 3 end-user routines:
1. A pure python implementation: Easy to read and modify --- it can
be cut out into a python source code.
2. A straight forward cython implementation: About 4 times as fast
as the python implementation.
3. An optimised cython implementation earning another factor of 2
in speed (depends on the parameters used).
I see this code as a "research grade" that would evolve in the near
future, as I am working on a related project, and hopefully following
Announcing CorePy 1.0 - http://www.corepy.org
We are pleased to announce the latest release of CorePy. CorePy is a
complete system for developing machine-level programs in Python.
CorePy lets developers build and execute assembly-level programs
interactively from the Python command prompt, embed them directly in
Python applications, or export them to standard assembly languages.
CorePy's straightforward APIs enable the creation of complex,
high-performance applications that take advantage of processor
features usually inaccessible from high-level scripting languages,
such as multi-core execution and vector instruction sets (SSE, VMX,
This version addresses the two most frequently asked questions about
1) Does CorePy support x86 processors?
Yes! CorePy now has extensive support for 32/64-bit x86 and SSE
ISAs on Linux and OS X*.
2) Is CorePy Open Source?
Yes! CorePy now uses the standard BSD license.
Of course, CorePy still supports PowerPC and Cell BE SPU processors.
In fact, for this release, the Cell run-time was redesigned from the
ground up to remove the dependency on IBM's libspe and now uses the
system-level interfaces to work directly with the SPUs (and, CorePy is
still the most fun way to program the PS3).
CorePy is written almost entirely in Python. Its run-time system
does not rely on any external compilers or assemblers.
If you have the need to write tight, fast code from Python, want
to demystify machine-level code generation, or just miss the good-old
days of assembly hacking, check out CorePy!
And, if you don't believe us, here's our favorite user quote:
"CorePy makes assembly fun again!"
__credits__ = """
CorePy is developed by Chris Mueller, Andrew Friedley, and Ben
Martin and is supported by the Open Systems Lab at Indiana
Chris can be reached at cmueller[underscore]dev[at]yahoo[dot]com.
__footnote__ = """
*Any volunteers for a Windows port? :)
I would like to port a matlab library which provides functions for
rigid body mechanics such as operations on homogeneous matrices (in
SE(3)), twists (in se(3)) and so.
In matlab, the library worked on 3d matrices: n homoneous matrices
were stacked along the 3d dimension. This speeded up computations on
multiple matrices, at the price that native matrix opertators such H1
* H2 did not work (it is not defined for 3d matrices).
In this spirit, in numpy a set of rotation matrices could be built in
the following way:
SE(3) matrices corresponding to a rotation around x-axis. Theta is
a 1-d array
costheta = np.cos(theta)
sintheta = np.sin(theta)
H = np.zeros((theta.size,4,4))
H[:,0,0] = 1
H[:,3,3] = 1
H[:,1,1] = costheta
H[:,2,2] = costheta
H[:,2,1] = sintheta
H[:,1,2] = sintheta
I'm now seeking advices regarding an implementation with numpy (it's
my first time with numpy).
- Is there any difference between a 3d array and a 1-d array of 2-d
arrays (seems not)
- would you use a 3d-array or a list of 2d arrays or anything else to
store these matrices ?
- Is there a way to work easily on multiple matrices of the same shape
? (in single-instruction/multiple-data spirit)
for instance if A.shape==(3,2,4) and B.shape=(3,4,1), what is the
best way to compute C
for i = (0,1,2)
C[i,:,:] = np.dot(A[i,:,:],B[i,:,:])
- is it a good idea/not to hard to subclass ndarray with a
HomogenousMatrix class ? (one could then redefine inv() for instance)
- Is my implementation of rotx efficient ?
Thank you for any help, and please feel free to send me back reading
anything I missed.
While using the PIL interface to numpy, I rediscovered a logic error in
the PIL.Image.fromarray() procedure. The problem (and a solution) was
mentioned earlier at:
There does not seem to be a formal way to report errors to the PIL
project, and I was told that the PIL/numpy interface was contributed by
the numpy developers so I'm reporting it here.
Please let me know if there is something additional I should do.
FWIW, I'm using:
* Python version: 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC
v.1310 32 bit (Intel)]
* numpy version: 1.2.1
* PIL version: 1.1.6