[r-t] delta based transposition for blue line generation
doug boniface
dougboniface20 at gmail.com
Fri Jun 10 20:04:33 UTC 2016
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).
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
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.)
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.
On 10 Jun 2016, at 03:11, ringing-theory-request at bellringers.net wrote:
> Send ringing-theory mailing list submissions to
> ringing-theory at bellringers.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://bellringers.net/mailman/listinfo/ringing-theory_bellringers.net
>
> or, via email, send a message with subject or body 'help' to
> ringing-theory-request at bellringers.net
>
> You can reach the person managing the list at
> ringing-theory-owner at bellringers.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ringing-theory digest..."
>
>
> Today's Topics:
>
> 1. Delta-based transposition representation (Alan Burlison)
> 2. Re: Delta-based transposition representation (Don Morrison)
> 3. Re: Delta-based transposition representation (Alan Burlison)
> 4. Re: Delta-based transposition representation (Don Morrison)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 9 Jun 2016 18:59:13 +0100
> From: Alan Burlison <alan.burlison at gmail.com>
> To: ringing-theory at bellringers.net
> Subject: [r-t] Delta-based transposition representation
> Message-ID: <5759AE71.6090309 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> 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, and you trivially know if a
> change is valid by summing the deltas - the result must be 0. It's also
> easy to check for other validity errors, for example the first colunm
> must be either 0 or 1 as the bell can't move off the end of the row and
> so forth.
>
> 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.
>
> --
> Alan Burlison
> --
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 9 Jun 2016 14:31:46 -0400
> From: Don Morrison <dfm at ringing.org>
> To: ringing-theory at bellringers.net
> Subject: Re: [r-t] Delta-based transposition representation
> Message-ID:
> <CAO9hiFVEvXfq1gwbfbwty=qV6XGdAf4Uu8pSssKRREzepRXXkw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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_bellringers.net/attachments/20160609/5732b1a6/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 10 Jun 2016 00:22:17 +0100
> From: Alan Burlison <alan.burlison at gmail.com>
> To: ringing-theory at bellringers.net
> Subject: Re: [r-t] Delta-based transposition representation
> Message-ID: <5759FA29.8040306 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 09/06/2016 19:31, Don Morrison wrote:
>
>> I'm sorry, but unless I am misconstruing what "reversing the signs" means,
>> I don't think this is true at all.
>
> You are right, when I actually went and looked at the code I'd written
> it didn't do that at all to generate the inverse. Oops ;-) The other
> points are I believe valid, though.
>
>>> 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.
>
> I'm not sure why having a representation that looks identical for two
> different semantics is considered to be a bonus, but that's just me.
>
>> 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.
>
> Yes, I didn't mention performance at all, I wasn't concerned with that
> aspect.
>
>> 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.
>
> Agreed, purely personally I believe the code is simpler and easier to
> reason about if you use deltas. Of course both approaches are equally
> valid but I hadn't seen the 'delta' approach anywhere else and was
> wondering if there was any particular reason why, other than common
> practice and convention. The question was "Am I missing something
> obvious?" not "The conventional way is deficient".
>
> --
> Alan Burlison
> --
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 9 Jun 2016 22:10:54 -0400
> From: Don Morrison <dfm at ringing.org>
> To: ringing-theory at bellringers.net
> Subject: Re: [r-t] Delta-based transposition representation
> Message-ID:
> <CAO9hiFWVcR=vRsY-yjZXTpCkmrENLZ+P-UKwvs83fEnHRWReYg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Jun 9, 2016 at 7:22 PM, Alan Burlison <alan.burlison at gmail.com>
> wrote:
>> I'm not sure why having a representation that looks identical for
>> two different semantics is considered to be a bonus
>
> It's certainly not necessary, but it is sometimes convenient. For example,
> if you have any operations you want to be able to apply both to changes (in
> the more general sense, such as permutation operations of lead end and
> course ends and so on) and to rows (e.g. isInCourse()) you only have to
> write them once, not twice.
>
>
>
> --
> Don Morrison <dfm at ringing.org>
> "The faults of the burglar are the qualities of the financier: the
> manners and habits of a duke would cost a city clerk his situation."
> -- George Bernard Shaw, _Major Barbara_
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://bellringers.net/pipermail/ringing-theory_bellringers.net/attachments/20160609/a17b7038/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ringing-theory mailing list
> ringing-theory at bellringers.net
> http://bellringers.net/mailman/listinfo/ringing-theory_bellringers.net
>
>
> ------------------------------
>
> End of ringing-theory Digest, Vol 140, Issue 23
> ***********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://bellringers.net/pipermail/ringing-theory_bellringers.net/attachments/20160610/6fce5e5b/attachment-0001.html>
More information about the ringing-theory
mailing list