I've put up two more Lucas Aurifeuillian factors with 32/30 large primes (these ones are 3LP on the rational side because that seemed quicker from trial sieving)

[QUOTE=fivemack;503586]I've put up two more Lucas Aurifeuillian factors with 32/30 large primes (these ones are 3LP on the rational side because that seemed quicker from trial sieving)[/QUOTE]
I’ve got a pending C190 GNFS 32/32 3LP (a side) job which test sieves at reasonable speed but your 32/30 strategy intrigues me. Do you think there are any potential pitfalls? 
[QUOTE=swellman;503623]I’ve got a pending C190 GNFS 32/32 3LP (a side) job which test sieves at reasonable speed but your 32/30 strategy intrigues me. Do you think there are any potential pitfalls?[/QUOTE]
I would expect 32/30 to work poorly for GNFS, because part of the polynomial selection effort is to make the algebraic and rational sides of similar difficulty  I'm using it for SNFS where the algebraic side is fixed and always small, and the rational side defines the actual number you're factoring. I tried 32/29 for the L4245AB numbers, but the time per relation went up by 20% and I wasn't able to convince myself that the number of relations needed would go down by more than 10%. 
[QUOTE=fivemack;503650]I would expect 32/30 to work poorly for GNFS, because part of the polynomial selection effort is to make the algebraic and rational sides of similar difficulty  I'm using it for SNFS where the algebraic side is fixed and always small, and the rational side defines the actual number you're factoring.
I tried 32/29 for the L4245AB numbers, but the time per relation went up by 20% and I wasn't able to convince myself that the number of relations needed would go down by more than 10%.[/QUOTE] Thank you for your insights. I’ll leave the GNFS job as is but will explore 32/30 on some upcoming SNFS jobs. 
My electricity bills for the compute farm (order of £250 a month) are starting to look disproportionate to my lack of income, so I intend to turn off a few nodes in the New Year and will have less postprocessing available. I plan to keep the i9/7940X running linear algebra solidly, which ought to be a meaningful contribution.

Do what you have to do. Others will take up the slack. Or not. But do not worry  we all contribute as our resources allow.

Reserving C217_133_94 for postprocessing

1 Attachment(s)
L2268 cofactor is finished
[CODE]Thu Dec 27 13:55:24 2018 p115 factor: 4468728470697900840421834967730559072239351609830923968364687516254286475954809097190830791569015578978902211846881 Thu Dec 27 13:55:24 2018 p152 factor: 18296844178068673791615190258094855085834941817043952297534445967738800235208282862863613003855248613009139445140931940077191085694589632995284025835767[/CODE] [PASTEBIN]u0Cq6pvG[/PASTEBIN] 
I gave a quick test to L4245A (32/30, aim for 250M relations). (not reserving it, just testing)
Beware that duplication rate is much higher than for other sieving projects: currently from 263M raw rels, only 209M are unique. 
Reserving Fib(1983) cofactor.
Interesting fact: factoring Fib(1983) cofactor (which is [C]Fib(1983)/Fib(1983/3)[/C] ) is ...factoring [C]lucas(1322)1[/C] For odd n , [C]fibonacci(3*n) = fibonacci(n)*(lucas(2*n)1) = fibonacci(n)*(lucas(n)^2+1)[/C] For even n, [C]fibonacci(3*n) = fibonacci(n)*(lucas(2*n)+1) = fibonacci(n)*(lucas(n)^21) = ...[/C] (but for even n, it is obvious that this falls apart into fibonacci(3*n/2)*lucas(3*n/2) and so on, by chain) 
Fib(1983) has a very high duplication rate, so far.
We will probably need to extend the region... [C]Found 286915235 unique, 72560974 duplicate, and 3787 bad relations. Largest dimension used: 1034 of 1300 Average dimension used: 875.6 of 1300[/C] 
All times are UTC. The time now is 01:43. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2021, Jelsoft Enterprises Ltd.