Hello,
This is the draft of the proposal
https://github.com/amitjamadagni/Knots/wiki/Knot-theory-implementation. Any
comments on this would be really helpful. Thanks.
On Sat, Mar 15, 2014 at 5:43 PM, Amit Jamadagni <[email protected]>wrote:
> 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.
