Re: VMs: NSU review of Rugg (2003)...

[Gordon Rugg <g.rugg@xxxxxxxxxxxxxx>]

Dear Nick,

Good points. I'm happy to discuss my experiences of trying to hoax (and encode!)
the VMS and to share the information with the group so that we can generate some
testable hypotheses. Maybe a workshop/seminar would help? I could see about putting
something on at Keele.

A lot of the things I found are easy to demonstrate in person, but hard to describe
in writing. One thread running through my work was finding ways to break up
sequences (so that the same set of prefixes wasn't repeated in the same sequence in
different lines, for instance). There's a surprising number of ways of doing this
which don't take significantly more time and effort, but which would make life
pretty difficult for would-be decipherers. One simple example is table layout. One
of my trial tables was created as two sheets, one for the left half of the table
and the other for the right (originally for practical purposes, since this was
easier to file). It's no extra effort to generate some text with the two halves
swapped round, and that would cause real problems for anyone looking for
regularities within the line.

I agree with you that we need testable hypotheses, and here are two examples
arising from my experience.

1: I found that, when right-justifying text against a picture, there were times
when the word produced by the table and grille was too long to fit, even if I
cramped it. Since each word was generated on the fly, I couldn't budget space more
than one word ahead (let me know if that needs clarification). I then had three
options:
(a) leave a space
(b) abbreviate the word using an "m"
(c) generate a shorter word and use that instead.
Option (c) is compatible with a hoax, but not with a meaningful ciphertext.
So, if the VMS was generated on the fly by a hoaxer using table and grille in this
way, then we might expect to find that there was an unusually high proportion of
short words (excluding those ending with "m") right-justified against pictures.

2: When tired, and in the middle of a table, it's easy to mis-align the grille so
that the left cell exposes a suffix from the previous column rather than a prefix
(the illustration in the Nature article should make this clear). If you're tired,
it's easy to transcribe the contents of the left cell before realising the mistake.
This can't happen with the first word of the table, since there's no previous
suffix.
So, if the hoaxer used a moving grille, rather than a large grille that generated
an entire line in one go, then we might expect to find a higher proportion of words
beginning with "y" and "dy"etc  in the middle of lines than as the first word of a
line.

These are both pretty specific hypotheses, and depend on quite a few assumptions
about the precise mechanism, but they are examples of how we could start reducing
the problem space.

Best wishes,

Gordon

Nick Pelling wrote:

> Dear Gordon,
>
> At 16:42 18/12/2003 +0000, Gordon Rugg wrote:
> >We may be at cross-purposes here. I think that the tables (if this method
> >was used)
> >can probably be reconstructed; however, I think that the appropriate
> >method for
> >this is not use of statistics and probability theory (which is what I
> >understood
> >you to be advocating). I'm hoping that some of the crypto people can
> >tackle this -
> >as I've said, it's not my field.
>
> As a crypto guy, I think it would be fair to say that it would take a bit
> more definition to operationalise your paper into something testable - so
> would characterise it as still being at an early research stage.
> Cryptanalysis almost always comes down to a combination of intuition and
> brute force statistics, so stats and probability theory would always be the
> main tools for getting under the skin of a code - intuition alone is rarely
> sufficient.
>
> >As for the deliberate use of more than one table, there are several
> >reasons for
> >suspecting this. One is Philip Neal's observation that some pages look as if
> >they've been filled in as alternate lines for some reason.
>
> ...whatever that reason is (penmanship? stylistics? methodology? content?
> encoding?) But AFAICR, Phil doesn't claim that this is true for all pages
> (which would be false), but only for some. It might then be easier to
> restrict brute force searches to pages where palaeographic analysis can
> shown it be false. All the same...
>
> >Another is the pattern
> >of syllables if you set out VMS pages as a spreadsheet, removing dains and
> >first
> >lines - the impression that came through when I tried this was that there
> >were two
> >different tables involved, with noticeably different syllable
> >distributions (though
> >you could get the same thing from a single table with "bands" of different
> >syllables running through it - for instance, a few rows with lots of "qo"
> >prefixes,
> >then a row or two with "o" or "dy" prefixes).
>
> I'm not sure about this at all. I've certainly noted letter distribution
> differences at the paragraph level in the past, but not at the line level.
> Has anyone tested the statistical significance of letter distribution at
> the level of the line?
>
> One relatively straightforward way to doing so might be to determine
> whether, within any given paragraph, the letter distribution of the first
> half of a line is a better predictor of the second half of the line than
> the first half of the next line down. Towever, there are a few subtleties
> to address - ie, (1) how to handle unsampled characters, (2) whether to
> convert to glyphs first, (3) whether to pairify first, etc.
>
> So, I'm less interested in whether multiple tables (or trickily "banded"
> tables) could achieve this result than whether it actually exists or not -
> and whether it is more true in Language A, Language B, the recipe section, etc.
>
> >In terms of testable hypotheses, I'm putting forward the hypothesis that
> >something
> >with the features and complexity of Voynichese can be produced using
> >tables and
> >grilles. It had previously been claimed that the VMS was too complex to
> >have been
> >hoaxed, and I believe that this claim has now been disproved.
>
> I don't think you're quite there yet. Unless you can demonstrate a little
> more of the mechanics, you're giving a proof by anagram (where all the
> information is stored in your tables, and anagrammed to generate the VMs).
> Again, it's the <<accounting for all features>> criterion which it stumbles
> over.
>
> Cheers, .....Nick Pelling.....
>
> ______________________________________________________________________
> To unsubscribe, send mail to majordomo@xxxxxxxxxxx with a body saying:
> unsubscribe vms-list

______________________________________________________________________
To unsubscribe, send mail to majordomo@xxxxxxxxxxx with a body saying:
unsubscribe vms-list