<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I am willing to wait for PR <span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji"">#18398 as I am mainly interested at this point in the process of developing a new DType and then array coercion and casting.</span></div><div dir="ltr"><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji""><br></span></div><div><font color="#24292e" face="-apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji">Does </font><a href="https://github.com/numpy/numpy/blob/main/numpy/core/src/umath/_rational_tests.c.src">_rational_tests.c.src</a><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji""> illustrate the new DType?</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 16, 2021 at 4:11 PM Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 2021-03-16 at 13:17 -0500, Lee Johnston wrote:<br>
> Is the work on NEP 42 custom DTypes far enough along to experiment<br>
> with?<br>
> <br>
<br>
TL;DR:  Its not quite ready, but if we work together I think we could<br>
experiment a fair bit.  Mainly ufuncs are still limited (though not<br>
quite completely missing).  The main problem is that we need to find a<br>
way to expose the currently private API.<br>
<br>
I would be happy to discuss this also in a call.<br>
<br>
<br>
** The long story: **<br>
<br>
There is one more PR related to casting, for which merge should be<br>
around the corner. And which would bring a lot bang to such an<br>
experiment:<br>
<br>
<a href="https://github.com/numpy/numpy/pull/18398" rel="noreferrer" target="_blank">https://github.com/numpy/numpy/pull/18398</a><br>
<br>
<br>
At that point, the new machinery supports (or is used for):<br>
<br>
* Array-coercion: `np.array([your_scalar])` or<br>
  `np.array([1], dtype=your_dtype)`.<br>
<br>
* Casting (practically full support).<br>
<br>
* UFuncs do not quite work. But short of writing `np.add(arr1, arr2)`<br>
  with your DType involved, you can try a whole lot. (see below)<br>
<br>
* Promotion `np.result_type` should work very soon, but probably isn't<br>
  is not very relevant anyway until ufuncs are fully implemented.<br>
<br>
That should allow you to do a lot of good experimentation, but due to<br>
the ufunc limitation, maybe not well on "existing" python code.<br>
<br>
<br>
The long story about limitations is:<br>
<br>
We are missing exposure of the new public API.  I think I should be<br>
able to provide a solution for this pretty quickly, but it might<br>
require working of a NumPy branch.  (I will write another email about<br>
it, hopefully we can find a better solution.)<br>
<br>
<br>
Limitations for UFuncs:  UFuncs are the next big project, so to try it<br>
fully you will need some patience, unfortunately.<br>
<br>
But, there is some good news!  You can write most of the "ufunc"<br>
already, you just can't "register" it.<br>
So what I can already offer you is a "DType-specific UFunc", e.g.:<br>
<br>
   unit_dtype_multiply(np.array([1.], dtype=Float64UnitDType("m")),<br>
                       np.array([2.], dtype=Float64UnitDtype("s")))<br>
<br>
And get out `np.array([2.], dtype=Float64UnitDtype("m s"))`.<br>
<br>
But you can't write `np.multiple(arr1, arr2)` or `arr1 * arr2` yet. <br>
Both registration and "promotion" logic are missing.<br>
<br>
I admit promotion may be one of the trickiest things, but trying this a<br>
bit might help with getting a clearer picture for promotion as well.<br>
<br>
<br>
The main last limitation is that I did not replace or create "fallback"<br>
solutions and/or replacement for the legacy `dtype->f-><slots>` yet. <br>
This is not a serious limitation for experimentation, though.  It might<br>
even make sense to keep some of them around and replace them slowly.<br>
<br>
<br>
And of course, all the small issues/limitations that are not fixed<br>
because nobody tried yet...<br>
<br>
<br>
<br>
I hope this doesn't scare you away, or at least not for long :/.  It<br>
could be very useful to start experimentation soon to push things<br>
forward a bit quicker.  And I really want to have at least an<br>
experimental version in NumPy 1.21.<br>
<br>
Cheers,<br>
<br>
Sebastian<br>
<br>
<br>
> Lee<br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div></div>