Date: Feb 7, 2013 1:19 PM
Author: David Bernier
Subject: Re: PARI/gp wins my Riemann zeta speed contest, so far
On 01/21/2013 12:23 AM, David Bernier wrote:
> I had done my own Riemann zeta computations with Bernoulli numbers,
> computing in days a few 10,000 (say 55,000) decimals of
> the imaginary part of the first non-trivial zero
> 1/2 + i*14.13... using PARI-gp.
> This time, I used PARI-gp's own zeta(.):
> ? system(date);zeta(t);system(date)
> Sun Jan 20 03:36:28 EST 2013
> Sun Jan 20 07:10:17 EST 2013
> // 20,000 decimals precision
> // t is with 1/10^400 of first non-trivial zero.
> 3 hours and 34 minutes for 20017 significant digits
> near 1/2 + i*14.134725141734693790457251983562470270784257
> ? \p
> realprecision = 20017 significant digits (20000 digits displayed)
> ? a=zeta(t);
With realprecision \p set to 40,000 digits, something strange
happened with zeta(.):
*** at top-level: zeta(s)
*** zeta: the PARI stack overflows !
current stack size: 500000000 (476.837 Mbytes)
[hint] you can increase GP stack with allocatemem()
*** Break loop: type 'break' to go back to GP
*** Warning: new stack size = 2000000000 (1907.349 Mbytes).
^C *** at top-level: zeta(s)
*** zeta: user interrupt after 38h, 47min, 59,768 ms.
about 39 hours and has not completed. > 500 MB of stack needed.
I was double-checking my Euler-Maclaurin computations.
To be continued ...
dracut:/# lvm vgcfgrestore
File descriptor 9 (/.console_lock) leaked on lvm invocation. Parent PID
Please specify a *single* volume group to restore.