feat: add support for specifying a data type "kind" in astype
#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?
There was a problem hiding this comment.
Quick update: I took the liberty to update the wording. I also made the call to broaden the list of data type kinds. I think there are reasonable arguments for providing any one of the numeric data type kinds (e.g., int32 and real floating => float64, etc), and it is possible to delineate a set of clearly defined rules in terms of which data type should be returned. Leaving bool out seems somewhat arbitrary, especially when the semantics are clearly specified and all other kinds can be, IMO, reasonably provided (note: even including "numeric"; i.e., convert anything provided to me to numbers so I can compute the sum, etc).
|
Gentle reminder of the 2024 milestone here! |
There was a problem hiding this comment.
just one nit, otherwise this new wording LGTM, thanks @kgryte !
|
As discussed during the workgroup meeting on January 23, 2025, given that this is new behavior without any downstream implementations, we decided to do two things:
@ev-br Would you mind adding to |
kgryte
changed the title
astype: accept a kind of data typeastype
This PR:
dtypefromuinttointandfloattocomplex? #859 by adding data type "kind" support inastype.