Printable View
well what is wrong with this piece of code ?
#include <stdio.h>
main()
{
double input;
char mystring[50]="143.01";
printf ("%s \n",mystring);
input=atof(mystring);
printf("%f",input);
}
the last printf command is not printing the value 143.01
what is wrong over here ?
--------------------------------------------------------------------------------
What is it printing then?
Take a look at this FAQ as well - C++ String: How to convert a string into a numeric type?
Code:#include <stdio.h>
#include <stdlib.h>
int main()
{
double input;
char mystring[50]="143.01";
printf ("%s \n",mystring);
input=atof(mystring);
printf("%f",input);
}
I suspect that sangfroid is not getting a double that ends in exactly .01. He's probably getting something like 143.0099999999999999999.
If so, then the answer is that even though double's are precise to 15 decimal digits, they are still only an approximation to the "real" number that your are trying to see.
There's no way around this. That's why doubles are usually avoided for financial transactions.
Mike
You are probably right.. but I wanted to know what the OP is getting because as mentioned by JohnyDog, he does not include stdlib and hence the code shouldn't compile even on a compliant compiler.Quote:
Originally Posted by MikeAThon
Just curios here, what kind of financial transactions are you referring to? I have worked on few applications dealing with derivatives pricing and we worked well with double.. although we were only looking for accuracy in not more than 5/6 decimal places. For the case here (OP), rounding rules should work fine.Quote:
Originally Posted by MikeAThon
I was being overly-simplisitc, and as usual, it got me in trouble.Quote:
Originally Posted by exterminator
It's usually impossible to avoid using doubles in financial calculations. For example, how would you ever be able to calcualte mortgages and the like?
I was referring to balance sheet-style situations, where it's necessary to add things up and check for equality with other summations. This can be done with doubles too (e.g., carry around an extra half-cent), but you need to be careful and you need to be aware of what you're doing.
Mike
Thats the thing - i actually tried the code (with gcc) before noticing the missing include and it compiled and run fine, just producing some random number in call to atof. I don't know if it is bug or name conflict with some gcc builtin function or what, but it is definitely interesting :)Quote:
Originally Posted by exterminator
Which version? I compiled it on gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125). It complained of the missing header... and so did gcc version 3.4.2 (mingw-special) and comeau.Quote:
Originally Posted by JohnyDog
4.1.0 - i got warning about undeclared function too, but it linked just fineQuote:
Originally Posted by exterminator
this example should show whats going on.
BTW: gcc doesn't warn if the default warning level is used.Code:#include <stdio.h>
/* #include <stdlib.h> fail to include header */
int main() {
double input, x;
double f = 143.01;
char mystring[50]="143.01";
printf ("s:%s\n",mystring);
printf ("f:%.2f\n",f);
input=atof(mystring); /* atof is not defined so an int return value is assumed */
/* that int is then converted to a double */
printf("%f\n",input);
x = *((int*)&f);
printf("%f\n",x); /* prints the same as above */
return 0;
}
Kurt
ohh sorry for late reply....I tried with this header file...it worked...Thanks a lot
Quote:
Originally Posted by JohnyDog
It typically does compile with a C89 compiler, though, behavior is undefined (and I hope you see it's pure C code).Quote:
Originally Posted by exterminator
IIRC, it may compile with a C++ compiler, because a standard header is allowed to include symbols from another standard header.
Now, the OP surely meets the problem of implicit definition of the symbol atof, as a function taking a char* parameter and returning int. This int is subsequently converted to a floating point number.
On x86 CPU, the convention for returning floating point numbers is different from the convention for int returns, and thus, ax/eax/rax contains a garbage int value after the call to atof.
What explains that the OP may get a value in range [-2147483648; 2147483647] with nothing except zeroes after the decimal point.
Well, actually, behavior is undefined by the standard.
In C99 and C++, implicit declarations have been banned.
One question: I cannot tell why a float equal to 333.33 cannot be print correctly to screen? And after we run ff = f1 + f2; the result is not 333.33? does it mean that result of f1 + f2 will be stored as double then cast back to float for ff?
Thanks a lot in advance!
Code:#include "stdio.h"
void printthefloat(float);
void printthedouble(double);
void main()
{
const char* str_float = "333.33";
double d;
float f1 = 333.0, f2 = 0.33, f3;
float ff = 333.33;
//try to print 333.0
//print 333.0
printthefloat(f1);
//try to print 0.33
//print 0.33
printthefloat(f2);
//try to print 333.33
//however print 333.329987
printthefloat(ff);
ff = f1 + f2;
if(ff == 333.33)
{
printf("we got ff equals to 333.33");
}
//try to print 333.33
//however print 333.329987
printthefloat(ff);
sscanf(str_float, "%lf", &d);
//try to print 333.33 as double
//print 333.33
printthedouble(d);
return;
}
void printthefloat(float f)
{
static int si = 0;
si += 1;
printf("input float-%d is now %f\n", si, f);
}
void printthedouble(double f)
{
static int si = 0;
si += 1;
printf("input double-%d is now %lf\n", si, f);
}
Please do a search here on CodeGuru. This has been discussed so many times here, and in great depth.
Simple answer -- floating point is not exact and cannot be represented exactly with a binary number system, unless the floating point number can be represented by sums of reciprocal powers of 2.
What is 0.33 in binary? Once you figure this out, then you have your answer. 0.33 in binary is a non-terminating, repeating, binary number.
Regards,
Paul McKenzie
Thanks! I searched, but didnot find the answer. Maybe not searching enough. :blush:
http://www.codeguru.com/forum/showthread.php?t=323835
Regards,
Paul McKenzie
1/3 cannot be represented by a decimal number, because 3 is not a divisor of 10.Quote:
Originally Posted by sandodo
Similarly, 1/5 cannot be represented by a binary float, because 5 is not a divisor of 2.
Numbers that can be represented by binary floats are sums of powers of two.
It's easy to see that these numbers can be expressed with this form:
integer*2**i where i is a negative or positive integer.
Thanks Paul McKenzie for the helpful link. :wave:
Thanks. the example of 1/3 cannot be represent by decimal number is very good.Quote:
Originally Posted by SuperKoko
However for, cannot understand...... :confused:Code:integer*2**i
Basically, this means that the only decimal fractions that can be represented exactly in binary are sums of powers (negative or positive) of 2.Quote:
Originally Posted by sandodo
For example:
0.5 can be represented exactly in binary, since:
0.5 = 1/2 = 1 * 2^(-1) (where "^" means "to the power of"). The "**" that Superkoko mentioned is the same as "to the power or".
Similarly, 3/16 can be represented in binary exactly since:
3/16 = 3/(2*8) = 3/(2^(-3)).
So basically if the denominator is 1, 2, 4, 8, 16, 32, 64, etc. the number can be represented in binary exactly.
Regards,
Paul McKenzie
The ** is for "to-the-power". +ve as well as -ve.
Right.Quote:
Originally Posted by exterminator
Good thing that you mention it, since it wasn't obvious.
I used the ** operator, in order to avoid confusion with the C xor operator ^.
But, I probably caused confusion with this least used convention.
Thanks a lot to all of you. You guys are great.
All my best!