Link class, Wrappers, structure ….

Ah! Okay its already been a week and the last week was pretty decent. The main aim of the week was to analyse the pros and cons of Plink and Spherogram for the link class which would form the basis of the project.  While this was running in the back of my mind, I also started to look through Vogel’s algorithm implementation which would determine the Braid word representation of Link given labelled peer code as input. In the first part I would present the progress pertaining to Vogel’s Algorithm implementation. In the second part I would be presenting a analysis of Link class structure from Plink and Spherogram.

First part :
So we had this task of converting Gauss code to Braid word representation, an important link in the project. I started to go through various software, until I came across Braid Project which has some extensive results related to Braid word. Some exceptional work has been done in developing the package. I was browsing through the code and Miguel sends me a mail asking whether Braid program was compiling ?? I was till then browsing the code and still did not get it running on my system. Immediately I set off for the installation and it went smoothly for me but Miguel was having a problem. That sparked off a discussion which had two implications :
1. Re-implement the entire logic.
2. Wrap the present code.
1 and 2 had strong reasons in support for them. the first reason would give more flexibility, easy code maintenance. The second would save time by not re-implementing the entire logic. The problem with the first was it would take time and resources, and the problem with the second was compiler issues (which were faced by Miguel as he was using a more recent version of the gcc compiler) Added to this there were license issues, as the project was not released under any particular license. Two mails one to the sage-dev list and one to Andrew (the author and maintainer of Braid project) were sent addressing the subject. Andrew has yet to reply on the license issue and I guess the community is in favor of patching up the work by replacing the libraries used in the present code (for example bigint library has to be replaced by gmp) and they are as well okay with rewriting but prefer the former than the later. This has been the progress till now.

Second Part: The interesting one …..
Okay on first sight Plink and Spherogram both sound great. Here is the analysis.

Plink : Class LinkManager has the machinery

Spherogram : Class Link has the machinery
Input :
Plink : Takes in a file which has the following information (it can take input in 3 different forms : Link Projection, triangulation, generators. We consider the case of Link Projection as it is more fitting and it is well documented) :

Number of each one is to be mentioned followed by the information.

1. Components (with start-vertex, end-vertex)

2. Vertices (Takes in 2D co-ordinates as inputs, arbitrary start and end)

3. Edges (Start-vertex, end-vertex)

4. Crossings (Under-edge, Over edge).

Shperogram : Takes in 2 different kinds of inputs : Planar Diagram Code, Gluing up the Crossings (There is extensive machinery for this).

So here just the Planar Diagram and Gluing crossings will do the job, less number of inputs compared to the extensive input given to Plink
Coding Paradigm :
Plink : The link manager has many methods to manipulate around. The structure of the code uses less classes for internal representation therefore giving less freedom on the individual aspects. For example, it has classes like Arrow, Vertex and Crossing. The functionality of these is set so that we the methods in LinkManager work.(It is more methods for the front-end).

Moving through the methods, as most of the information is gathered from the input, it is well manipulated. The structure is as follows :
Initialize everything to null (list or required data-structure). Then these are filled up by reading the file, using  temporary locations and then using pickle method. Then the machinery starts to work on methods like arrow_components which returns a list of components, by working on the vertex data. Then this is followed by the crossing_component which returns a list of ecrossings. Then the sorted components which uses Morwen’s rule and returns crossing components and also has the logic which sets the hit counters. These methods are used to return the PD_Code( crossing_components), DT_Code(Sorted Components) , Gauss_Code (DT_Code).

Spherogram: Every component of the link structure has a class and has methods to play around. It has the following classes :
Crossing : for instantiating a crossing, the methods here allow the user to rotate as well as join around stuff.
Crossing_Strand : Has methods pertaining to each incoming strand at the crossing.
CrossingEntryPoint : entry points of the oriented crossing are worked on by the methods the class.

Strands : This has methods to play around with the components (has methods like fusing, getting the label)
Then the Link class uses the above machinery in using the input which is either in the PD code, or got by gluing the crossings.
Compared to the features of Plink, Spherogram offers the user a lot more to play around with the basic structure of the link. Plink has the basic methods for building the structure of the Link (Remembering it is used as a graphical tool, the functionality is more in that direction).

I guess we could have a good combination of the both to represent the basic structure of the link, for example taking in the input as any of these options would provide the user with a great amount of choice.  Then the translation from one to another could be carried out by the already implemented logic.  Flushing the not so necessary parts of Spherogram and integrating the features of Plink would help in creating a great package for the analysis of Links in general.

In order news, I have received a diary and pen from Google as a welcome pack for being selected as GSoC student :). Thanks for reading through.