I don't really see why having a separate class for the invariants is better
than just having methods in the Link class that produce those invariants. I
mean, i think that the user would expect something like:
sage: L=Link("some entry")
sage: type(L)
<class of links>
sage: L.alexander_polynomial()
t^(-1) + 1 + t
No need to have something like:
sage: L=Link("some entry")
sage: type(L)
<class of links>
sage: LI=L.invariants()
sage: type(LI)
<class of link invariants>
sage: LI.alexander_polynomial()
t^(-1) + 1 + t
In spherogram (which is a part of snappy) there is already something
similar to that. It can be taken as a basis to start with.
By the way, i do consider that besides gauss/DT codes or braids, another
way to enter a knot could be a list of points in space (such that the knot
is the piecewise linear curve defined by them). This kind of input can
appear in real life applications, so it would be good to give support to it.
El lunes, 10 de marzo de 2014 09:26:43 UTC+1, Amit Jamadagni escribió:
>
> Hello,
> I have started working on my proposal and I would like to present
> my ideas of implementation. With my understanding I see two phases to the
> project one which plays around with various representations and conversion
> between them and then a separate class of invariants which would form the
> second phase(But both would be worked on simultaneously, the phase split is
> only to make two as independent as possible). I would like to start of with
> the representation part as there seems to be work done with respect to
> braid groups. We start with the braid word as the input for the knot and
> then calculate the Seifert Matrix and then Alexander's polynomial from this
> matrix. So once an invariant is calculated we can move to the others from
> this (For reference we can use
> http://mathworld.wolfram.com/AlexanderPolynomial.html. A list of total
> implementation of presentation as well as invariants is given in
> http://www.indiana.edu/~knotinfo/ out of which we can try to achieve as
> much as possible taking into consideration the feasibility. Then once we
> are done with the braid word representation I would like to implement the
> Vogel's algorithm which takes in the Gauss Code and generates the braid
> word. So this would be a layer above the initial layer as the user can
> input either the Gauss Code or Briad word and similarly this would linked
> to the Invariants class. Gauss code being closely related to DT code we can
> use the above implementation to generate the DT Code. The presentations
> which remain are the Planar Diagram presentation, Arc presentations, Conway
> notation (This is in comparison to
> http://katlas.org/wiki/The_Mathematica_Package_KnotTheory%60) for which I
> have to find a way in order to convert between.Finally there is the fox
> algorithm from which we can move to the Alexander's polynomial. I am yet to
> see the partial differential implementation in Sage which might be useful
> for this implementation. This would come under the presentation part. So to
> summarize it,
>
> class Various
> presentations ============== class of invariants
> |
> |
> inter conversion
> between
> one presentation to
> other ---------------------------- >same here
> |
> |
> More generally
> this would
> help in taking
> the input for ========> This could be extended to present the various
> diagrams.
> various
> computations
>
> * I feel taking in the input would be the most difficult part even though
> we would provide with a lot of options, I guess user would be more
> interested in giving in a input which is as compact as possible.
>
> I understand the need to focus more on the invariants and I will try to
> add (mainly the algorithms) as much as possible in the coming days.
>
> Finally to test the above implementation we can use the already present
> software which I would like to list in order to what goes for what.
>
> 1. For the Siefert Matrix we have the site
> http://www.maths.ed.ac.uk/~s0681349/SeifertMatrix/#alphabetical
> 2. For Vogel's algorithm we have the GAP implementation ( I still have to
> go through this).
> 3. For braid to DT code we can use knotscape to test the code.
>
> I hope the above outline would take around 4 - 5 weeks with everything in
> place (Considering the documentation, test cases, code including a part of
> the invariants). The rest of the remaining weeks if everything goes
> according to plan would be implementing the other invariants.
>
> I have seen through Spherogram which has a very good implementation of
> links. I am still in the process of reading the entire material and would
> integrate parts of it once I am thoroughly done with it.
>
> This is an outline on which I would like to build my proposal. Any
> comments or further inputs would be of great help in making this project
> successful.
>
> Amit.
>
--
You received this message because you are subscribed to the Google Groups
"sage-gsoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-gsoc.
For more options, visit https://groups.google.com/d/optout.
