[QUOTE=Wick;351340]I have something weird. I've used Yafu a lot, but never seen this before (or never noticed it).


I run yafu on 240765853219392558438410640216030738239500175822788425739227496334412241225100880531810717709711

It first finds PRP23 64111090342285968711967 with ECM and then switches to SIQS and finds a PRP25 and a PRP48. The PRP48 is fine, but the PRP25 is displayed as 64111090342285968711967 (the PRP found in ECM.

Here is the output:

[CODE]
08/29/13 18:42:21 v1.34.1 @ CIPJLT106,
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, ****************************
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, Starting factorization of 240765853219392558438410640216030738239500175822788425739227496334412241225100880531810717709711
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, using pretesting plan: normal
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, using tune info for qs/gnfs crossover
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, ****************************
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, rho: x^2 + 3, starting 1000 iterations on C96
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, rho: x^2 + 2, starting 1000 iterations on C96
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, rho: x^2 + 1, starting 1000 iterations on C96
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, pm1: starting B1 = 150K, B2 = gmp-ecm default on C96
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, current ECM pretesting depth: 0.00
08/29/13 18:42:21 v1.34.1 @ CIPJLT106, scheduled 30 curves at B1=2000 toward target pretesting depth of 29.54
08/29/13 18:42:22 v1.34.1 @ CIPJLT106, Finished 30 curves using Lenstra ECM method on C96 input, B1=2K, B2=gmp-ecm default
08/29/13 18:42:22 v1.34.1 @ CIPJLT106, current ECM pretesting depth: 15.18
08/29/13 18:42:22 v1.34.1 @ CIPJLT106, scheduled 74 curves at B1=11000 toward target pretesting depth of 29.54
08/29/13 18:42:26 v1.34.1 @ CIPJLT106, Finished 74 curves using Lenstra ECM method on C96 input, B1=11K, B2=gmp-ecm default
08/29/13 18:42:26 v1.34.1 @ CIPJLT106, current ECM pretesting depth: 20.24
08/29/13 18:42:26 v1.34.1 @ CIPJLT106, scheduled 214 curves at B1=50000 toward target pretesting depth of 29.54
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, prp23 = 64111090342285968711967 (curve 53 stg2 B1=50000 sigma=952853473 thread=0)
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, Finished 106 curves using Lenstra ECM method on C96 input, B1=50K, B2=gmp-ecm default
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, final ECM pretested depth: 22.72
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, scheduler: switching to sieve method
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, starting SIQS on c73: 3755447800590435602734059179926112323116714107864969196389774505840684433
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, random seeds: 33691659, 3306147874
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, ==== sieve params ====
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, n = 74 digits, 245 bits
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, factor base: 21040 primes (max prime = 505111)
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, single large prime cutoff: 37883325 (75 * pmax)
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, allocating 6 large prime slices of factor base
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, buckets hold 2048 elements
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, using 32k sieve core
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, sieve interval: 8 blocks of size 32768
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, polynomial A has ~ 9 factors
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, using multiplier of 13
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, using SPV correction of 21 bits, starting at offset 29
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, using SSE2 for trial division and x64 sieve scanning
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, using SSE4.1 enabled 32k sieve core
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, using SSE2 for resieving 13-16 bit primes
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, trial factoring cutoff at 87 bits
08/29/13 18:42:56 v1.34.1 @ CIPJLT106, ==== sieving started ( 2 threads) ====
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, trial division touched 1262737 sieve locations out of 20308819968
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, 21246 relations found: 10923 full + 10323 from 104208 partial, using 38736 polys (303 A polys)
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, on average, sieving found 2.97 rels/poly and 3227.01 rels/sec
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, trial division touched 1262737 sieve locations out of 20308819968
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, ==== post processing stage (msieve-1.38) ====
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, begin with 115131 relations
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, reduce to 30230 relations in 2 passes
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, recovered 30230 relations
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, recovered 21009 polynomials
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, freed 8 duplicate relations
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, attempting to build 21238 cycles
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, found 21238 cycles in 1 passes
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, distribution of cycle lengths:
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, length 1 : 10922
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, length 2 : 10316
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, largest cycle: 2 relations
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, matrix is 21040 x 21238 (2.9 MB) with weight 584858 (27.54/col)
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, sparse part has weight 584858 (27.54/col)
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, filtering completed in 3 passes
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, matrix is 15929 x 15993 (2.3 MB) with weight 479973 (30.01/col)
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, sparse part has weight 479973 (30.01/col)
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, saving the first 48 matrix rows for later
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, matrix is 15881 x 15993 (2.0 MB) with weight 391033 (24.45/col)
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, sparse part has weight 354045 (22.14/col)
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, matrix includes 64 packed rows
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, commencing Lanczos iteration
08/29/13 18:43:32 v1.34.1 @ CIPJLT106, memory use: 2.6 MB
08/29/13 18:43:35 v1.34.1 @ CIPJLT106, lanczos halted after 253 iterations (dim = 15881)
08/29/13 18:43:35 v1.34.1 @ CIPJLT106, recovered 18 nontrivial dependencies
08/29/13 18:43:35 v1.34.1 @ CIPJLT106, prp25 = 64111090342285968711967
08/29/13 18:43:35 v1.34.1 @ CIPJLT106, prp48 = 750798755893184797203638345990912940716502906301
08/29/13 18:43:35 v1.34.1 @ CIPJLT106, Lanczos elapsed time = 2.5270 seconds.
08/29/13 18:43:35 v1.34.1 @ CIPJLT106, Sqrt elapsed time = 0.0470 seconds.
08/29/13 18:43:35 v1.34.1 @ CIPJLT106, SIQS elapsed time = 38.2513 seconds.
08/29/13 18:43:35 v1.34.1 @ CIPJLT106,
[/CODE][/QUOTE]

Weird - I've never noticed anything like this before either. I tried it out and it worked fine for me, but I suppose there could be some intermittent bug. Do you remember if the screen output display the 23 digit factor twice or did it display unique factors?

[QUOTE=BudgieJane;352519]
It would seem that something is not right.[/QUOTE]

Other than the stalling (known bug that I haven't fixed yet) it all looks normal to me. Your runs in the two different directories are different simply by finding the two different p17's before running siqs. And your second run in the second directory skipped all of the pretesting entirely because it saw a siqs savefile that was valid for the input number. Or is it something else that I'm missing?

[QUOTE=bsquared;352522]Other than the stalling (known bug that I haven't fixed yet) it all looks normal to me. Your runs in the two different directories are different simply by finding the two different p17's before running siqs. And your second run in the second directory skipped all of the pretesting entirely because it saw a siqs savefile that was valid for the input number. Or is it something else that I'm missing?[/QUOTE]

I provided all the data I saw in case it helped determine what is going on. I don't think that there is anything else.

You say that stalling is a known bug and so I think I should wait until it is fixed before looking at this again. For the moment I shall revert to version 1.33.

Thank you for your reply.

[QUOTE=bsquared;352520]Weird - I've never noticed anything like this before either. I tried it out and it worked fine for me, but I suppose there could be some intermittent bug. Do you remember if the screen output display the 23 digit factor twice or did it display unique factors?[/QUOTE]

The number was part of a larger job, so I didn't see the screen output. After I saw the results in the log I tried to reproduce it and run the number twice more, but got correct results. Since I never seen this before I decided to post it, but it might just be one of those one time things that is never going to be found again. The only reason I noticed this one is that I copied the first factor of the C73 to factordb and it told me it didn't divide.

Thanks for looking in to it. If it happens again I will post it again.

[QUOTE=BudgieJane;352523]I provided all the data I saw in case it helped determine what is going on. I don't think that there is anything else.

You say that stalling is a known bug and so I think I should wait until it is fixed before looking at this again. For the moment I shall revert to version 1.33.

Thank you for your reply.[/QUOTE]

I believe this bug is now fixed (SVN 320). It impacted only the sse2 code branch; the sse41 code branch was correct and worked fine, which is maybe why I had difficulty reproducing it at first. Dana's fix from [URL="http://www.mersenneforum.org/showpost.php?p=344261&postcount=114"]here [/URL]was correct (and is what the sse41 branch already did).

This fix applies also to the problem originally reported by EdH [URL="http://www.mersenneforum.org/showpost.php?p=339976&postcount=103"]here[/URL].

While playing about during an idle moment I entered factor(2^66725+33) and got an immediate crash (windows reported "Yafu has stopped working") at the end of the trial division stage.

This is with windows 7, Yafu 1.34.5, 64 or 32 bit versions.

Yafu 1.33 works at least to the ecm stage (where I aborted to return to some more serious work).

[QUOTE=Antonio;355696]While playing about during an idle moment I entered factor(2^66725+33) and got an immediate crash (windows reported "Yafu has stopped working") at the end of the trial division stage.

This is with windows 7, Yafu 1.34.5, 64 or 32 bit versions.

Yafu 1.33 works at least to the ecm stage (where I aborted to return to some more serious work).[/QUOTE]

This is already fixed (SVN 318), but not yet released. See posts 212 - 217 in this thread. It will be in 1.35.

[QUOTE=bsquared;355700]This is already fixed (SVN 318), but not yet released. See posts 212 - 217 in this thread. It will be in 1.35.[/QUOTE]

Sorry, I seem to have missed that whole page when scanning through to see if it had already been reported. :blush:

[QUOTE=Antonio;355703]Sorry, I seem to have missed that whole page when scanning through to see if it had already been reported. :blush:[/QUOTE]

No problem, I'd rather have stuff reported twice than not at all.

No ECM multithreading
 

I'm trying to run ecm on a 273 digit number ([url]http://factordb.com/index.php?id=1100000000031569499[/url]), but whether I use ecm() or factor(), it won't multithread. Running smaller composites, Yafu has no issue, but with this one, I can't get it to work.

The command is:

[CODE]../yafu-x64.exe "factor(@)" -v -p -batchfile number.txt -threads 8[/CODE]

Do you have an "ecm_path" statement in a yafu.ini file? It will only run multi-threaded using an external executable. It will also only run multithreaded at B1=50k or above. If you know that both of those things are correct in your run and it still doesn't work, does it print any kind of error message?