[r-t] Are FCH's needed any more?

[Mark Davies]

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
 > that?

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

MBD