Maximilian Linhoff
Maximilian Linhoff
@da-woods How can this be not a bug or at least a valid feature request if the fused type system is advertised here for exactly this usecase: https://cython.readthedocs.io/en/latest/src/userguide/numpy_tutorial.html#more-generic-code
In the meantime, I found that implementing the cython function for 1d arrays and using `np.nditer` in python works and already gives a great speedup (especially for contiguous nd-arrays, where...
Let me note that Cython must already have some way of identifying that numpy and c types are actually the same, since I got "ambiguous type overload" errors for something...
Ah, ok, now I understand where the missing information is
> One way of identifying the Numpy scalar types and mapping them to a C type is that you can create a 0D Python memoryview of them (i.e. the builtin...
I just ran into this. Could this be added to the documentation at least mentioning which of the options cannot be given in `setup.cfg`?
@mhvk Want to take a look? I am also not sure if this is something that can go into 5.2 as @pllim set for now, this might need to wait...
> That's because, in the existing implementation, once the value has been converted and broadcasted on the first call to __get__(), it shouldn't be converted or broadcasted again (assuming reasonable...
> Hmm, yes, getting a secondary frame attribute may in fact be a reason for validating on __get__ in the first place. I am not sure what I should make...
That also solves the circular import problem, nice