[SnapPea-planning] Finishing SnapPea 3.0

[Nathaniel Thurston]

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>