Re: [complib-talk] Method categories

[Don M. <df...@ri...>]

2009/4/15 Richard Smith <ri...@ex...>:
> But my suggestion here is that instead of hard-coding these,
> we instead equip the system with a way of defining these
> concepts ourselves.  GSiril goes some way towards this:
> assuming b and p are already defined, we can define W on 8
> bells as:
>
>   W = repeat( { b, /*8?/: b, break; p } )

There's an interesting dichotomy when we're describing touches, that
from your description it would appear GSiril cuts both ways:

In one way when describing touches we want to enumerate chunks
of the changes that generate rows. These are the things that typically
(though not always!) get repeated in multi-parts and repeated blocks
and so on. Siril operates exclusively at this level.

In another way when describing touches we want to talk about the rows
produced. This is what we're doing when we use calling positions such
as M,W,H that refer to an observation bell. I believe Graham's
notation in the prototype operates exclusively at this level.

But in real life we tend to drift back and forth between these two
views. I guess human beings find this sort of model munging natural,
but it's a nuisance when you're trying to come up with an unambiguous
notation a machine can understand.

Perhaps the most obvious example of such model munging is the way
Grandsire is conventionally laid out on higher numbers:

23456789  1  2  3  4
____________________
324765    s  -  -  s
23456987  s     -  -
42356798  -        -

The calls at 1, 2, 3 and 4 are at the level of changes. They're "make
the relevant call at the first, second, ..." lead that comes up,
without regard to the position of any bells in the rows produced. If
this were part of a repeating block where subsequent block heads might
include 23165978 every bell would be in a different postion in that
subsequent repetition, so it's got to be a reference to changes, not
rows.

And yet to turn this into something meaningful we've got to look at
the rows produced to know when the course ends. That is, to know how
many plain leads to hang on the end of each of these courses, as the
first is four leads, the second five leads, and the sixth six leads.
Making matters even worse, the only evidence we have for this is the
printed course heads, or perhaps our own implicit smarts as to the
back bells probably coming together at a course end.

And yet when we repeat this block, we're repeating the changes, not
looking at the rows again, as we're not even being show most of the
course heads for the repeats! That is, we want a sequence of changes,
but we need the rows in the first use of those changes to help us
define which changes we wanted, but then stick exlusively to a
sequence of changes.

I'm not entirely clear on how GSiril is spanning these two different
models, though apparently it is. That /*8?/: thingie
pattern matches against the rows generated, and is some kind of
conditional? So I could define some block that includes these pattern
matching thingies and say "repeat it five times" and each of those six
instances of it might have a completely different length and different
composition of changes? Is there someway to have GSiril describe, say,
a seven part that uses calling positions against an observation bell,
with the observation bell changing in each part? How about a calling
on higher numbers that uses calls with respect to the tenor to
describe shuffling the big bells around, but M,W,H with respect to
just the little bells?



-- 
Don Morrison <df...@ri...>
"In many ways, the long-standing animus between the Red Sox and
the New York Yankees is authentic, deep-rooted and wholly organic.
In [other] ways, it’s a bit more like pro wrestling."
                 -- Sean McAdam, _The Boston Herald_, 7 January 2009