[Debian-med-packaging] Bug#1053265: dipy: test_icm_square test fails since exact equality used with floating point numbers

[Andreas Tille]

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 at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de