[Numpy-discussion] ndrange, like range but multidimensiontal

[Eric Wieser]

Isn’t that what arange is for?

Imagining ourselves in python2 land for now - I’m proposing arange is to
range, as ndrange is to xrange

I’m not convinced it should return an ndarray

I agree - I think it should return a range-like object that:

   - Is convertible via __array__ if needed
   - Looks like an ndarray, with:
      - a .dtype attribute
      - a __getitem__(Tuple[int]) which returns numpy scalars
      - .ravel() and .flat for choosing iteration order.

On Wed, 10 Oct 2018 at 11:21 Allan Haldane allanhaldane at gmail.com
<http://mailto:allanhaldane@gmail.com> wrote:

On 10/10/18 12:34 AM, Eric Wieser wrote:
> > One thing that worries me here - in python, |range(...)| in essence
> > generates a lazy |list| - so I’d expect |ndrange| to generate a lazy
> > |ndarray|. In practice, that means it would be a duck-type defining an
> > |__array__| method to evaluate it, and only implement methods already
> > present in numpy.
>
> Isn't that what arange is for?
>
> It seems like there are two uses of python3's range: 1. creating a 1d
> iterable of indices for use in for-loops, and 2. with list(range) can be
> used to create a sequence of integers.
>
> Numpy can extend this in two directions:
>  * ndrange returns an iterable of nd indices (for for-loops).
>  * arange returns an 1d ndarray of integers instead of a list
>
> The application of for-loops, which is more niche, doesn't need
> ndarray's vectorized properties, so I'm not convinced it should return
> an ndarray. It certainly seems simpler not to return an ndarray, due to
> the dtype question.
>
> arange on its own seems to cover the need for a vectorized version of
> range.
>
> Allan
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20181011/bd646273/attachment.html>