OK, I looked into the code, so here is a small followup.
On Sun, 2019-05-05 at 10:58 -0400, Alex Samuel wrote: > Hi, > > I'm working on building a number of related custom dtypes, and I'm > not sure how to set the type and kind fields in PyArray_Descr. I > tried using type='V' and choosing a single unused kind for all my > dtypes; this mostly worked, except I found that coercions would > sometimes treat values of two different dtypes as if they were the > same. But not always... sometimes my registered cast functions would > be called. The reason is that when the "kind" and "itemsize" and "byte order" are identical, the numpy code decides that data types can be cast (because they are equivalent). So basically, the "kind" must not be equal unless the "type"/dtype only differs in precision or similar. (The relevant code is in multiarraymodule.c in PyArray_EquivTypes) > > Through trial and error, I've found that if I choose an unused type > code for each dtype, coercion seems to work as I expect it to (no > coercion unless I've provided a cast). The kind doesn't seem to > matter. > > I couldn't find any guidance in the docs for how to choose these > values. Apologies if I've overlooked something. Could someone > please advise me? > Frankly, I do not think there is any, because nobody ever created many types (there is only quaternions and rationals publicly available). > More widely, is there some global registry of these codes? Is the > number of NumPy dtypes limited to the number of (UTF-8-encodable) > chars? It seems like common practice to use dtype.kind in user code. > If I use one or more for my custom dtypes, is there any mechanism to > ensure they do not collide with others'? Are there any other > semantics for either field I should take into account? I have checked the code, and no, there appears to be no such thing currently. I suppose (on the C-side) you could find all types, by using their type number and then asking them. dtype.kind is indeed used a lot, mostly to decide that a type is e.g. an integer. My best guess right now is that the rule you saw above is the only thing you have to take into account. Best, Sebastian > > Thanks, > Alex > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
