fact.txt | factexcl.txt | factrange.txt

[Death]

After finishing some range, I can submit each of this files to sob.com/sieve and recieve some "xx new factors, xx added to database" response.

Which file is needed for submission? And what each file mean?

[ceselb]

fact.txt is the stuff to send, the others are just duplicates and out of range factors.

If you make a shortcut and edit it to proth_sieve.exe -d -w , it won't print or save them.

[hc_grove]

But if we don't find the remaining 11 primes for n<20M, we might want to sieve that range too, and then most of the factors in factrange.txt will be usable, so if you have the disc space I would save those.

[ceselb]

If you think that you'll remeber them in 3 years, keep them. I won't bother myself, we'll have to sieve everything again anyway so it won't help much.

[Death]

got it.

well, I'll submit all of them anyway. factexcl.txt sometimes gives me new factors...

PS Today I found two very close factors.

171164922447721 | 33661*2^4735392+1
171169201595629 | 28433*2^3491665+1

Who can give pair factors that is more close to each one?

[Mystwalker]

Smallest gap between factors: 2 (1347400799 - 1347400801)

:D

Just look at the gap pages (http://www.aooq73.dsl.pipex.com/gaps/Gaps_n3_20_p01u.htm). There is the smallest gap between factors for each gap range.

[Death]

Non reserved ranges
FactorsU FactorsD FactorsE Score

sub-total 36 19 692 16836.278


Other factors can also give some scores =))

[Death]

Factors
171260911427897|55459*2^23674246+1,

Verification Results


Factor table setup returned 1
Test table setup returned 1

0 of 1 verified in 0.03 secs.
0 of the results were new results and saved to the database.

[Mystwalker]

The factor submission page doesn't accept n > 20M.

[Death]

where can I submit such factors?

171260911427897 | 55459*2^23674246+1
171264165238339 | 21181*2^26561228+1
171267127994437 | 67607*2^21442099+1

[hc_grove]

Originally posted by Death
where can I submit such factors?

171260911427897 | 55459*2^23674246+1
171264165238339 | 21181*2^26561228+1
171267127994437 | 67607*2^21442099+1

Nowhere! They won't be of any use to the project for several years, and therefore they won't waste the discspace it would take to store them. As the ranges we sieve now will have to be redone anyway, there's almost no (possibly none at all, I don't know the client well enough to tell) extra work involved in rediscovering these factors again. Of course you could also save them, and hope that you'll be able to find and submit them when sieving above 20M starts. (BTW: If you had read the thread you would have known this as ceselb and I discussed this early in the thread).

[ceselb]

You can't submit them now. If you're prepared to hold on to them 2-3 years (or more), you could submit them when we begin sieving 20-?40M sometime in the distant future.
But there is no real gain in holding on to them (unless you're a real stats freak or something.

[ceselb]

Originally posted by Death
got it.

well, I'll submit all of them anyway. factexcl.txt sometimes gives me new factors...

It might accept them, but you get NO POINTS for them at all. Please don't submit them, they just sit and take up space on the server.

[Death]

Originally posted by ceselb
It might accept them, but you get NO POINTS for them at all. Please don't submit them, they just sit and take up space on the server.

oops. no points at all? suxx. i believe that i have some point for them =(((
but if/when we start to sieve >20M they can already be at server...
why are you discard them if they can be used at future?

and there's not so much space for few digits...

[MJX]

Please don't submit them, they just sit and take up space on the server.

as the density of the factors decrease when the sieving progresses, wouldn't it be interesting to post duplicate factors to get a reliable second hand "gap analysis", to see, for example, if a range is complete?

I personally find interesting to see whose composites are "smooth" ie. have many small factors and i usually like to submit my duplicates. After all, the SETI database permits to study the hydrogen gas in our galaxy as a corollary of the ET search...200T sieving isn't so common so why not study the factors of the proth numbers in the sob project???..

[kugano]

So I'm not sure I completely understand what you're suggesting. We should store *duplicate* factors? In other words keep track of the same factor for the same k/n pair but 'discovered' by two different users? What does that accomplish, and how would it help a gap analysis? This is genuine curiosity, not to be confused with resistance to the idea; I haven't had much to do with the sieving and factoring sub-projects so I'm sure I have a lot to learn =)

[MikeH]

We should store *duplicate* factors? In other words keep track of the same factor for the same k/n pair but 'discovered' by two different users? Dave, in sieving terms a duplicate is where a new factor is found for a k/n pair where a factor was already known. With the new sob.dat file, duplicates are not generated in the normal factor file very often, but they are a fact of life.

In terms of two people finding the same factor, with the sieve co-ordination, in theory this shouldn't happen. The only time this happens is where sieving crosses over factors that were found with P-1.

To a point I do agree with MJX, it's always useful saving data (provided you have the storage space) because it may be useable in some way that you can't image right now.

[kugano]

I see. I actually didn't know we weren't storing those ... let's call them "secondary" factors ... already. I only have two concerns about doing so.

Firstly, there needs to be some minimum size below which factors aren't recorded -- we really don't want to pollute the database by recording, say, the factor "3" for all the different k/n pairs.

Secondly, as you said, finding secondary factors should be rare because a k/n pair for which a factor has been found should be eliminated from the search within some reasonable amount of time. So how useful is the secondary factor data going to be, realistically, since even if we record known secondary factors, we also know that some large majority of the time they are never even found? I'm worried that any analysis that comes from it, however cool, would be based on incomplete and maybe misleading data.

[kugano]

I wasn't very clear in that last message. I'm not opposed at all to storing secondary factors, as long as they exceed a certain size threshold, because I advocate maintaining as complete a database about the current state of the Sierpinski problem as possible. I'm just worried about any analysis that might be done using data that is "biased" so to speak by the fact that secondary factor discoveries are, for the most part, "accidents" and not an intentional goal of the sieve project.

[MJX]

Excuse me, but I thought that the factexcl.txt was containing all the duplicates - or secondary - factors found in the p range since the discrete log algorithm first found p than can divide some k/n's then find the k/n's that are effectively divided (and some "out of range" factors : factrange.txt) then verify with the sob.dat whose are new factors....

In http://groups.yahoo.com/group/primenumbers/message/14439 one can read : " A discrete log derives the value for n in the equation b^n = r mod p for fixed b, r,and p." and (msg 14410) : "On a related note, it is possible to significantly speed up the
Carol/Kynea sieve, but sievers would have to sieve larger ranges to
get benefit from it. The improvement would come from using a dicrete
log to find values of k such that (2^k +/- 1)^2 - 2 mod p = 0.
Calculating the discrete log becomes more efficient (compared to the
current algorithm) as the range of k is increased" **and that's why mklasson program is so fast compared to former programs**.

In fact, I think that the discrete log algorithm isn't really a sieve (with a bit array representing unfactored numbers, from the sob.dat file, divided by all prime p's)...

I may be wrong of course but I think that submitting the factexcl.txt file will maintain the database up to date with duplicates (of course for the sieved range). As I understand it, refreshing the dat file will only avoid declaring as new factors, factors of k/n pairs still factorized...

maybe can mklasson give me/us some explanations about that point?

[MJX]

Just an explanation about gap analysis : if I am right about factexcl.txt : at 200T, the average gap between primes will be something like 11G (read on a thread in this forum), so in a 100G range, you'll submit #9 factors and maybe 2 or maybe 15... The gap analysis -controlling the range is complete- will become harder on these common intervals. Another gap analysis based n duplicates (still over hundred/100G) should be much more accurate to see the holes in the sieve...

[mklasson]

Yes, unless explicitly disabled (-d switch) all factors that divide some k,n pair that's not in the .dat go to factexcl.txt or factrange.txt depending on whether n is within the n range (currently 1M-20M) or not.

[Death]

Knowledge is a power.
more information - more possibilities.