This thread is getting too serious.
 
There are few ways to look at the problem - theoretical (as a former mathematician) or practical (as Wall Street programmer for the last 17 years). It is a big problem - theoretically. Numbers obviously do not match.  It has always been that way - and I can probably dig messages from 15 years old messages CompuServe describing exactly the same precision issues with almost any type (timestamp, numbers, rowid, etc) when the client and the server do not share the same underlying data structure.
 
The practical solution I have seen is not to do calculations on the server, but rather do intelligent rounding on protocol level. With your sample of x=1.919999... rounding to 2 decimal places
you go with x = round( round(x+.5),3),2)
 
Please take a look how the db drivers deal with the same issue when they need to include timestamp or double in WHERE portion of update/delete statement - they always have the same issue as client precision is almost always different from the server one.
 
If you use automatic code generator for your database access ( we use our own daoFlex tool that you are welcome to take a look at), you can use DB precision attribute to automate rounding for the numbers on updates - making your programmers blissfully unaware of the problem.
 
The next step is to understand why Flex is dealing not just with single double type, but gets "int" in the conversion. Typical DB case would be retrieval argument. If you try to update Sybase's table that have int id as primary key, the statement "where id=?" with setDouble(1, param) it will not use index on id (but will find the record as the rounding will kick in later). 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.
 
Bottom line is that you always have to be aware that ANY data crossing machine boundaries with an exception of string needs to be rounded. You have to make sure your DAO layer can make use of DB metadata to hide it from the developers that are guaranteed to make the mistake.
 
Sincerely,
Anatole Tartakovsky
 
 
 
 
 

 
On 8/16/06, Jack W. Caldwell @ Zingit Technologies, Inc. <[EMAIL PROTECTED]> wrote:

Gordon:
 
I must be missing something here.  Are you saying that, for example, if I had
a datagrid with 10 rows and one of the columns has 2 digit decimal numbers
in it and I wanted to get the average of the ten numbers . . . . .
 
that we can NOT do that in AS?  That we have to send a server request and
calculate it in the server and wait for it to come back . . . .
 
I have to be missing something . . . . I hope.
 
Thanks,
 
Jack


From: [EMAIL PROTECTED]ups.com [mailto: flexcoders@yahoogroups.com] On Behalf Of Gordon Smith
Sent: Wednesday, August 16, 2006 4:22 PM
To: [EMAIL PROTECTED] ups.com
Subject: RE: [flexcoders] Re: decimal numbers in financial applications

 

Hi, Matt.

We worked closely with many enterprise customers, including financial ones, during our development phase and beta period, and support for decimal arithmetic was not a priority for them. I've also read many thousands of FlexCoders and Beta list emails during the Flex 1, 1.5, and 2 cycles, and I recall only a handful raising this issue.

Like you, I'm surprised by this. I don't know whether most Flex developers simply haven't needed decimal arithmetic for the applications they are developing, or whether they're working around the lack of it in _javascript_, ECMAScript, ActionScript, and Flex  by using some particular technique such as doing server-side computation, scaling to integers, or porting a library like you're considering.

I believe the committee designing the next version of ECMAScript, which Adobe sits on, is considering adding a decimal type to the language.

In the meantime, I think a community effort to port an open-source library would be great. Adobe would probably be happy to help make it available. However, given the relatively small percentage of our customers asking for this feature, it's unlikely that the Flex team will write or port such a library in the near future.

- Gordon


From: [EMAIL PROTECTED] ups.com [mailto:[EMAIL PROTECTED] ups.com] On Behalf Of busitech
Sent: Wednesday, August 16, 2006 11:24 AM
To: [EMAIL PROTECTED]ups.com
Subject: [flexcoders] Re: decimal numbers in financial applications

Gordon,

Thank you very much for the reply.

I'm very surprised that the decision was made at some point that
support for fixed decimal numbers was not absolutely an essential and
required part of the product and framework before release, when
targeting the enterprise customer.

We need an immediate solution beyond dumbing down the client side to
only use strings. So much functionality would be given up in that
scenario that I'd be ashamed and embarrased of our product in the end.

I'm considering creating a port to Actionscript of "BigDecimal for
_javascript_" which is an open source project. See
http://freshmeat.net/projects/js_bigdecimal/

Custom serialization is outlined on pg 1098 of the Developer's Guide.
I'm hoping I can extend BigDecimal and implement Externalizable,
create a new similar object in Actionscript, and get them to
serialize/deserialize correctly. Hopefully there's nothing in the
Java adapter standing in the way of making this work... Any help or
advice on this would be appreciated.

The BigDecimal is mentioned on page 1091 of the Developer's Guide as
being deserialized to both int/uint and number, with no further
explanation. As I've pointed out, BigDecimal is completely
incompatible with both of these AS types.

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