I finally got a chance to watch your very interesting SciPy 2013 talk, and I have a comment about the ufunc comparisons - I noticed for example that the matrix shows that astropy.units supports most ufuncs, but this is incorrect (in the current astropy.units implementation). In version 0.2 of Astropy, it's true that ufuncs won't raise an exception, but that is just because Quantity implements __array__ so that any Numpy ufunc will first simply convert the Quantity to an array, then operate on it. This means that even though no exception will be raised, the result will be incorrect:
In [7]: np.sin(np.pi * u.deg)
Out[7]: 1.2246467991473532e-16
i.e. the unit is simply dropped, and the value extracted. I suspect that many of the packages that follow the Container model will have this issue. It might therefore be useful to check the result of the operations.
Note that in astropy/astropy#929 this issue will be solved, so that Numpy ufuncswill return the correct values (with units).
I finally got a chance to watch your very interesting SciPy 2013 talk, and I have a comment about the ufunc comparisons - I noticed for example that the matrix shows that
astropy.unitssupports mostufuncs, but this is incorrect (in the currentastropy.unitsimplementation). In version 0.2 of Astropy, it's true thatufuncswon't raise an exception, but that is just becauseQuantityimplements__array__so that any Numpyufuncwill first simply convert theQuantityto an array, then operate on it. This means that even though no exception will be raised, the result will be incorrect:i.e. the unit is simply dropped, and the
valueextracted. I suspect that many of the packages that follow theContainermodel will have this issue. It might therefore be useful to check the result of the operations.Note that in astropy/astropy#929 this issue will be solved, so that Numpy
ufuncswill return the correct values (with units).