3+ table

[Batalov]

I can already see the day when 3+ table will catch up in shortness with 3-.
There will be only 5 holes left by early June.

[Raman]

Originally Posted by fivemack

Were you not deliberately to obfuscate the factors that you post, I would be significantly less vexed. In particular, a bug in our corporate NFS setup meant that downloading the .txt file crashed Safari and ate the state I'd been preparing for some time in the content-management system.

I would of course recommend my approach to posting factorisation reports ('it took S hours to sieve and L hours to do the linalg on a Y*Z matrix of weight W using $ncores cores of a $MHZ $COMPUTER').

Base 10 is being used since antiquity since it is the number of fingers to count. Would the base have been 10 if we had more or less fingers or no finger or toe systems at all, by human evolution? Why didn't our ancestors count 1024 with 10 fingers by using open or close finger abacus? Base 2, is being the most natural, why people make use of base 2 (and then that base 10) tables more often than those other tables? How do they use those tables for all that other mathematical works? What such works? Use of base 10 cause that multiples of 3, 9, 11, 2, 5, 4, 8 to have their own divisibility tests. Not any quite straightforward tests for that 7 at all. Base 16 is made by packing up 4 bits at a time, better referred to as a nibble. Thus, do you wish that I post all that future factors of me over here within that decimal format only, actually?

It is totally amusing if downloading a plain text file, and then subsequently opening that could cause any operating system to crash. Factoring an integer of such size is the most difficult part, converting any number between two bases, representing any random prime number of that form 1 (mod 4) into sum of two squares, calculating totient with known factors, modular exponentiation, GCD, modular inverse, modular square root, Chinese remainder theorem, etc. are all quite direct parts of calculation.

The sieving time for a special-q range of 1 million is always being quite fixed up. Over a single Core 2 Duo processor of 2.8 GHz or that compute cluster, in which each core is a Xeon processor of 2.4 GHz, there are 14 nodes, 8 cores per node that are being available always within that compute cluster, though I will often make use of half of that, of such resources only, on an average scale. With gnfs-lasieve4I14e siever, it takes upto 7 days for sieving up that special-q range of 1 million, while with that gnfs-lasieve4I15e siever, that range generally takes upto 13 days. For 3,575+ 3,580+ 6,355- 6,355+ 10,275+ 11,265- that I sieved a special-q range of from 30M upto 100M with that gnfs-lasieve4I15e siever, upon that rational side. For that 5,400+ 40M-120M just simply, for 2,935- 50M-150M, for 7,335- 60M-170M, for 6,365- 60M-180M, for 3,581+ 40M-120M over the algebraic side, by using that gnfs-lasieve4I14e siever just simply, indeed really.

For that future projects, I estimate about, that for 12,265+ from 80M upto 200M, that for 2,955+ 7,340+ 5,410+ rather 100M-250M? How much more of extra sieving, that will be needed up for that 5,415+? Any ideas about that?

[Raman]

Originally Posted by Batalov

I can already see the day when 3+ table will catch up in shortness with 3-.
There will be only 5 holes left by early June.

What about that for that 6- tables, with 6,365- 6,385- that being killed up? Only 5 holes, then actually, plus that 6,349- 6,377- is always being quite relatively easier when being compared up with those other prime exponents within that same tables, of course, forever.

No holes at all, for that 3LM, 6LM, 12LM tables, that exponents always being divisible up by 3, that they are always relatively being easier to be cleared up, to be clean enough always.

[Batalov]

Originally Posted by Raman

Thus, do you wish that I post all that future factors of me over here within that decimal format only, actually?

Now, why would you limit yourself to such an extravagant choice? Who uses base 10 these days, anyway?
It was only four posts that were unexplicably negative about your innovation. On the bright side, think of the millions of people who silently supported your point of view.

I am strongly inclined to spell out the next factor in words. Sorry, or is that spell up?

[Batalov]

Originally Posted by Raman

No holes at all, for that 3LM, 6LM, 12LM tables, that exponents always being divisible up by 3, that they are always relatively being easier to be cleared up, to be clean enough always.

It had nothing to do with divisibilty by 3, seriously. Think about the real reason.

[Batalov]

We have a fairly interesting factorization for 3,568+ (SNFS diff.272):

3^568+1 = p136 * c136, where
p136=2965649098765320881163776420790238683223089541617264964063715812862258678485005431045156765260965962775673575728582254376394260183250529
c136=3409988525310796058922055845863689147574033545222342506996063508207928452184712368600919724443591224654704573451266679363765861109884578


c136= p68 * c68, where
p68= 56525996137747987572429427088943164513476938620601034480823743972321
c68= 60326022685226242378522896162491705896592748167611629523524434606818

c68= (3^8+1) * p64, where
p64=9193237227251789451161672685536681788569452631455597306236579489

The quasi-perfect dichotomy strikes me as very odd, but it doesn't look like an algebraic (except the algebraic composite 3^8+1, of course).
This is the actual order in which I've received the factors from the consecutive sqrt routines, p64 being a remainder! (Because I feared many factors, I ran strictly one-by-one sqrt's by msieve; each took only 50 minutes and I was able them simultaneously.)

Technical details for the factorization will follow.

For Batalov+Dodson, --Serge

[bdodson]

Originally Posted by Batalov

We have a fairly interesting factorization for 3,568+ (SNFS diff.272):

3^568+1 = p136 * c136, where
p136=2965649098765320881163776420790238683223089541617264964063715812862258678485005431045156765260965962775673575728582254376394260183250529
c136=3409988525310796058922055845863689147574033545222342506996063508207928452184712368600919724443591224654704573451266679363765861109884578


c136= p68 * c68, where
p68= 56525996137747987572429427088943164513476938620601034480823743972321
c68= 60326022685226242378522896162491705896592748167611629523524434606818

c68= (3^8+1) * p64, where
p64=9193237227251789451161672685536681788569452631455597306236579489

The quasi-perfect dichotomy strikes me as very odd, but it doesn't look like an algebraic (except the algebraic composite 3^8+1, of course).
This is the actual order in which I've received the factors from the consecutive sqrt routines, p64 being a remainder! ...

For Batalov+Dodson, --Serge

A clarification (before we get the ecm miss posts), this may be the order
in which the prime factors arrived; but the composites Serge is reporting
were not in the msieve output (I hope!). So (according to emails) the
first sqrt gave c268 = c132*p136, and then subsequent sqrt(s) gave
c268 = p68*c_something_1 and c268 = p64*c_something_2. The extra
3^8+1 has been added synthetically, after the fact. -bd

(I.e., you can mutter about the p64 or even the p68; but that 3^8+1
wasn't in the c268 we were factoring. So, those C136 and C68 are also
synthetic; the first sqrt gave c132*p136, not sure about the other two
sqrts, but there was no 3^8+1 in the msieve output ...)

(And also, the 3rd sqrt has p64 as cofactor, yes? The other factor
from the sqrt being p132*p68; with no c68 in the msieve output.
Someone's spending too much thought on Cunninghams; we just factored
the C268. Sorry for the co-author mutter.)

[Batalov]

The log with comments is attached: "3 filtering runs/3 matrix" comparison and other minutiae.

Bruce is correct: the c268 was from the very start (3^568+1)/(3^8+1) and
c268 = p64 . p68 . p136
p64 and p68 are not misses really (no Cell-ECM in base 3, or is there?); finding both of them would have been a miracle, ...finding just one would have been a farce.

The rest is simply a set of curios, a pun on "Aurifeuillian of the n-th kind": the values are close but not really close. Nothing to see there.

[bdodson]

Originally Posted by bdodson

A clarification ...
Someone's spending too much thought on Cunninghams; ...

Sam liked it; goes to show what I know. -bd

[frmky]

NFS@Home has finished 3,562+.

prp86 factor: 26199296583362121868114814478342229370563687963452355809509570295596751843331841869537
prp170 factor: 14113281051758972232868021764730987926513783537329498398393771546011860018376960097290152672454661953389252964726223471498533168262298795814515812559338238535647583298633

[bdodson]

Originally Posted by frmky

NFS@Home has finished 3,562+.

prp86 factor * prp170 factor

And reserved 3, 563+ c239 which will leave the 3+ table shorter
than the line on the "first five holes" page, updated yesterday. Actually,
the current set also includes 3,563- c199, which will drop that table to
length three. (At the moment, these are on Sam's "who's" list, but not
yet on the NFS@Home "Status".) The c199 has finished ecm pretesting,
while the c239 has another t55 left to go. A very nice pair of Cunningham
numbers; NFS@Home could use a few more dedicated contributors,
or even a few more with just a passing interest.

-Bruce