-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Related to gh-12, since it could be nice to keep similar. However, it is somewhat special, as it needs to support things such as alignment.
@ahaldane just pinging you on the off-chance that you have an opinion on this. Right now we use
typedef int (get_transferfunction_func)(
struct _CastingImpl *self,
int aligned,
npy_intp src_stride, npy_intp dst_stride,
PyArray_Descr *src_dtype, PyArray_Descr *dst_dtype,
int move_references,
PyArray_StridedUnaryOp **out_stransfer,
NpyAuxData **out_transferdata,
int *out_needs_api);
is currently how I use this internally. Things like move_references for Object support (I feel it is OK to not allow downstream to implement these things themselves for objects), or the fact NULL is supported for some pointers, is a bit tricky. Also it currently uses NpyAuxData which is fine, but maybe not the API we want if we should make this public.
Another important question is how to handle alignment. Right now we have int alignment; defined on the descriptor struct. We could also make a DType.get_alignment(descriptor) slot/method instead? What would be the best way for a dtype to tell numpy its alignment be? The slot/method is probably best, since it is in principle plausible that one DType class has different alignments.
For the moment we can provide only a very limited API for users and not allow them to actually implement this themselves (i.e. they can only provide contiguous versions, or contiguous + strided version). Allowing us to to