|
From: | Tom Rondeau |
Subject: | Re: [Discuss-gnuradio] make check fails: assertComplexTuplesAlmostEqual |
Date: | Mon, 2 Jan 2012 22:45:21 -0500 |
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.ThanksShalabhWhat version or checkout are you using?I'm using the latest master branchcommit d0a7de063ce737f186b3e750d1b01b1707b916a6Merge: f88a1e6 8b05eb2Author: Tom Rondeau <address@hidden>Date: Wed Dec 21 10:56:20 2011 -0500This 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!TomFAIL: test01 (__main__.test_fll_band_edge_cc)----------------------------------------------------------------------Traceback (most recent call last):File "./qa_fll_band_edge.py", line 80, in test01self.assertComplexTuplesAlmostEqual (expected_result, dst_data, 4)File "/opt/gnuradio_src/gnuradio-core/src/python/gnuradio/gr_unittest.py", line 71, in assertComplexTuplesAlmostEqualself.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 placesOn Mon, Jan 2, 2012 at 8:38 PM, Marcus D. Leech <address@hidden> wrote:On 02/01/12 07:41 PM, Tom Rondeau wrote:Does our QA structure use randomized test vectors, or fixed ones? If
>
>
> 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.
>
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.ThanksShalabh
[Prev in Thread] | Current Thread | [Next in Thread] |