|
From: Richard S. <ri...@ex...> - 2009-05-01 07:07:23
|
Don Morrison wrote:
> 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.
Yes, I think that having the flexibility to move between the
two systems is one of the key advantages to what I'm
suggesting. The reason is that I would like to see
compositions captured in the database in as close a form to
their published form as possible.
> 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.
It is to some extent a nuisance, but one I'd rather see
dealt with now rather than as an afterthought.
However, just to be absolutely clear, I do *not* think that
we want a unique representation for a given composition.
Frequently it will be possible to represent a touch using M,
W, H, or using numeric calling positions in a fixed length
course, or just a sequence of p, b, s. And probably other
ways too. It'll be up to the person entering the
composition to choose the most natural format -- which
hopefully will be an obvious decision most of the time.
(For that matter, the client may well enforce particular
choices in particular circumstances. But that's a client
issue.)
> 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 - -
That's an interesting example. So we have courses with 4, 5
and 6 leads respectively. It would be easy to suggest that
this comp is using the 6th as observation for the purpose of
defining the course end. But that's not true in general.
Perhaps the course length is dictated by the number of calls
in it -- add one extra lead for each plain lead. Given how
Grandsire works, that's close to being right. But not
completely right. Consider the first composition of G9 on
Don's site:
5,076 Grandsire Caters
Richard I Allton
23456789 1 2 3 4 5
-----------------------
23458967 s s - -
32498765 s - -
23476589 s s -
42356978 s -
24397568 s - -
42356879 s s -
24356987 - - s*
42356789 - - -
-----------------------
6-part, calling bob for s* in parts 3 and 6.
Here the first course is odd because it has 11 leads in it.
In many compositions (this one included) the course end has
the 2,3,4 in some order in 2,3,4; but that's not exclusively
the case.
Maybe it's the wrong approach to look for too much logic in
what the course end is and simply code the first course of
RIA's comp as (using GSiril notation):
p,s,s,b,b, repeat(p, {/23458967/: break})
i.e. a sequence of calls followed by as many plain leads is
is required to bring up the specified course end. And list
all of the course ends.
> 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.
Not necessarily. Consider the first course of RIA's peal.
23456789 1 2 3 4 5
-----------------------
23458967 s s - -
What this means is ring p,s,s,b,b and then plains until the
course end is related to the part end as 23458967 is related
to 23456789. I.e. in the second part this means ring plains
until 42358967.
In pseudo-mathematical notation if h is the part end and l
is the current lead end, we want to ring plains until
h . 23458967 = l
[...]
> 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?
Yeah. Let me pick apart my original example:
W = repeat( { b, /*8?/: b, break; p } )
Repeat repeats its argument indefinitely until it is
terminate. This can either be with a break (a controlled
exit that'll continue proof from the thing following the
repeat block), or an abort (which halts proof). The default
rule for 'false' (which is implicitly invoked when the
composition becomes false, for what ever definition of false
is currently in force) calls this.
The { ... } thing is a list of alternatives. The syntax is
{ condition1: expr1; condition2: expr2; ...; default }
It tests condition1, and if that succeeds runs expr1; or if
condition1 fails, it tries condition2, and so on. If no
condition succeeds then default is executed. In this
particular example, there is just one condition which is b,
/*8?/. This means (more or less) try a bob and see if this
puts bell 8 in position N-1.
The clever bit is that everything done in the condition
block is immediately thrown away irrespective of whether the
condition passes or fails. It doesn't matter if the
condition prints something, or aborts because it runs false,
or whatever. The output is suppressed, and any other
changes are undone. This is why there is also a 'b' at the
start of the expression that we evalute if the conditional
succeeds.
> 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?
You mean something like the composition of Smith's 23
2345678 W H
-------------
3578264 -
8375264 -
5873264 -
7358264 - -
5738264 -
-------------
7-part.
Yes and no. In my development copy of GSiril, I've extended
the pattern matching syntax. I've used Perl as a model
where /pattern/ is shorthand for $_ =~ /pattern/. In GSiril
/pattern/ is now shorthand for @ ~ /pattern/ where @ is a
variable meaning the current row. (This fits naturally with
@'s role in quoted strings in Siril which GSiril has
adopted.)
The second change is the addition of a whole bunch of
arithmetic operators, some of which have been overloaded to
work on rows too. At present there are + (addition), -
(subtraction and unary minus), * (multiplication), /
(division), \ (left division), ^ (exponentiation), %
(modulus) and ! (factorial). Of these, *, / and \ have been
overloaded to work with a pair of rows, and ^ also works
with a row and an integer. What do I mean by left division?
I've simply defined a\b as shorthand for a^-1*b; obviously
for integers a\b == b/a.
It'll be a little while before I've committed this change as
there are still a few type-safety issues that I need to
resolve. But I'm getting there.
How does this help? Well, it means that instead of writing
/*8?/ in the pattern test for W, I can now write
W = repeat( { b, (parthead\@) ~ /*8?/: b, break; p } )
This way we can define the peal as:
peal = partend = @*'15738264', H,3W,2H
(Add paretheses to taste.)
RAS
|