[r-t] Extension question

[Graham John]

On 6 November 2017 at 11:57, Don Morrison <dfm at ringing.org> wrote:

> Can you explain to me how you come to this conclusion? While to my mind it
> is an obvious extension, I sure can't figure out whether or not they are
> "officially" related, let alone whether or not that relation is unique. But
> that may simply be a failing of my understanding.

I agree that extension is difficult to get your head around, and even
more difficult to determine that you haven't missed anything. I have
come to look at this seriously only this year, and couldn't see how it
could be done reliably without computational support. Even then I
found it tough to encapsulate the rules in code.  Nevertheless, I have
done quite a bit of this now, so while I can't guarantee that I have
got it totally right, the results look reasonable. I have made the
results public in Complib, so anyone can look at the related Methods
section when displaying any method to see the candidate extensions,
together with accepted extensions where they have been named. There
are still some rules that I am not applying, either because it is
useful not to e.g. to show where a treble dodging method extends to a
differential at certain stages, or because I haven't figured out the
best way of coding it (e.g. the consecutive place rule). I am also not
showing methods with non plain bob leadheads at the moment, as the
rules seem a bit deficient in this area. Huge numbers of candidate
extensions are available and it seems to me that like plain bob
leadhead methods, there needs to be other leadhead groupings
established (such as cyclic leadheads) that give a tighter
relationship to a parent.

> Also, how do alliance hunt paths like this extend? I see nothing in decision
> (G) addressing that, though maybe I'm just missing something.

This is an interesting one. I found that if you just apply the rules
as you would to treble dodging methods, the algorithms still work
well. Different constructions can give alternative treble paths, and
by inspection you can see which ones give better results (e.g.
indefinite extension and more stages covered). As a result there is no
need
to specify or constrain how a treble path extends.

> In a related matter, why doesn't (G)B.7. require that 8ths be made
> adjacent to the treble twice in a half-lead rather than just once?

It depends upon the extension construction. The same place is retained
relative to treble only where that is the section replicated from the
parent.

> How do you know the hunt path expands

Answered above.

> Also, (G).C.2.(a)i. doesn't appear to have any entries corresponding to what
> the treble is doing in the last section in Semiquincentenary, so ...?

The treble is in 7-8, so it is section H. It doesn't say dodging in 7-8.

> And in related vein (G).C.1.(b) seems exceedingly vague about alliance methods:

Yes, probably because it is difficult to know whether the algorithm
would work in every case. In the case of Semiquincentenary, it seems
to work fine.


One of the things I was surprised about having coded up the algorithm,
is that it works surprisingly well; better than I had expected. I
found quite a few extensions that hadn't been rung which are
remarkably good matches to their parents, and given that there can
only be one extension candidate chosen for each name, having a lot of
other possibilities would make it even more confusing. We know that
there are lots of anomalies with previously named extensions, but I
believe that much of this has arisen because it has been so difficult
to know whether a newly devised method is related to an existing one,
and any algorithm is hard for most people to apply themselves to find
candidate extensions. By providing support for extension in Complib, I
hope that it is and will be continue to become much easier for people
to identify and check extensions for themselves.

Graham