Last edited by Dontgiveup; 03-24-2011 at 04:18 PM.
add this to your 'do' loop
do {
double c = (double)(counter - 1);
printf("\n--- %f ",c);
double p = pow(10,c);
printf("%f ",p);
int i = int(p);
printf("%d ",i);
int j = x / i;
printf("%d ",j);
int k = j % 10;
printf("%d ",k);
int z = k;
printf("%d ",z);
int y = (x/(int(pow(10,(double)(counter-1)))))%10;//Here is probably where
printf("%d ---\n",y);
...
here's the result i get
Please enter a number
75767
--- 4.000000 10000.000000 10000 7 7 7 7 ---
seven-
--- 3.000000 1000.000000 1000 75 5 5 5 ---
five-
--- 2.000000 100.000000 100 757 7 7 7 ---
seven-
--- 1.000000 10.000000 10 7576 6 6 6 ---
six-
--- 0.000000 1.000000 1 75767 7 7 7 ---
seven-
the OS doesn't matter but the compiler/library version might. are you using visual C++? which version. i am testing with VC2010
Last edited by dmh2000; 03-24-2011 at 04:26 PM.
I am using DEVC++ version 4.9.9.2. Here is what I got:
Please enter a number
75767
--- 4.000000 10000.000000 10000 7 7 7 7 ---
seven-
--- 3.000000 1000.000000 1000 75 5 5 5 ---
five-
--- 2.000000 100.000000 100 757 7 7 5 ---
five-
--- 1.000000 10.000000 10 7576 6 6 6 ---
six-
--- 0.000000 1.000000 1 75767 7 7 7 ---
seven-
you should change pow(10,... to pow(10.0,... because an integer in the first position means it is a little harder to understand which overload is being used. but that won't fix the problem.
and i used 'printf' instead of 'cout' because I am too old school. that can be cout of course
what the hell. i call compiler/library error. it is almost never that but 'y' should have been == to 'z'.
what the hell. i call compiler/library error. it is almost never that but 'y' should have been == to 'z'.
Last edited by dmh2000; 03-24-2011 at 04:43 PM.
So I wonder where the problem is.
cmath vs math.h - C++ Forum
change the pow(10, to pow(10.0 and see what happens
Changed to pow(10.0 still, the problem is there.
ok, the problem is in the precision of the floating point in the computation of y. i installed dev-c++ and reproduced the problem. I looked at the assembly output of the two versions of computing 'z' and 'y' and they are slightly different.
the 'y' version computes pow(10.0,(counter-1)) in a way that comes out slightly less than the exact value. so in the erroneous computation '5', the pow(10,(counter-1) computes 99.9999999 (instead of 100) and then the cast to int generates 99 instead of 100. when 75767 was divided by 99 it came out as 765 instead of 767 so the digit it output is 5. this is to be expected in mixed floating point and integer that the precision issues cause unexpected results.
the right fix is to round the floating point value up to the next integer before dividing. this will fix the problem.
try this:
int y = (x/(int(pow(10,(counter-1))+0.5)))%10;//Here is probably where
edit : don't use ceiling, it might cause a problem if pow return 100.000000001 whereas the +0.5 won't.
xxxxxxxxor use the ceiling function
xxxxxxxxint y = (x/(int(ceil(pow(10,(counter-1))))))%10;
p.s. someone came in my office while I was working on it that delayed me.
i can't resist a challenge lol
Last edited by dmh2000; 03-24-2011 at 05:42 PM.
Yeah you are right. Now it works flawlessly and is accurate, thanks a lot. Just out of curiosity, although I am a complete beginner, can you tell me from where you got the assembly and managed to find the "error"; just in case I get another problem and I maybe able to see what the problems is.
when you use the Dev-C++ IDE you have a limited selection of compiler options. but in the 'bin' directory of Dev-C++, you can access the compiler directly from the command line and add more options. in the case I compiled with
c:\dev-cpp\bin\g++ -g -c x.cpp
<this produces x.o>
c:\dev-cpp\bin\objdump -S x.o
<this produces the assembler output intermixed with source>
. looking at this, I could see that the assembly for the two computations was slightly different. I didn't figure out exactly what was happening but it gave me the clue to look closer at the floating point terms in the expression.
and as usual I was wrong to call compiler bug. it wasn't. it is just the nature of floating point.
Thank you so much. Now what if I would want to introduce numbers with a point. Example: Someone types in 1234.12 and I would like to print out the answer: one-two-three-point-one-two
For that you'd be better off converting the value to string first.
With floating point values what you see on the screen differs from the value in memory. For output, the value is rounded to some precision whereas the actual value is an approximation with a larger number of digits.
Therefore it may be quite hard to get meaningful results with just arithmetic manipulations. You can't round 2.3199999999999998 and store the result in the double, because it wasn't possible to represent the rounded value 2.32 exactly in the first place.Code:#with Python >>> a = 2.32 >>> print a #print value rounded to default precision 2.32 >>> print "%.16f" % (a,) #output value with a larger precision 2.3199999999999998
All that is linked to the troubles you were having with the pow function earlier.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.