[Numpy-discussion] Bug in numpy all() function
Wed Feb 6 14:18:38 CST 2008
On 06/02/2008, Robert Kern <firstname.lastname@example.org> wrote:
> > I guess the all function doesn't know about generators?
> Yup. It works on arrays and things it can turn into arrays by calling the C API
> equivalent of numpy.asarray(). There's a ton of magic and special cases in
> asarray() in order to interpret nested Python sequences as arrays. That magic
> works fairly well when we have sequences with known lengths; it fails utterly
> when given an arbitrary iterator of unknown length. So we punt. Unfortunately,
> what happens then is that asarray() sees an object that it can't interpret as a
> sequence to turn into a real array, so it makes a rank-0 array with the iterator
> object as the value. This evaluates to True.
> It's possible that asarray() should raise an exception for generators, but it
> would be a special case. We wouldn't be able to test for arbitrary iterables.
Would it be possible for asarray() to pull out the first element from
the iterable, make an array out of it, then assume that all other
values out of the iterable will have the same shape (raising an error,
of course, when they aren't)? I guess this has high foot-shooting
potential, but is it that much worse than numpy's shpe-guessing
It would be handy to be able to use an iterable to fill an array, so
that you'd never need to store the values in anything else first:
a = N.array((sin(N.pi*x/n) for x in xrange(n)))
More information about the Numpy-discussion