## Re: Problem with pariGP's factor() function

Expand Messages
• ... After about 10 times more usage, with Pari-GP Version 2.5.0, exactly one failure has occurred, in this section of code:-
Message 1 of 49 , Jan 2, 2012
• 0 Attachment
--- In primenumbers@yahoogroups.com, "mikeoakes2" <mikeoakes2@...> wrote:
>
> > default(primelimit,10^6);
> > saferfactor(x)=trap(,factor(x,0),factorint(x,1));
> > should be both fast and safe, for your 12-digit targets,
> > since it combines all three of the offered remedies,
> > each of which is inferior by itself.

> I have been running this code for 18 hours now, on 4 cores
> and all without a whisper of a problem.

After about 10 times more usage, with Pari-GP Version 2.5.0, exactly one failure has occurred, in this section of code:-

saferfactor(x)=trap(,factor(x,0),factorint(x,1));
{write_line(k,x)=f=saferfactor(kk);...

The error is not repeatable in debug mode, witness this transcript:-

*** at top-level: ...)>=Kmin)&&(abs(k)<=Kmax),write_line(k,x));y+=
*** ^--------------------
*** in function write_line: ...nd,pow_str,len=0,s="");f=
*** saferfactor(kk);facs
*** ^--------------------
*** in function saferfactor: trap(,factor(x,0),factorint(x,1))
*** ^---------------
*** factorint: bug in PARI/GP (Segmentation Fault), please report
*** Break loop: type 'break' to go back to GP
break> kk
359507948009
break> saferfactor(6)
[2 1]
[3 1]
break> saferfactor(kk)
[7 1]
[59 1]
[27031 1]
[32203 1]

The code has been runnng exclusively on 12-digit integers, of which there are a lot(!); about 2% of them have been processed to date.

So, it looks as if there is yet one more strand to the clutch of pari coding bugs in this area.

Mike
• ... After about 10 times more usage, with Pari-GP Version 2.5.0, exactly one failure has occurred, in this section of code:-
Message 49 of 49 , Jan 2, 2012
• 0 Attachment
--- In primenumbers@yahoogroups.com, "mikeoakes2" <mikeoakes2@...> wrote:
>
> > default(primelimit,10^6);
> > saferfactor(x)=trap(,factor(x,0),factorint(x,1));
> > should be both fast and safe, for your 12-digit targets,
> > since it combines all three of the offered remedies,
> > each of which is inferior by itself.

> I have been running this code for 18 hours now, on 4 cores
> and all without a whisper of a problem.

After about 10 times more usage, with Pari-GP Version 2.5.0, exactly one failure has occurred, in this section of code:-

saferfactor(x)=trap(,factor(x,0),factorint(x,1));
{write_line(k,x)=f=saferfactor(kk);...

The error is not repeatable in debug mode, witness this transcript:-

*** at top-level: ...)>=Kmin)&&(abs(k)<=Kmax),write_line(k,x));y+=
*** ^--------------------
*** in function write_line: ...nd,pow_str,len=0,s="");f=
*** saferfactor(kk);facs
*** ^--------------------
*** in function saferfactor: trap(,factor(x,0),factorint(x,1))
*** ^---------------
*** factorint: bug in PARI/GP (Segmentation Fault), please report
*** Break loop: type 'break' to go back to GP
break> kk
359507948009
break> saferfactor(6)
[2 1]
[3 1]
break> saferfactor(kk)
[7 1]
[59 1]
[27031 1]
[32203 1]

The code has been runnng exclusively on 12-digit integers, of which there are a lot(!); about 2% of them have been processed to date.

So, it looks as if there is yet one more strand to the clutch of pari coding bugs in this area.

Mike
Your message has been successfully submitted and would be delivered to recipients shortly.