NEP 40: Informational NEP about current DTypes #15505
Conversation
|
I think it would be helpful to use sub-headings to distinguish between "current model", "problems with the current model", and "ideas toward solving the problems". |
Next pass will be to reorganize everything a bit as Matti suggested it there is a very little start here already
Hopefully nothing broke much, but I think so, also removes a bit of duplication which I had missed before :/
|
It may be worth asking for some help here. E.g. one of the Pandas devs (@TomAugspurger or @jorisvandenbossche any interest, or can you suggest someone?) may be willing to write up one or two examples of where this helps Pandas; @mhvk or @ngoldbaum or @hgrecco may be willing to adapt a units example of astropy.units/unyt/pint where they can see this having value. EDIT: sorry wrong NEP, moving to gh-15506 |
| variable length (string, bytes, | ||
| and void). This distinction is similarly exposed by the C-Macros | ||
| ``PyDataType_ISFLEXIBLE`` and ``PyTypeNum_ISFLEXIBLE``. | ||
| For instance, ``"S8"`` can represent longer strings than ``"S4"``. |
There was a problem hiding this comment.
This sentence feels a little out of place here, but probably is sensible to work in somehow.
| For instance, ``"S8"`` can represent longer strings than ``"S4"``. | ||
|
|
||
| The basic numerical datatypes are not flexible (do not inherit from | ||
| ``npflexible``). Float64, Float32, etc. do have a byte order, but the described |
There was a problem hiding this comment.
| ``npflexible``). Float64, Float32, etc. do have a byte order, but the described | |
| ``np.flexible``). ``float64``, ``float32``, etc. do have a byte order, but the described |
| will lead to the same results, and thus ignores the existing datatype. | ||
| The same logic also applies to floating point scalars, which are allowed to | ||
| lose precision. | ||
| The behavior is not used when both inputs are scalars. |
There was a problem hiding this comment.
Can you give an example here?
|
|
||
|
|
||
| Current Implementation of Casting | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
There was a problem hiding this comment.
For my own reference: made it this far, will come back to the rest later.
There was a problem hiding this comment.
Same commentary as in NEP 41 - mostly suggestions and nearly all of them can be safely ignored. A lot of interesting background info here although I think that it was actually beneficial having read NEP 41 in detail before reading this one as a lot of the context for the discussion (e.g. motivation) is actually better captured in NEP 41.
Also, just a heads-up - it seems like some of the comments from others (such as @stefanv) weren't incorporated even though they were marked as resolved. I noticed something similar on a different PR - you might want to go back and make sure that any accepted suggestions actually got applied/committed correctly.
As in NEP 41, make sure all instances of "user defined" -> "user-defined".
Thanks for putting this together, I certainly learned a lot about the dtype system :)
| lose precision. | ||
| The behavior is not used when both inputs are scalars. | ||
|
|
||
| Although, the above behavior is defined in terms of casting the a given |
There was a problem hiding this comment.
This sentence is a bit rough, maybe:
"Although the above behavior is presented in terms of casting a given scalar value as exposed through np.result_type, this behavior is also important with respect to ufunct dispatching, which currently relies on safe-casting semantics."
I'm not sure that captures the point you were trying to make though.
Co-Authored-By: Ross Barnowski <rossbar@berkeley.edu> Co-Authored-By: Eric Wieser <wieser.eric@gmail.com>
|
Putting this in so it can be better reviewed and discussed. |
Rendered version as of 2020-03-11
This NEP is meant to be mostly informational. The idea is to start a serious of NEPs:
Where the second two could maybe be split up further or simply expanded with time.