Excellent, I’ll look back at it when I find time to progress on my own pet project of custom numeral notation.
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:
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.
This is so neat.
Thanks for putting it together. A strange number system, but interesting.
It would be great if it could be done in Unicode.
I'm intrigued to know what it was used for.
They're not tally marks, it's just a different way of encoding a positional number system representation. You would get the same effect if instead of writing zeroes you left empty spaces. 2_4 + 1_3_ = 1234. If you were writing in columns you would not need the additional glyph.
> I guess this would always work with tally marks.
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)
I've thought, in other contexts too, how much easier innovation in script (in writing, glyphs, etc.) is when handwriting instead of printing text. Anyone could create their own Cistercian shorthand - and Medieval writers did use all sorts of shorthand.
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?
You could just provide a canvas to draw on and share images instead of strings of characters. If you restrict it to just black and white, and crop to only the used area, it would probably compress reasonably well, but then you'd also have to deal with the fact that some people have awful handwriting, writing with a mouse is hard (I'm particularly awful at it, being a left-handed person who uses a mouse with my right hand. If I need to draw into a computer, I have to get my drawing tablet out of a drawer), you can't paste into google translate for people writing in foreign languages etc
How many times in your life have you needed to create a new a glyph? Would the added expressive power make up for the inconvenience of having to explain the meaning of the novel symbols?
> How well do LLMs handle handwriting recognition?
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.
The glyphs are really facinating; thank you. Has anyone proposed Unicode code points for them?
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.
Fun fact: Chinese has separate "financial numerals" precisely to prevent one digit being changed to another, the way that could be easily done with regular numerals like turning 一 (1) into 三 (3) or 十 (10). A lot harder when they look like 壹, 叁, and 拾 instead.
Another fun fact: German registration plates use a font for which it is difficult to change one digit to another, for example by adding a bit of tape. The font is called FE-Schrift.
https://en.wikipedia.org/wiki/FE-Schrift
Excellent, I’ll look back at it when I find time to progress on my own pet project of custom numeral notation.
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...
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.
This is so neat. Thanks for putting it together. A strange number system, but interesting. It would be great if it could be done in Unicode. I'm intrigued to know what it was used for.
> Sometimes (not always), this makes addition visual
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”.
They're not tally marks, it's just a different way of encoding a positional number system representation. You would get the same effect if instead of writing zeroes you left empty spaces. 2_4 + 1_3_ = 1234. If you were writing in columns you would not need the additional glyph.
> I guess this would always work with tally marks.
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)
I've thought, in other contexts too, how much easier innovation in script (in writing, glyphs, etc.) is when handwriting instead of printing text. Anyone could create their own Cistercian shorthand - and Medieval writers did use all sorts of shorthand.
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?
You could just provide a canvas to draw on and share images instead of strings of characters. If you restrict it to just black and white, and crop to only the used area, it would probably compress reasonably well, but then you'd also have to deal with the fact that some people have awful handwriting, writing with a mouse is hard (I'm particularly awful at it, being a left-handed person who uses a mouse with my right hand. If I need to draw into a computer, I have to get my drawing tablet out of a drawer), you can't paste into google translate for people writing in foreign languages etc
How many times in your life have you needed to create a new a glyph? Would the added expressive power make up for the inconvenience of having to explain the meaning of the novel symbols?
> How well do LLMs handle handwriting recognition?
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.
The glyphs are really facinating; thank you. Has anyone proposed Unicode code points for them?
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.
> Has anyone proposed Unicode code points for 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)
In a high trust environment, I suppose easy addition is helpful. Probably not best used in loan agreements.
Fun fact: Chinese has separate "financial numerals" precisely to prevent one digit being changed to another, the way that could be easily done with regular numerals like turning 一 (1) into 三 (3) or 十 (10). A lot harder when they look like 壹, 叁, and 拾 instead.
https://en.wikipedia.org/wiki/Chinese_numerals#Financial_num...
Another fun fact: German registration plates use a font for which it is difficult to change one digit to another, for example by adding a bit of tape. The font is called FE-Schrift. https://en.wikipedia.org/wiki/FE-Schrift
Neat, you made me one of the 10 thousand today.
scnr 9900