[Numpy-discussion] Proposal of new function: iteraxis()

Matthew Brett matthew.brett at gmail.com
Thu Apr 25 13:54:12 EDT 2013


On Thu, Apr 25, 2013 at 10:42 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On Thu, Apr 25, 2013 at 6:30 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> Hi,
>> On Thu, Apr 25, 2013 at 10:14 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>> On Wed, Apr 24, 2013 at 10:37 PM, andrew giessel
>>> <andrew.giessel at gmail.com> wrote:
>>>> Hello all-
>>>> A while back I emailed the list about function for the numpy namespace,
>>>> iteraxis(), which allows you to generalize the default iteration behavior of
>>>> numpy arrays over any axis.
>>>> I've implemented this function more cleanly and the pull request is here:
>>>> https://github.com/numpy/numpy/pull/3262, and includes passing tests and
>>>> documentation.
>>>> This is very simple code, which uses np.rollaxis() to bring the desired
>>>> dimension to the front, and then allows you to loop over slices in this
>>>> re-structured view of the array.  While little more than an alias, I feel
>>>> this is a very useful function because looping over iterators is a core
>>>> pattern in python, and makes working with slices of any multidimensional
>>>> array very pythonic.  Adding this function makes this more visible for
>>>> users, new and old, and I hope members of this list will agree it is worth
>>>> adding to the namespace.
>>> I'm afraid I don't. It's a just a reduced-functionality version of
>>> rollaxis(). I don't think the additional name adds anything
>>> substantial.
>> There's a little more on this in the pull request discussion for those
>> of y'all that are interested.
>> So the decision has to be based on some estimate of:
>> 1) Cost for adding a new function to the namespace
>> 2) Benefit : some combination of: Likelihood of needing to iterate
>> over arbitrary axis. Likelihood of not finding rollaxis / transpose as
>> a solution to this. Increased likelihood of finding iteraxis in this
>> situation.
> 3) Comparison with other solutions that might obtain the same benefits
> without the attendant costs: i.e. additional documentation in any
> number of forms.

Right, good point.  That would also need to be weighted with the
likelihood that people will find and read that documentation.



More information about the NumPy-Discussion mailing list