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!
In a week and a half, this is happening:
It's somewhat short notice (my bad :-/), but I think it would be good
to have a short video meeting sometime this week as a kind of
"pre-meeting" -- to at least briefly go over the main issues we see
facing the project to prime the pump, get a better idea about what we
want to accomplish at the meeting itself, and gather some early
feedback from anyone who won't be able to make it to SciPy (we'll miss
The obligatory doodle:
Depending on the interest level, I'm thinking we'll either use Google
Hangouts or Bluejeans (https://bluejeans.com/ -- same as what Ralf
used for the similar SciPy meeting a few months ago; needs a plugin
installed but is available for Windows / OS X / 64-bit Linux / Android
/ iOS, or regular telephone, or h323 softphone).
Nathaniel J. Smith -- http://vorpus.org
I just finished porting a large code-base to Python 3 (making it work on
2.6, 2.7 and 3.4). It wasn't that difficult, but one thing gave me a
hard time and it was this:
Python 2.7.9 (default, Apr 2 2015, 15:33:21)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = np.zeros(7, int)
>>> n = a
>>> isinstance(n, int)
With Python 3.4 you get False. I think I understand why (np.int64 is no
longer a subclass of int). So, I did this instead:
which works fine (with numpy-1.9). Is this the "correct" way or is
there a better way to do it? I would imagine that a lot of code will
break because of this - so it would be nice if isinstance(n, int) could
be made to work the same way in 2 and 3, but I don't know if this is
possible (or desirable).
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.
There are three long ago deprecations that I am not sure how to handle.
- keywords skiprows and missing in genfromtxt, deprecated in 1.5.
- keyword old_behavior (default False) in correlate. added in 1.5 at
least, but default value changed later.
The documentation says they will be removed in numpy 2.0, but we might want
to try ealier. The case of the correlation function is trickier, as we
probabaly need to provide a function with the old behavior before removing
the keyword. I've left these cases as is, but the more old stuff hanging
about the greater our technical debt.
I am learning numpy/scipy, coming from a MATLAB background. The xcorr function in Matlab has an optional argument "maxlag" that limits the lag range from –maxlag to maxlag. This is very useful if you are looking at the cross-correlation between two very long time series but are only interested in the correlation within a certain time range. The performance increases are enormous considering that cross-correlation is incredibly expensive to compute.
What is troubling me is that numpy.correlate does not have a maxlag feature. This means that even if I only want to see correlations between two time series with lags between -100 and +100 ms, for example, it will still calculate the correlation for every lag between -20000 and +20000 ms (which is the length of the time series). This (theoretically) gives a 200x performance hit! Is it possible that I could contribute this feature?
I have introduced this question as a scipy issue https://github.com/scipy/scipy/issues/4940 and on the spicy-dev list (http://mail.scipy.org/pipermail/scipy-dev/2015-June/020757.html). It seems the best place to start is with numpy.correlate, so that is what I am requesting. I have done a simple implementation (https://gist.github.com/bringingheavendown/b4ce18aa007118e4e084) which gives 50x speedup under my conditions (https://github.com/scipy/scipy/issues/4940#issuecomment-110187847).
This is my first experience with contributing to open-source software, so any pointers are appreciated.
I'm looking to change some numpy deprecations into errors as well as remove
some deprecated functions. The problem I see is that
SciPy claims to support Numpy >= 1.5 and Numpy 1.5 is really, really, old.
So the question is, does "support" mean compiles with earlier versions
of Numpy ? If that is the case there is very little that can be done about
deprecation. OTOH, if it means Scipy can be compiled with more recent numpy
versions but used with earlier Numpy versions (which is a good feat), I'd
like to know. I'd also like to know what the interface requirements are, as
I'd like to remove old_defines.h