[entrox]

Originally posted by shortcipher:
This whole issue is very weird and I dont profess to fully understand why non-recurring decimals are so hard to represent (perhaps I am misunderstanding though) however it seems to me that in most circumstances you want the "intelligent" behaviour as demonstrated by calc, even in programming languages such as Javascript/Flash or whatever, the user should be shielded from this type of strangeness as it does them no benefit to have to deal with it. Other languages are undoubtedly different, so please dont flame me. ;-)

It is not weird at all! That's the way IEEE floating point numbers work on computers. There are usually two different representations: single precision (32 Bit) and double precision (64 Bit). A floating point number can be converted into a binary number (how else would you store them in a register?) by using the formula V = (-1)^s * (1.F) * 2^C+E0. 's' is the sign bit, 'F' the mantissa, 'C' the characteristic and 'E0' is an offset. For single precision, the storage is 1 Bit for the sign, 23 Bit for the mantissa and 8 Bit for the offset, which yields us a single 32 Bit number (for double precision, the numbers are 1, 52 and 11).

Let's look at an example: How do we represent the number 123 as a single precision floating point number?

First we convert 123 into binary and then normalise it: 123 is 1111011 in binary and 1,111011 * 2^6 normalised. We then calculate the characteristic: C = 6 - E0 = 6 + 127 = 133, which is 10000101 in binary (E0 is -127 for single precision). 123 is positive, so the sign bit is 0.
We can now put it all together: 0 10000101 11101100000000000000000 (1 Bit sign, 8 Bit characteristic and 23 Bit mantissa).

As you can easily see, all floating point numbers need to be represented using a finite number of Bits so they can fit into a register (I think the PPC FPU uses 64 Bit registers), which of course makes everything inexact. FWIW, AltiVec doesn't work with double precision numbers, so vectorised code is pretty inaccurate.

Is this confusing? Yes. Is it difficult? Yes (these are only the basics). Still, if you don't know how floating point works, you have no business programming computers. It is pretty easy to do integer calculations exact and the better programming languages have provisions for this (e.g. not C/C++/ObjC). Take a look at Common Lisp:

Code:
? (* (/ 1 3) 3) ; calculate (1 / 3) * 3
1
? (/ 28 6) ; calculate 28 / 6
14/3
? (expt 2 128) ; calculate 2^128
340282366920938463463374607431768211456

As you can see, integer arithmetic is represented exactly (and there's no overflow if you exceed 31 Bit!) But what happens, when we use floating point?

Code:
? (/ 1.0 3.0) ; single precision
0.33333334
? (- 1.0 0.9) ; single precision
0.100000024
? (- 1.0d0 0.9d0) ; double precision
0.09999999999999998D0

Well, we get rounding errors! That's the trade-off between being exact and being fast. Even my 150� HP calculator can't calculate everything with arbitrary precision.

[Eug Wanker]

Is speed really that much of an issue for a calculator with a GHz OS X machine?

It's not as if we're trying to do the stuff people do with Mathematica.

[entrox]

Originally posted by Eug Wanker:
Is speed really that much of an issue for a calculator with a GHz OS X machine?

It's not as if we're trying to do the stuff people do with Mathematica.

No, it's not an issue for the calculator. But you still have to make a trade-off: do you use the built-in floating point facilities in the CPU (which have to be fast) or do you re-implement every operation in software to get around the hardware limits? What do you think is the faster method (in development time)?

In my opinion, the calculator should use the latter approach, simply because I expect it to be 'correct' to a certain extent. My HP calculator is smart enough to know that sin(3pi/4) is sqrt(2)/2 and not 0.707106781185...
But this correctness comes at a price and I don't expect Apple to go to great lengths to make the bundled (free) calculator equally good. They just have other priorities.

[shortcipher]

Originally posted by entrox:

Is this confusing? Yes. Is it difficult? Yes (these are only the basics). Still, if you don't know how floating point works, you have no business programming computers.

ah, someone with a single minded opinion of what programming is, excellent.

It would have been better, and slightly less patronising, to say that in many programming situations this knowledge is essential, but by no means is it a defining factor in whether a person has any business programming computers. I have made a very successful business of programming computers for over 10 years and have never needed to know why floating point maths is inaccurate.

Choose your words more carefully please.

[entrox]

Originally posted by shortcipher:
I have made a very successful business of programming computers for over 10 years and have never needed to know why floating point maths is inaccurate.

Choose your words more carefully please.

Why should I? I absolutely stand by what I said. This is amongst the most basic stuff you learn as an undergraduate in the first year of computer sciences or software engineering. I would also immediately distrust every mechanical engineer who admits to not understanding physics.

[Chris O'Brien]

Isn't the whole point of this that you should be able to round numbers to the degree you desire?

To me it seems trivial. If I type in a number to 2 sig. fig. I don't expect to trust an output (and therefore quote it) to anything above 2 sig. fig.

The fact that maths is imprecise on sin functions etc (although, admittedly not the 1.0-0.9-0.1 thing) is inherent in every calculation. We just work to what is accurate enough for our means. You can compound errors as much as you want (try building a dam where the stress analysis over the whole surface gets taken from one side to the other - by the time you're at the end - OUCH!! - you need to make sensible decisions on how to do things).

Anyhoo. Round/think for yourself. Yes, OSX's calculator doesn't do it all for you - but it is still accurate to 10 decimal places - more than you'll probably ever need. On this basis, it is correct, and if you are using it for maths then there is no way it should be beyond your ablity to recognise this and quote the data in a relevant way. No?

And I know that it *should* round up simple calculations (such as sin 90) to what the actually are, but it's not hard for you to do it. It may even make you a better mathematician...

[digital_dreamer]

We�re still discussing this?
Well, let me beat the horse some, too...

There is nothing wrong with the calculator.

Originally posted by chabig:
Part of the problem is that most people don't understand the concept of significant figures and think that if the calculator shows 16 digits they are all significant, regardless of the number of significant figures in the operands. This is not correct.

Chris

Bingo!

What people here fail to realize is that, for all practical purposes, neither of the answers shown here are really incorrect. It�s off by 0.00000000000001. Does the trajectory guiding a probe to Mars know the difference between 2.99999999999999 and 3.00000000000000? Not likely.

However, is it disconcerting, distracting to the user? Yes.

The problem lies in the fact that the number of digits the calculator displays exceeds its rated precision: 16 display digits with 10 digits of precision (without rounding). Far more accuracy that ANYONE here needs.

To get around this issue and get the calculator to respond like any other, that is, work within its rated precision, do this: select View>Precision>10. Close Calculator with Command-W and Quit. (Follow this exactly.) This will save your precision request.

There is nothing wrong with the calculator. It is simply not rounding based on its precision.

Apple should have set the View>Precision to 10 digits and left it at that.
But, instead, Apple chose to implement a 16-digit calculator and allow the user to select the amount of precision s/he wanted to view, although its only accurate to 10 digits of precision in floating point arithmetic without rounding. (Integer arithmetic is accurate to 16 digits of precision, obviously.)

There is nothing wrong with the calculator.

regards,
MAJ

P.S.
It does, however, have some bugs unrelated to calculating: Prefs not saved normally; Paper Tape precision view doesn�t coincide with setting, there may be more...

There is nothing wrong with the calculator.

[Eug Wanker]

Actually what I don't like is the fact that the paper tape disappears when you go to another app. Kinda defeats the point of the paper tape.

[piracy]

What Every Computer Scientist Should Know About Floating-Point Arithmetic

http://docs.sun.com/source/806-3568/ncg_goldberg.html