Hello,
Thanks for the review. I have seen the braid.py in groups in Sage
and would like to make that as a starting point. I will have a look at it
and try to bring it in the prototypes. I have also mentioned that it would
be my start point. I have started going through Spherogram and would add
the inputs from it as well. Any other comments would be really helpful in
making it more perfect. Thanks.
On Thu, Mar 13, 2014 at 1:37 AM, Miguel Angel Marco <
[email protected]> wrote:
> At a very first glance, i would like to mention that sage already has a
> class for braids, so i think it woul be better to have something like this:
>
> sage: B=BraidGroup(2)
> sage: b=B([1,1,1])
> sage L=Link(b)
> ...
>
> That way we could also accept gauss/DT codes to create the Link.
>
> Also, i strongly recommend you to take a look at spherogram, since it
> already implements a class for links.
>
>
>
> El miércoles, 12 de marzo de 2014 16:04:48 UTC+1, Amit Jamadagni escribió:
>>
>> 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.
>
--
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.
