allow numbers in any base to be entered regardless of the BASE mode

[bxparks]

Currently, RPN83P follows the UI of the HP-42S, where the BASE mode (i.e. DEC, HEX, OCT, BIN) determines the base of the number that is entered. For example, in OCT mode, the entry 377 is interpreted to be base-8, and the digits 8, 9 are disabled. The digits A through F are enabled only in HEX mode.

I am finding that this behavior is inconvenient for doing real life calculations. I often want to enter a number in any base regardless of the BASE mode. Here are my thoughts on how to implement this feature.

Survey of Other Solutions

Here are some examples of how some other languages and calculators represent integer literals in different bases:

Decimal:

• #..d, e.g. #255d (HP48/49/50)
• NNNN₁₀ i.e. subscript 10 (math notation)

Hex:

• 0x prefix, e.g. 0xFF (C, C++, assemblers)
• 0h prefix, e.g. 0hFF (assemblers)
• $ prefix, e.g. $FF (assemblers)
• h suffix, e.g. FFh (assemblers)
• #..h suffix/prefix, e.g. #FFh (HP48/49/50)
• NNNN₁₆, i.e. subscript 16 (math notation)

Octal

• 0 prefix, e.g. 0377 (C, C++, assembler)
• 0o prefix, e.g. 0o377 (Python)
• 0q prefix, e.g. 0q377 (assemblers)
• o suffix, e.g. 377o (assemblers)
• q suffix, e.g. 377q (assembers)
• #..o suffix/prefix, e.g. #377o (HP48/49/50)
• NNNN₈, i.e. subscript 8 (math notation)

Binary

• 0b prefix, e.g. 0b0101 (C23, C++14, Python, assemblers)
• b suffix, e.g. 1111b (assmebers)
• #..o suffix/prefix, e.g. #377o (HP48/49/50)
• NNNN₂, i.e. subscript 2 (math notation)

Issues for RPN83P

The existing solutions (above) can pose UI/UX problems if implemented directly on the RPN83P:

• lower-case letters cannot be entered on TI calculators, unless specifically enabled by the app
• even when enabled, it takes an extra ALPHA keystroke, compared to capital letters which are the default
• capital O (oh) looks very similar to numeral 0
• capital B can be mistaken for the numeral 8
• the # character is not available on the TI calculator keyboard
• the TI calculator fonts do not support subscript characters

The C/C+/GoLang convention of using a bare leading 0 to indicate an octal number is probably considered by most people to be a mistake. It is difficult to remember because octal numbers are not used often, and this can lead to unintended bugs in code. I think most modern languages have decided to use a different notation, for example, an explicit 0o or 0q prefix instead of a bare 0.

Even when perform numerical calculations on calculators, instead of writing code, it is sometimes more natural to enter a leading 0. For example, when a section of memory is dumped in hex format, it looks like 03 C3 71 02 .... Let's suppose we need to perform bitwise operations with these numbers as 16-bit integers. It is convenient to be able to type in the numbers as written on the screen. In the case of this example, the two 16-bit hex numbers are C303 and 0271, assuming little-endian format. It is easier to allow the second number to be typed in exactly as displayed, with the leading 0, instead of forcing people to remember the leading 0 must be dropped for 271.

Proposed Solution for RPN83P

The internal character set in the TI-OS is a superset of the ASCII characters, with the addition of special math symbols and other specialized pictorial characters. But as far as I know, the TI-83/84 keyboard exposes only a few of the non-letter/non-digit characters through the ALPHA button:

• : colon
• " double-quote
• ? question mark
• space

It would be possible to expose additional characters through the RPN83P menu system, but the menu system is not convenient for quick access. It would be difficult to navigate to a specific menu button, while entering in a number on the keyboard quickly.

Given this limitation, I think the best we can do is use the : character as a base-number modifier to indicate that an integer is in a different base:

• 255:10 or simply 255 - decimal
• FF:16 - hex
• 377:8 - octal
• 11111111:2 - binary

Potential Implementation Issues

• the input parser must perform at least one more pass, to scan forward to check for the : character
• it must bind the : at a fairly high precedence, so that an integer can be a field separated by , in a Record date type (e.g. Date)
• inside a string delimited by ", the : and , characters must become part of the string, instead of being interpreted as a base-delimiter
• if this is implemented, then the : character cannot be used for any other expression. For example, a "range" expression could be something like "2:4", meaning something like "2, 3" or "2, 3, 4".
• only the 4 base numbers (:10, :16, :8, :2) will be supported. Any other sequence of letters or digits after the : should be a syntax error.
• we should probably allow the : modifier syntax outside of BASE mode, because sometimes we will start typing in a number before realizing that we have to go into theBASE menu
• since : is a suffix, we can no longer disable illegal digits in certain BASE modes. For example, we cannot disable A to F in BIN mode, because that would prevent hex numbers to be entered in BIN mode.

[diemheych]

Good idea. The colon reminds me of IPv6 :-)