Hello, I drafted the initial proposal on Github Wiki page (the link which I shared previously and then we had the prototype discussion, sorry as I am unable to provide the link again as I am currently editing the same page) and I would like to mention that I did not post it on melange. I will post it on melange as soon as possible with all the edits. Thanks.
On Sat, Mar 15, 2014 at 4:29 PM, Miguel Angel Marco < [email protected]> wrote: > Do you already have a draft of your proposal? I would suggest you to write > it in the google melange site. That way we could make comments based on the > proposal itself. > > El sábado, 15 de marzo de 2014 11:11:31 UTC+1, Amit Jamadagni escribió: >> >> Hello, >> >> Thanks for the insight and help. I have been working on my >> prototypes and have tried to add methods for other representations as well. >> I would like to post it once I am all done with it. Any other comments on >> the previously posted outline of the proposal would be helpful. It would be >> great if you could comment on whether I am in the right direction or if not >> mention the changes so that it would help me in making a good proposal. >> Thanks. >> >> >> On Fri, Mar 14, 2014 at 6:35 PM, Miguel Angel Marco <[email protected] >> > wrote: >> >>> I like more something like: >>> >>> class Link: >>> def __init__(self, input=None, gauss_code=None, dt_code=None,...): >>> if type(input) == sage.groups.braid.Braid: >>> self._braid = braid >>> self._gauss_code = None >>> self.dt_code = None >>> elif gauss_code!=None: >>> self._braid = None >>> self._gauss_code = gauss_code >>> self.dt_code = None >>> ... >>> >>> def gauss_code(self): >>> if self._gauss_code == None: >>> self._gauss_code= (code to compute the gauss code from the >>> available data) >>> return self._gauss_code >>> >>> >>> And so on. No need to create classes that the user will not use. >>> >>> Even, if we decide to use different formats for DT codes and gauss >>> codes, we wouldn't even need to use special parameters, we could see if the >>> input is one or the other by looking into its format. >>> >>> The main idea is that we will be implementing a few possible >>> representations for a link... but there might be others that could be >>> implemented in the future (polygonal curves in the space, tangles, some >>> kind of codification in a planar graph...). I do not think that creating a >>> class for each representation is a good idea. That would force to touch all >>> the code in the future. >>> >>> Maybe it is a matter of personal taste, but i really prefear to have >>> only one class. But if somebody has some other insights, i would like to >>> hear about it. >>> >>> El viernes, 14 de marzo de 2014 10:43:21 UTC+1, Amit Jamadagni escribió: >>>> >>>> Can we have something like this : >>>> >>>> class Link: >>>> def __init__(self, value, input): >>>> self.value = value >>>> self.input = input >>>> if(self.value == "braidword"): >>>> self.a = Braidword() >>>> if(self.value == "DTCode"): >>>> self.b = DTCode >>>> >>>> def braid2dt(self): >>>> return self.a.braid2dt >>>> >>>> class Braidword(): >>>> def braid2dt(self): >>>> >>>> <Other Methods> >>>> >>>> class DTCode(): >>>> <Methods> >>>> >>>> Similarly other methods from braidword and dtcode would be get >>>> defined under link class and would be called from their respective classes. >>>> This would allow the user to have Link as input and as well others (even >>>> though others might not be of help, they would act as base classes for >>>> link).This would allow particular method from a class and not any method >>>> from any class. Everything again here will be discrete, the classes would >>>> be retained but Link would be having all the methods from the other >>>> representations and in addition some special ones which can be taken from >>>> Spherogram. Any comments on this would be helpful. Thanks. >>>> >>>> >>>> >>>> >>>> On Fri, Mar 14, 2014 at 2:05 AM, Amit Jamadagni <[email protected]>wrote: >>>> >>>>> Hello, >>>>> Yes I got the idea of what you have mentioned. For an update I >>>>> have started working on editing my prototype which would make link as the >>>>> main class. I would update it once I am done with it concretely. Any other >>>>> comments on the implementation details would be of great help. Thanks. >>>>> >>>>> >>>>> On Thu, Mar 13, 2014 at 2:50 PM, Miguel Angel Marco < >>>>> [email protected]> wrote: >>>>> >>>>>> I think that, for the user, it makes much more sense to have just one >>>>>> class (Link), that can be created from a braid, a DT code, a Gauss Code, >>>>>> or >>>>>> a list of 3d points. Then it is up to the class init method to initialize >>>>>> the object in different ways deppending on the type of the input. That >>>>>> is, >>>>>> if the input is a braid, then use the procedure to initialize the object >>>>>> from a braid word. If the input has the format of a DT code, then proceed >>>>>> accordingly, and so on. If it is not possible to distinguish from the >>>>>> format of the input, then maybe a keyword could be used, as >>>>>> >>>>>> sage: Link(gauss_code=[-1, 3, -2, 1, -3, 2]) >>>>>> >>>>>> or >>>>>> >>>>>> sage: Link(dt_code = [4, 8, 10, -14, 2, -16, -18, -6, -12]) >>>>>> >>>>>> and so on. But i definitely not like the idea of the user needing to >>>>>> use different functions to create the same class of objects. Think of >>>>>> what >>>>>> happens with plot, for instance. You can call it on a symbollic >>>>>> expression, >>>>>> a string, a polynomial, a function... and the user doesn't have to care >>>>>> about it. Something similar happens with permutations and many other >>>>>> classes. >>>>>> >>>>>> For instance, if say, the link is created from a gauss code, then the >>>>>> constructor initializes the atribute _gauss_code and leaves the rest as >>>>>> None. Then, the method to compute the DT code would first check which >>>>>> atributes are already defined, and, if _dt_code is None, compute it from >>>>>> the available atributes, and then initialize _dt_code to its value. >>>>>> >>>>>> I hope what i wrote makes sense to you. >>>>>> >>>>>> >>>>>> >>>>>> El miércoles, 12 de marzo de 2014 22:03:45 UTC+1, Amit Jamadagni >>>>>> escribió: >>>>>>> >>>>>>> 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-impl >>>>>>>>>> ementation >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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/#alph >>>>>>>>>>>>>> abetical >>>>>>>>>>>>>> 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. >>>>>> >>>>> >>>>> >>>> -- >>> 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.
