Math issue, isn't it?

[Jan Schenkel]

--- On Mon, 5/11/09, Bob Sneidar <bobs at twft.com> wrote:
> From: Bob Sneidar <bobs at twft.com>
> Subject: Re: Math issue, isn't it?
> To: "How to use Revolution" <use-revolution at lists.runrev.com>
> Date: Monday, May 11, 2009, 10:21 AM
> I was thinking of a new property called MathPrecision or
> something. Set the mathprecision to -2 would round to 2
> decimal places for the result of any math equasion. Set the
> mathprecision to 2 would round to the nearest 100. The
> default could be -9 in which case the prior error in
> floating point math that started this thread would not have
> occurred.
> 
> Bob Sneidar
> IT Manager
> Logos Management
> Calvary Chapel CM
> 
HyperCard used 'byte arithmetic' for its calculations - where numbers are stored as strings and each digit occupies a byte. While you still couldn't accurately represent a number with an infinite number of decimals (like 1/3 = 0.3333333...) it allowed for high precision mathematics.

But this came at the cost of performance: CPU architectures come with multiple integer and floating point arithmetic units, where numebrs are represented in a 'condensed' binary form of 4 to 16 bytes. Some numbers simply can't be represented accurately in binary form and will soon result in small differences.

In Java, you have to choose between integer/double or BigInteger/BigDecimal numbers for your arithmetics. The former are just as fast as their native counterparts, but the latter are an order of magnitude slower but provide excellent precision - so that's why they're uaually employed for business apps inspite of the added complexity.

Scott Raney - the original developer of Metacard, the underlying engine for Revolution - opted for the better speed of CPU-native numbers, instead of the byte arithmetic algorithm as implemented in HyperCard. For most purposes, floating-point calculations using doubles provides more than sufficient precision; but there will always be corner cases.

I'm intrigued by the idea of a 'mathPrecision' local property, but I'm afraid it would be a serious undertaking to modify the engine - especially multiplying numbers that have a high number of digits could suffer from additional compounded rounding errors.

And to finish off: there are so many ways to handle rounding itself that it isn't even funny, unless you're an engineer; here's a link to a webpage with more information about rounding than you might ever want to know: <http://www.diycalculator.com/popup-m-round.shtml>

Jan Schenkel.
=====
Quartam Reports & PDF Library for Revolution
<http://www.quartam.com>

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)