Describe the issue:

xref: numba/numba#8478

For a long time, the .types attribute on ufuncs has contained char typecode descriptions of the implemented loops. For example:

In [1]: import numpy as np

In [2]: np.sin.types
Out[2]: 
['e->e',
 'f->f',
 'd->d',
 'f->f',
 'd->d',
 'g->g',
 'F->F',
 'D->D',
 'G->G',
 'O->O']

Since (I think) NumPy 1.23, ISA specific dispatch loops have been added to some ufuncs, these also appear in .types as additional registrations ahead of the "original" registered loops. Example:

In [3]: np.fmax.types
Out[3]: 
['ff->f',
 'dd->d',
 'gg->g',
 '??->?',
 'bb->b',
 'BB->B',
 'hh->h',
 'HH->H',
 'ii->i',
 'II->I',
 'll->l',
 'LL->L',
 'qq->q',
 'QQ->Q',
 'ee->e',
 'ff->f',
 'dd->d',
 'gg->g',
 'FF->F',
 'DD->D',
 'GG->G',
 'mm->m',
 'MM->M',
 'OO->O']

Note how the ff->f, dd->d and gg->g types occur a) first and are b) replicated later on.

I'm not sure that this is actually an issue that would matter in practice except that...

1. In Numba, the .types is used as part of the matching logic for type specific code generation, this is now broken by the above due to the following. In NumPy 1.23 a call in Numba to np.fmax(int64, int64) resolves via ff->f as it is the first "match" (can cast to the type), whereas prior to this it would first match on ll->l (as none of the types prior to this would be a safe cast).
2. The .types description/char codes are not capturing that some of the loops registered are ISA specific, it looks like a potential mistake/bug in the output.

Essentially this ticket is to seek clarification over the intent so that I can patch Numba against it!

Many thanks in advance for your help.

Reproduce the code example:

import numpy as np
print(np.fmax.types)

Error message:

N/A

NumPy/Python version information:

NumPy version 1.23.1

Context for the issue:

Impacts Numba. xref: numba/numba#8478