Hello,
I feel that taking making the inputs discrete class would allow the
user to choose over the input rather than always asking him to use the
already present braid implementation. Here in this case we can directly
call it as braidwords rather than calling the Braid group first and then
the braid word presentation and then passing it onto as a input for link.
As I have mentioned in the proposal we could have separate classes for
Gauss code and DT codes directly allowing the user to work on this. I have
just had a view at implementation of Spherogram links, they have taken PD
as input and have methods defined for properties of various crossings such
as rotation ...(I may be completely wrong here so please correct me). I
feel having classes for each representation would give freedom to the user
and also calculate more properties relating to the input. I do not intend
to say we must keep it as a separate entity, I would like to mention that
we can construct it in such a way that we can have both these approaches
working rather than just the approach mentioned, so that the user has the
freedom to compute things in a more direct manner. These are my thoughts,
but please correct me if I am going wrong. Thanks.
On Thu, Mar 13, 2014 at 1:45 AM, Amit Jamadagni <[email protected]>wrote:
> 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.
>>>>>>> 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.
>>>>
>>>
>>> --
>> 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.
