--- On Mon, 5/11/09, Bob Sneidar <[email protected]> wrote: > From: Bob Sneidar <[email protected]> > Subject: Re: Math issue, isn't it? > To: "How to use Revolution" <[email protected]> > 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) _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
