Other conventions for braids and loops

[jeanluct]

It would be nice to allow the user to use different conventions for braids (right-to-left, counterclockwise) and loops (Dehornoy, etc.)

Could implement this using dependent properties and an internal default, such as in this example, which I also used to define n in the braid class.

[jeanluct]

From Jean-Luc Thiffeault on 2014-09-29 18:16:57+00:00

Toby and Oyku seem to use left-right for braid generators, but counterclockwise interchanges.

[jeanluct]

From Jean-Luc Thiffeault on 2014-10-07 19:57:08+00:00

For braids: Would two flags be enough?

readdir: 'left-right' vs 'right-left' (default 'lr')

rotdir: 'clockwise' vs 'counterclockwise' (default 'cw')

Can we take care of everything at output? I'm not sure if this is easy. After all, we have access to "word" semi-directly. That is, a user can do: b.word = myword. Should we then be reversing it? Not sure. Maybe make privateword the internal word, with private access, and word itself a dependent property. But then all the code should internally use privateword.

Must doublecheck how indexing works.

[jeanluct]

From Jean-Luc Thiffeault on 2014-10-07 20:44:25+00:00

Here's an example, the class braidconv:

#!matlab

% Test class: braid with user-defined convention for left-right and
% clockwise/anticlockwise.

classdef braidconv
  properties (Dependent)
    word
  end
  properties %(Access=private)
    lr = 1;    % 1 for left-to-right, -1 for right-to-left.
    cw = 1;    % 1 for clockwise, -1 for counterclockwise.
               % Maybe this should only be in 'loop'?
               % Or only used in braid.mtimes?
    pword
  end

  methods

    function obj = braidconv(w)
      obj.word = w;
    end

    function obj = set.word(obj,value)
      if obj.lr == 1
        obj.pword = obj.cw*value;
      else
        obj.pword = flip(obj.cw*value);
      end
    end

    function value = get.word(obj)
      if obj.lr == 1
        value = obj.cw*obj.pword;
      else
        value = flip(obj.cw*obj.pword);
      end
    end
  end % methods
end % classdef

I'm not making the conventions private just yet, for testing. Here's an example:

#!matlab

>> b = braidconv([1 2 3])

b = 

  braidconv with properties:

     word: [1 2 3]
       lr: 1
       cw: 1
    pword: [1 2 3]

>> b.lr = -1     % change convention to right-to-left

b = 

  braidconv with properties:

     word: [3 2 1]
       lr: -1
       cw: 1
    pword: [1 2 3]

>> b.cw = -1     % change convention to counterclockwise

b = 

  braidconv with properties:

     word: [-3 -2 -1]
       lr: -1
       cw: -1
    pword: [1 2 3]

>> b.word = [-4 -3 -2 -1] % now define word (read right-to-left)

b = 

  braidconv with properties:

     word: [-4 -3 -2 -1]
       lr: -1
       cw: -1
    pword: [1 2 3 4]

>> b.word(2) = 2 % change the second generator, read from right-to-left

b = 

  braidconv with properties:

     word: [-4 2 -2 -1]
       lr: -1
       cw: -1
    pword: [1 2 -2 4]

In the last step this does the right thing: the user is setting the 2nd element, but this is the 2nd-to-last in the internal representation.

Multiplying by cw is probably not the right way to go. Rather, just use cw when applying braid.mtimes to a loop?

Does something need to be changed about the product of two braids? Inverse?

[jeanluct]

From Jean-Luc Thiffeault on 2014-10-07 20:47:35+00:00

The above examples are in devel in 9c99cda.

[jeanluct]

From Jean-Luc Thiffeault on 2014-10-07 21:05:34+00:00

Maybe I'm also overdoing it for the property lr: after all, the direction in which the braid is read is immaterial until we act on a loop? And maybe when plotting?

Need to do a bit more research of how these conventions are used, and how it matters in practice. See for example Birman's book.

[jeanluct]

From Jean-Luc Thiffeault on 2014-10-07 23:20:44+00:00

Actually, global variables might be better here. If I'm Toby I don't want to pass the option 'clockwise' every time I create a braid. So instead set values for BRAIDLAB_braids_act_clockwise and BRAIDLAB_braids_act_right_to_left or something.

[jeanluct]

Ok, I think I found the right way to do this. See branch iss64-other-conventions.

Basically there is a function prop that sets and gets properties, which are stored as persistent variables. The advantage is that there are not global variables, which is less messy and maybe more efficient.

Example:

>> prop('GenRotDir')

ans =

     1

>> prop('GenRotDir',-1)
>> prop('GenRotDir')

ans =

    -1

Here GenRotDir stands for generator rotation direction.

[jeanluct]

Also implemented GenOverUnder property, to affect how braids are plotted.

[jeanluct]

Is it worth moving all of braidlab's globals to the prop system? Supposedly globals have a speed hit, but I'd like to test this. The reason is that a function then has to search a larger pool of variables, but doesn't that depend on how many variables are defined? Maybe do a test.

[jeanluct]

See http://stackoverflow.com/questions/7888899/global-could-be-very-inefficient http://www.mathworks.com/matlabcentral/answers/19316-global-could-be-very-inefficient#answer_25760

[jeanluct]

Ok, now implemented a few conventions: GenRotDir, GenPlotOverUnder, BraidPlotDir.

Example:

>> prop('BraidPlotDir','lr')   % plot braids from left to right
>> plot(braid([1 -2]))

[jeanluct]

What's left?

• Options for loop coordinates for braids (Dehornoy, etc. See braid.loopcoords). This is easy since the options are already checked for in loopcoords. Just need to use prop instead of function arguments. Keep function arguments? Probably not worth it: just mention flags. I worry about an interaction with this and with GenRotDir and the next two conventions, though. In other words, maybe there should only be a left/right option for the position of the boundary puncture in loopcoords, but one would get Dehornoy by setting left and GenRotDir=-1.
• Sign of Dynnikov coordinates. (Toby&Oyku vs us.) Implement this as set.coords / get.coords? But be careful: methods for the loop class will call coords with not set/get, but others will go through them. Is this ok?
• Order of application of generators on a loop. Possible name: GenLoopActDir.

[jeanluct]

Implemented LoopCoordsBasePoint in c90590d.

[jeanluct]

Well, I just doublechecked the convention that Oyku and Toby use, and it's the same as ours. So for now no need to have an option to change this.

That leaves GenLoopActDir. Implement just like GetRotDir: look for applications of loopsigma, reverse order. Should this also be used in loopcoords? Probably...

[jeanluct]

Implemented GenLoopActDir as above. I think maybe that's enough for now, as far as this issue is concerned. Other properties to be added as needed, but they can get their own issue.

The only thing left is to document the properties.