On Mon, Mar 14, 2011 at 2:22 PM, Mark Wiebe <mwwi...@gmail.com> wrote: > On Sun, Mar 13, 2011 at 7:47 PM, Charles R Harris > <charlesr.har...@gmail.com> wrote: >> >> On Sun, Mar 13, 2011 at 8:23 PM, Mark Wiebe <mwwi...@gmail.com> wrote: >>> >>> On Sun, Mar 13, 2011 at 1:22 AM, Ralf Gommers >>> <ralf.gomm...@googlemail.com> wrote: >>>> >>>> Hi all, >>>> >>>> On Tuesday (~2am GMT) I plan to create the 1.6.x branch and tag the >>>> first beta. So please get your last commits for 1.6 in by Monday >>>> evening. >>>> >>>> Also, please review and add to the 1.6.0 release notes. I put in >>>> headers for several items that need a few lines in the notes, I hope >>>> this can be filled in by the authors of those features (Charles: >>>> Legendre polynomials, Pearu: assumed shape arrays, Mark: a bunch of >>>> stuff). >>> >>> I've added a few more things, and made a small change to the iterator >>> construction API that I've discovered is useful, but would be more difficult >>> to do later. The Python exposure of the iterator is renamed from 'newiter' >>> to 'nditer', is that a reasonable name or does anyone have a better >>> suggestion? >> >> I think nditer is fine, certainly better than newiter. I don't see where >> nditer appears in the changes though, the test still uses newiter. > > I didn't rename the files, I can do that too.
Hi Mark, I see you just did this, but is there anything else you want/need to do? If it's necessary I can postpone the first beta by a couple of days. Better that than rush things too much and end up with an API you have reservations about. Cheers, Ralf >> On the arr_ravel_coords name and the python exposure of same, I've been >> thinking ravel_fancyindex might be more suggestive than ravel_coords. > > Hmm, that doesn't seem quite right to me, it implies something fancier about > it than I think it actually is. Maybe the ideal would be to have it be > ravel_index/unravel_flatindex, but the unravel_index function already > existed as precedent. On the other hand, in lots of contexts just saying > "index" sounds like it should be one number, not a tuple, which is why in > the iterator API the "index" usage refers to a C or Fortran-order flat > index. Of the options we've considered so far, probably ravel_multiindex is > my favorite, though nothing has really stood out. > -Mark > _______________________________________________ > 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