Calculations differ between VB6 and VB7

I am converting a VB6 project to VB7 (.NET) and I have encountered some inconsistencies in the way the to platforms run calculations. The most significan is this. I have found that values calculate differently between VB6 and VB7.
Use the following line of code in either version and the values returned will differ.

VB Code:

CInt(CDbl(13 / 60) * 30)

VB6 Returns a 7
VB7 Returns a 6
It seems as if we have a pair of dyslexic twins here.
Has anyone else encountered similar differences, if so, how did you resolve them.

John Vonesh

i think its got somet to do with rounding. the answer is 6.5 therefor vb6 is rounding it up to fit as an integer without decimal places, and vb7 is just getting rid of the decimal and putting it as 6.

if u want the real answer, try declaring it as a double instead of an integer maybe, im not sure what CDbl so im not sure if that is altering the answer.

Actually, you are not correct. If you use the Round() function in VB6 or VB7 with the value of 6.5, you will receive a 6 from both products.

VB6 Round(6.5) = 6
VB7 Round(6.5) = 6

I already thought of that....

hI,

VB Code:

CInt(CDbl(13 / 60) * 30-.1)

returns 6 in VB6, so obviously, this combination of functions in VB6 does result in normal rounding.

Therefore it seems that VB6 produces a value expressed as an integer variable whilst VB.NET produces a true integer result.

Presumeably this was a little known bug in VB6 which has now been corrected.

Have you considered that the bug may exist in .NET?
I ran my calculations a step at a time in both environments.
The result of 13 / 60 is 0.21666666666666667 from both products, but!
When you multiply 0.21666666666666667 * 30 in VB6, the result is 6.50000000000001 while VB7 returns just 6.5 . . .
How oddly curious.
The buttom line is that 6.50000000000001 is greater than 6.5 so when you convert it to an integer, or even round it, the result is 7.

I'm contacting Microsoft after this posting to determine if we have a bonafide bug in the Math library of the .NET framework, or if there is some way around the truncation of the decimal places in the value that is returned from multiplying 0.21666666666666667 * 30.
Cheers

John

The final word...
It seems that the Double data type is not sufficient for performing the calculations that I need due to my clients requirements. What is needed is the Decimal data type.
The original code produced undesirable results because the Single and Double data types are subject to rounding errors in the .NET framework: Excerpt from MSDN...

Quote:

---

Floating point (Single and Double) numbers have larger ranges than Decimal numbers but can be subject to rounding errors. Floating point types support fewer significant digits than Decimal but can represent values of greater magnitude.

---

So my original code was returning an errant result because of the rounding issues that surround the double data type.

This code produces the desired result.

VB Code:

CInt(Convert.ToDecimal(13 / 60) * 30)

Problem solved....
I hope my efforts are beneficial to someone else here :D

John

[QUOTE]Originally posted by CyberHawke
The buttom line is that 6.50000000000001 is greater than 6.5 so when you convert it to an integer, or even round it, the result is 7.


In correct arithmetic, 6.5 also rounds up to 7.

It depends on which rule you use.
The bankers rule for rounding states that you round to the nearest even number. This is because in accounting when you are working with large quantities of numbers, and you may have to round several hundred or even several thousand rows, to keep things balanced, you round up if the value preceeding the decimal is odd and you round down if the value preceeding the decimal is even.
mathforum.org/library/drmath/view/58972.html
Both VB6 and VB7 will use this rule when rounding because Visual Basic is generally considered a business programming language. As such more often than not you are working with financial data and need to keep "the bottom line" balanced when doing so.

I hope this clarifies things for you.

John