On Mon, Jan 2, 2012 at 10:45 PM, Tom Rondeau <[email protected]> wrote:
> On Mon, Jan 2, 2012 at 10:20 PM, Shalabh Jain <[email protected]>wrote: > >> On Mon, Jan 2, 2012 at 7:41 PM, Tom Rondeau <[email protected]> >> wrote: >> >>> On Mon, Jan 2, 2012 at 7:34 PM, Shalabh Jain <[email protected]> >>> 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 <[email protected]> >> 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 <[email protected]>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. > > Thanks for the patch Tom. I see the update. I'll try it and let you know the results. > 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. > > The number I reported was the worst case scenario I got. But even the general phenomenon is worst than what you observed.
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
