@Mr. Odd: Your ecm binary should be located at:
[code]
/usr/bin/ecm
[/code] on your Ubuntu 11.10 system, but since it's installed, you might be able to just use:
[code]
ecm_path=ecm
[/code]PS. To check on the location of specific Ubuntu programs (like gmp-ecm), you can do the following:
[code]
1. Open System>Administration>Synaptic Package Manager
2. Enter the filename in the Quick Search box
3. Wait for the files to populate the package window
4. Highlight the filename
5. In the main menu choose Package>Properties
6. In the new window choose the Installed Files tab
[/code]This should give you a full list of associated files, with their complete paths.

Thanks, gentlemen, that did the trick! Now I can use 1.29.2 with the parallel ECM. And I do enjoy using all 6 cores. :smile:

I'm still working on setting up MSIEVE and GGNFS to take advantage of the GPU.

[QUOTE=EdH;281568]PS. To check on the location of specific Ubuntu programs (like gmp-ecm), you can do the following:
[code]
1. Open System>Administration>Synaptic Package Manager
2. Enter the filename in the Quick Search box
3. Wait for the files to populate the package window
4. Highlight the filename
5. In the main menu choose Package>Properties
6. In the new window choose the Installed Files tab
[/code]This should give you a full list of associated files, with their complete paths.[/QUOTE]

"which ecm" might also do the same thing.

[QUOTE=Mr. P-1;281649]"which ecm" might also do the same thing.[/QUOTE]
Indeed, it does!

Thank you.

This is a very minor issue and I don't think it actually affects anything, but during NFS poly selection, the nfs.dat.p file contains lines "time: xxx" which seem to be added at the end of a range of leading coefficients:
[code]...
# norm 1.035919e-013 alpha -4.635570 e 1.235e-008 rroots 2
skew: 997346.38
c0: -310291006502716213658976858
c1: 964696271120154400006
c2: -2945701464261145
c3: -8642801400
c4: 2484
Y0: -1388565366876329213081639
Y1: 103985052218425
[color=red]time: 764[/color]
# norm 4.806800e-014 alpha -4.984506 e 8.385e-009 rroots 2
skew: 6143657.62
c0: -703709386826779522181914700400
c1: 137657799974944430622260
c2: -31622949323424031
c3: 5718337874
c4: 2040
Y0: -1458441776080115379372499
Y1: 140477185192253
...[/code]

In the event that the best poly is the last found in its coefficient range, the "time" line will end up in the nfs.job file and the siever prints [code]Warning: Ignoring input line:
time: 764[/code]

As far as I can tell, the sieving continues as normal, so this isn't very important to fix.

I wondered when someone would notice that :smile:.

I wanted a mechanism to resume polynomial selection and have it "remember" how much time has been spent thus far. Hence the "time:" messages in the .p file. Before I went to some length to fix my .job file creation routine, I thought I'd see if ggnfs would be smart enough to skip lines it didn't understand and sure enough it was. So I didn't bother removing the time: lines before writing the .job file. Every once in a while they will sneak in, but aside from some screen spam they are harmless.

Having a small problem with poly selection phase. I don't think it can be solved, but I just want to tell others to avoid it.

I used to use the "pause/break" button to temporary stop a cmd-prompt window and release the involved cores. Not so many know that in windows you can use the "pause/break" key to "freeze" a DOS task (command prompt) and later on, use "enter" to resume it. This is very nice, because you do not need to close the window, just freeze it, then minimize it, do your daily task that needs the cores, then go back to your frozen DOS stuff and resume it. When it's frozen, it will release all the CPU resources (but not the memory) so you can use them for other purposes. Theoretically, you can have 100 yafu/aliqueit all open in the same time, but all frozen, and you can activate only the one you like to work with, or two, or more, depending on how many cores you have free and want to give them to work with.

Now, this works fine, except when the nfs does poly selection. Poly selection is time-limited, and I believe it is using the system timer. So, it reads the system timer when it starts, and it reads it again after new polys are found. If the time is out, it will stop poly selection, if not, and there is still enough time left, it will look for better polys.

But when you freeze the window, the time is still running in background. So, if your timeout is 600 seconds, but you freeze the window just after poly selection starts, and unfreeze it after 10 minutes, he reads the new time, say the poly selection "exceeded the allocated time" and exit with a bad poly, or with no poly at all.

Unfortunately there is no work around this except "don't use the pause button during poly selection". As the task freezes, there is no way for itself to know it (to save the time, or something), it is just frozen. When it is unfrozen, it will continue from where it stopped, without knowing, like a jump in the future. The best solution would be for the task itself to read the frozen time every time when it computes the timeouts, or to "count" effectively how much time it spent looking for polys, but both these solutions are very difficult to implement, first one would involve specific "command.com" tricks, therefore being not portable at all, and the second one would involve implementing its own clock in yafu, without using the system clock.

But just to let you know, if you want to end up with a good poly, then do not use the pause button during poly selection phase.

We've never been able to reach agreement on how to time-limit a polynomial selection task, which has no real fixed boundary of work to do. Measuring CPU time instead of wallclock time is easy (we have code that does it), but any proposed solution needs to be able to

- suspend the counting when the machine goes to sleep
- give the right numbers when running multithreaded
- give the right numbers when the CPU throttles
- give the right numbers at idle priority
- let LaurV freeze his command prompt :)

[QUOTE=jasonp;281967]We've never been able to reach agreement on how to time-limit a polynomial selection task, which has no real fixed boundary of work to do. Measuring CPU time instead of wallclock time is easy[/QUOTE]

I don't know the code, so I don't know how easy it'll be to implement -- but, the correct solution is to use a unit of work, instead of a unit of time (as proxy). Right now, whether it is wall clock time or CPU time, a faster CPU does more work than a slower CPU, which is not optimal. It should be a unit of measure that will do the same(ish) amount of work regardless of the CPU used.

Number of coefficients searched is a good candidate. The program already does this for the leading coefficient, but with time limit per coefficient. Can we somehow extend it to all the coefficients -- such that a fixed bound of 2nd/3rd coefficients per leading coefficient is searched?

I would like to know the meaning of this, explained like for a guy who has no idea how nfs works. In which situation could appear? Is it normal, or my computer is going nuts sometimes?

[CODE]
Tue Dec 20 12:30:41 2011 multiply complete, coefficients have about 30.43 million bits
Tue Dec 20 12:30:42 2011 initial square root is modulo 548240387
Tue Dec 20 12:36:07 2011 Newton iteration failed to converge
Tue Dec 20 12:36:07 2011 algebraic square root failed
[/CODE]edit: I got it at the 6th dependency, after three times "gcd is N, no factor" and two times "gcd is 1, no factor". The 7th dependence found a factor. Never saw it till now. Still curious.

Why is Yafu calling M127 composite?
 

Please fix this bug:

[CODE]>> isprime(2^127-1)
Found expression: 2^127-1
not prime
ans = 0[/CODE]

Yafu should recognize this as prime almost instantly. Why does it say it's composite? All the other Mersenne primes less than 10[SUP]1000[/SUP] show up as PRP (Which is normal for any prime greater than 10000).

I did quick PRP checks on other numbers just to check and it seems to be limited to M127:

[CODE]
>> isprime(2^127-1)
Found expression: 2^127-1
not prime <-- Should say "probably prime"
ans = 0

>> isprime(8675309)
Found expression: 8675309
probably prime
ans = 1
>> isprime(2^521-1)
Found expression: 2^521-1
probably prime
ans = 1

>> isprime(2^107-1)
Found expression: 2^107-1
probably prime
ans = 1

>> isprime(2^607-1)
Found expression: 2^607-1
probably prime
ans = 1

>> isprime(2^1279-1)
Found expression: 2^1279-1
probably prime
ans = 1

>> isprime(2^2203-1)
Found expression: 2^2203-1
probably prime
ans = 1

>> isprime(2^2281-1)
Found expression: 2^2281-1
probably prime
ans = 1

>> isprime(2^3217-1)
Found expression: 2^3217-1
probably prime
ans = 1[/CODE]

I even tried repeatedly testing it in case it was a temporary error and it still gets it wrong. Even the LLT is wrong:

[CODE]
PRP test:
>> isprime(2^127-1)
Found expression: 2^127-1
not prime
ans = 0

>> isprime(2^127-1)
Found expression: 2^127-1
not prime
ans = 0

>> isprime(2^127-1)
Found expression: 2^127-1
not prime
ans = 0

>> llt(2^127-1)
Found expression: 2^127-1
composite.
ans = 170141183460469231731687303715884105727
[/CODE]
Why is Yafu calling a prime that has been known since the 19th century composite? Please fix that!