Changed behaviour on how eigency deals with types #73
Conversation
…d reduced overhead in conversions.pyx and conversions.pxd
Signed-off-by: Maki4748 <[email protected]>
Signed-off-by: Maki4748 <[email protected]>
Signed-off-by: Maki4748 <[email protected]>
|
long and ulong are still missing in the tests, thanks to Numpy removing it in 1.24.0 and reintroducing it in a different way in 2.0.0 I need to use compile time conditions, but at the same time cython/cython#4310 is removing the nice way to implement this, so I'm gonna need to figure something out. |
…em for numpy>=2.0.0 Signed-off-by: Maki4748 <[email protected]>
|
@fbordeu I'm not entirely happy with this, but it works and doesn't use anything deprecated. |
|
Wow, lots of work!! I'm going to read the code carefully on Monday. Can you share with me in what project you use eigency. |
|
Sure thing, take your time. Tho I also wanted to work on eigency, cause I saw it wasn't maintained for a while and I figured out how hard it is to find a nice wrapper for these kind of implementations myself. |
| _NDAV(std::complex<float>, ndarray_complex_float, ndarray_complex_float_C, ndarray_complex_float_F) | ||
| _NDAC(std::complex<float>, ndarray_complex_float, ndarray_copy_complex_float_C, ndarray_copy_complex_float_F) | ||
| // This is the currently best option for this mess, tho if I can figure out a better one, I will banish this thing back to the place from whence it came | ||
| _NDAV(signed char, __pyx_fuse_0ndarray, __pyx_fuse_0ndarray_C, __pyx_fuse_0ndarray_F) |
There was a problem hiding this comment.
I understand the problem, I think maybe writing some doc to explain the bijectivity between array_type_t <-> dtype.
I think we need to write down that the order is really important
There was a problem hiding this comment.
We could write this a bit more extreme in the code comment, but the thing won't compile if the order is wrong.
It would just complain, that the type is mismatched, but I totally support making this very very clear in the code comments.
I looked it over yesterday, perfect, thanks, I saw this issue the other day, so it might be a while before we get any new Eigen version. |
…AC and NDAV Signed-off-by: Maki4748 <[email protected]>
|
@fbordeu Please look it over |
@fbordeu This should give us the behaviour we want.
Tests are currently fixed width, tho I'm gonna add some aliases in a bit, with np.long being a big problem, cause it doesn't exist between 1.24.0 and 2.0.0.
On the c++ side the types are handled way differently, every possible type is defined for the Arrays, Maps and Matrices, so we only really give it the object over and it figures the correct type out on it's own.
Same happens in reverse, thanks to typed memoryviews cython deals with finding the correct type and gives it over to numpy.
I wanted to originally write a proposal for this one, since it is a very big change in how eigency deals with Eigen->Numpy, but this right now is the best way I could figure to solve the problem of giving numpy the correct type always and ever with consistent behaviour.
Please look it over.
Also, just to note, the whole mapping the correct function for NDAC and NDAV, I'm working on it, currently this is the best approach, but I'm not happy with this. I got some pointers from some cython devs in cython/cython#6525, but this is gonna take me a bit more googling to figure out.