Re: Problem with pariGP's factor() function
- --- In firstname.lastname@example.org,
Jack Brennen <jfb@...> wrote:
>Indeed. But Mike's I/O problem, as reported, was with "FNEW" files
> According to the GP built-in help (?factorint) it is feasible that
> any of the k from 8 to 15 could return composite numbers.
from MPQS. So he should be able to fix that with factorint(n,1).
- --- In email@example.com, "mikeoakes2" <mikeoakes2@...> wrote:
>After about 10 times more usage, with Pari-GP Version 2.5.0, exactly one failure has occurred, in this section of code:-
> --- In firstname.lastname@example.org, "djbroadhurst" <d.broadhurst@> 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
> @100% loading, which has activated it about 1.5 billion times -
> and all without a whisper of a problem.
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=
*** 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
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.