I found that it does work in 1.08 with one small bug - sometimes two sequence entries end up on the same line. This means when using -s to upload it, the second one on the line is skipped causing a break in the sequence. It is probably a simple matter of adding a return in the right place.

---------
I thought I would mention an issue that I don't think requires fixing, but you might want to know about. If you run the same sequence at the same time you get duplicate entries (Yafu also crashes constantly which is actually useful as you know something is wrong). I suppose you could lock the elf file for write so it can still be read, but another aliqueit wouldn't be able to also write to it, but I would consider that low priority compared to everything else.

[QUOTE=Greebley;179146]I found that it does work in 1.08 with one small bug - sometimes two sequence entries end up on the same line.[/quote]

My guess is that this happens if you manually create a .elf and omit the linefeed on the last line. Do you know if that's the case or do you have another situation?

[QUOTE=Greebley;179146]I thought I would mention an issue that I don't think requires fixing, but you might want to know about. If you run the same sequence at the same time you get duplicate entries (Yafu also crashes constantly which is actually useful as you know something is wrong). I suppose you could lock the elf file for write so it can still be read, but another aliqueit wouldn't be able to also write to it, but I would consider that low priority compared to everything else.[/QUOTE]

Yeah, locking files seems like more trouble than it's worth.

[quote=mklasson;179149]My guess is that this happens if you manually create a .elf and omit the linefeed on the last line. Do you know if that's the case or do you have another situation?[/quote]

It seems to have a return. Also it is the partial line that ends up on the line before it rather than being a problem after the partial line.

I attached a fast example file. I had to change the extension from elf to txt since elf is not a valid extension (could we get it added?) Just rename it to alq_803236.elf and run aliqueit on that number and abort it after it finishes some lines (very fast so instantly). look at line 13:

I just noticed something else. In emacs the lines after 13 have a ^M so the issue might be unix style vs windows style carriage return? Can you run aliqueit on windows to try this?

Line 13 as it appears for me:
13. 744218928 = 2^4 * 3^4 * 17^2 * 1987 14 . 1545076388 = 2^2 * 13697 * 28201


[quote]Yeah, locking files seems like more trouble than it's worth.[/quote]
Agreed.

[QUOTE=Greebley;179154]I just noticed something else. In emacs the lines after 13 have a ^M so the issue might be unix style vs windows style carriage return? Can you run aliqueit on windows to try this?[/quote]

Indeed. It works ok if I change the LF on line 13 to CRLF. I can understand this on windows, but it seems odd that it fails on your linux(?) system. I get the file pos after reading the penultimate line, chop the file at that position and then start appending lines from the partial line. Somehow that LF before the partial line gets lost... Curious that your linux binary also uses CRLF for linefeeds.

No I am windows.

[QUOTE=Greebley;179171]No I am windows.[/QUOTE]

Oh, well, ok then. :smile: I assumed you were running linux when you asked me to try running under windows. Anyway, I'll make some room and put it on the list.

Ya, I wasn't very clear. I meant to say that it might only happen on windows systems so testing unix only wouldn't show the error that I was trying to show.

[quote=10metreh;176575]You'll need about 7M relations, give or take a few hundred thousand. The problem is that the "x" in "need x to proceed" is only based on the values of lpbr and lpba, and as factMsieve.pl is designed for SNFS as well (which needs less relations for the same lpbr and lpba), the formula is adjusted for that. Hacking factMsieve.pl is something we all do.[/quote]

I was thinking of doing the hack so I don't waste time looking for a solution when there isn't enough relations, but I also don't want to waste time looking for too many relations. I think I found the right line:

$MINRELS=int(0.2*1.442695*( (2**$LPBA)/$LPBA + (2**$LPBR)/$LPBR));

Not sure what the best thing to change it to is. Maybe 0.5 instead of 0.2?

[QUOTE=Greebley;179615]Maybe 0.5 instead of 0.2?[/QUOTE]

0.7 is a value that I've used with some success.

IIRC 0.7 does to much sieving on smaller numbers.

0.5 is what I'm using most of the time (although these days I use the minrels file).

I am using 0.5 and (as mentioned) that seems the better value. In at least 2 cases, there were enough relations on the first attempt. At 0.6 or 0.7 I would have gone too long. It does seem big numbers like the 124 digit attempt don't have enough at 0.5, but it figures that out pretty fast compared to generating new ones so aiming low seems better for generic aliqueit runs at least.

Also is there a maximum size for ecm curves done by aliqueit.exe? Is there ever an number that I would want to manually run more ecm at higher levels than aliqueit does? Not that I think I will be running much higher than the 124. That took a good while to complete. I am guessing a c130 would be measured in weeks?