-
-
Notifications
You must be signed in to change notification settings - Fork 11k
MAINT: Move can-cast table to a custom header file #21178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the table used here and in numpy/core/src/multiarray/legacy_dtype_implementation.c ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
-O1
which 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.