2.200000
2.300000
2.400000
2.500000
2.600000
2.700000
2.799999
2.899999
2.999999
3.099999
Im at a loss. My current fix is to use
slope = slope.format("%0.1f").toFloat();
2.200000
2.300000
2.400000
2.500000
2.600000
2.700000
2.799999
2.899999
2.999999
3.099999
slope = slope.format("%0.1f").toFloat();
#include <stdio.h>
int main()
{
float f = 2.2f;
float g = 2.2f;
for (int i = 0; i < 10; ++i) {
fprintf (stdout, "f=%f g=%f\n", f, g + (i * 0.1f));
f += 0.1f;
}
return 0;
}
<Mon 06/27/2016 14:19:01.30>
C:\test>cl t.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
t.cpp
Microsoft (R) Incremental Linker Version 12.00.40629.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:t.exe
t.obj
<Mon 06/27/2016 14:19:25.40>
C:\test>t
f=2.200000 g=2.200000
f=2.300000 g=2.300000
f=2.400000 g=2.400000
f=2.500000 g=2.500000
f=2.600000 g=2.600000
f=2.700000 g=2.700000
f=2.799999 g=2.800000
f=2.899999 g=2.900000
f=2.999999 g=3.000000
f=3.099999 g=3.100000
Shark - I might be speaking out the blowhole in my head (you can call me "friendly_dolphin"!)My use case jim is the user must enter a value between 0 - 25.5 it is a 1 byte field that gets converted to range 0 -255. But I want to store it as the true value, which is the 0.1 precision < 25.5. If a double would eliminate the increment error then no reason why I couldn't I suppose.
But what if you use doubles instead of floats? More memory, but more precision, IIRC...