431,871 Members | 2,418 Online
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
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.63999999999But 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 #include 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 #include 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 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 #include 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.63999999999But 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: 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 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 bestapproximation for that number that the compiler could come up withand it doesn't look like adding bits to the representation wouldhelp.Actually, it's the debugger's best approximation of the best approximationthat the run-time could come up with. The compiler doesn't get its handson 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 thesame basic type, initialized using exactly the same expression, withinthe same region of program text (same declaration even, sharing thesame 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.