[r-t] Extension

[Tim Barnes]

On Apr 23, 2015 9:35 AM, "Don Morrison" <dfm at ringing.org> wrote:
>
> On Thu, Apr 23, 2015 at 9:05 AM, Robin Woolley <robin at robinw.org.uk>
wrote:
> > I revised the Extension document some time ago - we just haven't got
around
> > to publishing it although one member of this list did receive a copy by
> > request
>
> Could you forward it to the whole list, please? I think several of us
> would benefit by some explication.
>
> Thanks!

Robin - yes, it would be very helpful if you could post your Extension
document to this list.  So far you're the only person to respond saying you
have something that can help interpret Decision (G), so it seems this is
rare information.

You may be right that a big challenge is writing the algorithm down in a
way that's clear.  I'm having the same challenge with PABS's algorithm and
will probably have to ask for help on how to relate the red and blue
asterisks to the written description of the algorithm.  But thanks, Philip,
for posting it - it looks interesting and reads as a generic way of
extending methods.

But it does seem, as Tony and Philip E have noted, that some parent methods
will always be able to extend in more than one way.  It's curious in some
ways that the Exercise has adopted a 1:1 naming solution to a 1:many
problem.

In terms of what could / should be done in a revised set of Decisions, I
imagine most of us would agree that any method that is already named should
keep its name, even if under a new algorithm a method now has a
differently-named parent.

Presumably under any algorithm some methods won't extend, so there's a
question of whether bands should have discretion to name extensions in good
faith in these cases.  I would think they should.

Then there's the question of whether all extension naming should be at
bands' discretion, and algorithm(s) serve as guides, or whether, if an
extension fits into the algorithm, it has to take its parent's name (unless
the name has already been taken under a different extension route).  This
seems to depend, at least in part, on whether there is really only one
viable algorithm (with PABS's viewed as a more generic version of Decision
G), or if there are many algorithms, all conceptually valid, but each
producing different results.  If it's the latter, it seems hard to justify
mandating an arbitrary algorithm.  If it's the former, I can see the
argument to use it where it works, perhaps with additional
cross-referencing in the method library to link additional extension
relationships (Bristol to Littleport, etc).

TJB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://bellringers.net/pipermail/ringing-theory/attachments/20150428/705c23c6/attachment-0004.html>