[r-t] Delta-based transposition representation

[Don Morrison]

On Thu, Jun 9, 2016 at 1:59 PM, Alan Burlison <alan.burlison at gmail.com>
wrote:
> A while ago I wrote some code to expand place notation to the
corresponding blue line numbers. One thing that I did to make my life
easier was to describe the difference between two rows as deltas. For
example the change between the following two rows:
>
> A  1 2 3 4 5 6
> B  2 1 4 3 6 5
>
> would be:
>
> +1 -1 +1 -1 +1 -1
>
> Between the two ends of a sequence of rows:
>
> A  2 6 4 1 5 3
> :
> N  5 3 6 2 1 4
>
> +3 +1 +3 +1 -4 -4
>
> i.e. the bell in place 1 (#2) has moved +3 places to place 4. the bell in
place 6 (#3) has moved -4 places to place 2.
>
> Applying a change to ma row is very simple - just add the deltas to the
current bell positions. It's easy to create the inverse of a change by
simply reversing the signs of the deltas

I'm sorry, but unless I am misconstruing what "reversing the signs" means,
I don't think this is true at all. All (non-jump) changes are involutions,
and the inverse of a (non-jump) change, C, is always just C. For example,
look at your first example above: reversing the signs you'd get -1 +1 -1 +1
-1 +1, which, as you've already noted, is illegal since it has a -1 in the
leading position. Or have I misunderstood something?

> I haven't seen changes described this way anywhere else which
> puzzles me a bit, because to me it's the blindingly obvious way of
> doing it, rather than the position-based notation I've seen used
> elsewhere.

I can see it may be a slightly more convenient representation when drawing
bluelines, but I'm not seeing any particular reason for generally
preferring it over the representation that keeps changes and rows
represented in the same way. It's a trivially easy, linear time (that is,
proportional to the stage) transformation from one representation to the
other, so it seems unlikely it offers any big performance improvement for
any operations you might want to perform. In fact, I suspect that on many
underlying hardware architectures it might be slightly slower at the
permute-a-row operation since you need to do some explicit arithmetic
before dereferencing the element of the row -- I'm not sure about that,
though, and such minuscule performance issues are rarely worth worrying
about anyway. Like so many things in ringing and in life I suspect it all
just comes down to your personal taste and what you find the most congenial
representation for the code you're writing.

Or am I missing something?



-- 
Don Morrison <dfm at ringing.org>
"Premature optimization is the root of all evil."
  -- Donald Knuth, "Structured Programming with Go To Statements"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://bellringers.net/pipermail/ringing-theory/attachments/20160609/5732b1a6/attachment-0002.html>