Re: [Numpy-discussion] nasty bug in 1.8.0??
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 had time to build NumPy 1.8 yet to test this); it has a slightly
> more restricted model for what data can look like than NumPy has, and it's
> easier to always just look at the stride for all sizes rather than
> special-case for size=1. I think that means the bug is ndarray's (indeed,
> it's probably the kind of bug this new behavior was intended to catch, as I
> should be handling the case of non-itemsize-multiple strides more
> gracefully even when size > 1), and I'm working on a fix for it there now.
>
> Thanks, Neil, for bringing this to my attention, and to all the NumPy dev's
> for help in explaining what's going on.
>
> Jim
The problem I encountered, is that canonical generic c++ code looks like:
template
void F (in_t in) {
int size = boost::size (in);
...
This fails when "in" is nd::Array. In that case, the iterator is
strided_iterator. And here, I find (via gdb), that stride==0.
The failure occurs here:
StridedIterator.h:
template
int distance_to(StridedIterator const & other) const {
return std::distance(_data, other._data) / _stride;
}
How it happens that stride==0, and how to fix it, I don't know.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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 looking at code here, as I > haven't had time to build NumPy 1.8 yet to test this); it has a > slightly more restricted model for what data can look like than NumPy > has, and it's easier to always just look at the stride for all sizes > rather than special-case for size=1. I think that means the bug is > ndarray's (indeed, it's probably the kind of bug this new behavior was > intended to catch, as I should be handling the case of > non-itemsize-multiple strides more gracefully even when size > 1), and > I'm working on a fix for it there now. > Most bugs I saw were just simply assuming: arr.strides[-1] == arr.itemsize when the array is C-contiguous, and could be fixed by just using arr.itemsize... Unless you need to calculate contiguous flags which are compatible to NumPy with NPY_RELAXED_STRIDES_CHECKING (i.e. cython had this problem since its memoryview would reject numpy's contiguous arrays as not contiguous), you should not need to special case anything. - Sebastian > > Thanks, Neil, for bringing this to my attention, and to all the NumPy > dev's for help in explaining what's going on. > > > > Jim > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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 just looking at code here, as I > haven't had time to build NumPy 1.8 yet to test this); it has a slightly > more restricted model for what data can look like than NumPy has, and it's > easier to always just look at the stride for all sizes rather than > special-case for size=1. Note that arrays in which any dimension is 0 (i.e., 0 total elements) can also have arbitrary strides with no consequence. -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
> 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 NumPy 1.8 yet to test this); it has a slightly more restricted model for what data can look like than NumPy has, and it's easier to always just look at the stride for all sizes rather than special-case for size=1. I think that means the bug is ndarray's (indeed, it's probably the kind of bug this new behavior was intended to catch, as I should be handling the case of non-itemsize-multiple strides more gracefully even when size > 1), and I'm working on a fix for it there now. Thanks, Neil, for bringing this to my attention, and to all the NumPy dev's for help in explaining what's going on. Jim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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 rational was that since arbitrary strides *are* possible for such arrays, creating them with arbitrary strides when you use NPY_RELAXED_STRIDES_CHECKING=1 helps finding bugs. Of course you are right to suppose that a *new* array should generally have nice and clean strides, but if your code does work with arrays you did not yourself create, it cannot make these assumptions. And I think most code does this. And there are some advantages to ignoring such strides for the contiguous flags. If your arrays are contiguous, you don't really need the strides (use the itemsize instead). How is ndarray broken by this? - Sebastian > 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 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 this help test your > > software to don't depend of the strides when shapes is 1. > > > > On Mon, Dec 2, 2013 at 2:35 PM, Neal Becker wrote: > >> 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.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: > > > >> 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-discussion > >> > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >>> ___ > >>> NumPy-Discussion mailing list > >>> NumPy-Discussion@scipy.org > >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion > >> > >> > >> ___ > >> NumPy-Discussion mailing list > >> NumPy-Discussion@scipy.org > >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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 stride handling in general, which has a number of benefits: http://docs.scipy.org/doc/numpy-dev/release.html#npy-relaxed-strides-checking http://docs.scipy.org/doc/numpy/reference/arrays.ndarray.html#internal-memory-layout-of-an-ndarray Why do you care about the stride of an array with only 1 element, where by definition you never use the stride? -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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 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 this help test your > software to don't depend of the strides when shapes is 1. > > On Mon, Dec 2, 2013 at 2:35 PM, Neal Becker wrote: >> 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.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: > >> 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-discussion >> ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> ___ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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é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.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: > 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-discussion > >>> >>> >>> ___ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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 this help test your software to don't depend of the strides when shapes is 1. On Mon, Dec 2, 2013 at 2:35 PM, Neal Becker wrote: > 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.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: > 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-discussion > >>> >>> >>> ___ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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.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: >>> 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-discussion >> >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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. Using such strange strides will cause segfault if you use them, so it allow to see if you rely on them. In Theano, we did some assertion on strides and checked them for optimized call to blas. So we will need to change some code to support this. But I don't those strange strides should happen in the wild. Did you installed NumPy manually? Fred On Mon, Dec 2, 2013 at 2:14 PM, Daπ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: >> >> 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-discussion > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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]: (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]: (9223372036854775807,) >>> >>> ___ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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: > >> 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-discussion >> ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nasty bug in 1.8.0??
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]: (9223372036854775807,) > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] nasty bug in 1.8.0??
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-discussion
Re: [Numpy-discussion] math.fsum() like ufunc for numpy
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/dev/peps/pep-0450/ On 02.12.2013 19:07, Nathaniel Smith wrote: > 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 look at the algorithm >> (http://code.activestate.com/recipes/393090-binary-floating-point-summation-accurate-to-full-p/) >> and it looks quite straightforward to implement. I can try to submit a >> patch for it. >> >> Cheers, >> Daniele >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] math.fsum() like ufunc for numpy
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 look at the algorithm > (http://code.activestate.com/recipes/393090-binary-floating-point-summation-accurate-to-full-p/) > and it looks quite straightforward to implement. I can try to submit a > patch for it. > > Cheers, > Daniele > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] math.fsum() like ufunc for numpy
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 straightforward to implement. I can try to submit a patch for it. Cheers, Daniele ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Joining lists to an array
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, y]).transpose() y and docs are lists that are created in the loop body and all joined together. From these two long lists an array is created at the end. At the end data has a shape like (28, 2). Is there a way I can do this more elegantly using numpy or scipy tricks? I was working on something like the two lines I commented out, but ... Thanks, Florian ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
