Re: [complib-talk] Method categories

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

2009/5/1 Richard Smith <ri...@ex...>:
> It is to some extent a nuisance, but one I'd rather see
> dealt with now rather than as an afterthought.

I agree completely. Sorry if that wasn't clear.

> However, just to be absolutely clear, I do *not* think that
> we want a unique representation for a given composition.

I agree wholeheartedly with this, too. If we wanted a unique
representation, we'd just write down all the rows, after all!

>   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.

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.
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.

>   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.

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!

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.


-- 
Don Morrison <df...@ri...>
"They were treated like royalty--not the sort who get dragged off to be
beheaded or have something nasty done with a red-hot poker, but the
other sort."   -- Terry Pratchett, _A Hat Full of Sky_