Bug in conversion from double to integer (only some value)

[Christian Ehrlicher]

I dobut there is a bug in such a simple thing.
Please provide the output of the three toDouble() without multiplication.

[JAHT]

The double value are right.

QString s16 = "1.6";
QString s17 = "1.7";
QString s18 = "1.8";
auto i16 = uint8_t(s16.toDouble() * 10);
auto i17 = uint8_t(s17.toDouble() * 10);
auto i18 = uint8_t(s18.toDouble() * 10);
qDebug() << s16.toDouble() << s17.toDouble() << s18.toDouble();
qDebug() << int(i16) << int(i17) << int(i18);

10:27:17: Starting D:\TrabajoJose\DoubleConversion\build-DoubleConversion-Desktop_Qt_5_15_2_MinGW_32_bit-Debug\debug\DoubleConversion.exe ...
1.6 1.7 1.8
16 16 18

[Christian Ehrlicher]

So no Qt problem here.

[JonB]

@Christian-Ehrlicher , @JAHT
uin8_t(double) does floor not any kind of round, right? So a tiny difference where what shows as 1.7 is actually 1.6999999999999 and * 10 gives 16.999999999 would be enough for uint_t() to produce 16 rather than 17? Still not sure why 32-bit worse than 64-bit, are doubles not 64-bit in both (try printing sizeof(double) in each)? I think this code should not directly use uint_t(double), some sort of math round() first? Or add 0.5 like uint8_t(s17.toDouble() * 10 + 0.5);? I always add 0.5 (or 0.4999 depending on what you want to happen to x.5) before inting a double.

[JAHT]

Yes, it seems that that is the issue, I was wrong when saying the version used by my colleague that it worked, it is Qt 6.6.0 MinGW_64_bit

[Christian Ehrlicher]

Again: this has nothing to do with Qt but maybe with the compiler you're using (mingw version whatever). And @JonB is correct - you should round your number before otherwise it's truncated.

[JonB]

@JAHT
I am a bit lost as to whether you now say it does or does not work correctly in 64-bit MinGW. But in any case if you think about it I suggest you always add 0.5/0.4999 to a double before you int it if you want it rounded not floored.

[JAHT]

@Christian-Ehrlicher @JonB

Thank you for your suggestion.

With 32-bit MinGW it doesn´t work and with 64-bit MinGW it works

[JonB]

If 32-bit MinGW says unit_t(1.7 * 10 + 0.5) == 16 I would be surprised/shocked, and worry about anything (at least with floating point) compiled with it, but I cannot test....

[JAHT]

Yes with:

QString s16 = "1.6";
 QString s17 = "1.7";
 QString s18 = "1.8";
 auto i16 = uint8_t(s16.toDouble() * 10+0.5);
 auto i17 = uint8_t(s17.toDouble() * 10+0.5);
 auto i18 = uint8_t(s18.toDouble() * 10+0.5);
 qDebug() << s16.toDouble() << s17.toDouble() << s18.toDouble();
 qDebug() << int(i16) << int(i17) << int(i18);

The result is as expected with MingW_32

11:22:25: Starting D:\TrabajoJose\DoubleConversion\build-DoubleConversion-Desktop_Qt_5_15_2_MinGW_32_bit-Debug\debug\DoubleConversion.exe ...
1.6 1.7 1.8
16 17 18

Thank you very much @Christian-Ehrlicher @JonB

[Christian Ehrlicher]

@JAHT said in Bug in conversion from double to integer (only some value):

+0.5

use a proper round function or you will get wrong results with negative numbers.

[JonB]

Great that is working now. But can you please write s16.toDouble() * 10 + 0.5 rather than * 10+0.5 as that just encourages mis-reading :)

@Christian-Ehrlicher said in Bug in conversion from double to integer (only some value):

use a proper round function or you will get wrong results with negative numbers.

Never thought about that as I don't have negative numbers! What would you suggest? Because I am worried that round() from the math library delivers its result as a double not an int. Then if the conversion of that from double to int still has some tiny floating point precision issue, as your tests claim to show, I am wondering if that still might produce 16 where it ought be 17...?

[SimonSchroeder]

@JonB said in Bug in conversion from double to integer (only some value):

Because I am worried that round() from the math library delivers its result as a double not an int.

Well, there are also lround and llround (https://en.cppreference.com/w/cpp/numeric/math/round). Hopefully, these two functions don't provide any problems with corner cases.

[JonB]

@SimonSchroeder I didn't know about std::lround(), that should be acceptable if preferred to adding 0.5 and then taking int.