+- The Voynich Ninja (https://www.voynich.ninja)
+-- Forum: Voynich Research (https://www.voynich.ninja/forum-27.html)
+--- Forum: Analysis of the text (https://www.voynich.ninja/forum-41.html)
+--- Thread: Deconstructing the VMS : A positionless ledger (part 1) (/thread-6040.html)
RE: Deconstructing the VMS : A positionless ledger (part 1) - oshfdk - 26-08-2026
I'm not sure what I'm talking about. What I initially assumed when talking about cycles was "a path through a structure that returns to the starting node". These obviously are present in the ledger. Then I thought maybe it's about repeating the same sequence verbatim many time. While it's possible to avoid this up to a certain limit, still it is possible to achieve this with the ledger. So, I have no idea what Dunsel meant specifically by "the ledger itself doesn't have cycles". So, back to square 1, I have no idea what this means.
RE: Deconstructing the VMS : A positionless ledger (part 1) - Dunsel - 26-08-2026
(26-08-2026, 08:52 AM)Jorge_Stolfi Wrote: You are not allowed to view links. Register or Login to view.If the ledger can generate infinitely many strings, it must have a cycle. That's because a set of infinitely many words must have arbitrarily long words. If a finite state automaton with N states generates a word with N or more letters, it must go twice or more through some state. That means the automaton has a cycle. Then traversing that cycle M times generates a word that contains a substring that is repeated M times, for any M.
On the other hand, if the alphabet has N letters, it is possible to create a word with ~N^K letters that does not repeat any substring of K letters. These words are called "De Bruijn sequences". For example, with 10 letters one can create a text of a million letters that does not repeat any substring of 6 or more letters.
Ok, I guess I didn't quite understand your definition of cycles, and I've let my replies drift into territory I'm not actually claiming. I need to clarify.
Does the ledger have cycles? By itself, no.
Is it an FSM? By itself, no.
Could you use it to create an FSM with cycles? Of course. It's the inventory you could use to create an FSM. The inventory of letters and consonant/vowel structure in English is not an FSM. It tells you how words can be assembled. You could use that inventory and those constraints to construct an FSM.
The ledger is only one component. It isn't the production mechanism. It provides the constraint space for constructing words. The scribe is the other component and provides the rules for operating inside that space: what transition to choose, when to reset, when to stop, what to copy or what to mutate.
So could a procedure that simply walked the ledger's allowed transitions produce arbitrarily long strings? Sure. I could take English word rules and create one. But that's a property of a traversal procedure, not of the ledger or English rules. Like English, the scribes clearly weren't just blindly walking every available transition.
A De Bruijn sequence, as I understand it, would just be one possible mathematically defined way of traversing the set of transitions. The scribes had their own method.
That's the part I've been trying to get at:
The ledger is only half of the rule system. The scribal policy is the other half.
RE: Deconstructing the VMS : A positionless ledger (part 1) - Jorge_Stolfi - 26-08-2026
(26-08-2026, 01:03 PM)Dunsel Wrote: You are not allowed to view links. Register or Login to view.So could a procedure that simply walked the ledger's allowed transitions produce arbitrarily long strings? Sure. I could take English word rules and create one. But that's a property of a traversal procedure, not of the ledger or English rules. Like English, the scribes clearly weren't just blindly walking every available transition. ... The ledger is only half of the rule system. The scribal policy is the other half.Any FSA can be used indifferently as a string generator or a string validator. The "language" of the FSA is the set of all strings it can generate, which is the same as the set of all strings that it will accept.
So you are saying that your ledger aims only for maximum "coverage" of the VMS text, not maximum "precision". That is, you care only that its language L contains all the strings of glyphs that occur in the VMS text without spaces. You don't care about how many strings are in L that do not occur in the VMS.
That makes the ledger less interesting than other models that account for spaces and try to balance coverage and precision, like slot grammars and the early FSA models. The VMS text has many errors that create single-occurrence word types with unusual digraphs, trigraphs, etc. Transcription errors add to that. By trying to include those weird words, the ledger ends up accepting a lot more than it should. Thus the ledger will not tell many constraints that are almost certainly true, like "a word can have at most one gallows" and "there cannot be a d between two ch".
All the best, --stolfi
RE: Deconstructing the VMS : A positionless ledger (part 1) - Dunsel - 27-08-2026
(26-08-2026, 04:26 PM)Jorge_Stolfi Wrote: You are not allowed to view links. Register or Login to view.Any FSA can be used indifferently as a string generator or a string validator. The "language" of the FSA is the set of all strings it can generate, which is the same as the set of all strings that it will accept.
So you are saying that your ledger aims only for maximum "coverage" of the VMS text, not maximum "precision". That is, you care only that its language L contains all the strings of glyphs that occur in the VMS text without spaces. You don't care about how many strings are in L that do not occur in the VMS.
That makes the ledger less interesting than other models that account for spaces and try to balance coverage and precision, like slot grammars and the early FSA models. The VMS text has many errors that create single-occurrence word types with unusual digraphs, trigraphs, etc. Transcription errors add to that. By trying to include those weird words, the ledger ends up accepting a lot more than it should. Thus the ledger will not tell many constraints that are almost certainly true, like "a word can have at most one gallows" and "there cannot be a d between two ch".
All the best, --stolfi
Voynich words are not assembled arbitrarily. Their internal transitions obey a restricted, reusable construction system, and that system can be represented by the ledger.
And that is all I am claiming the ledger is.
There is no efficiency that needs to be optimized, no precision target, and no claim that the ledger is a complete computational model of Voynich text production. It is simply a set of very simple rules describing how words could have been constructed and allowing existing words to be validated against those rules. The ledger defines those available construction rules. It does not claim that every permitted combination was actually used, that every permitted word was equally likely, or that the scribes mechanically traversed every possible path. Those are separate questions about scribal behavior, not about the construction rules themselves.
The rules themselves are quite literal.
- You cannot use H as a midfix after D.
- You can use CH as a midfix after D.
- You can use Y as a word suffix when the preceding letter is D.
- You cannot use A as a word suffix when the preceding letter is D
Find any non-suffix letter in a word in the prefix column and it will tell you which letters were used as midfix and suffix after that letter.
Those are the kinds of rules the ledger records. These are not invented rules I'm trying to persuade anyone into believing. These are the actual rules the Voynich uses. The ledger is built from the Voynich. I am not proposing a model or a generator. I am not making a claim about cycles. I am not proposing an nBits model. I am describing a set of basic construction rules that constrain the sequences of letters found in Voynich words.
Could it be turned into a generator. Very likely, but an entire host of line preferences, page preferences, word length rules and weighting would need to be added in order to do so. I am not there yet so I only claim what's above.
I may have gotten off track in earlier posts trying to understand the questions and explain how this ledger works and I apologize for that. You'll forgive me, I'm not an academic.
This is what I can defend and nothing more.
RE: Deconstructing the VMS : A positionless ledger (part 1) - Jorge_Stolfi - 27-08-2026
(27-08-2026, 10:38 PM)Dunsel Wrote: You are not allowed to view links. Register or Login to view.It is simply a set of very simple rules describing how words could have been constructed and allowing existing words to be validated against those rules. The ledger defines those available construction rules.
I understand that. My point is that the rules defined by your ledger are only a subset of the actual rules.
Apparent actual rules include "there can be at most one gallows per word", "there can be at most three of {ch,sh,ee} per word", "there cannot be a d between two ch in the same word", "the in,iin,iiin can only occur at the end of a word", and many others.
Does your ledger impose those restrictions? If the Scribe used your ledger as a "spell checker" while writing, could he write the words "iindy", "chdch", "okydoky", "chochochychy"?
Anyway, when building the ledger you should exclude any word type that occurs only once in your sample. Maybe exclude even any short word type that occurs only 2 or 3 times. They are likely to be errors (by the Author, the Scribe, or the Transcriber).
If you include those unique or almost-unique words, and they are errors, your ledger may end up allowing transitions that never occur in any correct word. If you exclude them but they are correct, it probably will not make any difference, because the transitions in those words will probably occur in other words.
All the best, --stolfi
RE: Deconstructing the VMS : A positionless ledger (part 1) - nablator - 27-08-2026
I'm still trying to understand why so many possibilities. For example: where is suffix a after ch if hapax are excluded?
RE: Deconstructing the VMS : A positionless ledger (part 1) - Mauro - 31-08-2026
(24-08-2026, 01:31 PM)Dunsel Wrote: You are not allowed to view links. Register or Login to view.(24-08-2026, 07:12 AM)oshfdk Wrote: You are not allowed to view links. Register or Login to view.How is this different from a slot grammar? If treated as a slot grammar, how does this ledger score against the existing slot grammars in Mauro's metric? Most likely this question is about the full version of the ledger with gallows, etc, because the metric measures the efficiency in reconstructing the full text, which requires a nearly 100% coverage.
Ok, couldn't sleep last nite so I dug into your question. I was vaguely aware of Mauro's work but hadn't really examined it. So here's some preliminary results as I understand his work:
This ledger is basically a conditional slot grammar rather than a conventional slot grammar: the the next letter in a word depends on the glyph immediately before it. I had to force it into a finite slot-style implementation so that Mauro's coverage/efficiency metric could be applied.
Every slot grammar can become a 'conditional slot grammar', i.e. by adding transition probabilities. Indeed I did exactly that when I wrote my asemic pseudo-Voynich generator. A slot grammar becomes a Markov chain (and with enough states and transitions a Markov chain can arbitrarily approximate any text in any language).
(24-08-2026, 01:31 PM)Dunsel Wrote: You are not allowed to view links. Register or Login to view.With gallows retained it covered 100% of the 8,424 RF1a-n types tested (the transcription Maro used) and generated about 7.82 billion possible forms, giving an efficiency of 1.08×10⁻⁶. For comparison, Mauro's EXTENDED-12 covers 88.45% while generating 6.12 billion forms, with efficiency 1.16×10⁻⁶. So the two have almost identical efficiency, but the ledger reaches full coverage.
However, my metric does not use efficiency, because it's unsound, as I demonstrated (as is the "F1 score"). It uses Nbits/Ncoverage, the amount of compression which is achieved by treating the VMS as being generated by the slot grammar. This metric is, instead, sound. To get this metric you first need to parse the VMS text into 'chunks' (ie.: 'qok', 'aiin', 'd') using your ledger (I don't know how), then use the chunks dictionary to compress the text (one symbol for each 'chunk'; I used variable-length encoding for the symbols, but fixed-length should work too and is less anachronistic).
(24-08-2026, 01:31 PM)Dunsel Wrote: You are not allowed to view links. Register or Login to view.Stripping gallows (which I will explain my reasonings for this in the next post) makes a huge difference. The ledger still gives 100% coverage of the stripped vocabulary, but the generated space falls from 7.82 billion to about 337 million. Efficiency improves about 15-fold, to 1.65×10⁻⁵. Mauro’s EXTENDED-12 is 1.16×10⁻⁶ at 88.45% coverage.
So the stripped ledger has full coverage and roughly 14 times Mauro’s efficiency.
But here you're comparing apples and oranges. The coverage of the full text with your ledger (without gallows) is much lower than the coverage of my EXTENDED-12 (which, by the way, is an obsolete grammar since much improved upon). Or, alternatively, you should compare with other grammars where gallows have been stripped too.
In case you want to know more about my metric, you can read here:
You are not allowed to view links. Register or Login to view.
RE: Deconstructing the VMS : A positionless ledger (part 1) - Dunsel - 01-09-2026
(31-08-2026, 01:12 PM)Mauro Wrote: You are not allowed to view links. Register or Login to view.But here you're comparing apples and oranges. The coverage of the full text with your ledger (without gallows) is much lower than the coverage of my EXTENDED-12 (which, by the way, is an obsolete grammar since much improved upon). Or, alternatively, you should compare with other grammars where gallows have been stripped too.
Again, I retract any comparison to your method or any claim that this is some 'grammar'. It is not. It's an accurate method built on the Voynich for determining which letter can legally follow another letter in the midfix or suffix position. That and nothing more.
RE: Deconstructing the VMS : A positionless ledger (part 1) - Dunsel - 01-09-2026
(27-08-2026, 11:08 PM)Jorge_Stolfi Wrote: You are not allowed to view links. Register or Login to view.I understand that. My point is that the rules defined by your ledger are only a subset of the actual rules.
Exactly.
(27-08-2026, 11:08 PM)Jorge_Stolfi Wrote: You are not allowed to view links. Register or Login to view.Apparent actual rules include "there can be at most one gallows per word", "there can be at most three of {ch,sh,ee} per word", "there cannot be a d between two ch in the same word", "the in,iin,iiin can only occur at the end of a word", and many others.
Does your ledger impose those restrictions?
No, there are no rules in the ledger other than what letters can follow another letter. Just as I demonstrated with the Finnish ledger. The ledger only shows what letters are attested as following other letters in the midfix and suffix positions.
(27-08-2026, 11:08 PM)Jorge_Stolfi Wrote: You are not allowed to view links. Register or Login to view.If the Scribe used your ledger as a "spell checker" while writing, could he write the words "iindy", "chdch", "okydoky", "chochochychy"?
If the ledger allows it then yes. But, the scribe didn't just invent words out of thin air just as Finnish doesn't keep repeating umlauts forever. The Finnish ledger shows that ÖÖ occurred in the observed text at least once. It doesn't mean they said ÖÖÖÖÖÖÖÖÖÖ is a word. There were other rules they used that restricted such words. If you consider copy and mutate then the ledger would only be needed to tell them that changing chody to chory would be a valid word because somewhere else, r followed an o as a midfix.
(27-08-2026, 11:08 PM)Jorge_Stolfi Wrote: You are not allowed to view links. Register or Login to view.Anyway, when building the ledger you should exclude any word type that occurs only once in your sample. Maybe exclude even any short word type that occurs only 2 or 3 times. They are likely to be errors (by the Author, the Scribe, or the Transcriber).
Of course. In the OP, that ledger excludes all hapax and all gallows tokens. It's purpose was to build the ledger using core words that kept getting reused. The 'rare' midfix transitions reflects that 2 or 3 times word count.
(27-08-2026, 11:08 PM)Jorge_Stolfi Wrote: You are not allowed to view links. Register or Login to view.If you include those unique or almost-unique words, and they are errors, your ledger may end up allowing transitions that never occur in any correct word. If you exclude them but they are correct, it probably will not make any difference, because the transitions in those words will probably occur in other words.
And you are correct. We all know that there are transcription errors. But how do you distinguish between what looks like an error and words like dydydy which apparently isn't an error? In this initial build of the ledger the only 'safe' option is to include everything and then see where the outliers are. If I arbitrarily set rules to exclude this or that, then I'd have objections that I'm not creating an accurate ledger. So, if I do include them, I shouldn't and if I don't include them, I should. How do I win that argument?
RE: Deconstructing the VMS : A positionless ledger (part 1) - Dunsel - 01-09-2026
(27-08-2026, 11:43 PM)nablator Wrote: You are not allowed to view links. Register or Login to view.I'm still trying to understand why so many possibilities. For example: where is suffix a after ch if hapax are excluded?
It comes from cha, which occurs twice in Scribe 1, at You are not allowed to view links. Register or Login to view. and f42r. I'm using the Takahashi transcription.
So it is not a Scribe 1 hapax and is not removed by the hapax exclusion. It is classified as a rare form in the ledger, not core.
That gives the rare suffix transition CH → A: 1 type, 2 tokens.