[RESOLVED] Calculate percent with Currency Data Type

[Mith]

hi,

i use Int(curData * 100 / curDataTotal) to calculate the current percent progress value but i run into an overflow error if curData*100 is higher than the maximum currency value (922337203685477@).

Does anybody have an idea for a different approach to calculate the percent progress value with large currency variables to avoid the overflow error?

[OptionBase1]

hi,

i use Int(curData * 100 / curDataTotal) to calculate the current percent progress value but i run into an overflow error if curData*100 is higher than the maximum currency value (922337203685477@).

Does anybody have an idea for a different approach to calculate the percent progress value with large currency variables to avoid the overflow error?

 Int((curData / curDataTotal) * 100)

[Elroy]

That forward-slash division is going to return a Double, which doesn't have the significand precision that a Currency has. In other words, down in the "little numbers" you may see zeroes start appearing.

ADDED: In other words...

Debug.Print TypeName(CCur(1)/CCur(2))

... reports "Double".

Without an API call, VB6 doesn't give us a way to do integer division with Currency types.

[Elroy]

You could use Decimal (in a Variant) type to do it. Division with Decimal types is done with pure Decimals.

[Mith]

After some tests i found a "strange" solution to avoid the overflow error:

Int((curData/1) * 100 / (curDataTotal/1))

example: Int((722337203685477@/1) * 100 / (922337203685477@/1)) = 78%

Can someone explain why dividing by 1 avoids the overflow error?


And finally this solution works very nice:

Int(curData / curDataTotal * 100)

[Elroy]

You don't need the curData/1. All you need to do is CDbl(curData) because that's effectively what you're doing. Again, Double doesn't have as much significand as a Currency, so your "little numbers" may go to zero.

[Elroy]

A Double has 52 bits of significand, whereas a Currency has 63 bits of significand.

[Mith]

A Double has 52 bits of significand, whereas a Currency has 63 bits of significand.

ok, its a downgrade from currency to double and this avoids the error. thanks for the info!

i will use your first solution: Int((curData / curDataTotal) * 100)

[georgekar]

Use Decimal for calculation and then use CCur() to get the currency back (or you get Error 6, overflow)

Decimal has priority. Multiplication/division for Currency turn to double, so change to decimal using Cdec(curVariable) and do the maths and then use CCur to get back the Currency. You get the maximum precision. Decimal is better than Currency, but need 16 bytes (as a type of a variant). Currency value need 8 bytes.


I will post the new cint64() as I prepare for my Interpreter (is the best solution).

[Elroy]

It's been bugging me that I didn't do a better job of explaining what I meant by rounding of the "little numbers".

Here's a piece of code:

Option Explicit

Private Sub Form_Load()
    Dim c As Currency
    c = 864286428642864.2864@

    Dim c2 As Currency
    c2 = CDbl(c) / 2
    Debug.Print Format$(c2, "#0.0000")

End Sub

Common sense tells us that the answer should be: 432143214321432.1432

But, when we run this, here's what we get:

432143214321432.1250
                 ^^^
                 ||| wrong 
                 ||
                 || wrong
                 |
                 | wrong

And that happens without throwing any error at all. And the reason it happens is because we did the division in Double (which doesn't have as much significand as a Currency).

The easiest way to get this correct (as stated above) is to convert everything to Decimal (with CDec() function) before doing the division. And doing that will correctly throw overflow errors (if there is one) when the Decimal is re-assigned to the Currency.

JUST FYI: There is no Currency division. There's Currency addition, subtraction, & multiplication ... but no division. However, for Decimal (which completely covers all ranges of Currency) there is a pure Decimal division.