[Numpy-discussion] Numpy 1.7b1 API change cause big trouble
Charles R Harris
Sun Sep 9 14:42:35 CDT 2012
On Sun, Sep 9, 2012 at 11:12 AM, Frédéric Bastien <email@example.com> wrote:
> On Thu, Sep 6, 2012 at 11:32 AM, Charles R Harris
> <firstname.lastname@example.org> wrote:
> > On Thu, Sep 6, 2012 at 10:07 AM, Frédéric Bastien <email@example.com>
> >> Hi,
> >> I reply with more information probably later today or tomorrow, but I
> >> think i need to finish everything to give you the exact information.
> >> Part of the problem I had was that by default there is a warning that
> >> is generated. It tell that to remove this warning we need to set
> >> NPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION.
> > You don't want to define this macro if you need to directly access the
> > fields. What warning are you getting if you don't define it? Are you
> > Cython?
> If I don't define it and I remove the -Werror, I got 3 errors. 1 is
> related to an error message that was changed.
> The second was that we called numpy.dot() with 2 sparse matrix(from
> scipy). It worked in the past, but not now. Changing the test is easy.
> I don't expect people to have done this frequently, but maybe warning
> about this in the release note would help people to fix it faster. The
> error message is not helpful, it tell that it can't find a common
> dtype between float32 and float32 dtype. I changed the np.dot(a,b) to
> a*b as this is the matrix multiplication function for sparse matrix in
> scipy. This change remove the possibility to make a function that use
> matrix product to work with both ndarray and sparse matrix without
> special case for the object type. Not great, but there is an easy work
> around. So this stay like this in the release, there should be a
> The third is releated to change to the casting rules in numpy. Before
> a scalar complex128 * vector float32 gived a vector of dtype
> complex128. Now it give a vector of complex64. The reason is that now
> the scalar of different category only change the category, not the
> precision. I would consider a must that we warn clearly about this
> interface change. Most people won't see it, but people that optimize
> there code heavily could depend on such thing.
> The other problem I had was related to the fact that I tryed to use
> only the new API. This took me a few day and it is not finished, as
> now I have a seg fault that is not easy to trigger. It happen in one
> tests, but only when other tests a ran before... This is probably an
> error from my change
> The sed script that replace some macro helped, but there is few macro
> change that is not in the file: NPY_ALIGNED to NPY_ARRAY_ALIGNED. idem
> for NPY_WRITABLE, NPY_UPDATE_ALL, NPY_C_CONTIGUOUS and
I can add those, they seem to have been present since at least Numpy 1.5.
> The sed script change NPY_ENSURECOPY to NPY_ARRAY_ENSURECOPY, but I
> think that NPY_ARRAY_ENSURECOPY was introduced in numpy 1.7. Maybe
> warning somewhere in the API transition doc that if people want to
> stay compatible with older version of numpy, the should use an
> "#ifndef NPY_ARRAY_ENSURECOPY ..." in there code.
Hmm... Looks like you are right about NPY_ARRAY_ENSURECOPY. An alternative
would be to not deprecate it, but an #ifndef would be better for the long
term goal of having everyone use newer macros.
> I won't have the time to make a PR with those small change as I have a
> deadline the 16 september and the 1 october. I hope my comment will be
> helpful. If you still have questions, don't hesitate.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion