Int() vs CInt()

My recent automation components have required quite a bit of calculations compared to the automation scripts I've built up to this point.  (ie Any at all really)

And I've noticed a difference in behavior between the VBscript functions Int() and CInt().  So far I have been able to use Int() with no issues.  All it does is take a positive number and truncate the decimal.

This is necessary since the calculations the applications I am working with are doing just that, truncating the decimal.  Weird huh?

But CInt() has an upper and lower bound.  It will only allow you to convert to a integer value between -32,768 and 32,768.  This becomes a problem for me because in some applications I need to be be dealing with 6 digit integer values.  I tried CLng() but that rounds the value which the application under test appears not to do.

My Question to the Geekdom is, am I going to run into the same problem with Int()  OR am I ok using it to truncate the numbers.

My VBScript mentor gave me an alternative solution if Int() is going to cause me grief.   I've searched through my VBScript guides and on the net and no one mentions whether Int() has boundaries.

Anyone out there know if Int() has boundary conditions like CInt()? 

<its never as easy as you first think it will be eh?>

posted @ Monday, July 09, 2007 9:06 PM

Print

Comments on this entry:

# re: Int() vs CInt()

Left by David at 7/9/2007 11:32 PM
Gravatar
To answer your question if Int() has boundaries - yes, it does. But where? Well, thats a tricky one to answer.

You can pass to it any number which can contain a decimal. In VB the largest numeric value you can have goes up to 1.79e+308, either at its largest positive or lowest negative.

Try doing the following code:
Dim a AS Variant
a = 1E+309

You'll find that you get an Overflow Error. Change it to a 1E+208 and it'll be happy.

So to answer your question - you have a lot of room to play with Int() and I'd say if you were going to run out of space with Int(), then perhaps Visual Basic as a language is not quite up to what you are wanting to do. Try VB.Net or C++/C# instead - but I think that you will have enough.

Cheers,
David

# re: Int() vs CInt()

Left by Maryanne Sweat at 7/10/2007 7:26 AM
Gravatar
Well since the application under test is mortgage related I don't think I need to worry about Int() giving me grief.

<whew> That's a relief. Unfortunately if Int was going to have an upper bound orders of magnitude smaller than David mentions, I don't really have choice in the programming language. But Luckily, I had a solution that would work if Int() wouldn't accomodate.

# re: Int() vs CInt()

Left by David at 7/10/2007 6:44 PM
Gravatar
Thats great news that it can work for you. One more thing to keep in mind is that Int() truncates to the lowest decimal. So if you are dealing with negative numbers, be careful.

Example:
Dim a As Double
a = -5.45
Debug.Print "a =" & Int(a)

This will print: a = -6
That is because -6 is the integer base with 0.55 added to it. Bitwise, its using the twos-complement to achieve a negative number, hence why it returns to the lower number.
Perhaps its one of the problems with Int(), but it looks only in one direction - namely the lowest number is the integer.


Regards, David

# re: Int() vs CInt()

Left by Maryanne Sweat at 7/10/2007 7:11 PM
Gravatar
Yes all of these numbers are positive integers. I'm still debugging this code. I thougth I had the decimal truncation handled but it may be that the code under test is actually rounding on the percentage calculations after all. NOT 100% sure about that..but the debug slog continues. More to come I'm sure but my brain is fried today. <TOOOOOO MANY ENVIRONMENT ERRORS AT ONCE!!!>

Your comment:



 (will not be displayed)


 
 
 
 
 

Live Comment Preview:

 
«November»
SunMonTueWedThuFriSat
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345