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`.

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

Reply via email to