[r-t] delta based transposition for blue line generation

[Alan Burlison]

On 10/06/2016 21:04, doug boniface wrote:

> An interesting approach but I think I must be missing something as
> well. I assume you are calculating your deltas for each row from the
> place notation and then the blue line co-ordinates from the deltas.
> Surely this leads to the same amount, if not more, code than working
> directly from PN. If not I'd be very interested to know how its done
> (and I mean that seriously not cynically).

First thing to note is that I'm using a functional language (Scala) 
which is excels at applying functions to lists and other similar data 
structures, so converting to that type of format at the start makes 
subsequent operations much simpler.

To search and download a method's XML definition from 
methods.ringing.org, extract the PN and convert it from text into delta 
form is about 80 lines of code altogether. The core is 16 lines which 
parses the text PN and converts to deltas. The core algorithm is to 
generate pairs of 'swaps' (+1, -1) for each 'gap' between numbers in 
each Change represented in the PN, and replace the digits in the PN with 
0, as they denote the bells that don't move place. e.g. for the first 
change of PH Doubles:

"5" -> (+1,-1)+(+1,-1)+(0) = (+1,-1,+1,-1,0)

I expect that's more use than the code ;-)

     def expandPart(pn: String): Seq[Seq[Int]] = {
       for (c <- 
pn.split("""\.""").flatMap(_.split("""(?<=-)|(?=-)"""))) yield {
         c match {
           case "-" => swaps(stage)
           case _ => {
             var p = c.toSeq.map(CCBRToPlace)
             (swaps(p.head) :+ 0) ++
              p.sliding(2).flatMap({
                case Seq(a) => Seq.empty
                case Seq(a, b) => swaps(b - a - 1) :+ 0
              }) ++
              swaps(stage - p.last - 1)
           }
         }
       }
     }

Where 'swaps' is simply:

Range(0, num_swaps).map(s => if (even(s)) 1 else -1)

There's a bit more wrapping code, the result is a list of delta lists 
(Changes), each of which describes a single change, e.for PH Doubles:

Block(Change(1,-1,1,-1,0), Change(0,1,-1,1,-1))

Applying a Change repeatedly to a Row to expand an extent is trivial:

     val changes = plainHunt.forever
     var row = ring.rounds
     do {
       row = row * changes.next
       println(row.toCCBR)
     } while (row != ring.rounds)

The implementation of the '*' operator that applies a Change to a Row 
and returns a new Row is 1 line of code:

     def *(change: Change): Row =
      new Row(change.deltas.zipWithIndex.map(di => places(di._2 + di._1)))

Rows are represented as 0-based bell numbers and if for example if we 
start with reverse rounds and apply the first change of PH5 to it:

Row(0,1,2,3,4) * Change(1,-1,1,-1,0)

That first step maps the Change into a sequence of (delta, index) pairs:

((1,0),(-1,1),(1,2),(-1,3),(0,4))

Then add each of the inner pairs together to give:

(1,0,3,2,4)

Then uses those as indexes into the bell numbers in the old row to form 
the new row:

Position  Old row     Index  New row
    0         4          1       3
    1         3          0       4
    2         2          3       1
    3         1          2       2
    4         0          4       0

As I said in earlier mail the internal representation is really just 
down personal preference - I find the delta notation easier as it is 
expressed in terms of relative moves. The first version I wrote used 
'conventional' notation, there's not a huge amount of difference in 
terms of code complexity - and I have code to convert between the two 
representations anyway.

> I have also had the need to generate blue lines from place notation
> but decided to abandon tracking the whole row at each change and just
> track one bell. At the risk of the terms “Grandmother” and “suck
> eggs” coming to the minds of some readers, my approach was broadly:
> create PN for whole lead as:

> full PN = PN + HL + reverse PN + LE

Yes, for methods of that form that's what I do.

> select a start bell
> for each entry in full PN
> if entry = X
> move up or down 1 place according to if odd or even place
> else if at the place in PN entry
> stay in current pos
> else
> diff = place in PN entry – current position
> (Now determine move direction by whether diff is +ve or -ve, odd or
even and if the relevant place entry is odd or even.)

Sounds kinda like deltas to me ;-)

> There was a bit more detail in the full version to cope with methods
> that had multiple internal places. The results were fed into an array
> and used as co-ordinates by the line drawing functions.
>
> The whole block can be used to to generate the line for any given
> place bell or put in a loop to get the line for the whole method
> given any start bell.

Mine just dumps out ASCII as I know there are existing things that draw 
far nicer pictures than I could be bothered to generate, and the main 
aim was just to help me fully understand place notation, which it did.

-- 
Alan Burlison
--