On Mon, Jan 2, 2012 at 10:20 PM, Shalabh Jain <shalabh.j...@gmail.com>wrote:
> 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 > Yeah, I'm about to push a patch for this. I would have put money that the sequence was generated using the random function but that it was seeded. Turns out, we weren't setting the seed. Putting that in fixes the problem. What's still a bit strange is the frequency you are seeing it on the one machine. I had to loop the test dozens of times before seeing it fail on my machine here. Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
