Re: [Discuss-gnuradio] make check fails: assertComplexTuplesAlmostEqual

[Shalabh Jain]

On Mon, Jan 2, 2012 at 7:41 PM, Tom Rondeau <address@hidden> wrote:

On Mon, Jan 2, 2012 at 7:34 PM, Shalabh Jain <address@hidden> wrote:

Hello,

I am having a weird problem during the gnuradio installation. It seems like an issue with treatment of floating point values by the machine. What concerns me is the variability across different runs..

 

During the make check step, one of the tests throws an error asserting that the complex tuples are not equal. I run the same step 10 times continuously, it passes 5 or 6 times. So my installation is probably ok. Its something to do with the way the machine is handling the storage of decimal values. But I just can't figure it out. 

Does anybody know of any option I can configure to lock the machine behavior so that the way floats/doubles are stored is consistent. 

Thanks

Shalabh

What version or checkout are you using?

I'm using the latest master branch

commit d0a7de063ce737f186b3e750d1b01b1707b916a6

Merge: f88a1e6 8b05eb2

Author: Tom Rondeau <address@hidden>

Date:   Wed Dec 21 10:56:20 2011 -0500 

 

This isn't too surprising given the nature of this block. Essentially, the QA code is asking for a control loop to converge after a specific number of samples, and it looks like it's just on the edge.

The variability is something to think about, though. I wonder if the precision of a 32-bit float is off by just enough that it's causing non-repeatable values.

The easy thing is to change the number of points of precision to 2 or 3 here, but I'd like to figure out why it's producing different values for you (and if it's related to the bug with the delay buffering).

Its correct that this error can be easily avoided by reducing the precision when I'm writing my own block. My concern was primarily because given such a large codebase, it would be difficult to differentiate genuine problems from manifestations of such mismatches. I have 2 identical machines which are set up almost the same. But this problem occurs on just one of them.

 

Thanks for pointing this out!

Tom

 

FAIL: test01 (__main__.test_fll_band_edge_cc)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "./qa_fll_band_edge.py", line 80, in test01

    self.assertComplexTuplesAlmostEqual (expected_result, dst_data, 4)

  File "/opt/gnuradio_src/gnuradio-core/src/python/gnuradio/gr_unittest.py", line 71, in assertComplexTuplesAlmostEqual

    self.assertComplexAlmostEqual (a[i], b[i], places, msg)

  File "/opt/gnuradio_src/gnuradio-core/src/python/gnuradio/gr_unittest.py", line 44, in assertComplexAlmostEqual

    (msg or '%s != %s within %s places' % (`first`, `second`, `places` ))

AssertionError: -0.20000000000000001 != -0.19991560280323029 within 4 places

On Mon, Jan 2, 2012 at 8:38 PM, Marcus D. Leech <address@hidden> wrote:

On 02/01/12 07:41 PM, Tom Rondeau wrote:
>
>
> The variability is something to think about, though. I wonder if the
> precision of a 32-bit float is off by just enough that it's causing
> non-repeatable values.
>

Does our QA structure use randomized test vectors, or fixed ones?  If
it's fixed test vectors, then the results
 had better darned well be the same every single time!

 

The code seems to use a fixed offset to compare with but the data sequence is randomly generated. 

Thanks

Shalabh