About divide with floating point
-
Are you trying to get the console app to round (or truncate) the number, or the calculator to show more digits of precision? Or do you need arbitrary high-precision arithmetic (in which case I suggest GMP)?
-
I need (991801 / 1586194) with floating point. In the picture, results are different(Calculator and basic Qt Console Application). How can ı make it like that?!
@Hakan-AFAT said in About divide with floating point:
I need (991801 / 1586194) with floating point. In the picture, results are different(Calculator and basic Qt Console Application).
Your calculator's wrong, I only wanted to point out. You have a rational number with a 7 digit denominator and the representation is given with a precision of 4 digits after the dot ... and the rounded digits are not zeroes ...
Or do you need arbitrary high-precision arithmetic (in which case I suggest GMP)?
If you're going to work with rational numbers, you won't need that.
Read and abide by the Qt Code of Conduct
-
@Hakan-AFAT said in About divide with floating point:
I need (991801 / 1586194) with floating point. In the picture, results are different(Calculator and basic Qt Console Application).
Your calculator's wrong, I only wanted to point out. You have a rational number with a 7 digit denominator and the representation is given with a precision of 4 digits after the dot ... and the rounded digits are not zeroes ...
Or do you need arbitrary high-precision arithmetic (in which case I suggest GMP)?
If you're going to work with rational numbers, you won't need that.
@kshegunov said in About divide with floating point:
@Hakan-AFAT said in About divide with floating point:
I need (991801 / 1586194) with floating point. In the picture, results are different(Calculator and basic Qt Console Application).
Your calculator's wrong, I only wanted to point out. You have a rational number with a 7 digit denominator and the representation is given with a precision of 4 digits after the dot ... and the rounded digits are not zeroes ...
Or do you need arbitrary high-precision arithmetic (in which case I suggest GMP)?
If you're going to work with rational numbers, you won't need that.
I don't follow: first, I don't see how his calculator is wrong. I did the first twelve digits longhand and got exactly what is posted above. Second, the OP says they want a floating point result (not rational), so it's entirely possible that arbitrary precision is needed, depending on the use case.
Chris Hennes, Pioneer Library System
-
@kshegunov said in About divide with floating point:
@Hakan-AFAT said in About divide with floating point:
I need (991801 / 1586194) with floating point. In the picture, results are different(Calculator and basic Qt Console Application).
Your calculator's wrong, I only wanted to point out. You have a rational number with a 7 digit denominator and the representation is given with a precision of 4 digits after the dot ... and the rounded digits are not zeroes ...
Or do you need arbitrary high-precision arithmetic (in which case I suggest GMP)?
If you're going to work with rational numbers, you won't need that.
I don't follow: first, I don't see how his calculator is wrong. I did the first twelve digits longhand and got exactly what is posted above. Second, the OP says they want a floating point result (not rational), so it's entirely possible that arbitrary precision is needed, depending on the use case.
@Chris-Hennes said in About divide with floating point:
first, I don't see how his calculator is wrong.
Ah, I see how can my statement be easily misconstrued. I meant the rightmost-upmost number, that's rounded. I meant it's not correct in the sense that it doesn't show all the relevant digits.
Second, the OP says they want a floating point result
Integer division (as in the OP) is a rational number, so arbitrary precision is overkill, it's an overkill for most other purposes in matter of fact.
Read and abide by the Qt Code of Conduct
-
@Chris-Hennes said in About divide with floating point:
first, I don't see how his calculator is wrong.
Ah, I see how can my statement be easily misconstrued. I meant the rightmost-upmost number, that's rounded. I meant it's not correct in the sense that it doesn't show all the relevant digits.
Second, the OP says they want a floating point result
Integer division (as in the OP) is a rational number, so arbitrary precision is overkill, it's an overkill for most other purposes in matter of fact.
@kshegunov said in About divide with floating point:
@Chris-Hennes said in About divide with floating point:
first, I don't see how his calculator is wrong.
Ah, I see how can my statement be easily misconstrued. I meant the rightmost-upmost number, that's rounded. I meant it's not correct in the sense that it doesn't show all the relevant digits.
Second, the OP says they want a floating point result
Integer division (as in the OP) is a rational number, so arbitrary precision is overkill. You can still represent the rational number (int32 arguments) in a floating point (double) result without a loss of precision as the double has enough mantissa bits for this case. And everything after 0.xxx093 is garbage in this case and shouldn't be regarded as significant at all.
Since the OP's got integers, the notion of "significant digits" does not (necessarily) apply. If I write "1/3" it would seem that from your argument I'd only have one significant digit. The digits after the 0.xxx093 are not "garbage" at all, they are perfectly mathematically valid. Whether the OP truly needs them or not depends on the application.
Chris Hennes, Pioneer Library System
-
@kshegunov said in About divide with floating point:
@Chris-Hennes said in About divide with floating point:
first, I don't see how his calculator is wrong.
Ah, I see how can my statement be easily misconstrued. I meant the rightmost-upmost number, that's rounded. I meant it's not correct in the sense that it doesn't show all the relevant digits.
Second, the OP says they want a floating point result
Integer division (as in the OP) is a rational number, so arbitrary precision is overkill. You can still represent the rational number (int32 arguments) in a floating point (double) result without a loss of precision as the double has enough mantissa bits for this case. And everything after 0.xxx093 is garbage in this case and shouldn't be regarded as significant at all.
Since the OP's got integers, the notion of "significant digits" does not (necessarily) apply. If I write "1/3" it would seem that from your argument I'd only have one significant digit. The digits after the 0.xxx093 are not "garbage" at all, they are perfectly mathematically valid. Whether the OP truly needs them or not depends on the application.
@Chris-Hennes said in About divide with floating point:
The digits after the 0.xxx093 are not "garbage" at all, they are perfectly mathematically valid
Yes, true, I must've been half asleep. So I did correct the post without realizing you had found the fault in my text in the meantime. ;)
Read and abide by the Qt Code of Conduct
-
@Chris-Hennes said in About divide with floating point:
The digits after the 0.xxx093 are not "garbage" at all, they are perfectly mathematically valid
Yes, true, I must've been half asleep. So I did correct the post without realizing you had found the fault in my text in the meantime. ;)
@kshegunov said in About divide with floating point:
@Chris-Hennes said in About divide with floating point:
The digits after the 0.xxx093 are not "garbage" at all, they are perfectly mathematically valid
Yes, true, I must've been half asleep. So I did correct the post without realizing you had found the fault in my text in the meantime. ;)
:) It happens -- and I agree with your statement that arbitrary precision is overkill in most cases. Since I have no idea what the OP is doing with the numbers or what they represent, I tossed the idea out there.
-
I found this repo -> https://github.com/DesarrollosCuado/BCMath-for-Cpp
I ran my sample code and it solved my problem. -
For anyone dropping in this conversation in the future:
Use boost::multiprecision http://www.boost.org/doc/libs/1_64_0/libs/multiprecision/doc/html/boost_multiprecision/tut/floats.html"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
For anyone dropping in this conversation in the future:
Use boost::multiprecision http://www.boost.org/doc/libs/1_64_0/libs/multiprecision/doc/html/boost_multiprecision/tut/floats.htmlI don't agree.
I have said it before, I will say it again:No multiprecision library, and no amount of mantissa bits can save you from unstable summations, from catastrophic cancellation or from other numerical instabilities. Adding more memory and hoping for correct results is like throwing stuff at the wall to see what sticks, it's not how it's done, it's not how it's going to work. Unless you're doing a very precision sensitive calculation where you have made sure your instability doesn't come from a specific operation (or set of operations) adding a multiprecision support only makes your program slower, or at best just defers the inevitable manifestation of the numerical instability.
