IsNumeric Function

[Guest]

What is prefered way to check whether a is a numeric value
Is ther something like IsNumeric function in VB6

Thanks
Mark.

 

[VJ]

The same IsNumeric is available in VB.NET, but the recomendation is to use
the RegEx functions.. here is a sample..

Imports System.Text.RegularExpressions

blnValidData = Regex.IsMatch(Text1.Text, "^\d+$") 'Allows integer,and
comma formatted numbers
If Not blnValidData Then
MsgBox("You can enter numbers only in - " & Text1.Name,
MsgBoxStyle.OKOnly + MsgBoxStyle.Exclamation, "Error")
End If

visit www.regexlib.com for more patterns

VJ

 

[Chris Botha]

Must say, comparing the two, I'd go for the IsNumeric

 

[Scott M.]

One problem with IsNumeric is (and always has been) that if the value STARTS
out with a number it will be treated as numeric. For example,

123,456.AA

would be considered numeric by IsNumeric.

 

[Chris Botha]

Scott, maybe in VB6, but your example will evaluate to false in .NET.
One problem that was and still is, is something like 123E1 , which can mean
numeric 1230 if so intended, or an error if miss-typed.

 

[Jon Skeet [C# MVP]]

The same IsNumeric is available in VB.NET, but the recomendation is to use
the RegEx functions..

That may be *your* recommendation. It's certainly not mine

Rather than using regular expressions, it's very easy to write a method
which quickly knocks out most "obviously" non-numeric strings.

Having done that, you can use Double.TryParse.

This approach is significantly faster than using regular expressions
(in the tests I did a while ago, at least).

 

[Alvin Bruney [MVP]]

This approach is significantly faster than using regular expressions

(in the tests I did a while ago, at least).

can you point me to those test?

Tryparse actually throws an exception on an invalid format. I'm not sure
that a live exception is faster than a regex compilation and execution. It
would make sense that if the data was significantly faulty, or perhaps
generally unknown that the use of a regex would be a suitable optimization
to avoid the run-time exceptions.

 

[Jon Skeet [C# MVP]]

can you point me to those test?

Sure. Have a look on groups.google.com for "Checking if a string can be
converted to Int32" (in this group).

Tryparse actually throws an exception on an invalid format. I'm not sure
that a live exception is faster than a regex compilation and execution.

Um, I don't think TryParse *does* throw an exception - the whole point
is that it doesn't, surely?

It would make sense that if the data was significantly faulty, or perhaps
generally unknown that the use of a regex would be a suitable optimization
to avoid the run-time exceptions.

No it wouldn't - not compared with a simple hard coded test and then
using TryParse.

Here are the results I got from the benchmark in the thread mentioned
earlier:

Benchmarking type StringToInt
JustException: 00:01:15.7989936
HardCodedCheck: 00:00:00.7010080
DoubleTryParse: 00:00:40.8387232
Regex: 00:00:43.0418912
IsNumeric: 00:01:06.9062064

(It does the obvious thing.)

Yes, the hard-coded test is over 50x faster than the next-best, which
is Double.TryParse.

 

[mikeb]

Jon:

I've seen you put forth and defend this algorithm several times. I
suggest you add this to your FAQ - maybe in the "Converting to C# from
VB.NET" section. It's not only a FAQ, but it's one that seems to get
you sucked into a lengthy explanation each time.

 

[Jon Skeet [C# MVP]]

I've seen you put forth and defend this algorithm several times. I
suggest you add this to your FAQ - maybe in the "Converting to C# from
VB.NET" section. It's not only a FAQ, but it's one that seems to get
you sucked into a lengthy explanation each time.

Yes, good idea

I'll try to get round to it later today.

 

[Alvin Bruney [MVP]]

I don't think i found the exact thread but what i found i used which just
had the hard check and exception.
I also have a monster laptop

No extra checking: 00:00:30.4537904
(Total=65554500000)
With preliminary checking: 00:00:00.2603744
(Total=65554500000)

Your conclusions are correct.
i really don't know where i got that from. it's obviously wrong.

Another important point is that running this test under visual studio skews
each result by about 5% - 15% when the debugger is not attached in both
release and debug mode. Attaching the debugger provided results which took
over 10 minutes. I've concluded that timing applications by using visual
studio is unreliable at best since the skew is not a constant value for each
result.