Re:Converting binary floating-point numbers to integers
by kevingadd on Saturday October 23, 2021 @05:42AM
(#28967004)
If your goal is to benchmark something like to_int64, you should be benchmarking it on a wide range of values instead of just ones and one-halves. You can always pre-generate a diverse data set and shove it in memory - how expensive that is doesn't matter, since all your benchmarks will be paying the same cost to read the test data (unless one of your benchmark test cases is so profoundly slow that it pushes the test data out of cache)
Similarly you definitely should have a table of known numbers you want to test and not just go through the space by 0.5. You want to test denormals, stuff like 1/3, etc.
Re:Converting binary floating-point numbers to integers
by nly on Saturday October 23, 2021 @05:36AM
(#28966977)
Unit test cases should be explicit. For determining if his algorithm is correct he could implement it 2 completely different ways and do bitwise fuzz testing to try and find cases where the output differs.
Re:Converting binary floating-point numbers to integers
by ghoward on Saturday October 23, 2021 @04:34PM
(#28971986)
Or (if he did it with floats), tested it with all 4 billion floats. [1]
[1]: https://randomascii.wordpress.com/2014/01/27/theres-only-fou...
for (double x = 1; x < 1000000000; x += 0.5) {
}The fractional part is always mostly 0.5, or 0.10000... While that shouldn't really affect things, I think a proper test would sample randomly, though this runs into the problem of the random number generator itself influencing the time spent, so I can see the appeal for this method. Perhaps generating a random float array with N elements and calculating the results for x + arr[x%N] would accomplish this.