Re: [Numpy-discussion] Numpy 1.10.3 release.
On Wed, Jan 6, 2016 at 8:30 AM, Ralf Gommers wrote: > > > > On Mon, Jan 4, 2016 at 9:38 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: >> >> >> The failed tests require pyrex, fortran, and swig. The refcount error >> comes and goes, probably the test isn't very good. Ralf, is there any >> reason to keep the various extension building tests? They are very old. >> > > There are f2py tests that are useful - if they fail then building anything > else with f2py fails as well. However those are all in f2py/tests/ IRRC, > not in distutils/tests. > >> >> I don't know what the recommendation on using nosetests is, >> > > Don't use it (it definitely gives test errors due to not having the > knownfailure plugin), use either runtests.py or numpy.test(). > > >> but probably it is finding too many tests. >> > > It's doing its job here in finding these though. It looks like these tests > need either fixing (the extensions aren't built) or removing. I'll have a > look tonight. > Should be fixed by https://github.com/numpy/numpy/pull/6955 `nosetests numpy` will still give test errors (6 right now), but only due to not understanding KnownFailureException. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Subclass awareness of outer, inner, dot, ...
Hi All, Having just had a look at functions where astropy's quantities are silently converted to ndarray, I came across some that, in principle, are easy to solve, yet for which, as always, there is a worry about backward compatibility. So, the question arises what to do. As a specific example, consider `np.outer` which is defined in `numeric.py` and boils down to multiply(a.ravel()[:, newaxis], b.ravel()[newaxis,:], out) Since multiply is fine with subclasses, all should be well, except that before it is called, there are `a = asarray(a)` and `b = asarray(b)` statements, which mean subclasses are lost. Obviously, in this case, a simple fix would be to use `asanyarray` instead, but ideally, similar routines behave similarly and hence one would also want to change `np.inner` and `np.dot` (and perhaps more)... Hence, before doing anything, I thought I would ask whether: 1. Such changes are or are not too risky for backward compatibility; 2. If so, whether, given that `np.dot` can be caught using `__numpy_ufunc__`, one should perhaps allow functions such as `outer` also to be passed through that? All the best, Marten ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
