Integer byte encoding peculiarity

From mojo_puzzler
Revision as of 15:56, 17 November 2023 by Gneale (talk | contribs) (Created page with "===== Return to: Chialisp ===== According to Matt Howard 20210816, there is a "peculiarity with how integers are encoded in bytes. It's signed integers. If you just return <code>run '(q . 0xd7)'</code> you get -41 because the most significant bit is set and that's telling the interpreter to read this as a negative number. If you add some leading zeroes <code>run '(q . 0x00d7)'</code>, it should pop out as you would expect". Returns 215. <h1>Orig...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Return to: Chialisp

According to Matt Howard 20210816, there is a "peculiarity with how integers are encoded in bytes.

It's signed integers.

If you just return run '(q . 0xd7)' you get -41 because the most significant bit is set and that's telling the interpreter to read this as a negative number.

If you add some leading zeroes run '(q . 0x00d7)', it should pop out as you would expect".

Returns 215.

Original concern

Q: I still have one question: why does brun '(- (q . 0xd7) (q . 0x1))' return -42?

A: hex(-42 & 0xff) == '0xd6 I see thanks!