Expressions such as X↑Y give an 'A Invalid argument' error when X is negative, even when Y is an integer. For example:

PRINT (-1)↑2

This is because the to_power routine computes the value as EXP (Y*LN X), and LN X is undefined for negative values of X.

Numeric comparisons work by subtracting one number from the other (see the subtract call at 3554). This means that:

PRINT 1e38>-1e38

gives a '6 Number too big' error instead of the expected '1'. Any comparison whose difference exceeds the largest number that can be represented in floating-point form (about 1.7e38) fails the same way.

For the same reason, slightly different very small numbers are regarded as equal when compared (because their difference rounds down to zero). For example:

PRINT 5e-39,6e-39

prints two different values, but:

PRINT 5e-39=6e-39

prints '1' (as if the values were equal).

Consider the following program:

The negative coordinates apparently make no sense, but the result is a pixel plotted at (10,20), which the POINT command correctly identifies.

Likewise:

prints '59' and 'a' (as if the minus signs were not present).

Also:

CIRCLE -100,50,0.9

results in a pixel plotted at (100,50) - because the radius is less than 1 and so it just PLOTs the point. But:

CIRCLE -100,50,1

gives a more sensible 'B Integer out of range' error.

We've already seen that ATTR and SCREEN$ are blind to negative coordinates, but they also don't care about coordinates that are out of range. For example:

prints '255', because the attribute file address for (24,0) is computed as 23296, the first byte of the printer buffer (where the '25th line' of the attribute file would naturally be, if it existed).

Similarly:

prints '59' and 'a', because (0,32) effectively resolves to (1,0).