Re: [flexcoders] Re: decimal numbers in financial applications

Thu, 17 Aug 2006 01:02:23 -0700

Matt,
 
Sorry if  I sound too simplistic - just trying to explain the approach I usually take with the issue.
 
1. 1.91<> 1.92 issue.
The way I see it (correct me if I am wrong ) is that DB has 4.2 format. The way I would solve it is to define rate as double on data transfer object and let DB driver to do the rounding - you have very good chances that it would work.
Let me give you my understanding on similar but not identical subject: java.util.Date vs java.sql.Date - very similar, sql one has higher "precision" - but Flex supports utils one only, so we use only that and do rounding on the server side. There are cases when it is  a wrong thing to do - I encountered it once in 20 years, and I honestly can not remember the case - it was due to assumptions based algorithm.
 
2. Rounding on the client. If you must to round up every transaction up to the penny, you have to do client side rounding. That does not sound like financial application but rather tax reporting, and in the last 10 years they allowed different rounding but you do what have to do. You do not need large library - basically it is always long(x*100)/100 - unless you have very large numbers.  I am just saying that 10,000 lines in 7 classes may be to much for thin client deployment environment with 1MB footprint. If I correlate the number of people affected, the scope of workaround and deployment impact, smaller, simplier, financially oriented component of 50 lines or less starts making more sense to me.
 
Sincerely,
Anatole
 

 
On 8/17/06, busitech <[EMAIL PROTECTED]> wrote:

Hi Anatole,

I understand your sentiments, and I do understand and respect your
viewpoint. However Gordon has been kind enough to quickly make some
very clear statements for me regarding where we are at today, and as a
result, I'm making progress in solving the problem. I'm afraid that
trivializing the matter will impede this process.

If there's any hope in building a grass roots "ground swell" of
support for adding fixed decimal support to Flex, it has to come from
educating the folks about what we've got, and what the options are.
I'm happy others like Jeff want to know more about this.

It is time, for those who are unaware of what happens when you expect
and require the results and accuracy of decimal math while working
with floating point values, to learn and understand what the
difference is, the implications, and limitations of being forced to
use floating point variables.

The problem is far more serious and practical that it is theoretical.
To appreciate the complexity of dealing with fixed decimal numbers,
take a look at the over 10,000 lines of code in 7 different classes in
the Java API which deal directly with fixed decimal support. Make no
bones about it, there's a lot more going on than just carefully placed
rounding statements.

Jeff, the client side as it stands now is incapable of accurately
performing any mathematical function with accuracy on arbitrary
precision decimal numbers, especially when executed repeatedly. The
adding machine on your desk and the same formula within Flash client
will never agree with each other 100%.

A balance sheet must balance to the penny. A journal entry must
balance to the penny. A sales tax rate must be exactly 5.92 percent,
etc. Don't depend on the Flash client to do this successfully without
adding fixed decimal support of some kind to your application.

When doing decimal data entry in the Flash client, if the data is
first stored in a Number object before being transferred to the
server, the value will appear to change randomly before being stored
in the database. It is because some fractions can only be represented
in binary as an aproximation (not exact).

This is how we encountered the problem. It was a simple CRUD
application written to FDS. The object had two fields - Description
and Rate. Rate was a Number object in Actionscript, a BigDecimal 7
long with 4 decimal positions on the server. 1.92 was keyed into Rate
in Flash, and FDS wrote 1.91 to the database. It's that simple.

Anatole, out DAO layer is not able to compensate for this because
we're using FDS. FDS passes in a BigDecimal already initialized with
the wrong number. The problem, as you rightly point out, is a
rounding issue. The problem is precisely that FDS must always be
rounding down (because our value of 1.92, converted to double as
1.91999... ends up 1.91 in the database.

FDS deserialization is not considering the scale and precision of the
destination field during the conversion. If it did, we'd be highly
accurate, but not perfectly accurate. After enough iterations, we'd
still loose a penny eventually, and the CPA or CFO would storm into my
office and say "The system doesn't work right because..."

Prior to Flex, I've been working with C++ on the client side with a
fixed decimal library which is at least 15 years old, and with IBM
midrange business computers developed in the late 70's on the server
side, with languages where there is no such thing as a float (ONLY
fixed decimals).

This is the kind of software/hardware which was developed to handle
business transactions over 30 years ago, and much of the world still
runs on them.

Until Flex and all of the other new technologies have support for
fixed decimals and can add up a balance sheet, we will not be able to
replace these old back end systems which at the end of the day have to
balance the books month in and month out - to the penny.

Let's work to educate Flex users about the benefits of fixed decimal
math, and ask Adobe to make sure it gets in to the next version. It
will help solidify the future of the rich internet application a great
deal.

Best regards to all,

Matt


__._,_.___

--
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