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 |