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/#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.
>>>>
>>>
>>>
>> --
> 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.
