Strange.
Here is the version I'm now using in my code:
function FloatVal(a$)
// declare some bits
c AS integer
l AS integer
fd AS integer
dp AS integer
// initialise values
fd = 0
l = len(a$)
// search for the first dot in the string
for c = 1 to l
if mid(a$, c, 1) = "."
// indicate found
fd = 1
// store the location
dp = c
// get out of the loop
exit
endif
next c
// if no period found, just return float version of
// the value of the string
if fd = 0
v# = val(a$)
exitfunction v#
endif
// get the fractional part
fp$ = right(a$, l - dp)
// calculate the divisor needed to move the decimal
div# = (10.0 ^ (len(fp$)))
// convert, calculate and combine them
v# = val(left(a$, dp)) + (val(fp$) / div#)
endfunction v#
I like short variable names, and I had an old 'FloatVal' function, so I stuck with that name.
I looked at what I posted and can't see where I goofed making the names longer.
I just ran some tests to see how long fractional parts gets handled (the Str for the results specifies 12 decimal places):
a$='300.0' frac str='0' frac val=0.000000000000 div=10.0 res=300.000000000000
a$='0.75' frac str='75' frac val=0.750000000000 div=100.0 res=0.750000000000
a$='0.5' frac str='5' frac val=0.500000000000 div=10.0 res=0.500000000000
a$='0.99' frac str='99' frac val=0.990000009537 div=100.0 res=0.990000009537
a$='972' no fraction, res=972.000000
a$='-12' no fraction, res=-12.000000
a$='12345.987654321' frac str='987654321' frac val=0.987654328346 div=1000000000.0 res=12345.987304687500
a$='12345.123456789' frac str='123456789' frac val=0.123456791043 div=1000000000.0 res=12345.123046875000
It looks like we get somewhat strange behavior. I even tried calculating the two parts seperately and still got the same results.
The initial calculation for the fractional part shows it's ok out to the first 7 or 8 places and then messes up. And it get further messed up when combined with the whole part.
I think we are seeing a basic problem with handling large fractions. It may be due to how the basic is doing multiplications or the range it allows in storage (as hinted by the second mess up). If only 32 bit math/values are being used, that might be part of it.
I tried all three of the float conversion versions and they all returned the same result. I adjust the original FloatVal to allow up to 10 decimal places.
If it were Tier2 or Fortran (yup, I've done serious graphics and science in that language, I've even programmed in COBOL), I'd make sure that the variables were all the long version of floats (64 bits).
Cheers,
Ancient Lady