#19011: Add Jones representation of braid groups and Jones polynomials of braid
closures
-------------------------------------+-------------------------------------
Reporter: fuglede | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.9
Component: algebraic | Resolution:
topology | Merged in:
Keywords: | Reviewers:
Authors: Søren Fuglede | Work issues:
Jørgensen | Commit:
Report Upstream: N/A | ff004ad100d5fafaa7934757f433f6ae292a071d
Branch: | Stopgaps:
u/fuglede/jones_rep |
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by fuglede):
Yeah, looking at it for a collection of different rings certainly makes
sense. I don't think I've seen anyone actually consider that, though.
One thing that is common, though, is to not view the entries as elements
of the Laurent polynomial ring but rather a quotient thereof (since this
is what generalizes to higher genus surfaces in TQFT), so there might be a
point in allowing for some freedom in that direction.
It's worth noting, also, that the calculation of the representation on the
generators is reasonably fast, compared to actually manipulating the
resulting matrices: I know that the point is to save both memory and time,
but in my testing, it is significantly faster (roughly a factor of ~20) to
calculate the representation in the desired ring to begin with, than it is
to calculate it for {{{IntegerRing}}} and then use {{{subs}}} entry-wise
to obtain a matrix with entries in the desired ring.
Finally, I should note that an earlier version didn't actually use the
caching decorator. It's included now since it can play a role for braid
groups on a large number of strings. Then the number of strings is large,
it is the combinatorial part, i.e. the first loop in {{{create_TL_rep}}}
that takes up most of the time (in my testing, for the braid group on 14
strings, roughly 75% of the time is spent there). Putting together these
observations, to accommodate for the use case where one wants to save
memory while working with a large number of base rings, it would be
sensible to refactor and cache only the first part of the method,
reconstructing the actual matrices on every execution. This will, though,
slow down what I think is the more common use case of manipulating only
the representation over {{{IntegerRing}}}, so I'm not a big fan of doing
that.
--
Ticket URL: <http://trac.sagemath.org/ticket/19011#comment:12>
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 http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
