[r-t] Poll on consecutive blows in the same position

[Tim Barnes]

On Sat, Dec 27, 2014 at 7:39 PM, Don Morrison <dfm at ringing.org> wrote:

> On Sat, Dec 27, 2014 at 4:57 PM, Tim Barnes <tjbarnes23 at gmail.com> wrote:
> > C.  No bell can make the same place consecutively for all of a method's
> > changes (so for a method with n changes, the limit would be n-1).
>
> I'm having a bit of trouble decoding this. Are "all of a method's
> chanages" all the changes in a whole course of a method? Or are you
> talking about a single lead of things that are divisible into leads (which
> all CCC-approved methods are today, but not non-method blocks, and, I
> believe, not necessarily "methods" as we're trying to define them).
>

Agree this wording needs improvement.  I'm using the assumptions I've used
before, which are that a method is any sequence of changes, and that if you
ring a method's changes once, you've rung a plain lead of that method.  C
is intended to disallow a method where any bell remains in the same
position for the entirety of that plain lead, from the starting lead-head
to the finishing lead-head inclusive.

If you support C, you presumably are in the camp where you think there are
both sequences of changes that are 'methods' and sequences of changes that
are something other than methods (i.e. the non-method block approach).  Or
you would want a method that has a non-moving bell to be described as two
methods horizontally spliced with an internal stationary bell in the
middle.  And/or you would want a method that has a non-moving bell to be
described as a call that adds changes to another method.  I'm in camp D.


> And what about a rule-based
> method that has one bell fixed throughout in some courses, but not in
> others?
>

I continue to think that, in the same way we recognize call changes as a
separate class to method ringing, it's reasonable to say rule-based
constructs, as well as things like jump changes, can also be considered
separate classes.  I recognize that at one level it's arbitrary to say
there shouldn't be a distinction between methods and non-method blocks
(they should all be methods), but to say there should be a distinction
between methods and dixonoids.  But if the overall aim is to try to
persuade the CC to vote in improvements to the rules we have today, a level
of pragmatism is needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://bellringers.net/pipermail/ringing-theory/attachments/20141227/ae7a854d/attachment-0004.html>