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(.):

? zeta(s)

*** 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

break> break

? allocatemem(2000000000)

*** Warning: new stack size = 2000000000 (1907.349 Mbytes).

? zeta(s)

^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 ...

David Bernier

--

dracut:/# lvm vgcfgrestore

File descriptor 9 (/.console_lock) leaked on lvm invocation. Parent PID

993: sh

Please specify a *single* volume group to restore.