[r-t] A new Spliced Surprise Major canon

[Graham John]

MBD wrote:

> The key improvement was to abandon false node tables and instead work
> with leads. That needs much less memory and means the table build is only
> O(n^2) with respect to the number of different leads

Yes, I was a bit puzzled when you said how much memory your proving tables
were taking up. Presumably you also pre-calculate the music score for each
lead and hold them in the table.

> Availability of large amounts of RAM allows greedy algorithms such as
> the one you describe to work better on modern machines. 

Yes, I would now also be able to get rid of many constraints of my old
software. 

> I didn't really see this [calling structure] as a problem, but I guess
you're right, it
> could be a constraint for algorithms that use single steps, varying just
> one node at a time. In some senses it is just a special case of
> falseness between nodes, but perhaps it is one that it is worth dealing
> with. I think the best approach would be to combine nodes which visit
> the same course into a single node, and vary it as one. 

You are working with a predetermined calling (as I did) which is actually a
big constraint. If you have a course split into two blocks, you have four
fixed entry and exit points to contend with. Even with one block like those
in NCR callings you still have one fixed entry and exit. Another technique
is to find groups of mutually true leads in a minimum number of courses that
have the properties you want, and then try and link them together. Obviously
there is also a downside with this method, that linkage may be impossible.

Graham