val() function returns Indefinite value ("-1.#IND")

  • Thread starter Thread starter BillE
  • Start date Start date
I see; it is interesting, however, that val("d4860") = 0.0, not 10^4860.
val("d2") = 0.0, but it would seem that it should be 1000.0. Val("10e2") =
1000.0

Well, I sort of screwed up :) The line of code is in the Val function that
calculates the value in this case is:

value = value * (10 ^ (eval))

value represents the digits before the d. eval contains the number after the
d (or e). So, all of those case should return 0.0:

value = 0 * (10 ^ 2)
value = 0 * (10 ^ 4860)
....

Val will return NaN when ever 10 ^ eval part evaluates to a number larger then
Double.MaxValue.
 
I see; it is interesting, however, that val("d4860") = 0.0, not 10^4860.
val("d2") = 0.0, but it would seem that it should be 1000.0. Val("10e2") =
1000.0

Well, I sort of screwed up :) The line of code is in the Val function that
calculates the value in this case is:

value = value * (10 ^ (eval))

value represents the digits before the d. eval contains the number after the
d (or e). So, all of those case should return 0.0:

value = 0 * (10 ^ 2)
value = 0 * (10 ^ 4860)
....

Val will return NaN when ever 10 ^ eval part evaluates to a number larger then
Double.MaxValue.
 
BillE said:
I have to sort a list of Employees by the alphanumeric Employee Number (not
the primary key, but a unique index available to the user).

Sometimes users want to sort by the initial numerals of the employee number.
"2abc" should come before "11abc".

I thought the val function should accept any ascii characters.  The val
function should return a double: val("2abc") = 2.0  val("11abc") = 11.0
val("abc") = 0.0

It seems to me you'd get better results if you sorted on

EmpNum.ToUpper.PadLeft(MAX_EMPNUM_SIZE, "0"c)

where EmpNum is, obviously, the employee number, and MAX_EMPNUM_SIZE
is the maximum size of the employee number string.

Thanks for sharing the bug, I'd never know that Val takes also "d"
into account (even though the chances I use Val are almost as remote
as the chances I use "+" to concatenate strings, i.e., none; but it is
always fun to know these things).

Regards,

Branco.
 
BillE said:
I have to sort a list of Employees by the alphanumeric Employee Number (not
the primary key, but a unique index available to the user).

Sometimes users want to sort by the initial numerals of the employee number.
"2abc" should come before "11abc".

I thought the val function should accept any ascii characters.  The val
function should return a double: val("2abc") = 2.0  val("11abc") = 11.0
val("abc") = 0.0

It seems to me you'd get better results if you sorted on

EmpNum.ToUpper.PadLeft(MAX_EMPNUM_SIZE, "0"c)

where EmpNum is, obviously, the employee number, and MAX_EMPNUM_SIZE
is the maximum size of the employee number string.

Thanks for sharing the bug, I'd never know that Val takes also "d"
into account (even though the chances I use Val are almost as remote
as the chances I use "+" to concatenate strings, i.e., none; but it is
always fun to know these things).

Regards,

Branco.
 
Hello, Tom,

Re: "...but I'm not familiar with using D/d..."

If I recall correctly, the scientific notation using "E" first arose in
Fortran. There "E" was used for literals that were to be interpreted as
single precision (4-byte) and "D" was used for literals that were to be
interpreted as double precision (8-byte).

So perhaps this is a carryover from days of yore.

Cheers,
Randy
 
Hello, Tom,

Re: "...but I'm not familiar with using D/d..."

If I recall correctly, the scientific notation using "E" first arose in
Fortran. There "E" was used for literals that were to be interpreted as
single precision (4-byte) and "D" was used for literals that were to be
interpreted as double precision (8-byte).

So perhaps this is a carryover from days of yore.

Cheers,
Randy
 
Hello, Tom,

Re: "...but I'm not familiar with using D/d..."

If I recall correctly, the scientific notation using "E" first arose in
Fortran. There "E" was used for literals that were to be interpreted as
single precision (4-byte) and "D" was used for literals that were to be
interpreted as double precision (8-byte).

So perhaps this is a carryover from days of yore.

Cheers,
Randy

Interesting... You may have something there :)
 
Hello, Tom,

Re: "...but I'm not familiar with using D/d..."

If I recall correctly, the scientific notation using "E" first arose in
Fortran. There "E" was used for literals that were to be interpreted as
single precision (4-byte) and "D" was used for literals that were to be
interpreted as double precision (8-byte).

So perhaps this is a carryover from days of yore.

Cheers,
Randy

Interesting... You may have something there :)
 
Back
Top