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]<javascript:> > > 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] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> 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.
