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