Below example from Excel Help about VBA Log function, notation number# makes conversion of numberinto decimal data type, but makes it any difference for Log function if it takes 10 instead of 10# as an argument ?
Static Function Log10(X)
Log10 = Log(X) / Log(10#)
End Function
To explain why it won't make a difference I need to explain how type conversion is handled in VBA.
In VBA, by default types are attempted to be implicitly converted to the type required by a function/operation, using the default conversions based on your system locale (the system locale bit has meaning when it comes to dates and converting numbers as strings to a numeric type and vice versa).
Consider:
Dim aNumber As Integer, aString As String
aString = 1 & 2
aNumber = aString
aNumber = aString + 1
MsgBox aNumber
In the above, the numbers 1 and 2 are implicitly converted to strings. As system locale doesn't matter when dealing with integral types, aString subsequently is storing "12". Assigning a string to a number results in the string being implicitly converted to a number, so aNumber subsequently is 12, then 13 after the addition. Calling MsgBox passing in a number will result in the number being converted to a string before it is passed in.
Implicit type conversion like the above cannot be disabled in VBA, unlike in VB that has the Option Strict directive.
So, for your Log question above, an integral type passed in will be implicitly converted to a double before actually being passed in. Passing in e.g. 10# compared to 10 will save the conversion (an utterly irrelevant performance consideration) but otherwise is semantically equivalent.
Related
I am using IsNumeric() function in my code to validate numbers.
IsNumeric(100) - true,
IsNumeric(-100) - true,
IsNumeric(+100) - true,
IsNumeric(100-) - true - I have doubt in this. (100-) Is this a valid number? IsNumeric () returns true to this value.
Dim latitude As String = "12.56346-"
If IsNumeric(latitude) Then
If (Convert.ToDouble(latitude) >= -90 And Convert.ToDouble(latitude) <= 90) Then
isValidLatitude.Text = "true"
Else
isValidLatitude.Text = "false"
End If
Else
isValidLatitude.Text = "false"
End If
Error while converting latitude to double
Input string was not in a correct format.
IsNumeric is from the Microsoft.VisualBasic namespace/dll, a bunch of helper stuff intended to help VB6 programmers get their arcane VB6 code /knowledge working on VB.NET
You'll note if you use other functions from the same dll such as Microsoft.VisualBasic.Conversion.Int(), or you use dedicated VB.NET converters such as CInt or CDbl these will also cope with a trailing minus sign and return a negative value
If you want to dispense with the old ways of VB6, use a numeric type's TryParse.. but all in, be consistent / if you use a function from Microsoft.VisualBasic to determine if a conversion can be made, use the vb conversion because within itself the package will be consistent but between Microsoft.VB and normal .net System there are some differences in behavior
Edit:
A couple of people have been wondering about the source code and how it uses TryParse, so why doesn't it work like using TryParse directly?
Microsoft.VisualBasic.Information.IsNumeric() uses Microsoft.VisualBasic.CompilerServices.DoubleType.TryParse() to determine whether an expression is numeric. This DoubleType.TryParse is not the same as Double.TryParse - it is a helper method again in the VB namespace that specifically sets the NumberStyles.AllowTrailingSign flag among many other flags. When parsing the number (first as non currency related, using Double.Parse, then if it fails a second attempt is made using adjusted values for currency related tests) this AllowTrailingSign flag will be considered in conjunction with other regional number formatting rules in determining if the passed in value is numeric
You'll note that on a machine obeying a USA number formatting culture, a string of "(100$)" is also declared to be numeric but calling Double.TryParse("(100$)", x) will also return false. The VB helper methods here are being a lot more liberal in what they accept than the System methods, because they're telling the System methods to be more liberal than they are by default
As noted, I've always regarded the Microsoft.VisualBasic namespace as a bunch of helper methods intended to allow terrible old VB6 code to be pasted into VB.NET and work with minimal fiddling. I wouldn't advocate using it for new projects and I remove the reference when I work on VB.NET - using it to support the VB6 notions of "just sling anything in, of any type, and it'll probably figure it out and work.. and if it doesn't we can always on error resume next" should be discarded in favour of precise and accurate about the operations executed and their intent
Note: my previous answers were wrong about assuming it was a bug. As the answer of #Damien_The_Unbeliever states, this function tries to validate the string as a lot of data types. And actually, the value "100-" is a valid Decimal number. That's why it returns true (as it's a "valid" Decimal) but gives a exception when converting to Double (as it's not a valid Double). #Damien_The_Unbeliever really deserves your +1 for pointing that.
From the documentation (showing all the data types that IsNumeric tries to validate):
IsNumeric returns True if the data type of Expression is Boolean, Byte, Decimal, Double, Integer, Long, SByte, Short, Single, UInteger, ULong, or UShort. It also returns True if Expression is a Char, String, or Object that can be successfully converted to a number. Expression can contain non-numeric characters. IsNumeric returns True if Expression is a string that contains a valid hexadecimal or octal number. IsNumeric also returns True if Expression contains a valid numeric expression that begins with a + or - character or contains commas.
Also, #CaiusJard did a nice search and pointed out that inner methods use a NumberStyles.AllowTrailingSign option, which allows this behavior.
Ok, now to the solution:
Just use a TryParse method, from your desired data type (int, long, etc...). The cool thing is that it'll behaves exactly as you expect, and if the parsing is successful, we have the parsed value already available to use!
if (Int32.TryParse(value, out int number))
{
// String is a valid number, and is already parsed in the 'number' variable!
}
else
{
// String is not a valid number!
}
Solution's VB.Net version:
Dim value As String = "12.56346-"
Dim number As Double = 0
If Double.TryParse(value, number) Then
' String is a valid number, and is already parsed in the "number" variable!
isValidLatitude.Text = "true"
Else
' String is not a valid number!
isValidLatitude.Text = "false"
End If
IsNumeric answers a question no sane person wants to ask. As quoted by Vitox's answer:
IsNumeric returns True if the data type of Expression is Boolean, Byte, Decimal, Double, Integer, Long, SByte, Short, Single, UInteger, ULong, or UShort. It also returns True if Expression is a Char, String, or Object that can be successfully converted to a number.
Note, it doesn't tell you that the given string can be converted to all numeric types. It tells you that the string can be converted to at least one numeric type. And for bonus bad style points, of course, it doesn't tell you which types the string can be converted to.
Decimal.Parse("100-") will execute perfectly well and give you a Decimal containing a value of -100.
So, it's not a bug, it's a bad function that has been retained for backwards compatibility reasons. Nowadays, we know better, and that we want to test whether a string can be converted to a specific data type, for which the TryParse family of functions have been designed.
I'm taking a Visual Basic class and I've been taught to use a type character after declaring a constant variable that is a decimal, like so:
const VARIABLE_NAME As Decimal = 0.06D
It seems redundant to me to add the D at the end, as I have already declared the data type. im afraid to ask my teacher, because i assume she probably wont be able to give me a clear answer in front of the class. I previously took a class on micro-processors so I have some (little) understating of how floats are stored in memory using binary. Can anyone give me a clear explanation so I can share it with my other classmates?
The data type you declare for your entity (a constant) is not necessarily the data type of the expression used to initialize that entity. You declare the type on the left side of the =, and it does not extend to the right. If the data types do not match, a conversion will need to happen upon assignment.
As documented, the type of a literal expression is dictated by its shape. A literal that falls under Numeric, fractional part is interpreted as a Double by default.
If you enable Option Strict On (which you should), the declaration
Const VARIABLE_NAME As Decimal = 0.06
will fail with the error:
Option Strict On disallows implicit conversions from 'Double' to 'Decimal'.
This is because there is no implicit conversion from Double to Decimal, as the Double data type can possibly contain values that Decimal cannot represent.
To avoid the conversion, you provide a type character D that makes the literal Decimal in the first place.
Compare this to
Const VARIABLE_NAME As Decimal = 42
The left part is Decimal, the right part is Integer, but no compile error occurs even with Option Strict On, because now there is an implicit widening conversion from Integer to Decimal, because Decimal can represent all values an Integer can possibly have.
Question: Can I assume that Str(myString) will always return the same result as Str(CDbl(myString)) (assuming that myString is statically typed as a string)?
Context:
I am trying to understand VBA's implicit conversions. So far, it appears to me that Str(myString)
implicitly parses myString into a double (culture-sensitive) and then
converts the result into a culture-insensitive string.
For example, using a German locale (i.e. using , as the decimal separator), it holds that
" 1.2" = Str(1.2) = Str("1,2") = Str(CDbl("1,2"))
Since these implicit conversions contain a lot of "magic" to me, I am trying to rewrite a procedure that uses an implicit conversion (Str(myString)) to one using explicit conversion without changing the behavior.
Unfortunately, the documentation is wrong and, thus, useless. (The documentation claims that the argument to Str is interpreted as a Long, which is obviously rubbish: If that were the case Str(1.2) could never yield " 1.2".)
Your statement is true. Str(x) and Str(Cdbl(x)) give identical result provided that x is String data type and contains a valid number.
I made a small test to get convinced.
I used Excel, but it holds the same with Access.
Public Function myStr(txt As String) As String
myStr = Str(txt)
End Function
Public Function myStrCDbl(txt As String) As String
myStrCDbl = Str(CDbl(txt))
End Function
I tried with some key values (0, 1.2, 1E+307, 1E-307, ...) : result of myStr and myStrCDbl are always identical.
I also agree with you that the documentation is wrong. If Str() argument would be interpreted as Long, then Str(1.2) would give "1", because Long is an integer type.
In the mean time, I've found the VBA language specification and can confirm that the spec also answers the question with "yes":
CDbl, when receiving a string, performs a Let-coercion to Double:
If the value of Expression is not an Error data value return the Double data value that is the result of Expression being Let-coerced to Double.
Str, when receiving a string, first performs a Let-coercion to Double and then applies Str:
[If Number is a String,] the returned value is the result of the Str function applied to the result of Let-coercing Number to Double.
Please forgive me, I haven't used this site very much! I am working in Visual Studio with Visual Basic. I finished programming my project with Option Strict Off, then when I turned Option Strict on, I was alerted that this code was wrong:
Const TAX_Decimal As Decimal = 0.07
The explanation was that "Option Strict On disallows implicit conversions from 'Double' to 'Decimal'"
But I thought I had declared it as a decimal! It made me change it to:
Const TAX_Decimal As Decimal = CDec(0.07)
The only thing I did with this constant was multiply it by a decimal and saved it to a variable declared as a decimal!
Can someone tell me why this is happening?
Double is 8 bytes and Decimal is 16 bytes. Option Strict prevents from automatic type conversion. By default if you write a number with decimals in VB.NET it is considered as double and not decimal. For saying decimal you have to use some character to specify (I thing for decimal is m) so if you declare
Const VAR as decimal = 0.07m
then you wont require casting.
When the compiler sees a numeric literal, it selects a type based upon the size of the number, punctuation marks, and suffix (if any), and then translates the the sequence of characters in it to that type; all of this is done without regard for what the compiler is going to do with the number. Once this is done, the compiler will only allow the number to be used as its own type, explicitly cast to another type, or in the two cases defined below implicitly converted to another type.
If the number is interpreted as any integer type (int, long, etc.) the compiler will allow it to be used to initialize any integer type in which the number is representable, as well as any binary or decimal floating-point type, without regard for whether or not the number can be represented precisely in that type.
If the number is type Single [denoted by an f suffix], the compiler will allow it to be used to initialize a Double, without regard for whether the resulting Double will accurately represent the literal with which the Single was initialized.
Numeric literals of type Double [including a decimal point, but with no suffix] or Decimal [a "D" suffix not followed immediately by a plus or minus] cannot be used to initialize a variable of any other, even if the number would be representable precisely in the target type, or the result would be the target type's best representation of the numeric literal in question.
Note that conversions between type Decimal and the other floating-point types (double and float) should be avoided whenever possible, since the conversion methods are not very accurate. While there are many double values for which no exact Decimal representation exists, there is a wide numeric range in which Decimal values are more tightly packed than double values. One might expect that converting a double would choose the closest Decimal value, or at least one of the Decimal values which is between that number and the next higher or lower double value, but the normal conversion methods do not always do so. In some cases the result may be off by a significant margin.
If you ever find yourself having to convert Double to Decimal, you're probably doing something wrong. While there are some operations which are available on Double that are not available on Decimal, the act of converting between the two types means whatever Decimal result you end up with is apt to be less precise than if all computations had been done in Double`.
Basically, I have been using both Integer.Parse and CInt in most of my daily programming tasks, but I'm a little bit confused of what the difference is between the two.
What is the difference between Integer.Parse and CInt in VB.NET?
CInt does a whole lot more than Integer.Parse.
CInt will first check to see if what it was passed is an integer, and then simply casts it and returns it. If it's a double it will try to convert it without first converting the double to a string.
See this from the help for CInt and other Type Conversion Functions
Fractional Parts. When you convert a
nonintegral value to an integral type,
the integer conversion functions
(CByte, CInt, CLng, CSByte, CShort,
CUInt, CULng, and CUShort) remove the
fractional part and round the value to
the closest integer.
If the fractional part is exactly 0.5,
the integer conversion functions round
it to the nearest even integer. For
example, 0.5 rounds to 0, and 1.5 and
2.5 both round to 2. This is sometimes called banker's rounding, and its
purpose is to compensate for a bias
that could accumulate when adding many
such numbers together.
So in short, it does much more than convert a string to an integer, e.g. applying specific rounding rules to fractions, short circuiting unnecessary conversions etc.
If what you're doing is converting a string to an integer, use Integer.Parse (or Integer.TryParse), if you're coercing an unknown value (e.g. a variant or object from a database) to an integer, use CInt.
Looking with ILDASM at some sample code you can see that CInt is converted to this call:
Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Conversions::ToInteger(string)
Using .NET Reflector, you can extract this piece of code:
Public Shared Function ToInteger(ByVal Value As String) As Integer
Dim num As Integer
If (Value Is Nothing) Then
Return 0
End If
Try
Dim num2 As Long
If Utils.IsHexOrOctValue(Value, (num2)) Then
Return CInt(num2)
End If
num = CInt(Math.Round(Conversions.ParseDouble(Value)))
Catch exception As FormatException
Throw New InvalidCastException(Utils.GetResourceString("InvalidCast_FromStringTo", New String() { Strings.Left(Value, &H20), "Integer" }), exception)
End Try
Return num
End Function
You can see that internally it calls Conversions.ParseDouble.
Therefore, as already explained by Binary Worrier, use Integer.Parse for string coercing and CInt only for casting.
Here is a real difference :
Integer.parse("1.00") will thrown an error.
CInt("1.00") will work
The <Data Type>.Parse methods are used to extract a value of the type from a string that represents the value (e.g 2 from "2") The C<Data Type> functions operate on expressions and return a variant sub-typed to the desired type (e.g. CInt("2") OR CInt(SomeDouble + SomeDouble), etc.).