You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On the Debian "ARM 32 bit little Endian Soft Float" ("armel") platform, I get test failures since the platform seems to handle floating point errors differently. This is a regression, but it could probably be ignored?
Expected behavior
The tests should succeed
Actual behavior
I get the following two failures:
______________________ test_linear_fit_model_set_weights _______________________
def test_linear_fit_model_set_weights():
[…]
with pytest.warns(RuntimeWarning,
match=r'invalid value encountered in true_divide'):
> fitted_model = fitter(init_model, x,
np.ma.array(y, mask=np.isclose(weights, 0)),
weights=weights)
E Failed: DID NOT WARN. No warnings of type (<class 'RuntimeWarning'>,) was emitted. The list of emitted warnings is: [].
astropy/modeling/tests/test_model_sets.py:392: Failed
and
____________________ test_blackbody_exceptions_and_warnings ____________________
def test_blackbody_exceptions_and_warnings():
[…]
with pytest.warns(AstropyUserWarning, match='invalid') as w:
bb(0 * u.AA)
> assert len(w) == 3 # 2 of these are RuntimeWarning from zero divide
E assert 1 == 3
E + where 1 = len(WarningsChecker(record=True))
astropy/modeling/tests/test_physical_models.py:119: AssertionError
@plim (guessing the question was general), I checked my patches, and I think they are all not useful for the general. However I found some that disabled failing tests which are claimed to be fixed now -- I will remove and check them tomorrow. Thank for reminidng to look!
As for these particular reported warnings (or lack of), isn't it a good thing that there is less warning? I am not sure if there is anything to fix in astropy as I cannot reproduce them on my machine (which is very different from what is reported). Is it possible to patch these up on Debian side instead?
Sure, this is not a problem at all. I will just remove the check/assumption for zero divide warnings in these places. armel is (in my opinion) also a quite exotic arch for astropy (all recent Raspberries run with armhf or a variant of), and we should not put too much efforts here for an architecture where floating point is emulated by software. That is anyway not where you want to run astropy, and the problem is probably rather the emulation than astropy itself.
I reported this rather since it may point to a real problem and the code author should know it.
This could be tagged with "wontfix" and closed.
Activity
pllim commentedon Nov 9, 2020
@saimn , didn't you work on the linear fit stuff recently?
@karllark , do you remember why you expected 3 warnings for the blackbody test?
karllark commentedon Nov 9, 2020
This test was one that already existed and I just adapted to the new BlackBody model. At least that is what my memory says.
saimn commentedon Nov 9, 2020
Yes, I added this test in #10687, but I have no idea why the warning is not raised (and the same warning is raised a few lines before).
pllim commentedon Nov 10, 2020
@olebole , are there any special patches to
astropyfor this Debian build that we need to know about before jumping into 🐰 🕳️ ?olebole commentedon Nov 10, 2020
@plim (guessing the question was general), I checked my patches, and I think they are all not useful for the general. However I found some that disabled failing tests which are claimed to be fixed now -- I will remove and check them tomorrow. Thank for reminidng to look!
pllim commentedon Nov 10, 2020
As for these particular reported warnings (or lack of), isn't it a good thing that there is less warning? I am not sure if there is anything to fix in
astropyas I cannot reproduce them on my machine (which is very different from what is reported). Is it possible to patch these up on Debian side instead?olebole commentedon Nov 10, 2020
Sure, this is not a problem at all. I will just remove the check/assumption for zero divide warnings in these places. armel is (in my opinion) also a quite exotic arch for astropy (all recent Raspberries run with armhf or a variant of), and we should not put too much efforts here for an architecture where floating point is emulated by software. That is anyway not where you want to run astropy, and the problem is probably rather the emulation than astropy itself.
I reported this rather since it may point to a real problem and the code author should know it.
This could be tagged with "wontfix" and closed.
embray commentedon Jun 21, 2021
Looks like we agreed this one can be closed.