Why does this not give the correct answer?

The short answer is because floating point maths on computers is intrinsically somewhat inaccurate.

The long answer is IEEE 754.

 

This is not an ObjC thing. This is a computers thing. This happens with most computer languages on every platform, and is intrinsic to how floating point math works.

You are getting a perfectly accurate answer for floating point math, it just does not fit into your ascetic desires. You are just used to systems that do a lot of extra work to make things look pretty for you. Others have already provided you with the answers on this. Accept it and move on.

 

Deep Thoughts

I weep for the future.

On a more helpful note, just remember that there's more going on here than may first appear. You can either ignore the man behind the curtain and just get by with your programs, or you can spend some time and effort to understand things.

There are a lot of issues here:
1. binary vs. decimal representation of numbers, particularly fractions;
2. displayed precision vs. calculated precision;
3. digits of accuracy.

Each of those topics is worthy of serious study. For example, the "digits of accuracy" was a prominent topic in a Numerical Analysis course that I took in college (30 years ago). It was offered in the Math department, there was a corresponding one in the Computer Science department that covered the issues from a different perspective.

As an aside, the whole "just-get-by vs. understand-things" conflict is not isolated to your programming life. This is an issue about critical thinking and how you want to live your life. At some point you'll need to make decisions about your finances, insurance, where you live, politics, and many other things. When those issues come up, will you just make a decision or will you think about who's doing what to whom and why they're doing it before making your choice?

 

Just for a cheap thrill, the only kind of thrill I ever get , I wrote this program in C, compiled it, and ran it to get 47.12390.

By the way, I used double, not float, because I think float variables always get converted to double precision.

Code:

#include <stdio.h>
#include <math.h>

static double pi(void)
{
  return 4.0 * atan(1.0);
}

static double circumference (const double diameter)
{
   return pi() * diameter;
}

int main(void)
{
  double diam = 15;

  printf("%lf\n", circumference(diam));
  return 0;
}

 

Yes. If a FPU can do double math, why would you bother implementing single (float) internally? The PPC lfsx loads the 32 bit float and immediately converts it to a 64 bit double for use. The value and/or its derivatives will continue to be doubles internally until written to memory with stfsx. In fact, I think the math unit adds 3 extra bits of precision for computation, which get rounded off on register-write-back. I believe most FPUs work this way, because to support floats internally would be a pointless waste of gates.

The only time you should ever use float is when memory space is a serious concern (almost never, except for extremely large arrays).

32 bit x86 always used a separate internal FPU. I seem to recall x87 internal architecture was 80 bit.

 

I think I have Standard Apple Numerics Environment in hardbound around here somewhere, from about 18 or so years ago. The introduction is pretty amusing, at least to the kind of person who knows how to chat up a CAFEBABE.

 

How are you so sure that the same thing doesn't happen in C#?

This is a fundamental hardware level phenomenon. You would have to implement a software layer that filters the math to eliminate the floating point inaccuracies.

I have even seen these errors in math computation packages, like MATLAB.

I am pretty sure C# via .Net uses the hardware FPU directly. Hence it will also show these errors.

Your initial assumption that C# does not have these inaccuracies is wrong. The reason why you may not have seen them in other languages is probably because you may not have had enough experience with them to come across this.

 

Well I just tried your code in c# .net 4.0.

I get 47.100023 too. It should work the same in VB too, because they are all .net.

I do a lot of work in numerical simulation. So this was one of the first things I noticed.

However, in more "general" programming, you will probably never notice these small errors. And it only happens with floating points too. So if you are working with ints, you will never encounter this problem.

Besides, if you print out a floating point number, the print function may be smart enough correct for the error. So you will never see it unless you spend time in the debugger monitoring each variable.