Hello,
Thanks for the review of the outline. I meant a separate class in the
sense we could avoid code duplication to the extent possible. We define a
method in the link class for the invariant, when called would refer to the
class of invariants rather than defining each invariant for every
representation. I guess we can define the invariants for the one kind of
representation and any when an invariant is called from the other
representation we could convert this into the one where we have the
invariant defined and then return the answer.
For example :
We define for the braid word representation and it is easy to get the
Alexander polynomial from this. So given any other representation we could
convert it to braid word and then get the Alexanders polynomial (So for
instance if the user inputs the DT code we can convert it to braid word and
then get the invariant from it rather than writing an algorithm to
calculate from the given representation, I do not say it is not possible
but in some cases, anyways your views on it would be really helpful) .
Similarly if from other presentations we can get some other invariants
quickly we can convert the given input to the present one and then get the
invariant.
Amit.
On Mon, Mar 10, 2014 at 3:16 PM, Miguel Angel Marco <
[email protected]> wrote:
> 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.
>
--
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.
