Repository navigation
NEP 40: Informational NEP about current DTypes - #15505
Conversation
charris
added
04 - Documentation
component: NEP
01 - Enhancement
and removed
04 - Documentation
labels
stefanv
left a comment
stefanv
left a comment
There was a problem hiding this comment.
Well, I learned a lot—thanks! This was a first pass read, and it would probably be worth (for all these NEPs) looking at the outlines to see if they make sense too. Will ping you about that tomorrow.
stefanv
left a comment
stefanv
left a comment
There was a problem hiding this comment.
Well, I learned a lot—thanks! This was a first pass read, and it would probably be worth (for all these NEPs) looking at the outlines to see if they make sense too. Will ping you about that tomorrow.
|
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". |
stefanv
changed the title
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.
rossbar
left a comment
rossbar
left a comment
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 <[email protected]> Co-Authored-By: Eric Wieser <[email protected]>
|
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.