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. That’s 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 flex’s use of the data type – it is just inherent to all OS’s. On 17/8/06 23:20, "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
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. That’s 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 flex’s use of the data type – it is just inherent to all OS’s. 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
> 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 flex’s use of the data type – it is just inherent to all OS’s. On 17/8/06 23:20, "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: [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 flex’s use of the data type – it is just inherent to all OS’s. 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
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
> 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: [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 straight with 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 produced from 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 issues are 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 would replace 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. __,_._,___
[flexcoders] Re: decimal numbers in financial applications
> 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 when converting 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 a price on the client side, trying to save the data. Imagine a user doing a price change on thousands of items, hitting save, and watching hours of work disappear... You're right - letting the DB driver do the rounding would work if we had a separate DTO for each domain object where we could put the floating point number temporarily. Since we're using EJB 3.0, which is an excellent abstract persistence layer, we are able to allow the POJO 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 BigDecimal in Actionscript which can pass through the protocol layer unscathed and give exact results on the client. This not only provides a fix for the persistence problem, but also allows the client to compute things without help from the server, and display them confidently to the 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 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 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.9199289457264239899814128875732421875 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 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
- Original Message - From: "ryanm" <[EMAIL PROTECTED]> To: 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
> 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. ;-) 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
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 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 decim
[flexcoders] Re: decimal numbers in financial applications
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 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
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.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 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 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 Actio
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: [SPAM] [flexcoders] Re: decimal numbers in financial applications
> For example, if I set the column to the right value in the database > manually and then refresh the client view of the data, the value makes > it down to the client unchanged, displays on the screen in Flash with > the correct decimal value, and can be used in computations, which > appear to be correct (so far). > No, you wouldn't want to use it in computations on the client because there are rounding problems with floating point math in AS (same as js). If you simply read it from the server side and display it in the client, it's just a string so it's always correct. Once you want to do math on it, neither AS or JS are safe for important calculations, which pretty much means that short of an applett or activex control, there is no such thing as a "safe" web client for financial calculations. 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
> 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/
[flexcoders] Re: decimal numbers in financial applications
Hi Gordon, I appreciate your reply. Here's some more information for you, which might help. It looks to me like it's a one-way problem (client--->server). Unless the user is doing data-entry on the Flash client, and then saves the data, this problem would appear not to effect them. This might explain why there's no outcry. For example, if I set the column to the right value in the database manually and then refresh the client view of the data, the value makes it down to the client unchanged, displays on the screen in Flash with the correct decimal value, and can be used in computations, which appear to be correct (so far). I hit the problem when I am creating or updating a record. Once Flash sends a new value to the server, and the Java adapter creates a new BigDecimal from the Number, the decimal portion gets changed ever so slightly. Then, the code must always round down just before assignment. If standard rounding were in place within the Java adapter, I would still not realize this problem exists. The wrong values are only off by one thousandths when dealing in hundredths. I am going to go forward with the porting or creation of the fixed decimal class, and will try to end up with BigDecimals on the other side. I'll let you know how it goes. -- 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. __,_._,___
[flexcoders] Re: decimal numbers in financial applications
Creating a new class is the good option. It would be time comsuming, but would bring about the desired outcome, assuming everything could be worked out. If you read Gordon's post again, you will understand what I was not too excited about. I was not objecting to creating a new class, nor was this suggested, except by me. Gordon mentioned one option was to do all of the math strictly on the server, and pass strings back and forth. I'm sure you can see why this would be a last resort. -- 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
> 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/
[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 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/
