complib-talk — Complib mailing list

[complib-talk] Composition Library Project Update - July 2011

[Graham J. <gr...@ch...>]

Although development of the Composition Library software has continued at a
slow pace over the last two years, it is still progressing.

All of the functions have been prototyped and refined and the concept has
been fully proven. In fact, I already find it very useful. It now has the CC
decisions on methods encoded which means that it can properly classify and
entitle new methods, and derive all its properties including symmetry,
method above and below, right place and hunt and working bell cycles.

It now imports the CC collections (all methods and provisional methods) from
the XML collections, and validates these in the process. A number of
discrepancies in the CC collections have been identified in the process, and
have been corrected in the CC collections. It also now displays the blue
lines and/or grids for methods, by default drawing a line through hunt bells
and each unique working bell (i.e. one of each cycle for differentials).

Collections have been implemented, allowing compositions to be easily added
to collections as references. This feature provides the means to create new
collections for public or personal use, and to record composition references
against existing publications, such as the Ringing World, or published
books.

Some statistics reports have been added, providing analysis of methods by
leadhead code, class and stage, and numbers of compositions recorded by
composer and stage.

Library update and user registration functionality has been included,
providing the means to keep your local database up to date with methods,
compositions and collections, and to upload any additions or updates to the
master Composition Library.

For more details see the version 0.2 alpha:
<http://www.changeringing.co.uk/complib/screenshots.php>

Now work turns to taking the core composition functionality to the next
level. At present, it only deals with compositions in single methods, and
positional calling. A major enhancement will see a complete rework to
introduce a composition editor with the flexibility to cope with (hopefully)
any composition, be it Grandsire, Stedman, Spliced, unusual starts, or
bizarre differentials. Following this enhancement and some testing, the
intention is to issue a beta version to project members to trial.
 
Graham John, July 2011

Re: [complib-talk] Where's Don?

[Graham J. <gr...@ch...>]

Thanks for the update Don - I understand the demands! Since no-one reviewed
the paper I submitted to this list in May I have not done any work on
Complib since, and have recently been sidetracked into another small project
in addition to Handbell Manager, which I thought was going to be a very
short project - they never turn out that way, do they?

I do intend to get back to Complib, but it is a big undertaking to do
completely on my own. Not only that, but there are plenty of other projects
lurking on my to-do list that I would like to start if I could find the
time. So if anyone can find time to help design Complib to get it going
again, please shout, or if you have any suggestions about how best to
proceed from here, please say.

Graham  

[complib-talk] Where's Don?

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

You may recall that months ago I undertook to perform several tasks
for this effort, including producing a bunch of example compositions
and drafting some goals. If you do recall that, you will instantly
deduce I've fallen down on those commitments.

It's clear to me I will never get around to making the contributions
to this effort I had hoped to. I'm sorry.

Seeing how much my to-do list has grown since I added these items to
it, and thus how much further down the list these items now are, I'm
just going to scratch them off. I'm clearly not going to be much of a
contributor here.

I suspect none of this comes as much of a surprise to anyone, but my
apologies none the less. It must be frustrating to others to see me
express a lot of opinion but do no actual work.

If this effort ever reaches the stage where it is desirable to pour
the contents of ringing.org's database into it, I will, of course,
still stand ready to help there. Based on my performance to date I
don't know how much actual implementation you'll get out of me, but
I'll certainly try to provide as much help as I can.



-- 
Don Morrison <df...@ri...>
"It's because their minds are so often involved with deep and
problematic matters...that their mouths are allowed to wander
around making a nuisance of themselves."
                                  -- Terry Pratchett, _Hogfather_

Re: [complib-talk] Storing compositions on the database

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

On Fri, May 22, 2009 at 3:31 PM, Graham John <gr...@ch...> wrote:
> Deathly silence. Is that a good, or a bad sign?

In my case it is a sign that work has been hectic recently, and what
spare time it and family obligations have left have gone to things
higher up on my prioritised (implicit) list. Like so many other
things, neglected, but not forgotten.



-- 
Don Morrison <df...@ri...>
"He was honest by temperament; the honest, in this world,
give one another a hard time. He was an engineer."
                      -- Hilary Mantel, _Giving Up the Ghost_

Re: [complib-talk] Storing compositions on the database

[Graham J. <gr...@ch...>]

Deathly silence. Is that a good, or a bad sign?

Graham

-----Original Message-----
From: Graham John [mailto:gr...@ch...] 
Sent: 11 May 2009 5:57 PM
To: 'Composition Library email list'
Subject: Re: [complib-talk] Storing compositions on the database

I have defined some tables and attributes, and produced a set of worked
examples to demonstrate how the data can support the input and formatting of
those compositions. It is unlikely to support every scenario as yet, and
clearly some snags will not materialise until we try and develop it,  but I
think it will cope with a broad range of compositions including some tricky
cases.
 
Comments, suggestions and input welcome, especially from those who have not
yet said anything.

Graham 

Re: [complib-talk] Storing compositions on the database

[Graham J. <gr...@ch...>]

I have defined some tables and attributes, and produced a set of worked
examples to demonstrate how the data can support the input and formatting of
those compositions. It is unlikely to support every scenario as yet, and
clearly some snags will not materialise until we try and develop it,  but I
think it will cope with a broad range of compositions including some tricky
cases.
 
Comments, suggestions and input welcome, especially from those who have not
yet said anything.

Graham 

[complib-talk] Demo Download

[Graham J. <gr...@ch...>]

The demo can now be downloaded as a self-installing executable from the
Complib home page on sourceforge without the need for a development
environment. The only prerequisite is a PC with .NET Framework 3.5 SP1
installed. If you downloaded the demo over the last couple of days, you
should redownload, as it was missing the installation for MS ReportViewer
which I used for the statistics panel.

 

Graham 

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

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_

Re: [complib-talk] Method categories

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

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

Re: [complib-talk] Method categories

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

On Wed, Apr 29, 2009 at 2:29 PM, Richard Smith <ri...@ex...> wrote:
> test it with a large range of test cases.  And
> to that end it would be good to start accumulating a set of
> test compositions wreiten out in their natural form -- i.e.
> how you would publish them on the web or in the RW.

I will assemble an initial selection of such test cases and put them
someplace where we can all get at them in the next few days.



-- 
Don Morrison <df...@ri...>
"When _Alice_ was published and won her [Queen Victoria's] heart, she
graciously suggested that Mr. Dodgson dedicate his next book to her.
Unfortunately for Her Majesty, his next book was a mathematical opus
entitled _An Elementary Treatise on Determinants_."
-- Alexander Woollcott, introduction to _The Complete Works of Lewis Carroll_

Re: [complib-talk] Storing compositions on the database

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

On Mon, Apr 27, 2009 at 6:12 PM, Graham John <gr...@ch...> wrote:
> In a printed composition, it seems that you have to work out was is intended
> from the given coursehead. Is it necessary to enter every coursehead for
> this type of composition to define it? This doesn't seem ideal. Is there a
> better way?

I think you either have to supply some indication of how to recognize
a course head, or specify the course's length. The canonical example
of the former is, of course, to write out the course head, though in
principal you could often supply a simpler rule, such as "tenor comes
home" or "back three bells come home in some arrangement". But,
particularly given the modern fashion of more interesting back bell
positions and even things like calling little bell runs in Stedman a
course end, this gets harder, and the whole course end may really be
required.

The alternative of specifying the length of the course is, mercifully,
becoming more common. Anyone that has tried to enter into proving
software a composition with unusual courses and back bell positions
understands how painful it can be having to work things out backwards
from a desired course end. Yes, if you're calling it, the discipline
of writing it all out by hand is probably a good one, but it works
against trying to enter something quickly to prove or format it when
you have no intention of calling it yourself.

I think working from course lengths instead of course ends has a
further advantage: it keeps you entirely in the realm of changes,
rather than getting down into the rows they generate. This is where
things like repeating blocks fall naturally, and it seems best to stay
away from the actual rows when defining a composition to the extent
one can.  Sometimes, of course, you have no choice but to operate at
the level of the actual rows; Dixon's, for example.

This problem doesn't just arise in things with numbered calling
positions. Consider something like Smith's 23, when it is notated as
calls at W and H, with the observation bell changing each part. Or
compositions on higher numbers with unusual back bell positions that
are using M,W,H with respect to whatever bell was last in last place
at a course end.

Anyway, I think in most cases, at least for single methods, it is best
to specify the length of every course when using numbered calling
positions; or, rather, to specify a default course length, and then
make explicit any deviations from it.



-- 
Don Morrison <df...@ri...>
"The ships hung in the air in exactly the same way that bricks don't."
                -- Douglas Adams, _The Hitchhiker's Guild to the Galaxy_

Re: [complib-talk] Method categories

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

(Catching up...)

Don Morrison wrote:

> Ripping up a piece of sofware and starting over isn't a big deal. I
> think we all know that nearly every serious piece of software gets
> written more than once before it's done.
>
> But populating a database and throwing that away and starting over
> again is a different matter entirely.

Yes and no.  I don't object to throwing the database schema 
away as long as we can programatically convert all of the 
data from the old format to the new format.

The bigger problem is retaining compatibility with the wire 
protocol between server and client.  That's the one thing 
that I really don't think we can afford to break.


>> So far as I recall, his [Ander's] idea was that we start 
>> with a minimum of hard-coded ideas. Basically, rows, 
>> changes, and the notion of truth.
>
> No, we don't need a notion of truth. That's simply an attribute that
> gets considered when we think about whether or not a composition
> should be added to the database, but doesn't need to be included in
> the database.

Yes, that's a good way of thinking about it.  And that 
neatly side-steps any problems with differing levels of 
truth such as whole extents, MEBs, every row at hand and 
back, an 840 of spliced doubles and minor.  Excellent.

> The important thing to capture isnt' "what's good about this
> composition" it's "what is this composition". It's higher level tools,
> querying the database, that should be worrying about the various
> attributes, good or bad, of the compositions it contains.

Agreed.  Though it *might* be worth having some facility for 
annotating the database with this information too.  But if 
we do we can probably do it with opaque flags -- i.e. some 
external flag comes along later and sets some piece of 
metadata (a flag, a value, ...) on a composition.  Anyway, I 
think we can defer discussion of that, at least for the 
moment.

>> 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:
>
> To a lesser extent (no pun intended) this is also, sort of, what I do
> in Duckworth. I think it is less flexible than GSiril sounds, though,
> as it does hardwire some assumptions in: compositions are always
> composed of leads (ok, divisions), or at least contiguous fragments of
> leads; there are no more than 2 calls within a lead, and they replace
> changes without altering length. Clearly having something even more
> flexible than that would be an advantage for this database.
>
> The point in Duckworth, though, is that composition is really just a
> sequence of chunks of changes, where the chunking obeys conventions
> that may vary by method and composition style. And I think that's an
> important observation. Any higher level way we find to describe a
> composition that just as chunks of conveniently grouped bits of place
> notation will fail to work for some possible compositions; and not
> just outrageously pathological ones. Imagine someone undertaking this
> effort 100 years ago: they probably would have considered something
> like cyclic part heads as a ridiculous thing to support.

Yeah, that's precisely the flexibility I'm keen to support. 
Perhaps a better way of describing what I envisage is a 
platform on which it is poossible to implement specialist 
systems for different styles of compositions, but without 
enforcing any specific style.  And on top of that we produce 
a few stock systems (rulesets per my earlier terminology) 
for common types of composition.

>> So instead of telling the system with various standard
>> compositional devices, we provide it with a way of defining
>> our own rules on top of the basic concepts.  Here, instead
>> of M, W, H, we have the idea of repition and pattern
>> matching a row.
>
> As alluded to in my previous paragraph, I don't see how we can come up
> with a rule language that will be sufficient to express every case one
> might come up with in practice. I would love to be shown to be wrong
> about this, though.

I don't think it's necessary to try.  We produce a 
basic definition for change ringing: no jump changes; no 
cylindrical; every bell rings once per row.  That's probably 
sufficient.

Then we provide a rule definition 'language' for defining 
higher-level concepts.  It doesn't matter too much if 
definig rules is aomething of a dark art -- it's not 
something that ordinary users will ever do or probably even 
be aware of.

>> If you're writing a client, perhaps you only care about
>> touches in a single method on an even number of bells.  If
>> so, you might hard-code an assumptions about the relevant
>> ruleset into client.  Similarly, a client only interested in
>> twin-bob compositions of Stedman Triples might hard-code
>> assumptions about that ruleset.
>
> Yes, I think it's perfectly reasonable for particular clients to deal
> with only a subset of what's in the database. But none of that should
> float back into the database itself, which should be designed to
> support as wide a variety of potential clients as possible.

Agreed.

>> Anyway, how does an approach like this sound?
>
> My principle worry is that we can't define a sufficiently flexible and
> expressive rule language. Though clearly it's an improvement on the
> status quo.

That's largely why I'd like to prototype its semantics in 
GSsiril and test it with a large range of test cases.  And 
to that end it would be good to start accumulating a set of 
test compositions wreiten out in their natural form -- i.e. 
how you would publish them on the web or in the RW.

Richard

Re: [complib-talk] How do you run the prototype?

[Graham J. <gr...@ch...>]

Visual C# 2008 Express cannot build the reports I added for the Statistics
panels, so please use version 3 for the time being. If you have Visual
Studio, it should build OK. 

When I get a some time, I will also see if I can create an install package
so that people can try the demo without having a development environment.

Graham 

Re: [complib-talk] Storing compositions on the database

[Graham J. <gr...@ch...>]

I am making some progress on this, but I have a question for you.

In a composition that uses non-observation calling positions (i.e. one that
counts the leads or divisions from the previous coursehead to define the
column headings), how can complib work out where the next coursehead is e.g.
how many leads/divisions are there to the next coursehead after the last
call in the course? The course length may vary (e.g. Stedman turning
courses, or compositions of Bristol Major that cycle the tenors), and the
resulting coursehead may have no observation bell. 

In a printed composition, it seems that you have to work out was is intended
from the given coursehead. Is it necessary to enter every coursehead for
this type of composition to define it? This doesn't seem ideal. Is there a
better way?
 
Graham 

[complib-talk] Storing compositions on the database

[Graham J. <gr...@ch...>]

We have discussed (under method categories) the topic of how do you store
compositions on the database, and Richard was going to put his thinking cap
on regarding it. If anyone on this list has any suggestions please say, as
this is a tricky problem and I accept Don and Richard's view that we have to
get this bit right from the start, as it is fundamental to the successful
design of Composition Library.

The question is:-

How do we represent compositions on the database in a way that will
encompass any composition that has been rung to date and also provide as
much flexibility as possible to minimise change for future developments?

I have been thinking about this further this week, and have come to the
conclusion that we cannot separate the way a composition is stored entirely
from either how it is entered or how it is formatted, because:

1. After a composition is input and saved, it needs to be represented in
exactly the same way if a subsequent edit is required.
2. In spliced, Method mnemonics will need to be supplied at the time of
input.
3. To format a composition in its normal compact form, information needs to
be captured at the time of input, as it would be infeasible to reconstruct a
multipart composition that has included, omitted or A/B blocks. It may also
be better to allow the submitter to influence the column headings used (e.g.
for Belfast do you have a columns headed I, O and V, or do you have a column
headed B and use I/V and I/O/V/V in the lines? In split tenors compositions
where the observation changes in each part, often course positions are used
rather than MWH.

To check whether a proposed approach works, we need to work examples through
end-to-end i.e. how input, how stored, how formatted.
   
Examples need to include:
1. Conventional BMWH compositions of regular even bell methods with several
types of call.
2. Half lead calls
3. Unusual starts
4. Spliced compositions included spliced at the half lead or another
position
5. Differential methods with multiple cycles
6. Multi-extent blocks
7. Stedman
8. Twin hunt methods
9. Other principles
10. Irregular methods
11. High numbers
12. Other oddities that we can think of

Graham

Re: [complib-talk] Method categories

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

2009/4/20 Don Morrison <df...@ri...>:
> include 23165978 every bell would be in a different postion in that

Ah, sorry, typo. That was supposed to be 34265978. As you can see, my
fingers were shifted one space to the left from where I thought they
were!


-- 
Don Morrison <df...@ri...>
"Human beings, who are almost unique in having the ability to learn
from the experience of others, are also remarkable for their apparent
disinclination to do so."      -- Douglas Adams, _Last Chance to See_

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

Re: [complib-talk] SQLite with Mono

[Graham J. <gr...@ch...>]

Richard wrote:

> The System.Data.SQLite.SQLiteFoo classes seem to be
> called Mono.Data.Sqlite.SqliteFoo in the version
> I've got.  I think I understand the Mono vs System
> namespace prefix, but I'm puzzled about the
> capitalisation difference.  Are these class and
> namespace names case-insensitive on Windows?

That's strange, they are case sensitive in windows. 

> Also, in Complib/Properties/Resources.resx, the Resources/
> subdirectory is inconsistently capitalised.  The directory
> in SVN has a capital 'R', but some of the references in that
> file have lower-case 'r's.  That's easily fixed though.

Again odd, although folder names are case insensitive in Windows.

Graham

[complib-talk] Installation and program notes

[Graham J. <gr...@ch...>]

Composition Library - Developer installation instructions and program notes

INSTALLATION

1. Download and install Visual C# 2008 Express Edition, free from 
http://www.microsoft.com/express/vcsharp/

2. Download and install SQLite ADO.Net dotnet2 version, free from
https://sourceforge.net/project/showfiles.php?group_id=132486
In the installation box, check Visual C# Express Edition, to add the SQLite designer components into Visual C#. 

3. Download and install TortoiseSVN (win32 version), free from
http://tortoisesvn.net/downloads

4. Create a folder called complib where you want it, right click The folder and select SVN Checkout. In the TortoiseSVN dialog, type the location of complib into the URL box as below and click OK https://complib.svn.sourceforge.net/svnroot/complib

On any future occasion, right click and Update will keep Complib up to date. If you make any changes in the directory, you can also upload them to the repository using SVN commit.

5. Find and double-click the solution file (or open in Visual C#) 
complib/SVN/trunk/complib.sln

6. On the Visual C# menu, click on Project and Complib Properties, then Click on the Settings Tab. Find the Connection called ComplibLiteConnectionString. Edit the pathname in Value to point to the Test Complib database which is:
your path...Complib\trunk\Complib\SQLite\ComplibLite

7. Click the green run arrow. The solution should build and run, and Complib should launch.    

NOTES

This is partially developed unstable code, with little validation, and a number of features not yet implemented. If you stick to regular methods and valid composition input though, it should work sufficiently to give you an idea. 

I had to learn C# in the process of writing this, so please excuse any poor coding practices. In fact if you see anything that could be improved or spot a bug, please feel free to recode it and commit it back to subversion.

Here is a list of what works and what doesn't:-

Menu
- View
Two missing icons.
- Tools/Options
Advanced mode is not yet implemented - intention is when it is not selected to hide all features other than those required by a conductor.
- Compositions are not yet downloaded on startup (there is no online composition database!)
- User details are currently hardcoded

Method
- Find Method(s) Tab - should be OK. Title is the only field using "like". BTW - Clicking find with nothing selected shows the whole method database. Restrict searches for "Methods true to" by entering a leadhead code. There are currently problems caused by irregular methods, and by running out of memory, as currently none gets released until the whole set of compositions has been proved. You may get away with up to 700.
- Method Results Tab - Should be OK, as should the navigation bar.X on the navigation bar removes from results, not the database.
- Method Properties Tab - Should be OK, apart from "Little" and "Differential" flags not being shown or added the the Classes. Similarly these are not shown in the Title. Negative Method Ids are converted to an l to indicated local. Twin hunt methods need some attention to cope with the way they are held on the method database.
- Blue Line - not yet implemented. Code offerings welcome.
- New Method Tab - Some validation here, but not on Class, or null fields. PN will show in Red if invalid, or no Stage selected. PN will be reformatted in standard full form. New methods are held on the local database with negative Method ID's, (Unrung) is shown in the title.

Composition
- Find Composition(s) Tab - None of the check boxes do anything at present. Other fields apart from By Composed and Leadhead group(s) should work.
- Composition Results - Sometimes this appears with wrongly sized columns. This is fixed by clicking on a column heading to sort. Parts is always 1. If "List false compositions" is checked in Tools Options, two columns are added to show False Rows and whether the composition comes round.
- Properties Tab - Should be OK
- Formatted - Still needs a lot more work, but should show something reasonable in most cases. If a composition is false, courseheads are not being shown correctly after it runs false. Edit and Delete are greyed out unless you are either the submitter, modifier, one of the composers, or a Composition Library administrator. This will give some security to protect vandalism of data.
- Music - OK, but no subtotalling, or composition total shown here.
- New/Edit Composition. PN is validated, but not much else. I'm not happy with the Composer dropdown box. If you select {new composer} a dialog box comes up to allow you to enter a new one. Date first rung is not stored at present, and start row offset is stored, but not used. Applicable leadheads is an unvalidated entry field, but I want Complib to calculate this once I have an algorithm. Calling needs to follow the format as described in the Composition Library Calling Notation document. It is not validated at entry time, so problems can occur when proofing. You may get a terse error, which is not handled properly. 

Collection

- Not yet implemented

Music Scoring
- No validation. Only mask Types implemented are Row and Wrap. A mask can include x or ? as single character wildcards. A short mask e.g. 5678 in Major will count 5678s anywhere in the row. For Wraps I don't count it unless it actually wraps the row (i.e. Rounds itself doesn't count as a wrap of rounds). For the observant, this was incorrect in the demo presentation, as 87654321 was counted as a wrap at the previous handstroke row.
- Intention is to calculate Possible. Min and Max I will probably drop as unnecessary. Score is the multiplier to use.
- The autosort gives strange effects as you edit data 

Statistics

- Method Tab and composition Tab now show a report. Nothing in Collection and Submission tabs.

Upload

- Not implemented. Intention is to provide a list of compositions which have been added or amended, and allow these to be individually or collectively selected for upload. Any additions of composers will also need uploading. Login and password will be needed to update the online database to give some security and auditing control. Once updated online, the details will be removed from the local database.

Download

- Not implemented for compositions.

- Implemented for methods, but I want to add a test for new methods being found on the local database, so that they can be deleted, with advice to the user (in case a method they had stored locally has been rung by someone else). 

Re: [complib-talk] SQLite with Mono

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

Richard Smith wrote:

>> I uploaded the demo code again - It now uses SQLite as the local database.
>
> Complib/LocalComplibDataSet.Designer.cs line 10030 and
> following lines are still referencing
> System.Data.SqlServerCe.  Have you commited the wrong
> vesrion of this file?

A few other things I've noticed.

The System.Data.SQLite.SQLiteFoo classes seem to be called 
Mono.Data.Sqlite.SqliteFoo in the version I've got.  I think 
I understand the Mono vs System namespace prefix, but I'm 
puzzled about the capitalisation difference.  Are these 
class and namespace names case-insensitive on Windows?

Also, in Complib/Properties/Resources.resx, the Resources/ 
subdirectory is inconsistently capitalised.  The directory 
in SVN has a capital 'R', but some of the references in that 
file have lower-case 'r's.  That's easily fixed though.

RAS

Re: [complib-talk] SQLite with Mono

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

Graham John wrote:

> I uploaded the demo code again - It now uses SQLite as the local database.

Complib/LocalComplibDataSet.Designer.cs line 10030 and 
following lines are still referencing 
System.Data.SqlServerCe.  Have you commited the wrong 
vesrion of this file?

I notice that a lot files (including that one) contain a 
warning:

// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:2.0.50727.1433
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>

Where is the source for them, and what is the tool used to 
generate them?

RAS

Re: [complib-talk] Licensing

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

[Have just got back from a few days away and am catching up]

Don Morrison wrote:

> Others may think of other points, but I think the major consideration
> here is
>
>    If we stick with the GPL, folks that sell proving software and so
>    on will not be able to incorporate our stuff unless they make
>    their own sources freely available, which I presume they'd be
>    loath to do.

The counter argument is: why I / we / Graham put a lot of 
effort into developing the application and give it away for 
free without getting anything back in return?  By GPLing it, 
if someone creates a derivative program, we'll be able to 
use their work in future programs that we might write.

I would certainly prefer to see anything clever that I 
contribute significantly to (whether client or server side) 
under a strong copyleft licence such as the GPL.  If it ends 
up that the server and/or default client aren't all that 
clever, then I'm less concerned.

(For example, the methods database server code isn't all 
that complicated, and, although we released it under the 
GPL, I wouldn't be concerned if we changed this to something 
more perrmissive.  And the C++ client code is already under 
the more permissive LGPL.)

So I'd be quite content to leave it as GPL at the moment 
and, if part of it turns out to be fairly trivial, we can 
relicense it later.

And as Graham says, none of this stops us from documenting 
the wire protocol and allowing anyone to interface to this 
without restriction.

RAS

Re: [complib-talk] How do you run the prototype?

[Graham J. <gr...@ch...>]

Richard wrote:

> There does seem to be an issue with the loading of
> odd bell methods - look at Grandsire.

Yes. This is because I didn't initially appreciate how twin hunt methods
were held on the online method database. They are not held as lead notation
and leadend notation, but as two blocks, both of which can be symmetrical.
The first block holds 3, then the second block holds half of the rest of the
notation.

Suffice it to say - Complib doesn't deal with twin hunt methods at present.

Graham 

Re: [complib-talk] How do you run the prototype?

[Richard A. <rc...@al...>]

Graham

Thanks for all the info - I have got it working from this (although it does
seem to think I am you when running in debug mode!)

There does seem to be an issue with the loading of odd bell methods - look
at Grandsire.

Regards
Richard

-----Original Message-----
From: Graham John [mailto:gr...@ch...] 
Sent: 19 April 2009 15:32
To: 'Composition Library email list'
Subject: Re: [complib-talk] How do you run the prototype?

One further step added to the list to fix the database connection string,
and a few other tweaks to the instructions below should get anyone going
with this.

1. Download and install Visual C# Express Edition, free from
http://www.microsoft.com/express/vcsharp/

2. Download and install SQLite ADO.Net dotnet2 version, free from 
https://sourceforge.net/project/showfiles.php?group_id=132486 
In the installation box, check Visual C# Express Edition, to add
the SQLite designer components into Visual C#. 

3. Download and install TortoiseSVN (win32 version), free from
http://tortoisesvn.net/downloads

4. Create a folder called complib where you want it, right click
The folder and select SVN Checkout. In the TortoiseSVN dialog,
type the location of complib into the URL box as below and click OK
https://complib.svn.sourceforge.net/svnroot/complib

On any future occasion, right click and Update will keep Complib up
to date. If you make any changes in the directory, you can also
upload them to the repository using SVN commit.

5. Find and double-click the solution file (or open in Visual C#) 
complib/SVN/trunk/complib.sln

6. On the Visual C# menu, click on Project and Complib Properties, then
Click on the Settings Tab. Find the Connection called 
ComplibLiteConnectionString. Edit the pathname in Value to point to the
Test Complib database which is ...Complib\trunk\Complib\SQLite\ComplibLite

7. Click the green run arrow. The solution should build and run, and
Complib should launch. On the Complib menu click Tools Options and unselect
"List false compositions", as I use this option to help testing.   

This is partially developed unstable code, with virtually no validation, and
a number of features not yet implemented. If you stick to regular methods
and valid composition input though, it should work sufficiently to give you
an idea. I'll put together a list of what works and send out later.

I'll add this to a Readme when I next update it. I'll also see if I can
make the connection string a relative pathname to eliminate step 6.

Graham


----------------------------------------------------------------------------
--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
complib-talk mailing list
com...@li...
https://lists.sourceforge.net/lists/listinfo/complib-talk