From nathaniel at thething.is  Sun May  3 07:41:02 2009
From: nathaniel at thething.is (Nathaniel Thurston)
Date: Sun, 3 May 2009 11:41:02 +0000
Subject: [SnapPea-planning] priorities
In-Reply-To: <C7A9A2B0-7D27-48B2-B8FA-2548CF243284@thething.is>
References: <C7A9A2B0-7D27-48B2-B8FA-2548CF243284@thething.is>
Message-ID: <654026CC-B722-4DB7-AD91-8CBD96881032@thething.is>

Dear All,

I'm getting a better focus on the potential projects after all of the  
feedback.

In the immediate term, I could imagine three potential projects:
	1. Port SnapPea to MacOSX / Cocoa
	2. bring the documentation and unit tests of the Snappea routines up  
to Sage standards.
	3. make the graphics routines work within Sage notebooks.
I'm not sure about the relative priority of these.  In particular, it  
seems to me like (1) would be substantially easier than (3), and also  
that it would provide a better user experience, but of course it would  
only be useful for people who use the Mac.
Marc and/or Nathan, do you have a good idea about how much effort  
would be involved in (1) and (2)?
Jeff, how much time would you expect to spend on an MacOSX port (if  
you were doing one)?

4. more robust Dirchlet domain algorithm
5. requests (grouped by estimated effort required, and ordered by time
of request)
	a. short-term
		identify dehn-drilling axes in viewer [Bill Thurston]
	b. medium-term
		good drillings view [Bill Thurston]
		integrated hyberbolic viewer [Bill Thurston]
		direct computation of Chern-Simons invariant [Marc Culler]
		more robust generator of short geodesics [Dylan Thurston]
		tube radius function for simple geodesics [Dave Gabai]
	c. long-term
		looking for supergroups of finite index [Bill Thurston]
		detriangulate command: manifold -> link complement [Bill Thurston]
		dealing with non-hyperbolic manifolds [Dylan Thurston]
		rewrite snap in sage (use existing work as starting place) [Nathan  
Dunfield]
		systematic treatment of incompressible surfaces [Bill Thurston]
		handle manifolds with higher-genus boundary [Bill Thurston]
		compute hyperbolic structures with infinite volume [Bill Thurston]


From nathaniel at thething.is  Sun May  3 07:48:37 2009
From: nathaniel at thething.is (Nathaniel Thurston)
Date: Sun, 3 May 2009 11:48:37 +0000
Subject: [SnapPea-planning] priorities
In-Reply-To: <C8D01CBE-2D7F-4DB8-ACC1-2A99210BFBEE@gmail.com>
References: <C7A9A2B0-7D27-48B2-B8FA-2548CF243284@thething.is>
	<87473A8D-0478-441D-AA9B-8A1C5698D80D@gmail.com>
	<66ECD059-32B8-4938-89E4-C4105FE28FE0@thething.is>
	<C8D01CBE-2D7F-4DB8-ACC1-2A99210BFBEE@gmail.com>
Message-ID: <C0D55A0B-57F4-40A0-ACA6-904C02C0F3E0@thething.is>

If we're going to get this ambitious, I think it makes sense to  
rewrite the core in a modern language.  I'd favor either Haskell or  
Python (not knowing very much about either), as being friendlier to  
mathematicians who aren't experienced programmers.  Also, there's no  
special reason we can't have both -- we should have a reasonable  
separation of the various modules, and it's possible to write common  
library routines, some of which would handle the conversion between  
human-readable file and internal representation.

I forgot a priority #0 on the previous list -- document a list of  
SnapPea-related projects, with ideas about how to go about  
implementing them.

-- Nathaniel
On 28 Apr 2009, at 17:52, Bill Thurston wrote:

> So --- it's not obvious to me the extent to which it's better (in the
> long run) to separate the different aspects of geometry and topology,
> communicating perhaps by  human-legible and editable ascii files vs.
> the extent to which it's better to aim for a single integrated master
> program whose inner workings are more shielded.


From nmd at illinois.edu  Sun May  3 12:17:08 2009
From: nmd at illinois.edu (Nathan Dunfield)
Date: Sun, 3 May 2009 11:17:08 -0500
Subject: [SnapPea-planning] priorities
In-Reply-To: <C8D01CBE-2D7F-4DB8-ACC1-2A99210BFBEE@gmail.com>
References: <C7A9A2B0-7D27-48B2-B8FA-2548CF243284@thething.is>
	<87473A8D-0478-441D-AA9B-8A1C5698D80D@gmail.com>
	<66ECD059-32B8-4938-89E4-C4105FE28FE0@thething.is>
	<C8D01CBE-2D7F-4DB8-ACC1-2A99210BFBEE@gmail.com>
Message-ID: <C6C8B7E7-68E1-4229-B399-A21ABFCD87E7@illinois.edu>

Bill wrote:
> So --- it's not obvious to me the extent to which it's better (in the
> long run) to separate the different aspects of geometry and topology,
> communicating perhaps by  human-legible and editable ascii files vs.
> the extent to which it's better to aim for a single integrated master
> program whose inner workings are more shielded.

I think that there's a number of forces that cause mathematicians  
collectively to produce a lot of small, specific programs instead of  
integrated work.   For instance, mathematicians typically have  
limited programming skills, and so can only work in one or two  
languages that might well not be that of the more integrated program  
in the area.  Also, If you only need some small thing, learning the  
basics of developing for an integrated system can be a lot of overhead.

The good news is that, and this is the lesson of Sage, many small  
programs can be integrated into a coherent, useable larger program.    
I've done a lot of computations of this mix-and-match type recently  
(e.g. my paper with Dinakar), and Python is very good at allowing you  
stitch things together.

	Best,

	Nathan

P.S. to Nathaniel or Dylan or whomever is maintaining this list:

Could messages sent to the list have the "Reply-To" field set to  
"snappea-planning" rather than the author of the message.

In sending this one, I almost forgot that I needed to reply to all so  
it would go everyone, not just Bill.

From nmd at illinois.edu  Sun May  3 13:10:06 2009
From: nmd at illinois.edu (Nathan Dunfield)
Date: Sun, 3 May 2009 12:10:06 -0500
Subject: [SnapPea-planning] priorities
In-Reply-To: <654026CC-B722-4DB7-AD91-8CBD96881032@thething.is>
References: <C7A9A2B0-7D27-48B2-B8FA-2548CF243284@thething.is>
	<654026CC-B722-4DB7-AD91-8CBD96881032@thething.is>
Message-ID: <1D41F565-9591-4A6C-BB9B-AF375CEFE1E6@illinois.edu>

Nathaniel wrote:
> 	1. Port SnapPea to MacOSX / Cocoa
> 	2. bring the documentation and unit tests of the Snappea routines up
> to Sage standards.
> 	3. make the graphics routines work within Sage notebooks.
> I'm not sure about the relative priority of these.  In particular, it
> seems to me like (1) would be substantially easier than (3), and also
> that it would provide a better user experience, but of course it would
> only be useful for people who use the Mac.
> Marc and/or Nathan, do you have a good idea about how much effort
> would be involved in (1) and (2)?
> Jeff, how much time would you expect to spend on an MacOSX port (if
> you were doing one)?

In terms of the difficulty of (1), it's hard for me to judge, as my  
experience with Cocoa is limited to adding a few features to Jeff's  
version, and I never really became fluent in either Cocoa or  
Objective C.  (I definitely recommend Hillegrass's book on Cocoa, by  
the way.)   My wild guess is that I could do it in 3-4 weeks or so,  
but I'm really not very good at that sort of stuff.   Looking at  
Jeff's draft SnapPeaX compared to SnapPea Classic, I see the  
following tasks:

* Add straight forward to implement features (those with minimal  
graphics):
	* View menu:
		Chern-Simons
		Orientation Cover
		All Covers
		Core geodesics/Holonomies
		Cusp shapes
		(Change) Peripheral curves
		Tetrahedra shapes
		Retriangulation
	* Tools menu:
		Closed census
		Torus bundles
		Isometry

* Link Editor: the current one was an interesting experiment, but  
needs to be replaced with an old-style one.    Here, Marc's Plink  
(Python/tk) would be an excellent model, and since Objective-C and  
Python are *very* similar, you should be able to lift the basic  
structure from that.

* Cusp neighborhoods: The graphics in Jeff's version Classic version  
are very detailed, but limited user interaction, just sliding the  
image around.

* Finish the Dirichlet domain viewer.  In particular, you need to be  
able to click on the cells of the polytope and get information about  
them.

I would say that the above is about as much (maybe a little more) as  
what already exists, so if Jeff remembers how much time he put into  
the Cocoa version, you've probably got that much left.

------

(2) Is very straight-forward.  It would take me less than a week to  
do, maybe quite a bit less.  Marc and I are currently polishing  
SnapPy (as the new Python interface to SnapPea is called), and adding  
doctests is pretty trivial.  (See http://docs.python.org/library/ 
doctest.html for more on this).

Also, one only needs to add such things if one wants SnapPy to be  
part of *default* install.   As an optional packages such niceties  
aren't necessary.

------

(3) Let me experiment a bit and get back to you on this, and maybe  
consult the folks on sage-devel for their insight.

	Best,

	Nathan





From nmd at illinois.edu  Sun May  3 14:41:06 2009
From: nmd at illinois.edu (Nathan Dunfield)
Date: Sun, 3 May 2009 13:41:06 -0500
Subject: [SnapPea-planning] priorities
In-Reply-To: <C0D55A0B-57F4-40A0-ACA6-904C02C0F3E0@thething.is>
References: <C7A9A2B0-7D27-48B2-B8FA-2548CF243284@thething.is>
	<87473A8D-0478-441D-AA9B-8A1C5698D80D@gmail.com>
	<66ECD059-32B8-4938-89E4-C4105FE28FE0@thething.is>
	<C8D01CBE-2D7F-4DB8-ACC1-2A99210BFBEE@gmail.com>
	<C0D55A0B-57F4-40A0-ACA6-904C02C0F3E0@thething.is>
Message-ID: <689F912C-0D95-47B7-9C97-3DA8E4C3F9C9@illinois.edu>

> If we're going to get this ambitious, I think it makes sense to
> rewrite the core in a modern language.  I'd favor either Haskell or
> Python (not knowing very much about either), as being friendlier to
> mathematicians who aren't experienced programmers.  Also, there's no
> special reason we can't have both -- we should have a reasonable
> separation of the various modules, and it's possible to write common
> library routines, some of which would handle the conversion between
> human-readable file and internal representation.

In an ideal world, rewriting the core in a modern language would make  
sense, but in this one I suspect it's too low on the reward/work  
ratio to be worth it --- for one thing, it would be a tremendous  
amount of work, even with todays more expressive programming languages.

Also, you can get a lot of the benefits of rewriting the core by just  
mixing it in with more modern code.  For instance:

* Marc and I wrote, some years ago, a Python triangulation package  
called "t3m" (which is available at our website).  It does basic  
normal surface theory, including spun normal surfaces.   We have a  
class that "mixes" t3m's representation of a 3-manifold  with  
SnapPea's and allows you to do things like this:

 >>> from boundary_slopes import *
 >>> M = OneCuspedManifold("8_20")
 >>> M.find_normal_surfaces()
 >>> M.boundary_slopes()
[(0, 1), (1, 0), (2, -1), (4, -1), (8, 3), (10, -1)]
 >>> M.volume()
4.1249032518076758
 >>> M.fundamental_group()
Generators:
    a,b
Relators:
    aabbaabbaaBAAAB

* In this context,  I should also mention Ben Burton's program  
"Regina" (http://regina.sf.net) which focuses on Normal surface  
theory.   The core triangulation library is written in C++ and there  
is a full python interface to this.  He also has a complete GUI,  
based on KDE/Qt, which runs on Linux and OS X.  Ben's program is very  
well documented, though I haven't used it all that much.  (Which I  
think comes back to my response to Bill's question about big vs.  
small.  Ben's program is big, and when it was first introduced was  
very hard to get to compile much less mess with.  I think it is much  
better now, but I haven't been motivated to look at it much because,  
of course, I already understand how t3m works...)

---------------------------

In terms of additional items for your wish list, an idea version of  
GUI SnapPea would encompass Damian Heard's orbifold additions to  
SnapPea as shown in his Orb program.

	Best,

	Nathan








From nmd at illinois.edu  Tue May  5 14:59:55 2009
From: nmd at illinois.edu (Nathan Dunfield)
Date: Tue, 5 May 2009 13:59:55 -0500
Subject: [SnapPea-planning] priorities
In-Reply-To: <654026CC-B722-4DB7-AD91-8CBD96881032@thething.is>
References: <C7A9A2B0-7D27-48B2-B8FA-2548CF243284@thething.is>
	<654026CC-B722-4DB7-AD91-8CBD96881032@thething.is>
Message-ID: <FF5C268C-B09B-4177-B5C2-C8EE5BD26425@illinois.edu>

> 	3. make the graphics routines work within Sage notebooks.
> I'm not sure about the relative priority of these.  In particular, it
> seems to me like (1) would be substantially easier than (3), and also
> that it would provide a better user experience, but of course it would
> only be useful for people who use the Mac.

Dear All,

I played with Sage's graphics capabilities and found that basic 2d and  
3d stuff works fine.  The examples at http://wiki.sagemath.org/ 
interact give an example of the possibilities.

Starting with Marc's PyOpenGL code for viewing Dirichlet domains, I  
was easily able to show Dirichlet domains in the Klein model.  When I  
tried the Poincare model, both as Jeff's SnapPeaX and SnapPy do, it  
worked, but not as well as either of the former.   This is not  
surprising, as Sage's 3d graphics comes from the the Java-based Jmol,  
rather than OpenGL.  (Sage also has a built-in ray-tracer which  
produces pretty, but static, pictures).   It's also quite possible  
that I'm not doing things in the optimal way, but in any event the  
Poincare model is the just the visual icing on the cake.

This is certainly an instance where a picture is worth N >> 0 words,  
so see

http://sagenb.org/home/pub/513/

for the results.   You should be able to rotate the Dirichlet domains  
about, regardless of whether you have Sage installed.  You can use the  
scroll wheel of your mouse to zoom in and out.  Near as I can tell,  
you can't make them spin in the canonical SnapPea way.

The things are unclear to me are:

1) If clicking on the 3d image can be reported and tied to a  
particular face/edge/vertex
2) How one would write a link editor.

I will make some inquiries on this.

	Best,

	Nathan


From nathaniel at thething.is  Wed May  6 05:44:00 2009
From: nathaniel at thething.is (Nathaniel Thurston)
Date: Wed, 6 May 2009 09:44:00 +0000
Subject: [SnapPea-planning] priorities
In-Reply-To: <FF5C268C-B09B-4177-B5C2-C8EE5BD26425@illinois.edu>
References: <C7A9A2B0-7D27-48B2-B8FA-2548CF243284@thething.is>
	<654026CC-B722-4DB7-AD91-8CBD96881032@thething.is>
	<FF5C268C-B09B-4177-B5C2-C8EE5BD26425@illinois.edu>
Message-ID: <5B58FDE9-B5A8-4DB4-BF94-7D08E8E127A7@thething.is>

Dear All,

Wow, that was fast!  It's starting to sound like you're going to do  
(3) without my intervention...

--Nathaniel

On 5 May 2009, at 18:59, Nathan Dunfield wrote:

>> 	3. make the graphics routines work within Sage notebooks.
>> I'm not sure about the relative priority of these.  In particular, it
>> seems to me like (1) would be substantially easier than (3), and also
>> that it would provide a better user experience, but of course it  
>> would
>> only be useful for people who use the Mac.
>
> Dear All,
>
> I played with Sage's graphics capabilities and found that basic 2d and
> 3d stuff works fine.  The examples at http://wiki.sagemath.org/
> interact give an example of the possibilities.
>

From nathaniel at thething.is  Wed May  6 05:55:56 2009
From: nathaniel at thething.is (Nathaniel Thurston)
Date: Wed, 6 May 2009 09:55:56 +0000
Subject: [SnapPea-planning] News
Message-ID: <424077FB-F396-4C8F-A249-6C4D380A4F1E@thething.is>

I spoke with Michael Douglas from the Simons Center yesterday, and  
he's given the project a green light, to start in June.  News:
	1. It's expected that I spend up to about 1 week working on the  
project every month or two.
	2. I will be needing a "manager/administrator" from the group to sign  
off on the time I spend working on SnapPea.
	3. I'll be spending about half of my time (at least initially)  
writing better documentation of what we already have.

--Nathaniel

From wpthurston at gmail.com  Wed May  6 09:34:08 2009
From: wpthurston at gmail.com (Bill Thurston)
Date: Wed, 6 May 2009 09:34:08 -0400
Subject: [SnapPea-planning] News
In-Reply-To: <424077FB-F396-4C8F-A249-6C4D380A4F1E@thething.is>
References: <424077FB-F396-4C8F-A249-6C4D380A4F1E@thething.is>
Message-ID: <22890BFB-6681-47B6-B8A8-0326706F6DCB@gmail.com>

Fantastic!  It's exciting to see things start to converge and move.
	Bill
On May 6, 2009, at 5:55 AM, Nathaniel Thurston wrote:

> I spoke with Michael Douglas from the Simons Center yesterday, and
> he's given the project a green light, to start in June.  News:
> 	1. It's expected that I spend up to about 1 week working on the
> project every month or two.
> 	2. I will be needing a "manager/administrator" from the group to sign
> off on the time I spend working on SnapPea.
> 	3. I'll be spending about half of my time (at least initially)
> writing better documentation of what we already have.
>
> --Nathaniel
> _______________________________________________
> SnapPea-planning mailing list
> SnapPea-planning at lists.bostoncoop.net
> http://lists.bostoncoop.net/mailman/listinfo/snappea-planning


From nmd at illinois.edu  Fri May  8 03:21:23 2009
From: nmd at illinois.edu (Nathan Dunfield)
Date: Fri, 8 May 2009 02:21:23 -0500
Subject: [SnapPea-planning] priorities
In-Reply-To: <5B58FDE9-B5A8-4DB4-BF94-7D08E8E127A7@thething.is>
References: <C7A9A2B0-7D27-48B2-B8FA-2548CF243284@thething.is>
	<654026CC-B722-4DB7-AD91-8CBD96881032@thething.is>
	<FF5C268C-B09B-4177-B5C2-C8EE5BD26425@illinois.edu>
	<5B58FDE9-B5A8-4DB4-BF94-7D08E8E127A7@thething.is>
Message-ID: <C00FBB4A-73A3-4A3B-9A1A-C27468CF47E4@illinois.edu>

On May 6, 2009, at 4:44 AM, Nathaniel Thurston wrote:
> Wow, that was fast!  It's starting to sound like you're going to do
> (3) without my intervention...

Oh, there's no risk of that.  I just did the easy bit.   As for the  
two remaining issues that I mentioned in my last message:

1) Clicking on a cell in the Dirichlet domain and getting information  
about that cell.

I think this is possible, though I didn't look into it in detail.    
The 3D viewer Sage uses (it's a Java app), called Jmol, comes from  
chemistry, and the standalone version allows you to select atoms and  
measure how far apart they are.  So it can at least relate clicks to  
objects in some way, and presumably one can go from there.

Regardless, there are other, arguably better ways of getting this  
information to the user if this is not possible.  E.g. one could have  
a list of cell equivalence classes, with the information about  
dihedral angles, etc., and when the user clicks a class, it  
highlights in the 3d-view.   Or, and this is probably better, one  
could have a check-box for each class and all classes with a checked  
boxes are highlighted (in different colors, with the connection  
between color and class clear).

2) A link editor.

For this, I think one would need to write a link editor in Java or  
Javascript, and it would then be straight forward to integrate this  
with Sage's notebook.

For instance, some Sage folks are currently working on a similar  
editor for graphs.   You can see the drafter version here:

http://www.math.uiuc.edu/~rkirov2/processing/grapheditor.html

and the discussion about it in the thread:

http://groups.google.com/group/sage-devel/browse_thread/thread/ 
834be3b28bd7919f/01bf6e54a0d1e7af?hl=en&

There's already a primitive (compared to Marc's plink) Java knot  
editor here:

http://www.indiana.edu/~knotinfo/homelinks/knotsketcher.html

	Best,

	Nathan



From genevieve.walsh at gmail.com  Mon May 11 17:13:27 2009
From: genevieve.walsh at gmail.com (Genevieve Walsh)
Date: Mon, 11 May 2009 17:13:27 -0400
Subject: [SnapPea-planning] funding?
Message-ID: <1eed48460905111413x604df5a5v410f8965e6876189@mail.gmail.com>

I'm not sure what is going on with the funding (I'm a little out of the loop
on this) but doesn't this sounds like us?  I keep thinking that the snappea
project should be funded in a major way, and by the NSF (isn't this the kind
of thing they should be doing?) Note bullets 1 and 2 (and 3) below.

This is a new influx of money from the stimulus.

Genevieve.


   1. *MRI-R2 <http://www.nsf.gov/pubs/2009/nsf09561/nsf09561.htm#mri22>
Program
   Purpose and Goals*

The primary purpose of the
MRI-R2<http://www.nsf.gov/pubs/2009/nsf09561/nsf09561.htm#mri22>
program
is to facilitate scientific and engineering research and research training
through the acquisition or development of research instrumentation.
Therefore, the MRI-R2<http://www.nsf.gov/pubs/2009/nsf09561/nsf09561.htm#mri22>
program
will not support the acquisition or development of instrumentation used
primarily for standard science and engineering education courses, or for
general purpose instrumentation that does not have a common or specific
research focus.  Other uses of the instrumentation may serve to facilitate
the broader impacts of the project.

Proposals to the
MRI-R2<http://www.nsf.gov/pubs/2009/nsf09561/nsf09561.htm#mri22>
program
should conform to one or more of its goals:

   -

   Supporting the acquisition of major state-of-the-art instrumentation,
   thereby improving access to, and increased use of, modern research and
   research training instrumentation by scientists, engineers, and graduate and
   undergraduate students;
   -

   Fostering the development of the next generation of instrumentation,
   resulting in new instruments that are more widely used, and/or open up new
   areas of research and research training;
   -

   Enabling academic departments, disciplinary and cross-disciplinary units,
   and multi-organization collaborations to create well-equipped research
   environments that integrate research with education;
   -

   Supporting the acquisition and development of instrumentation that
   contributes to advancements in supercomputing technology, and/or takes
   advantage of existing investments in cyberinfrastructure while avoiding
   duplication of services already provisioned by NSF investments.  The NSF
   document, ?Cyberinfrastructure Vision for the 21st Century? (
   http://www.nsf.gov/pubs/2007/nsf0728/index.jsp) provides an evolving
   vision that will help guide the Foundation's future investments in
   cyberinfrastructure;
   - Promoting substantive and meaningful partnerships for instrument
   development between the academic and private sectors (i.e., small
   businesses).  Such partnerships have the potential to build capacity for
   instrument development in academic settings and to create new products with
   wide scientific and commercial impact.  Partnerships with applicability to
   the Industry/University Cooperative Research Centers (I/UCRCs) program are
   encouraged.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bostoncoop.net/pipermail/snappea-planning/attachments/20090511/21ba4bb7/attachment.htm 

From nathaniel at thething.is  Thu May 14 13:24:29 2009
From: nathaniel at thething.is (Nathaniel Thurston)
Date: Thu, 14 May 2009 17:24:29 +0000
Subject: [SnapPea-planning] funding?
In-Reply-To: <1eed48460905111413x604df5a5v410f8965e6876189@mail.gmail.com>
References: <1eed48460905111413x604df5a5v410f8965e6876189@mail.gmail.com>
Message-ID: <890FF407-6186-4A12-B43F-9E982FB1C467@thething.is>

This may well be us, and I would agree that SnapPea should be better- 
funded.  I don't know anything about writing grant proposals (the  
process with the Simons Center was informal) -- is there anyone more  
knowledgeable who would like to assist in preparing a grant application?

--Nathaniel

On 11 May 2009, at 21:13, Genevieve Walsh wrote:

> I'm not sure what is going on with the funding (I'm a little out of  
> the loop on this) but doesn't this sounds like us?  I keep thinking  
> that the snappea project should be funded in a major way, and by the  
> NSF (isn't this the kind of thing they should be doing?) Note  
> bullets 1 and 2 (and 3) below.
>
> This is a new influx of money from the stimulus.
>
> Genevieve.
>
> MRI-R2 Program Purpose and Goals
> The primary purpose of the MRI-R2 program is to facilitate  
> scientific and engineering research and research training through  
> the acquisition or development of research instrumentation.   
> Therefore, the MRI-R2 program will not support the acquisition or  
> development of instrumentation used primarily for standard science  
> and engineering education courses, or for general purpose  
> instrumentation that does not have a common or specific research  
> focus.  Other uses of the instrumentation may serve to facilitate  
> the broader impacts of the project.
>
> Proposals to the MRI-R2 program should conform to one or more of its  
> goals:
>
> Supporting the acquisition of major state-of-the-art  
> instrumentation, thereby improving access to, and increased use of,  
> modern research and research training instrumentation by scientists,  
> engineers, and graduate and undergraduate students;
>
> Fostering the development of the next generation of instrumentation,  
> resulting in new instruments that are more widely used, and/or open  
> up new areas of research and research training;
>
> Enabling academic departments, disciplinary and cross-disciplinary  
> units, and multi-organization collaborations to create well-equipped  
> research environments that integrate research with education;
>
> Supporting the acquisition and development of instrumentation that  
> contributes to advancements in supercomputing technology, and/or  
> takes advantage of existing investments in cyberinfrastructure while  
> avoiding duplication of services already provisioned by NSF  
> investments.  The NSF document, ?Cyberinfrastructure Vision for the  
> 21st Century? (http://www.nsf.gov/pubs/2007/nsf0728/index.jsp)  
> provides an evolving vision that will help guide the Foundation's  
> future investments in cyberinfrastructure;
>
> Promoting substantive and meaningful partnerships for instrument  
> development between the academic and private sectors (i.e., small  
> businesses).  Such partnerships have the potential to build capacity  
> for instrument development in academic settings and to create new  
> products with wide scientific and commercial impact.  Partnerships  
> with applicability to the Industry/University Cooperative Research  
> Centers (I/UCRCs) program are encouraged.
> _______________________________________________
> SnapPea-planning mailing list
> SnapPea-planning at lists.bostoncoop.net
> http://lists.bostoncoop.net/mailman/listinfo/snappea-planning

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bostoncoop.net/pipermail/snappea-planning/attachments/20090514/b0729639/attachment.htm 

From saulsch at math.rutgers.edu  Sun May 24 22:11:42 2009
From: saulsch at math.rutgers.edu (Saul Schleimer)
Date: Sun, 24 May 2009 22:11:42 -0400 (EDT)
Subject: [SnapPea-planning] snappea request (fwd)
Message-ID: <Pine.GSO.4.44.0905242210410.16680-100000@math.rutgers.edu>


Dear Nathaniel -

  Nathan mentioned to me your plan to start working on SnapPea.  Let me
just say that this is a wonderful idea.  I've read the archived messages
with great interest, and subscribed to the list.
  Let me make two requests of the future SnapPea:

1. [Easy] Finer control of cusp settings: In the Cusp Neighborhoods
window, there is a slider for each cusp.  The maximum setting for each
slider is where that cusp first bumps itself.  The minimum setting is
where the cusp has volume 3 sqrt(3) / 16.  SnapPea then computes (and
shows in the cusp viewing window) the canonical triangulation with respect
to the given cusp settings.

When there is only one cusp this is a non-issue: there is only one
canonical triangulation.  When there is more than one cusp there are
finitely many canonical triangulations.  (If you play with the sliders
while looking at the cusp viewing window you can see the retriangulation
happening.)  The current minimum settings of the slider prevents us from
seeing all of the canonical triangulations.  I am particularly interested
in seeing the "stable" canonical triangulation - ie the one that you get
as the blue cusp volume goes to zero.

[Example: look at m295, from the red cusp, with blue on the minimal
setting: the canonical triangulation has vertices on the blue cusp
of height 0.631703 and of height 0.427413.  If we shrank the blue cusp the
canonical triangulation would only have vertices on the larger.  This can
be seen via a nice trick shown me by Futer and Gueritaud - take a double
cover and look from red with blue on minimal setting.  This gives the
correct canonical triangulation.]

Implementation: There is no minimum setting that will work for all
manifolds.  But allowing the cusp volume go to 3 sqrt(3) / 32 certainly
deals with all examples I've looked at.  Perhaps the correct thing to do
is leave the default setting where it is and provide a window where the
user can type in a smaller value (ie a negative one.)

2. [Harder] A window to view Dehn surgery space for the k^th cusp of the
manifold.  Perhaps click on a point and the vital statistics of the filled
manifold are shown.  In this window there should be little dots on the
integral points and the "good region" (where solution_type =
'all tetrahedra positively oriented' or 'contains negatively oriented
tetrahedra') should be in white while the bad region should be in black.
In particular this gives a visual way to see the set of exceptional
surgeries.  The shape of the bad region reflects very interesting
questions about the representation variety of the manifold.

Easy implementation: for every pixel reinitalize the manifold and compute.
(This is very slow, but looks very accurate and is dead easy to code.)

Irritating implementation: Work in polar coordinates - for every radial
ray reinitalize and then compute for every pixel along the ray, working
from the boundary of the viewing window towards zero.  As soon as you
enter the bad region, go on to the next ray.  (This is much faster
and hopefully still accurate.  Trickier to code.)

Very irritating implementation: crawl along the boundary of the bad
region.  Fill in the disk bounded by the curve you find.  This might be
lightning fast, but who knows how stable it will be: see the examples
below.

Here is a bit of ASCII art - the bad region for m004:

    ######################################
      ##################################
       ################################
       ##########            ##########
        ############ #####  ##########
        #########   ######   #########
       ##########            ##########
       ################################
      ##################################
    ######################################

and for m378

                                              #
                                            ###
                                          #####
                                        #######
                                      #########
                                    ###########
           ##                   ###  ##########
             #####################   ##########
             ####################   ###########
             ###################    ###########
              ##################    ###########
              ##################    ###########
              ##################    ########## #
              ##################   ##########  #
              ##################   # ######    #
              ##########  #######     ####    ##
              ##########    #       # ##      ###
              ##########     ####  ##       #####
               #########     # # ##      #########
                ###########  #  ###################
                 ############  #######  ###########
                  ########## # ###### #   ##########
                  #######     ## ######     #########
                   ####     #  ##     #     ##########
                   ##      ##           #   ##########
                   ##    ####   #  ######## ##########
                    #   ########   ###################
                    # ##########    ##################
                    ############    ##################
                    ############    ##################
                    ############    ##################
                    ###########     ##################
                    ###########   #####################
                    ###########  #######################
                    #############                       #
                    ##########
                    ########
                    ######
                    ####
                    ##

best,

saul



From saulsch at math.rutgers.edu  Sun May 24 22:12:01 2009
From: saulsch at math.rutgers.edu (Saul Schleimer)
Date: Sun, 24 May 2009 22:12:01 -0400 (EDT)
Subject: [SnapPea-planning] snappea request (fwd)
Message-ID: <Pine.GSO.4.44.0905242211450.16680-100000@math.rutgers.edu>


One more obvious thought - you can use the central symmetry of the Dehn
filling plane to get a two-fold speed-up.  Also, I should have mentioned
Boileau's definition of an exceptional surgery:

Suppose that M is finite volume hyperbolic and T is a cusp.  Then the
surgery (p, q) is _nonexceptional_ if there is a cone deformation from
\rho_0 (at infinity) to (p,q) along the radial ray (ie from angle zero to
angle 2\pi) through hyperbolic manifolds (including at (p,q)).

best,

saul





From saulsch at math.rutgers.edu  Sun May 24 22:12:42 2009
From: saulsch at math.rutgers.edu (Saul Schleimer)
Date: Sun, 24 May 2009 22:12:42 -0400 (EDT)
Subject: [SnapPea-planning] snappea request (fwd)
Message-ID: <Pine.GSO.4.44.0905242212120.16680-101000@math.rutgers.edu>



---------- Forwarded message ----------
Date: Sun, 24 May 2009 20:52:42 -0500
From: Nathan Dunfield <nmd at illinois.edu>
To: Saul Schleimer <saulsch at math.rutgers.edu>
Cc: nathaniel at thething.is
Subject: Re: snappea request

Saul,

Back when I was in graduate school, I wrote a program to probe the
boundary of hyperbolic Dehn surgery space in the manner that you
describe.  It worked by the following method:

- For each lattice point x in a large square, do a change of
peripheral basis so that x is a meridian.   Then move in along the
corresponding ray in the following manner:

/*

This function finds the point on the boundry of hyperbolic Dehn
surgery space along the ray in the meridian direction.   The algorithm
works like this: At each stage we consider two points along the ray,
lower_pt and upper_pt, where lower_pt < upper_pt, lower_pt is some
kind of degenerate solution and upper_pt is a geometric solution
(allowing neg. oriented tetra.).  We then consider the midpoint of
upper_pt and lower_pt and test it to see if it lies in hyperbolic Dehn
surgery space. If the midpoint does then it becomes the new upper_pt,
else it becomes the new lower_pt. The algorithm terminates once
upper_pt and lower_pt are closer than the constant sensitivity or if
max_iter is exceeded.  The function puts the final lower_pt in the
varible final_lower_point and returns the solution type of the
final_lower_pt.

The function does not change manifold.  Setting the intial_lower_pt to
0 is OK as in this case, the function does not check to see if the
intial_lower_pt represents a non-geometric solution.

The function find_bdry_of_hyperbolic_dehn_surgery_space calls
sub_find... several times with different starting points in order to
deal with the problem of sub_find reporting much to small of numbers.

*/

I've attached the source code.  My recollection is that it worked fine
but was slow.  But that was more than 10 years ago, so it runs pretty
quickly now...

--------

Also, Saul, I think it would be a good idea if you forwarded your
messages, and this one, to the snappea-planning list for posterity.

	Best,

	Nathan




-------------- next part --------------
A non-text attachment was scrubbed...
Name: find_bdry_of_surgery_space.cc
Type: application/octet-stream
Size: 4925 bytes
Desc: 
Url : http://lists.bostoncoop.net/pipermail/snappea-planning/attachments/20090524/1d2d11a7/attachment.obj 

