#5396: Wrapping lcalc library
------------------------------------------+---------------------------------
Reporter: rishi | Owner: Rishi
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-4.3.2
Component: number theory | Keywords: lcalc
Author: rishi, ylchapuy | Upstream: N/A
Reviewer: John Cremona, David Kirkby | Merged:
Work_issues: |
------------------------------------------+---------------------------------
Old description:
> Wrapping lcalc library
New description:
I plan to release version L-1.3 in a couple of weeks, and also to
have Rishi update his cython wrapper during our march workshop (I made
a handful of changes that will need him to update).
There are a number of key improvements.
Precision-
I've spent quite a bit of effort getting a multiprecision version
of lcalc to work. I now have it working with Bailey's double double
and quad double (about 30 and 60 digits respectively) and also MPFR,
though the latter seems quite slow, perhaps because of the c++ wrapper
that I am using... haven't dug too deep with the latter since
Bailey's dd and qd works quite nicely, and 60 digits is quite reasonable.
Nonetheless,
it does work to higher precision with mpfr.
I am also developing a test suite to be run at compile time to check on
accuracy of many of the routines and do various timing tests.
Output precision-
Rishi needs to handle this carefully since I have a parameter
which describes how many digits of the working digits are accurate.
I use this parameter when outputting my results. Not sure how
or if Rishi makes use of this extra info, or just passes the double
results
of my routines.
At the same time I am wiring in better control of output precision
based on the explicit formula and also on using the smooth approximate
functional equation with a couple of different test functions.
Derivatives-
the version in L-1.23 is very crummy and I fixed that up too
in version L-1.3. I initially just wanted to get that functionality in
there, and I now use (version L-1.3 to be released) higher central
differences for the derivatives that gives an accuracy of about
Digits*4/(n+4) for the nth derivative. So for the 1st derivative,
my new version is accurate to about 4/5 the working precision, so roughly
12-13 digits with double precision and 24-25 digits with Bailey's dd.
Zeros-
I fixed a subtle bug that would on rare occasion cause some zeros to be
omitted
and other zeros to be duplicated in their place.
I'm also finishing to wire in a test of the explicit formula (based on a
prototype that Kevin McGown helped me with in our kickoff frg coding
sprint) that will prevent
such bugs from going unnoticed!
Trivial zeros-
I built in knowledge of the trivial zeros so that correct output is
displayed there.
This allowed me to apply the functional equation correctly, so that the
new version
works throughout the complex plane (previously it gave nonsense results
left of 0).
Band limited interpolation-
I'm wiring in some code of ghaith Hiary for computing zeta using band
limited
interpolation. This will give a significant speedup in, for example,
computing zeros of zeta.
Start at Nth zero-
Ability to start searching for zeros from the Nth zero onward (rather than
always starting from the real axis). This one was long overdue!
Many small improvements that have a big impact-
For example I coded up my own trig functions that are about 4 times faster
than
the machines (for double precision) and also faster than Bailey's and
MPFR's.
Anyhow, my package definitely needs a companion paper and much better
documentation. Something to work on...
Other planned improvements for version L-1.4:
1) broader use of openmp in some of the key routines
2) fft algorithms- will lead to orders of magnitude improvement
especially for higher degree L-funcitons
3) L-functions of number fields and symmetric powers
--
Comment(by mrubinst):
Replying to [comment:60 drkirkby]:
> Replying to [comment:59 cremona]:
> > I think it is important to note here that lcalc can handle a vastly
larger assortment of L-functions than the opposition. For example, the
one value I recomputed independently is of the only kind I can handle with
my code (and I can only compute the value at the centre, not anywhere
else!). So we should not leave the impression that lcalc is inferior just
because it only uses double precision and not multi.
>
> I agree, but there is significant precision loss - perhaps more than
some might expect, so personally I would have thought that worth
documenting. Of course, anyone should know hardware floating point will be
less accurate (but faster) than extended precision in software.
>
> Given for simple computations, 16 digits of precision are possible, but
here only 9, I would have thought that work documenting.
>
> The fact lcalc can handle a vastly larger assortment of L-functions than
anything else should also be noted!
>
> Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5396#comment:61>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
