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
> h
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
On Mon, Dec 2, 2013 at 3:15 PM, 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 jus
> 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 NumP
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.
On Mon, Dec 2, 2013 at 11:35 AM, Neal Becker 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 definition of contiguity and
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
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.
>
> Fr
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 th
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 wrote:
>> I built using:
>>
>> CFLAGS='-march=native -O3' NPY_RELAXED_STRIDES_CHECKING=1 python3 setup.p
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.
Usi
It is the NPY_RELAXED_STRIDES_CHECKING=1 flag that caused this.
Fred
On Mon, Dec 2, 2013 at 2:18 PM, Neal Becker 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
>> Out[4]
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 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 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
> Out[7]: (9223372
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
http://mail.scipy.org/mailman/listinfo/numpy-discu
related this PR attempts to improve the accuracy of summation:
https://github.com/numpy/numpy/pull/3685
but math.fsum gives the exact result so it would a valuable ufunc even
when that PR is merged.
python3.4 will have yet another accurate summation in the statistics module:
http://www.python.org/
I think that would be great. Technically what you'd want is a "gufunc".
-n
On Mon, Dec 2, 2013 at 9:44 AM, Daniele Nicolodi wrote:
> Hello,
>
> there would be interest in adding a floating point accurate summation
> function like Python's math.fsum() in the form of an ufunc to NumPy?
>
> I had a
Hello,
there would be interest in adding a floating point accurate summation
function like Python's math.fsum() in the form of an ufunc to NumPy?
I had a look at the algorithm
(http://code.activestate.com/recipes/393090-binary-floating-point-summation-accurate-to-full-p/)
and it looks quite strai
Hello,
I have this piece of example code
import random, numpy as np
y = []
doc_all = []
# da = np.zeros(2)
for i in range(4):
docs = range(random.randint(1, 10))
y += [i]*len(docs)
doc_all += docs
# np.append(da, np.column_stack((docs, y)), axis=0)
data = np.array([doc_all,
19 matches
Mail list logo
