MAINT: Move can-cast table to a custom header file #21178
Conversation
This is not much cleaner/easier, but the long goal is to remove the whole "promotion table initialization" function. The short term goal is that I would like to have compile time constant `CAN_CAST()` to clean up the scalar code, moving this to a header, rather than a run-time function should help with that. (I am assuming a constant table lookup is fine)
| @@ -15,6 +15,7 @@ | |||
| #include "numpy/npy_math.h" | |||
|
|
|||
| #include "array_coercion.h" | |||
| #include "can_cast_table.h" | |||
There was a problem hiding this comment.
Is the table used here and in numpy/core/src/multiarray/legacy_dtype_implementation.c ?
There was a problem hiding this comment.
Yes, and my new scalar stuff uses it there as well (which could be up for discussion, but right now I think it makes sense). I think it should be possible to remove it from legacy_dtype_implementation.c once the weak-scalar stuff goes in (or is finalized, it may be needed for warnings).
I am wondering if we should move this to common/..., but not sure.
On a separate note, I now think it would make sense to create a .h.src file with a host of inline functions: npy_cast_@from@_to_@to@. It seems likely that we will have a copy of casting logic around for fast scalar math – and for now for the dtype->casts slot. And it probably makes the casting code easier to read anyway.
There was a problem hiding this comment.
So merge this now and then do the refactoring later or do you want to do it now?
There was a problem hiding this comment.
Oh, I am happy to go ahead for now. It doesn't seem terrible and I am not quite sure where to best put it/name it. But if you have a preference, will do that.
Please make sure this doesn't get lost |
|
OK, I can prioritize that part. After gh-21188, or would you prefer to do it before that? |
|
After is fine, even just opening an issue is fine. |
This is not really cleaner/easier, but the long goal is to remove
the whole "promotion table initialization" function.
The short term goal is that I would like to have compile time
constant
CAN_CAST()to clean up the scalar code, moving thisto a header, rather than a run-time function should help with
that. (I am assuming a constant table lookup is fine,
godbold suggests it is, although you need
-O1which seems OK).I didn't have a better idea than this... My current plan is to use (templated) code for the scalar math like:
but I don't like the idea of that requiring a run-time lookup. Moving this to a header means that the compiler should be able to resolve it at compile time.
Plus, I don't actually it is worse, either way you need a bit to grok the templating or the macros...
EDIT: Or well, a switch statement maybe. I have to still dig a bit. A major thing is to decide when the binary operator should defer.