[QUOTE=henryzz;324676]Currently I think I can only find a list of roadblocks that when cleared would simplify the proof for >=1600. Is there a list anywhere of composites the if factored would allow a proof to n digits?[/QUOTE]

If I understand correctly, when Pascal adapted Kevin Hare's method of working around roadblocks, he also got the phenomenon that there are no longer absolute limits. Both proofs can always go a little bit higher by adding more roadblock circumvention calculations. But the roadblock circumvention calculations are much bulkier that the factor chains possible when factors are known. Extending the proofs becomes a management of resources problem - deciding when it is more efficient to make more roadblock circumvention calculations versus when to factor some of the roadblocks.

Since Bob isn't posting much anymore, I'll take the time to acknowledge that at some point there is not much new mathematics in this allocation of resources. Pascal doesn't seem to feel we have reached that point yet, but even if the professional mathematicians lose interest there is still fun, and there are potential benefits from the accumulated factorizations.

Pascal recently asked for help with these level six and level five roadblocks that we have been tracking here. Offlist, Ryan Propper has recently factored over 30 of Pascal's most heavily weighted roadblocks below 200 digits. I'll post more about this in the not-too-distant future..

[QUOTE=henryzz;324676]How were the initial factors to forbid chosen? Was it just experimentation?[/QUOTE]

Maybe "observation" is a little more appropriate than "experimentation." For example, they do 13 before 3 because a proof for three will always have

3^2 -> 13

(i.e If 3^2 || N, then sigma(3^2)=13 divides N)

without forbidden factors, a nearly entire proof for 13 becomes embedded in the 3 proof right here. I don't know of anything more systematic than observing these natural redundancies.

Running "./yafu "snfs(200029^37-1, (200029^37-1)/(2^2*3*79*211))" -threads 8" it will automatically start sieving? I'm trying to run yafu on linux.

carlos

With the latest svn, like ~r285 or so (current is 291). 1.33 doesn't have it; it's still in testing phase.

[QUOTE=Dubslow;324738]With the latest svn, like ~r285 or so (current is 291). 1.33 doesn't have it; it's still in testing phase.[/QUOTE]

I need some guidance. Where can I find that version?

[url]http://yafu.svn.sourceforge.net/viewvc/yafu/trunk/[/url]

There has not been a formal release yet; like I said, it's still in testing. I can send you a binary if you'd like.

[QUOTE=henryzz;324676] I assume there would be different lists for total number of prime factors and largest component.
[/QUOTE]

For the largest component, we deal with numbers with at most 63 digits: everything has been factored. For the total number of prime factors, we do not have many roadblocks, and their impact on the running time is negligible. There are many composites that are not roadblocks, but the speed up obtained from their factorization is not worth it. In most cases, if such a composite is factored into two prime factors, then the subtree is not even modified (that is, no speed up at all), since the algorithm already takes into account that a composite has at least two prime factors. For a composite in the "total number of prime factors"-list, we are more happy if we get a factor and a composite cofactor rather than a full factorization into two primes.

What am I doing wrong? Do I need the snfs file or yafu searches for the right poly?

./yafu "snfs(200029^37-1, (200029^37-1)/(2^2*3*79*211))" -threads 8


[code]nfs: commencing nfs on c197: 13817824122658419547399851017557180330278983713767365721715619950128113918378644044199224283682279984169863968440019858817534432706309179958135262942735575203332682472043807416507625261347929241708
nfs: searching for brent special forms...
Expected to create 10 schedules on side 0, have 6
Aborted (core dumped)
Segmentation fault (core dumped)[/code]

Oh joy. Run
[code]gdb --args ./yafu "snfs(200029^37-1, (200029^37-1)/(2^2*3*79*211))" -threads 8[/code]
and then when it fails, type `bt full` and copy/paste the output into an email to me.

It should be generating the poly on its own, but it looks like it fails somewhere in the form detection code.

I don't understand your bt full command but it is generating at least two polys.

Hmm... what are the polys it's generating? Does that mean it's not crashing anymore? (Could a mod move these to the yafu bugs thread?)