this logic is baffling me (long post sorry)

# Thread: this logic is baffling me (long post sorry)

1. Senior Member
Join Date
Dec 1969
Posts
702

2. Member
Join Date
Dec 1969
Posts
87

## RE: this logic is baffling me (long post sorry)

Eeek. <BR><BR>I wouldnt try and add/subtract currencies. All currencies/rates (as a general rule of thumb, b4 I get howls of derision from other sources, in Banking anyway) are stored up to 6d.p. Calculations are then done to 6d.p. so any rounding error is so nominal, it does not matter.<BR><BR>You could try doing that and then the displayed currency amounts &#039;should&#039; always match the total.

3. Senior Member
Join Date
Dec 1969
Posts
96,118

## NO NO NO!

FormatCurrency produces a *STRING*!!!!<BR><BR>INCLUDING the appropriate currency SYMBOL!<BR><BR>If you add "\$7.52" to "\$9.32" you get... <BR><BR>ready for this?<BR><BR> "\$7.52\$9.32"<BR><BR>Because you are doing *STRING* addition, NOT arithmetic!<BR><BR>*ONLY* use FormatCurrency to *DISPLAY* the currency to the user(s). NEVER use it when doing arithmetic or comparisons!<BR><BR>CDBL is a fine thing to use.<BR><BR>

4. Senior Member
Join Date
Dec 1969
Posts
96,118

## Well, yes and no...

Maybe in COBOL you have that fine a control on how many decimal places there are. And in some databases you can store numbers in that form.<BR><BR>But in *most* computer languages--including C/C++/Java/VB/C#/Pascal/JS--numbers are stored in the native form of the machine. Typically in double precision, meaning roughly 14 or 15 digits *all total*.<BR><BR>So if you have \$1.98, you are only using 1 digit left of the DP and can get 13 digits of accuracy to the right.<BR><BR>With amounts up to \$99,999,999 you&#039;d still have room for 6 digits or more of accuracy after the decimal point.<BR><BR>Are there alternatives? Yes, but they are less commonly used, and only one is available with VBScript:<BR><BR>COM has a data type *called* currency, and it is actually a LONG integer that is "scaled" to always have 4 digits right of the decimal point. (In other words, it actually keeps values that are 1/100ths of pennies, *as integers*, and only does the divide by 10,000 when displaying the results.)<BR><BR>Java and the .NET framework have decimal data types that are *actually* simply strings of a special kind, that the libraries know how to perform basic "string arithmetic" on. They are, of course, hundreds of times slower to use than the native machine numbers. But they *are* of arbitrary accuracy.<BR><BR>Finally, some machines have LONG DOUBLE types--128 bit floating point--which give you roughly 30 digits of accuracy. Same as DOUBLE, just more accuracy.<BR><BR>

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•