[r-t] Lead head codes

[Ian McCulloch]

On Thu, 13 Apr 2017, tuftyfrog at gmail.com wrote:

> The lead head code for a particular method serves two purposes, in that it specifies the order of the PB lead heads and indicates the place notation at the change from lead end to the lead head. 
> 
> Not entirely understanding the complex history that led to us denoting Plain Bob lead heads as we do today, and then not being sure why it is relevant anyway, it occurs to me that the system is poorly thought out. A better one
> would be as follows:
> 
> A method's code would be given simply by the number 1, 2,..., n-1 corresponding to which Plain Bob lead head it has, with the order given by Plain Bob as usual. This has the distinct advantage of being infinitely extensible with
> literally no effort whatsoever (unlike our current system) and also allows you to quickly calculate short touches of spliced using arithmetic modulo n, for example.

Yes, strong agree, that would be a much better system.

> 
> The lead end/head change can then be designated by a second character. Something like "a" for 12 and "b" for 1n would work. 

Why invent a new code for this?  The place notation is already short, wny 
not just use that?

> 
> The codes of the "standard eight" surprise major become:
> 
> CYNPS = 2a
> LR = 6a
> B = 6b

Or

CYNPS = 2,12
LR = 6,12
B = 6,18

Extend it a bit more to include the notation for a bob and single if 
required.  eg CYNPS = 2,12,14,1234

Maybe use negative numbers if the number is bigger than (stage-1)/2 ? LRB 
= -1 is probably more useful in practice, unless you are very good at 
doing modulo arithmetic in your head.

> 
> From this it's much easier to see that L, R and B are related by the same lead head order, despite having different lead end changes. This information is completely obscured using letters of the alphabet as we do currently. 
> 
> I have little to no hope that such a change of system would ever happen, though. We've been using the same classifications for so long that to change now would almost certainly be considered more trouble than it's worth. Ah
> well. 

Use whatever system you like.  The CC formalizes a system in their 
descriptions, but it is a baroque system, like most of the rules and 
decisions.  People are free to NOT follow it.  And when constructing 
software that utilizes the CC collections, translate the notation into 
something better.

I was intending to reply to Robin Woolley's earlier post, defending the 
(IMHO insane) rules that extensions to an odd number of bells require a 
second hunt bell, complete with bogus example.  The CC decisions on 
methods are a mishmash of historical legacies based on incorrect reasoning 
(eg the impression I got from reading historical minutes of the meetings 
is that the prohobition of methods that are false in the plain course is a 
result of a mistaken belief that such methods cannot generate a true 
extent) and incremental updates that are forced when it becomes no longer 
tenable to keep the old ways (or typically, a few years after it becomes 
no longer tenable...).  While the methods committee remain as gate-keepers 
for what constitutes a "peal" and what does not, there is going to be very 
little progress on new forms of ringing, because the perceived stakes are 
too big.

Cheers,
Ian