On Tue, Jun 10, 2014 at 04:19:11PM +0200, Julien Puydt wrote:
> Hi,
>
> Le 10/06/2014 15:14, Bill Allombert a écrit :
> >On Tue, Jun 10, 2014 at 07:13:03AM +0200, Julien Puydt wrote:
> >>Hi,
> >>
> >>Peter Bruin bissected the problem down to a commit (8cfb9c6b,
> >>incorrect rounding in mulur), see comment #91 on the sage bug.
> >
> >First, I need to clarify that PARI never promised to return identical results
> >on 32 and 64 bit platforms, and I do not see anything wrong with commit
> >8cfb9c6b.
> >
> >Secondly, on the face of it, the issue is catastrophic cancellation in
> >computel.gp, in the loop
> >for(y=1,ncoeff,Gvec[d+y]=1.*sum(j=1,d,subst(recG[j],n,y)*Gvec[d+y-j]));
>
> Well, since such cancellation wasn't an issue before, that stops the
> sage people from transitioning out of a heavily patched pari to the
> latest upstream.
As far as I know, the cancellation was an issue before, just not in this
particular example.
> All I can tell is that their Dokchitser code does something like this:
> self._gp_eval('default(realprecision, %s)'%(self.prec//3 + 2))
> and changing the realprecision to self.prec//3+3 fixes gives the
> correct result.
Increasing the precision makes sense, but you should increasing it by
19 to be safe. (PARI precision is in increment of
log(2^(8*sizeof(long)))/log(10)).
> The problem is that I'm not sure I can advocate that change... is it
> really sage doing something wrong?
Sage is using a script that is largely heuristic. They cannot expect
success in all cases.
If you like you can report the problem to the author of the script,
Tim Dokchitser.
But anyway, this is less and less relevant to the Debian package of pari.
Cheers,
--
Bill. <[email protected]>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
