[r-t] Results of Poll on the Null Change
dfm at ringing.org
Fri Jan 16 04:32:19 UTC 2015
On Sun, Jan 11, 2015 at 2:20 PM, Tim Barnes <tjbarnes23 at gmail.com> wrote:
> Row: A sequence of N bells in which each bell rings once and only once.
I think including the unbound variable N, without an explanation, is just
confusing. Also it needs to be a fintie sequence. What is wrong with simply
"A finite sequence of bells in which each bell rings exactly once."?
> Stage: A name that represents the number of bells, N, that form a given Row,
> as shown in the table below. (Table to be added, 4=Minimus, etc.)
I don't think as useful a term as "stage" should be reserved for something
is superficial as a name. I think "stage" should be the number of bells, not
the name for the number of bells. If we need a name for the name, how about
"stage name"? It should be made explicit that it is a finite, non-negative
integer (OK, the integeer and non-negative may be a bit of overkill, but
it won't hurt). It should probably even be "positive" instead of "non-negative",
though I'm not certain about that. It might even have to be at least 2?
> Change: A transposition of bells at a given Stage from their Places in one
> Row into the Places of the next Row.
"to _their_ Places in the next"?
If a "stage" is just a name, and not the number it denotes, this needs
to be rephrased to something rather awkwad to really make sense,
> Simple Change: A Change where the transposition moves every bell to either
> the same Place it previously occupied, or to an immediately adjacent Place.
Perhaps it would be worth even spelling out what an "adjacent Place" is?
While we think we know what we mean, would someone who doesn't already be
sure to know? And, pace MDB, there are those within our community for
whom "adjacent" means something radically different within a row and
within a sequence of leads.
> Method: A process for generating a sequence of Changes at a given Stage.
While this is intended to imply that all the changes in a method are of
the same stage, it's not at all clear that it says that unambiguously.
It should be more explicit. Maybe something like "a process for generating
a sequence of Changes at a given Stage, each of those Changes being of
> Method Classification:
> Static Method: A Method that can be defined by a fixed sequence of Changes.
> Dynamic Method: A Method that is not a Static Method.
> [Lots of other method classification terms to be added here]
A static method also needs to be of finite length. I'm a bit worried
about the "dynamic"/"static" language: certainly "static" is used in a
different sense today, where it, and possibly "dynamic", are
subjective judgements of how much bells move around within a lead or
other sub-chunk of a course of a method. It is common to say Cray is a
static method. "Dynamic" is probably less used, but I would not be
surprised to hear someone say London or Plain Bob is more dynamic than
> Method Naming:
> Methods may be named and recorded in the Central Council’s Method Library,
> subject to the following requirements:
> A Static Method may not be separately named and recorded if its sequence
> of Changes is a rotation of another Static Method that has already been
> named and recorded.
> [Other requirements to be added, such as ringing the method in a peal or QP]
I'm not convinced "rotation" is unambiguous without some further definition. It
may be, but it's not entirely obvious that it is.
> On Calls, here are the points I can think of that would need to be debated /
> validated. No doubt there are others:
> Calls alter the Changes that would otherwise be generated by the Method that
> is being rung.
> Calls are never rung in their own right - they are only used to alter the
> Changes generated by a Method.
> Calls are defined locally as part of a Composition (see later section).
> There is no central recording of named calls or similar.
Doesn't this exterminate Doubles variations? If so, I think there is
a substantial subset of the ringing community that would not be happy.
> Calls may:
> Modify one or more adjacent Changes of a Method
> Remove one or more adjacent Changes of a Method without replacing them
> Insert one or more adjacent new Changes into a Method without removing any
> of the Changes of the Method
Is this an exhaustive partitioning of the possibilities?
Don Morrison <dfm at ringing.org>
"Childhood may be defined as the age of play; therefore some
children are never young, and some adults are never old."
-- Will Durant, _Fallen Leaves_
More information about the ringing-theory