Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: maximum reliable double precision
20 views
Skip to first unread message
Ben Bacarisse
May 11, 2021, 7:08:01 PM5/11/21
to
You've been hit by a bug in Google Groups. Apparently it sometimes
drops the ++ from the geoup name so you end up posting in comp.lang.c.
I've copied my reply to comp.lang.c++ and I've set a followup-to header
so maybe other replies will end up where you expect them to be...
Pawel Por <porp...@gmail.com> writes:
> How can I get maximum reliable double precision ?
> The following program prints 2 values. Both of them are incorrect.
> 5.630500000000001 - precision digits10
> 84983.71643982800015 - precision digits10-1
I see you have been pointer to the well-known paper by Goldberg. It's
excellent, so do read it, but it's way too detailed for answering most
simple questions, and it's not easy to follow if you don't have the
right background.
> #include <iostream>
> #include <limits>
> #include <iomanip>
>
> int main()
> {
> double d = 1.1261 + 2.2522*2;
The most common pit-fall for beginners is that most numbers you type can
not be represented in the machine's variables. You may know that C's
"double" can represent about 17 decimal digits, so 1.1261, having only 5
significant digits, should be fine. It's not.
Internally, the value is stored as a binary fraction. The closest
representable value is 0x1.204816f0068dc in hex. This is about
1.126100000000000100897...
Then 2.2522 will be off by a bit that you multiply by two you can see why
you don't get the result you want.
The solution depends on what you are trying to do. You can squeeze a
bit more precision using long double, and some C implementations support
even wider floating point types (usually in software). Others allow you
to use decimal arithmetic internally, though that, too, has its
limitations. Other software options include using an arbitrary
precision arithmetic library or emulating the calculations you want
using integers. This last option is messy but gives you a lot of
control over intermediate values are handled.
--
Ben.
drops the ++ from the geoup name so you end up posting in comp.lang.c.
I've copied my reply to comp.lang.c++ and I've set a followup-to header
so maybe other replies will end up where you expect them to be...
Pawel Por <porp...@gmail.com> writes:
> How can I get maximum reliable double precision ?
> The following program prints 2 values. Both of them are incorrect.
> 5.630500000000001 - precision digits10
> 84983.71643982800015 - precision digits10-1
I see you have been pointer to the well-known paper by Goldberg. It's
excellent, so do read it, but it's way too detailed for answering most
simple questions, and it's not easy to follow if you don't have the
right background.
> #include <iostream>
> #include <limits>
> #include <iomanip>
>
> int main()
> {
> double d = 1.1261 + 2.2522*2;
The most common pit-fall for beginners is that most numbers you type can
not be represented in the machine's variables. You may know that C's
"double" can represent about 17 decimal digits, so 1.1261, having only 5
significant digits, should be fine. It's not.
Internally, the value is stored as a binary fraction. The closest
representable value is 0x1.204816f0068dc in hex. This is about
1.126100000000000100897...
Then 2.2522 will be off by a bit that you multiply by two you can see why
you don't get the result you want.
The solution depends on what you are trying to do. You can squeeze a
bit more precision using long double, and some C implementations support
even wider floating point types (usually in software). Others allow you
to use decimal arithmetic internally, though that, too, has its
limitations. Other software options include using an arbitrary
precision arithmetic library or emulating the calculations you want
using integers. This last option is messy but gives you a lot of
control over intermediate values are handled.
--
Ben.
Pawel Por
May 12, 2021, 3:57:10 PM5/12/21
to
Thank you for an answer.
You're right I've posted to comp.lang.c++.
You're right I've posted to comp.lang.c++.
0 new messages