[r-t] Definitions so far

[Don Morrison]

On Thu, Jan 15, 2015 at 7:08 PM, Graham John <graham at changeringing.co.uk> wrote:
> I think these definitions encompass much more than the existing ones, so are
> definitely heading in the right direction.

I agree.

> Stage: a name given to the number of bells ringing changes. [makes it
> clearer that a cover bell is not included]

No, it's the number of bells ringing in a row. Bells don't ring in changes.
And, as you've not defined "change" yet, you've set up a circular chain
of definitions.

> Change: A transposition of bells from their Places in one Row into the next
> Row. [doesn’t need Stage as Row above uses Stage in its definition]

If you depend upon the Row's stage to define this, you need to be explicit
that both Rows are of the same stage. Maybe it's a theorem from whatever the
undefined term "transposition" means, but that's not a good thing to
depend upon.

> ·         Simple Change: A transposition where one or more adjacent pairs of
> bells swap Place.  [shorter and excludes Null Change so that the subtypes
> don’t overlap]

Erk. "Adjacent pairs of bells swap Place"? Something more explicit would be
far better. We know what it means, but I doubt that my late mother, may she
rest in peace, a non-ringer, would necessarily have known, and depending upon
preconcieved notions is a large part of what got us into the temperature of
water in which we currently swim.

> ·         Null Change: A transposition where no bell moves Place. [simpler
> definition]
>
> ·         Jump Change: A transposition where one or more bells moves to a
> non-adjacent Place. [defined by what it is, rather than what it isn’t]

You've radically recast what Tim was defining. You've partitioned changes
into three, disjoint classes, where he had only two. I think this is a mistake.
Doubly so in light of the recent vote that said more folks don't have a
problem with null changes. It's not at all clear to me we even need a
definition of "null change" -- where are we going to use that term? But if
we do, as a particular kind of Simple Change makes a lot more sense.

If I am overruled on this, though, there would then be two further fixes
that would be needed:

1) the order would need to go null->simple->jump or jump->simple->null.
If you have the partition into three classes, a null change is clearly
simpler than a simple change.

2) the name "simple change" would need to change, since a null change
is simpler than a simple chanage!

Also all this "moves Place" stuff sounds very jargony, and more likely
to confuse someone coming to this stuff cold than the plainer language
Tim used.

In summary, I think Tim had things better.

> Method: A process for generating a sequence of Changes at a given Stage.
>
> Static Method: A Method that can be defined by a fixed sequence of Changes.
>
> We concluded before that a Static Method is just a subset of a rules based
> Method. Therefore I do think it is necessary or helpful at this point to
> define Dynamic Method as a subtype. Then Dixons is just a Method, but
> Cambridge is also a Static Method.

On this I agree with Graham.

I do think we would be better with an intermediate class of method which
includes Dixonoids but excludes the truly exotic, but that's a whole
different issue. And could be added later without causing disruption, since
we don't plan on worrying further about non-static methods in the near term.



-- 
Don Morrison <dfm at ringing.org>
"A good love poem, though it may be addressed to
one person, is always meant to be overheard."
     -- T S Eliot, "The Three Voices of Poetry"