[SnapPea-planning] priorities

[Nathan Dunfield]

Nathaniel,

Some comments on your list.

> 1. finish tcl port (cross-platform graphics; test for mac osx & linux
> compatibility)

It seems to me that you should really test for Windows compatibility  
as well if you're going with TCL approach (instead of Cocoa/GNUStep or  
QT or...).  Windows has become more common as a default platform in  
math departments, at least in the States.  Using Windows in a virtual  
machine (e.g. VMWare) is pretty painless, really.

Also, I assume by the "tcl port" you mean Jeff's SnapPea 3.0b which  
used Python with TCL's windowing system "Tk".  Of course, one  
requirement for the above is that the Python interface be finished;  
it's mostly done but there are some functions that aren't wrapped.   
Marc and I are planning on finish that up over the summer.   (Writing  
the wrappers is trivial in Cython, though so you could just add them  
as you go if necessary).

As Marc mentioned, he has written a Tk link editor (which is  
excellent), a Dirichlet domain viewer (using OpenGL, so it should work  
with any interface) as well as a preliminary horoball viewer.    
However, there are no other GUI elements, so it's not as far along as  
perhaps Marc's message seems to indicate. (I would have given it at  
most one "O" ;-)  Certainly, it could be a starting point for  
Nathaniel's project.

Also, Marc has been working on some preliminary packaging of SnapPy  
using Python's distutils, and we're looking into options for making a  
"clickable" app under OS X.

(Dylan: I think this answers your question as to the status of the  
Python interface, but if not I can clarify further.)

> 2. sage interface

This is no different that the Python interface, and I've already added  
in the Sage specific features, mostly using GAP or Magma to do a  
better job finding finite covers.   Making it a Sage optional package  
should be trivial once Marc gets the distutils things working. One  
could consider getting it included as a default part of Sage, but this  
would require putting in a lot of unittests and documentation (they  
have pretty high standards).    This would, of course be a good thing  
in and of itself, though perhaps time consuming.   At the end of this  
message is the docstring for the cover method, which gives some idea  
of the Sage interaction.

> O 		rewrite snap in sage [Nathan Dunfield]
> (Nathan has written a 'proof of concept' script, and has some plans
> for continuing.)

This is correct except of the "plans for continuing" bit.

Regardless, I'm excited to here that the Simons Institute is likely to  
fund work on SnapPea.

Best,

	Nathan

Sage and SnapPy play well together:

sage: import SnapPy
sage: M = SnapPy.Manifold("m004")
sage: M.cover?
Type:             builtin_function_or_method
Base Class:       <type 'builtin_function_or_method'>
String Form:   <built-in method cover of SnapPy.SnapPy.Manifold object  
at 0x8044fb8>
Namespace:        Interactive
Docstring:

             Returns a Manifold representing the finite cover
             specified by a transitive permutation representation.  The
             representation is specified by a list of permutations,  
one for
             each generator of the simplified presentation of the
             fundamental group.  Each permutation is specified as a  
list P
             such that set(P) == set(range(d)) where d is the degree  
of the
             cover.

             If within SAGE the permutations can also be of type
             PermutationGroupElement, in which case they act on the set
             range(1, d + 1).  Or, you can specify a GAP or MAGMA  
subgroup
             of the fundamental group.     Some examples:

             sage: M = SnapPy.Manifold("m004")

             # The basic method
             sage: N0 = M.cover([[1, 3, 0, 4, 2], [0, 2, 1, 4, 3]])

             # From a Gap subgroup

             sage: G = gap(M.fundamental_group())
             sage: H = G.LowIndexSubgroupsFpGroup(5)[9]
             sage: N1 = M.cover(H)
             sage: N0 == N1
             True

             # Or a homomorphism to a permutation group

             sage: f = G.GQuotients(PSL(2,7))[1]
             sage: N2 = M.cover(f)
             sage: N2.volume()/M.volume()
             7.9999999999999947

             # Or maybe we want larger cover coming from the kernel of  
this.

             sage: N3 = M.cover(f.Kernel())
             sage: N3.volume()/M.volume()
             167.99999999999858

             # Check the homology against what Gap computes directly

             sage: N3.homology().Betti_number()
             32
             sage: len([ x for x in  
f.Kernel().AbelianInvariants().sage() if x == 0])
             32

             # We can do the same for Magma

             sage: Q, f = G.pQuotient(5, 1, nvals = 2)
             sage: M.cover(f.Kernel()).volume()
             sage: h = G.SimpleQuotients(1, 11, 2, 10^4)[1,1]
             sage: N4 = M.cover(h)
             sage: N2 == N4
             True

sage: M.all_covers?
Type:		builtin_function_or_method
Base Class:	<type 'builtin_function_or_method'>
String Form:	<built-in method all_covers of SnapPy.SnapPy.Manifold  
object at 0x8044fb8>
Namespace:	Interactive
Docstring:

             Returns a list of Manifolds corresponding to all of the
             finite covers of the given degree.

             WARNING: If the degree is large this might take a very,  
very,
             very long time.

             If you are using SAGE, you can use GAP to find the  
subgroups,
             which is often much faster, by specifying the optional  
argument

             method = "gap"

             If you have Magma installed, you can used it to do the  
heavy
             lifting by specifying method = "magma".

Class Docstring:
     <attribute '__doc__' of 'builtin_function_or_method' objects>