This week we have been working on editing the code to reach the standards along side running the tests. A decent amount of time has been spent on documentation. Plot methods and 3d co ordinates seem to be taking a longer time and even Miguel is giving this a good thought, so as of now these remain still in the thinking phase. In the meantime Miguel has shared some great work regarding the implementation of HOMFLY polynomial, stronger invariant to distinguish links. I am enjoying myself going through it as it shows how it is related to few other things which are of interest to me. Here is the link for it

http://www.maths.dur.ac.uk/Ug/projects/highlights/PR4/Goulding_Knot_Theory_report.pdf

So as a part of it I have implemented the dowker notation which is nothing but the (Ux, Ox) that is under-cross, over-cross at a particular crossing. This was a straight forward implementation as we had everything already present the PD code and the orientation of the crossings. In addition to this we have been working on the code to make it better and more cleaner. We have dropped the support to take in key words, now it is just that we directly give in the input for the link (the user need not mention whether it is a braid, PD_Code, or oriented gauss code) we have made it possible to detect from the way the user inputs what kind of input it is. There are few minor issues with code refactoring which we have been working on. Here is the link for the latest code :

https://github.com/amitjamadagni/sage/blob/week14/src/sage/knots/link.py

]]>

There has been a delay this time. This week I have worked on cleaning the code and I am trying to get to the standard required as well trying to clear the bugs which come along. I have been studying the theory on plotting (not really the theory but the components required for implementation). The inspiration mainly comes from Graph theory and network flows. I have been trying to understand what is going in the Spherogram package where they try to generate the data required for the plot and use plink to get the diagram using this data. The focus has been on to achieve the data they have got and use it via the sage methods rather than directing it to plink. The code is mainly present in the orthogonal.py file and they have used orthogonal representations to generate the plot. The one thing which is basic and still not clear is what are they considering as vertices. While I was working on this, I and Miguel had a meeting on Monday and we had some issues to be resolved before we moved forward. I have resolved the issues which were arising in the seifert_to_braid method and have added the __repr__ method. The issue with seifert_to_braid was with the ordering of the seifert_circles. Previously the idea was to find the intersection of the seifert circles with others (as initially we had used the idea of consecutive numbers for naming the edges) by adding a one and subtracting and checking on the intersection. But I over looked this part when I worked on the extension to links and it stuck me here, that I had to even edit this. Now I have edited this part and now we check for the intersection of seifert circles with the pd code, remove all the crossings which share the seifert circle numbering and at the same time select one of the crossings which share the seifert circle and construct a variable which had only parts other than the seifert circle. Now we use this to find the intersection with the other seifert circles and so on and so forth, in this way we order the seifert circles. The __repr__ method has been straight forward. I have removed the method smallest equivalent and replaced the name of the link_number with ncomponents.

Moving on I worked with Jones polynomial, I had this doubt whether the smoothing would depend on the orientation of the crossing. The answer was that it does not and that made my things easy as I had to just refine the earlier code which took into consideration the orientation of the crossing. So now I can say atleast the Kaufmann’s polynomial works fine, to get to the Jones polynomial, I would have to replace the polynomial variable by t^(1/4) for which I have been searching around with no answers. I would be working on the plot methods this week and try to see if I can get something out.

This is the last week before the pencils down, however I will try to continue the work and blog accordingly. I have learnt a lot during these two months, it has been a fascinating journey and I would be continuing my work post GSoC on making things better. I hope you have enjoyed reading the posts (sometimes I have not moved into the details, because I wanted to keep it simple). I will be continuing to blog my posts and hopefully the work till now can get me across the final evaluation.

I would like to leave you with some examples of Jones polynomial (without the t^(1/4) substitution) and also the work till now.

sage: L = link.Link(B([-1, 2, -1, 2, -3, -2, 1, -2, -3])) sage: L.alexander_polynomial() -2*t^4 + 5*t^3 - 2*t^2 sage: L.jones_polynomial() t^24 - t^20 + t^16 - 2*t^12 + t^8 - t^4 + 2 sage: L = link.Link(B([-1, -1, -2, 1, 3, -2, 3])) sage: L.alexander_polynomial() -2*t^3 + 5*t^2 - 2*t sage: L.jones_polynomial() t^16 - t^12 + t^8 - 2*t^4 + 2 - t^-4 + t^-8 The white-head link: sage: l5 = [[1,8,2,7],[8,4,9,5],[3,9,4,10],[10,1,7,6],[5,3,6,2]] sage: L = link.Link(PD_code = l5) sage: L.jones_polynomial() t^14 - 2*t^10 + t^6 - 2*t^2 + t^-2 - t^-6 The Right Trefoil sage: L = link.Link(B([1, 1, 1])) sage: L.jones_polynomial() t^-4 + t^-12 - t^-16 The Left Trefoil sage: L = link.Link(B([-1, -1, -1])) sage: L.jones_polynomial() -t^16 + t^12 + t^4 The Hopf Link sage: l1 = [[1,4,2,3],[4,1,3,2]] sage: L = link.Link(PD_code = l1) sage: L.jones_polynomial() -t^10 - t^2

And here is the link for the latest code :

https://github.com/amitjamadagni/sage/blob/week13/src/sage/knots/link.py

Thanks for reading through.

PS: I mentioned in the previous blog that 3d input was the priority, but as 3d inputs and plot were more related, I choose to work on the latter. 3d inputs require projecting the lines into 2d but I have not found any methods around which would make things easier. Plot looks to be more achievable. Yet I will work on the 3d inputs but for now the plot seems more interesting.

]]>

This week we mainly focused on jones polynomial. The orientation method had few edits and we are expecting it to be fine. I started out with the implementation of jones polynomial, the previous version where the trip matrix was used was restricted to knots. That method mainly used the oriented gauss code but in this implementation we have used the PD code so that it would work for links as well. I have tried to comment in the code the method I have followed, the outline of the procedure has been taken from

http://katlas.math.toronto.edu/wiki/The_Jones_Polynomial#How_is_the_Jones_polynomial_computed.3F.

There are few things which remain to be implemented, mainly like accepting the 3d coordinates and HOMFLY polynomial. Few methods have to be renamed and a I guess there is work remaining in the documentation part of the code. This week the focus would be on accepting 3d coordinates and converting it to PD code that would allow the conversion to braid or oriented gauss code. So the target for the week would be

1. 3d coordinates (the priority)

2. Renaming the methods

3. Storing (this has been pending for a good amount of time, the idea is once something related is computed we store it, this is being achieved by creating an object which is not an efficient way of doing things).

Hopefully I can get the above things working. That’s it from me and thanks for reading through.

Here is the pull request for the week,

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

]]>

The last week we focused on extending the current functionality to links. That involved a lot of refactoring the code. The methods have become more general and work for links. Some of the issues like naming of the methods and storing once a form of representation is calculated are some of the few which remain to be worked upon. This has been a great learning curve for me. Many things were edited which includes addition of the method orientation which gives the signs of the crossings. That was really helpful in formulating the other structures. There was one other issue in the vogel move, this had a case where the pulling of the higher strand onto the lower one did not lead to a generalization on constructing the new crossings. The issue was resolved as we looked upto the strands in the regions and decided how the crossings would be generated. If the strands were positive, one kind of crossing were obtained and if the strands were negative the other crossings were obtained. I had this thought but I was not sure whether it would work for all cases, Miguel chipped in and gave me the idea in a more concrete setting. So that set the method vogel move up. The rest was revamped and a lot of cleaning has been taking place in the code to remove the stuff which is not necessary. Hope we have most of the functionality by the end. That’s it from me. Thanks for reading through and here is the latest pull request.

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

]]>

The last week we focused on the conversions. Some parts are ready for the knots, in sense the standard input conversion is done but there is lots more to add to it. We are returning the braid word as of now where we need to return the braid itself. That would give access to the other methods like the Seifert Matrix and Alexander polynomial. As of now we are thinking of conversions for the links. The braid to pd code has been edited. We no longer maintain the order the crossings, it is just that we encounter a crossing and we start numbering , previously we used to trace the braid out and then order the crossing accordingly. This week the focus is on converting pd code to braid for links, but it seems that we need to even consider the signs for the crossings, this might affect the way we have been considering the pd code uptil now. There is one more way we can look at the pd code that is assign four new numbers at each crossing, that would completely change the way we have looked at the pd code and would also call for lot of re implementation. I guess considering the signs should be the possible way out for the pd code of the links. In knots we did not have this problem as it was a more structured structure. This is taking a lot of time than expected. Hopefully we have the implementation for links and all issues resolved by this week. Still there is the invariants which have to be implemented (the conway, homfly) but for now the focus is totally on the conversions. That’s it from me. Thanks for reading through. And here is the pull request for the week.

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

]]>

This week we have made an attempt at implementing the Jones Polynomial. We have used the trip matrix of the knot to determine the Jones polynomial. The trip matrix of a knot is determined by the following process. We number the crossings randomly, and we start moving along the knot, let T be the matrix and T

First Reference:

http://www.math.nus.edu.sg/~urops/Projects/knot.pdf

Second Reference :

A matrix for computing the Jones Polynomial of a Knot by Louis Zulli

We have dedicated some time for documenting the code that we coded till now. There have been some edge cases where the code showed some inconsistency. We are working on the edge cases as well as cleaning the code alongside continuing the implementation of the invariants.

Here is the pull request for the week:

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

Here is the entire code uptil now:

https://github.com/amitjamadagni/sage/blob/b94bf8d9db77dd8ec52b92fe1da32f9bd9010e03/src/sage/knots/link.py

]]>

The past week has been really on the thinking end. The task was to detect the braid word from the oriented gauss code. So I mentioned the dots were to be connected, but then I had problems implementing it. I was thinking more and more rather than a looking for the straight implementation. It took me a week to break through and then I had some consistent results. So they were various ideas on how one could detect the braidword. One was to update the outgoing strands after each crossing has been looked into and then match it with were we have the incoming. I was working on various other ideas as well as I felt there was some kind of difficulty on the implementation end. Here are the gists of code on the ideas I worked upon.

The ones I attempted

https://gist.github.com/amitjamadagni/1ccad5ca91b96eac367b

The one which is working

https://gist.github.com/amitjamadagni/57b5de098efe11056efa

This was like I had all the answers yet I was missing something. There are some glitches still though, small condition on the seifert circles one is missing. I need to work on the documentation end as we are missing on that. And here is the pull request for the past two weeks.

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

Lot of work as to be done on the documenting and testing side of the code. Here are the results for the algorithm

sage: from sage.knots import link

sage: L = link.Link(oriented_gauss_code = [[-1, +2, -3, 4, +5, +1, -2, +6, +7, 3, -4, -7, -6,-5],[‘-‘,’-‘,’-‘,’-‘,’+’,’-‘,’+’]])

Seifert Circles

sage: L.seifert_circles()

[[9, 13, 9], [4, 12, 10, 4], [2, 8, 14, 6, 2], [1, 7, 3, 11, 5, 1]]

PD Code

sage: L.PD_code()

[[1, 7, 2, 6],

[7, 3, 8, 2],

[3, 11, 4, 10],

[11, 5, 12, 4],

[14, 5, 1, 6],

[13, 9, 14, 8],

[12, 9, 13, 10]]

Regions

sage: L.regions()

[[4, -11],

[2, -7],

[6, -1],

[13, 9],

[-4, -10, -12],

[-8, -2, -6, -14],

[10, -3, 8, -13],

[14, -5, 12, -9],

[7, 3, 11, 5, 1]]

We perform a move if they are bad regions

sage: L.remove_regions()

[[1, 9, 2, 8],

[9, 3, 10, 2],

[5, 13, 6, 12],

[13, 7, 14, 6],

[18, 7, 1, 8],

[17, 11, 18, 10],

[14, 11, 15, 12],

[16, 4, 17, 3],

[15, 4, 16, 5]]

Final method gives the above information after all the moves are made

sage: L.final()

Seifert Circles

[[[4, 18, 4],

[15, 21, 15],

[1, 9, 3, 19, 11, 17, 5, 13, 7, 1],

[2, 10, 20, 16, 12, 6, 14, 22, 8, 2]],

Regions

[[-15, -21],

[6, -13],

[2, -9],

[8, -1],

[18, 4],

[-3, 10, -19],

[12, -5, -17],

[20, 16, -11],

[14, 22, -7],

[19, 11, 17, -4],

[21, -14, -6, -12, -16],

[15, -20, -10, -2, -8, -22],

[5, 13, 7, 1, 9, 3, -18]],

PD Code

[[1, 9, 2, 8],

[9, 3, 10, 2],

[5, 13, 6, 12],

[13, 7, 14, 6],

[22, 7, 1, 8],

[19, 11, 20, 10],

[16, 11, 17, 12],

[18, 4, 19, 3],

[17, 4, 18, 5],

[21, 14, 22, 15],

[20, 16, 21, 15]]]

And finally we convert it to braid

sage: L.seifert_to_braid()

[-1, -2, -3, 2, 1, -2, -2, 3, 2, -2, -2]

One more example :

sage: from sage.knots import link

sage: L = link.Link(oriented_gauss_code = [[-1, +2, 3, -4, 5, -6, 7, 8, -2, -5, +6, +1, -8, -3, -4, -7],[‘-‘,’-‘,’-‘,’-‘,’+’,’+’,’-‘,’+’]])

sage: L.seifert_circles()

[[2, 10, 6, 12, 2], [4, 16, 8, 14, 4], [1, 13, 9, 3, 15, 5, 11, 7, 1]]

sage: L.regions()

[[6, -11],

[15, -4],

[9, 3, -14],

[2, -9, -13],

[1, 13, -8],

[12, -1, -7],

[5, 11, 7, -16],

[-3, 10, -5, -15],

[-6, -10, -2, -12],

[16, 8, 14, 4]]

sage: L.PD_code()

[[1, 13, 2, 12],

[9, 3, 10, 2],

[14, 4, 15, 3],

[4, 16, 5, 15],

[10, 5, 11, 6],

[6, 11, 7, 12],

[16, 8, 1, 7],

[13, 8, 14, 9]]

sage: L.remove_regions()

‘No move required’

sage: L.final()

[[[2, 10, 6, 12, 2], [4, 16, 8, 14, 4], [1, 13, 9, 3, 15, 5, 11, 7, 1]],

[[6, -11],

[15, -4],

[9, 3, -14],

[2, -9, -13],

[1, 13, -8],

[12, -1, -7],

[5, 11, 7, -16],

[-3, 10, -5, -15],

[-6, -10, -2, -12],

[16, 8, 14, 4]],

[[1, 13, 2, 12],

[9, 3, 10, 2],

[14, 4, 15, 3],

[4, 16, 5, 15],

[10, 5, 11, 6],

[6, 11, 7, 12],

[16, 8, 1, 7],

[13, 8, 14, 9]]]

sage: L.seifert_to_braid()

[-1, 2, -1, -2, -2, 1, 1, -2]

So this week we are looking at jones polynomial implementation and lots of documentation and testing.Thanks for reading through.

]]>

Last week we implemented the Vogel’s algorithm Part – 1, which would check for the bad regions and remove them. This week started off tweaking the last week’s code. I was thinking that instead of performing a move and then looking for the bad regions, why not perform all the moves necessary to correct the bad regions in a single go. But this turned out to be a wrong approach as the seifert circles expected were not matching with the results we got. So we choose a bad region, perform a move and again see if there are bad regions, basically a while loop which captures this was implemented. If there are no bad regions we move onto the next part which is detecting the braidword of the knot. In the part 2, we use the following information from part 1 of the algorithm, the PD Code, seifert circles, regions with respect to the final knot after we have removed the necessary regions by performing the moves. Now there are exactly two seifert circles which match with the regions, we select one of them and see with what seifert circle it shares a crossing and number the second seifert circle as 2 and so on and so forth.

For example here are the results we get :

sage: L = link.Link(oriented_gauss_code = [[-1, +2, -3, 4, +5, +1, -2, +6, +7, 3, -4, -7, -6,-5],[‘-‘,’-‘,’-‘,’-‘,’+’,’-‘,’+’]])

Final method gives out the final seifert circles, regions and the planar code of the modified knot. We see exactly two regions coincide with the seifert circles.

sage: L.final()

seifert circles

[[[18, 4],

[21, 15],

[9, 3, 19, 11, 17, 5, 13, 7, 1],

[10, 20, 16, 12, 6, 14, 22, 8, 2]]

regions,

[[-15, -21],

[6, -13],

[2, -9],

[8, -1],

[18, 4],

[-3, 10, -19],

[12, -5, -17],

[20, 16, -11],

[14, 22, -7],

[19, 11, 17, -4],

[21, -14, -6, -12, -16],

[15, -20, -10, -2, -8, -22],

[5, 13, 7, 1, 9, 3, -18]]

PD_code,

[[1, 9, 2, 8],

[9, 3, 10, 2],

[5, 13, 6, 12],

[13, 7, 14, 6],

[22, 7, 1, 8],

[19, 11, 20, 10],

[16, 11, 17, 12],

[18, 4, 19, 3],

[17, 4, 18, 5],

[21, 14, 22, 15],

[20, 16, 21, 15]]]

#this is still a method in development

sage: L.seifert_to_braid()

here we have numbered the seifert circles which form the strands in the braidword

{1: [18, 4], 2: [9, 3, 19, 11, 17, 5, 13, 7, 1], 3: [10, 20, 16, 12, 6, 14, 22, 8, 2], 4: [21, 15]}

#this is other information required for the ordering of the crossings

{1: [[18, 4, 19, 3], [17, 4, 18, 5]], 2: [[1, 9, 2, 8], [9, 3, 10, 2], [5, 13, 6, 12], [13, 7, 14, 6], [22, 7, 1, 8], [19, 11, 20, 10], [16, 11, 17, 12], [18, 4, 19, 3], [17, 4, 18, 5]], 3: [[1, 9, 2, 8], [9, 3, 10, 2], [5, 13, 6, 12], [13, 7, 14, 6], [22, 7, 1, 8], [19, 11, 20, 10], [16, 11, 17, 12], [21, 14, 22, 15], [20, 16, 21, 15]], 4: [[21, 14, 22, 15], [20, 16, 21, 15]]}

{1: [‘-‘, ‘+’], 2: [‘-‘, ‘-‘, ‘-‘, ‘-‘, ‘+’, ‘-‘, ‘+’, ‘-‘, ‘+’], 3: [‘-‘, ‘-‘, ‘-‘, ‘-‘, ‘+’, ‘-‘, ‘+’, ‘+’, ‘-‘], 4: [‘+’, ‘-‘]}

{1: [[4, 19], [18, 5]], 2: [[9, 2], [3, 10], [13, 6], [7, 14], [1, 8], [11, 20], [17, 12], [4, 19], [18, 5]], 3: [[9, 2], [3, 10], [13, 6], [7, 14], [1, 8], [11, 20], [17, 12], [22, 15], [16, 21]], 4: [[22, 15], [16, 21]]}

{1: [[18, 3], [17, 4]], 2: [[1, 8], [9, 2], [5, 12], [13, 6], [22, 7], [19, 10], [16, 11], [18, 3], [17, 4]], 3: [[1, 8], [9, 2], [5, 12], [13, 6], [22, 7], [19, 10], [16, 11], [21, 14], [20, 15]], 4: [[21, 14], [20, 15]]}

So the next and the final part is to trace through the ordering of the crossings and assign them with a braid generator and that generates the braidword.

The last part of ordering has been a tough part to generalize and code. It is like we have all the information but the dots are yet to be connected to get the final picture. I would like to leave you with two examples which we start from the first.

#so we start with the oriented gauss code

sage: L = link.Link(oriented_gauss_code = [[-1, +2, -3, 4, +5, +1, -2, +6, +7, 3, -4, -7, -6,-5],[‘-‘,’-‘,’-‘,’-‘,’+’,’-‘,’+’]])

#get the pd_code

sage: L.PD_code()

[[1, 7, 2, 6],

[7, 3, 8, 2],

[3, 11, 4, 10],

[11, 5, 12, 4],

[14, 5, 1, 6],

[13, 9, 14, 8],

[12, 9, 13, 10]]

#compute the regions

sage: L.regions()

[[4, -11],

[2, -7],

[6, -1],

[13, 9],

[-4, -10, -12],

[-8, -2, -6, -14],

[10, -3, 8, -13],

[14, -5, 12, -9],

[7, 3, 11, 5, 1]]

#compute the seifert circles

sage: L.seifert_circles()

[[13, 9], [12, 10, 4], [8, 14, 6, 2], [7, 3, 11, 5, 1]]

#remove the bad regions … this is just a method showing how the remove_regions works

#it returns a pd_code after the move has been made

sage: L.remove_regions()

[[1, 9, 2, 8],

[9, 3, 10, 2],

[5, 13, 6, 12],

[13, 7, 14, 6],

[18, 7, 1, 8],

[17, 11, 18, 10],

[14, 11, 15, 12],

[16, 4, 17, 3],

[15, 4, 16, 5]]

#the below method returns the seifert circles, regions and pd_code after the correction (we run the above method until we end up with these results)

sage: L.final()

[[[18, 4],

[21, 15],

[9, 3, 19, 11, 17, 5, 13, 7, 1],

[10, 20, 16, 12, 6, 14, 22, 8, 2]],

[[-15, -21],

[6, -13],

[2, -9],

[8, -1],

[18, 4],

[-3, 10, -19],

[12, -5, -17],

[20, 16, -11],

[14, 22, -7],

[19, 11, 17, -4],

[21, -14, -6, -12, -16],

[15, -20, -10, -2, -8, -22],

[5, 13, 7, 1, 9, 3, -18]],

[[1, 9, 2, 8],

[9, 3, 10, 2],

[5, 13, 6, 12],

[13, 7, 14, 6],

[22, 7, 1, 8],

[19, 11, 20, 10],

[16, 11, 17, 12],

[18, 4, 19, 3],

[17, 4, 18, 5],

[21, 14, 22, 15],

[20, 16, 21, 15]]]

#here we have numbered the seifert circles which form the strands in the braidword

sage: L.seifert_to_braid()

{1: [18, 4], 2: [9, 3, 19, 11, 17, 5, 13, 7, 1], 3: [10, 20, 16, 12, 6, 14, 22, 8, 2], 4: [21, 15]}

The ordering of the crossing remain …. which would complete the algorithm

Another example :

sage: L = link.Link(oriented_gauss_code = [[-1, +2, 3, -4, 5, -6, 7, 8, -2, -5, +6, +1, -8, -3, -4, -7],[‘-‘,’-‘,’-‘,’-‘,’+’,’+’,’-‘,’+’]])

sage: L.PD_code()

[[1, 13, 2, 12],

[9, 3, 10, 2],

[14, 4, 15, 3],

[4, 16, 5, 15],

[10, 5, 11, 6],

[6, 11, 7, 12],

[16, 8, 1, 7],

[13, 8, 14, 9]]

sage: L.regions()

[[6, -11],

[15, -4],

[9, 3, -14],

[2, -9, -13],

[1, 13, -8],

[12, -1, -7],

[5, 11, 7, -16],

[-3, 10, -5, -15],

[-6, -10, -2, -12],

[16, 8, 14, 4]]

sage: L.seifert_circles()

[[10, 6, 12, 2], [16, 8, 14, 4], [13, 9, 3, 15, 5, 11, 7, 1]]

sage: L.remove_regions()

‘No move required’

sage: L.final()

[[[10, 6, 12, 2], [16, 8, 14, 4], [13, 9, 3, 15, 5, 11, 7, 1]],

[[6, -11],

[15, -4],

[9, 3, -14],

[2, -9, -13],

[1, 13, -8],

[12, -1, -7],

[5, 11, 7, -16],

[-3, 10, -5, -15],

[-6, -10, -2, -12],

[16, 8, 14, 4]],

[[1, 13, 2, 12],

[9, 3, 10, 2],

[14, 4, 15, 3],

[4, 16, 5, 15],

[10, 5, 11, 6],

[6, 11, 7, 12],

[16, 8, 1, 7],

[13, 8, 14, 9]]]

sage: L.seifert_to_braid()

#we number the strands

{1: [10, 6, 12, 2], 2: [13, 9, 3, 15, 5, 11, 7, 1], 3: [16, 8, 14, 4]}

Other information for extracting the braidword

{1: [[1, 13, 2, 12], [9, 3, 10, 2], [10, 5, 11, 6], [6, 11, 7, 12]], 2: [[1, 13, 2, 12], [9, 3, 10, 2], [14, 4, 15, 3], [4, 16, 5, 15], [10, 5, 11, 6], [6, 11, 7, 12], [16, 8, 1, 7], [13, 8, 14, 9]], 3: [[14, 4, 15, 3], [4, 16, 5, 15], [16, 8, 1, 7], [13, 8, 14, 9]]}

{1: [‘-‘, ‘-‘, ‘+’, ‘+’], 2: [‘-‘, ‘-‘, ‘-‘, ‘-‘, ‘+’, ‘+’, ‘-‘, ‘+’], 3: [‘-‘, ‘-‘, ‘-‘, ‘+’]}

{1: [[13, 2], [3, 10], [11, 6], [7, 12]], 2: [[13, 2], [3, 10], [4, 15], [16, 5], [11, 6], [7, 12], [8, 1], [14, 9]], 3: [[4, 15], [16, 5], [8, 1], [14, 9]]}

{1: [[1, 12], [9, 2], [10, 5], [6, 11]], 2: [[1, 12], [9, 2], [14, 3], [4, 15], [10, 5], [6, 11], [16, 7], [13, 8]], 3: [[14, 3], [4, 15], [16, 7], [13, 8]]}

{1: [[9, 3, 10, 2], [10, 5, 11, 6], [6, 11, 7, 12]], 2: [[1, 13, 2, 12], [9, 3, 10, 2], [14, 4, 15, 3], [4, 16, 5, 15], [10, 5, 11, 6], [6, 11, 7, 12], [16, 8, 1, 7], [13, 8, 14, 9]], 3: [[14, 4, 15, 3], [4, 16, 5, 15], [16, 8, 1, 7], [13, 8, 14, 9]]}

[[13, 2], [3, 10], None]

So to conclude, I hope I can say we are almost able to see the result and almost there but as said the dots are yet to be connected. The implementation of the last part remains.

]]>

The past week has been a great learning curve for me. So let me take you back to where we stopped the last week. So given a oriented gauss code we were able to generate the planar diagram code. Now this week, we start with this planar diagram code and generate the Seifert circles, the regions of the knot, the bad regions and performing the Reidemeister move to correct the bad regions. So let me start by explaining what everything means.

Seifert circles : The regions obtained by smoothing of the crossing.

So in the above crossing t(i) (under cross, entering) goes to t(j) (over cross, leaving) and similarly we have t(j) (over cross, entering) goes to t(i+1) (under crossm leaving)

So we have the following example which shows such kind of a smoothing.

Regions of the knot: For the Seifert circles we moved in a specific direction at every crossing but here we only turn left at every crossing and if we move against the component we note it down with a negative sign.

So we have the regions and the seifert circles, now when do we call a region bad, a bad region is one that has two edges(two components) with the same sign, but that belong to different Seifert circles. So now we have the information of everything so we perform the corresponding Reidmeister move to correct the bad regions.

So if we start numbering the components, we eventually end up with the Planar Diagram code, from which we can make out the bad regions and perform the move.

So that was just a synopsis of the algorithm we implemented.

So first we generate the Seifert circles, from the PD code (which had all the information of the entering , leaving, + , – , under and over) this was straight forward as we had to match the formula which was mentioned above.

To compute the regions, we first had to turn left at every crossing. So we have arrays of data and we had to map one onto the other to get the regions.

Now we have the Seifert circles and bad regions so we start to look for the bad regions, this was also a bit straight forward as we just had to implement the formula for the bad regions. Now once- the bad regions were recognized we performed the move and renumbering the components was a simple logic of adding multiples of 2 to the respective edges. Then, once this was done we had to renumber the new crossings, the logic was to map the new data to the old data and to compute the numbering we had to use the logic that the greatest among the leaving component will have the lowest component entering. So that setup converted the bad to good regions. Now once this is done we need to compute the Seifert circles once again in order to get to the braid word which is the goal of the algorithm. So till now we have identified the Seifert circles, the regions, the bad regions, corrected them and computed the Seifert circles once again. So the next part of the algorithm is to read the braidword from the Seifert circles obtained.

Here is the gist of the implementation of PD Code, Seifert circles, regions and _is_move_required. A lot of refining has to be done, we just got the bare essentials working. The idea was to first get it going and then optimize as we move along. So that’s it from me, hope we conclude the implementation this week.

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

Here is the entire file we are working on :

https://github.com/amitjamadagni/sage/blob/a9d368758d23d65067d6cbc5cfbd652c6927a1ca/src/sage/knots/link.py

And here is the pull request for the week :

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

The images have been taken from this document and this document has also been followed to a good extent to get a better understanding :

http://magma.maths.usyd.edu.au/~danr/site/talks/20070606.pdf

PS : There has been some edits to the code, will post the remaining part as well as the edited version sooner.

]]>

This week we focused on the implementation details of the Vogel’s algorithm. I will get back to this algorithm at a later stage. To start off, last week we had a problem in generating the planar diagram code. But that was resolved using the braid as input. It seems braid word has all the information to generate the planar diagram (unique). The problem with other inputs like the gauss code or the dt code is we get a planar diagram but which component of the over-crossing comes first when we move in the clockwise direction is what is the problem. But in braidword we have this information in the form of -1 and +1, which happens to provide this information. This was achieved at the very beginning of the last week. Ever since it has been the implementation of Vogel’s algorithm, which takes in the oriented gauss code and converts it to the braid word. We have had to work on the oriented gauss code as the parameter to the method, it is not in a great shape but still the main idea has been achieved. (The minor problem is we have to pass the oriented gauss code as a parameter for the method). The difference here is, for every crossing we take how the crossing is oriented, so the name oriented gauss code. So this allows us to convert from oriented gauss code to planar diagram. The next thing was to determine the regions and then the Seifert circles. There are two parts to the algorithm of which one is to identify the unoriented Seifert circles and then perform a Reidmester move. Once this move is done then look for other unoriented Seifert circles. Once we end up with no unoriented circles we get the braidword which forms the second part. So in the first part we are able to convert the oriented gauss code to Planar Diagram, we are working on looking into how we can get regions which are bounded by the components. Next step is to identify the Seifert circles and then detect the unoriented pair. We have used different approaches for detecting the regions, like the Directed graphs where the crossings form the vertices and they have an edge if they have a component or two in common. But this made things a bit complicated as directed graphs cycles (g._show_all_cycles() ) returned more data and it was a bit difficult to get the exact regions. We are working on this as of now. Miguel has sent in his ideas on this matter and I am looking into it. The idea now is to move around the crossings in a given fashion and then work out the regions and then move on. I had another approach which I took time to read, this was the approach of Andrew who has implemented a version of Vogel’s algorithm in the Braid programme. It is somewhat on the similar lines but we choose to re think as it had some huge information to calculate after each step. I have sent in a pull request with the work

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

Documentation work still remains of the newly implemented methods and we just got these methods working we still need to re think on the design, two to three things that we are lacking as of now:

1. Documentation

2. Redesigning the currently implemented methods.

3. Setting the minor issues which have been already identified from the previous pull requests. (in-line comments on the previous pull requests have to be worked upon).

]]>