From nthurston at mac.com  Thu Nov  6 09:51:03 2008
From: nthurston at mac.com (Nathaniel Thurston)
Date: Thu, 06 Nov 2008 14:51:03 +0000
Subject: [SnapPea-planning] Finishing SnapPea 3.0
In-Reply-To: <0K9V001WLDUPP890@smtpin134.mac.com>
References: <0K9V001WLDUPP890@smtpin134.mac.com>
Message-ID: <95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>

Several people (including me) like the idea of my spending some time  
working on SnapPea.

Two things need to happen first, both involving the current users of  
SnapPea:

	1. The most obvious task is to continue adding old features into the  
current OSX application until it can do everything the old one could,  
but I'd like to ask around first.  Dylan, for example, would like it  
to work on linux.  Are there other requests?

	2. There seem to be two obvious routes for funding: find someone who  
wants to contribute unallocated grant funds, and/or apply for a grant  
for the purpose.

So:

Who should I consult regarding ideas about the requirements for the  
next version of SnapPea, or grant funds for the purpose?

Does anyone want to participate in the process of deciding what  
should be done?

Regards,
	Nathaniel


From dpt at math.columbia.edu  Thu Nov  6 12:49:51 2008
From: dpt at math.columbia.edu (Dylan Thurston)
Date: Thu, 6 Nov 2008 18:49:51 +0100
Subject: [SnapPea-planning] Finishing SnapPea 3.0
In-Reply-To: <36BA547C-AAD1-4881-9BCC-EC7F04DBA8BE@mac.com>
References: <0K9V001WLDUPP890@smtpin134.mac.com>
	<95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>
	<E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
	<36BA547C-AAD1-4881-9BCC-EC7F04DBA8BE@mac.com>
Message-ID: <20081106174951.GG26204@amaryllis.bostoncoop.net>

On Thu, Nov 06, 2008 at 12:22:21PM -0500, Bill Thurston wrote:
> 	b. The dirichlet domain command should be more robust,  either by  
> higher accuracy arithmetic or a smarter algorithm that
> isn't killed by (I assume) floating point inaccuracy.

Integration with Snap would do this, although a smarter algorithm
would be faster.

And as long as we're dreaming:
* A more robust generator of short geodesics
* Dealing with non-hyperbolic manifolds

--Dylan


From nmd at illinois.edu  Thu Nov  6 11:08:12 2008
From: nmd at illinois.edu (Nathan Dunfield)
Date: Thu, 6 Nov 2008 10:08:12 -0600
Subject: [SnapPea-planning] Finishing SnapPea 3.0
In-Reply-To: <95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>
References: <0K9V001WLDUPP890@smtpin134.mac.com>
	<95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>
Message-ID: <E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>

Nathaniel,

Great to hear that you are interested in working on SnapPea.   Let me  
give some quick answers now, with perhaps more once I've thought about  
things a bit.

> Two things need to happen first, both involving the current users of  
> SnapPea:
>
> 	1. The most obvious task is to continue adding old features into  
> the current OSX application until it can do everything the old one  
> could, but I'd like to ask around first.  Dylan, for example, would  
> like it to work on linux.  Are there other requests?

In my opinion, a Linux version is probably the greatest need after one  
that works on OS X.  Longer term, a new version that runs on Windows  
might be a good idea.   I don't know whether the current Windows port

http://home.att.net/~Manoharan/SnapPea/snappea.html

is/will be maintained (the source code is not posted, unfortunately)  
and it's missing some of the graphical features of the original Mac OS  
version (IIRC no pictures of Dirchlet domains).  Note: the Windows  
port does run find under Wine on Linux and OS X/Intel and I have used  
it as a stop-gap on those platforms.

> Who should I consult regarding ideas about the requirements for the  
> next version of SnapPea

One additional person you should definitely consult is Marc Culler (culler at math.uic.edu 
), to whom I've taken the liberty of cc'ing this message.   Marc is  
currently working on a new, better, Python interface to the SnapPea  
kernel, using Pyrex/Cython instead of writing the wrappers by hand.   
He has some of the graphical features working, including Dirichlet  
domains, a very nice link editor, and some preliminary horoball  
stuff.    See some pics here:

http://dunfield.info/temp/screen-part.png

He used the cross-platform Tk library for this, so it could form a  
basis for a new GUI, but that is not (I think) his motivation at the  
moment.

More broadly, Saul Schleimer is heavy user of SnapPea who might have  
some ideas on this.


> , or grant funds for the purposes?

The most reasonable person to contact at NSF is Joanna Kania- 
Bartoszynsk.  I'm not sure how much the NSF likes to fund this sort of  
thing, since, while it is clearly needed, it may seem to them like  
maintenance, which they try to avoid, I think.  One might have better  
luck with one of the smaller foundations like AIM or Clay or Jim  
Simon's new Math/Physics thing.  Bus Jaco used to be pretty tight with  
the head of AIM, for instance.

> Does anyone want to participate in the process of deciding what  
> should be done?

Yes.

	Best,

	Nathan


From wpthurston at mac.com  Thu Nov  6 12:22:21 2008
From: wpthurston at mac.com (Bill Thurston)
Date: Thu, 06 Nov 2008 12:22:21 -0500
Subject: [SnapPea-planning] Finishing SnapPea 3.0
In-Reply-To: <E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
References: <0K9V001WLDUPP890@smtpin134.mac.com>
	<95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>
	<E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
Message-ID: <36BA547C-AAD1-4881-9BCC-EC7F04DBA8BE@mac.com>

I'm  enthusiastically in favor of this project, but I'm of course very  
biassed and for that reason not necessarily in the best position for  
seeking NSF funding.  It shouldn't be hard to make a strong case. If  
NSF is constitutionally unsuited (or even if its suited) Nathan's  
other funding suggestions sound  good:
> ... One might have better luck with one of the smaller foundations  
> like AIM or Clay or Jim Simon's new Math/Physics thing.  Bus Jaco  
> used to be pretty tight with the head of AIM, for instance.
especially in light of Dylan's comment (I didn't know)
> That's a good idea.  John Morgan is leaving Columbia to be the
> founding director of the Simons institute; I could approach him.
since Morgan would almost certainly appreciate the significance of the  
project.
> 	1. The most obvious task is to continue adding old features into  
> the current OSX application until it can do everything the old one  
> could, but I'd like to ask around first.  Dylan, for example, would  
> like it to work on linux.  Are there other requests?
Yes the first priority should be getting the OSX version up to speed.  
Still it may be worth thinking ahead toward new capabilities,  
especially because it might make it easier to sell to NSF and others.   
Here are some quick thoughts, things that have nagged me for a while:
	a. It would seem natural to have a "good drillings" view that, at  
least for one cusp, would trace out the boundary
of the region in Dehn surgery  where tetrahedron in (one r  
triangulation | at least one from a set of triangulations) are  
positively oriented. Of course there are lots of additional  
enhancements from this e.g. displaying identification
information for the most significant Dehn fillngs.
	b. The dirichlet domain command should be more robust,  either by  
higher accuracy arithmetic or a smarter algorithm that
isn't killed by (I assume) floating point inaccuracy.
	c. An integrated hyperbolic viewer along the lines of maniview (from  
geomview). Or, as a start, just putting the larger
SO(3,1) group into the Dirichlet domain viewer.
	d.  Identifying Dehn-drilling axes within the dirichlet domain view  
and/or the cusp view.

These are things that don't seem too far out of the way from the  
current snappea. There's other longer-range stuff that would be cool,  
but probably take more thought and more work, such as a "wrapping up"  
search to look for supergroups of finite index (inverse to the finite  
covers command) and a "detriangulate" command that goes from a 3- 
manifold whose fundamental group has parabolic generators
to an embedding in S^3 as a link complement ... or even, drills stuff  
out and then constructs a link ...or ... or ... lots of possibilities.

and ... an iphone version.

	Bill
>
>
> 	2. There seem to be two obvious routes for funding: find someone  
> who wants to contribute unallocated grant funds, and/or apply for a  
> grant for the purpose.
>



> Nathaniel,
>
> Great to hear that you are interested in working on SnapPea.   Let  
> me give some quick answers now, with perhaps more once I've thought  
> about things a bit.
>
>> Two things need to happen first, both involving the current users  
>> of SnapPea:
>>
>> 	1. The most obvious task is to continue adding old features into  
>> the current OSX application until it can do everything the old one  
>> could, but I'd like to ask around first.  Dylan, for example, would  
>> like it to work on linux.  Are there other requests?
>
> In my opinion, a Linux version is probably the greatest need after  
> one that works on OS X.  Longer term, a new version that runs on  
> Windows might be a good idea.   I don't know whether the current  
> Windows port
>
> http://home.att.net/~Manoharan/SnapPea/snappea.html
>
> is/will be maintained (the source code is not posted, unfortunately)  
> and it's missing some of the graphical features of the original Mac  
> OS version (IIRC no pictures of Dirchlet domains).  Note: the  
> Windows port does run find under Wine on Linux and OS X/Intel and I  
> have used it as a stop-gap on those platforms.
>
>> Who should I consult regarding ideas about the requirements for the  
>> next version of SnapPea
>
> One additional person you should definitely consult is Marc Culler (culler at math.uic.edu 
> ), to whom I've taken the liberty of cc'ing this message.   Marc is  
> currently working on a new, better, Python interface to the SnapPea  
> kernel, using Pyrex/Cython instead of writing the wrappers by hand.   
> He has some of the graphical features working, including Dirichlet  
> domains, a very nice link editor, and some preliminary horoball  
> stuff.    See some pics here:
>
> http://dunfield.info/temp/screen-part.png
>
> He used the cross-platform Tk library for this, so it could form a  
> basis for a new GUI, but that is not (I think) his motivation at the  
> moment.
>
> More broadly, Saul Schleimer is heavy user of SnapPea who might have  
> some ideas on this.
>
>
>> , or grant funds for the purposes?
>
> The most reasonable person to contact at NSF is Joanna Kania- 
> Bartoszynsk.  I'm not sure how much the NSF likes to fund this sort  
> of thing, since, while it is clearly needed, it may seem to them  
> like maintenance, which they try to avoid, I think.  One might have  
> better luck with one of the smaller foundations like AIM or Clay or  
> Jim Simon's new Math/Physics thing.  Bus Jaco used to be pretty  
> tight with the head of AIM, for instance.
>
>> Does anyone want to participate in the process of deciding what  
>> should be done?
>
> Yes.
>
> 	Best,
>
> 	Nathan


From nmd at illinois.edu  Thu Nov  6 18:08:46 2008
From: nmd at illinois.edu (Nathan Dunfield)
Date: Thu, 6 Nov 2008 17:08:46 -0600
Subject: [SnapPea-planning] Finishing SnapPea 3.0
In-Reply-To: <20081106174951.GG26204@amaryllis.bostoncoop.net>
References: <0K9V001WLDUPP890@smtpin134.mac.com>
	<95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>
	<E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
	<36BA547C-AAD1-4881-9BCC-EC7F04DBA8BE@mac.com>
	<20081106174951.GG26204@amaryllis.bostoncoop.net>
Message-ID: <8F20C976-23A5-4599-8A25-D473A5482990@illinois.edu>

> On Thu, Nov 06, 2008 at 12:22:21PM -0500, Bill Thurston wrote:
>> 	b. The dirichlet domain command should be more robust,  either by
>> higher accuracy arithmetic or a smarter algorithm that
>> isn't killed by (I assume) floating point inaccuracy.
>
> Integration with Snap would do this, although a smarter algorithm
> would be faster.

Actually, I'm not sure this is true.  As I understand things, Snap  
does not actually include a version of the SnapPea kernel that works  
in high precision.   Rather, it uses the stock SnapPea kernel, but  
then takes the solutions to the gluing equations that the kernel finds  
and further "polishes" them in a separate stand-alone add-on which  
uses the PARI arbitrary-precision type.   Then it further uses the  
PARI library to identify the fields involved, etc.

To connect this to the funding issue, at some point Walter Neumann got  
a grant to rewrite Snap.  The idea, if I recall correctly, was to move  
it from C++ wrapped PARI over to the interpreted PARI language in  
order to make things more flexible/maintainable.   This did not  
actually happen as Oliver Goodman, who was going to do the work, left  
math at that point.  However, it does indicate that some funding for  
this type of project is available, though you'd have to ask Walter to  
find out where he got the grant from.  (Actually, the interpreted PARI  
language (GP) is rather dreadfully primitive, and these days one would  
want to use Sage (www.sagemath.org) instead.  Indeed as a proof of  
concept, I wrote a couple of pages of code which used Sage, rather  
than PARI, to replicate the very basic functions of Snap.)

I think Morwen Thistlethwaite was working on an extended precision  
SnapPea kernel at some point, but I don't know if anything came of it.

	Best,

	Nathan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: snap.py
Type: text/x-python-script
Size: 3795 bytes
Desc: not available
Url : http://lists.bostoncoop.net/pipermail/snappea-planning/attachments/20081106/79ed43d0/attachment-0001.bin 

From dpt at math.columbia.edu  Thu Nov  6 11:46:52 2008
From: dpt at math.columbia.edu (Dylan Thurston)
Date: Thu, 6 Nov 2008 17:46:52 +0100
Subject: [SnapPea-planning] Finishing SnapPea 3.0
In-Reply-To: <E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
References: <0K9V001WLDUPP890@smtpin134.mac.com>
	<95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>
	<E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
Message-ID: <20081106164652.GE26204@amaryllis.bostoncoop.net>

On Thu, Nov 06, 2008 at 10:08:12AM -0600, Nathan Dunfield wrote:
>> Who should I consult regarding ideas about the requirements for the  
>> next version of SnapPea
>
> One additional person you should definitely consult is Marc Culler 
> (culler at math.uic.edu) ...

It's also worth talking to Walter Neumann (neumann at math.columbia.edu)
and Oliver Goodman (oag at ms.unimelb.edu.au).  They are the developers
of Snap, hosted at http://sourceforge.net/projects/snap-pari/ .  I'm
not sure how active that project is.

> ...  One might have better luck with one of the smaller foundations
> like AIM or Clay or Jim Simon's new Math/Physics thing.

That's a good idea.  John Morgan is leaving Columbia to be the
founding director of the Simons institute; I could approach him.

--Dylan


From nathaniel at thething.is  Sat Nov  8 04:39:45 2008
From: nathaniel at thething.is (Nathaniel Thurston)
Date: Sat, 8 Nov 2008 09:39:45 +0000
Subject: [SnapPea-planning] Finishing SnapPea 3.0
In-Reply-To: <8F20C976-23A5-4599-8A25-D473A5482990@illinois.edu>
References: <0K9V001WLDUPP890@smtpin134.mac.com>
	<95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>
	<E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
	<36BA547C-AAD1-4881-9BCC-EC7F04DBA8BE@mac.com>
	<20081106174951.GG26204@amaryllis.bostoncoop.net>
	<8F20C976-23A5-4599-8A25-D473A5482990@illinois.edu>
Message-ID: <AC5F8126-BFE0-4554-A93D-EBD3C1EE25CB@thething.is>

Dear All,

Wow!  It's been a delight to see all of the interest so far.

There seems to be enough interest to set up some mailing lists.   
There are three:
	SnapPea-announce for news of relevance to anyone who uses SnapPea  
(e.g., major releases).
	SnapPea-summary for people who want to stay abreast but don't want  
to get bombarded with too much information.
	SnapPea-planning for those who want to see the details.
I'll be posting the announcements and summaries to the more detailed  
lists, so you only need to subscribe to one of them.
They're all hosted at http://lists.bostoncoop.net/ (Thanks, Dylan!)
Unless anyone objects, I'm going to take the liberty of forwarding  
our discussion to date to the SnapPea-planning list.
This will be my last message to the Cc: list.  If you want to stay  
involved, join one of the lists or let me know otherwise.

Regarding funding, the most favored path seems to be applying for a  
grant.  I'm not ruling out any options yet, but my first choice is  
the Simons institute.  I'm planning to make the initial approach  
soon, while there is still considerable flexibility about the scope  
and direction of the project.

Regarding Dirchlet domains, I was recently contacted by Alexander  
Rahm; he's working on constructing fundamental domains using Bianchi  
groups.  Some thoughts:
	1. His approach (if it works) might be an alternative to the SNAP/ 
numerical routes we've considered so far.
	2. I like the idea of collecting and publishing (online) ideas about  
possible future work.
	3. I also like the idea of organizing a best-practices guide for  
people getting started programming in mathematics.  It would be a  
Good Thing if more of the mathematics programming efforts were as  
well-documented and reusable as SnapPea.

Best Regards,
	Nathaniel

On 6 Nov 2008, at 23:08, Nathan Dunfield wrote:

>> On Thu, Nov 06, 2008 at 12:22:21PM -0500, Bill Thurston wrote:
>>> 	b. The dirichlet domain command should be more robust,  either by
>>> higher accuracy arithmetic or a smarter algorithm that
>>> isn't killed by (I assume) floating point inaccuracy.
>>
>> Integration with Snap would do this, although a smarter algorithm
>> would be faster.
>
> Actually, I'm not sure this is true.  As I understand things, Snap  
> does not actually include a version of the SnapPea kernel that  
> works in high precision.   Rather, it uses the stock SnapPea  
> kernel, but then takes the solutions to the gluing equations that  
> the kernel finds and further "polishes" them in a separate stand- 
> alone add-on which uses the PARI arbitrary-precision type.   Then  
> it further uses the PARI library to identify the fields involved, etc.
>
> To connect this to the funding issue, at some point Walter Neumann  
> got a grant to rewrite Snap.  The idea, if I recall correctly, was  
> to move it from C++ wrapped PARI over to the interpreted PARI  
> language in order to make things more flexible/maintainable.   This  
> did not actually happen as Oliver Goodman, who was going to do the  
> work, left math at that point.  However, it does indicate that some  
> funding for this type of project is available, though you'd have to  
> ask Walter to find out where he got the grant from.  (Actually, the  
> interpreted PARI language (GP) is rather dreadfully primitive, and  
> these days one would want to use Sage (www.sagemath.org) instead.   
> Indeed as a proof of concept, I wrote a couple of pages of code  
> which used Sage, rather than PARI, to replicate the very basic  
> functions of Snap.)
>
> I think Morwen Thistlethwaite was working on an extended precision  
> SnapPea kernel at some point, but I don't know if anything came of it.
>
> 	Best,
>
> 	Nathan
>
>
> <snap.py>


From wpthurston at mac.com  Thu Nov  6 13:44:40 2008
From: wpthurston at mac.com (Bill Thurston)
Date: Thu, 06 Nov 2008 13:44:40 -0500
Subject: [SnapPea-planning] Finishing SnapPea 3.0
In-Reply-To: <20081106174814.GB3567@math.uic.edu>
References: <0K9V001WLDUPP890@smtpin134.mac.com>
	<95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>
	<E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
	<20081106174814.GB3567@math.uic.edu>
Message-ID: <FF00E0C6-CCE4-4A7C-9B12-F0B9065F7E06@mac.com>


On Nov 6, 2008, at 12:48 PM, Marc Culler wrote:

> Planned) Walter Neumann's student, Christian Zickert, has an
> algorithm that will compute Chern-Simons invariants quickly and
> directly, without requiring initialization.  This should be
> implemented in the SnapPea kernel.

A point to perhaps be highlighted if asking the Simons Institute for  
funds!


From jrw at geometrygames.org  Fri Nov  7 14:43:24 2008
From: jrw at geometrygames.org (Jeff Weeks)
Date: Fri, 07 Nov 2008 14:43:24 -0500
Subject: [SnapPea-planning] Dirichlet domain algorithms
Message-ID: <20081107194331.33D881000093@mailhub2.barnard.columbia.edu>

Dear All,

>to compute the distance functions... recursively...

>It's easy to transport this information 
>one simplex to its neighbors,

  This is the tricky step.  Conceptually it's trivial, of course,
  but computationally if we perform an O(3,1) matrix multiplication
  to tranfer the information, then we're setting off down
  the slippery slope of exponentially accumulating error.
  So the question would be, is there a way to propogate
  the information outward while keeping the numerical error
  under control?

As a test case, it's helpful to visualize, say, a Dehn filling
with coefficients (53, 117).  The Dirichlet domain will look almost
like that of the corresponding cusped manifold, but with some
tiny little faces way out where the cusp used to be.
The question is, what's the robust way to locate the vertices
that live way out on the former cusp?

Of course, one must acknowledge from the get-go that
*any* Dirichlet domain algorithm is sure to fail for 
all (p,q) Dehn fillings with sufficiently large p and q, 
even for such (p,q) Dehn fillings on the figure eight knot complement.
The challenge is to find an algorithm that gets us as far as possible
in this toy test case.  One would then hope that such an algorithm
would fare well with the more realistic Dirichlet domains that
one typically wants to study in practice.

Can anybody see how to propogate the direction and distance information
without undue numerical errors?

Best wishes to all,
Jeff


From culler at math.uic.edu  Thu Nov  6 12:48:14 2008
From: culler at math.uic.edu (Marc Culler)
Date: Thu, 6 Nov 2008 11:48:14 -0600
Subject: [SnapPea-planning] Finishing SnapPea 3.0
In-Reply-To: <E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
References: <0K9V001WLDUPP890@smtpin134.mac.com>
	<95A749F5-E2BE-42D0-BF6F-FD80EA0AD513@mac.com>
	<E242F39F-75AB-4D20-AA7C-8CEBBC54D7F8@illinois.edu>
Message-ID: <20081106174814.GB3567@math.uic.edu>

On Thu, Nov 06, 2008 at 10:08:12AM -0600, Nathan Dunfield wrote:
> Nathaniel,
> 
> Great to hear that you are interested in working on SnapPea.   Let me  
> give some quick answers now, with perhaps more once I've thought about  
> things a bit.

While Nathan is thinking, here are a couple of things that we did, or
plan to do, in the python version.

(Done) It turns out that the Smith Normal Form algorithm is
notoriously nasty in that, during the course of the computation, it
tends to generate numbers that are much much bigger than either the
numbers in the input matrix or the output matrix.  This causes SnapPea
to overflow when trying to compute the homology of a not-so-big finite
cover.  The python version uses PARI to do this computation.  (And,
due to the design of PARI, this means embedding all of PARI into
SnapPy.)

(Planned) Walter Neumann's student, Christian Zickert, has an
algorithm that will compute Chern-Simons invariants quickly and
directly, without requiring initialization.  This should be
implemented in the SnapPea kernel.

- Marc


From wpthurston at mac.com  Fri Nov  7 12:56:51 2008
From: wpthurston at mac.com (Bill Thurston)
Date: Fri, 07 Nov 2008 12:56:51 -0500
Subject: [SnapPea-planning] Dirichlet domains
In-Reply-To: <0K9Z00BCL3UJAJF0@smtpin123.mac.com>
References: <0K9Z00BCL3UJAJF0@smtpin123.mac.com>
Message-ID: <4ADB451F-9DF4-4F2E-A448-63C785B2770F@mac.com>

Dear All,
	This is probably getting ahead of ourselves, but it's hard to  
resist!  Jeff, your idea sounds like a good interim measure,
as long as we're not dealing with truly huge manifolds. My thought,  
probably naive, for a conceptually robust algorithm if arbitrary- 
precision arithmetic does not work well: to compute the distance  
functions from images of the base point recursively simplex-by- 
simplex. For each simplex, the length of a homotopy class of paths to  
the base point can be recorded by a vector and a distance from a point  
in the center of each simplex. It's easy to transport this information  
one simplex to its neighbors, and the computations should involve  
modest size nuimbers and little rounding error unless some of the  
simplices are nearly degenerate. This data for a bounded number of  
paths is enough to describe the Dirichlet domain.
	Bill
On Nov 7, 2008, at 12:13 PM, Jeff Weeks wrote:

> Dear All,
>
> I'm delighted to see the breadth of enthusiasm for bringing
> SnapPea up to date, and of course even more delighted that
> Nathaniel plans to do something about it.  :-)
>
> On the subject of the Dirichlet domain computation,
> I agree that a completely new -- and more robust -- algorithm
> would be ideal.  If that's not possible, though, there's
> a simply way to make the existing algorithm more robust.
> As you guys know, the root of the problem is that as you
> perform successive multiplications on matrices in O(3,1),
> the numerical error accumulates exponentially fast.
> In effect, if you do too many matrix multiplications you get garbage.
> The bad news is that exponential accumulation of error seems
> to be an unavoidable fact of life in hyperbolic space.
> The good news is that the effect is far milder in PSL(2,C)
> than in O(3,1) -- many orders of magnitude milder.
> (If anybody wants to see why, I can send you a very elementary paper
> explaining why PSL(2,C) gives better results, and giving
> some estimates of the difference.)
>
> So... a quick-and-easy (well, quick-and-relatively-easy) way
> to improve the Dirichlet domain algorithm's robustness would
> be to replace the O(3,1) matrix multiplications with
> PSL(2,C) matrix multiplications.  (The SnapPea kernel already
> includes a MoebiusTransformation structure that extends PSL(2,C)
> to handle orientation-reversing isometries.)
> The rest of the existing Dirichlet domain algorithm is tied
> pretty heavily to the Minkowski space model, so the simplest
> way to switch over to PSL(2,C) might be to do it "secretly".
> That is, let the rest of the algorithm think it's still working
> in the Minkowski space model with O(3,1) matrices, but extend
> the definition of an O(3,1) matrix to include a "shadow" PSL(2,C)
> matrix.  Then, whenever the main Dirichlet algorithm calls
> the function to multiply together two O(3,1) matrices, that function
> first secretly multiplies the corresonding shadow matrices in  
> PSL(2,C),
> then converts the product to O(3,1) and reports the result.
> The downside, of course, is that you incur the overhead
> of the conversion at each step of the way.  The upside is that
> you can significantly improve the algorithm without undertaking
> the more massive task of rewriting the whole thing in the context
> of PSL(2,C).
>
> Of course, in the face of exponentially accumulating errors,
> that sort of trick merely postpones the inevitable loss of precision
> to larger Dirichlet domains, it doesn't eliminate the problem  
> completely.
> So if Nathaniel (or any of you guys) can come up with
> a fundamentally better algorithm, that would be the ideal solution.
>
> Best wishes to all of you,
> Jeff
>
>
>


From jrw at geometrygames.org  Fri Nov  7 12:13:31 2008
From: jrw at geometrygames.org (Jeff Weeks)
Date: Fri, 07 Nov 2008 12:13:31 -0500
Subject: [SnapPea-planning] Dirichlet domains
Message-ID: <20081107171333.072601000141@mailhub1.barnard.columbia.edu>

Dear All,

I'm delighted to see the breadth of enthusiasm for bringing
SnapPea up to date, and of course even more delighted that
Nathaniel plans to do something about it.  :-)

On the subject of the Dirichlet domain computation,
I agree that a completely new -- and more robust -- algorithm 
would be ideal.  If that's not possible, though, there's
a simply way to make the existing algorithm more robust.
As you guys know, the root of the problem is that as you
perform successive multiplications on matrices in O(3,1),
the numerical error accumulates exponentially fast.
In effect, if you do too many matrix multiplications you get garbage.
The bad news is that exponential accumulation of error seems 
to be an unavoidable fact of life in hyperbolic space.
The good news is that the effect is far milder in PSL(2,C)
than in O(3,1) -- many orders of magnitude milder.
(If anybody wants to see why, I can send you a very elementary paper
explaining why PSL(2,C) gives better results, and giving 
some estimates of the difference.)

So... a quick-and-easy (well, quick-and-relatively-easy) way
to improve the Dirichlet domain algorithm's robustness would
be to replace the O(3,1) matrix multiplications with
PSL(2,C) matrix multiplications.  (The SnapPea kernel already
includes a MoebiusTransformation structure that extends PSL(2,C)
to handle orientation-reversing isometries.)
The rest of the existing Dirichlet domain algorithm is tied
pretty heavily to the Minkowski space model, so the simplest
way to switch over to PSL(2,C) might be to do it "secretly".
That is, let the rest of the algorithm think it's still working
in the Minkowski space model with O(3,1) matrices, but extend
the definition of an O(3,1) matrix to include a "shadow" PSL(2,C)
matrix.  Then, whenever the main Dirichlet algorithm calls
the function to multiply together two O(3,1) matrices, that function
first secretly multiplies the corresonding shadow matrices in PSL(2,C),
then converts the product to O(3,1) and reports the result.
The downside, of course, is that you incur the overhead 
of the conversion at each step of the way.  The upside is that
you can significantly improve the algorithm without undertaking
the more massive task of rewriting the whole thing in the context
of PSL(2,C).

Of course, in the face of exponentially accumulating errors,
that sort of trick merely postpones the inevitable loss of precision
to larger Dirichlet domains, it doesn't eliminate the problem completely.
So if Nathaniel (or any of you guys) can come up with
a fundamentally better algorithm, that would be the ideal solution.

Best wishes to all of you,
Jeff




