#17030: Knot Theory as a part of GSoC 2014.
-------------------------------------+-------------------------------------
Reporter: amitjamadagni | Owner: amitjamadagni
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-7.2
Component: algebraic | Resolution:
topology | Merged in:
Keywords: | Reviewers: Miguel Marco, Karl-
Authors: Amit Jamadagni, | Dieter Crisman, Frédéric Chapoton,
Miguel Marco | Travis Scrimshaw
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/ticket/17030 | 0cce5891b429ea267c45bd89adacff6ebb12e453
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:170 fuglede]:
> Cool, that's also what I suspected back then. Where I come from, Seifert
surfaces are connected by definition; that can make life a bit easier --
in particular in this situation where you can just use the same definition
for the Alexander polynomial regardless of the chosen surface.
Yes, definitely.
> In any case, by "cylinder", I meant something homeomorphic to ''S''^1^ ×
[0, 1] which has boundary two separated unknots, and which has non-trivial
''H'',,1,,.
In that case, I agree. Although this doesn't agree with Seifert's
construction AFAIK, and for 4+ components, at least by my understanding of
how you are constructing things, wouldn't give a surface.
> In that case, a Seifert matrix is the 1x1 zero matrix. Likewise in the
case of the unknot, you can avoid having to ponder about 0x0 matrices,
since ''H'',,1,,(''D''^2^ × '''R''', '''Z''') may be presented by the 1x1
unit matrix.
>
> For the case at hand, the algorithm still produces incorrect results for
links which bound disconnected oriented surfaces (I would not call such
links "disjoint", since link components are ''always'' disjoint);
>
> {{{
> sage: B3 = BraidGroup(3)
> sage: b = B3([1, 2, -2])
> sage: b.alexander_polynomial()
> 0
> sage: Link(b).alexander_polynomial()
> 1
> }}}
In that case the `2 -2` are canceled automatically by the braid group:
{{{
sage: B = BraidGroup(4)
sage: B([1,2,-2])
s0
}}}
So it becomes just 1 unknot as far as the code currently works. Which is
why we get an Alexander polynomial of 1.
> And a weirder example:
>
> {{{
> sage: B2 = BraidGroup(2)
> sage: b = B2([1, -1])
> sage: b.alexander_polynomial()
> 0
> sage: Link(b).alexander_polynomial()
>
---------------------------------------------------------------------------
> ValueError Traceback (most recent call
last)
> <ipython-input-14-c27fd62b3305> in <module>()
> ----> 1 Link(b).alexander_polynomial()
>
> /home/fuglede/repos/sage/local/lib/python2.7/site-
packages/sage/knots/link.pyc in alexander_polynomial(self, var)
> 1244 R = LaurentPolynomialRing(ZZ, var)
> 1245 # The Alexander polynomial of disjoint links are defined
to be 0
> -> 1246 if len(self._braid_word_components()) > 1:
> 1247 return R.zero()
> 1248 t = R.gen()
>
> /home/fuglede/repos/sage/local/lib/python2.7/site-
packages/sage/knots/link.pyc in _braid_word_components(self)
> 899 ml = list(self.braid().Tietze())
> 900 if not ml:
> --> 901 raise ValueError("the braid remains the same with no
components")
> 902
> 903 l = set(abs(k) for k in ml)
>
> ValueError: the braid remains the same with no components
> }}}
>
> Edit: Ah, it looks like for the first one of those examples, the library
throws away one of the components (is that intended? According to the
docs, only "The strands of the braid that have no crossings at all are
removed", and in this case, all of them have crossings; they just happen
to be pretty trivial).
In both cases this is what is going on. Although we could special case the
identity element of the braid group, but this wouldn't handle when the
input is `B([3, 1, -3, -1])`. I'm somewhat unsure if we really should push
this in as-is. I think it is a very good addition, but not dealing with
these lingering braid group issues seems to cause confusion... I can try
to fix things up a little bit to handle all of these issues, but I'm not
sure I will be successful with out a substantial rewrite (which I am not
sure I have the mathematical knowledge to do).
--
Ticket URL: <http://trac.sagemath.org/ticket/17030#comment:171>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" 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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.