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.com> 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
17976931348623157081452742373170435679807056752584 499659891747680
31572607800285387605895586327668781715404589535143 824642343213268
89464182768467546703537516986049910576551282076245 490090389328944
07586850845513394230458323690322294816580855933212 334827479782620
4144723168738177180919299881250404026184124858368

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*************************@posting.google.com> ,
Old Wolf <ol*****@inspire.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
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
1797693134862315708145274237317043567980705675258 4499659891747680
3157260780028538760589558632766878171540458953514 3824642343213268
8946418276846754670353751698604991057655128207624 5490090389328944
0758685084551339423045832369032229481658085593321 2334827479782620
41447231687381771809192998812504040261841248583 68

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,740,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,740,992 or 9,007,199,254,740,994, but not 9,007,199,254,740,993.

[Richard Herring]

In message <84*************************@posting.google.com> , Old Wolf
<ol*****@inspire.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
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)

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
1797693134862315708145274237317043567980705675258 4499659891747680
3157260780028538760589558632766878171540458953514 3824642343213268
8946418276846754670353751698604991057655128207624 5490090389328944
0758685084551339423045832369032229481658085593321 2334827479782620
41447231687381771809192998812504040261841248583 68

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