Re: [complib-talk] Method categories

[Richard S. <ri...@ex...>]

Don Morrison wrote:

>>   p,s,s,b,b, repeat(p, {/23458967/: break})
>
> While noting the course end is the conventional way, or at least the
> old fashioned convention, for indicating how long a course is, the
> more I think about it the more I think it is A Bad Idea.
>
> a) My experience with dealing with submissions of peal compositions
> and so on is that the single most common error is to cite an incorrect
> course end. If we depended upon a course end for the definition of a
> composition this would make it exceedingly fragile.

This is a fair point.  However I'm not saying that as a 
matter of course we should write out the course heads in 
full like this; I'm merely wondering whether it would be a 
useful fallback position if we could do that so that we can 
handle the odd course that doesn't really fit the rules. 
Most of the time I expect a consistent course end rule like

   repeat(p, {/[234][234][234]*/: break})

would be sufficient.

> b) It's not really unique. It is perfectly legal (in the sense of not
> contravening any CC Decisions) to have, in an MEB, a chunk that goes
> through the same change two or more times without an intervening call.

GSiril permits several approaches to this.  The simplest way 
is simply to repeat the rule that takes you to the course 
end:

   3 repeat(p, {/*8/: break})

That will only stop after the third lead end with 8 at the 
back.  There might be circumstances in which a more 
complicated approach is needed, and then GSiril allows you 
to write:

   n=0, repeat(p, {/*8/ && ++n==3 : break})


> Depending upon a particular course head in the face of this is
> ambiguous. Granted, it's not something I'd personally want to do, and
> is unlikely to come up often in practice, but it is a potential
> problem. And I believe an extreme example of exactly such a
> construction has been rung at least once.
>
> I continue to think the better solution is to specify, when necessary,
> how many leads a course is.

And that's also fine.  If you want to do that then the right 
approach is probably:

   p,s,s,b,b,6p

What I'm suggesting really is that the underlying framework 
should allow any of these approaches.  (I'm not advocating 
support for all of the more complicated bits of GSiril; as 
I've said before, I'm just using GSiril as a means of 
experimenting with the fundamental building blocks and 
determining what they are.)

>>   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.
>
> I am troubled by this "repeat until false" business.

OK.  I've not done a good job of explaining this.  I think 
we're getting confused between what GSiril does because it 
is a peal proving program intended to be compatible with 
Siril, and what we want from the compositions database.

In GSiril a repeat block can be terminated in two ways: a 
break or an abort.  The repeat-break mechanism is important 
as it is the only way of doing repetition without 
hard-coding the number of iterations required.  I think the 
peals database will need something like that, however we 
choose to dress it up.  By contrast, the repeat-abort 
mechanism is important to GSiril as a proving program 
because it allows you to abort a prove when it runs false. 
I completely agree that that we don't want an idea of truth 
in the peals database.

The only actions that GSiril does that depend on its idea(s) 
of truth are governed by the true, notround, false and 
conflict symbols (which is the same as Siril); unset these, 
and GSiril never acts on truth.  This is the behaviour we 
want from the peals database.

And without the conflict symbol (I was mistaken when I said 
it was the false symbol that invoked abort), there's no 
obvious reason to support the repeat-abort mechanism. 
Unless we use it to handle the case of a composition that 
seems to be stuck in a infinite loop.  (E.g. call a Wrong, 
and then repeated Homes until it comes round.)

> 1) Viewing GSiril simply as a proving platform, it falls into a trap
> that I think is unfortunate, though common. It causes the thing to
> stop, or at least become useless, at the first false row. It can
> really be helpful to the end user to have a broader presentation of
> where a composition runs false. For example, if you see just a
> handfull of rows, all with the treble in 6ths, are false against one
> another it leads you to consider the root cause as different than if
> you see 32 consecutive rows are false against exactly the same 32 rows
> also appearing consecutively somewhere else!

In my experience, most proving programs allow this behaviour 
to be configured.  Certainly Microsiril, Sirilic and GSiril 
all do.  In all three, by default, conflict is defined:

   conflict = "# rows ending in @",
              "Touch not completed due to false row$$"

The $$ in a string aborts the search.  However, if you 
change this to

   conflict = "False row: @"

then any of these peal proving programs will print a list of 
false rows followed by

   5040 rows ending in 13256478
   Touch is false in 32 rows

And I'm sure there's scope for doing more with the conflict 
symbol too.

> 2) I don't think a particular notion of "true" has any place in our definition
> of a composition for storage in the database. As discussed earlier, I
> think a composition should be some sequence of changes, structured in
> some appropriate way, but that how it stacks up against various
> definitions of truth should be something determined externally
> (though, perhaps cached in the database), on the same footing as how
> many little bell rollups it contains, whether it contains back stroke
> tenor reversals, whether or not it contains an equal number of plains,
> bobs and singles, or whether or not it is all the work.

I completely agree.

RAS