Hexadecimal can be done with 4 bars, representing 4 bits, on the top right = one hexadecimal digit.
For four quadrants, we get 4 x 4 bits = 16 bits = 2 byte digit.
0-65,535 in one digit. A digit reduction by a factor of 4.
Just a byte could be represented by a half-height vertical line, with only left and right "quadrants". A lower case number!
And a 4 byte = 32 bit number could be represented with one digit, with vertical and horizontal main bars. I.e. 8 quadrants. One "digit", 0-4,294,967,295.
https://theconversation.com/shakespeare-by-numbers-how-mathe...
(As an aside, the western Arabic numerals we use today are quite different to the eastern Arabic numerals used in Arabic writing)
I guess this would always work with tally marks. Is there a more complex number system where visual feedback like this always works?
For a taste of this in Arabic numerals consider a 7 segment font, with 1 aligned to the left; we’d have “5+1=6”.
I also thought it was fun that when you overlay digits, you do get 1+4=5, 1+6=7, 1+8=9, 2+6=8, and 2+7=9 . That one I only found accidentally after a bit of playing, so the demo note is more of a fun side note than a really useful property.
This script overlays the marks, it doesn’t put them side by side. So, in the strict sense, this does not work with tally marks. If you write a tally mark on top of another tally mark, you won’t get two tally marks.
> Is there a more complex number system where visual feedback like this always works?
No. The “+1” operator would have to add the encoding for the number one to whatever number you apply it to, so starting at 1, the numbers would have to grow larger every time.
(Similarly, since “+2” must be identical to applying “+1” twice, it must add whatever “+1” adds twice, “+3” must do that thrice, etc)
Print requires a pre-composed set of glyphs with exceptions that are, I suppose, expensive (i.e., custom made by the printer). Typing right now on your computer, how easily can you create a custom glyph and share it? Look what the OP must do - stretch the bounds of typeface function, something few people are equipped to do.
If HN comments were hand written, each commenter could create custom glyphs on the fly. We could also draw diagrams and pictures, musical notation, draw lines pointing to different taxt from others - gloss each others comments.
Thinking about it (and wandering onto a tangent): If computers could process handwriting the same way as text encodings, would that be preferrable? I can't type as fast as I write but partly because I type far more. I could do so much more with a pen; it would be interesting to try. How well do LLMs handle handwriting recognition?
Also sometime it’s nice to express something for your own private enjoyment. Maybe it can spit also to something useful for the rest of the world here and there. But making this "predicted usefulness for the common" a requirement is depriving humanity of all this intimate joys and everything that can emerge from it.
On computers I haven't had the opportunity. When adopting new technology people commonly don't imagine the applications - even expert technologists, even those who developed the technology, often don't know.
> Would the added expressive power make up for the inconvenience of having to explain the meaning of the novel symbols?
It's a good question, but I could see definitions working efficiently in many situations. If the symbol is shorthand, it's easy to say 'the population of Hacker News P(H) ...', and it works well in mathematics, 'let Q be _____'. (These are imperfect examples because I can't create new symbols.)
Pretty well for neat modern handwriting, but much worse for cursive or messier writing. They also really struggle if the text is at an angle. I have some recent experience with a project where we tried to use LLMs to digitise handwritten specimen labels from the 19th and early 20th century, and the success rate was far too low to proceed with that approach.
Hallucination was also a common problem, with the output often replaced by a similar (but more common) name or word.
I’d assume you could improve the results by using a model trained specifically on handwriting data sets, grounding the model, or using existing purpose-built OCR tools - but frankly that’s above my pay grade.
Are there more efficient representations of numbers - or anything else - in terms of bits per glyph? The Cistercian numarals encode a bit over 13 bits per glyph, of course. Maybe forms of Chinese - though I think most words require 2 characters - or another ideographic language? But also is there anything with Cistercian cognitive efficiency? You can learn it in minutes.
I wonder why the didn't make 3 into F. They follow two other patterns for 3 then 4 glyphs: 3,4,5 have hypotenuses and 6,7,9 have the short parallel line. Also, they use other glyphs that approximately match Latin letters - e.g. 9 (P), 100 (L), 900 (b), 9000 (d) - so that wouldn't deter them.
There is "Background for Unicode consideration of Cistercian numerals" (https://www.unicode.org/L2/L2020/20290-cistercian-digits.pdf)
And also one in the Under-ConScript Unicode Registry for the Private Use Area (https://www.kreativekorp.com/ucsur/) (https://www.kreativekorp.com/ucsur/charts/cistercian.html)
> There is "Background for Unicode consideration of Cistercian numerals" (https://www.unicode.org/L2/L2020/20290-cistercian-digits.pdf)
That's the most complete summary I've seen so far, though I don't know if the author, Kirk Miller, has expertise in the area.
https://en.wikipedia.org/wiki/Chinese_numerals#Financial_num...
Specification: each cipher from 0 to 9 is using n+1 stroke, using only horizontal, vertical or left-bottom to right-top orientations. They also have distinctive traits that let them be identified even with only the very top or very bottom part. So 0 looks like / for example.
I also went above base 10 and made enough glyph to cover a sexagesimal base. The constraints on the drawing are then looser, so to go up to 20 we had a single "\". Incidentally and funnily enough that makes the 10th glyph look like a X. Then to get up to 40 glyphs, we simply square the 20 previous ones. And the plan to reach the 60 glyphs is to have a circled variation.
I’m not versed in the art of font crafting, but I would love to find someone to work in common on that one.
Here is a draft with the first steps for those interested:
https://commons.wikimedia.org/wiki/File:Alternative_cipher_n...