floating number issues

[Cathyhjj]

Python/np.arange sometimes creates floats like 0.99999999, this may create issues in scan plans, for example, when merging energy_rangies, duplicate values will be removed, but 1.0 and 0.999999 are not considered duplicate values, and both points will be scanned.

[canismarko]

I think this may be solved by the solution in https://github.com/spc-group/haven/commit/d48328cf57e4a8656355bf33b8afe3483651f543 which uses np.linsapce instead of np.arange, ensuring that the final value is properly the requested end point.

[Cathyhjj]

krange(2.8, 14, 0.05) will not give 14 but 13.95, because (14-2.8)/0.05 is supposed to give 224 steps, but 223 was given because python calculates (14-2.8)/0.05 = 223.999999, and int(223.99999) = 223

[canismarko]

We might need to use round() to get around this.

We'll have to think about how to figure out what the digits argument should be. If we wanted to be super fancy, we could calculate it based on the precision of the given float. Maybe something like this:

def round_to_int(num):
    digits = -int(math.log10(math.ulp(num)))
    return int(round(num, digits))

test_value = (14 - 2.8) / 0.05
assert round_to_int(test_value) == 224

I only tested this with the one set of numbers you gave.

[Cathyhjj]

This is a great solution and it has now passed the tests~