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]<javascript:> > > 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] <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.
