[jakapaka]

I found while making my Debian 6 package for Kodi RC3 that the unit tests for fft try to compare for equality float numbers, and fail (for the last decimal or so). I think when comparing floating numbers some accuracy margin should be taken into account. I've made some simple searches on the forum but I haven't seen anything about this.

As a sample:

Testfft.cpp:283: Failure
Value of: varstr.c_str()
Actual: "8.778495"
Expected: refstr.c_str()
Which is: "8.778496"

We can argue that this difference is greater than 24-bit resolution, but no greater than 16-bit.

I'm not acquainted with this set of unit testing tools, but should it be easy to specify a comparison within 1/10000 (barely better than 16bit) or so? Right now I have disabled the two tests affected.

Regards

[ironic_monkey]

the reason for stuffing it into a string first is to have roundoff to 6 decimals. you are unlucky and it just rounds "wrong" in your case. certainly a fugly hack instead of using the fuzzy comparison functions of gtest (which iirc can't do vectors but a loop won't kill ya).

6 decimals for a float. whoever wrote this did not consider roundoff effects..

[jakapaka]

So maybe it'd be wiser to truncate the string to a specific number of places (as floats mantissa and number of decimals are related but not the same) than epsilon'd comparisons.

I'll give it a try...