feat: astype: accept a kind of data type
#848
Conversation
rgommers
added
the
API change
There was a problem hiding this comment.
Thanks for getting the ball rolling on this @lucascolley! Some comments inline.
| For ``dtype_or_kind`` a data type, an array having the specified data type. | ||
| For ``dtype_or_kind`` a kind of data type: | ||
| - If ``x.dtype`` is already of that kind, the data type is maintained. | ||
| - Otherwise, an attempt is made to convert to the specified kind, according to the type promotion rules (see :ref:`type-promotion`). |
There was a problem hiding this comment.
Why "an attempt"? That seems ambiguous. We have to be clear about what must work. Which I think is:
- float to complex
- unsigned to signed integer
Anything else doesn't I think? There's no point allowing 'bool' I think, since there is only one boolean dtype so dtype=xp.bool will be cleaner.
For 'signed integer' and 'real floating-point'` there are also no promotion rules to follow, so they can be left out - or do you see a use case?
There was a problem hiding this comment.
I've reduced this down to just 'complex floating' (use-case: mixed float/complex to complex) and 'signed integer' (use-case: mixed signed/unsigned to signed).
I think "an attempt" would still be accurate for an implementation of this? xp.astype(some_int8_array, 'complex floating') would attempt a conversion, whose success will depend on the implementation-specific type promotion rules, right?
Unless you think that this function should always error when the type promotion is not defined by the standard?
There was a problem hiding this comment.
I think "an attempt" would still be accurate for an implementation of this?
I think you have the right idea in mind here, it's just a "language we use to specify things" thing. We specify which behavior has to be supported - 'complex floating' has type promotion rules defined in the standard, so it's expected to always work for a compliant implementation. Then, if we expect other input types to raise, then we specify that by "must raise ..." or "input type must be ...". In this case there's no reason to do that (implementors are free to suppport more types, it's just not standardized), so we then say "input type should be ...".
Your "attempt to ..." seems to be the same as "should be ...", it's just language we want to write in a uniform way.
There was a problem hiding this comment.
how about the wording now?
| - If ``x.dtype`` is already of that kind, the data type must be maintained. | ||
| - Otherwise, ``x`` should be cast to a data type of that kind, according to the type promotion rules (see :ref:`type-promotion`) and the above notes. | ||
| - Kinds must be interpreted as the lowest-precision standard data type of that kind for the purposes of type promotion. For example, ``astype(x, 'complex floating')`` will return an array with the data type ``complex64`` when ``x.dtype`` is ``float32``, since ``complex64`` is the result of promoting ``float32`` with the lowest-precision standard complex data type, ``complex64``. | ||
| - Where type promotion is unspecified and thus implementation-specific, the result is also unspecified. For example, ``astype(x, 'complex floating')``, where ``x`` has data type ``int32``. |
There was a problem hiding this comment.
This is overly restrictive, and conflicts with the behavior specified above. The whole point of astype is to be able to do casts that aren't in the promotion table, like int -> float casts. In fact, I would say this whole line should be deleted as the above note already clearly talks about what is and isn't defined.
There was a problem hiding this comment.
This is overly restrictive, and conflicts with the behavior specified above. The whole point of astype is to be able to do casts that aren't in the promotion table, like int -> float casts
I think there is a misunderstanding - this point applies only in the case that a kind of data type is provided, as this is under the bullet list started on line 63.
Ralf suggested in #848 (comment) that it doesn't make sense to support kinds for which the resulting dtype would always be undefined, given that there are no type promotion rules to follow. Do you disagree?
|
|
||
| - If ``x.dtype`` is already of that kind, the data type must be maintained. | ||
| - Otherwise, ``x`` should be cast to a data type of that kind, according to the type promotion rules (see :ref:`type-promotion`) and the above notes. | ||
| - Kinds must be interpreted as the lowest-precision standard data type of that kind for the purposes of type promotion. For example, ``astype(x, 'complex floating')`` will return an array with the data type ``complex64`` when ``x.dtype`` is ``float32``, since ``complex64`` is the result of promoting ``float32`` with the lowest-precision standard complex data type, ``complex64``. |
There was a problem hiding this comment.
The text you've added here seems to only be thinking about the case where the dtype argument is a string, but the dtype being an actual dtype object is also still supported.
There was a problem hiding this comment.
Line 62 covers the dtype case. Do you have a suggestion to make it more clear?
|
Gentle reminder of the 2024 milestone here! |
#841 (comment) @rgommers