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
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 7:34 PM, Shalabh J. [email protected]
wrote:
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?
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).
Thanks for pointing this out!
Tom
On 02/01/12 07:41 PM, Tom R. 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!
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Mon, Jan 2, 2012 at 7:41 PM, Tom R. [email protected]
wrote:
During the make check step, one of the tests throws an error asserting
What version or checkout are you using?
I’m using the latest master branch
commit d0a7de063ce737f186b3e750d1b01b1707b916a6
Merge: f88a1e6 8b05eb2
Author: Tom R. [email protected]
Date: Wed Dec 21 10:56:20 2011 -0500
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.
File “./qa_fll_band_edge.py”, line 80, in test01
places
On Mon, Jan 2, 2012 at 8:38 PM, Marcus D. Leech [email protected]
wrote:
The code seems to use a fixed offset to compare with but the data
sequence
is randomly generated.
Thanks
Shalabh
On Mon, Jan 2, 2012 at 10:20 PM, Shalabh J.
[email protected]wrote:
concerns me is the variability across different runs…
Date: Wed Dec 21 10:56:20 2011 -0500
The easy thing is to change the number of points of precision to 2 or 3
Traceback (most recent call last):
AssertionError: -0.20000000000000001 != -0.19991560280323029 within 4
non-repeatable values.
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
On Mon, Jan 2, 2012 at 10:45 PM, Tom R. [email protected]
wrote:
I am having a weird problem during the gnuradio installation. It seems
Does anybody know of any option I can configure to lock the machine
Merge: f88a1e6 8b05eb2
non-repeatable values.
machines which are set up almost the same. But this problem occurs on just
FAIL: test01 (main.test_fll_band_edge_cc)
44, in assertComplexAlmostEqual
sequence is randomly generated.
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.