I guess that if what are (arguably) bugs in matplotlib and
scikit-image are holding up the numpy release, then it's worth CC'ing
their mailing lists in case someone feels like volunteering to fix
On Fri, Jul 4, 2014 at 9:48 PM, Charles R Harris <charlesr.harris@...149...> wrote:
On Fri, Jul 4, 2014 at 2:41 PM, Nathaniel Smith <njs@...503...> wrote:
On Fri, Jul 4, 2014 at 9:33 PM, Charles R Harris >> <charlesr.harris@...149...> wrote:
> On Fri, Jul 4, 2014 at 2:09 PM, Nathaniel Smith <njs@...503...> wrote:
>> On Fri, Jul 4, 2014 at 9:02 PM, Ralf Gommers <ralf.gommers@...149...> >> >> wrote:
>> > On Fri, Jul 4, 2014 at 10:00 PM, Charles R Harris >> >> > <charlesr.harris@...149...> wrote:
>> >> On Fri, Jul 4, 2014 at 1:42 PM, Charles R Harris >> >> >> <charlesr.harris@...149...> wrote:
>> >>> Sebastian Seberg has fixed one class of test failures due to the
>> >>> indexing
>> >>> changes in numpy 1.9.0b1. There are some remaining errors, and in
>> >>> the
>> >>> case
>> >>> of the Matplotlib failures, they look to me to be Matplotlib bugs.
>> >>> The
>> >>> 2-d
>> >>> arrays that cause the error are returned by the overloaded
>> >>> _interpolate_single_key function in CubicTriInterpolator that is
>> >>> documented
>> >>> in the base class to return a 1-d array, whereas the actual
>> >>> dimensions
>> >>> are
>> >>> of the form (n, 1). The question is, what is the best work around
>> >>> here
>> >>> for
>> >>> these sorts errors? Can we afford to break Matplotlib and other
>> >>> packages on
>> >>> account of a bug that was previously accepted by Numpy?
>> > It depends how bad the break is, but in principle I'd say that
>> > breaking
>> > Matplotlib is not OK.
>> I agree. If it's easy to hack around it and issue a warning for now,
>> and doesn't have other negative consequences, then IMO we should give
>> matplotlib a release or so worth of grace period to fix things.
> Here is another example, from skimage.
> ERROR: test_join.test_relabel_sequential_offset1
> Traceback (most recent call last):
> File "X:\Python27-x64\lib\site-packages\nose\case.py", line 197, in
> line 30, in test_relabel_sequential_offset1
> ar_relab, fw, inv = relabel_sequential(ar)
> line 127, in relabel_sequential
> forward_map[labels0] = np.arange(offset, offset + len(labels0) + 1)
> ValueError: shape mismatch: value array of shape (6,) could not be
> to indexing result of shape (5,)
> Which is pretty clearly a coding error. Unfortunately, the error is in
> package rather than the test.
> The only easy way to fix all of these sorts of things is to revert the
> indexing changes, and I'm loathe to do that. Grrr...
Ugh, that's pretty bad :-/. Do you really think we can't use a
band-aid over the new indexing code, though?
Yeah, we can. But Sebastian doesn't have time and I'm unfamiliar with the
code, so it may take a while...
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh