Indications are, VAL in SmileBasic V1 is identical to that in V2.


VAL is a function which converts a string representation of a number into a numeric value. The empty string gives a result of 0, so VAL("") evaluates to 0; it does not evaluate expressions (except for a single unary - if it appears at the beginning of the string followed by a decimal value), so for example VAL("4+8") will give the result 4; and the function processes only the largest leftmost substring that represents a number, so for example VAL("34TWO5") evaluates to 34 and VAL("&B101210") evaluates to 5. An important consequence is that VAL("VARIABLENAME") will always return 0, regardless of the value stored in the variable.

There are several shortcomings or pitfalls in the Petit Computer implementation of this function. The following are some examples.

If the string is the single character "-", the function will generate an error "Illegal function call (VAL)".

VAL("X") gives 0, as explained above, but VAL("-X") generates "Illegal function call (VAL)".

If the string starts with "--", the function will generate "Illegal function call (VAL)". This is in contrast to executable program text, where, for example, the expression --2 evaluates to 2 without any error.

VAL only recognises the prefix &H for hexadecimal values, in executable program text you can use &H or &h. VAL("&h0") generates a Syntax Error.

The string "&H" generates 0, which is in contrast to executable program text, where &H that is not followed by a hexadecimal number generates a Syntax Error.

VAL("&H20") gives 32, as expected, but VAL("-&H20") makes an "Illegal function call (VAL)" error, and VAL("&H-20") gives 0.

VAL("&H20.2") gives 32. &H only processes integer values.

The behaviour for &B and &b is as it is for &H and &h.

VAL("&") and VAL("&A") generate Syntax errors, but VAL("%"), VAL("@"), and the like, give 0.

VAL("+7") gives 0.

VAL("0.3") gives 0.3, and VAL("-.3") gives -0.3, as expected, but VAL(".3") gives 0.

VAL is, conceptually, the opposite of STR$, but STR$ only has precision to one-thousandth, less precise than numerical values are stored by the system (1/4096). For example, say you execute the assignment Z=5/4096. Z will have the value precisely 5/4096, or 0.001220703125, with no rounding error (Z*4096==5 is TRUE). Then, STR$(Z) gives the string "0.001", and VAL(STR$(Z)) will give 4/4096, or 0.0009765625. VAL(STR$(Z)) can even generate an Illegal function call (VAL), for instance, after Z=524287.9999, so in practice, they don't really operate purely as opposites of each other.

VAL is subject to the 0.999995 bug.

VAL mostly rounds towards zero. It sometimes 'rounds' further than it should, too, e.g. 0.0002449 is greater than 1/4096, the smallest positive value the system can represent, but VAL("0.0002449") does not give 1/4096, it gives 0. And, it sometimes rounds in the opposite direction, e.g. 0.000976 is less than 4/4096, but VAL("0.000976") gives the result 4/4096.


Indications are, VAL in SmileBasic V3 is identical to that in V2, except hopefully, the bugs are fixed.