val function returns NaN

  • Thread starter Thread starter BillE
  • Start date Start date
Bill,

I think the mite is here:

dt.Columns.Add("valENum", GetType(Long))

that should be a:

dt.Columns.Add("valENum", GetType(Double))

because that is the result of VAL()

Do you have Options Strict On?

You should of gotten a compiler error with the assignmentL

dr("valENum") = Val(dr("ENum"))

--
 
Bill,

The GetType(long) bug fix to GetType(Double) is part of the issue.

But you should just take control of the conversion to resolve the
issue with a function like this:

function atol(byval o as object, optional def as long = 0) as long
try
return val(o)
catch ex as exception
return def
end try
end function

Now depending on how you are rendering the results, the default error
value of zero might give you false positives on your display.

IF -1 is out of range for your application, then you might consider
using -1 for the default:

dr("valENum") = atol(dr("ENum"),-1)

Hope this helps

PS: As a side note, this is why I think it was a bad idea for MS to
make long 64 bit. Just unnatural - to me. <g>

--
 
Bill,

The GetType(long) bug fix to GetType(Double) is part of the issue.

But you should just take control of the conversion to resolve the
issue with a function like this:

function atol(byval o as object, optional def as long = 0) as long
try
return val(o)
catch ex as exception
return def
end try
end function

Now depending on how you are rendering the results, the default error
value of zero might give you false positives on your display.

IF -1 is out of range for your application, then you might consider
using -1 for the default:

dr("valENum") = atol(dr("ENum"),-1)

Hope this helps

PS: As a side note, this is why I think it was a bad idea for MS to
make long 64 bit. Just unnatural - to me. <g>

--
 
Mike said:
Bill,

I think the mite is here:

dt.Columns.Add("valENum", GetType(Long))

that should be a:

dt.Columns.Add("valENum", GetType(Double))

because that is the result of VAL()

Do you have Options Strict On?

You should of gotten a compiler error with the assignmentL

dr("valENum") = Val(dr("ENum"))

--


Actually, that is neither a compile error, nor an exception at runtime.
 
Mike said:
Bill,

I think the mite is here:

dt.Columns.Add("valENum", GetType(Long))

that should be a:

dt.Columns.Add("valENum", GetType(Double))

because that is the result of VAL()

Do you have Options Strict On?

You should of gotten a compiler error with the assignmentL

dr("valENum") = Val(dr("ENum"))

--


Actually, that is neither a compile error, nor an exception at runtime.
 
D:\Local\wcsdk\wcserver\dotnet\Sandbox\testnan2.vb(52) : error
BC30512: Option Strict On disallows implicit conversions from 'Double
' to 'Long'.

dr1("valENum") = Val(dr2("Enum"))
~~~~~~~~~~~~~~~~
* ExitCode: 1

Looks like a compiler error (not warning) to me. :-)

The code was (with Options Strict On):

Dim dr1 As New Dictionary(of string, long)
Dim dr2 As New Dictionary(of string, object)

dr2("Enum") = Math.Sqrt(-1)
dr1("valENum") = Val(dr2("Enum"))

---
 
D:\Local\wcsdk\wcserver\dotnet\Sandbox\testnan2.vb(52) : error
BC30512: Option Strict On disallows implicit conversions from 'Double
' to 'Long'.

dr1("valENum") = Val(dr2("Enum"))
~~~~~~~~~~~~~~~~
* ExitCode: 1

Looks like a compiler error (not warning) to me. :-)

The code was (with Options Strict On):

Dim dr1 As New Dictionary(of string, long)
Dim dr2 As New Dictionary(of string, object)

dr2("Enum") = Math.Sqrt(-1)
dr1("valENum") = Val(dr2("Enum"))

---
 
But in the context of this thread, dr is of type DataRow and DataRow columns
are considered to be of type Object for the purposes of interrogation and
assignment, regardles of the 'internal' type for the column concerned.

Therfore the statement dr1("valENum") = Val(dr2("Enum")) is legal, even
with Option Strict On because a Double can be assigned to an Object.

The issue is, what is the value of dr("Enum") that makes Val return
Double.NAN.
 
But in the context of this thread, dr is of type DataRow and DataRow columns
are considered to be of type Object for the purposes of interrogation and
assignment, regardles of the 'internal' type for the column concerned.

Therfore the statement dr1("valENum") = Val(dr2("Enum")) is legal, even
with Option Strict On because a Double can be assigned to an Object.

The issue is, what is the value of dr("Enum") that makes Val return
Double.NAN.
 
The code runs fine, converting mixed alpha and numeric values to pure
numeric values as expected. There is only one reported instance among a
number of clients experiencing this issue. I don't know if I can get the
data to investigate further.

I appreciate all the help provided!
 
The code runs fine, converting mixed alpha and numeric values to pure
numeric values as expected. There is only one reported instance among a
number of clients experiencing this issue. I don't know if I can get the
data to investigate further.

I appreciate all the help provided!
 
Stephany said:
But in the context of this thread, dr is of type DataRow and DataRow
columns are considered to be of type Object for the purposes of
interrogation and assignment, regardles of the 'internal' type for the
column concerned.

Which why I did in:

Dim dr2 As New Dictionary(of string, object)
Therfore the statement dr1("valENum") = Val(dr2("Enum")) is legal, even
with Option Strict On because a Double can be assigned to an Object.

Unless I missing something, that is not what I am seeing:

Dim dr2 As New Dictionary(of string, object)
dr1("valEnum") = PUT ANY OBJECT TYPE HERE
dr1("valENum") = Val(dr2("Enum")) <<--- type convert error

and unless I turn off strict, I get the compiler error.
The issue is, what is the value of dr("Enum") that makes Val return
Double.NAN.

I agree.

But its not val() IMO.

I don't think I been able to find any way VAL() itself to produce a
NaN. All inputs are technically strings, in fact, for the overload:

val(expression)

The expression object must be return a string according to MSDN (I
presume this is done using operators)

So it is dr("Enum") that is evaluated to NaN as based as I can tell.

Anyway, IMO, for the OP, when doing conversions, exception traps must
be incorporated because of unknowns such as thing.

--
 
Stephany said:
But in the context of this thread, dr is of type DataRow and DataRow
columns are considered to be of type Object for the purposes of
interrogation and assignment, regardles of the 'internal' type for the
column concerned.

Which why I did in:

Dim dr2 As New Dictionary(of string, object)
Therfore the statement dr1("valENum") = Val(dr2("Enum")) is legal, even
with Option Strict On because a Double can be assigned to an Object.

Unless I missing something, that is not what I am seeing:

Dim dr2 As New Dictionary(of string, object)
dr1("valEnum") = PUT ANY OBJECT TYPE HERE
dr1("valENum") = Val(dr2("Enum")) <<--- type convert error

and unless I turn off strict, I get the compiler error.
The issue is, what is the value of dr("Enum") that makes Val return
Double.NAN.

I agree.

But its not val() IMO.

I don't think I been able to find any way VAL() itself to produce a
NaN. All inputs are technically strings, in fact, for the overload:

val(expression)

The expression object must be return a string according to MSDN (I
presume this is done using operators)

So it is dr("Enum") that is evaluated to NaN as based as I can tell.

Anyway, IMO, for the OP, when doing conversions, exception traps must
be incorporated because of unknowns such as thing.

--
 
In case anyone is interested...

There are some string expressions which the val() function returns "-1.#IND"
An example is "d48609" (the value of the client's Employee Number).
"e48609" also returns "-1.#IND"
However, "c48609" or "f48609" or "d4860" return 0.0

I haven't spent much time investigating this - apparently IND suggests
"INDefinite", possibly a variation of NAN.
 
In case anyone is interested...

There are some string expressions which the val() function returns "-1.#IND"
An example is "d48609" (the value of the client's Employee Number).
"e48609" also returns "-1.#IND"
However, "c48609" or "f48609" or "d4860" return 0.0

I haven't spent much time investigating this - apparently IND suggests
"INDefinite", possibly a variation of NAN.
 
BillE said:
In case anyone is interested...

There are some string expressions which the val() function returns
"-1.#IND" An example is "d48609" (the value of the client's Employee
Number). "e48609" also returns "-1.#IND"
However, "c48609" or "f48609" or "d4860" return 0.0

I haven't spent much time investigating this - apparently IND suggests
"INDefinite", possibly a variation of NAN.

Thanks for letting us know.


Armin
 
BillE said:
In case anyone is interested...

There are some string expressions which the val() function returns
"-1.#IND" An example is "d48609" (the value of the client's Employee
Number). "e48609" also returns "-1.#IND"
However, "c48609" or "f48609" or "d4860" return 0.0

I haven't spent much time investigating this - apparently IND suggests
"INDefinite", possibly a variation of NAN.

Thanks for letting us know.


Armin
 
Back
Top