Fix undefined behaviour in dot product kernels

[argilo]

Fixes #651.
Fixes #659.

In tests, the dot product is a summation of 131071 terms, so a fair amount of error can accumulate. From the past CI failures it can be seen that the error can reach a magnitude of 2, so I've set a tolerance of 10 to leave a safe margin.

Since the summation can be close to zero, it makes sense to check the absolute error instead of the relative error. The ccompare function did not have an absolute mode, so I added one.

Update: The test failures and large errors identified in #651 were due to undefined behaviour in the dot product kernels, which sometimes manifested in trailing samples/taps not being included in the calculation. I've updated the pull request to include fixes for that problem.

[argilo]

The test failure is unrelated; it's due to #646.

[argilo]

On my machine I can get away with an absolute tolerance of 1e-2 even if I change the order of floating point operations in the generic kernel by reversing the loop. So I'm confused why the errors have been so much larger in CI. There might be something more to the failures. Let's hold off on merging this until we know what's going on.

[jdemel]

@argilo you could convert this PR into a draft. This would clearly indicate that it is still being worked on.

[argilo]

Aha! The volk_32fc_32f_dot_prod_32fc kernels misbehave because they cast a float* to lv_32fc_t* and then dereference it, which is undefined behaviour.

volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h

Lines 64 to 65 in a26a1b8

	float res[2];
	float *realpt = &res[0], *imagpt = &res[1];

volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h

Line 78 in a26a1b8

*result = *(lv_32fc_t*)(&res[0]);

I got rid of the float array and replaced it with lv_32fc_t, following the model that the accumulator kernels use.

Tests now pass on all platforms, even with the tighter 1e-2 absolute tolerance.

[argilo]

The test failures are unrelated; both are due to #646.

[argilo]

volk_16i_32fc_dot_prod_32fc has the same bug, but I'll leave that one for later.

[argilo]

GNU Radio uses both volk_32fc_32f_dot_prod_32fc and volk_16i_32fc_dot_prod_32fc for FIR filtering, so it will be good to get them cleaned up and tested with tighter tolerances.

[argilo]

volk_16i_32fc_dot_prod_32fc has the same bug, but I'll leave that one for later.

Actually, I'll throw it in here because it will also need the new absolute tolerance code.

[argilo]

The test failure in the latest run is due to #650. At least there's some variety. 😄

[argilo]

Some information about why casting from float[] to std::complex is Undefined Behaviour:

https://stackoverflow.com/questions/23198943/is-it-legal-to-cast-float-to-stdcomplexfloat

[jdemel]

Almost LGTM. Only a very few comments. Thanks!

[jdemel]

Compilers would potentially complain about uninitialized variables here.
I suggest: lv_32fc_t returnValue = lv_cmake(0.0f, 0.0f);
I'd update the other occurrences as well.

[argilo]

I'm not sure compilers would be confused by this particular case, but it would make the code easier to understand for humans. I'll add initializations and change all the updates to +=.

[argilo]

Updated, and rebased on main. It might be a while until CI catches up. 😄

[argilo]

CI has now caught up. ✅

[jdemel]

LGTM