TST: 5 test failures in test_wfc_destripe.py in devdeps about acstools HOT 6 CLOSED

I took a look at the discrepancies and consulted with Norman. Given that the differences are all in the 5th or 6th significant figure and affect <2.5% of pixels in the detector, they are minor enough to ignore. Let me know if there's anything else I can help with.

from acstools.

Thanks! I can look into adjusting the tests when I have time. This is not urgent for now.

from acstools.

I have #185 that would make the CI green but I did find some difference that require me to set the tolerance very high (atol=0.1). Is this something you would accept as a solution? If not, what was the new tolerance you were thinking about (how relaxed are you willing to go)?

from acstools.

I confirmed that the failures are caused by numpy 2.0.dev , not scipy nor astropy dev versions. See #187 (comment)

from acstools.

I ran some tests in a numpy 2.0 dev environment and an environment with current numpy (1.26.2) to track down the cause of the failures. It looks like numpy 2.0 keeps results of some arithmetic in the original dtypes, when the current numpy converts them to np.float64. These differences in dtypes compound floating point errors during subsequent calculations, resulting in the discrepancies we see as test failures. This may explain some of the behavior we're seeing: https://numpy.org/neps/nep-0050-scalar-promotion.html#table-comparing-new-and-old-behaviour

For the failures, I think setting atol = 0.01 should allow the tests to pass. That level of error is acceptable to us given the stripe uncertainties (0.9 e- RMS). If that level of absolute tolerance doesn't work, I'll have to revisit this.

from acstools.

Thanks for investigating, @jryon ! I think atol=0.01 worked. See #192

from acstools.