Another kernel with a lot of variying precision is the log2 implementation since it's currently a polynomial approximation with a 6-th degree polynomial.
The glibc implementation uses a 14-th degree polynomial to approximate log2 which turns out to have a maximum error of 2**-58.45. Probably the log2 approx. should be improved to a point where the maximum normalized error is always less than 0.15. The current implementation produces large normalized errors for input values close to 1. ``` offset 98458 in1: -1.70264e-05 in2: -2.47955e-05 measured error was: 0.456301 tolerance was: 0.15 ``` Cheers Andrej On Mon, Oct 08, 2018 at 06:37:50PM +0200, Andrej Rode wrote: > Hi all, > > I just created an issue for that in the volk GitHub repository: > https://github.com/gnuradio/volk/issues/202 > > The normalized error seemed to be in the ~1e-8 range (errors in volk are > normalized to the amplitude of the result in question) > Thus it passes the default error threshold of 1e-6. > > Marcus pointed out offline that some of the intrinsics might even have a > better precision compared to the generic implementation. > > Cheers > Andrej > > On Wed, Oct 03, 2018 at 04:57:32PM -0700, Ron Economos wrote: > > It depends on which box I look at. > > > > 1) volk_32fc_x2_divide_32fc a_avx u_sse3 > > > > 2) volk_32fc_x2_divide_32fc a_avx u_avx > > > > Ron > > > > On 10/03/2018 08:05 AM, Müller, Marcus (CEL) wrote: > > > Well, I'd be willing to call that a bug, all in all: > > > > > > Though I totally get the "machine accuracy" argument, I'd at least > > > expect the same results when running the same program twice, on the > > > same machine. > > > > > > Now, I'm an author of one of the 32fc_x2_divide_32fc implementations; > > > I'd like to know what I can do to fix this. Ron, what was the machine > > > that volk_profile picked for you? > > > > > > By the way, just as for the float/char (and other ints) conversion > > > kernels, it's not inherently obvious who's right or wrong, the > > > optimized or the generic impl. So, we should be analyzing which values > > > led to the differing result. > > > > > > Best regards, > > > Marcus > > > > > > On Wed, 2018-10-03 at 06:52 -0700, Ron Economos wrote: > > >> That's the problem. If a set_output_multiple(4) in added to the > > >> constructor in divide_cc_impl.cc, it solves the issue. > > >> > > >> Ron > > >> > > >> On 10/03/2018 06:42 AM, Ron Economos wrote: > > >>> Well, I guess it's not really a bug. Most likely it has to do with the > > >>> accuracy difference between the x86 intrinsics and the C library. If > > >>> you look at the code in volk_32fc_x2_divide_32fc.h, the remaining > > >>> points that are not a multiple of four are calculated with the C > > >>> library. If the points from one run that are calculated with the C > > >>> library line up with points calculated with intrinsics in the next > > >>> run, there can be a mismatch. > > >>> > > >>> Ron > > >>> > > >>> On 10/03/2018 06:27 AM, Ron Economos wrote: > > >>>> It's a VOLK bug. Go into ~/.volk/volk_profile and change the > > >>>> volk_32fc_x2_divide_32fc line to generic. That fixes the issue here. > > >>>> > > >>>> Ron > > >>>> > > >>>> > > >>>> On 10/03/2018 05:46 AM, Piotr Krysik wrote: > > >>>>> Hi all, > > >>>>> > > >>>>> I simplified the flowgraph a bit and prepared a script that runs it > > >>>>> twice and compares the results. > > >>>>> > > >>>>> https://imgur.com/a/CSjOeLc > > >>>>> > > >>>>> In short something is wrong indeed. > > >>>>> Almost after every run of the script I get results with differences. > > >>>>> > > >>>>> I tested it on GNU Radio 3.7.12.0, I'm compiling the most fresh > > >>>>> version > > >>>>> now. > > >>>>> > > >>>>> Best Regards, > > >>>>> Piotr Krysik > > >>>>> > > >>>>> W dniu 03.10.2018 o 06:55, Reiichiro Nakano pisze: > > >>>>>> Here's an updated flowgraph where you don't need a separate file > > >>>>>> source. Just run the flowgraph twice for a few seconds each. You'll > > >>>>>> likely get different file sizes but `cmp` doesn't care, it'll still > > >>>>>> show the first differing byte which should still prove the bug > > >>>>>> exists. > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- > Andrej Rode > GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Andrej Rode GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA
signature.asc
Description: Digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
