TQC, Hopf algebras and TPM

Hello everyone,
It has been a long time since I got time to update. The last few months have been rough as well as exciting. To start off  here are the project updates :
Between the last update and this, I gave my second internals at the university which went pathetic, made it to the GSoC reunion in California where I had worked on the documentation and few failing cases, and have started to read more of TQC, Hopf algebras and material on Topological Phases of Matter.
Coming to the project, the issues with the documentation had been resolved, I could not get time to revamp the code and get it working for the failing cases. Recently Miguel chipped in with the revamped code and most of the cases seem to work. The library is open for testing and it would be great to hear some comments on it.
Coming to the trip to California it was a great experience (not before a lot of travel … changed around 7 flights on the way and back … no more flights without leg space), I had an opportunity to interact with people from various other open source communities (some of them which I contributed and attempted to contribute to) and legends like Linus Torvalds, Peter Norvig. On my return,a lot of work had already been piled up and I had to catch up with various deadlines. Somehow I managed to finish them but not without the support of my friends.
Lately I have started reading through the work of Prof. Wang who has been an inspiration from the time I started to go through the topics of TQC. I have been making attempts to understand his paper titled “Quantum Computing : A Quantum Group Approach”. My understanding of it is the anyonic systems can be modeled through UMC’s (Unitary Modular Categories). The symmetries of crystals can be explained by Group Theory but not all phases of matter can be classified by this and so to classify these Topological phases of matter we use Fusion Categories (More of it can be found from the paper on String Net condensation, I had a look at it but nothing concrete). So to continue I had the understanding of Ribbon Categories (which are rigid braided monoidal categories with an additional isomophim which maps the object to the dual of the dual). This mathematical structure is in total sync with the anyonic system, as the rigidity property relates to the anti particle of the anyon, the braiding isomorphism relates to the braiding of anyons, and the monoidal structure explains how anyons can be put together and the interaction with the trivial anyon, then to explain the twist isomorphism (this can be viewed as the link formed when an anyon is braided around a trivial anyon is not same as not braiding at all) so we use the additional isomorphism (I think it can be called as a pivotal structure). So anyon can be related as an object in this category. To explain the fusion rules we require the semisimplicity and in addition to that we require the condition of modularity and that would make the system complete. This also can be related through Hopf algebras which share similar structure.
How can this be related to TQFT’s and link invariants ??
n+1 TQFT can be defined as a functor from n+1 bordism category to the category of finite dimensional vector spaces. (I just took the definition) from my understanding there can be some results which can be obtained in the 3+1 TQFT using such kind of a formulation.
Link invariants :
The axioms of RFC are used to define topological invariants of braided trivalent framed graphs in the plane. This statement is again from the paper and I am trying to still understand this.

I had the opportunity to realize why Jones polynomial computation is faster in quantum realm than in classical realm but I really cant write it down firmly I have an idea of how it works but I will make an attempt to explain it the next time.
I recently got into relating graphs and knots, and this might be clinging on for some time in the near future. I have read through Kauffman bracket formulation using graphs and its a simple enough idea on how we construct a graph out of a knot. We shade the bounded regions and mark as nodes the regions, which ever regions shares a crossing we draw an edge across it and we extend the rules.

I am again sorry if something is not clear, I am not good at writing mathematics in blogs but I hope I could provide the underlying connections and ideas.

Advertisement

Cleaning, Other projects, permissions

Hello Everyone ….
Its been a long time since I have posted anything on the work I have been doing. There has been a lot of work at hand the academics at the university as well as other constraints arising from the other projects. I would like to post about
1. The project and its current status (Knot Theory for sage)
2. Permissions on the Linux file system (And a bit of my project I have been working on, using raspberry pi)
3. Quantum Computation using Categorical ideas (This might be a little bit harsh as I am not using mathjax as of now for the symbols)

I.
So starting off with the project, the status report is as follows :
1.There has been some reviewing going on the project and corrections have been made. I have been committing the work on sage trac ticket 17030, we have moved from github to the trac server.
2. I am working on the plot method based on the ideas that Miguel has presented me with. I am not getting enough time to get through it all at once. This will be really important and will be focusing in the coming days.
3. The ncomponents method needs edits and the construction of the various representations must be in the form of tuples.
4. The documentation is not building, there are some errors as I try to build it up so I need to get this working.
5. After the above work (which is already pending and a lot) I need to steer my efforts in bringing up the two important knot invariants the HOMFLY polynomial and Khovanov homology.(These are big targets and will be great additions to the project).

II.

We are working on developing a framework for controlling the GPIO pins on Raspberry Pi over small to medium range using wireless techniques. We are more focused on the software and not on the hacking the hardware. So we had this idea of file creation and watcher watching this event on the pi whenever there is a communication between pi and the user. So where does file permissions come in : GPIO pins cant be accessed as a user, one needs root privileges. So what are the alternatives :
1. We found this pigpio daemon which could control GPIO pins without the root access.
2. We thought we could tweak a further and there in came the file permissions, so how do you do it :
set the setuid bit so that the file is run with the permissions of the owner rather than the user, but this does not work on scripts so compile a C file with the file permissions setting the uid and then running the file. This works … But the whole idea is yet to be adjusted to this adjustment.

(ITS 4_ _ _ for setting the uid) 😛

III.
Off late I have started to focus on the study of Topological Quantum Computation through Categorical Framework. I have reached upto the understanding of the Ribbion Category structure. Next would be modular tensor categories which are ribbon categories with additional structure like the semisimplicity and modularity. I have simultaneously started working on Hopf Algebras (Quantum Groups) to get a better understanding of the current design. The next targets are to understand these structures through Categorical Framework. There is some close relation between Hopf Algebras and knot invariants (I might be wrong on this) but yes it would be great to complete the incomplete picture to realize the artistic math in it. I have messed it up here with the jargons and I hope I could have put more concretely and precisely for everyone to understand. That’s it from me … Hope you didnt curse at me while reading this last instance … Anyways thanks for scanning through … 🙂

Further edits

Hello Everyone,
This week I have worked on several minor issues. The main ones are the following:
1. Check on the pd_code
Have added additional conditions, to check whether each number is given exactly twice.
2. Work on the imports.
I tried various ways before sending in a mail to Miguel in what I was missing. Finally we could figure it out and now it is possible to just create a link on the fly no need to import the module.
3. One of the most exciting things I have worked on is I have started using the SMC (sage math cloud) for development. There are some latency issues but that said wow!!! I am amazed working on SMC. I am still tweaking around with the editor but till now it has been amazing !!!!
4. So if you want to test out my work :
(a) Create an account on sage math cloud (cloud.sagemath.com)

(b) create a terminal (you have an instance in hand)

(c) git clone -b week15 <link to my github repo)

(d) move into the sage folder and hit make (while it builds grab a coffee and read my previous posts)

Test out the latest work :). Just do a pull if you are interested in the latest work. Dont forget to build once you have pulled.

I am still working on few other methods (the ncomponents is one which needs a bit of focus as we have ignored the trivial circles) and the pull request below shows the work that needs to be done.

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

Edits, Evaluations and university …

Hello Everyone,
This week we focused on edits (minor ones, some related to documentation and small others in the code). The code is in the review phase and Miguel is giving it a thorough check. Once we are done with it we would be creating a ticket on trac server and then I hope the works gets merged in the master. A lot of documentation has been added on how the input works. The constructor has been completely revamped, some conditions have been added to check on the input. Last week we could identify what kind of input it was, but this time we have enhanced it to check whether it is in the required format or not. There is an conditional check to be performed on the PD code and that should be done this week. I do not remember mentioning in the previous post about the jones polynomial. We were initially working in the LaurentPolynomialRing but we have changed it to SymbolicRing so that the answer is returned with least damage. So once the support for the rational powers chips in we can revert back to LaurentPolynomialRing for Jones polynomial. Many such edits were made in the documentation.

We had the final evaluations on Friday and I have passed the evaluations. I am happy with the way things have been moving, this has been a great learning curve for me and I will be continuing my efforts in making this module more functional and robust.  The next target would be making the code reach the required standards before adding further functionality which would be the homfly polynomial and then the plot. I am very much excited in implementing the other invariants but that said the most important thing is to prepare the present code for the master.

There are a lot of people to thank who have kept me motivated and inspired during the program. Miguel has been very much supportive and has helped me a lot. He has helped me tackle some questions with ease. I would like to thank the Sage community for having accepted me and making me a part of such a wonderful team. I would like to thank David Horgan for having followed my work and inspiring me with the physics applications of the subject. Thanks to Nisanth, I still remember it all started off with us discussing FOSS and for giving some invaluable tips. Thanks to Manoj and Srikanth for all the chat we had , it would have been difficult to move forward without some of those chats we had. Hoping to continue the work and getting some results. The university has resumed and a great summer has finally come to an end. Lots of targets and lots to learn. That’s it from me. Thanks for reading through.

Edits, dowker notation, HOMFLY …

Hello everyone,
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

Click to access 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

Jones polynomial and plotting ….

Hello everyone,
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.

Jones polynomial, the next week …

Hello everyone,
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

Revamped to work for links …

Hello everyone,
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

Conversions, cleaning …

Hello everyone,
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

Jones Polynomial, Trip Matrix, documenting ….

Hello everyone,
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 _ij  be the elements. Now we start with the crossing i and see how many times we have encountered the crossing j until we return to the crossing i. We take mod2 of this value and fill that matrix element. So in this way we construct all the elements except the diagonal elements. For the diagonal elements we see whether i is a positive cross or negative cross. If it is a positive cross we fill it with zero and for the negative cross we fill it with 1. Now we have the initial trip matrix. To evaluate the Jones polynomial we smooth the crossings until we have a link for which we know the Kauffman’s bracket. So this decomposition here is looked by the matrix. So for the initial diagonal elements of the trip matrix we assign a certain type of smoothing and determine the number of seifert circles. Now we construct a new matrix by doing the following, we choose a crossing and smooth it in another way(different from the first), the only elements which are different from the initial matrix are the diagonal elements and the only element which changes when we do such kind of a smoothing is the crossing number element. In sense if we change the smoothing at crossing i we change the number at the matrix element T _ii   (this is flipped from either one to zero or zero to one). Again we continue this until all the options are exhausted. Then for every matrix we have certain coefficients of the jones polynomial. Adding all these up gives the jones polynomial for the knot. I know it is tough to follow but that is the gist of the algorithm. I have followed the following material and I request the readers to have a look at them for greater understanding.

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