Math issue, isn't it?

[Bob Sneidar]

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 <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)
>
>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution