[QUOTE=LaurV;274469]If you start putting your fingers into it, may I be allowed to suggest some other small improvements? [...] At least it would speedup some of my batch processing stuff.. :D[/QUOTE]

You can suggest stuff all you like :smile:.

Long term, I think it would be easier (and make more sense) to integrate yafu into PARI than to try to make yafu look like PARI.

[QUOTE=bsquared;272273]Yes: you can use the yafu.ini file. Just add a line R=1 to it and it will run in ggnfs restart mode.[/QUOTE]

Do I need to remove the R=1 line when I want to do streightforward factorizations (i.e. factorizations which are not resumed factorizations) later?

[QUOTE=Andi47;274519]Do I need to remove the R=1 line when I want to do streightforward factorizations (i.e. factorizations which are not resumed factorizations) later?[/QUOTE]

Generally, no. R=1 just enables a resume to occur, it doesn't force anything to resume.

YAFU plus
 

I like how easily and quickly YAFU lets me count the number of primes between 3*10^18 and 3*10^18+10^10. Is there something like it that would allow me to do this for starting numbers more like 10^30?

Thanks,

David

[QUOTE=dbaugh;274973]I like how easily and quickly YAFU lets me count the number of primes between 3*10^18 and 3*10^18+10^10. Is there something like it that would allow me to do this for starting numbers more like 10^30?

Thanks,

David[/QUOTE]

Thanks!

As of now, no there isn't any way to do that easily.

Experimental versions of yafu some time ago had a "sieve to value" function that would sieve arbitrary ranges of integers with primes up to a specified value. This removes *most* of the composites from the range, but it is impractical to remove them all purely with sieve methods - PRP or primalty tests would need to be run on everything that survived the sieving. I never made that function available. I suppose I could revive it, but it would probably be pretty slow compared to ranges near 10^18. Mind me asking what you are using YAFU for - hobby, school, something else?

I think it would be called an avocation. A distraction from doing my paid work.

A build a the arbitrary precision sieve for Win64 would be very useful to me. If it is faster than counting NextPrime's with Mathematica it would count as a win. I could save the likely primes in a file and then remove remaining composites with pfgw or some such. Overall pretty slow, but better than repeated trial division.

Best regards,

David

@bsquared: Curiosity question:
How big is the upper limit SIQS can go in yafu? I know, I read in doc files that "totally hard cap at 150 digits". But my question is where this limit is coming from? Will it be too snail-slow over this limit? Taking ages? (I observed that the time almost doubles with every 5-6 digits, and I assume that is because each 5-6 digits means a new "digit" in your internal numeration base). Or is it just because it is untested and no one knows if it works? (you said something like that in the docs, but in this case, let some of us testing it, I would happily give it a try for few 140-160 digit numbers or so, just like a return of favor for making such a nice tool). Or are there some other ([B]physical[/B]) limitations like memory not enough for sieving, word lengths, etc.? (i have in my mind something like the discussion of single precision floats against double precision floats related to FFT in the GPU threads)

[QUOTE=LaurV;275952]@bsquared: Curiosity question:
How big is the upper limit SIQS can go in yafu? I know, I read in doc files that "totally hard cap at 150 digits".[/QUOTE]
(maybe you already know this, but...)
For practical reasons, (i.e. time required) you'd want to do GNFS instead of SIQS for anything over a certain cutoff, that's closer to 90-100 digits. When you get anywhere near 150 digits, SIQS is terribly slower than GNFS, and it makes no sense at all (practically) to do it. As to why the limitation is there, I'm not sure, maybe bsquared can answer it. But I'd see nothing wrong with it being a completely artificial limitation, just to help people know to use GNFS instead for anything that large.

Note that the largest QS factorization ever completed had 136 digits. That's not because QS won't fit on your computer anymore, but because eventually it becomes too dificult to find any relations at all. If you get one relation per minute, and need 5 million relations, and GNFS gets 10 million relations in maybe three days, why bother making QS faster, or even workable, for inputs that large?

Ok, thanks for answering. If the only reason is "time related", why not take out the limit? As a matter of fact, there are other (much slower) algorithms programmed inside without such a limitation. Let the cranks like me to play with it, if they want to waste their time....

The largest factorization yafu's siqs has done (to my knowledge) is [URL="http://www.mersenneforum.org/showpost.php?p=161872&postcount=681"]this [/URL]C130 which took ~250 cpu days. By your own estimation, a C150 would be at least 16 times harder (assuming things continue to scale the same - which I would find surprising given the complete SWAG for parameters at those sizes).

That's 4000 cpu days. Even accounting for the fact that yafu is probably about 25% faster now, and that cpus are maybe twice as fast, that's still 1500 cpu days. Versus maybe 25 with gnfs (a quad core for a week).

That said, the limit of C150 is arbitrary. I don't know of a reason why it wouldn't continue to work above that, but at the same time wouldn't be surprised if it didn't. I've never tested it above c130.

Complete a few factorizations up to the current bound. If you still want to go higher after you've done that, I'll raise the limit :smile:.