Thanks for the update.

I've spent the past few weeks making major improvements to lcalc.
I plan to release this updated version in a few weeks.

1) I got rid of the deprecated header files and the unused variables
so it compiles much cleaner.

2) I got lcalc to compile and run with Bailey's double double and quad double,
and also with mpfr (using a newer c++ wrapper for that),
so it now works in arbitrary precision. This took some effort to make sure
all the routines work in higher precision and to deal with some quirks
of each package.

3) I wrote my own cos and sin which is 4 times faster than my machine's (at 
least
on my core2 laptop) and more than twice as fast Bailey's. It uses table a
lookup table of Taylor series. I spent two days hacking it as much as I could.
This makes some key routines 2-3 times faster.

4) I now handle values of s anywhere in the complex plane (rather than a half
plane). I had previously avoided slight complications due to trivial zeros 
cancelling
out poles of the gamma factors in Lambda(s) (completed L-function).

5) I improved the derivatives option substantially using formulas for central 
differences that give much better precision and allow for higher derivatives 
numerically.

6) I am in the process of finishing to wire in Hiary's band limited 
interpolation
routine for the Riemann zeta function when many values are needed. 
At height 10^12 it runs 15 times faster than the straight forward summation of 
the
Riemann Siegel formula, and at height 10^16 it runs a few hundred times faster.

7) I cleaned up and reorganized the makefile and am adding a 'make test'
option that will check whether routines are running to the expected precision.

8) I fixed a couple of bugs that were affecting precision slightly.

9) There is a subtle bug that appears when looking for zeros of L-functions-
sometimes (very rarely) a zero is duplicated and another zero is skipped.
I'll be fixing that up in a little while.

10) Now that openmp is available on gcc with most machines I am going
to make use of that (as a compile option) in some of the key routines.

11) Many other small improvements are planned for later this year:
application of the fft and band limited interpolation to make
zero finding  much faster (by a few orders of magnitude- more
improvement the further one goes).

About the guy who asked about number fields- I might try to get this
to work in my code using pari's routines (not immediately), but having him
try it in sage with Rishi's wrapper would also be a good idea.

Best,
Mike





On Wed, 25 Nov 2009, William Stein wrote:

> On Wed, Nov 25, 2009 at 8:24 AM, Dr. David Kirkby
> <david.kir...@onetel.net> wrote:
>> Pablo De Napoli wrote:
>>> It would be really nice if we can include the new weapper for the lcalc
>>> library.
>>>
>>> http://trac.sagemath.org/sage_trac/ticket/5396
>>>
>>> [marked ad "with patch, neeeds review"]
>>>
>>> Pablo
>>
>> I have been less than impressed with lcalc itself. Of all the packages I have
>
> For balance, I have to comment that I'm more than impressed by what
> lcalc itself actually *does*. It's by far the world's best program at
> computing zeros of L-functions (such as the Riemann Zeta function),
> far surpassing anything available in any other general purpose (or
> otherwise) math software, as far as I know.
>
> It would indeed be very nice to have much more functionality from
> Lcalc exposed in Sage, so I'm glad for 5396 getting finished, finally!
>  Of course, I'm also glad David pointed out the various quality
> issues, and hope they can get addressed too.   Mike -- maybe you can
> hire an undergrad CS major using our grant to knock them out?  They
> don't require any real knowledge of math.
>
> -- William
>
>> met in Sage, it seems to have presented with more than its fair share of 
>> problems.
>>
>> * At one point there was a non-portable option to suppress warnings from the
>> assembler. I fixed that, so it would actually build on Solaris with gcc, with
>> either the Sun or GNU assembler.
>>
>> http://trac.sagemath.org/sage_trac/ticket/6609
>>
>> * I note it used the -no-deprecated (or similar option) to hide the fact the
>> code is deprecated.
>>
>> * It will not build on Solaris with the Sun compiler
>> http://trac.sagemath.org/sage_trac/ticket/7065
>>
>> * It will not build on HP-UX with gcc
>> http://trac.sagemath.org/sage_trac/ticket/7178
>>
>> * If you run 'lint' on the sources, one find numerous variables that are
>> declared but never used.
>>
>> IMHO, lcalc needs a major overhall.
>>
>> I always find it worrying when the source is deprecated, efforts are made to
>> suppress warnings, it is not portable, variables are unused ...It always 
>> makes
>> me wonder what other issues might exist, which I do not know about.
>>
>>
>> Dave
>>
>>
>> --
>> To post to this group, send an email to sage-devel@googlegroups.com
>> To unsubscribe from this group, send an email to 
>> sage-devel-unsubscr...@googlegroups.com
>> For more options, visit this group at 
>> http://groups.google.com/group/sage-devel
>> URL: http://www.sagemath.org
>
>
>
> -- 
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to