Paul,
  I actually got a few messages on my private email with the same sentiment. Please note that the typical problem on 10 years old systems was the float type on client versus double/bigdecimal on the server. In case of rate 1.92 rate as 4 byte float, in order to get 1 cent rounding you need something like mere $5000 as multiplier for the problem to show up. In case of Actionscript double (1.9199999999999999289457264239899814128875732421875  from the original post) it is $500 billion. Now, If you have so much in a single transaction and it is off by 1 cent (which is bad)  - then you have a problem.
 
Sincerely,
Anatole
 
On 8/17/06, Paul Andrews <[EMAIL PROTECTED] > wrote:


----- Original Message -----
From: "ryanm" < [EMAIL PROTECTED]>
To: < flexcoders@yahoogroups.com>
Sent: Thursday, August 17, 2006 7:54 AM
Subject: Re: [flexcoders] Re: decimal numbers in financial applications

>> At that point you are looking at full table scan to update single
>> record - and it might be much worse problem then loosing one cent on
>> rounding.
>>
> On the other hand, the application I was working on dealt with a
> service
> model that involved tenths or hundredths of a penny per transaction, and
> added up hundreds of thousands of transactions on a typical "page" of
> data,
> so losing a penny to a rounding error would've been a very serious
> problem.
> It really depends on the nature of the app and just how precise you need
> the
> numbers to be.
>
> These situations are where a properly abstracted business logic layer
> comes in handy. When fully seperated from the display layer, all the
> calculations take place in a single language/platform and all precisions
> issues can be dealt with at one time, hopefully in a single place in the
> code. Depending on the nature and purpose of the app that kind of
> precision
> may not be required, but it still makes it a lot easier to fix precision
> issues when they come up if your logic is all handled in one place.
>
> I guess what I'm saying is it depends on the app. ;-)

You are absolutely right. I've seen this problem (years ago) on an
application where the UI was client server and
the reporting was done separtely on the server (different software to the
client). It can be rather problematic
seeing one thing on screen and something different in a printed invoice or
report (no matter how small the difference).

For some reason the customer/users start losing faith in the software..

Paul

> ryanm
> Yahoo! Groups Links
>
>
>
>
>
>
>


__._,_.___

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com





SPONSORED LINKS
Software development tool Software development Software development services
Home design software Software development company


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to