[r-t] Are FCH's needed any more?
mark at snowtiger.net
Sat May 22 14:26:31 UTC 2010
Peter King asks,
> What I would be far more interested in learning about is how we
> can use these concepts in computer proof and composition generation.
> There's lots of discussion in this list about SMC32(and similar)
> and trees and nodes etc it would be very informative to have an
> explanation of these and a simple training example of how to use
> these to generate compositions more efficiently. Could someone do
I made some efforts to document this sort of thing in the SMC32 user
guide - I don't think you're on the (so-called) beta test programme for
SMC32 Peter, but happy to send it you if you want.
Again, this would be a useful topic to cover on the Wiki. The basic idea
of a computer search is pretty straightforward. There are two bits:
1. The table build. Here we turn the search space into a network of
nodes. This is generally very quick, so we make use of the power of the
machine to do as much work as possible, in order to help the search phase.
2. The search. Here we perform a tree seach on the node network. This is
the big job, hence the need to do as much preparation work in the table
build as possible.
What is a node? It's an atomic part of the search space. It has links to
other nodes, caused by calls at the end of the node, but cannot be
divided by calls. For instance, in Yorkshire, the lead from the Middle
to the Wrong in coursing order 24653 might be one node. There are 60
other nodes from M-W for bobs-only tenors-together searches. If we were
looking for three-parts with a 5678 part end, you could even consider
coursing order **56* from M->W to be a single node, reducing the count
to 20, and dramatically improving your search. Other nodes would cover
more leads - for instance, H->B is two leads. For tenors-together
searches, you have reasonably low numbers of nodes (typical 120 times
5), for tenors-split searches you might have hundreds of thousands of them.
The clever thing about the table build is that you can use it to
restrict the search in all sorts of ways. For instance, you could delete
some nodes, so the search will never visit them. Why? Perhaps you have a
split-tenors section that you want to incorporate into a tenors-together
composition. Simply delete all the tenors-together nodes your
split-tenors section is false against, and run a tenor-together search.
You'll get a touch into which your split-tenors section could be included.
Similarly, you can join nodes up in the table build. Perhaps you have
composed two or three big blocks which you want to link together into a
peal. In the table build, simply join up the nodes that form these
blocks, so that once the search algorithm reaches the first node in a
block it has no option other than to follow your calling. The result - a
very efficient linkage search that joins up human-composed blocks into
the optimal peal length.
With both these techniques, the actual search algorithm is unchanged;
it's just the table build which is affected. That's good, because we can
keep the search as speedy as possible.
This kind of technique has I believe revolutionised computer
composition. It turns the machine from a blind churner-outer of dull
multipart compositions, into a dynamic tool able to work alongside the
human composer and extract the best from machine speed and human ingenuity.
Don is probably the originator and still the prime proponent of these
techniques, as even a brief look at the quality and quantity of his
output will confirm. However, this sort of approach is in theory now
available to anyone in SMC32, although I'll admit it does need to get
More information about the ringing-theory