[QUOTE=BigBrother;194174]I frequently see a inconsistent digit count, like in this example:
[CODE]10/29/09 10:27:52 v1.12 @ LAPTOP,
Initializing with Tom's Fast Math (x86-32 asm)...
cached 78504 primes. pmax = 1000099
detected cpu 6, with L1 = 32768 bytes, L2 = 3145728 bytes


starting SIQS on [B][U]c81[/U][/B]: 244319173756229060069606235012489045211851322430046929300276036276182797256294079

==== sieve params ====
n = [B][U]82 digits[/U][/B], 270 bits[/CODE]
Very often the difference between these two is 1, sometimes it is 2. I never noticed this in previous versions of yafu.[/QUOTE]

In fact there is a speed up in quadratric sieve when you factorize k*n instead of n, for the above number k=5, listed as "using multiplier of 5" in yafu, and for that 5*n is really 82 digits and 270 bits.

For your second example k=59.

[QUOTE=R. Gerbicz;194180]In fact there is a speed up in quadratric sieve when you factorize k*n instead of n, for the above number k=5, listed as "using multiplier of 5" in yafu, and for that 5*n is really 82 digits and 270 bits.

For your second example k=59.[/QUOTE]

Ah now I see, thank you for the explanation!

[quote=BigBrother;194181]Ah now I see, thank you for the explanation![/quote]

Yes, as R. Gerbicz noted, the first size is reported for the input number, the second after it has been scaled by the multiplier. I guess I haven't paid much attention to this either but I think this behavior has been there for previous versions as well... not that it matters much :smile:.

I've finally re-gained access to my page! Lousy auto-migration of googlepages to sites.google broke something which took a web browser upgrade to fix.

So the win64 version of yafu-1.12 is now available, thanks to Jeff (provided over a month ago).

yafu 1.13 available
 

v. 1.13 Now available [url=sites.google.com/site/bbuhrow]here[/url]

New in Version 1.13
+ bugfixes
+ siqs speedups
+ squfof improvements
+ multi-threaded ECM.

I fixed the issues causing a slowdown in single threaded siqs that occurs in v1.12 vs. 1.10. Plus sped things up another small increment by getting rid of some overhead. This is now the fastest yafu to date (and hopefully I won't take any backward steps again), single or multi-threaded. ECM is now multi-threaded as well, so anyone running the general purpose factor() routine in multi-threaded mode should see some good throughput improvement.

- ben.

[QUOTE=bsquared;196906]v. 1.13 Now available [url=sites.google.com/site/bbuhrow]here[/url][/QUOTE]

Nice. I should be able to send you the Win64 binaries tonight after I put the kids to bed.

Jeff.

[QUOTE=Jeff Gilchrist;196908]Nice. I should be able to send you the Win64 binaries tonight after I put the kids to bed.

Jeff.[/QUOTE]

Great, thanks!

[QUOTE=bsquared;196906]v. 1.13 Now available [url=sites.google.com/site/bbuhrow]here[/url]

New in Version 1.13
+ bugfixes
+ siqs speedups
+ squfof improvements
+ multi-threaded ECM.

I fixed the issues causing a slowdown in single threaded siqs that occurs in v1.12 vs. 1.10. Plus sped things up another small increment by getting rid of some overhead. This is now the fastest yafu to date (and hopefully I won't take any backward steps again), single or multi-threaded. ECM is now multi-threaded as well, so anyone running the general purpose factor() routine in multi-threaded mode should see some good throughput improvement.

- ben.[/QUOTE]

On your page, "64 bit Windows users (coming soon)" appears to be linked to the ("coming soon") 32 bit Linux version.

[QUOTE=10metreh;196911]On your page, "64 bit Windows users (coming soon)" appears to be linked to the ("coming soon") 32 bit Linux version.[/QUOTE]

Thanks, fixed.

[quote=bsquared;196912]Thanks, fixed.[/quote]

Ben, you missed out a critical bit of the revised Windows timing code so the ECM time estimates on Windows are still seriously screwed up I'm afraid.

Brian

[QUOTE=Brian Gladman;196922]Ben, you missed out a critical bit of the revised Windows timing code so the ECM time estimates on Windows are still seriously screwed up I'm afraid.

Brian[/QUOTE]

You're right, I failed to get the latest in there :blush:

But I tested it on two different windows platforms and everything worked fine, single or multi-threaded. For example on a core2 with 3 threads:

[CODE]Processing expression: factor(rand(80))

***** cpu looks to be about 3028.228560 MHz

factoring 9797819404810769263653579038358070159754699618874081742171517090591157705353813472429

div: primes less than 10000
rho: x^2 + 1, doing 1000 iterations on C82
rho: x^2 + 3, doing 1000 iterations on C82
rho: x^2 + 2, doing 1000 iterations on C82
pp1: base 859203183, doing B1 = 20K, B2 = 1M on C82, processed < 1000003
pp1: base 607275111, doing B1 = 20K, B2 = 1M on C82, processed < 1000003
pp1: base 3351482247, doing B1 = 20K, B2 = 1M on C82, processed < 1000003
pm1: base 2397117891, doing B1 = 100K, B2 = 5M on C82, processed < 5000011
***** using 64bit windows core2 data for QS time estimation
***** qs time estimate = 205.084994 seconds
ecm: 3 curves on C82 input, at B1 = 2K, B2 = 200K
***** 15 digit level took 0.316767 seconds.
***** using 64bit windows core2 data for QS time estimation
***** qs time estimate = 18.506633 seconds
***** estimating 17 more curves can be run at 20 digit level
ecm: 17 curves on C70 input, at B1 = 11K, B2 = 1100K
***** 20 digit level took 2.849680 seconds.
***** using 64bit windows core2 data for QS time estimation
***** qs time estimate = 18.506633 seconds
***** estimating 2 more curves can be run at 25 digit level
ecm: 2 curves on C70 input, at B1 = 50K, B2 = 5M
***** 25 digit level took 3.153414 seconds.
***** using 64bit windows core2 data for QS time estimation
***** qs time estimate = 18.506633 seconds
***** estimating 0 more curves can be run at 30 digit level

starting SIQS on c70: 1613614204085568053637736215085340000483223603454440719731638328781401

==== sieve params ====
n = 70 digits, 230 bits
factor base: 11453 primes (max prime = 261619)
single large prime cutoff: 17005235 (65 * pmax)
allocating 7 large prime slices of factor base
buckets hold 1024 elements
sieve interval: 6 blocks of size 32768
polynomial A has ~ 8 factors
using multiplier of 1
using small prime variation correction of 18 bits
using SSE2 for trial division and x64 sieve scanning
trial factoring cutoff at 82 bits

==== sieving in progress ( 3 threads): 11517 relations needed ====
==== Press ctrl-c to abort and save state ====
9479 rels found: 4619 full + 4860 from 51774 partial, (3066.40 rels/sec)

trial division touched 756193 sieve locations out of 1761199128576
QS elapsed time = 21.0000 seconds.

==== post processing stage (msieve-1.38) ====
begin with 64584 relations
reduce to 17046 relations in 2 passes
attempting to read 17046 relations
recovered 17046 relations
recovered 14756 polynomials
attempting to build 11569 cycles
found 11569 cycles in 1 passes
distribution of cycle lengths:
length 1 : 5273
length 2 : 6296
largest cycle: 2 relations
matrix is 11453 x 11569 (1.4 MB) with weight 313167 (27.07/col)
sparse part has weight 313167 (27.07/col)
filtering completed in 3 passes
matrix is 10575 x 10639 (1.2 MB) with weight 284889 (26.78/col)
sparse part has weight 284889 (26.78/col)
saving the first 48 matrix rows for later
matrix is 10527 x 10639 (1.0 MB) with weight 230590 (21.67/col)
sparse part has weight 202306 (19.02/col)
matrix includes 64 packed rows
commencing Lanczos iteration
memory use: 1.4 MB
lanczos halted after 168 iterations (dim = 10527)
recovered 17 nontrivial dependencies
Lanczos elapsed time = 1.7660 seconds.
Sqrt elapsed time = 0.0940 seconds.
SIQS elapsed time = 22.8594 seconds.
ECM/SIQS ratio was = 0.275338

Total factoring time = 31.0781 seconds[/CODE]

Frequency looks right: it predicted 18.5 seconds and it took 22.8... close enough given the errors inherent to the extrapolation equations. The ECM elapsed times also are recorded correctly. So if it's broken it doesn't look *too* broken. Is it different with win64?