
this logic is baffling me (long post sorry)
I will first explain what I am trying to do:<BR><BR>I have someone enter a bill amount, then I allocate it across several offices based on percentages. After the calculations are done, I sometimes get currency amounts that, when added together will add up less then the input amount or greater (depending on how the computer rounds up/down) What I do is add the currencies up individually after the calculations are made and compare to the original input amount.  then to check if they are the same, I subtract the calculated amounts from the input amount  the difference sometimes is a penny or so one way or another. <BR><BR>Now I want to add/subtract that number from on of the calculated amounts. But when I use this logic  I get tangled in negative or positive currency:<BR><BR> calcedifference = formatcurrency(cdbl(calcedamount)cdbl(amount))<BR><BR>if formatcurrency(cdbl(calcedamount)) > formatcurrency(cdbl(amount)) then<BR> 'response.write "Hey, the additions are higher then amount by " & cdbl(calcedifference)<BR> <BR>amountperm = formatcurrency(amountperm  cdbl(calcedifference))<BR><BR><BR>elseif formatcurrency(cdbl(calcedamount)) < formatcurrency(cdbl(amount)) then<BR> ' 'response.write "the calced amounts are lower then the original amountby "& cdbl(calcedifference)<BR> amountperm = formatcurrency(amountperm + cdbl(calcedifference))<BR><BR><BR><BR><BR>I am getting so confused about should I be subtracting the difference or adding the difference (the difference can be negative or positive currency)<BR><BR>This only seems to be working for positive numbers<BR><BR>Would I be better to make the difference an absolute number?<BR><BR>When adding and subtracting currency  is it exactly like adding and subtracting integers?<BR><BR>Thanks for any input and apologies for having to read this

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 'should' always match the total.

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>

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 languagesincluding C/C++/Java/VB/C#/Pascal/JSnumbers 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'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 types128 bit floating pointwhich 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

Forum Rules

