Avoid double-precision rounding error in dropq test

[martinholmer]

This pull request makes no substantive changes in test_dropq.py, but does scale back expectations about the equality of two large floating-point numbers in a test that was added in pull request #1060. That new test expected two numbers that are conceptually equal to be the same down to the third decimal place. The new test passed on one local computer, but failed on another local computer (as described in the #1060 conversation). Travis-CI does not run this test because the test uses the confidential puf.csv file. But the two numbers being compared are large: about 1.081e11. So the original test would fail if the two numbers were (for example):

108,100,000,000.001 and
108,100,000,000.002

The expectation was for 15 digits of accuracy, which is at the outer limits of double-precision accuracy. This pull request simply scales back expectations for how close two large floating-point numbers must be to be considered equal.

@talumbau

[codecov-io]

Current coverage is 98.76% (diff: 100%)

Merging #1067 into master will not change coverage

@@             master      #1067   diff @@
==========================================
  Files            38         38          
  Lines          2761       2761          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits           2727       2727          
  Misses           34         34          
  Partials          0          0          

Powered by Codecov. Last update 464010c...80de40e

[talumbau]

looking at the docs for assert_array_almost_equal:

https://docs.scipy.org/doc/numpy/reference/generated/numpy.testing.assert_almost_equal.html

it looks like the more highly recommended choice is assert_allclose:

https://docs.scipy.org/doc/numpy/reference/generated/numpy.testing.assert_allclose.html#numpy.testing.assert_allclose

So I probably should have done that in the first place. I believe that in assert_array_almost_equal the decimal argument is interpreted as "digits of accuracy after the decimal point" so I was surprised to see the decimal=9. We can merge this if you would like and I can do a follow up PR to change to assert_allclose or if you are willing to change to assert_allclose I think that would be the more maintainable solution.

[martinholmer]

@talumbau, Is commit 80de40e in pull request #1067 more like what you want?

[talumbau]

Yes, I think that's better. The default relative tolerance in assert_allclose is 1e-7 which seems good for this use case.

[talumbau]

+1