search

vukics / Wigner_Time

Timeline creation and management for open-loop control in AMO experiments and beyond.
Boost Software License 1.0
0 stars 0 forks source link

`np.int32` for the type of cycle count in `add_cycles`, creating a bug in the `finish` section #7

Closed vukics closed 1 week ago

vukics commented 3 weeks ago

This is not reproduced on my Arch Linux box, where the type is np.int64. However, the problem is present on the lab machine.

It makes that the special cycle count 2**31 overflows and wraps around, getting represented as -2147483648

Probably it has to be made explicit somewhere that we want np.int64.

vukics commented 2 weeks ago

Apparently every conversion to int has the potential of downcasting np.int64 to np.int32.

Such conversions happen in adwin.to_tuples and timeline.sanitize.

vukics commented 1 week ago

This is still a problem! Apparently, the ADwin C API (which probably underlies the Python) cannot cope with 64bit integers, either. Should we fall back to 32bits everywhere?

light-matters commented 1 week ago

If the C API cannot cope then I guess we have to :(. That seems like a bug though. You should file something with ADwin.

vukics commented 1 week ago

@light-matters 2**31 actually doesn’t fit an int32, 2**31-1 being the largest positive integer. So this is still an issue in both adwin.py and the *.bas files. I suggest to simply switch to 2**31-1.