Reminds me of this:
https://twitter.com/qikipedia/status/1584937832069484546
(a system devised by 13th century monks, for writing numbers 1-9999 each as a single glyph)
There are 113 symbols (7 rows of 16, plus 1 at the beginning)
There are 54 distinct symbols: 6 of them appear 4 times each, 3 appear 3 times, 35 appear twice, 10 appear once.
I was expecting this to be more useful... that there would be some subset of symbols that were obviously being used much more often because they represent vowels or whatever.
Ah, good catch about the relatively-few distinct symbols... that was actually because my image had a bug in it. Oooops.
Correct image is now at the top of the post.
Each symbol can be divided into 4 quarters. Each quarter has 4 different configurations. For the bottom right quarter those configurations look approximately like I, b, h, or L. Each quarter is independent of each other.
Thus each symbol contains 4^4 or 2^8 or one byte of information.
Putting together the observations from noggin-scratcher and Yair Halberstadt, could this be the expansion of some number like e or pi in base 256?
That was thinking of noggin-scratcher's comment about the monkly glyphs for 1-9999. I hadn't thought of their helpful analysis that there's only 54 symbols used across 113 symbols. I guess that even if this is somewhere on the right lines, the base must be something much lower, like 64.
In which case, given the 1st and 14th characters are the same, and the 14th character of pi in base 256 is 3, that's my leading guess, pending checking a few more glyphs.
Hmm. My guess was that the order from most significant digit to least significant digit was top left, bottom left, top right, bottom right; and that an absent stroke is 0, a line is 1, a curve is 2 and a loop is 3.
And it sometimes works! The third character is 0333 = (0*64)+(3*16)+(3*4)+(3*1) = 63. Which Wolfram Alpha tells me is the 3rd term in pi_256.
But it doesn't always work. That would make the 4th character 2221_4 = 166_10. But 4th character of pi_256 is 106 (=1222_4). Which is an anagram. But maybe that's just a coincidence.
Out of time to check more fully, but from the first few I think it works if a curve is 1 at the top but 2 at the bottom. (And straight lines vice versa.)
I have now checked through the whole top row of the expansion, and this does seem to be what's going on.
Each glyph represents a 4 digit base 4 number.
The digits are read in the order top left, bottom left, top right, bottom right.
An empty space off the central pole is always read as a zero.
A loop that comes from the centre of the central pole and joins to the top or bottom of the pole is always a three.
The horizontal bar and the curve coming from the centre of the bar (not re-joining, to distinguish it from the loop) vary in meaning depending on whether they are at the top or the bottom. At the top, the horizontal bar is two and the curve is one; at the bottom, the horizontal bar is one and the curve is two.
So, at the top we have a glyph representing 0003_4 = 3 (followed by a point).
Then the first few along the top row can be read off as:
0210_4 = 36_10
0333_4 = 63_10
1222_4 = 106_10
2020_4 = 136_10
And Wolfram Alpha can tell us that pi in base 256 starts:
3.36:63:106:136:133:163:8:211:19:25:138:46:3..._256
Having the strokes for one and two adopt inverse meanings top and bottom adds a little wrinkle to this as a puzzle, but otherwise as a design decision if one were semi-seriously thinking of this as a way of encoding information it seems to unnecessarily add to the thought needed to decode.
Also on design, I'm torn about whether the ordering of the parts is better or worse than top then bottom. The current design keeps the most significant parts on the left, which is mostly what we expect. But the overall presentation of the number is read across the page, left to right, so there could also be a case for having the order top-left, top-right, bottom-left, bottom-right.
The top half of a 2 might kinda look like the curve shape, and the bottom stroke of a 2 looks like a horizontal bar. So if there were partial characters hanging from the central pole, they might look a bit like those...
But... If it's that, the curve probably only works on the bottom right anyway. So if you're willing to mirror it for the bottom left, why not mirror to the top too?
And... That doesn't really explain the 1 parts anyway. They're just using "whichever part of a 2 isn't being used for 2".
So I guess this isn't a complete explanation.
Aha. For each side of the pole, you can write the binary representation of 4 bits vertically, and where there's a 1 you have a line joining it. The middle two bits both go to the middle of the pole, so they have to curve off upward or downward to indicate which they are.
So 2 is 0010, and you have no lines in the top half and one line representing the bottom of the middle, so it curves downward.
Whereas 4 is 0100, so it has the upward-curving middle-connecting line, and none in the bottom half.
Here’s something I’ve been playing with:
Explanation coming soon, but you may enjoy trying to figure it out on your own.
[EDIT 10-29: I initially uploaded an incorrect image, included below for posterity:]
