VBer new to VB.net - handles divide by zero?
-
Christian Graus wrote: Wrong. I converted into code which didn't use strings at all, and the Single variable gets the VALUE of positive Infinity. That's where the string value comes from, the Single, which does not blow up. Sorry. I suffered a momentary rectal/cranial inversion. ;P It would be interesting to see what IL is generated for the same code. I'll try and take a look at that when I get to work. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Dave Kreskowiak wrote: I suffered a momentary rectal/cranial inversion *grin* I'd certainly forgive you for assuming this would not be the case, it's pretty screwed up. Dave Kreskowiak wrote: It would be interesting to see what IL is generated for the same code. I'll try and take a look at that when I get to work. I'd be really interested to hear your thoughts. Overall, I thought that VB.NET and C# did roughly the same thing, and this sort of difference is frankly astounding to me. Christian Graus - Microsoft MVP - C++
-
Isn't CInt one of the legacy methods that was going to be removed ? I wasn't sure on this. Dave Kreskowiak wrote: His code is converting the DivideByZero exception to a string before it blows up. This results in the string "Infinity" being returned. Wrong. I converted into code which didn't use strings at all, and the Single variable gets the VALUE of positive Infinity. That's where the string value comes from, the Single, which does not blow up. Then I changed the code to set to an int, and it DOES blow up then, but it doesn't throw a DivideByZero exception, it throws an OverflowException. C# will blow up on a divide by zero, no matter what type it's being set to, and it throws the right exception. Do you have an explanation for this that doesn't involve the VB.NET design team spending most of their time drunk ? Because we spent a Friday laughing about it here ( where we never use VB.NET ). Christian Graus - Microsoft MVP - C++
Christian, If you realy would like to know why.. it throws an OverflowException as you said.. Take a look here: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q315965&ID=kb;en-us;Q315965&SD=MSDN[^] And Here: http://visualbasic.about.com/od/usingvbnet/l/bldyknaninfa.htm[^] I think it should clear it up for you. progload
-
Christian, If you realy would like to know why.. it throws an OverflowException as you said.. Take a look here: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q315965&ID=kb;en-us;Q315965&SD=MSDN[^] And Here: http://visualbasic.about.com/od/usingvbnet/l/bldyknaninfa.htm[^] I think it should clear it up for you. progload
Thanks for the links. Mathematically, you CAN divide by zero, but what you get is "infinity". Actually, this is not true. Google some maths sites if you don't believe me. Either way, as the article states, this leaves the way open for some serious problems in business apps that don't work hard to avoid this happening. I don't understand the integer divide ( \ ) thing. Does that stop VB from implicitly converting ints to floats ? I guess C#, being more strongly typed, wouldn't need that, and that would go *some* way to explaining why C# and VB.NET behave so differently from one another in this instance. Thanks for the info. Christian Graus - Microsoft MVP - C++
-
Did I stumble into the wrong forum? No wait, it still says Visual "Basic / VB.NET" across the top. Are there any VB programmers in here? That's sort of what I was, you know, expecting. :mad: So anyways. Progload, if division by zero *is* an exception thrown, why did it not get caught? ________________________________________________________________________ Dave Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
Sorry Dave, you seem to have stumbled upon an amazingly illogical and inconsistent piece of VB.NET behaviour, hence the discussion. I thought I did in fact explain how to get the exception to throw though, didn't I ? Christian Graus - Microsoft MVP - C++
-
Thanks for the links. Mathematically, you CAN divide by zero, but what you get is "infinity". Actually, this is not true. Google some maths sites if you don't believe me. Either way, as the article states, this leaves the way open for some serious problems in business apps that don't work hard to avoid this happening. I don't understand the integer divide ( \ ) thing. Does that stop VB from implicitly converting ints to floats ? I guess C#, being more strongly typed, wouldn't need that, and that would go *some* way to explaining why C# and VB.NET behave so differently from one another in this instance. Thanks for the info. Christian Graus - Microsoft MVP - C++
Christian, Integer Division under VB.Net Operators: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbls7/html/vblrfvbspec11_5_4.asp[^] and a simple comparison: http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html[^] Hope this helps. progload
-
Dave Kreskowiak wrote: I suffered a momentary rectal/cranial inversion *grin* I'd certainly forgive you for assuming this would not be the case, it's pretty screwed up. Dave Kreskowiak wrote: It would be interesting to see what IL is generated for the same code. I'll try and take a look at that when I get to work. I'd be really interested to hear your thoughts. Overall, I thought that VB.NET and C# did roughly the same thing, and this sort of difference is frankly astounding to me. Christian Graus - Microsoft MVP - C++
After doing a little code and IL research and going back to the VB.NET docs on mathematical operators, all has become crystal clear. There are TWO division operators in VB.NET. Click here[^] for the docs, or just read on... The normal one, that we're all used to using in any language, is "/". Well, in VB.NET, this operator is only used to divide two floating point numbers. The operator is defined for both the Single and Double types and also the Decimal type. The Single and Double types are evaluated using standard IEEE 754 rules. Nothing new here, it's what we've been using for decades in C/C++ on floating point values and where our "interpretation" problem comes in while evaluating the original posters
n1/n2expression. The Decimal type is a little different. If the right-hand operand is 0, the aSystem.DivideByZeroExceptionis thrown. If the resulting value is too large to hold in the Decimal type aSystem.Overflowexception is thrown. If the resulting value is too small, then the Decimal type result will be 0. The second division operator in VB.NET is "\" and is reserved for integer division using the VB.NET Byte, Short, Integer, and Long types. This is the division that the equivilent C# code is doing when comparing VISUALLY identical VB.NET and C# code using integer operands! Now, according to MSDN: "According to normal operator resolution rules, regular division purely between operands of types such as Byte, Short, Integer, and Long would cause both operands to be converted to type Decimal. However, when doing operator resolution on the division operator when neither type is Decimal, Double is considered narrower than Decimal. This convention is followed because Double division is more efficient than Decimal division." Keeping that statement in mind, here's the proof of what's going on with the OP's code: This is the test function code for VB.NET:Dim n1, n2 As Integer
n1 = Convert.ToInt32("32")
n2 = Convert.ToInt32("0")
Console.WriteLine(n1 / n2)The output is the string "Infinity". Something C# and C/C++ coders wouldn't expect to see. The test function in C# is:
int n1;
int n2;
n1 = Convert.ToInt32(@"32");
n2 = Convert.ToInt32(@"0");
Con -
Christian, Integer Division under VB.Net Operators: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbls7/html/vblrfvbspec11_5_4.asp[^] and a simple comparison: http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html[^] Hope this helps. progload
Thanks :-) Christian Graus - Microsoft MVP - C++
-
After doing a little code and IL research and going back to the VB.NET docs on mathematical operators, all has become crystal clear. There are TWO division operators in VB.NET. Click here[^] for the docs, or just read on... The normal one, that we're all used to using in any language, is "/". Well, in VB.NET, this operator is only used to divide two floating point numbers. The operator is defined for both the Single and Double types and also the Decimal type. The Single and Double types are evaluated using standard IEEE 754 rules. Nothing new here, it's what we've been using for decades in C/C++ on floating point values and where our "interpretation" problem comes in while evaluating the original posters
n1/n2expression. The Decimal type is a little different. If the right-hand operand is 0, the aSystem.DivideByZeroExceptionis thrown. If the resulting value is too large to hold in the Decimal type aSystem.Overflowexception is thrown. If the resulting value is too small, then the Decimal type result will be 0. The second division operator in VB.NET is "\" and is reserved for integer division using the VB.NET Byte, Short, Integer, and Long types. This is the division that the equivilent C# code is doing when comparing VISUALLY identical VB.NET and C# code using integer operands! Now, according to MSDN: "According to normal operator resolution rules, regular division purely between operands of types such as Byte, Short, Integer, and Long would cause both operands to be converted to type Decimal. However, when doing operator resolution on the division operator when neither type is Decimal, Double is considered narrower than Decimal. This convention is followed because Double division is more efficient than Decimal division." Keeping that statement in mind, here's the proof of what's going on with the OP's code: This is the test function code for VB.NET:Dim n1, n2 As Integer
n1 = Convert.ToInt32("32")
n2 = Convert.ToInt32("0")
Console.WriteLine(n1 / n2)The output is the string "Infinity". Something C# and C/C++ coders wouldn't expect to see. The test function in C# is:
int n1;
int n2;
n1 = Convert.ToInt32(@"32");
n2 = Convert.ToInt32(@"0");
ConThanks - I had pieced part of this together with some help already ( the two operators thing ), but this makes everything quite clear. The core issue then is the convert to a float64. I wonder if these conversions behind the scenes are a reason for the argument that VB.NET is slower than C# ? Does this mean that C# can't divide using IEEE 754 rules ? Or is it just that VB.NET, being loosely typed, does conversions behind the scenes that C# does not. Certainly I could see where the overflow exception came from, that all makes sense now. Christian Graus - Microsoft MVP - C++
-
Thanks - I had pieced part of this together with some help already ( the two operators thing ), but this makes everything quite clear. The core issue then is the convert to a float64. I wonder if these conversions behind the scenes are a reason for the argument that VB.NET is slower than C# ? Does this mean that C# can't divide using IEEE 754 rules ? Or is it just that VB.NET, being loosely typed, does conversions behind the scenes that C# does not. Certainly I could see where the overflow exception came from, that all makes sense now. Christian Graus - Microsoft MVP - C++
Christian Graus wrote: The core issue then is the convert to a float64. I wonder if these conversions behind the scenes are a reason for the argument that VB.NET is slower than C# ? It'll definitely contribute to the speed difference because of the conversion process and the 64-bit floating division. But I think the problem lies in the fact that the people who want to bash VB.NET so bad just write some ad-hoc test code for both languages, like in my post, don't realize that they're not comparing apples to apples. When the difference comes up, wow!, they just jump all over the language. Christian Graus wrote: Does this mean that C# can't divide using IEEE 754 rules ? Or is it just that VB.NET, being loosely typed, does conversions behind the scenes that C# does not. No. C#, being based on the same Framework, using the same types and generating the same IL, uses the exact same math rules VB.NET does. C# just has a syntax advantage in the compiler where is will recognize the division situation, since it only has a single division operator, and generate the correct code automatically, (for example when dividing an int32 by an int32, assume the result required is an int32 and generate code for integer division), where VB.NET puts more of that decision process on the coder. The coder is responsible for explicitly telling VB.NET which type of division to use, integer (\) or floating-point (/). I guess you could make a case for that being a simpler advantage for VB.NET, I don't know. In C#, if you wanted to force floating-point division on two int32's, you'd have to cast the operands to some floating-point type in the expression. IMHO, I'd say it might be slightly simpler to control in VB.NET, but more readable and comprehendable in C#. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Christian Graus wrote: The core issue then is the convert to a float64. I wonder if these conversions behind the scenes are a reason for the argument that VB.NET is slower than C# ? It'll definitely contribute to the speed difference because of the conversion process and the 64-bit floating division. But I think the problem lies in the fact that the people who want to bash VB.NET so bad just write some ad-hoc test code for both languages, like in my post, don't realize that they're not comparing apples to apples. When the difference comes up, wow!, they just jump all over the language. Christian Graus wrote: Does this mean that C# can't divide using IEEE 754 rules ? Or is it just that VB.NET, being loosely typed, does conversions behind the scenes that C# does not. No. C#, being based on the same Framework, using the same types and generating the same IL, uses the exact same math rules VB.NET does. C# just has a syntax advantage in the compiler where is will recognize the division situation, since it only has a single division operator, and generate the correct code automatically, (for example when dividing an int32 by an int32, assume the result required is an int32 and generate code for integer division), where VB.NET puts more of that decision process on the coder. The coder is responsible for explicitly telling VB.NET which type of division to use, integer (\) or floating-point (/). I guess you could make a case for that being a simpler advantage for VB.NET, I don't know. In C#, if you wanted to force floating-point division on two int32's, you'd have to cast the operands to some floating-point type in the expression. IMHO, I'd say it might be slightly simpler to control in VB.NET, but more readable and comprehendable in C#. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Dave Kreskowiak wrote: IMHO, I'd say it might be slightly simpler to control in VB.NET, but more readable and comprehendable in C#. Fair enough - thanks for taking the time to look into this, I've found it quite fascinating. Christian Graus - Microsoft MVP - C++