New experimental DType example (for physical Unit handling)

Hi all, I have created a new prototype showcasing the new experimental DType and ufunc API here: https://github.com/seberg/unitdtype Aside from showing Units, this is also a good resource to get an idea of how the new (including very complicated) DTypes will look like, as well as how UFuncs should look like. This time it is in C and much more full featured (although some convenience methods are missing) -- expect more of those to be added over time. As of now, it requires a custom NumPy branch (I hope that goes away quickly, but it may always be necessary as new things gets added). It does use `unyt` under-the-hood in order to calculate conversion factors and result units. [1] The code should be able to do quite a lot of things, but of course is not meant to be full-featured yet and bugs are likely if you do stranger things. A main thing is that a good chunk of ufuncs are now supported by "reusing" NumPy's existing ufuncs: * negative, positive * add, subtract * multiple, divide * matmul * fmod * hypot (not sure if this is quite right) * maximum, minimum, fmax, fmin * comparisons (note that we never compare to 0 scalars, unlike some implementations) – that also allows `np.min` and `np.max`. * Logical ufuncs (via casting to boolean) More common things that are definitely not support (as of now!): * `sum` is clunky requiring `initial=QuantityScalar(0, correct_unit)` to work. This is a problem with NumPy's design of the "identity", and the (always known) fix is to improve the identity machinery in NumPy. – I am looking into it, but as usual it requires more cleanup elsewhere for a good solution. * `prod` is more tricky, because its result unit would depend on the number of elements. This (and gufuncs for such operations) would require a specialized, new, API. (I do not think this is hard, but I will not throw myself at it.) * sorting/parititioning and many other functions. Those two can be made to work easily (by using the old API, we should make a new one but that is a different issue). * `arange` and `linspace` each have their problems (linspace just because the `scalar` is not really usable yet). (again, nothing major, although `arange` could use a new machinery) * printing is not great, this requires a cleanup of how NumPy prints... * … Cheers, Sebastian [1] Completely arbitrary and easily replaceable choice, I just found how to get the conversion factors quickly in `unyt`. Plus, without using a dev-version of `astropy`, `astropy.units` sometimes clashes with NumPy `main`.
participants (1)
-
Sebastian Berg