Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications
Title: Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications Read the WIKI on floating multiplication particularly towards the bottom. Thats the reason why you get an error during arithmetic operations. As I said, usually FP is 2^64-1 (double precision) - single is 2^32-1 and used most of the time unless specified hence long (datatype) single (datatype) under c/c#/c++. Since flash (I believe) was coded ontop of c++, it depends on the mapping between datatypes as to which one prevails most of the time. Long / double precision numbers take a hell of a lot of cpu processing (hence the release of celeron processors of intel using a less intensive FPU) I could understand why its not the default type. Matt the datatype NUMBER how is this translated into a datatype such as long etc? Regards Samuel On 18/8/06 03:54, Gordon Smith [EMAIL PROTECTED] wrote: Normally this is guaranteed to 2^64 1 The Number data type is based on the IEEE-754 double-precision standard. It uses 64 bits to store a floating point number. However, only 52 bits are used for the binary significand; 11 are for the binary exponent, and 1 is for the sign. So it cannot store integers up to 2^64 -1 exactly; only up to 2^52 - 1. It can of course also store some integers (and non-integers) much larger than 2^64 - 1, such as 1e100. - Gordon From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Samuel D. Colak Sent: Thursday, August 17, 2006 3:58 PM To: flexcoders@yahoogroups.com Subject: Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications Guys, FP precision is based upon the machine capabilities. Normally this is guaranteed to 2^64 1 as FP is usually encoded using 2*32 bit registers on mac and on PC 32 bit. Big or Small Edian aside, the IEEE ratification is standard amongst all OS platforms however some have extended the format to cater for there own nuances. Try http://www.psc.edu/general/software/packages/ieee/ieee.html Now when you perform arithmetic on 2 DP numbers, there are some failures which occur. Check out http://en.wikipedia.org/wiki/Floating_point for why. Regards Samuel PS. So it isnt a fault with flexs use of the data type it is just inherent to all OSs. On 17/8/06 23:20, Anatole Tartakovsky [EMAIL PROTECTED] wrote: Ryan, With double, precision should not be an issue - usually money datatype is limited to 18 digits and in most practical applications is limited to 11-12 digits. If you work with doubles (16+ correct digits) t would take quite a few operations to get precision under 12 digits. In terms of individual operations, in order to get 1 cent rounding error for the original case 1.9199289457264239899814128875732421875 * amount, the amount has to be over 50. You decide if it is practical or not Regards, Anatole On 8/17/06, ryanm [EMAIL PROTECTED] wrote: Apparently you acknowledge that it would work but need to keep BigDecimal for other reasons. I get the impresson that they want some calculations to be done real time on the client, and for that a BigDecimal object would be needed in the client as well as on the server. ryanm __._,_.___ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com YAHOO! GROUPS LINKS Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
RE: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications
You seem to be confused about integer data types versus floating-point data types. ActionScript supports three numeric data types: int: a signed 32-bit integer uint:: an unsigned 32-bit integer Number: a 64-bit floating-point number, the same as a double in Java ActionScript does not have a 64-bit integer type, or a 32-bit floating-point type (a float in Java). A Number/double takes up 64 bits, but the value 2^64 - 1 has no relevance to the Number type. A Number cannot even store this value exactly. 2^64 - 1 is the largest value that can be stored in an unsigned 64-bit integer data type. But that isn't what a Number is, and ActionScript doesn't have a 64-bit integer data type. Similarly, 2^32 - 1 is the largest value that can be stored in an 32-bit integer data type (uint). But it can't even be stored exactly by a float. - Gordon From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Samuel D. Colak Sent: Friday, August 18, 2006 12:27 AM To: flexcoders@yahoogroups.com Subject: Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications Read the WIKI on floating multiplication particularly towards the bottom. Thats the reason why you get an error during arithmetic operations. As I said, usually FP is 2^64-1 (double precision) - single is 2^32-1 and used most of the time unless specified hence long (datatype) single (datatype) under c/c#/c++. Since flash (I believe) was coded ontop of c++, it depends on the mapping between datatypes as to which one prevails most of the time. Long / double precision numbers take a hell of a lot of cpu processing (hence the release of celeron processors of intel using a less intensive FPU) I could understand why its not the default type. Matt the datatype NUMBER how is this translated into a datatype such as long etc? Regards Samuel On 18/8/06 03:54, Gordon Smith [EMAIL PROTECTED]com wrote: Normally this is guaranteed to 2^64 1 The Number data type is based on the IEEE-754 double-precision standard. It uses 64 bits to store a floating point number. However, only 52 bits are used for the binary significand; 11 are for the binary exponent, and 1 is for the sign. So it cannot store integers up to 2^64 -1 exactly; only up to 2^52 - 1. It can of course also store some integers (and non-integers) much larger than 2^64 - 1, such as 1e100. - Gordon From: [EMAIL PROTECTED]ups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Samuel D. Colak Sent: Thursday, August 17, 2006 3:58 PM To: [EMAIL PROTECTED]ups.com Subject: Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications Guys, FP precision is based upon the machine capabilities. Normally this is guaranteed to 2^64 1 as FP is usually encoded using 2*32 bit registers on mac and on PC 32 bit. Big or Small Edian aside, the IEEE ratification is standard amongst all OS platforms however some have extended the format to cater for there own nuances. Try http://www.psc.edu/general/software/packages/ieee/ieee.html Now when you perform arithmetic on 2 DP numbers, there are some failures which occur. Check out http://en.wikipedia.org/wiki/Floating_point for why. Regards Samuel PS. So it isnt a fault with flexs use of the data type it is just inherent to all OSs. On 17/8/06 23:20, Anatole Tartakovsky anatole.tartakovsky@gmail.com wrote: Ryan, With double, precision should not be an issue - usually money datatype is limited to 18 digits and in most practical applications is limited to 11-12 digits. If you work with doubles (16+ correct digits) t would take quite a few operations to get precision under 12 digits. In terms of individual operations, in order to get 1 cent rounding error for the original case 1.9199289457264239899814128875732421875 * amount, the amount has to be over 50. You decide if it is practical or not Regards, Anatole On 8/17/06, ryanm [EMAIL PROTECTED]net wrote: Apparently you acknowledge that it would work but need to keep BigDecimal for other reasons. I get the impresson that they want some calculations to be done real time on the client, and for that a BigDecimal object would be needed in the client as well as on the server. ryanm __._,_.___ -- 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
Re: [flexcoders] Re: decimal numbers in financial applications
Matt, Sorryif Isound 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 theserver side. There are cases when it is a wrong thing to do - I encountered it once in20 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 butyou do whathave 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. IfI correlate the number of people affected, the scope of workaround and deployment impact, smaller, simplier, financially orientedcomponent of 50 lines or lessstarts 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 yourviewpoint. However Gordon has been kind enough to quickly make somevery 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 thattrivializing the matter will impede this process. If there's any hope in building a grass roots ground swell ofsupport 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 expectand require the results and accuracy of decimal math while working with floating point values, to learn and understand what thedifference is, the implications, and limitations of being forced touse 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 inthe Java API which deal directly with fixed decimal support. Make no bones about it, there's a lot more going on than just carefully placedrounding statements.Jeff, the client side as it stands now is incapable of accuratelyperforming any mathematical function with accuracy on arbitrary precision decimal numbers, especially when executed repeatedly. Theadding machine on your desk and the same formula within Flash clientwill 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 withoutadding 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 theserver, the value will appear to change randomly before being storedin the database. It is because some fractions can only be representedin binary as an aproximation (not exact). This is how we encountered the problem. It was a simple CRUDapplication written to FDS. The object had two fields - Descriptionand Rate. Rate was a Number object in Actionscript, a BigDecimal 7long with 4 decimal positions on the server. 1.92 was keyed into Ratein Flash, and FDS wrote 1.91 to the database. It's that simple.Anatole, out DAO layer is not able to compensate for this becausewe're using FDS. FDS passes in a BigDecimal already initialized with the wrong number. The problem, as you rightly point out, is arounding issue. The problem is precisely that FDS must always berounding down (because our value of 1.92, converted to double as1.91999... ends up 1.91 in the database.FDS deserialization is not considering the scale and precision of thedestination field during the conversion. If it did, we'd be highlyaccurate, but not perfectly accurate. After enough iterations, we'd still loose a penny eventually, and the CPA or CFO would storm into myoffice 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 IBMmidrange business computers developed in the late 70's on the serverside, with languages where there is no such thing as a float (ONLYfixed decimals). This is the kind of
Re: [flexcoders] Re: decimal numbers in financial applications
- 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 -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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 Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: decimal numbers in financial applications
Paul, I actually got a few messages on my private email with the same sentiment. Please note thatthe typical problem on 10 years old systems was thefloat 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.9199289457264239899814128875732421875 from the original post) it is $500 billion. Now, If you haveso muchin a single transaction and itis 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.comSent: 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 andthe 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 -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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 Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
Re: [flexcoders] Re: decimal numbers in financial applications
Matt, I am sorry, I must be missing something simple. I was suggesting not to use BigDecimal on the server and deal straightwith double on both sides. Apparently you acknowledge that it would work but need to keep BigDecimal for other reasons. I am wondering about other data types that are produced by VRUD framework you are using. Are the dates producedfrom sql or utils package - would be the next question. That is one of the reasons for us to create Flex specific CRUD framework ( http://www.adobe.com/devnet/flex/articles/daoflex.html) so the marshalling issuesare eliminated If that is the case, your options are really limited. You obviously requested Adobe to look into the issue and , if you logged the error, you usually get confirmation within few days that it has or has not been recreated and some indication on the release timeframe. If for whatever reason you need to fix protocol and need to deal with that now, here is anothe roption. For custom datatypes, I would build trivial gateway for FDS. Here is a post for unsecured remoting (simple AMF, not FDS)gateway I use to batch/transact unregistered requests ( http://www.faratasystems.com/?p=7) . You could relatively simply (50-100 lines of Java code the last time we had to do similar patch) set up either filter or similar gateway and do rounding there. Given a choice, I wouldreplace BigDecimal with double in CRUD level and let DB do the truncation. Sincerely, Anatole On 8/17/06, busitech [EMAIL PROTECTED] wrote: In case of Actionscript double(1.9199289457264239899814128875732421875 from the original post) it is $500 billion. Hi Anatole,Did you note that FDS _truncates_ the actionscript double whenconverting to BigDecimal? The extra information is lost in FDS.So in this case, when the tax rate keyed in at the client is off by .01%, this works out to be a 10 cent mistake on a $1,000 transaction. This problem would present itself any time the user is keying in aprice on the client side, trying to save the data. Imagine a user doing a price change on thousands of items, hitting save, and watchinghours of work disappear...You're right - letting the DB driver do the rounding would work if wehad a separate DTO for each domain object where we could put the floating point number temporarily. Since we're using EJB 3.0, whichis an excellent abstract persistence layer, we are able to allow thePOJO entity to become the DTO, and thus our serialization framework(Flex) must either be fixed (by Adobe) to round correctly, or extended (a new serializable type class).So for us the immediate answer is to create a serializable BigDecimalin Actionscript which can pass through the protocol layer unscathedand give exact results on the client. This not only provides a fix for the persistence problem, but also allows the client to computethings without help from the server, and display them confidently tothe user, knowing that when the server performs the same calculation,it will match exactly. Best regards,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 Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications
Apparently you acknowledge that it would work but need to keep BigDecimal for other reasons. I get the impresson that they want some calculations to be done real time on the client, and for that a BigDecimal object would be needed in the client as well as on the server. ryanm -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications
Ryan, With double, precision should not be an issue - usually money datatype is limited to 18 digits and in most practical applications is limited to 11-12 digits. If you work with doubles (16+ correct digits)t would takequite afew operations to get precision under 12 digits. In terms of individual operations, in order to get 1 cent rounding error for the original case 1.9199289457264239899814128875732421875 * amount, the amount has to be over 50. You decide if it is practical or not Regards, Anatole On 8/17/06, ryanm [EMAIL PROTECTED] wrote: Apparently you acknowledge that it would work but need to keep BigDecimal for other reasons. I get the impresson that they want some calculations to be done real time on the client, and for that a BigDecimal object would be needed in the client as well as on the server.ryanm __._,_.___ -- 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 Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications
Title: Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications Guys, FP precision is based upon the machine capabilities. Normally this is guaranteed to 2^64 1 as FP is usually encoded using 2*32 bit registers on mac and on PC 32 bit. Big or Small Edian aside, the IEEE ratification is standard amongst all OS platforms however some have extended the format to cater for there own nuances. Try http://www.psc.edu/general/software/packages/ieee/ieee.html Now when you perform arithmetic on 2 DP numbers, there are some failures which occur. Check out http://en.wikipedia.org/wiki/Floating_point for why. Regards Samuel PS. So it isnt a fault with flexs use of the data type it is just inherent to all OSs. On 17/8/06 23:20, Anatole Tartakovsky [EMAIL PROTECTED] wrote: Ryan, With double, precision should not be an issue - usually money datatype is limited to 18 digits and in most practical applications is limited to 11-12 digits. If you work with doubles (16+ correct digits) t would take quite a few operations to get precision under 12 digits. In terms of individual operations, in order to get 1 cent rounding error for the original case 1.9199289457264239899814128875732421875 * amount, the amount has to be over 50. You decide if it is practical or not Regards, Anatole On 8/17/06, ryanm [EMAIL PROTECTED] wrote: Apparently you acknowledge that it would work but need to keep BigDecimal for other reasons. I get the impresson that they want some calculations to be done real time on the client, and for that a BigDecimal object would be needed in the client as well as on the server. ryanm __._,_.___ -- 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 Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
RE: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications
Normally this is guaranteed to 2^64 1 The Number data type is based on the IEEE-754 double-precision standard. It uses 64 bits to store a floating point number. However, only 52 bits are used for the binary significand; 11 are for the binary exponent, and 1 is for the sign. So it cannot store integers up to 2^64 -1 exactly; only up to 2^52 - 1. It can of course also store some integers (and non-integers) much larger than 2^64 - 1, such as 1e100. - Gordon From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Samuel D. Colak Sent: Thursday, August 17, 2006 3:58 PM To: flexcoders@yahoogroups.com Subject: Re: [SPAM] Re: [flexcoders] Re: decimal numbers in financial applications Guys, FP precision is based upon the machine capabilities. Normally this is guaranteed to 2^64 1 as FP is usually encoded using 2*32 bit registers on mac and on PC 32 bit. Big or Small Edian aside, the IEEE ratification is standard amongst all OS platforms however some have extended the format to cater for there own nuances. Try http://www.psc.edu/general/software/packages/ieee/ieee.html Now when you perform arithmetic on 2 DP numbers, there are some failures which occur. Check out http://en.wikipedia.org/wiki/Floating_point for why. Regards Samuel PS. So it isnt a fault with flexs use of the data type it is just inherent to all OSs. On 17/8/06 23:20, Anatole Tartakovsky anatole.tartakovsky@gmail.com wrote: Ryan, With double, precision should not be an issue - usually money datatype is limited to 18 digits and in most practical applications is limited to 11-12 digits. If you work with doubles (16+ correct digits) t would take quite a few operations to get precision under 12 digits. In terms of individual operations, in order to get 1 cent rounding error for the original case 1.9199289457264239899814128875732421875 * amount, the amount has to be over 50. You decide if it is practical or not Regards, Anatole On 8/17/06, ryanm [EMAIL PROTECTED]net wrote: Apparently you acknowledge that it would work but need to keep BigDecimal for other reasons. I get the impresson that they want some calculations to be done real time on the client, and for that a BigDecimal object would be needed in the client as well as on the server. ryanm __._,_.___ -- 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 Web site design development Computer software development Software design and development Macromedia flex Software development best practice YAHOO! GROUPS LINKS Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
Re: [flexcoders] Re: decimal numbers in financial applications
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 don't see why, it comes to the same thing. Implementing a new type would effectively be putting a class between the regular int type and the application, and that class would either be handling the numbers as strings or as seperate integers internally anyway, so how is that any more or less embarrasing? ryanm -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
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: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of busitech Sent: Wednesday, August 16, 2006 11:24 AM To: flexcoders@yahoogroups.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 Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
Re: [SPAM] RE: [flexcoders] Re: decimal numbers in financial applications
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. The last app I worked on that dealt with money did all of the money calculations on the server side and used asynch calls to get pages of precalculated data for display. On the rare occasion that something needed to be calculated on the client, I just split the number at the decimal and dealt with each piece as an integer. ryanm -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [flexcoders] Re: decimal numbers in financial applications
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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gordon SmithSent: Wednesday, August 16, 2006 4:22 PMTo: flexcoders@yahoogroups.comSubject: 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 busitechSent: Wednesday, August 16, 2006 11:24 AMTo: [EMAIL PROTECTED]ups.comSubject: [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 thatsupport for fixed decimal numbers was not absolutely an essential andrequired part of the product and framework before release, whentargeting the enterprise customer.We need an immediate solution beyond dumbing down the client side toonly use strings. So much functionality would be given up in thatscenario 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. Seehttp://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 toserialize/deserialize correctly. Hopefully there's nothing in theJava adapter standing in the way of making this work... Any help oradvice on this would be appreciated.The BigDecimal is mentioned on page 1091 of the Developer's Guide asbeing deserialized to both int/uint and number, with no furtherexplanation. As I've pointed out, BigDecimal is completelyincompatible 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 Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
Re: [flexcoders] Re: decimal numbers in financial applications
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 last17 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 calculationson the server, but rather do intelligent roundingon protocol level.With your sample of x=1.91... 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 clientprecision is almost always different fromthe serverone. 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 youtry to updateSybase's table that have int id as primary key,the statementwhere 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 thatANY data crossing machine boundaries with an exception of string needs to be rounded. You have to make sure yourDAO layercan make use of DB metadata to hide it from thedevelopersthat 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 SmithSent: Wednesday, August 16, 2006 4:22 PMTo: [EMAIL PROTECTED] ups.comSubject: 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 busitechSent: Wednesday, August 16, 2006 11:24 AMTo: [EMAIL PROTECTED]ups.comSubject: [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 thatsupport for fixed decimal numbers was not absolutely an essential and required part of the product and framework before release, whentargeting the enterprise customer.We need an immediate solution beyond dumbing down the client side toonly 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
