Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
A C program to find if the input number is palindrome or not
The problem as I see it is that the even numbered powers come out strange. Can anyone please tell me what the problem could be?
The pow function is returning incorrect values right. instead of using the pow in the code multiply 10 with the sum to get the output
remainder = n%10;
reversed = reversed*10 + remainder;
n /= 10;
The best way to get accurate results with pow function would be to use doubles as much as you can. Like most functions using integers for large floating point operations tends to leave you with inaccurate results
The implementation of pow you are using returns incorrect values. For integer powers of 10, it ought to return exactly 1, 10, 100, 1000, et cetera, but it returns values slightly different. Furthermore, when it returns a value slightly under an integer and that value is converted from floating-point to int, it is truncated, so the result of int x = pow(10, 3) may be 999 rather than 1000.
Do not use this pow for exponentiating ten. You can write a simple integer replacement for pow (with another name, of course), or you can rewrite your code to avoid relying on exponentiating ten. (Working iteratively, with 1, 10, 100, 1000, and so on, is often better—simply multiplying by ten at each step instead of exponentiating to calculate the power.)
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 12 months ago.
Improve this question
I've a problem: I would need to concatenate 3 double numbers into one only double number. For example, I've:
a = 40.000000;
b = 56.000000;
c = 10.236330;
I need the following number: 40.5610236330. The integer part is defined by the first two cyphers of a, the first two decimal cyphers are the integer part of b and the other decimal cyphers are all the cyphers of c. I've tried with:
k = a+(b/100)+(c/1000);
But due to approximation error, the result is 40.570236. Could you help me? Thank you so much!
Floating point calculation always loose some precision.
But 40.570236 instead of 40.5610236330 is too much off.
The big error you see is because of a simple bug in your code.
You need k = a+(b/100)+(c/10000); (i.e. c is to be divided by 10000)
Maybe it would be more clear if you did k = a+(b/100)+(c/100/100);
But never expect floating point calculation to 100% precise. It's not even certain that the number 40.5610236330 can be represented in float/double
And further, the input values them self may be imprecise:
double c = 10.236330;
printf("%.20f\n", c);
Output:
10.23633000000000059515
There is enough precision in a double variable to store a number of 12 significant digits (though your question does not really state how many digits c has).
double k= a + b * 0.01 + c * 0.0001;
will work. But when you display it, be sure to use a format with 10 digits after the decimal point (%.10f) so that rounding restores the correct decimals.
This question already has an answer here:
Why the result of pow(10,2) 99 instead of 100? [duplicate]
(1 answer)
Closed last year.
I am trying to use the power function in a program but it is displaying/returning different values in the different text editors. Below is the simple code. I have typecasted since power returns double. In code blocks text editor, the power function is returning 100. But in an atom text editor, it is returning 99. But the same function in atom returns 100 if I replace count by 2. Am I missing installation of any extension in atom?. I don't know what is going on. Any suggestions/corrections are welcome.
#include <stdio.h>
#include <math.h>
int main(){
int count=2;
printf("%d",(int)pow(10,count));
return 0;
}
My guess is that this is due to a floating point rounding error. It may be that, while the real answer is 100, pow(10, 2) is returning 99.99998. When you convert that to an int, the decimal part gets chopped off.
What you can do is, instead of casting right away, run the result through the lround function (also found in math.h). This will return a long.
Avoid the pow function at all cost! It calculates a double raised with a double (for all possible values). This is an extremely complex calculation and it's done using an approximation. Rounding the result instead of using the default double to integer cast (which is defined as "round to zero") helps a bit, but not when the approximation errors more than 0.5.
If you intend to calculate "integer raised with an integer" I strongly suggest that you write your own that simply loops over the exponent -- it's way faster and it doesn't have any approximation problems.
(I say this as someone who has spent 25 years writing C compilers.)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I want to write a fmod() function
double fmod(double x, double y) {
double mod = x;
while(mod >= y)
{
mod -= y;
}
return mod;
}
But fmod(1.2, 0.05) returns 0.05
Although the title asks about incorrect comparison, the comparison in the program shown is correct. It is the only correct floating-point operation in the program; all the others have errors (compared to real-number arithmetic).
In fmod(1.2, 0.05), neither 1.2 nor 0.5 are representable in the double format used in your C implementation. These numerals in source code are rounded to the nearest representable values, 1.1999999999999999555910790149937383830547332763671875 and 0.05000000000000000277555756156289135105907917022705078125.
Then, in the subtraction in mod -= y;, the exact real arithmetic result, 1.14999999999999995281552145343084703199565410614013671875 is not representable, so it is rounded to 1.149999999999999911182158029987476766109466552734375.
Similar errors continue during the calculations, until eventually 0.0499999999999994615418330567990778945386409759521484375 is produced. At each point, the comparison mod >= y correctly evaluates whether mod is greater than or equal to y. When mod is less than y, the loop stops.
However, due to intervening errors, the result produced, 0.0499999999999994615418330567990778945386409759521484375, is not equal to the residue of 1.1999999999999999555910790149937383830547332763671875 divided by 0.05000000000000000277555756156289135105907917022705078125. The correct result can be calculated with the standard fmod function, which returns 0.04999999999999989175325509904723730869591236114501953125.
Note that, when you define a function named fmod, the C standard does not define the behavior because this conflicts with the standard library function of that name. You ought to give it a different name, such as fmodAlternate.
Inside the fmod routine, errors can be avoided. It is possible to implement fmod so that it returns an exact result for the arguments it is given. (This is possible because the result is always in a region of the floating-point range that is fine enough [has a low enough exponent] to represent the real arithmetic result exactly.) However, the errors in providing the arguments cannot be corrected: It is not possible to represent 1.2 or 0.05 in the double format your C implementation uses. The source code fmod(1.2, .05) will always calculate fmod(1.1999999999999999555910790149937383830547332763671875, 0.05000000000000000277555756156289135105907917022705078125), which is 0.04999999999999989175325509904723730869591236114501953125.
An alternative is to represent the numbers differently. For example, you could scale these numbers by a factor of 100, and fmod(120, 5) will return 0. What solution is appropriate depends on the circumstances of the problem you are trying to solve.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
This is C. I am a beginner, so sorry for the experts to whom this question may seem trivial. I am trying to round this float to the nearest integer, away from zero. I've also tried rintf based on some other posts on the internet, but it just won't work! I used printf to check the results, and they weren't rounded to the nearest integer.
//Approximate US grade level.
float index = 0.0588 * L - 0.296 * S - 15.8;
float roundf(float index);
Note that
float roundf(float index);
is a declaration of a function. It is not a call.
If you use float roundf(float index); as function call inside of index = float roundf(float index); you should get a compiler error, but maybe you are on an uncommon compiler. Thus it can be a reason that it "won't work" as expected.
A correct call would be index = round(index);.
I used printf to check the results, and they weren't rounded to the nearest integer.
Note that floating-point precision isn't the best one in case you want to represent integers with it. A float or double can't represent an even integer value fully accurate. It has only a narrowed and limited precision.
Related:
Why not use Double or Float to represent currency?
Functions in C take an input and return an output in this way: output = function(input);. There may be more than one input for some functions, of course, but the principle is that.
For your case, try index = roundf(index); if you want the result to overwrite the non-rounded value.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 3 years ago.
For some reason, ceil(x) rounds up round numbers to x+1.
For example:
double og_grade = 50;
double fact_grade = ceil(og_grade*1.1);
og_grade*1.1 should be 55.0000, but ceil(og_grade*1.1) returns 56.0000
Note that og_grade is always a whole number.
I tried the ceil(x) function, but for some reason when x in already
round, it rounds it up to x+1
No that would mean that the implementation of ceil was defective. Not impossible but extremely unlikely.
It's likely that the x for which this effect is observed is in fact not integral, and the decimal portion is omitted from the formatting or debugger.
Assuming IEEE754, the closest double to 1.1 is slightly larger than that; this most likely accounts for your result.
In your case, given that op_grade is in fact a whole number, your best bet is to use an int for op_grade, and multiply by 11 instead; the subsequent rounding checks are then both trivial and exact.