By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,871 Members | 2,418 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,871 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Apr 12 '06 #1
Share this Question
Share on Google+
21 Replies


P: n/a
ok******@gmail.com wrote:
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.

Apr 12 '06 #2

P: n/a
> 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.

Apr 12 '06 #3

P: n/a
ok******@gmail.com wrote:
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 12 '06 #4

P: n/a
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

Apr 12 '06 #5

P: n/a
asterisc wrote:
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.


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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 12 '06 #6

P: n/a
<ok******@gmail.com> wrote:
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.
Apr 12 '06 #7

P: n/a
Abdo Haji-Ali wrote:
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.


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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 12 '06 #8

P: n/a
asterisc wrote:
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;


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.

--

Pete Becker
Roundhouse Consulting, Ltd.
Apr 12 '06 #9

P: n/a
osmium wrote:
<ok******@gmail.com> wrote:
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.


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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 12 '06 #10

P: n/a
> 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...
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.

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

Apr 12 '06 #11

P: n/a
"Victor Bazarov" writes:
osmium wrote:

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.


If there is information there, as opposed to words, it eludes me.
Apr 12 '06 #12

P: n/a
osmium <r1********@comcast.net> wrote:
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

--
Marcus Kwok
Replace 'invalid' with 'net' to reply
Apr 12 '06 #13

P: n/a
osmium wrote:
"Victor Bazarov" writes:

osmium wrote:


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.

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.

--

Pete Becker
Roundhouse Consulting, Ltd.
Apr 12 '06 #14

P: n/a
osmium wrote:
"Victor Bazarov" writes:
osmium wrote:

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.


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


Too bad.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 12 '06 #15

P: n/a
Victor Bazarov wrote:
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?


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

http://www.doc.ic.ac.uk/~nd/surprise.../article2.html

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

regards
Andy Little

Apr 12 '06 #16

P: n/a

Victor Bazarov wrote:
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

Apr 12 '06 #17

P: n/a
asterisc wrote:
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.

Apr 13 '06 #18

P: n/a
> 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.

Apr 13 '06 #19

P: n/a

asterisc wrote:
#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

Apr 13 '06 #20

P: n/a

asterisc skrev:

[snip]
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 '==';


On the contrary. "==" is the only way to compare equality. Use your
EPSILON stuff to test for proximity, not for anything else.

[snip]

/Peter

Apr 13 '06 #21

P: n/a
asterisc wrote:
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.


Sure. Cosmic rays, random hardware failures, etc. But when you use the
same expression to initialize values of the same type you get the same
value.

Anyway, i just wanted to express that if you need to check if two floating numbers are equal,
then don't rely on the '==';


And that is simply wrong. == tells you whether two floating-point values
are equal. If what you really want to know is whether they're
approximately equal, that's up to you. But when you do that you bring in
a new set of complications that most people who recommend this approach
haven't taken the time to understand.

--

Pete Becker
Roundhouse Consulting, Ltd.
Apr 13 '06 #22

This discussion thread is closed

Replies have been disabled for this discussion.