Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Merged
merged 1 commit into from
Mar 22, 2022

Conversation

seberg
Copy link
Member

@seberg seberg commented Mar 11, 2022

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 this
to 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:

if (CAN_CAST(NPY_UINT, @type@) && PyArray_IsScalar(UInt)) {
     /* get value */
}
else if (...)

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.

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"
Copy link
Member

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 ?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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.

@mattip mattip merged commit d29f8b8 into numpy:main Mar 22, 2022
@mattip
Copy link
Member

mattip commented Mar 22, 2022

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.

Please make sure this doesn't get lost

@seberg
Copy link
Member Author

seberg commented Mar 22, 2022

OK, I can prioritize that part. After gh-21188, or would you prefer to do it before that?

@seberg seberg deleted the can-cast-maint branch March 22, 2022 14:35
@mattip
Copy link
Member

mattip commented Mar 22, 2022

After is fine, even just opening an issue is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants