<!-- PDF page 48 -->

```
-10
-10
```

What happened here is that -**1** is as we discussed **65535** for unsigned integers. So on line 10, the computer multiplied **10 \* 65535** which resulted to **655350** but as an integer number, this is larger than 16 bits. Then it gets truncated to 16 bits which results into **65526** which is obviously wrong as a result. Moving to line 20 we hit the first pitfall discussed in the opening statement: The result of **SGN {-1}** which is **-1** gets converted into an unsigned integer itself so you end up with the exact same situation as with line 10; a multiplication of **10** with **65535**. The pitfall therefore here is that **SGN{...}** must apply to the entirety of the integer expression, so if there are other non-signed expressions they must be taken into consideration when writing each statement! Line 30 produces finally what we were aiming for, but that also happens with line 40! So both are correct but which is the right way to do it?

The answer to that question lies with what we discussed above regarding the "pitfall" with integer expressions. The *subexpression* **SGN {-1}** will get evaluated to whatever is in the enclosing expression. So if the enclosing expression is an *unsigned expression*, the result of the *subexpression* will also become converted to *unsigned*; ergo since the entirety of the integer expression of line 30 is a *signed expression*, the *signed subexpression* is unnecessary and *may even delay* execution (especially in very complex calculations). The right way therefore to do it, is the way defined in line 40. Obviously this also applied to our initial example which is best written as:

```
PRINT % SGN {1 -32300- (-1)}
```

which is much neater to write AND read!

### Exercises

1. Using the discussion about the unary **!** operator and 16 bit binary numbers, calculate and print on screen the *two's complement* for the signed 32 bit integer: **650323**

