Curve-Line System - Bluetoes edition

[Mauro]

See, I'm hoping I missed the "After introducing the concept of ‘looping’ slot grammars" and that is why it sounds like Mauro is casting spells at me  . I may need to backtrack some to get a foothold into that, but I certainly will, just learning what an Nbit and LOOP-L (rappers?) is will help demystify things greatly.

I have the advantage of not being able to fully understand either your CLS or Mauro's grammars   So for me they look similar enough.

But as far as I understand, both systems identify certain Voynichese sequences as "conforming" and certain other sequences as "non conforming". And you seem to be using a metric, normally called "coverage", that tells how many of actual Voynichese words (from a particular page or the whole manuscript) are identified as conforming. Or how many are identified as non-conforming, which is basically a variant of the same metric.

However, coverage alone doesn't show how good a system actually is, because you can make a very flexible "anything goes" system, that would obviously have perfect coverage. So, there should be another metric, for example, "specificity", which tells us how many possible sequences a system can generate, whether attested in the MS or now. For a loop-like system, that can generate sequences of any lengths, we can talk about how many possible sequences up to length X the system can produce. Then using a combination of "coverage" and "specificity" you can argue which system better describes the text.

But then again, you can make a system that just lists all known Voynichese words, either explicitly (just making a list) or implicitly (via a long list of rules like "qo can precede t if t is followed by edy, unless it's followed by..."). This system would have a perfect coverage (all words present in the MS are listed) and a perfect specificity (only words present in the MS are listed). So, "coverage" and "specificity" might not be enough, there probably should be another metric reflecting how complex the system itself is.

Perfectly summarized.

As far as I understand this, Mauro has found a good answer to this by making a metric that shows how many bits it takes to encode the whole text and the grammar together. But this could be an overkill for a relatively simple system, maybe it makes sense to just start with understanding what the specificity of the original CLS and your version of CLS is. E.g., how many possible glyph sequences of length 3 can either system produce?

I think the ideal approach would be to use a compression algorithm which is not constrained in the set of possible chunks it can use but which can find the optimal solution nonetheless. Unfortunately I don't know how to do it: an exhaustive search is impossible (the search space is too big), or maybe a variant of Lempel-Ziv LZ78 could be used (but I'm no sure at all, LZ78 may even not guarantee optimality). The "slot grammars" approach was a (rather good, I think) workaround around this problem.

With an algorithm like that it would not matter much if one starts from a curve-line system or from EVA. In effect, a working algorithm should be able to pull toghether 'C's and '\'s into 'characters' (thus progressing on the transcription problem) and then 'chunks of characters' (thus progressing on words structure) in the most sensible way.

PS.: waiting for Bluetoes to post his curve-line model