Seifert Matrix implementation to various invariants …..

Hello everyone,
The past week has been decent. I have managed to send in a pull request which has the implementation of Seifert Matrix and related methods. That was a roller coaster ride week. I was a bit relaxed as I was done with the implementation by Thrusday, I was verifying its correctness against the Seifert program on Friday and there came the inconsistencies. The array used for creating the homology_generators was completely wrong, then correcting it gave further problems with the method braidwordcomponents(), then I discussed the implementation with Miguel and he said it would be better to re-think the logic. So that explains why I was consistently changing the gist that I posted on the previous post. I took time and wrote the logic for braidwordcomponents,  and started to implement other parts as well. Genus method implementation took a bit of time, as there were some issues with the smallest_equivalent method and the logic that went into genus method implementation. Once that was done, the others were mostly dependent on the Seifert matrix. So to brief the structure …
It starts with any input being converted to braid —->>>   generate the _braidwordcomponents —- >>> generate the _braidwordcomponentvector
The above methods form the machinery for the remaining methods. Then we generate the homology generators leading to Seifert Matrix.
Seifert Matrix is mainly used in the computation of the Alexander polynomial. Mostly the remaining methods implemented keep playing either with the machinery or Seifert Matrix. The results have been checked with the Seifert program hosted online (http://www.maths.ed.ac.uk/~s0681349/SeifertMatrix/#alphabetical).
So that concludes the implementation of Seifert Matrix related methods, I have tried to document it to a good extent, and that said there is a lot that needs to go into documentation.

The pull request :

https://github.com/miguelmarco/sage/pull/3

I guess we are on schedule or perhaps say a bit ahead.
So the next targets :
1. Checking on the speeds of  Alexander polynomial of present implementation with the already implemented method.
2. Lazy imports is one which I need to work on for the stuff that is being imported
3. Conversion between DT Code and Gauss Code
4. A basic idea of Vogel’s algorithm and its implementation
1 & 2 are the medium ones, while 3 &4 are the top priority and they form the target for the week.

Hope you are finding this understandable as I tend to get too messy at writing. Well this has been a great experience for me till now. To end, many thanks for reading through.

Advertisements

Seifert Matrix , the first week ….

Hello everyone,
The blog post got delayed because of various reasons,  mainly because of my travel. However I have managed to code decent amount after the discussion with Miguel last week. This week the target was to achieve the Seifert Matrix implementation with all other related methods. The Seifert matrix implementation has been achieved and the next aim would be to write the documentation and tests. The other parts like genus,  arf invariant and signature remain.  A draft of the code is here

https://gist.github.com/amitjamadagni/fe7536070b69ab31f031

PS: The above link has been changing every now and then, I guess this is the fourth time I have changed the link. First they were inconsistencies while testing, so had to rethink a part of it. Now this is fine and has been verified with the Seifert program. If any inconsistencies found, please send in a message. Thanks 🙂 . The above gist is decently documented and can be loaded directly into the sage cell for usage.
I guess the target for the week has been achieved but still few methods surrounding have to be implemented.

Dynamism, Braid Project ….

The last week, I was mostly busy with the semester end exams at our University. Doing 8 courses per semester is a pretty heavy task and the end-semester exams are no less. They started off on 5th and will be going on till 16th, so I could not make much progress. However we had the discussion on integration of Spherogram, rather we are considering it to be a package of inspiration, and if possible would use the peer code implementation which would be helpful in Vogel’s algorithm implementation. We had a discussion on the dynamism(able to perform Reidemeister moves on the given link), this gave rise to a completely different way of looking at the structure of the link. But we decided not to move away from the already discussed implementation, and at the same time not lose the dynamism, so we are looking forward to implement a method which could return the link after the moves are done. And coming to the Braid project, Andrew has yet to give his comments on licensing, if he does then we can go ahead with the wrappers or they could be a lot of re-implementation happening. That’s a pretty short update. Thanks for reading through.

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.