I also have to report a small problem, related to fibo numbers. Got in my list "I(1049)/66871114224246686249583360541620833)", and I was surprised that yafu has no idea what to do with it. It took me a while to realize that is the fib(1049) after searching through the factordb tables. So I had to manually edit the file and replace it with fib(xxx) as yafu knows it.

Can something be done (in yafu to recognize I(...) as the fibo function, or in the data base to report it like fib(..)) to avoid this kind of problems in the future? I mean, most users won't even realize, if they get a bunch of numbers, that one of them is skipped from the output report. In my case it was just luck that I saw it.

Now as another rhetorical question, is there any way to resume an "yafu nfs()" command, if the computer crashed (for different reasons, not related to yafu) and the only available files are about 60 megs of "nfs.dat.p" and about 2 megs of "nfs.dat.0.p"? I mean there is no "ggnfs.job" and no "session.save" available, just the two files above, checked "-R" but it just restarts from poly 12.

I ask because I am crunching the C185 from above since last Friday and my computer crashed 3 times that evening (restart again by bios) probably because of electricity breaks (trouble with big floods here around). Fortunately it ran ok over the weekend and this morning I found the 60 megs of the files above, I would feel quite sorry to lose them at all if - god forbid - another crash happens... In fact to lose 3 days f work, because the file are still there fine thanks...

Sequence 360840 also broke just now: it says 'Error on number 25546882901999266122383172472132566395747844071088901416635434329351190073543786907038511855567961915654490741855089875884096941965043943400' just after I'd submitted the factor 5055665580392101656332147458022948328871794706297 for term 400.

If i click on the button "Do quick selftest" i become the answer:
Checking yafu: ..yafu failed!

yafu fails for me too.

And group orders are messed up.

The FactorDB seems to have great problems:

Look at any Factor Table and the first pages:

There're always FF-numbers without any factors shown or only small factors but missing the remaining.

Hi everyone,

I think I found the problem - installed a new version of yafu but messed with the user rights.
Everything should be working now, just a little bit slow until the index is fully rebuilt.

Sorry for the problems!

[QUOTE=Syd;269831]Hi everyone,

I think I found the problem - installed a new version of yafu but messed with the user rights.
Everything should be working now, just a little bit slow until the index is fully rebuilt.

Sorry for the problems![/QUOTE]No trouble. We were all just worried that something broke permanently.

[QUOTE=LaurV;269756] "I(1049)/66871114224246686249583360541620833)"

... I am crunching the C185 from above since last Friday ...[/QUOTE]

I am going nuts, replying to my own posts...
Well, first of all thanks to bb for replying to my question in the "yafu" thread. It seems like if the yafu crash in the poly phase of a nfs job it is not too much to do.. Or at least, let's say it is over my head of knowledge to start combining polys by hand.

Guess what, my wheelbarrow crashed last night (most probably electricity break, caused by the floods in my area). I am left with about 60 megs of poly's don't know what to do with them. If someone think the stuff is useful, tell me where to send it. If not, it will be deleted in a couple of days (about 4 days of work lost) and restart from the beginning. Put a new coin, pull the lever once more, see if three lemons in a row will pop.

[QUOTE=LaurV;269861]If not, it will be deleted in a couple of days (about 4 days of work lost) and restart from the beginning. Put a new coin, pull the lever once more, see if three lemons in a row will pop.[/QUOTE]

The data is not useful... re-read fivemack's post in the yafu thread. The number is doable with SNFS and doesn't need the GNFS polynomials. At a minimum, copy the stuff in his post into nfs.job and start yafu with "nfs(fib(1049)/66871114224246686249583360541620833))" -siever 14 -r. For extra credit, study why this works.

Already did that, sieving since. Figured by myself the part with "-R" (didn't know small r works too). See my reply there. Thanks both of you.

SNFS poly select & algebraic factors
 

from the [URL="http://www.mersenneforum.org/showthread.php?t=15977"]SNFS poly select 919^87-1[/URL] thread:

[QUOTE=Stargate38;269847]Here's a poly from factordb for 919[SUP]87[/SUP]-1 (166 digit cofactor): [URL]http://www.factordb.com/snfs.php?id=1100000000225474717[/URL][/QUOTE]

[QUOTE=frmky;269851]This auto-generated polynomial doesn't take advantage of the known algebraic factor. I agree that the original sextic is the obvious choice.[/QUOTE]

(note: the "original sextic" is posted in the starting post of the aforelinked thread.)

[QUOTE=wblipp;269854][B][SIZE="3"]BAD CHOICE. [/SIZE][/B]

This is difficulty 258 digits, MUCH MUCH harder than the 178 digits example I gave.

It looks like the factordb's polynomial finder needs to learn some tricks about removing algebraic factors.

William[/QUOTE]

[QUOTE=bsquared;269867]Also, something is wrong with the way it picks several of the parameters. Setting mfbr/a to more than twice lpbr/a doesn't make any sense. That will result in many more vain 2LP factorizations. Also, I've never seen r/alambda set so high. I'm less sure that this is bad, but it deviates from the status quo by a couple tenths. Extrapolating from the end of a lookup table, maybe?[/QUOTE]