On Sat, Mar 5, 2011 at 4:20 PM, Mark Wiebe <[email protected]> wrote:
> On Sat, Mar 5, 2011 at 2:43 PM, Charles R Harris < > [email protected]> wrote: > >> On Sat, Mar 5, 2011 at 3:28 PM, Benjamin Root <[email protected]> wrote: >> >>> >>> >>> On Sat, Mar 5, 2011 at 7:44 AM, Pauli Virtanen <[email protected]> wrote: >>> >>>> On Fri, 04 Mar 2011 22:58:14 -0600, Benjamin Root wrote: >>>> > I recently had to fix an example in matplotlib where there was a 1xN >>>> > array being assigned to a 1-D slice of a numpy array. It used to >>>> work, >>>> > but it now doesn't. I don't know if this was intended or not, though. >>>> >>>> Probably not -- please file a bug report. If you can also point to a >>>> Numpy version in which it worked, that would also be nice. >>>> >>>> >>> I decided to give git bisect a try. In testing this, I tried two things: >>> >>> a = np.empty((20,)) >>> a[:] = np.random.random((1, 20)) >>> >>> and >>> >>> a[:] = np.random.random((20, 1)) >>> >>> These both currently fail with the same exception message. If I check >>> out and build v1.5.0, the former works, but the latter does not. Going back >>> to v1.4.0, and the latter still doesn't work. Maybe this really shouldn't >>> be considered a bug, and rather a more consistent behavior? >>> >>> By the way, git bisect says that the winner is: >>> >>> d90f19abf18d59be959e04d73b3dbd7ae04b1e89 is the first bad commit >>> commit d90f19abf18d59be959e04d73b3dbd7ae04b1e89 >>> Author: Mark Wiebe <[email protected]> >>> Date: Mon Jan 17 18:26:12 2011 -0800 >>> >>> ENH: core: Change PyArray_MoveInto to use the new iterator as well >>> >>> :040000 040000 a23fbcff385fca9704a5313e81217a6d80e3512c >>> 09b684bd8893e44405534fedad165ce85e751019 M numpy >>> >>> If we agree that this is still a bug and not a feature, I will file a >>> report. >>> >>> >> I think it is more of a feature. The assignment should probably only work >> if the rhs can be broadcast to the lhs. Whatever is decided, we need to make >> a test to enforce it. >> > > +1 for feature. I like stricter checking in most cases. > > Although I think this accounts for some of the failures in tables. Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
