Deconstructing the VMS : A positionless ledger (part 1)

[Dunsel]

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.