Hello,
I have drafted a proposal which still has a lot to add, this is in
between the totally finished and a rough outline. I would need some reviews
and comments on it. Thanks.
https://github.com/amitjamadagni/Knots/wiki/Knot-theory-implementation
On Tue, Mar 11, 2014 at 2:46 PM, Miguel Angel Marco <
[email protected]> wrote:
> Well we should check in which cases it is faster to convert from one
> representation to another and then compute the invariant, or directly use
> another method to compute the invariant from a different representation. My
> intuition tells me that the traduction between different representations
> will be very fast compared to the computation of the invariant... but it
> wouldn't hurt to run some benchmarks.
>
> I don't think that having two different methods to compute, say, the knot
> group, from the braid representation and from the DT code would really mean
> a duplication problem: they would be two different methods that do
> different things.
>
>
> El lunes, 10 de marzo de 2014 19:58:06 UTC+1, Amit Jamadagni escribió:
>>
>> 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.c
>>>> om/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.
>
--
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.
