fewer factors with larger dat

[ShoeLace]

I may be mistaken, but i get the feeling that i am finding less unique/new factors using the 991-50M dat file. as compared to teh standard dat file.

i'm getting lots more excluded factors (which i understand)
but my fact.txt file is about 50% <20M and 50% > 20M

can some please tell me im imagining things, and that i've just got a range with less factors or something..!??!?!


thanks

Shoe Lace

[maddog1]

Well, factor density IS decreasing as p grows larger.
I don't know the maths behind this (I suck at maths...) but it's fairly obvious.
I very much doubt it has anything at all to do with the dat size.

On the other hand, checking your stats (http://www.aooq73.dsl.pipex.com/ui/7378.htm) and the relevant gaps analysis (http://www.aooq73.dsl.pipex.com/gaps/Gaps_n3_20_p05u.htm) I can see you are currently sieving 733000-735000 and that you have progressed up to about 733400 so far. In this range you have already 12 unique factors, which I think is MORE than expected.

As a comparison, I am doing 763000-764000 and have found so far 5 uniques up to 763350, using the 1-20m dat, so I think this make your useful output almost double mine (which I think is fairly normal, compared to the previous ranges I have completed) ;)
On the closest completed ranges of mine, I got 19 from 700700-702000 (fairly bad) and 21 from 731000-732000 (seems just about right)

Perhaps the rush of factors you got -all 12 up to 733274- and the subsequent drought (100+m without new ones) got you thinking something is wrong, but I have seen this in my ranges too.

So, it's either
a) you are imagining things, your range is so far pretty damn good
b) I should be the one complaining :D

Any other opinions on the subject more than welcome :)

[Mystwalker]

AFAI see it, n size is concerned, not p size...

In that case, it's even more "strange", as I'd think that there are less duplicates for n > 20M.

[vjs]

The 991<n<50M works just fine with the proth client and it will find all factors within the range it is checking. Sieveing the same range with two smaller dat sizes example (991<n<20M and 20M<n<50M later) will not find more or less factors than doing it once in the given n and p range.

We know this from our orginal analysis, when we were determining the best dat for the job, %eff, missed factors, etc.

We sieved one range several times with different dats, ranging from 0-100M in 5x20M dats to 10M dats and 63M (max dat size). All of the runs found the same factors and none of them were missed. What we didn't check for was the number of excluded it could be different. Either way it's not important what the client puts into factexcl.txt what's important is that it doesn't miss factors for k/n pairs in the dat.

Also the fact that we are finding missed factors in lower p ranges basically shows us that it is working and we are doing better with 991<n<50M than we were before. With older clients and smaller dats.

Shoelace,

You have to consider the p-levels, if your previous ranges were at lower p then the current range you will find less. Since the number of factors per sieved range decreases with increasing p.



As far a duplicates are concerned the proth client doesn't look for duplicates... actually it doesn't even know that it is a duplicate how can it? Duplicates are not contained anywhere in the dat or client.

[ShoeLace]

okay thanks everyoen for your feedback.

i'll decide im crazy and it just _feels_ slower.

as for the duplicates, i had assumed it decided it was a duplicate when the p value had subfactors. hence the "(z,mod x) duplicate" lines

[royanee]

Duplicate factors may also be a result of the way in which the proth sieve client works. It might look for factor cycles to see which number a value of p would divide, and if that k/n pair is not in the dat, then it knows that it is an excluded factor. This is the only way that I can think of for it to be able to determine such information seeing as it doesn't have a list of them, and doesn't connect to the server.