That's a good idea. If you did that, you'd want to:Originally posted by mklasson
Let's say I tried to factor a k/n pair I was just assigned and actually found a factor. What would be a good thing to do next?
1) Submit the factor at http://www.seventeenorbust.com/sieve/
2) Expire the test at http://www.seventeenorbust.com/accou...sPending.mhtml
3) Clear your cache and retrieve a new # by modifying your username and saving settings ( to prompt the cache clear question). Click yes, then change your username back.
You'd want to do the first 2 steps in that order to avoid having the system reassign your test. You wouldn't have much time either. The server hands out the lowest number so if you just expired a test, it is mostly going to be the next in the queue. I'd guess that the average time from pressing expire to it being reassigned is 50 seconds.
-Louie
I'm a little un sure what P-1 factoring is but from watching this thread I've noticed that it appears it can save alot of work. What is the program that does this? Can it be incorporated with the prp client? How can I use it to help me? Just a few questions for all of us uninformed participants who can't figure out more than half of what is discussed in here.
Is there a plain text list of all the factors to be found somewhere?
I can't do much with the sob.dat file. I think there was a file like that distibuted with one of the earlier versions of sobsieve, but I deleted it months ago.
Ceselb,
What you want is the SoB.txt file included here
This will have all the n for each of the 12 k. They are "in the clear" unlike the sob.dat file that has only the delta to save space.
Joe O
This is clearly going to become very useful, so unless Louie gets there before me, I'll have a look at posting a daily updated version of this file (tomorrow).What you want is the SoB.txt file included here
I'd like to see how this pans out first, but if it does throw the stats out a long way, I have one easy method of sorting it. I could make it so that all factors with p significantly above the current sieveing range would score as if they were at the top of the current sieving range. Of course this means that anyone that has sieved high would see their score fall over night, but then it would slowly increase again. But I think this would be fair.One major concern about P-1 factoring:
- Mike H's sieve stats could be thrown off A LOT by P-1 factoring.:
If I had understood what does P-1 factoring do, I think it could save a lot of work if it is integrated into the SB client.
When someone starts working on a new k/n pair, the SB client executes the P-1 and if it finds a factor in 1 or 2 hours, there is no need to run a prp test that could take about 5 days.
What do you thing about this?
quote:
___________________________________________
What do you thing about this?
___________________________________________
I don't think that P-1 factoring is good at all.
- P-1 factoring uses an awful lot of memory
- It's hard to intelligently choose B1 and B2 on P-1 factoring,
and most users will not like the manual work
- Since the candidates have already been sieved to a pretty good
depth, there is a big chance that the remaining candidates
who are composite don't have a factor small enough to be
discovered with P-1 factoring
- Even for the candidates which have a factor small enough to be
discovered with P-1 factoring, the amount of time needed to
eliminate that number could have been used to eliminate 2
candidates by sieving
- The P-1 factoring software is not well optimized and has a lot
of bugs in it, and I think that it would be quite some time before
the software is fully tested.
The only project that does P-1 factoring is GIPMS, and they only
do that because they can't sieve.
MikeH,
AFAIK your sieve scoring is set to reflect the "avoided cost" of PRPing that n. If this is so, then it does not matter how we avoid PRPing that n. Sieving, P-1, P+1, ECM, etc. All of these have been used in the past. Look at the old thread(s). So there will now be more P-1 ing. So What! Big Deal!
A PRP avoided, is a PRP avoided.
Joe O
Hi,
I think, the p-1 factroing will mix up the stats quite a bit. The new factors are distributed between 1T and beyond 1E.
On the other hand, the update of the scoring algorithm as suggested by Mike, is not optimal either. I did quite a bit sieving (about 750G or so) for testing purposes at 281T and 1126T and will lose more than 7500 points on these factors.
I suggest changing the scoring algorithm in that way, that big factors are scoring, if the reserved or completed range of that user around that factor has that size that the expected number of factors in there is at least 0.5 or so. In that case these factors are fully scoring whose area is sieved by that user (that equals completed work).
i know it's difficult
biwema
Last edited by biwema; 06-16-2003 at 07:02 PM.
A quick explaination of P-1 factoring is presented @ http://www.mersenne.org/math.htmOriginally posted by Keroberts1
I'm a little un sure what P-1 factoring is but from watching this thread I've noticed that it appears it can save alot of work. What is the program that does this? Can it be incorporated with the prp client? How can I use it to help me? Just a few questions for all of us uninformed participants who can't figure out more than half of what is discussed in here.
Right now, our sieve is finding numbers pretty quickly, but the factor density is dropping fast. My computer may go 160,000p/s but our factor density is down to less than 1 factor / G (1,000,000,000p). Last I calculated, it was around 0.8. That means it takes an average of 2.2 hours to find a single factor. There's also about a 15% chance the factor is for an already factored number. Opps, closer to 2.6 hours now for each useful factor. This gets worse and worse each day we factor. When we hit 50T, factor density will fall to around 0.4 ==> 5 hours / factor. I don't suggest we stop any time soon, but the proverbial long hanging fruit is very much gone. Incidently, the thing that has really maintained the sieve speed has a lot to do with Jobling's Law(tm) which states that Paul Jobling will release a new version of SoBSieve that's 2x faster every 18 days.I've always hoped someone would do a study on the siever and graph speed increases. If no one does soon, I'll probably make my own soon.
P-1 factoring is a much more targeted approach to finding factors. It is also not dependent on the factor density like sieving. It's dependent on how "smooth" the factor -1 is. Not all the numbers will have a smooth factor, but those that do will give us VERY large factors rather quickly. That 1500 trillion sized factor I found won't be found by the regular sieve for a long long time. By the time regular sieving would have found it, the number would probably have been double checked and a factor would be of little use.
So that's the motivation and the explaintion.
As far as "what does it all mean for the project as a whole?" part, it's hard to say right now. GIMPS finds factors for about 3.2% of the numbers it tests by P-1 factoring (i think). It also takes them 2.2% of the time it would have taken to just test the numbers. Net gain of 1% in throughput. What should we expect? There is reason to believe it may be a little more but probably not a whole lot.
[FYI - The reason to believe goes something like:
GIMPS is able to trial factor numbers MUCH higher than us due to the special form of their factors. Something like 2^64. We're in 2^44 land. That difference is kinda huge. I'm still trying to decided if the difference all cancels out since they know that their exponent is a factor in P-1 factoring. It may completely cancel out or it may at least partially. I'll let you know if I figure that out.]
As for Moo, why you be hating on P-1 so much?
- It's hard to intelligently choose B1 and B2 on P-1 factoring,
and most users will not like the manual work
--> there's nothing saying users will have to. i'm working on making the program pick B1/B2 intelligently for you based on how likely is it will find factors. it may eventually be in the client so people can just check a box and do it if they want.
- Since the candidates have already been sieved to a pretty good
depth, there is a big chance that the remaining candidates
who are composite don't have a factor small enough to be
discovered with P-1 factoring
--> we just need one smooth factor that is larger than the current sieve depth. a lot of our numbers have these just waiting to be uncovered.
- Even for the candidates which have a factor small enough to be
discovered with P-1 factoring, the amount of time needed to
eliminate that number could have been used to eliminate 2
candidates by sieving
--> maybe for another month, but sieving is slowing down awfully fast. and those 2 theoretical factors you could have found sieving probably eliminated the need to do a test in range much higher than we're testing in. so those 2 factors will only truely be useful in a couple years. P-1 factoring can find factors for numbers that we're doing right now. even if you're pessimestic about it, at least half of the factors found sieving 3M-20M will not be needed for years and will not speed up how quickly we find the next prime. more realistically, 75-85% of the factors sieved out right now don't speed up the project "right now." i'm all for thinking long term, but we can't loose sight of shorter term goals.
- The P-1 factoring software is not well optimized and has a lot
of bugs in it, and I think that it would be quite some time before
the software is fully tested.
--> SBFactor v0.5 is fully optimized and has no bugs. I think 3 days of development time is pretty darn good.
-Louie
what program do we use? where do we get it?
To avoid duplication of work:
I am trying the program for k=21181 and 510k < n < 520k (with B1=25000 B2=B1*100).
This program, here.Originally posted by Keroberts1
what program do we use? where do we get it?
Usage:
sbfactor.exe k n 25000 0
Joe O
I think I agree with Joe on this one. I don't see the point in handicaping sieving or P-1 factoring or whatever. Ideally, factoring scores would be a similar to a "how much time did this save the project" kinda thing. realistically, this isn't done because otherwise I'd be credited with 50% of the "work saved" since I was the one who factored the first 25G (where a lot of the factors were). your current scoring does a good job of adjusting the size of the factors to match how hard they were to find. if someone can find a huge factor using P-1, I don't see why it should be discounted.Originally posted by MikeH
I'd like to see how this pans out first, but if it does throw the stats out a long way, I have one easy method of sorting it. I could make it so that all factors with p significantly above the current sieveing range would score as if they were at the top of the current sieving range. Of course this means that anyone that has sieved high would see their score fall over night, but then it would slowly increase again. But I think this would be fair.
reguardless of how you deal with P-1 factoring, I have a couple other sugestions.
I could add a column to the results.txt to show how many tests have been completed for each number. so a 0-factor (untested) should probably get a boost over a 1-factor (tested once) which should get a boost over a 2-factor (tested twice). this would encourage people to basically "do what helps the project most", especially with P-1 factoring (people won't factor small, already double checked numbers and will try and factor completely untested numbers). I know you're a proponent of the DC sieve and a large contributer there so it may seem cruel to discount that work by a faction but it may be more fair. just an idea. i don't expect you to discount them by half, but maybe by like 25% for one tested and 80% for factors of double-tested numbers.
also, last I saw your stats update at 10AM UK time. well I know I posted it somewhere, but I just wanted to make sure that you're aware: the result.txt file is dumped at 3:40AM EST. I'm guessing you're GMT and since I'm -5 that makes it an hour and 20 minutes between when the file is updated and your stats get updated. You could make it a little fresher by updating at 9AM. In fact, if you'd like, I could make it update more often or at different times. It only takes 2 seconds to run so it's not too big a deal to do it a few times a day. I made it 3:40AM back when no one was using it. Now that there are users, that kinda thing may matter more. My only real concern is that it will take too much bandwidth. I'll probably compress it and increase the portion stored off the server in lowresults.zip if you want to download it all the time. gzip files ok?
-Louie
I've already runwith no factor found. i.e k is 55459 and n is 539878Code:sbfactor.exe 55459 539878 25000 0
I'm in the process of running 432 < n < 2998 for various k. I've found factors, but these are already known factors. My list of k n pairs had not excluded them or I would not have run them. But at least it is more proof that the program works, and works well.
Joe O
O yes, I'm also runningfrom Louie's list. I'll post as soon as I'm done.Code:sbfactor.exe 55459 539410 25000 0 sbfactor.exe 55459 539158 25000 0 sbfactor.exe 55459 539146 25000 0 sbfactor.exe 55459 539050 25000 0 sbfactor.exe 55459 539014 25000 0
Joe O
OK, here is my stats proposal:
There should be 3 different stats:
1 for regular sieving
1 for DC sieving
and 1 for P-1 factoring.
For the regular sieving and DC sieving, scores should be based
on the number of ranges you have completed, regardless of
how low/high they are. To discourage people from deliberately
witholding factors, each completed range must have at least
70% of the expected number of factors, and if it doesn't, the
range won't count unless a double check of that range shows that
it is simply an unlucky range.
For the P-1 factoring stats, scores should be based on the number
of factors you find, no matter how big they are.
quote:
_________________________________________________
Incidently, the thing that has really maintained the sieve speed has a lot to do with Jobling's Law(tm) which states that Paul Jobling will release a new version of SoBSieve that's 2x faster every 18 days.
_________________________________________________
I'll revise that:
Jobling's Law states that Paul Jobling will release a new version
of SoBSieve that's 2x faster in 37 days.
SoBSieve v.1.06 was running at 8000 k/p/sec on my PC
on January 24th, and 150 days later (May 24th) SoBSieve
v.1.34 is running at 120000 k/p/sec on my PC, an improvement
of 15x or about 2^4.
Thanks ceselb. You've done a good job.
In fact, what I'd suggest is something like this.
I agree that we should focus on where our computing power makes the most contribution to the project.
As far as the coordination is concerned, how about creating a text file for each k seperately that has only the untested candidates (and those with no known factors of course) including ~14000 remaining for secret, and update those on a daily basis (also taking into account the addidtional factors submitted through sieve).
Better than that, we might consider two enhancements:
- Not including all untested numbers, but including those that are farther away than one week for their prp testing to start. (which would roughly be max n + 100K for n>4m, and secret max n + 10K? for secret)
- Also, excluding the numbers that are reserved (meaning being worked on, hopefully) for P-1 tests.
If everybody uses these files when reserving their P-1 test ranges, this way, I hope, we can:
- Test numbers that we need to test most, and
- Avoid duplication of effort.
Any other ideas?
how do i use it do i need to instal it someplace special?
There is an easy question and a hard question. The easy question is which numbers to test - I think it's clear that we want to stay a short ways ahead of the prp testing - far enough ahead that we are pretty sure P-1 will complete before the handout, but near enough that sieving still has a chance of getting in to save the P-1 test.Originally posted by jjjjL
1) Help me figure out a good allocation strategy for P-1 factoring. (wblipp, I'm looking at you
-Louie
The hard question is how to set the B1 and B2 values. I think we need to use the Dickman functions to estimate the probability of smooth factors, and then we need to know how much work it is to test as a function of B1 and B2.
you may want to grab a copy for the GIMPS source and check out the guess_pminus1_bounds() function in commonc.c. It's actually compiled into the current version but it doesn't yet work (it always returns 0,0). Some modification of this is probably what we want.
http://www.mersenne.org/gimps/source23.zip
-Louie
The other day when I updated the factor verifier, I changed the lowerbound for n from 1 to 1000. The new bounds are all on the sieve page. Anyway, it may not be that those factors are known, it may be that they are simply being rejected by the verifier.Originally posted by Joe O
I'm in the process of running 432 < n < 2998 for various k.
I'll update it to allow you to submit factors again soon.
-Louie
how do i get the program running is there a dat. file i need ? a special directory to install it to. I don't know why but when i open the file that was posted in response ot my question earlier it simply flashed on the screen and dissapeared
NEW version of SBFactor ready.
http://www-personal.engin.umich.edu/...sbfactor06.zip
v0.6 now has experimental (but working) ECM factoring support. usage is as follows:
sbfactor.exe k n B1 B2 curves ecm
such as
sbfactor.exe 33661 4000848 1000 0 1 ecm
this means I want B1 to equal 1000, B2 to be 100x larger than B1, I want to run only 1 curve and then I add the keyword ecm at the end to make the program use ECM mode.
ECM factoring is more difficult to understand than P-1. Here's a quick explanation from the GMP-ECM readme:
Anyway, expect the program to run slower when doing ECM vs P-1 factoring at similar B1/B2 levels. There is also a probablistic nature to how it works, so a factor may not always be found on successive runs like with P-1.The P-1 method works well when the input number has a prime factor P such that P-1 is "smooth", i.e. has all its prime factor less or equal the step 1 bound B1, except one which may be less or equal the second step bound B2. For P=67872792749091946529, we have P-1 = 2^5 * 11 * 17 * 19 *43 * 149 * 8467 * 11004397, so this factor will be found as long as B1 >= 8467 and B2 >= 11004397.
There is no need to run P-1 several times with the same B1 and B2, like for ECM, since a factor found with one seed will be found by another one.
The ECM method is a probabilistic method, and can be viewed in some sense as a generalization of the P-1 and P+1 method, where we only require that P+t is smooth, with t random of order P^(1/2). The optimal B1 and B2 bounds have to be chosen according to the (usually unknown) size of P.
A couple things to be aware of:
The "Normalizing Brent value" step in the begining can take a minute or two for large numbers. It will appear to immediately hang but it will get though it. This is because it's doing a brute force modular inversion of a very large number.
Also, there is no file saving yet. There will be soon.
I fixed a tiny bug in the P-1 code the caused the total time to be reset after saves, making it totally wrong. Nothing serious but it should work correctly now.
Let me know if you test out the new version. I'm pretty sure it's solid. Most people probably shouldn't deal with this feature but it's ok to have it for those of you that know how to use it.
-Louie
Originally posted by Keroberts1
how do i get the program running is there a dat. file i need ? a special directory to install it to. I don't know why but when i open the file that was posted in response ot my question earlier it simply flashed on the screen and dissapeared
- Pick/create a directory
- Put the program in that directory
- pick a k value, one of the 12
- pick an n value (or more than one) for the k value you chose
- create a something.bat file in your directory with one or more lines of the follwing form:
Code:sbfactor.exe k n 25000 0- run the bat file
- look for a fact.txt file in that directory - if there is one submit the lines the same way you would the results of a sieving run
- pick another k - or the same one
- pick some more n
- create a s.bat file or modify the something.bat file
- run it
- look for fact.txt and submit new results
- ...
Joe O
To find most 15 digit factors you should run about 25 curves with B1=2000 (ECM). I haven't tested how long each curve would take though.
Louie:
Can you make the next version run at idle priority or at least give it a command line option to do so? And also an option on how often to update the screen?
I think the biggest problem with manual P-1 is the coordination. So many numbers so it will be hard to keep track whcih numbers are done and with what bounds.
It would be great if a future SoB client would have an option to P-1 before the prp test starts.
If it takes a pc 5 days to prp a number and the chance of finding a factor is 3% (using optimal bounds) it's worth to spend
(2 * 5 * 24 * 1.02) * 0.03 ~ 7 hours on P-1 so the currentely used B1=25000 is actually to low (although i'm trying a few numbers with B1=15000 right now).
edit
Just thought of one more thing:
Can you let the program create a resuls file with all numbers tested (to what bounds and factors found)?
Last edited by smh; 06-16-2003 at 10:29 AM.
Keroberts1,Originally posted by Joe O
- create a something.bat file in your directory with one or more lines of the follwing form:
Code:sbfactor.exe k n 25000 0
In case you have problems creating one, here's a sample *.bat file for the remaining candidates of k=4847 for 4,000,000 < n < 4,001,000.
The lines in it contain;
sbfactor.exe 4847 4000167 50000 0
sbfactor.exe 4847 4000287 50000 0
sbfactor.exe 4847 4000503 50000 0
sbfactor.exe 4847 4000527 50000 0
sbfactor.exe 4847 4000623 50000 0
sbfactor.exe 4847 4000743 50000 0
Just unzip it to the same folder as the P-1 client, modify as you like, and run it.
EDIT: Forgot to mention, you can use notepad, wordpad etc. to view, edit and save. If you are using notepad, just save it by adding .bat at the end of the filename you select.
Last edited by Nuri; 06-16-2003 at 01:51 PM.
Progress report:Originally posted by Nuri
To avoid duplication of work:
I am trying the program for k=21181 and 510k < n < 520k (with B1=25000 B2=B1*100).
28 tests finished out of 43 in 17 hours, and found only one factor so far. That refers to 36 minutes per test on the average.
PS: Machine used is PIV-1700, 7/24, 99% of CPU time. Version used is 5.
Do you think those figures are normal? (both the speed and number of factors found per test).
If the figures are normal and, if I am not particulary unlucky finding only 1 factor within 28 tests, then it is far more beneficial to prp test instead of P-1 at n=510k level.
Just a quick comparison:
It takes 75 minutes to prp test a candidate at 510k. Taking a conservative view and assuming that in 10% of the tests the residues of secret and supersecret do not match, it takes 2.1 tests to completely get rid of a candidate. => 75 * 2.1 = 157.5 minutes. (or ~9 candidates per day).
I should have been 6 times more luckier to meet the prp effectiveness at 510k.
I am sure thinks are different at higher n values.
Any other benchmarks?
BTW: The factor found is 4965673550983 | 21181*2^510164+1. Nothing impressive.
Last edited by Nuri; 06-16-2003 at 01:35 PM.
I suggested that people might want to try around n=510k because they can be factored quicker than larger numbers. It's a good way to get used to the new program while it's still so user-unfriendly. I agree that it probably doesn't make sense to systematicly test all numbers around 510k.Originally posted by Nuri
I should have been 6 times more luckier to meet the prp effectiveness at 510k.
I am sure things are different at higher n values.
I'm gonna work on fixing the auto-bound setter. When I get that working, it will be much simpler for coordination purposes. We won't have to track the bounds used for each person on each number. People will just reserve all the n values in a short range and test them to the optimally chosen bounds.
After that I'll program in a .dat file reader so that instead of processing each number seperately though a klunky batch file, you'll just do like
sbfactor.exe SoB.dat 511000 511500 -optimal
as long as you have a new SoB.dat file, you won't have to sort though the text files and check for new factors. or maybe a SoB.dat / result.txt parser so that you can just get a new result.txt file instead of having to use it to update a .dat file.
Anyone find any interesting factors using ECM yet? I have a bunch of random ones I found during testing but nothing too impressive:
17311 | 3*2^4000+1
7 | 3*2^4000+1
7 | 3*2^4000+1
19089 | 4847*2^1000+1
670260543 | 4847*2^3000+1
303 | 4847*2^5000+1
692961 | 4847*2^6000+1
1933885607192733 | 4847*2^6600+1
14361 | 4847*2^6660+1
285261 | 4847*2^6666+1
2879443 | 4847*2^6667+1
189 | 4847*2^6670+1
189 | 4847*2^6670+1
55243523 | 4847*2^6675+1
35376326783 | 4847*2^667+1
189 | 4847*2^6670+1
10868360769 | 4847*2^17680+1
89523 | 4847*2^17680+1
11572653225845 | 4847*2^17685+1
3 | 22699*2^9607+1
21 | 22699*2^19607+1
127049127 | 22699*2^39607+1
69 | 22699*2^69607+1
3 | 22699*2^99607+1
442191729 | 22699*2^199607+1
3 | 55459*2^52537+1
-Louie
Tested 30 of 43 numbers with version 0.5.Anyone find any interesting factors using ECM yet?
Trying remaining 13 with version 0.6.
I'll post results when done.
EDIT: Used sbfactor.exe k n 1000 0 1 ecm for the remaining numbers. It took 6.5 minutes per test. No new factors. So, 1 in 43.
PS: Using 25000 instead of 1000 together with ecm would probably make each test last ~4 hours.
Last edited by Nuri; 06-16-2003 at 05:55 PM.
I don't think you're really unlucky. If you find 2 factors on the 43 tests you're finding factors for about 5% of the numbers.If the figures are normal and, if I am not particulary unlucky finding only 1 factor within 28 tests, then it is far more beneficial to prp test instead of P-1 at n=510k level.
It's definately not worth trying P-1 on 500K numbers with these high bounds. Thats what the optimal bounds are for.
You might have been luckier trying more numbers with lower bounds in the same time, but i guess even sieving is already past the optimal depth for numbers around 500K so most easy factors have aready been found.
Trying P-1 around 4M is a different story though. Each test might take longer to perform but if you still find factors for 3-5% of the candidates overall throughput will increase (especially if you take double checking into consideration).
I agree totally with what you are saying here, I just need to get the implementation sorted. As you'll see from today's stats, the current scoring doesn't work - biwema jumps straight to the top.I think I agree with Joe on this one. I don't see the point in handicapping sieving or P-1 factoring or whatever. Ideally, factoring scores would be a similar to a "how much time did this save the project" kinda thing....
The current scoring is really a "even though you get less factors the further we go, you still score the same as a similar sized lower range". Thus score is directionally proportional to computing effort (or there abouts). What I'd like to do is the same for P-1 factoring - when we have some data for the relative effort expended per factor, then we can follow the same line as the current sieve focused scoring. I like biwema's idea for identifying factors not from sieving.
This would be really useful. I tried to do something like this early on, but not having access to enough data meant I gave it up and just made things simpler, but less focused on finding factors for untested candidates.I could add a column to the results.txt to show how many tests have been completed for each number. so a 0-factor (untested) should probably get a boost over a 1-factor (tested once) which should get a boost over a 2-factor (tested twice).
With EST do you operate day light saving? That 10AM is GMT+1, so it's really 9AM GMT. If it's easy, how about updating 4x per day - I'll need to think about my side, but at least it will all be in place when I'm ready. How about moving the lowresults.zip up to 3T, that will significantly shrink the results.txt file. gzip files are OK with me.also, last I saw your stats update at 10AM UK time. well I know I posted it somewhere, but I just wanted to make sure that you're aware: the result.txt file is dumped at 3:40AM EST. I'm guessing you're GMT and since I'm -5 that makes it an hour and 20 minutes between when the file is updated and your stats get updated. You could make it a little fresher by updating at 9AM. In fact, if you'd like, I could make it update more often or at different times. It only takes 2 seconds to run so it's not too big a deal to do it a few times a day. I made it 3:40AM back when no one was using it. Now that there are users, that kinda thing may matter more. My only real concern is that it will take too much bandwidth. I'll probably compress it and increase the portion stored off the server in lowresults.zip if you want to download it all the time. gzip files ok?
Mike.
Mike,
I updated the factor result files. I think I got all our wishes covered. I added the NumTests column to the end of every factor line. I also have the script setup to gzip the result file a couple minutes after it makes it. The updates are now at 3:40/9:40 AM/PM EST. So you can have your stats update at every 10 and 4 your time. File is here:
http://www.seventeenorbust.com/sieve/results.txt.gz
I also raised the lower limit from 1T --> 3T per your suggestion. This plus the gziping brings the filesize down from over 3MB to 700k even though there is a new column.
The new archive of factors for p < 3T is here:
http://www-personal.engin.umich.edu/...results.txt.gz
I look forward to seeing how you use the new info. Any other data you can think of that would help with scoring?
-Louie
961094450858074349 | 67607*2^4022171+1
Just wanted to report a real big useful factor!!
Hi,
I tried p-1 on the mantisse 21181 between 350000 and 390000 until now.
There were 142 candidates and I found 7 factors with the bounds 100000 and 1000000.
I think (just a feeling), that it is not optimal to set B2 100 times bigger than B1. It takes too much time and the benefit is too small. I recommend that B2 is about 10 to 25 times bigger than B1.
With a B1 of around 100000 (a bit more than the suggested 25000) and a B2 of 1 to 2.5 million the efficiency might be a bit better.
My 7 factors look like this:
#1 374P, b1=15000, b2=90000
#2 18T, b1=3000, b2=125000
#3 324T, b1=250, b2=40000
#4 composite: product of a 10 digit and 13 digit factor
#5 256P, b1=3500, b2=15000
#6 2P, b1=30000, b2=125000
#7 2E, b1=90000, b2=800000
most of these factors are quite much below the bounds.
If I had set the bounds twice a big, I probably would have found 1 or 2 more factors, but it also would have taken twice as long to test that range.
By the way. sbfactor does not correctly measure the time of stage 2. It is much too low (or does that only happen on ma computer?). That might be a reason that people choose such a big b2?
Maybe that might change a bit with bigger exponents.
good luck
biwema
quote:
--------------------------------------------------------------------------------
I think I agree with Joe on this one. I don't see the point in handicapping sieving or P-1 factoring or whatever. __________________________________________________
and
quote:
______________________________________________
I agree totally with what you are saying here
______________________________________________
Look here, at Garo's factor:
961094450858074349 | 67607*2^4022171+1
EVEN IF IT IS A DUPLICATE, it would score over 9 million on
Mike's sieve stats!! That's >7x more than what we have sieved
COMBINED! There's got to be a better way to score the factors,
or
P-1 factoring
Biwema,
Are you using version 0.5 or 0.6?
It seems to me that version 0.6 measures the time correctly. Well, I tested it on with ecm paramter only, but it seemed right. If you mean version 0.5, you're right, it's time measurement was wrong.
Posting Permissions
Reply With Quote
