Differences between revisions 7 and 10 (spanning 3 versions)
 ⇤ ← Revision 7 as of 2008-11-09 11:08:11 → Size: 1413 Editor: was Comment: ← Revision 10 as of 2008-11-14 13:42:12 → ⇥ Size: 1738 Editor: anonymous Comment: converted to 1.6 markup Deletions are marked like this. Additions are marked like this. Line 6: Line 6: 1. Stuff still computed using gp: 1. Modularize the code (break into the following classes and sort dependencies)        * LSeries (Is already in there. Have to free it from the other 3 modules)        * GammaFactor (Done and documented)        * IncompleteGeneralizedGammaFactor (To be done)        * InverseMellinGammaFactor (To be done)    2. Stuff still computed using gp: Line 12: Line 18: 2. Doctest everything, making sure it all works 100% and fix issues with coercion, complex inputs, etc., as they are systematically uncovered.    3. Possibly maybe change from digits to bits prec.    4. Optimize. 3. Doctest everything, making sure it all works 100% and fix issues with coercion, complex inputs, etc., as they are systematically uncovered.    4. Possibly maybe change from digits to bits prec.    5. Optimize. Line 36: Line 42: Dokchiter's Paper: attachment:dokchitser.pdf Dokchiter's Paper: [[attachment:dokchitser.pdf]]

# Dokchitser Project for Sage Days 11

TODO:

1. Modularize the code (break into the following classes and sort dependencies)
2. Stuff still computed using gp:
• Delta polynomials in _recursions_at_infinity (search for comment below)
• _without_gp (gamma_series) has this line
• sinser = sage_eval(rs(gp_eval('Vec(sin(Pi*(%s)))'%(z0+x))))
• init_Ginf: still uses pari (see below)
• Ginf: still uses pari to evaluate continued fraction
3. Doctest everything, making sure it all works 100% and fix issues with coercion, complex inputs, etc., as they are systematically uncovered.
4. Possibly maybe change from digits to bits prec.
5. Optimize.

From Jen:

Here's the version (closest to Dokchitser's original pari code) that still uses continued fraction approximation:

(needs gamma_series.py to run:

The version with Pade approximation (l5.py) has a negligible speedup but only really works for low precision. I'm not sure if Pade gives us a means of computing bounds (I think Mike Rubinstein said that continued fractions won't). Also, l4.py doesn't work for imaginary inputs yet - some coercion with SymbolicRing that I didn't try.

Dokchiter's Paper: dokchitser.pdf

days11/projects/dokchitser (last edited 2008-11-14 13:42:12 by anonymous)