Support for NumPy 2.0 in Neo Core
following a policy of NEP 29 + 1 year.
Looks like we have some work to do :)
note that quantities 0.16.0, with support for NumPy 2.0, has just been released
I updated the branch so we should see the neo problems vs the quantities in the testing!
I think @JuliaSprenger saw this error before right?
AssertionError: array(99.) * mV == array(99.) * mV
Actually this is an example of an error related to the fact we no longer have the copy behavior. this test was an assertNotEqual, but because the data is now a copy we edited in place and so the array is the same when it shouldn't be.
Let's squash this one when it is ready. A lot of this is me tweaking the action and then messing up on one version. So a lot of these are trash commits.
Okay current core failures can be reproduced with the following:
>>> import quantities as pq
>>> import numpy as np
>>> times = np.arange(10, dtype=np.float32)
>>> times.dtype
'float32'
>>> times= times * pq.ms
>>> times.dtype
'float64'
and for the other failing test
>>> import quantities as pq
>>> import numpy as np
>>> times = [1,2,3] * pq.s
>>> np.concatenate((times, times))
array([1,2,3,1,2,3]) * dimensionless
I need to read more about numpy 2.0 changes to figure out these parts of the tests that have changed. Any ideas @apdavison and @samuelgarcia ?
The first issue seems like it could be numpy but the second issue seems like quantities needs to hand np.concatenate better no?
Actually it was a change in default numpy behavior which requires an extra as type in tests. My bad.
Once #1585 is in main we can merge main into this which fixes the RTD error. Then this ready.
Note this is only for the core of Neo. I want to do the RawIO/IO in a separate PR.
Also a reminder please squash before merge and let's at minimum wait until after the point release :)
RTD is not building the correct version of neo. I don't know why. Maybe I just need to give it a little time (I had hoped switching to 3.12 would flush any cache, but it still had the wrong Neo and it had other errors). I'll just try to rerun RTD build this weekend and see if time fixes it.
Sam and I looked over the RTD failure and we aren't sure why it is happening. I think it should fix itself once this is merged into main since the problem showing up is fixed in main.
@apdavison this is ready for review, the RTD is broken with some cache issue, but I fixed the problem on main (and merging main into this branch didn't fix it). so our options are you review and merge ignoring the RTD problem or I open a new PR built off of the current main and make the exact same fixes to make sure all tests pass. What's your preference?
thanks for for @zm711 @apdavison and @alejoe91
I did not folow so much. Does finally we are making a copy of the buffer every time we create a data object from numpy or not ?
It should force the user to return a view rather than a copy. So if someone wants to change the dtype at initialization they can't create a copy anymore at that stage. So they have to return the view and then change the dtype themselves (which will make the copy later). Same is true for quantity units. They can no longer change units at initialization. They have to do it later and make a copy at that time.
I think a couple structures may need to copy the view at a few places because of the views, but globally everything should start out as views.