This is np 1.8.0 on fedora x86_64:
In [5]: x =np.array ((1,))
In [6]: x.shape
Out[6]: (1,)
In [7]: x.strides
Out[7]: (9223372036854775807,)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
I get:
In [4]: x.strides
Out[4]: (8,)
Same architecture and OS, Numpy installed via Pip on Python 2.7.5.
On 2 December 2013 20:08, Neal Becker ndbeck...@gmail.com wrote:
This is np 1.8.0 on fedora x86_64:
In [5]: x =np.array ((1,))
In [6]: x.shape
Out[6]: (1,)
In [7]: x.strides
I built using:
CFLAGS='-march=native -O3' NPY_RELAXED_STRIDES_CHECKING=1 python3 setup.py
install --user
aπid wrote:
I get:
In [4]: x.strides
Out[4]: (8,)
Same architecture and OS, Numpy installed via Pip on Python 2.7.5.
On 2 December 2013 20:08, Neal Becker ndbeck...@gmail.com
It is the NPY_RELAXED_STRIDES_CHECKING=1 flag that caused this.
Fred
On Mon, Dec 2, 2013 at 2:18 PM, Neal Becker ndbeck...@gmail.com wrote:
I built using:
CFLAGS='-march=native -O3' NPY_RELAXED_STRIDES_CHECKING=1 python3 setup.py
install --user
aπid wrote:
I get:
In [4]: x.strides
There is a way to compile NumPy to use strange strides for dimension
with shape of 1.
This is done to help developer test their code to don't rely on this.
There was never a warranty to the value of strides in that cases. Most
of the time, it was the same, but in some cases, it was different.
I don't think that behavior is acceptable.
Frédéric Bastien wrote:
It is the NPY_RELAXED_STRIDES_CHECKING=1 flag that caused this.
Fred
On Mon, Dec 2, 2013 at 2:18 PM, Neal Becker ndbeck...@gmail.com wrote:
I built using:
CFLAGS='-march=native -O3' NPY_RELAXED_STRIDES_CHECKING=1
Just don't compile with NPY_RELAXED_STRIDES_CHECKING to have the old
behavior I think (which is an not always the same strides depending of
how it was created, I don't know if they changed that or not).
Do someone else recall the detail of this?
Fred
p.s. I didn't do this or asked for it. But
I opened a ticket for it, though thinking about it, its probably
intentional be intentional to find code that assumes it can use the
strides to get the itemsize.
https://github.com/numpy/numpy/issues/4091
On 02.12.2013 20:35, Neal Becker wrote:
I don't think that behavior is acceptable.
The software I'm using, which is
https://github.com/ndarray/ndarray
does depend on this. Am I the only one who thinks that this
behavior is not desirable?
Frédéric Bastien wrote:
Just don't compile with NPY_RELAXED_STRIDES_CHECKING to have the old
behavior I think (which is an not always
On Mon, Dec 2, 2013 at 11:35 AM, Neal Becker ndbeck...@gmail.com wrote:
I don't think that behavior is acceptable.
That's... too bad? I'm not sure what your objection actually is.
It's an intentional change (though disabled by default in 1.8), and a
necessary step to rationalizing our
On Mon, 2013-12-02 at 14:51 -0500, Neal Becker wrote:
The software I'm using, which is
https://github.com/ndarray/ndarray
does depend on this. Am I the only one who thinks that this
behavior is not desirable?
Well, this is not meant to be the way for a release version of numpy.
The
If your arrays are contiguous, you don't really need the strides (use the
itemsize instead). How is ndarray broken by this?
ndarray is broken by this change because it expects the stride to be a
multiple of the itemsize (I think; I'm just looking at code here, as I
haven't had time to build
On Mon, Dec 2, 2013 at 3:15 PM, Jim Bosch tallji...@gmail.com wrote:
If your arrays are contiguous, you don't really need the strides (use the
itemsize instead). How is ndarray broken by this?
ndarray is broken by this change because it expects the stride to be a
multiple of the itemsize (I
On Mon, 2013-12-02 at 18:15 -0500, Jim Bosch wrote:
If your arrays are contiguous, you don't really need the strides
(use the itemsize instead). How is ndarray broken by this?
ndarray is broken by this change because it expects the stride to be a
multiple of the itemsize (I think; I'm just
Jim Bosch wrote:
If your arrays are contiguous, you don't really need the strides (use the
itemsize instead). How is ndarray broken by this?
ndarray is broken by this change because it expects the stride to be a
multiple of the itemsize (I think; I'm just looking at code here, as I
haven't
15 matches
Mail list logo
