Matthew Brett | 11 Apr 20:10 2014

Re: Wiki page for building numerical stuff on Windows


On Fri, Apr 11, 2014 at 4:21 AM, Carl Kleffner <cmkleffner <at>> wrote:
> Hi,
> a small correction: a recent octave for windows is here:
> see ...
> Binary of octave 3.8.0 on windows is now prepared in voluntary contribution
> by Markus Bergholz.
> a discussion about OpenBLAS on the octave maintainer list:

Thanks - I've put those corrections in as well.

Can you edit the page by the way?  I'm assuming y'all can...

Nathaniel Smith | 11 Apr 18:03 2014

The BLAS problem (was: Re: Wiki page for building numerical stuff on Windows)

On Fri, Apr 11, 2014 at 12:21 PM, Carl Kleffner <cmkleffner <at>> wrote:
> a discussion about OpenBLAS on the octave maintainer list:

I'm getting the impression that OpenBLAS is being both a tantalizing
opportunity and a practical thorn-in-the-side for everyone -- Python,
Octave, Julia, R.

How crazy would it be to get together an organized effort to fix this
problem -- "OpenBLAS for everyone"? E.g., by collecting patches to fix
the bits we don't like (like unhelpful build system defaults),
applying more systematic QA, etc. Ideally this could be done upstream,
but if upstream is MIA or disagrees about OpenBLAS's goals, then it
could be maintained as a kind of "OpenBLAS++" that merges regularly
from upstream (compare to [1][2][3] for successful projects handled in
this way). If hardware for testing is a problem, then I suspect
NumFOCUS would be overjoyed to throw a few kilodollars at buying one
instance of each widely-distributed microarchitecture released in the
last few years as a test farm...

I think the goal is pretty clear: a modern optionally-multithreaded
BLAS under a BSD-like license with a priority on correctness,
out-of-the-box functionality (like runtime configurability and feature
detection), speed, and portability, in that order.

I unfortunately don't have the skills to actually lead such an effort
(I've never written a line of asm in my life...), but surely our
collective communities have people who do?

(Continue reading)

techaddict | 11 Apr 11:04 2014

numpy.copyto alternative for previous versions than 1.7.0 ?

Is there a alternative way to mimic the same behaviour like numpy.copyto in
previous versions of numpy ?

View this message in context:
Sent from the Numpy-discussion mailing list archive at
Matthew Brett | 11 Apr 04:44 2014

Wiki page for building numerical stuff on Windows


I've been working on a general wiki page on building numerical stuff on Windows:

I'm hoping to let Microsoft know what problems we're having, and
seeing whether we numericists can share some work - us and R and Julia
and Octave and so on.

Feedback / edits very - very - welcome,


Nathaniel Smith | 8 Apr 01:23 2014

PEP 465 has been accepted / volunteers needed

Hey all,

Guido just formally accepted PEP 465:


The next step is to implement it, in CPython and in numpy. I have time
to advise on this, but not to do it myself, so, any volunteers? Ever
wanted to hack on the interpreter itself, with BDFL guarantee your
patch will be accepted (if correct)?

The todo list for CPython is here:
There's one open question which is where the type slots should be
added. I'd just add them to PyNumberMethods and then if someone
objects during patch review it can be changed.



Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
Björn Dahlgren | 7 Apr 17:12 2014

Proposed new function for joining arrays: np.interleave


Interleaving arrays is something I need to do every now and then, and by the looks of stackoverflow so do others:

I think the code needed for the general n dimensional case with m number of arrays
is non-trivial enough for it to be useful to provide such a function in numpy, so I took the liberty to
make a Pull Request with my implementation. This would be my first contribution to NumPy so I apologize if something is not adhering to your practices.

Jaime has already pointed out that I should email this list (I hope I managed to email the list in
the right way - never used a mailing list before) for you to notice the pull request. He also pointed
out some improvements of my proposed implementation (not forcing consistent dtype), but before
I go on and make changes I might need to ask you guys if this is really something you are interested in including?

Best regards,
/Björn Dahlgren

NumPy-Discussion mailing list
NumPy-Discussion <at>
Yaroslav Halchenko | 6 Apr 23:43 2014

match RNG numbers with R?

Hi NumPy gurus,

We wanted to test some of our code by comparing to results of R
implementation which provides bootstrapped results.

R, Python std library, numpy all have Mersenne Twister RNG implementation.  But
all of them generate different numbers.  This issue was previously discussed in :  In Python, and numpy generated
numbers are based on using 53 bits of two 32 bit random integers generated by
the algorithm (see below).    Upon my brief inspection, original 32bit numbers
are nohow available for access neither in NumPy nor in Python stdlib

I wonder if I have missed something and there is an easy way (i.e. without
reimplementing core algorithm, or RPy'ing numbers from R) to generate random
numbers in Python to match the ones in R?

Excerpt from

# R
%R RNGkind("Mersenne-Twister"); set.seed(1); sample(0:9, 10, replace=T)

array([2, 3, 5, 9, 2, 8, 9, 6, 6, 0], dtype=int32)

# stock Python
random.seed(1); [random.randint(0, 10) for i in range(10)]

[1, 9, 8, 2, 5, 4, 7, 8, 1, 0]

# numpy
rng = nprandom.RandomState(1);  [rng.randint(0, 10) for i in range(10)]

[5, 8, 9, 5, 0, 0, 1, 7, 6, 9]


Yaroslav O. Halchenko, Ph.D.
Senior Research Associate,     Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
Julian Taylor | 6 Apr 22:05 2014

numpy git master requiring cython for build

numpy.random is largely built from a cython file. Up to know numpy git
included generated c sources for this one file.
It is troublesome to have merge 20k line changes for one line bugfixes,
so it is proposed to remove the generated sources from the master branch
in this PR:

Like in SciPy the sources will not be contained in git anymore but built
by the regular build when required.
Release source tarballs (sdist) will continue contain the generated
sources so users of stable release are not required to have cython

If you have any objects to this please speak up soon.

Francesc Alted | 6 Apr 12:51 2014

ANN: numexpr 2.4 RC1

  Announcing Numexpr 2.4 RC1

Numexpr is a fast numerical expression evaluator for NumPy.  With it,
expressions that operate on arrays (like "3*a+4*b") are accelerated
and use less memory than doing the same calculation in Python.

It wears multi-threaded capabilities, as well as support for Intel's
MKL (Math Kernel Library), which allows an extremely fast evaluation
of transcendental functions (sin, cos, tan, exp, log...)  while
squeezing the last drop of performance out of your multi-core
processors.  Look here for a some benchmarks of numexpr using MKL:

Its only dependency is NumPy (MKL is optional), so it works well as an
easy-to-deploy, easy-to-use, computational engine for projects that
don't want to adopt other solutions requiring more heavy dependencies.

What's new

A new `contains()` function has been added for detecting substrings in
strings.  Thanks to Marcin Krol.

Also, there is a new version of that allows better management
of the NumPy dependency during pip installs.  Thanks to Aleks Bunin.

This is the first release candidate before 2.4 final would be out,
so please give it a go and report back any problems you may have.

In case you want to know more in detail what has changed in this
version, see:

or have a look at RELEASE_NOTES.txt in the tarball.

Where I can find Numexpr?

The project is hosted at GitHub in:

You can get the packages from PyPI as well (but not for RC releases):

Share your experience

Let us know of any bugs, suggestions, gripes, kudos, etc. you may

Enjoy data!


Francesc Alted
Charles R Harris | 4 Apr 20:12 2014

Where to put versionadded

Hi All,

Currently there are several placements of the '.. versionadded::' directive and I'd like to settle
on a proper style for consistency. There are two occasions on which it is used, first, when a new function or class is added and second, when a new keyword is added to an existing function or method. The options are as follows.

New Function

1) Originally, the directive was added in the notes section.
.. versionadded:: 1.5.0

 2) Alternatively, it is placed after the extended summary.

blah, blah

..versionadded:: 1.5.0

Between these two, I vote for 2) because the version is easily found when reading the documentation either in a terminal or rendered into HTML.

New Parameter

1) It is placed before the parameter description

newoption : int, optional
    .. versionadded:: 1.5.0

2) It is placed after the parameter description.

newoption : int, optional

    .. versionadded:: 1.5.0

Both of these render correctly, but the first is more compact while the second puts the version
after the description where it doesn't interrupt the reading. I'm tending towards 1) on account of its compactness.



NumPy-Discussion mailing list
NumPy-Discussion <at>
Ralf Gommers | 3 Apr 22:14 2014

ANN: Scipy 0.14.0 release candidate 1


I'm pleased to announce the availability of the first release candidate of Scipy 0.14.0. Please try this RC and report any issues on the scipy-dev mailing list. A significant number of fixes for scipy.sparse went in after the beta release, so users of that module may want to test this release carefully.

Source tarballs, binaries and the full release notes can be found at The final release will follow in one week if no new issues are found.

A big thank you to everyone who contributed to this release!


NumPy-Discussion mailing list
NumPy-Discussion <at>