Tony Smith's letter to the RW

[Don Morrison]

I'm afraid I was nearly a week late in reading last week's RW, so have only just noticed that Tony Smith sent a letter renaming someone's method from a peal recently published. I'm curious: was this discussed with the Methods Committee, or was Tony acting on his own? It all reads as rather official, which would naturally lead one to presume it was the handiwork of the committee, but he's no longer on it.

-- 

Don Morrison <d...@ringing.org>

"I like large parties. They're so intimate. At small parties there

isn't any privacy."    -- F. Scott Fitzgerald, _The Great Gatsby_

[David Richards]

Hi Don,

On 27 April 2017 at 17:12, Don Morrison <d...@ringing.org> wrote:

... Tony Smith sent a letter renaming someone's method from a peal recently published.

 I'm curious: was this discussed with the Methods Committee, or was Tony acting on his own?

The conflict of names was raised with the Methods Committee by Peter on Sunday 16th April having been notified by Tony.

Nobody on the committee could easily confirm or deny that the method was the unique extension of Bitteswell Surprise Major, but I think it was generally accepted that the new maximus method had similarities (i.e. it seemed plausible).

I think it's fair to say there was no conclusion drawn from the Methods Committee, so I was slightly surprised to see Tony's letter saying, effectively, it wasn't a subject for debate. Tony's point is that it is logical consequence of the Decisions as they stand. I'm not sure that statement has been independently verified yet (but similarly, I don't think anyone is particularly working to verify it).

I think that it would be helpful if the Methods Committee could provide mechanisms to alert bands to these potential conflicts before new methods are rung - especially to avoid situations like this where the method name was designed to be an aid to the ringing but is then immediately overwritten without hope of appeal by a rule which is difficult (or maybe impossible) for individuals to check.

I'm sure that Tony will say that he's always happy to consulted on proposed new methods and help identify potential pitfalls (and frequently does, as far as I understand), however, it seems a bit sad if that's the only way to reliably avoid conflicts.

Just on the last point:

On 27 April 2017 at 17:12, Don Morrison <d...@ringing.org> wrote:

It all reads as rather official

Well it is official in the sense that Tony maintains the CC methods collection from outside the Methods Committee. Or, to put it another way, the Methods Committee isn't currently presenting any collection which could be considered definitive.

Cheers,

Dave.

[Ian Partridge]

On 27 April 2017 at 17:12, Don Morrison <d...@ringing.org> wrote:

> I'm afraid I was nearly a week late in reading last week's RW, so have only
> just noticed that Tony Smith sent a letter renaming someone's method from a
> peal recently published. I'm curious: was this discussed with the Methods
> Committee, or was Tony acting on his own?

I'm curious how Tony was able to decide that he thinks the method is
an extension. Does he have software to assist?

Applying the current Decisions on extension to a maximus method in
reverse to produce a major method is non-trivial!

--
Ian Partridge

[Mark Davies]

Ian writes,

> I'm curious how Tony was able to decide that he thinks the method is
> an extension. Does he have software to assist?

Yes, he has told me that he does. I asked whether he'd be prepared to
share it, to which he replied:

"I do have a Java program that I use to help in investigating extensions
but it is unfortunately not yet in a fit state to be used without
knowledge of its strengths and weaknesses. I do have a list of planned
improvements and would like to get it to the point when it could be
shared with others who understand the Decision on Extension. In the
meantime I'm always pleased to answer questions about methods and
extensions (and often do so!)"

I think we need independent software to do this. Also the software
should be capable of implementing other extension algorithms - the
protocol currently embodied in the council Decisions is not the only way
of producing extensions.

Cheers
M

[Richard Smith]

Mark Davies wrote:

> I think we need independent software to do this. Also the software should be
> capable of implementing other extension algorithms - the protocol currently
> embodied in the council Decisions is not the only way of producing
> extensions.

When I read Tony's letter the other week, I set about
writing software to do this. It's written in C++ using the
Ringing Class Library, to which I'll probably add it once
I've done a little more testing.

RAS

[Ian Partridge]

On 28 April 2017 at 13:45, Mark Davies <ma...@snowtiger.net> wrote:
> Ian writes,
>
>> I'm curious how Tony was able to decide that he thinks the method is
>> an extension. Does he have software to assist?
>
> Yes, he has told me that he does. I asked whether he'd be prepared to share
> it, to which he replied:
>
> "I do have a Java program that I use to help in investigating extensions but
> it is unfortunately not yet in a fit state to be used without knowledge of
> its strengths and weaknesses. I do have a list of planned improvements and
> would like to get it to the point when it could be shared with others who
> understand the Decision on Extension. In the meantime I'm always pleased to
> answer questions about methods and extensions (and often do so!)"

Thanks Mark. I'd chuck it up on GitHub regardless but that's just me :-)

--
Ian Partridge

[Graham John]

On 28 April 2017 at 13:45, Mark Davies <ma...@snowtiger.net> wrote:

> I think we need independent software to do this. Also the software should be
> capable of implementing other extension algorithms - the protocol currently
> embodied in the council Decisions is not the only way of producing
> extensions.

It seems to me that the even the current algorithms require one to
generate vast numbers of extensions on indefinite stages, which then
have to be checked to see of they qualify to share the same name. This
is no trivial task.

and RAS wrote:

> When I read Tony's letter the other week, I set about writing software to do
> this. It's written in C++ using the Ringing Class Library, to which I'll
> probably add it once I've done a little more testing.

I am currently doing the same for Complib, so it will useful to cross
check results.

Regards,

Graham

[Richard Smith]

Graham John wrote:

> On 28 April 2017 at 13:45, Mark Davies <ma...@snowtiger.net> wrote:
>
>> I think we need independent software to do this. Also the software should be
>> capable of implementing other extension algorithms - the protocol currently
>> embodied in the council Decisions is not the only way of producing
>> extensions.
>
> It seems to me that the even the current algorithms require one to
> generate vast numbers of extensions on indefinite stages, which then
> have to be checked to see of they qualify to share the same name. This
> is no trivial task.

I suspect it's worse than non-trivial. We don't even know
that it's possible. It might be computationally
undecidable, much like the halting problem.

Ignoring for a moment the fact that Tony has no authority to
make such pronouncements regardless of their accuracy, let's
consider what he is purporting to have done. It is easily
verified that Chogolisa S Max is a valid extension of
Bittleswell S Major according to the current Decisions; and
to my mind the methods are similar enough that this is not
one of the unreasonable extensions that the current
Decisions sometimes produce.

But Chogolisa is only required to be named Brittleswell if
it is the *sole* valid extension of Brittleswell S Major.
Is that actually the case? To be a valid extension, "the
relationship must cover an indefinite number of stages"
[Decision (G)B.1]. It seems accepted that "an indefinite
number" means an infinite number (specifically aleph zero),
but the extension relationship doesn't need to cover every
even stage: for example there are plenty of extensions that
are considered valid that only work on 4N bells, or that
don't work on certain particular stages because it is
differential there.

For a given method there will be hundreds of possible
extension rules. Some will be duplicates, some will be
ruled out because they fail to preserve adjacent places,
places next to the treble or the number of consecutive
blows, or become delight methods These eliminations are
easy: if they break on one stage they break everywhere.
But it still leaves scores of extension rules to check for a
suitable (i.e. regular, non-differential) lead head.
That's where it becomes difficult. Just because one
extension is irregular does not mean subsequent extensions
remain irregular.

Showing that an extension is valid is normally relatively
easy. You check the next few stages, observe that the
extension is working on sn+b bells for some particular s
(the step size) and b (the parent stage), and test the next
few values of n. In the case of Brittlewell k=2 and s=8,
and Tony has clearly tested n < 4, probably further. It's
clear from inspection of the methods that the extension will
work indefinitely, and a computer can reasonably assume that
if the extension works for (say) n < 6, it will continue
indefinitely. I can't prove that, and in fact I strongly
suspect that if b is large enough it is not true, but I'm
certain it's true when s <= 8 with palindromic methods where
the treble dodges once in each position.

But showing that an extension is not valid is much harder.
How many stages do you need to test before you give up
searchinf for an extension? I have no idea. I have
certainly found minor methods with extensions that work on
24n bells, and I suspect there are major methods that have
extensions with higher periods. Furthermore, it's quite
common to find the base method does not fit into the logical
extension series: for example, the base method might be on 6
bells while the extension works on 6n+4 bells.

Equally, there are extensions that work on a handful of low
stages and then never again. The traditional extension of
London is a standard example, but there are examples which
extend more than once before stopping. If I see an
extension that works on 6, 28 and 52 bells (and I have seen
such extensions), should I conclude it has worked randomly
on these three stages and will now stop, or that it's going
to work on 24n+4 bells? Or perhaps there could be some more
complicated type of pattern that I've never observed before.
I simply don't know; I have failed to prove any general
results of this sort, and I strongly suspect Tony has not
either, in which case he's basing his pronouncements on
conjecture and heuristics.

For a specific case it is generally possible to prove
whether or not an extension will ever work by carefully
studying it. But the process of "carefully studying"
something isn't an algorithm and can't be coded. This is in
the same way that a human can generally look at a piece of
code and decide whether it will halt, but it can be proved
that an algorithm cannot make this decision.

RAS

[Tim Barnes]

On Fri, Apr 28, 2017 at 9:58 AM, Graham John <gra...@changeringing.co.uk> wrote:

I am currently doing the same for Complib, so it will useful to cross
check results.

Good to hear both Richard and Graham are working on this.  Even if extension rules become advisory in the future rather than mandatory, it will be very useful to have this software available to analyze some possible extension and contraction paths for given methods.  It would also be interesting to know how many methods in the existing method collections don't meet the current extension rules, given that many methods were named prior to the extension rules being implemented.  (Although I've always had the impression there was a fair amount of reverse engineering involved in developing the extension rules -- i.e. here are existing families of methods, what rules would link them together?)

On Fri, Apr 28, 2017 at 11:27 AM, Richard Smith <ric...@ex-parrot.com> wrote:

But Chogolisa is only required to be named Brittleswell if it is the *sole* valid extension of Brittleswell S Major. Is that actually the case?

I also wondered this.  It may be more accurate to say "sole valid remaining extension of Brittleswell S Major".  There could be other extension paths, but the methods on these paths have already been given different names.  I believe it's only the last possible extension path that is required to use the parent's name, if a previous valid extension path didn't already use it.

I believe I've heard it said in the past that the MC uses stage 60 as a practical upper boundary for determining whether an "indefinite" relationship exists.  Leaving aside if and how that was arrived at, am I right in thinking that given an upper bound of 60, it would become possible to build an algorithm to verify that Chogolisa was in fact the last available (or only) extension path of Brittleswell?

Tim

[Richard Smith]

My extension code is working moderately well now, and I am
most amused to report that I think Tony is wrong.


Tony Smith (RW, p 365) gives an extension of Bitteswell S
Major and uses this to justify his assertion that Chogolisa
S Maximus, which was recently named in the impressive peal
in Worcester (p 342), must be renamed Bitteswell S Maximus.

I believe that Bitteswell S Major in fact has three families
of extensions that conform to the current Decisions of the
Central Council.

* Mode 2 FG over mode 6 HI works on 2N+8 bells, the first
extension being this Surprise Royal method:
&-3-4-2.5.36.4-4.3.6-6.5.6-6.5,2

* Mode 2 DEFG over mode 5 FGHI works on 8N+8 bells, the
first extension being this Surprise Sixteen method:
&-3-4-2.5.36.4-4.3.6-69.50.4-4.3.0-0A.5B.4-4.3.B-B.5,2

* Mode 2 DEFG over mode 5 EFGH works on 8N+8 bells, the
first extension being this Surprise Sixteen method:
&-3-4-2.5.36.4-4.3.6-69.30.4-4.3.0-0A.3B.4-4.3.B-B.5,2

The first of these is the extension Tony gave. I can see
nothing in the Central Council's Decisions to say the second
and third extensions are invalid. I accept that they seem
at first glance to be less attractive than the first family,
and if I were looking for a good extension of Bitteswell I
would likely choose the extension Tony gave, but the
Decisions do not say the best possible extension must be
chosen. How could they when which is best is subjective?

Nor do the Decisions say that an extension that works on
every even stage is better than one that only works every
eight stages. All three "cover an indefinite number of
stages", which is all Decision (G)B.1 require.

Decision (E)D.3(b) says:

Methods at different stages in the same type and class
that are uniquely related as in Parts A to D of the
Decision on Method Extension shall have the same name, and
where not uniquely related one relationship shall have the
same name.

There is no dispute that Bitteswell S Major and Chogolisa S
Maximus are related in this way, but unless I am mistaken,
Chogolisa S Maximus is not the unique extension of
Bitteswell S Major. The Decisions require that the methods
in one of the extension sequences are named Bitteswell, but
at the moment none of the methods in any of the extension
families has been rung. If the Worcester band wish to name
their method Chogolisa, I see nothing to prevent them from
doing so: two other extension families exist which can be
named Bitteswell. Equally, if they do want to rename their
method Bitteswell, that seems permissible under the Central
Council's Decisions too.


I gather this week's Ringing World is a little short on
content and they might still be amenable accepting a letter
for print on Friday, even though it is past the deadline.
But before I write a letter, is anyone able to verify that I
am correct re the two further extensions of Bitteswell S
Major?


RAS

[Tim Barnes]

That's interesting.  I applied 2DEFG over 5FGHI and got the same stage 16 method that you have below.  I also derived the stage 24 method with the same extension construction:

-3N-14-12.5N.36.14-14.3N.16-169N.50.14-14.3N.10-10AN.5B.14-14.3N.1B-1BFN.5G.14-14.3N.1G-1GKN.5L.14-14.3N.1L-1L.5N,12

which CompLib says is a true Surprise 24 method with Plain Bob lead ends, etc.

I wondered if any of (G) B. 6-8 might disqualify these methods, but they look ok.

So I can't see any reason why this extension family wouldn't be valid.  I haven't had a chance to look at 2DEFG over 5EFGH yet, but will do tomorrow.

Tim

[Ian Partridge]

On 30 April 2017 at 20:41, Richard Smith <ric...@ex-parrot.com> wrote:
> The Decisions require that the methods in one of the extension sequences are
> named Bitteswell, but at the moment none of the methods in any of the
> extension families has been rung.

I don't think this is quite accurate - Chogolisa S Max has been rung!

--
Ian Partridge

[Tim Barnes]

Agree 2DEFG over 5EFGH appears to work as well.

One question: (G) B.7 says, "Wherever the parent has a place made adjacent to the path of a hunt bell, this characteristic must be retained in all extensions."  I've never been sure how to interpret this.  Is this just referring to when the hunt bell makes a place, so that for normal hunt methods, if the lead end change is 12, this must be retained at higher stages, and if n-1/n is made at the half lead, this must also be retained at higher stages?

Or is, say, making 4th's while the treble is dodging in 5-6 considered adjacent?

I'm assuming it must be the former because if the latter, you couldn't use 6HI below for Bitteswell, and Tony has already recognized 2FG / 6HI.

Tim

[Richard Smith]

Tim Barnes wrote:

> Agree 2DEFG over 5EFGH appears to work as well.

Thanks.

> One question: (G) B.7 says, "Wherever the parent has a place made adjacent
> to the path of a hunt bell, this characteristic must be retained in all
> extensions." I've never been sure how to interpret this.

Likewise. It seems inherently ambiguous to me. This is
what I wrote yesterday when trying to interpret that:

// Both (G)B.7-8 say "wherever ... this characteristic must be
// retained in all extensions." This is ambiguous. When a
// change gets repeated as a result of the extension, foes
// "retained" mean the characteristic must be retained in both
// places or just one? Set multiple_retention = true for
// both. Tony Smith's letter to the RW re Chogolisa S Max (RW
// 2017, p 365) demonstrates that he believes the only one
// instance of the feature is required. This concurs with
// what Philip Saddleton has said in the past.
static const bool multiple_retention = false;

> Is this just referring to when the hunt bell makes a
> place, so that for normal hunt methods, if the lead end
> change is 12, this must be retained at higher stages, and
> if n-1/n is made at the half lead, this must also be
> retained at higher stages?
>
> Or is, say, making 4th's while the treble is dodging in
> 5-6 considered adjacent?

Both, I believe.

> I'm assuming it must be the former because if the latter, you couldn't use
> 6HI below for Bitteswell, and Tony has already recognized 2FG / 6HI.

You can if you follow the interpretation in my C++ comment
above. The HI section in Bitteswell is when the treble is
dodging 7-8 and lying, and has the place notation &6-6.5.
The places in sixths are adjacent to the treble's dodge. A
6HI extension under the treble gives us &6-6.5.6-6.5 around
the half-lead. The first pair of sixths is still next to
the treble, even though the second pair is not. That's
sufficient to satisfy my understanding of (G)B.7.

But suppose we were considering 6FG under the treble. The
FG section is 4-4.3 in the parent, so the middle part of the
extension would be &4-4.3.4-4.3.6-6.5. The first pair of
fourths are still next to the treble, so it doesn't matter
that the second pair are not. But the sixths are now
removed from the treble, so 6FG under the treble is not a
valid extension for Bitteswell according to (G)B.7.

At least, that's how I understand it.

RAS

[Tim Barnes]

On Mon, May 1, 2017 at 12:09 PM, Richard Smith <ric...@ex-parrot.com> wrote:

But suppose we were considering 6FG under the treble.  The FG section is 4-4.3 in the parent, so the middle part of the extension would be &4-4.3.4-4.3.6-6.5.  The first pair of fourths are still next to the treble, so it doesn't matter that the second pair are not.  But the sixths are now removed from the treble, so 6FG under the treble is not a valid extension for Bitteswell according to (G)B.7.

Ah ok.  So the adjacent places of all sections of the parent must be retained in the corresponding sections of the extension, but in the sections of the extension that are replications (e.g. FG, F2G2, F4G4), the adjacency needs only to appear at least once.  By definition, when it appears only once, it would appear in just the 'base' section (FG in this example).  If the adjacency appears more than once in the replication sections, it will appear in all of them.

That's def not clear from the Decisions wording.  It also doesn't seem clear that 'adjacent' necessarily refers to an adjacent place in the same row.  It could also mean the same place in an adjacent row.

Tim

[Richard Smith]

Tim Barnes wrote:

> Ah ok. So the adjacent places of all sections of the parent must be
> retained in the corresponding sections of the extension, but in the
> sections of the extension that are replications (e.g. FG, F2G2, F4G4), the
> adjacency needs only to appear at least once.

That's my understanding.

> By definition, when it appears only once, it would appear
> in just the 'base' section (FG in this example). If the
> adjacency appears more than once in the replication
> sections, it will appear in all of them.

Yes, I think that's right.

> That's def not clear from the Decisions wording.

I completely agree that it's not clear. I'm basing my
interpretation partly on a conversation I had with PABS back
in 2004, and partly by reverse engineering extensions that
have been allowed in recent years.

> It also doesn't seem clear that 'adjacent' necessarily
> refers to an adjacent place in the same row. It could
> also mean the same place in an adjacent row.

I think that's fairly clear when you read (G)B.8 in
conjunction with (G)B.6, and compare both with other uses of
the words 'adjacent' and 'consecutive' in the Decisions,
e.g. (J)A.2 and (E)A.1. Adjacent means within the row;
consecutive means from row to row.

But we shouldn't have to be relying on this sort of close
reading of the Decisions to infer the meaning of the terms
being used. They should be clearly defined.

RAS

[Tim Barnes]

On Mon, May 1, 2017 at 2:24 PM, Richard Smith <ric...@ex-parrot.com> wrote:

I think that's fairly clear when you read (G)B.8 in conjunction with (G)B.6, and compare both with other uses of the words 'adjacent' and 'consecutive' in the Decisions, e.g. (J)A.2 and (E)A.1.  Adjacent means within the row; consecutive means from row to row.

But we shouldn't have to be relying on this sort of close reading of the Decisions to infer the meaning of the terms being used.  They should be clearly defined.

Makes sense re: usage of adjacent vs. consecutive.

I'll see if I can get MC confirmation of this interpretation of (G) B.7 and (G) B.8 -- i.e. the adjacent places only need to be retained once.  Are there any other ambiguities that I should ask about at the same time?

Something that seems missing is a convention for designating the mode of an extension.  E.g. if a parent method just has places below the treble made in 1st's, 2nd's, 5th's and 6th's, an extension might keep 1st's and 2nd's static, but have 5th's and 6th's expand.  For this method you could describe the extension as either mode 2, mode 3 or mode 4.  Not a major issue, but it would seem helpful to have a convention of either using the lowest possible mode or the highest, so that extension construction modes are recorded consistently.

Tim

[Richard Smith]

Tim Barnes wrote:

> I'll see if I can get MC confirmation of this interpretation of (G) B.7 and
> (G) B.8 -- i.e. the adjacent places only need to be retained once. Are
> there any other ambiguities that I should ask about at the same time?

Are modes AB and BC (and more interestingly ABCD and BCDE)
allowed below the treble?

> Something that seems missing is a convention for designating the mode of an
> extension. E.g. if a parent method just has places below the treble made
> in 1st's, 2nd's, 5th's and 6th's, an extension might keep 1st's and 2nd's
> static, but have 5th's and 6th's expand. For this method you could
> describe the extension as either mode 2, mode 3 or mode 4. Not a major
> issue, but it would seem helpful to have a convention of either using the
> lowest possible mode or the highest, so that extension construction modes
> are recorded consistently.

We often have similar cases of multiple representations with
the section codes. The standard extension of Cambridge
S Minor can be called EF or FG below, and DE or EF above.


Incidentally, a reply to Tony's appears on p 454 of this
week's RW.

RAS