Hi,
Le 10/06/2014 21:09, Bill Allombert a écrit :
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.
I find the fact that it was working on 32bits with pari 2.5 and it's now
failing on 32bits with pari 2.7 disturbing...
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.
It's heuristic, but it did work.
But anyway, this is less and less relevant to the Debian package of pari.
Upstream bugs are relevant... and I'm not convinced yet there isn't one
hiding in there.
Snark on #debian-science
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
