SleefQuadPrecDType kind, char, num

[juntyr]

The kind, char, and num attributes of the SleefQuadPrecDType have weird values:

• kind is \x00
• char is \x00
• num is -1

At least kind should be set to f, the others can probably be left as-is since this is an extension dtype that doesn't have a unique identifier yet.

I'd be happy to submit a patch for kind if you can give me guidance on where to fix it.

[ngoldbaum]

This is true for all user DTypes and cannot be set from inside a user DType implementation. You're not supposed to rely on it to tell DTypes apart that don't come from NumPy.

[juntyr]

I have an as_bits utility function that reinterprets an array to the equivalently-sized unsigned integer type using a.view(a.dtype.str.replace("f", kind)) where kind is usually "u". Since numpy doesn't have a uint128 type, I sometimes use kind "V". However, since the kind is unset, this doesn't work - is there a better way?

[ngoldbaum]

However, since the kind is unset, this doesn't work - is there a better way?

Right now, no, not really.

I think ideally NumPy would have some sort of registration system, see e.g. numpy/numpy#23180 (comment).

I think if you want to support the current version of quad dtype in your library, you'll need to special-case it in the function you're working with.

I'm very aware that this is a problem for adopting user dtypes in the ecosystem. I added a character code to StringDType when I added it to NumPy to avoid dealing with this. It's a decent amount of design work and it probably requires a NEP and I just haven't had time to focus on the issue. If you have time and the appetite to work on NumPy internals this is a place that's ripe for improvement.

We have a NumPy developer Slack community with a #user-dtypes channel that you can join. Do you want an invite?

[juntyr]

We have a NumPy developer Slack community with a #user-dtypes channel that you can join. Do you want an invite?

Yes, that would be great!

[ngoldbaum]

sent to the email address in your CV