Re: Bug#1053265: dipy: test_icm_square test fails since exact equality used with floating point numbers
Hi,
I tried to reproduce this issue. When running autopkgtst in my local
pbuilder chroot I get four failures - but different from the one said
below. When checking Salsa CI[1] it has just one failure which is
pretty strange:
> assert_equal(duration_2core < duration_1core, True)
E AssertionError:
E Items are not equal:
E ACTUAL: False
E DESIRED: True
I wonder whether it makes sense at all to compare the execution times
depending from the number of cores used when running in our CI. Would
you agree that this test should be rather skipped?
Unfortunately I can't reproduce the h5py related issue.
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/dipy/-/jobs/4827654#L790
Am Sat, Sep 30, 2023 at 11:30:59AM +0200 schrieb Drew Parsons:
> Source: dipy
> Version: 1.7.0-2
> Severity: serious
> Justification: debci
>
> h5py 3.9.0 is triggering an error in dipy debci tests,
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dipy/38279462/log.gz
>
> However from the error log, it's not clear that the problem is
> directly related to h5py. An exact [in]equality test is failing
> between floating point numbers.
>
> The error log is:
>
> 1967s _______________________________ test_icm_square ________________________________
> 1967s
> 1967s def test_icm_square():
> 1967s
> 1967s com = ConstantObservationModel()
> 1967s icm = IteratedConditionalModes()
> 1967s
> 1967s initial_segmentation = square
> 1967s
> 1967s mu, sigma = com.seg_stats(square_1, initial_segmentation,
> 1967s nclasses)
> 1967s sigmasq = sigma ** 2
> 1967s npt.assert_(mu[0] >= 0.0)
> 1967s npt.assert_(mu[1] >= 0.0)
> 1967s npt.assert_(mu[2] >= 0.0)
> 1967s npt.assert_(mu[3] >= 0.0)
> 1967s npt.assert_(sigmasq[0] >= 0.0)
> 1967s npt.assert_(sigmasq[1] >= 0.0)
> 1967s npt.assert_(sigmasq[2] >= 0.0)
> 1967s npt.assert_(sigmasq[3] >= 0.0)
> 1967s
> 1967s negll = com.negloglikelihood(square_1, mu, sigmasq, nclasses)
> 1967s
> 1967s final_segmentation_1 = np.empty_like(square_1)
> 1967s final_segmentation_2 = np.empty_like(square_1)
> 1967s
> 1967s beta = 0.0
> 1967s
> 1967s for i in range(max_iter):
> 1967s
> 1967s print('\n')
> 1967s print('>> Iteration: ' + str(i))
> 1967s print('\n')
> 1967s
> 1967s final_segmentation_1, energy_1 = icm.icm_ising(negll, beta,
> 1967s initial_segmentation)
> 1967s initial_segmentation = final_segmentation_1
> 1967s
> 1967s beta = 2
> 1967s initial_segmentation = square
> 1967s
> 1967s for j in range(max_iter):
> 1967s
> 1967s print('\n')
> 1967s print('>> Iteration: ' + str(j))
> 1967s print('\n')
> 1967s
> 1967s final_segmentation_2, energy_2 = icm.icm_ising(negll, beta,
> 1967s initial_segmentation)
> 1967s initial_segmentation = final_segmentation_2
> 1967s
> 1967s difference_map = np.abs(final_segmentation_1 - final_segmentation_2)
> 1967s > npt.assert_(np.abs(np.sum(difference_map)) != 0)
> 1967s E AssertionError
> 1967s
> 1967s dipy/segment/tests/test_mrf.py:370: AssertionError
>
>
> I'm assumung final_segmentation is floating point, not integer.
> Correct me if that's wrong. In general exact equality of floating
> point numbers should always be expected to fail. The test should be
> something like
> npt.assert_( not np.isclose( np.abs(np.sum(difference_map)), 0 ) )
>
>
> If final_segmentation is an integer then of course it's a different
> problem.
>
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
--
http://fam-tille.de
Reply to: