I've tested it but seems to be buggy:: it works up to 156 ./part 156 p(156)= 73232243759
but for 157 gives a floating point exception error (and a gdb tracing says it is in the line 176 of the source code r2 = r0 % r1; in function g I've compiled it using gcc part.c -g -lmpfr -lm -DTEST_CODE -o part and my mpfr library is 2.2.1_p5 and gmp is 4.2.1 The code theres seems indeed to be GPL-ed, it has a copyright notice that says: "(C) 2002 Ralf Stephan ([EMAIL PROTECTED]). * See part.pdf on the same path for a summary of the math. * Distributed under GPL (see gnu.org). Version 2002-12." The pdf is: http://www.ark.in-berlin.de/part.pdf Pablo On /26/07, Bill Hart <[EMAIL PROTECTED]> wrote: > > Alternatively you could just use the implementation here: > > http://www.ark.in-berlin.de/part.c > > which seems to only rely on mpfr and GMP. However, since the Pari > version was based on it, I suspect it may also need correction. > > He does seem to adjust the precision as he goes, but I've no idea how > far above or below the required precision this is. However there is no > need to use a precision of 55 from a certain point on. That probably > forces it to use two doubles instead of one in the floating point > computations, which I think would be unnecesary. You can look on > mathworld for how well the Rademacher series converges. > > It would probably be quicker to do a fresh implementation from scratch > given the application in mind. The code there may not be GPL'd also. > > To check it works, one should at least look at the congruences modulo > 5, 7, 11 and 13. The author of the mpfr version does seem to check > them mod 11 but for very small n and only for a very few values of n. > > If the gcds prove to be a bottleneck, I have some code that is roughly > twice as fast as GMP for computing these. Certainly the code in the > mpfr version is suboptimal and needs some serious optimisation when > the terms in the dedekind sum fit into a single limb, which on a 64 > bit machine is probably always, when n is of a reasonable size. > > Another suggestion is that for sufficiently small values of h and or > k, it may be quicker to compute the dedekind sum directly rather than > use the gcd formula. > > A lookup table would also be useful for the tail end of the gcd/ > dedekind sum computation. > > I'd be shocked if the computation for n = 10^9 couldn't be done in > under 10s on sage.math. > > Bill. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---