# VAL (Function)

*915*pages on

this wiki

## V1Edit

Indications are, `VAL`

in SmileBasic V1 is identical to that in V2.

## V2Edit

`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 error`

s, 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.

## V3Edit

Indications are, `VAL`

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