5

Some years ago I had read an interesting article about how much information chinese people could put in one tweet of 140 characters. But I cannot find again this article.

I'm interested in having numbers to compare how much more information can be encoded with fewer signs/characters, like in Chinese, and Korean.

Do you know of a thorough study (maybe statistics?), or in which direction should I search: Is there a field in semantics that goes in this direction ?

e.g. in Chinese: 6 sinograms 中囯大, 日本小 can encode the same information as 22 latin letters in English China is big, Japan is small or even 31 in French La Chine est grande, le Japon est petit

I have tried to search things about "Semantics Density in Chinese" on google, but search results were not obvious.

I'm also interested in Korean, because the accumulation/contraction of syllables to make words/signs feels similar in the end to a ready-made chinese sinogram (it's my feeling, I have only learned some very limited beginner notions of Korean).

I would like these numbers so as to illustrate the interest of a computer programming language based on signs and symbols, so as to convey as much information as possible for the reader/programmer.

7
  • There is the basic information theory: a letter/interpunction char has ca 32 possibiltiies, ²log 32 = 5. A sinogram bears more information. Then the information that is actually conveyed etcetera.
    – Joop Eggen
    Feb 1, 2019 at 15:47
  • 2
    To expand upon the comment above, typing a Korean character usually takes 2 or 3 keystrokes (sometimes up to 5), and in a typical text editor (such as vim) it will take the same space of two Latin characters (otherwise it will look horrible and barely readable). So, if your hypothetical language uses Korean characters, you need to at least double the "information density per character" to break even.
    – jick
    Feb 1, 2019 at 17:29
  • 3
    As for your end goal, you might want to look at research into APL and J (a later language which started off as APL in ASCII), and into East Asian teaching languages like ドリトル.
    – abarnert
    Feb 1, 2019 at 21:41
  • 3
    Oh, also Chinese Applesoft Basic, or whatever it was called. As a kid, I had an Acer clone with a switch between "Apple ROM" and "Chinese", and, despite not knowing Chinese, I played with Chinese mode a lot. From what I remember: Basic keywords are one character (although it often takes 2 Cangjie keystrokes), although stored in memory as the same 1-byte token used in Applesoft. Variables can only be one character (2 keystrokes, and 2 bytes in memory); presumably that's often sufficient for meaningful names. Anyway, it looks something like "入 卜; 印 卜" instead of "INPUT X; PRINT X".
    – abarnert
    Feb 1, 2019 at 21:54
  • 1
    I looked for info on Asian programming languages like ドリトル and Chinese BASIC, but as far as I can tell, nobody ever promoted them for their information density, only for "you can learn programming without learning English" benefits. Which I guess makes sense. But just because I didn't find anything doesn't mean that it isn't out there.
    – abarnert
    Feb 2, 2019 at 0:45

2 Answers 2

4

I don't know of a study on the question you're asking, but I do have some information to add—and possibly a better way to approach the X in your XY problem.


First, let's look at your example:

in Chinese: 6 sinograms 中囯大, 日本小 can encode the same information as 22 latin letters in English China is big, Japan is small

The number of sinograms in an average literate Chinese native is somewhere in the ballpark of 8000, while English only has 26 letters (plus a few symbols, in both cases, but let's ignore symbols and spaces, as you already have). This means that, in information theoretic terms, each sinogram represents about 13.0 bits, each letter about 4.7. So we're really talking about 78 bits vs. 103 bits here, which is not nearly as dramatic as 6 vs. 22 characters.

Presumably the total information is important to production and processing costs. You can see this in other ways, too—the sinograms have much more relevant visual detail; it's presumably more costly to distinguish "大" from "小" than "g" from "l". This also means that people often double-width characters and/or larger fonts for reading Chinese on the screen.

Meanwhile, Chinese writing tends to be more ambiguous than Latin writing. Partly this is inherent to the way Chinese writing is used,1 But also, there aren't enough sinograms in common use to avoid homographs and other forms of ambiguity as much as English orthography does. For example, "中国大" can also mean "Chinese University", while the English string "China is big" obviously can't. This is presumably not an accident: Chinese writing strikes a pretty good balance for writing Chinese (and Japanese and Korean), but the same balance probably isn't right for a programming language.

So, I think your intuition may be misleading you here. It's still worth looking for research into the information density of the two orthographies (which, again, I don't have), but I don't know that it will tell you as much as you think it will.


Meanwhile, since your actual goal is to produce a "computer programming language based on signs and symbols", you may be better off looking at programming languages in the first place, instead of trying to draw analogies with natural languages.


Starting close to where you're already looking, there's Chinese BASIC, a family of variants of Applesoft BASIC using Chinese instead of English characters.

In Applesoft BASIC, each BASIC keyword is stored in-memory as a single-byte token, but displayed, and entered, as a word like "PRINT" or "INPUT". Variables can be as many letters as you want, but only the first two characters are significant.

In Chinese BASIC, each keyword is displayed and entered as a single sinogram like "印" or "入". That obviously takes a lot less room on the screen than 5 letters, and is arguably easier to process. And, while you only have a few hundred sinograms for variable names, you can still pack in a lot more useful information than 2 letters can—especially since there are good variable names beginning with most of those sinograms, but not many good variable names beginning with, say, "QX".

This is purely anecdotal, but as a kid who didn't even speak Chinese, I flipped my Acer switchable Apple ][ clone over to the Chinese ROM quite often. In part that was about saving keystrokes,2 but being able to find a character that looked like what it meant while only taking up less valuable real estate (remember, this was a 40x24 screen) was also definitely part of it.


But I think you'll find more research around Ken Iverson's language APL.

APL added custom symbols for operators and functions. This allowed people to use actual mathematical symbols like ÷ instead of having to map them to whatever's lying around in ASCII, but it also allowed a much larger number of operators and functions to be written as a single symbol. And adding the idea of "inflections" (which roughly parallel written Japanese verbs, written with a kanji root followed by zero or more kana) allows a huge number of things to be written with just a couple of symbols. For example, things that would take a nested for loop in FORTRAN may just take an extra / character in APL. The Wikipedia article has some good examples (picking 6 lottery numbers with x[⍋x←6?40], finding primes in quadratic time with (~R∊R∘.×R)/R←1↓ιR, etc.).

APL was mainly about array processing. Another way to make languages terser comes from functional programming. John Backus's language FP had similar single-symbol, non-ASCII operators for composing functions, lifting functions, etc., allowing what in modern terms is called point-free style.

Obviously this terseness has costs in comprehensibility, not just benefits. But let's pretend it's pure benefit. How much of that benefit comes from the extra symbols?

A later language by Iverson (and Roger Hui), J, merges APL and FP into a single language, giving you array-processing and functional conciseness and convenience in a single language. But J dropped APL's symbols. The most common operators and functions are a single ASCII character, but the rest are two characters. To make this work, they added a lot more inflections. Adding / to any symbol still means to fold that symbol's function, but you can also add, e.g., :, with a meaning that extends the symbol in a way that's only quasi-regular. (For example, =: turns equality into assignment, while /: turns folding into sorting.)

I don't know how much research went into making this decision. I don't even know why it was made—whether Iverson believes J is easier to comprehend, or that it's a bit harder but still a good tradeoff (so much easier to input, transmit over ASCII channels, typeset for printing, etc.). But there's probably a lot of information out there if you search for it.


1. It's why the same string can represent a Mandarin sentence, a Cantonese sentence, and even almost a Japanese sentence (it's missing particles and inflection, but a Japanese reader could easily get "China big, Japan small" out of that).

2. Computers like the Sinclair ZX81 and calculators like the HP 48S let you enter a full keyword with two keystrokes. The Apple ][ made you type all five letters and a space, but in Chinese mode, you could enter "印" as two keystrokes (using the Canjie input method), just like a Sinclair or HP.

14
  • On further thought, if this is a good answer to the question, the question probably belongs on some other SE site (not SO, but… maybe Programming?), possibly with a bit of rewriting first. I don't want to delete the answer and flag the question to be moved, but it might be worth writing a question about research into symbolic programming languages and posting it on another site instead of relying on a semi-off-topic answer on Linguistics.
    – abarnert
    Feb 2, 2019 at 3:53
  • IDEs for agda, coq and the like try to represent mathematical formulas closer to actual mathematical notation, with some success. IMHO, the fixation on sequential text is, in the age of hypertext, a red herring. IDEs already provide many visual programming features and grasping a big program without such tools is well difficult. And then just look at this page, it's full of color and illustration. By the way, Ruby is a language famous for syntax sugar, written by a Japanese, and recently rivaled by Elixir as far as syntax goes.
    – vectory
    Feb 3, 2019 at 19:17
  • With variable bitrate coding like UTF-8, you can have a bit string of variable length between 8 and 24 bits represent the better part of the whole english lexicon uniquely, or a string of 8 to 16b to represent 8000 chinese characters (of over 100,000; 4000 is a rough limit for literacy). "Text information density" is simply not well defined, is it? We do productively read on the word level, after all.
    – vectory
    Feb 3, 2019 at 19:34
  • @vectory Wolfram lets you display and even edit equations graphically, but for non-trivial edits to large equations people still usually drop down to editing the textual form. This may just be because programmers have a text habit that’s hard to break (but should be broken), but it may be because navigating around something that isn’t a square grid without leaving the keyboard is still a poorly solved problem. There’s probably research on that, which might help the OP, but I don’t know where.
    – abarnert
    Feb 3, 2019 at 21:06
  • @vectory There are also languages that let you go even farther, representing control flow as a visually-editable graph, but even children using (the Squeak one I forget the name of) as their first language who become proficient seem to end up pulling up the textual Smalltalk to edit the control flow, which implies that after 3 decades of research in visual programming, we still haven't had the breakthrough that will allow it to take off.
    – abarnert
    Feb 3, 2019 at 21:11
1

My question is really about Chinese vs. English, minimally. But the different valuable comments and the previous answer made me consider the problem differently.

Explained below, I arrive to a ratio between 1/7 and 1/2 when comparing Chinese and English.

That would make me states that the Chinese writing systems conveys between 2 and 7 more information than written English. I'm not sure if I can call this ratio "semantic density".

That can be a concrete example, an insight to express the power of existing meaning-oriented writting systems compared to existing phonetic-oriented systems.


First impression is that sheer information theory is much too large, in the sense that it explores all given possibility to encode information through one expression system (if I understood correctly). I prefer to restrict on existing and commonly used systems such as human languages.

The references to information theory however made me think about average length of words in languages, and how much words are needed to express a given information.

The numbers I have grasped so far are really rough approximations:

  1. from this link: average length of English words is 8.2

  2. from this link: most chinese words are 2 characters/signs long. But also those two estimations which differ greatly:

    • 100 Chinese signs = 170 english words
    • 170-210 Chinese signs = 100 English words

So we can roughly says:

  1. 100 * 2 = 200 chinese characters for 170 x 8.2 english words = 1400 => ratio 1/7
  2. 200 * 2 = 400 chinese characters for 820 english words => ratio 1/2

I'll try to refine those estimation. But I will use these numbers merely for illustration anyway. Because I'm sure I could be asked why I've chosen to base the core fundations of that programming language on 1-char signs.

These signs corpus has to be limited, because like Chinese, you have to know the signs so as to understand them. It's a real cognitive cost.

3
  • 1
    That last point is important—and also, you have to know how to enter the signs, and how to look them up in a manual (think of Chinese dictionaries sorted by stroke order and radical), and you have to be able to (rapidly and accurately) distinguish them visually, and so on. All of that is probably part of the reason Chinese has only a few thousand symbols instead of half a million, and everyday computational Chinese even fewer than newspaper Chinese (and earlier computational systems like Canjie had even fewer), and so on.
    – abarnert
    Feb 2, 2019 at 23:15
  • For the moment I rely on vim digraphs. But the issue of a more general input mechanism is a real subject. Feb 2, 2019 at 23:20
  • You have to make your measure dependent on time, not just space. Parsing a 7 letter word doesn't take longer and I'm biased to think it's even quicker. Whereas for space, the question should be how much differentiable info can be put in a 10pt square. Then you should wonder whether purely sequential layout were optimal for programming. As for spoken language, the lexicon is a different matter. There are only two hard problems in computer science, as they say, cache locality and naming.
    – vectory
    Feb 3, 2019 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.