Well it looks for all the world then, that in order to write any kind
of accounting application in Revolution, one would have to write their
own functions like newADD(), newSUBTRACT() and the like, which
internally would use the value() function on every argument, as well
as the result of every argument. In addition it could be based upon a
custom property of (let's say) 9, but could be temporarily overridden
by another passed arguement. Not undoable, and in fact kind of
challenging. Hmmm... Math Library anyone?
I must say however that real accounting or math based applications
obviously have some way to deal with this.
Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM
On May 11, 2009, at 12:40 PM, Jan Schenkel wrote:
--- 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
_______________________________________________
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
