━━━ bradix ━━━━━
Braille-radix numbers
More consistent, less biased numeric notation.
Braille-radix numbers replace the usual radix point (.) with a braille code point that encodes the base of the number in binary.
Here is the value of each dot in a braille code point (the two highest-valued dots lie below the baseline, like descenders on letters):
1 8 2 16 4 32 ━━━━━━━ 64 128
And here are some numbers
- 12 345⠊678 9 (base 10⠊ / decimal)
- 12 345⠌678 9AB (base 12⠊ / dozenal)
- 12,345⠐678,9ab (base 16⠊ / hexidecimal)
- -1 1100⠂0101 0101 (base 2⠊ / binary)
Some things you can see in those examples
- spaces and commas are valid digit separators
- digits beyond 9 are represented with case-insensitive English letters (for now)
- negative numbers are prefixed with
-(and positives may be prefixed with+)
There are various notations for numbers in various bases.
Sometimes, we don’t need any annotation at all; other times there is a prefix, like 0x or b; and sometimes a decimal number is used to explicitly name the base, as in #12r17 (which is 19 (in decimal) written using base-12) or 17₁₂0 (which is the same, but written using the decimal representation of the base as the radix point.
However, each of these has problems. Leaving off the annotation can be ambiguous sometimes. When you see “17” you can be reasonably sure that the base is at least octal, but nothing tells you definitively what it is. Usually it’ll be decimal, but bare hex numbers aren’t uncommon in some contexts.
The issue with prefixes is that they’re arbitrary and don’t generalize. You just have to know that 0x indicates hexidecimal. Even with prefixes like #12r, it’s contextual that the 12 is decimal. And, why use decimal?
Instead, Bradix uses an ever-present radix point and tries to simplify it as much as possible. I considered a unary system, but it doesn’t have any sort of Unicode support, and it becomes hard to read. Wait … is there 12 dots there or 16? But binary – still representable using only dots, but much more compact. And it has a standard ordering of the dots and Unicode support. So, our bases in binary look like
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | … |
| ⠁ | ⠂ | ⠃ | ⠄ | ⠅ | ⠆ | ⠇ | ⠈ | ⠉ | ⠊ | ⠋ | ⠌ | ⠍ | ⠎ | ⠏ | ⠐ | ⠑ | ⠒ | ⠓ | ⠔ | ⠕ | ⠖ | … |
And the code points are in the correct ordering for this use case, so you can subtract “BRAILLE PATTERN BLANK” from the code point of your character to figure out the radix.
So 17⠌ is now clearly 19⠊.
bradix-parse extracts a Bradix-formatted number from a string. If you (require 'bradix-reader), then there is also a syntax extension that causes Bradix-formatted numbers prefixed by ⠼ (the braille numeric indicator) to be read directly as literals.
See bradix-tests.el and bradix-reader-tests.el for some examples.
We recommend the following steps to make working in this repository as easy as possible.
This command ensures that any work you do within this repository happens within a consistent reproducible environment. That environment provides various debugging tools, etc. When you leave this directory, you will leave that environment behind, so it doesn’t impact anything else on your system.
This will apply our repository-specific Git configuration to git commands run against this repository. It’s lightweight (you should definitely look at it before applying this command) – it does things like telling git blame to ignore formatting-only commits.
Especially if you are unfamiliar with the Emacs ecosystem, there is a flake-based Nix build.
This project offers an Eldev build.
Emacs has a built-in reader-syntax for bases from 2⠊–16⠊. However, it only works for integers.
It uses a prefix like #16r, which is written in base 10⠊. Bradix supports bases 0⠊–255⠊ (but there are currently some bugs related to the higher bases).