[Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)

Charles R Harris charlesr.harris at gmail.com
Sat Mar 5 19:53:58 EST 2011


On Sat, Mar 5, 2011 at 4:20 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:

> On Sat, Mar 5, 2011 at 2:43 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>> On Sat, Mar 5, 2011 at 3:28 PM, Benjamin Root <ben.root at ou.edu> wrote:
>>
>>>
>>>
>>> On Sat, Mar 5, 2011 at 7:44 AM, Pauli Virtanen <pav at iki.fi> 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 <mwwiebe at gmail.com>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110305/8674bc1d/attachment.html>


More information about the NumPy-Discussion mailing list