is there a C-API function for numpy which implements Python's
multidimensional indexing? Say, I have a 2d-array
PyArrayObject * M;
and an index
how do I extract the i-th row or column M[i,:] respectively M[:,i]?
I am looking for a function which gives again a PyArrayObject * and
which is a view to M (no copied data; the result should be another
PyArrayObject whose data and strides points to the correct memory
portion of M).
I searched the API documentation, Google and mailing lists for quite a
long time but didn't find anything. Can you help me?
quite often I work with block matrices. Matlab offers the convenient notation
[ a b; c d ]
to stack matrices. The numpy equivalent is kinda clumsy:
I wrote the little function `stack` that does exactly that:
stack([[a, b], [c, d]])
In my case `stack` replaced `hstack` and `vstack` almost completely.
If you're interested in including it in numpy I created a pull request
. I'm looking forward to getting some feedback!
I have just sent a PR (https://github.com/numpy/numpy/pull/5015), adding
the possibility of having frozen dimensions in gufunc signatures. As a
proof of concept, I have added a `cross1d` gufunc to
In : import numpy as np
In : from numpy.core.umath_tests import cross1d
In : cross1d.signature
In : a = np.random.rand(1000, 3)
In : b = np.random.rand(1000, 3)
In : np.allclose(np.cross(a, b), cross1d(a, b))
In : %timeit np.cross(a, b)
10000 loops, best of 3: 76.1 us per loop
In : %timeit cross1d(a, b)
100000 loops, best of 3: 13.1 us per loop
In : c = np.random.rand(1000, 2)
In : d = np.random.rand(1000, 2)
In : cross1d(c, d)
ValueError Traceback (most recent call last)
<ipython-input-11-72c66212e40c> in <module>()
----> 1 cross1d(c, d)
ValueError: cross1d: Operand 0 has a mismatch in its core dimension 0, with
gufunc signature (3),(3)->(3) (size 2 is different from 3)
The speed up over `np.cross` is nice, and while `np.cross` is not the best
of examples, as it needs to handle more sizes, in many cases this will
allow producing gufuncs that work without a Python wrapper redoing checks
that are best left to the iterator, such as dimension sizes.
It still needs tests, but before embarking on fully developing those, I
wanted to make sure that there is an interest on this.
I would also like to further enhance gufuncs providing computed dimensions,
e.g. making it possible to e.g. define `pairwise_cross` with signature '(n,
3)->($m, 3)', where the $ indicates that m is a computed dimension, that
would have to be calculated by a function passed to the gufunc constructor
and stored in the gufunc object, based on the other core dimensions. In
this case it would make $m be n*(n-1), so that all pairwise cross products
between 3D vectors could be computed.
The syntax with '$' is kind of crappy, so any suggestions on how to better
express this in the signature are more than welcome, as well as any
feedback on the merits (or lack of them) of implementing this.
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
As mentioned in
#1450: Patch with Ziggurat method for Normal distribution
#5158: ENH: More efficient algorithm for unweighted random choice without
#5299: using `random.choice` to sample integers in a large range
#5851: Bug in np.random.dirichlet for small alpha parameters
some methods on np.random.RandomState are implemented either non-optimally
(#1450, #5158, #5299) or have outright bugs (#5851), but cannot be easily
changed due to backwards compatibility concerns. While some have suggested
new methods deprecating the old ones (see e.g. #5872), some consensus has
formed around the following ideas (see #5299 for original discussion,
followed by private discussions with @njsmith):
- Backwards compatibility should only be provided to those who were
explicitly instantiating a seeded RandomState object or reseeding a
RandomState object to a given value, and drawing variates from it: using
the global methods (or a None-seeded RandomState) was already
non-reproducible anyways as e.g. other libraries could be drawing variates
from the global RandomState (of which the free functions in np.random are
actually methods). Thus, the global RandomState object should use the
latest implementation of the methods.
- "RandomState(seed)" and "r = RandomState(...); r.seed(seed)" should offer
backwards-compatibility guarantees (see e.g.
As such, we propose the following improvements to the API:
- RandomState gains a (keyword-only) parameter, "version", also accessible
as a read-only attribute. This indicates the version of the methods on the
object. The current version of RandomState is retroactively assigned
version 0. The latest available version is available as
np.random.LATEST_VERSION. Backwards-incompatible improvements to
RandomState methods can be introduced but increase the LAGTEST_VERSION.
- The global RandomState is instantiated as
- RandomState() and rs.seed() sets the version to LATEST_VERSION.
- RandomState(seed[!=None]) and rs.seed(seed[!=None]) sets the version to 0.
A proof-of-concept implementation, still missing tests, is tracked as
#5911. It includes the patch proposed in #5158 as an example of how to
include an improved version of random.choice.
Comments, and help for writing tests (in particular to make sure backwards
compatibility is maintained) are welcome.
The problem arises when multiplying a stack of matrices times a vector.
PEP465 defines this as appending a '1' to the dimensions of the vector and
doing the defined stacked matrix multiply, then removing the last dimension
from the result. Note that in the middle step we have a stack of matrices
and after removing the last dimension we will still have a stack of
matrices. What we want is a stack of vectors, but we can't have those with
our conventions. This makes the result somewhat unexpected. How should we
It has been reported that sourceforge has taken over the gimp
unofficial windows downloader page and temporarily bundled the
installer with unauthorized adware:
As NumPy is also distributing windows installers via sourceforge I
recommend that when you download the files you verify the downloads
via the checksums in the README.txt before using them. The README.txt
is clearsigned with my gpg key so it should be safe from tampering.
Unfortunately as I don't use windows I cannot give any advice on how
to do the verifcation on these platforms. Maybe someone familar with
available tools can chime in.
I have checked the numpy downloads and they still match what I
uploaded, but as sourceforge does redirect based on OS and geolocation
this may not mean much.
I am pleased to announce release 2015.2 of SfePy.
SfePy (simple finite elements in Python) is a software for solving systems of
coupled partial differential equations by the finite element method or by the
isogeometric analysis (preliminary support). It is distributed under the new
Home page: http://sfepy.org
Mailing list: http://groups.google.com/group/sfepy-devel
Git (source) repository, issue tracker, wiki: http://github.com/sfepy
Highlights of this release
- major code simplification (removed element groups)
- time stepping solvers updated for interactive use
- improved finding of reference element coordinates of physical points
- reorganized examples
- reorganized installation on POSIX systems (sfepy-run script)
For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).
Robert Cimrman and Contributors (*)
(*) Contributors to this release (alphabetical order):
Lubos Kejzlar, Vladimir Lukes, Anton Gladky, Matyas Novak
After some discussion with Bill Spotz I decided to try to submit my new
typemap to numpy.i that allows in-place arrays of an arbitrary number of
dimensions to be passed in as a "flat" array with a single "size".
To that end I created my first pull request
sorry if I missed any steps or procedures - I noticed only after I did the
commit and pull request that I should have created a new feature branch,
sorry about that.
Anyway I noticed the pull request initiated a series of tests and one of
them failed. How do I go about debugging and resolving the failure?
Thanks for your help,