Re: Same code gives different answers in 2 different scripts
Re: Same code gives different answers in 2 different scripts
- Subject: Re: Same code gives different answers in 2 different scripts
- From: Doug McNutt <email@hidden>
- Date: Wed, 3 Jun 2009 15:53:43 -0600
At 22:23 -0700 6/1/09, Christopher Nebel wrote:
>Long answer: <http://docs.sun.com/source/806-3568/ncg_goldberg.html>.
>
>Short answer: Floating-point math such as AppleScript uses is not exact. What Script Editor displays as the result is often not the precise value of the number, and operations such as "div 1" can reveal the tiny discrepancies. AppleScript is not unique in this; most programming languages use the same floating-point standard.
The long answer is a real treatise. Accurate but perhaps overdone.
Let me suggest an intermediate:
IEEE 64-bit floating point splits the 64 bits into three parts, one bit for the sign, 11 bits for the characteristic, and 52 bits for the "mantissa" which is a common, but incorrect, use of the term.
The mantissa is always treated as a binary fraction between 1/2 and 1. The characteristic is the power of two, positive or negative by which the mantissa is to be multiplied. Because the first bit of a number between 1/2 and 1 is always one it is actually not kept in the 52 bits.
Take a minute to think about those mantissas. in binary .1 means 1/2, .01 means 1/4, .001 means 1/8 and so on. It's a whole lot like those inch marks that still appear, in the US of A anyway, on tape measures and school rulers. It'a also a whole lot like dividing gallons into quarts, pints, cups and on down to teaspoons.
In the world of decimal arithmetic if you try to express 1/3 exactly you start the division process and the first step shows 0.3 with a remainder of 0.1. the second step shows 0.33 with a remainder of .01 and it goes on forever yielding the repeated decimal .333333333 which goes on forever. As soon as you limit the number of digits you introduce the kind of rounding error that's being discussed. Computers will never understand the .3333... symbolism that says "repeat forever"; well, the likes of Maple and Mathematica do make a pretty good effort.
In binary arithmetic there is a similar problem that shows up most often in exact decimal fractions involving odd digits. 0.1 (base 10) is an example. It comes out as 1/16 + 1/32 + 1/256 or the mantissa
0.00011001100110011... which repeats forever but has to be cut off at 52 bits. Sure it's an error but if you want to use a binary computer for decimal fractions you just have to live with it. 64 bit floating point accuracy will always be limited to about 15 decimal digits. For nice numbers like 0.125 you'll get exact results but for 0.1 and 0.7 it just isn't possible.
One thought: Always do your rounding or formatting at the very end of all calculations.
Another: If you can come up with arithmetic that can be done in integers you'll have fewer worries. Doing financial calculations in pennies instead of dollars with fractional parts is fairly simple as long as you stay away from compound interest.
And a third. Think about how much better off we would be if those Persians who invented decimal numbers had ignored their thumbs. A base-8 numeric system would be much easier to work with. Metric standards are not really much better than imperial when it comes to how people like to divide things into halves, quarters and the like.
And we could all go back to the IBM 1620 which did its arithmetic in decimal but somehow I doubt that we'd be happy with the speed of execution.
--
--> If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. <--
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden