BIZZARE OUTPUT. SHOULDN'T OUTPUT BE 153 INSTEAD OF 152

Question

int main()
{

  char arr[3]={'1','5','3'};
  int sum=0;
  for (int i=0;i<3;i++)
  {
     sum+=pow((arr[i]-48),3);

     printf("%d to the power 3 is: %f\n",arr[i]-48,pow((arr[i]-48),3));
  }
 printf("sum is %d\n",sum);
}

Expected Output:

1 to the power 3 is: 1.000000
5 to the power 3 is: 125.000000
3 to the power 3 is: 27.000000
sum is 153

Actual Output:

1 to the power 3 is: 1.000000
5 to the power 3 is: 125.000000
3 to the power 3 is: 27.000000
sum is 152

Here is an image of the Output

Shouldn't the output be 153 and NOT 152?

Edit: If instead of sum+=pow((arr[i]-48),3); i use
sum+=(int)(floor(pow((arr[i]-48),3)));

OUTPUT IS CORRECTLY COMING AS 153. So i don't thing pow returning the smaller integer or for that matter type casting of float to integer returning the smaller value is the case over here

Its probably floating point inaccuracy. You're casting it to an int and the floating point value is probably 152.9999999 something. Casting that to int results in 152. — Neijwiert, Jun 11 '18 at 09:54
My previous statement is incorrect. the casting is done in the addition to the sum. There is the problem probably. Same problem origin as my previous comment. — Neijwiert, Jun 11 '18 at 09:56
@Lundin: If Microsoft Visual Studio gave an answer that was too low in integer division, would you consider it an integer arithmetic problem or a Microsoft defect? If the latter, why do you consider the fact that Microsoft `pow` gives an answer too low, when the correct result could in fact be returned, to be a floating-point arithmetic problem? — Eric Postpischil, Jun 11 '18 at 11:02
@Neijwiert if that was the case then instead of sum+=pow((arr[i]-48),3); if i used sum+= (int)(floor(pow((arr[i]-48),3))); the answer should have been 152 only. However ans is 153. Why? — CS Learner, Jun 11 '18 at 14:49

Eric Postpischil · Answer 1 · 2018-06-11T18:30:17.343

The Microsoft pow routine is notoriously bad. It is possible to return correct results for these and similar operands, as the macOS pow demonstrates, but Microsoft either has not put in the engineering work to do this or has chosen not to change their pow implementation. Even for small integer operands with mathematical results that are representable in floating-point, pow may return results that are slightly larger or slightly smaller than the correct value. When returns a result smaller than the exact integer result, then converting it to an integer results in truncation to the next lower integer.

Computing pow is difficult, and not all implementations do a good job. For floating-point functions, the best quality theoretically possible is correctly rounded. A correctly rounded routine returns the number representable in the floating-point format that is closest to the exact mathematical result, rounded in a direction governed by a chosen rounding rule. (The most commonly used rounding rule is to round to the nearest value, with ties toward the even low digit. Other rules include rounding toward +∞, toward −∞, and toward zero.) It is very difficult to compute pow with correct rounding, and no commercial or commonly used implementation I am aware of does so.

Nevertheless, it is possible to design pow so that it returns the exact result whenever the exact result is representable in the floating-point format. As I recall, the current macOS pow implementation does this. Thus, the program in the question, when compiled and executed with macOS tools, will produce the expected results. Microsoft’s pow does not have this property, so computing pow(x, 3) may return a value slightly less than x³, even when x³ is representable.

Even if one is using a high-quality pow implementation, it is generally desirable not to use pow with small integer powers for reasons of speed. Computing pow(x, 3) is slower than computing x*x*x.

BIZZARE OUTPUT. SHOULDN'T OUTPUT BE 153 INSTEAD OF 152

1 Answers1

Linked