How do I increment a float point num

[Kerry]

Let's say I have float num = 1.1 and have float increment = 0.1 ,
num +=increment doesn't compute exactly to 1.2 ... is there a way to
make it equal exactly to 1.2?

[John Harrison]

On 1 Aug 2004 09:11:52 -0700, Kerry <te************ ****@hotmail.co m> wrote:

Let's say I have float num = 1.1 and have float increment = 0.1 ,
num +=increment doesn't compute exactly to 1.2 ... is there a way to
make it equal exactly to 1.2?

No, for the simple reason that no floating point number exists which
equals one and one fifth. In exactly the same way there is no floating
point number that exactly equals one and one tenth, or any floating point
number that exactly equals one tenth.

Some floating point numbers are exact. Any integral number is exact, as
are fractions like one half, one quarter, one eighth, and multiples
thereof; but tenths you can just forget it, they are inherently
inaccurate. If you need exact artihmetic with tenths then the best way is
to use integers that are ten times bigger than the numbers you actually
need, and then divide by 10 as the last step.

john

[Old Wolf]

"John Harrison" <jo************ *@hotmail.com> wrote:

Some floating point numbers are exact. Any integral number is exact,

I thought this was implementation-dependent. On the only floating point
implementation I've ever looked at closely, integral numbers were not
exact unless they were powers of two. (They were stored as 0 <= m < 1
and integer e, and the value was m * 2^e)

Also, some a-priori reasoning: on my system DBL_MAX is
179769313486231 570814527423731 704356798070567 525844996598917 47680
315726078002853 876058955863276 687817154045895 351438246423432 13268
894641827684675 467035375169860 499105765512820 762454900903893 28944
075868508455133 942304583236903 222948165808559 332123348274797 82620
414472316873817 718091929988125 040402618412485 8368

If integral numbers were exact then 'double' would have to have
1024 bits (approximately) , but on my system, 'double' is 64 bits.

[John Cochran]

In article <84************ *************@p osting.google.c om>,
Old Wolf <ol*****@inspir e.net.nz> wrote:

"John Harrison" <jo************ *@hotmail.com> wrote:

Some floating point numbers are exact. Any integral number is exact,

I thought this was implementation-dependent. On the only floating point
implementati on I've ever looked at closely, integral numbers were not
exact unless they were powers of two. (They were stored as 0 <= m < 1
and integer e, and the value was m * 2^e)

Also, some a-priori reasoning: on my system DBL_MAX is
17976931348623 157081452742373 170435679807056 752584499659891 747680
31572607800285 387605895586327 668781715404589 535143824642343 213268
89464182768467 546703537516986 049910576551282 076245490090389 328944
07586850845513 394230458323690 322294816580855 933212334827479 782620
41447231687381 771809192998812 504040261841248 58368

If integral numbers were exact then 'double' would have to have
1024 bits (approximately) , but on my system, 'double' is 64 bits.

Let me rephrase Mr Harrison's answer.

Any integral number that can be represented in no more bits than the
mantissa is represented exactly. For IEEE double precision with 64 bits,
the mantissa is 53 bits long, it is capable of representing exactly any
integer value that has an absolute value less than or equal to 2^53 - 1
or 9,007,199,254,7 40,991 for any value larger than that, the value stored
is exact. However, not all values may be stored. For example, you may store
9,007,199,254,7 40,992 or 9,007,199,254,7 40,994, but not 9,007,199,254,7 40,993.

[Richard Herring]

In message <84************ *************@p osting.google.c om>, Old Wolf
<ol*****@inspir e.net.nz> writes

"John Harrison" <jo************ *@hotmail.com> wrote:

Some floating point numbers are exact. Any integral number is exact,
I thought this was implementation-dependent. On the only floating point
implementati on I've ever looked at closely, integral numbers were not
exact unless they were powers of two. (They were stored as 0 <= m < 1
and integer e, and the value was m * 2^e)

That's an unusual representation. Many FP formats save a bit by not
storing the leading 1 of the fraction (and treat zero as a special
case), so 1 <= m < 2 or 1/2 <=m < 1, depending where you put the point.

But it still doesn't rule out exact non-powers-of-two. For example, 3
can be stored exactly as m = 3/4 (binary 1100...0), e = 2.

Also, some a-priori reasoning: on my system DBL_MAX is
17976931348623 157081452742373 170435679807056 752584499659891 747680
31572607800285 387605895586327 668781715404589 535143824642343 213268
89464182768467 546703537516986 049910576551282 076245490090389 328944
07586850845513 394230458323690 322294816580855 933212334827479 782620
41447231687381 771809192998812 504040261841248 58368

If integral numbers were exact then 'double' would have to have
1024 bits (approximately) ,
only if every integer less than DBL_MAX could also be stored exactly.
They can't.
but on my system, 'double' is 64 bits.

--
Richard Herring