Knot Theory as a part of GSoC 2014.

amitjamadagni commented 10 years ago

We provide a basic implementation of knots and links such as the Seifert matrix, Jones and Alexander polynomials.

CC: @miguelmarco @jhpalmieri @tscrim @fuglede

Component: algebraic topology

Author: Amit Jamadagni, Miguel Marco

Branch: 207d033

Reviewer: Miguel Marco, Karl-Dieter Crisman, Frédéric Chapoton, Travis Scrimshaw, Søren Fuglede Jørgensen, John Palmieri

Issue created by migration from https://trac.sagemath.org/ticket/17030

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 10 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

1613a32 Changes.

miguelmarco commented 10 years ago

comment:44

Documentation does not build:

...
[knots    ] loading cross citations...
[knots    ] /home/mmarco/sage/local/lib/python2.7/site-packages/sage/knots/link.py:docstring of sage.knots.link:2: ERROR: Unexpected indentation.
[knots    ] /home/mmarco/sage/local/lib/python2.7/site-packages/sage/knots/link.py:docstring of sage.knots.link:4: WARNING: Block quote ends without a blank line; unexpected unindent.
[knots    ] <autodoc>:0: ERROR: Unexpected indentation.
[interface] reading sources... [ 25%] sage/interfaces/gap
[categorie] reading sources... [ 92%] sage/categories/semirings
Error building the documentation.
Traceback (most recent call last):
  File "/home/mmarco/sage/src/doc/common/builder.py", line 1491, in <module>
    getattr(get_builder(name), type)()
  File "/home/mmarco/sage/src/doc/common/builder.py", line 292, in _wrapper
    getattr(get_builder(document), 'inventory')(*args, **kwds)
  File "/home/mmarco/sage/src/doc/common/builder.py", line 503, in _wrapper
    x.get(99999)
  File "/home/mmarco/sage/local/lib/python/multiprocessing/pool.py", line 558, in get
    raise self._value
OSError: [knots    ] /home/mmarco/sage/local/lib/python2.7/site-packages/sage/knots/link.py:docstring of sage.knots.link:2: ERROR: Unexpected indentation.

Makefile:60: recipe for target 'doc-html' failed
make: *** [doc-html] Error 1

miguelmarco commented 10 years ago

comment:45

The conversion to braid gives wrong answer, which causes several other errors:

sage: L=Link([[1, 5, 2, 4], [7, 11, 8, 10], [3, 8, 4, 9], [9, 2, 10, 3], [5, 1, 6, 12], [11, 7, 12, 6]])
sage: L.braid()
s0*s1^-1*s2*s1^-1*s0^-1*s1^-1*s2^-1*s3^-1*s2*s1^-1*s0*s2*s1^-1
sage: L
Link with 2 components represented by 6 crossings

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 10 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

61bec34 Corrections.

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 10 years ago

Changed commit from 1613a32 to 61bec34

amitjamadagni commented 10 years ago

comment:47

I guess its fixed.Here are the results

sage: L=Link([[1, 5, 2, 4], [7, 11, 8, 10], [3, 8, 4, 9], [9, 2, 10, 3], [5, 1, 6, 12], [11, 7, 12, 6]])
sage: L
Knot represented by 6 crossings
sage: L.braid()
s0*s1^-1*s2*s1^-1*s0^-1*s1^-1*s2^-1*s3^-1*s2*s1^-1*s2*s3  
sage: L.braidword()
(1, -2, 3, -2, -1, -2, -3, -4, 3, -2, 3, 4)

New commits:

61bec34 Corrections.

miguelmarco commented 10 years ago

comment:48

Still broken:

sage: L=Link([[1, 9, 2, 8], [7, 15, 8, 14], [5, 17, 6, 16], [9, 1, 10, 18], [15, 7, 16, 6], [17, 11, 18, 10], [13, 3, 14, 2], [3, 13, 4, 12], [11, 5, 12, 4]])
sage: L.bra
L.braid      L.braidword  
sage: L.braidword()

(does not finish the computation).

amitjamadagni commented 10 years ago

comment:49

I am getting into an infinite loop with the _info_all_moves_ method.With this approach there seems that the regions with same sign never are in the same seifert circles there by the above method keeps on giving out the edited pd_code. Could you please let me know the knot reference ??

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 10 years ago

Changed commit from 61bec34 to a5cb90c

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 10 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

a5cb90c Documentation. WIP : Other methods.

amitjamadagni commented 10 years ago

comment:51

The above commit aims to fix the documentation. The documentation builds both pdf and html.

tscrim commented 10 years ago

comment:52

I think the bulk of the documentation should be at the class level, rather than the module level. That way when a user does Link?, the user sees all of that documentation. Also this way the doc is better associated with what it's documenting.

Side note, making things raw strings, the r""", is usually safer, in particular when you have latex commands.

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 10 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

e2f61ed Check in the documentation.

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 10 years ago

Changed commit from a5cb90c to e2f61ed

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 10 years ago

Changed commit from e2f61ed to 2b36cda

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 10 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

2b36cda Idea of plot method added. Some failing cases. WIP : ncomponents

amitjamadagni commented 10 years ago

comment:55

The idea of plot by Miguel has been added. I am trying on the refinement as it raises an error for the cases like :

sage: B = BraidGroup(8)
sage: L = Link(B([-1,3,1,5,1,7,1,6]))
sage: L.linkplot()

MIPSolverException: 'GLPK : Solution is undefined'

The errors like this and the work on documentation for the plot remain.

miguelmarco commented 10 years ago

comment:56

I would dsy thast this fasils because the diagram has more than one connected component. It could be useful to have a method to list the different "completely unlinked" components, as they should be treated separatedly in several places.

amitjamadagni commented 10 years ago

comment:57

Replying to @miguelmarco:

I would dsy thast this fasils because the diagram has more than one connected component. It could be useful to have a method to list the different "completely unlinked" components, as they should be treated separatedly in several places.

Okay then I guess a combination of braidwordcomponents which gives

sage: L._braidwordcomponents_()
[[-1, 1, 1, 1], [3], [5, 7, 6]]

ncomponents could be used. I will try to set this up.

miguelmarco commented 10 years ago

comment:58

No, it is not the same as ncomponents. ncomponents counts how many different pieces of rope are in the link. What i am talking about is about pieces of the diagram that don't cross at all.

That is, the braid [1,1] has two connected components (that is, two pieces of rope), but they have crossings between them, so they are in the same part of the diagram.

Whereas the braid [1,3] has also two connected components (two pieces of rope), but there is no crossing at all between them. The planar diagram is just two separated planar diagrams.

This situation of "completely independent" pieces needs to be treated separatedly in several methods. For instance, try to check how many methods fail for things like Link([[1,1,2,2],[3,3,4,4]])

amitjamadagni commented 10 years ago

comment:59

So are we looking at something like the braidwordcomponents() which acts like :

sage: L._braidwordcomponents_()
[[-1, 1, 1, 1], [3], [5, 7, 6]]

miguelmarco commented 10 years ago

comment:60

Yes, that is the idea.

But be careful: thinkig only in terms of braids might lead to errors that appear when we deal with other representations.

miguelmarco commented 9 years ago

Changed branch from u/amitjamadagni/ticket/17030 to u/mmarco/ticket/17030

miguelmarco commented 9 years ago

Changed reviewer from Miguel Marco to none

miguelmarco commented 9 years ago

comment:62

Since Amit did not answer lately, i decided to step up and do some cleanup and polishing of the code. Maybe documentation can be improved, but i think besides that it is pretty much ready for review.

Bad news is that, since i am now an author, somebody else should do the reviewing instead of me.

New commits:

`7f382ba`	`Cleanup of code`
`17a982e`	`Some further polishing.`
`b58f492`	`Cleanup of the braid conversion.`
`071683a`	`Merge branch 'u/amitjamadagni/knots' of git://trac.sagemath.org/sage into ticket/17030`
`29be8b0`	`Merge conflict resolution`
`37bd26b`	`Merge old branch.`

miguelmarco commented 9 years ago

Changed commit from 2b36cda to 37bd26b

kcrisman commented 9 years ago

comment:63

Bad news is that, since i am now an author, somebody else should do the reviewing instead of me.

Not all bad news, because you can specify exactly which files/commits/contributions remain "yet to be reviewed". You can also suggest ways for people (even non-knot theorists) to test things out, and which things need some outside eyes.

kcrisman commented 9 years ago

comment:64

By the way, once this has positive review, it might be worth making a new branch that just adds in all these new files at one fell swoop. Or that might be a bad idea, depending on how you want the history to go in Sage. Just pointing it out.

amitjamadagni commented 9 years ago

comment:65

In the case of testing, the polynomial invariants have been compared with Knot Atlas as mentioned by Miguel. The other major part that need to be tested are the conversions, I guess it is easy for anyone to have a go at this by reading the documentation.

kcrisman commented 9 years ago

comment:66

Alternately, if there is a good "core" of functionality you (mmarco) as reviewer approve of that is a coherent whole, then other stuff could be moved to a new ticket. Especially if the stuff that still needs review is more peripheral, such as plotting...

miguelmarco commented 9 years ago

comment:67

Inthe case of git history, i like it to reflect the process that actually took place, in case that someone in the future wants to do some archeology.

But it is just a matter of personal taste. I understand why other people prefear to avoid haveing too many commits in the history.

My last changes touch most of the relevant methods, so it would be difficult to stablish a clear separation from my work and Amit's.

Here some ideas of things that non specialists in knot theory can do towards reviewing:

Check the documentation. In fact, it is better if they are not specialist: the documentation should be clear for everybody. So if there is something that someone does not understand, please point it out.
Test some results that are known in other sources. For instance go to the knot atlas, pick any knot or link there, create it in Sage, compute the different invariants and compare. (Note, here we follow a different convention than in the knot atlas for the PD code, Xa,b,c,d in the knot atlas corresponds here to [a,d,b,c]).
Check out also the plotting of knots (no deep knowledge of knot theory is needed, although it is a complicated method, so it is hard to review... but it is really cool ;) ).

Regarding the idea of separting it into smaller tickets, we could do that, but besides the plotting, all the methods that can be separated into other tickets (i.e. the computation of the different invariants), are pretty trivial, since they are almost direct aplications of the conversion to braid).

miguelmarco commented 9 years ago

comment:68

I forgot to mention: the conversion to braid is one of the methods that i have rewriten. And it is really essential (i.e. it makes little sense to have a link class without it).

amitjamadagni commented 9 years ago

comment:69

I observe there is some problem with the regions method, I end up getting a build error.

miguelmarco commented 9 years ago

comment:70

Oops, i see there was some problem while merging different branches.

The actual branch is a mess. Let me try to solve it tonight.

miguelmarco commented 9 years ago

comment:71

How can i force the branch to go back to commit 17a982e? If i try to push it i get the message:

Not pushing your changes because they would discard some of the commits on the remote branch

kcrisman commented 9 years ago

comment:72

There is a lot of discussion out there about this. Git has the philosophy that once something is pushed to a public repo, it really shouldn't be changed. See this SO question and this answer for some points of view, though an internet search will yield a LOT more opinions on this, such as this one which seems more nuanced.

Basic is that you can "force" a push (and this happens on occasion on Sage Trac) or "revert" some commits.

videlec commented 9 years ago

comment:73

I would be happy to participate in the review. But first, you have to read my two cents about git history. I think that the git history must be helpful to newcomers and not for archaeologists (for them, we have trac and sage-devel. Moreover, they do not necessarily want to know that in the first n commits you were just trying to understand how to use git).

More precisely:

keep the history simple
always have the following sentence in mind: "what is the most helpful for the reviewer?"

More concretely

merge as less as possible
if you modify a lot on an already existing file, try to have one commit that deletes and an other one that adds
if you are only providing new functionalities in independent file, try to minimize the number of commits (or at least make them coherent for the reader)

Git history could be really helpful to reviewer. For example, if you simply move a file, the commit will only be "mv old_file -> new_file". Hence, as a reviewer, I know that there is nothing to check in that file.

Vincent

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Changed commit from 37bd26b to 17a982e

miguelmarco commented 9 years ago

comment:75

Ok, i forced a push that should simplify the history, and return to a sane state.

tscrim commented 9 years ago

comment:76

I'd have just merged the remote branch (from the message, it seems like your local branch was behind the one on trac). I'll try to take a look at this soon too.

Vincent and I disagree on the following git stuff. The general git philosophy, as far as I have seen, is to favor more commits into small logical chunks and to keep history that you can go back and see (or retrieve) code formats that you've tried before. The important thing is to have commit messages which describe what is done in the commit.

kcrisman commented 9 years ago

comment:77

My last changes touch most of the relevant methods, so it would be difficult to stablish a clear separation from my work and Amit's.

Well, not exactly; in fact, you only did the last two commits, so in principle someone else could review just those commits (and the very last commit seems very straightforward). What I was hoping to elicit from you is the answer to the following question:

In your opinion, is everything not touched by your commits okay (even if fairly trivial), and do you feel there is any additional work needed beyond reviewing the pieces (many, granted) you did work on?

kcrisman commented 9 years ago

Reviewer: Miguel Marco

kcrisman commented 9 years ago

comment:79

Some minor things, just on a first glance:

Various minor English misspellings.
There should probably be an "intro" module-level section telling people what links and knots are (in particular, the difference, since lots of people have heard of knots but not so many of links). See e.g. the cooperative game theory doc though this is quite comprehensive.
Sometimes there are sort-of-bullet lists that aren't formatted that way, such as for how to create a link.
The plot example doesn't show how to make a plot.

kcrisman commented 9 years ago

Changed reviewer from Miguel Marco to Miguel Marco, Karl-Dieter Crisman

miguelmarco commented 9 years ago

comment:80

Thank you for the review. You are totally right. I will work on that.

kcrisman commented 9 years ago

comment:81

Another random question. So say I look at a random knot page at the atlas, say K11a142. We only seem to have a few of the invariants (which is fine) but what about the non-polynomial invariants? Also, I think we have braid diagrams (?) so maybe we should have some of those in the examples.

miguelmarco commented 9 years ago

comment:82

Sorry, i don't really understand your question. Can you be more explicit about what you propose?

kcrisman commented 9 years ago

comment:83

What I mean is, are any of the non-polynomial invariants like "3-genus" available yet? Just asking.

Secondly, I think that we have a way to plot braids, and this is in the atlas, so we should probably at least mention this in the documentation along with an example or two.

Sorry for any confusion.

amitjamadagni commented 9 years ago

comment:84

Yeah we have genus, signature, determinant, arf invariant (only for knots) which can be seen as invariants as they distinguish between different links. Coming to the plotting of braids, the closure of braids gives a link but the plotting of braids would be not sufficient here as we have to close the braids to get the corresponding link, so we did not consider it as an option.

sagemath / sage

Knot Theory as a part of GSoC 2014. #17030