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.
