On Mon, Jan 2, 2012 at 7:41 PM, Tom Rondeau <trondeau1...@gmail.com> wrote:
> On Mon, Jan 2, 2012 at 7:34 PM, Shalabh Jain <shalabh.j...@gmail.com> > 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 <trond...@vt.edu> 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 <mle...@ripnet.com> 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
