atof approximates the String, I need exact value of the string passed

[oksuresh]

Hi talents,

I have noticed that atof() function approximates the string I pass to
it.

when I use atof() , as atof(" 184.64")
and it returns 184.63999999999

But I would like to have the exact value that is passed.

Could anyone help me?

Thanks
Suresh Ooty

 

[Rolf Magnus]

Hi talents,

I have noticed that atof() function approximates the string I pass to
it.

when I use atof() , as atof(" 184.64")
and it returns 184.63999999999

But I would like to have the exact value that is passed.

Could anyone help me?

No. Floating point types are not exact types. They cannot represent every
possible value. So whenever you convert a number representation of a string
into a floating point value, or take the string representation of a
floating point value, some approxiamtion must be done.

 

[asterisc]

when I use atof() , as atof(" 184.64")

and it returns 184.63999999999

But I would like to have the exact value that is passed.

For floating point operations you should specify some toleration like
EPSILON.
By the way, even the same number, can be represented in two different
representation, that it: if you have: double a = 10.5, b = 10.5; it's
very probable that a != b;
Alaways use: if( fabs ( a - b ) < EPSILON ) then they are equals.

 

[Victor Bazarov]

I have noticed that atof() function approximates the string I pass to
it.

when I use atof() , as atof(" 184.64")
and it returns 184.63999999999

Really? Try this:

#include <stdio.h>
#include <stdlib.h>
int main() {
double d = atof(" 184.64");
printf("%f\n", d);
}

Works for me...

V

 

[Abdo Haji-Ali]

Really? Try this:

#include <stdio.h>
#include <stdlib.h>
int main() {
double d = atof(" 184.64");
printf("%f\n", d);
}

Works for me...

You are right, however looking at the value of d while debugging will
show that d has a value of 184.639999999. But as you can see this makes
no difference as a whole as the calculation would be affected by a very
small amount, if any, and all the printing function would consider
this...

Abdo Haji-Ali
Programmer
In|Framez

 

[Victor Bazarov]

For floating point operations you should specify some toleration like
EPSILON.

If I try using "EPSILON" in my program, it says "undefined identifier".
Do I need to include some header for that?

By the way, even the same number, can be represented in two different
representation, that it: if you have: double a = 10.5, b = 10.5; it's
very probable that a != b;

Really? How "very probable" is that? 0.8? 0.9?

Alaways use: if( fabs ( a - b ) < EPSILON ) then they are equals.

V

 

[osmium]

I have noticed that atof() function approximates the string I pass to
it.

when I use atof() , as atof(" 184.64")
and it returns 184.63999999999

But I would like to have the exact value that is passed.

That *is* the exact value that was passed. It is the best approximation for
that number that the compiler could come up with and it doesn't look like
adding bits to the representation would help. It is analogous to the
problem of representing 1/3 exactly in the decimal number system. Compilers
commonly round the number to a more pleasing number when doing output. If
you can't get the compiler to do that you could round it yourself.

I would guess there are some helpful links or information on this problem in
the FAQ, or try Wikipedia.

 

[Victor Bazarov]

You are right, however looking at the value of d while debugging will
show that d has a value of 184.639999999.

I don't think it's irrelevant. Debugging is not defined in C++ language
Standard. Yes, I know, the world is a cruel place. But can't it be that
your debugger is wrong?

The point I was trying to make was simple: you cannot compare two different
representations. You need to compare two representations of the same kind.
External with external, for example. If you read five significant digits,
you need to compare it with the output that has only five significant digits
otherwise it's bogus.

OK, if you do atof("184.64000000000000000") and then output 20 digits, it's
still possible that you will not get the same sequence of characters. Only
then we can talk about precision of the internal representation because the
number of digits actually exceeds the precision.

But as you can see this
makes no difference as a whole as the calculation would be affected
by a very small amount, if any, and all the printing function would
consider this...

I don't understand that statement, sorry.

V

 

[Pete Becker]

For floating point operations you should specify some toleration like
EPSILON.
By the way, even the same number, can be represented in two different
representation, that it: if you have: double a = 10.5, b = 10.5; it's
very probable that a != b;

On the contrary: they're exactly the same. If you compute the values
differently you may get different results, but that's true of
fixed-width arithmetic in general. You can write examples of integer
arithmetic where computing what looks to us like the same thing produces
different results.

Alaways use: if( fabs ( a - b ) < EPSILON ) then they are equals.

Only do that if you know how the values were computed and that the
result you're getting with that rule makes sense. But keep in mind that
it's not transitive: there are many triples of values a, b, and c such
that a equals b and b equals c, but a does not equal c.

 

[Victor Bazarov]

That *is* the exact value that was passed. It is the best
approximation for that number that the compiler could come up with
and it doesn't look like adding bits to the representation would
help.

Actually, it's the debugger's best approximation of the best approximation
that the run-time could come up with. The compiler doesn't get its hands
on the actual double value. It's a sequence of chars in the source.

[...]

V

 

[Abdo Haji-Ali]

I don't think it's irrelevant. Debugging is not defined in C++ language

Standard. Yes, I know, the world is a cruel place. But can't it be that
your debugger is wrong?

Maybe, but I was building my point view on float representation of
numbers and the debugger seemed to prove it...

The point I was trying to make was simple: you cannot compare two different
representations. You need to compare two representations of the same kind.
External with external, for example. If you read five significant digits,
you need to compare it with the output that has only five significant digits
otherwise it's bogus.

I couldn't agree more...

I don't understand that statement, sorry.

For the first I meant: It's a fact that float can't represent all
numbers accuratley (that's why we need that Epsilon test), however the
Inaccuracy is negligible and won't affect the calculation.
For the second statement I meant : if atoi() would return 184.64 as
184.63999999 then printf() would print 184.63999999 as 184.64

Abdo Haji-Ali
Programmer
In|Framez

 

[osmium]

osmium wrote:

Actually, it's the debugger's best approximation of the best approximation
that the run-time could come up with. The compiler doesn't get its hands
on the actual double value. It's a sequence of chars in the source.

If there is information there, as opposed to words, it eludes me.

 

[Marcus Kwok]

I would guess there are some helpful links or information on this problem in
the FAQ, or try Wikipedia.

I would recommend reading "What Every Computer Scientist Should Know
About Floating-Point Arithmetic" by David Goldberg:

http://docs.sun.com/source/806-3568/ncg_goldberg.html

 

[Pete Becker]

:




If there is information there, as opposed to words, it eludes me.

The debugger translates the internal representation into a text
representation, just like printf does. It typically shows higher
precision, but you can do the same with printf or with iostreams.

 

[Victor Bazarov]

If there is information there, as opposed to words, it eludes me.

Too bad.

V

 

[andy]

Really? How "very probable" is that? 0.8? 0.9?

AFAIK the mapping of "very probable" to a numeric function is up to the
individual application:

http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol2/sbaa/article2.html

(C++ being a useful language in which fuzzy applications can be
written in usefully ... an' all.)

regards
Andy Little

 

[Abdo Haji-Ali]

If I try using "EPSILON" in my program, it says "undefined identifier".
Do I need to include some header for that?

There isn't any, EPSILON depends on your accuracy demands, it could be
0.001, 1 or even 100 so you should define it yourself.

Abdo Haji-Ali
Programmer
In|Framez

 

[Kaz Kylheku]

By the way, even the same number, can be represented in two different
representation, that it: if you have: double a = 10.5, b = 10.5; it's
very probable that a != b;

Actually, it's extremely improbable that two objects of exactly the
same basic type, initialized using exactly the same expression, within
the same region of program text (same declaration even, sharing the
same set of declaration specifiers), will compare unequal.

 

[asterisc]

Actually, it's extremely improbable that two objects of exactly the

same basic type, initialized using exactly the same expression, within
the same region of program text (same declaration even, sharing the
same set of declaration specifiers), will compare unequal.

Indeed, very improbable, but not impossible. Anyway, i just wanted to
express that if you need to check if two floating numbers are equal,
then don't rely on the '==';

If I try using "EPSILON" in my program, it says "undefined identifier".
Do I need to include some header for that?

There is no *standard* EPSILON. You have to define your own, depending
on your needs.
For example, i work in CAD industry, so i have my own EPSILON like
this:

#define EPSILON 0.00001

It's better to use a function that return that (instead of a macro),
or, better a singleton object.

 

[Gavin Deane]

#define EPSILON 0.00001

It's better to use a function that return that (instead of a macro),
or, better a singleton object.

A macro is certainly not the best choice, but, if the epsilon approach
with that value is appropriate for your application, why is a function
or a singleton better than

const double epsilon = 0.00001;

Gavin Deane