VAL()
The VAL(a$) function returns the decimal value represented by the string argument a$. While it is the logical inverse of the STR$(x) function, there are some additional features and considerations. For one, it supports the "hexadecade" date notation enabled by OPTIONS=HEXDEC (which see for more information). It also supports the decimal point and thousands separate character definitions in the Language Definition File (-> LANGUAGE).
VAL$(a$) ignores leading spaces, and stops at the first character which is not a legal character in a decimal value representation. So for example, VAL("123.4X") returns 123.4, and VAL(" 012 34") returns 12. See VALX() for an alternative that is more tolerant of non-numeric characters mixed up with the number being evaluated, such as prefixes, currency symbols, thousands separators, etc.
As in the case with the STR$(x) function, the compiler will often insert the VAL(a$) function implicitly into a statement or expression when needed to convert a string argument to obtain a numeric result. So its use is optional in cases like:
map1 x,f
map1 a$,s,10,"123"
x = a$ ! same as x = VAL(a$)
Note that when explicitly applied to an expression (rather than just a variable or literal), it causes the compiler to expect the expression to be of type string (since the point of the VAL(a$) function is to convert the string a$ to a numeric value). This can have counter-intuitive side effects, including converting any numeric operands within the expression to string, and treating the "+" operator as concatenation rather than addition. For example:
map1 x,f,6
map1 a$,s,10,"2"
map1 b$,s,10,"3"
x = a$ + b$ ! = 5
x = val(a$) + val(b$) ! = 5
x = val(a$ + b$) ! = 23
x = val(x + a$) ! = 232
x = numexpr(a$ + b$) ! = 5
The first two statements are equivalent, i.e. the compiler effectively converts the first expression into the second. The reasoning is that since the target of the assignment is a numeric variable (x), the expression on the right side of the equals sign should be a numeric expression. When the compiler encounters the string variables a$ and b$, it therefore inserts implicit val() functions to convert them to numbers, and interprets the plus operator as addition, i.e. val("2") + val("3") = 5
In the third statement, the explicit val() enclosing the expression causes the compiler to expect the expression to be string, which causes it to interpret the plus operator as concatenation, i.e. "2" + "3" = "23".
The fourth statement is just like the third, except that when the compiler sees the numeric x operand within val(x + a$), it perhaps counter-intuitively converts it to a string, since it expects the argument of the val() function to be string. So even though we have an explicit val() function, and a numeric argument x, we still treat the plus operator as concatenation rather than addition.
The final statement illustrates the numexpr() alternative to the val() function. Added in 6.5 (compiler 890), it tells the compiler to expect a numeric expression, which in turn causes it to convert the operands a$ and b$ to numbers, and to treat the plus operator as addition, which is probably a more intuitive approach when dealing with expressions rather than simple values.
See Also
