© 2008 Alastair Revell
Terms of Use
About Alastair Revell
About this Blog
Web Log Home | Welcome to this Web Log | Using this Web Log | New to Blogs? | About Revell Research Systems | Contact Details
We've recently started porting our large .NET class libraries from .NET 1.1 to .NET 2.0, which has to date been a fairly smooth process. We've also been revising and enhancing classes as we go and I stumbled across a rather nasty catch during this process.
I was working on a numerical class library that represents trigonometric angles, which is heavily dependent on the Double type (as you might expect).
It took me quite a while to track down the cause of some strange results I was getting from our code. The essence of the problem was similar to the code below:-
Dim result As Double = Double.MaxValue * 3/10
(Obviously, the situation was a little more complex!)
What quantity would you expect result to hold? Would you be surprised to learn that it was PositiveInfinity? I was initially...
A quick scan of the line suggests that result will hold something well below the maximum value allowed by the Double type. However, the VB.NET compiler sticks to the normal rules of operator precedence and finds itself with a value three times greater than the maximum allowable value (after multiplying by 3), which it concludes is PositiveInfinity. It then divides this by 10, which nonetheless still evaluates to PositiveInfinity...
Now consider:-
Dim value As Double Dim result As Double value = Double.MaxValue result = value * 3 / 10
What quantity would you expect result to hold? Would you be surprised to learn that it was NOT PositiveInfinity but the correct mathematical value?
Obviously, the VB.NET compiler evaluates differently if the right-hand side of an expression is a combination of constants and literals rather than based on a variable.