LMH status
 

The nofactor.cmp file was just updated and I decided to do a quick stat analysis to see just where we are. I took all the exponents between 25M and 79.3M and tried to see how far they have been factored. And here is the result:

[code:1]
Bits Exponents
57 26644
58 584877
59 338835
60 409474
61 13349
62 9036
63 4116
64 2484
65 3
66 8
67 6
68 6345
69 44
70 3
71 6
72 17
74 1
Tot. 1395248
[/code:1]

PS: I'm working on the 57 bits guys right now so we should have everything above 25M up to atleast 58 bits very soon.

Henk, Is it possible for you to update your page at:
http://home.planet.nl/~tha/mersenne/index.html

It's been a couple of months since the last update.

Updated stats. Henk's graphs would be real good tho :)
Dated: 8/8/2003

[code:1]
Bits Exponents
57 26643
58 575524
59 332780
60 420774
61 13400
62 11837
63 4421
64 2764
65 3
66 8
67 6
68 6480
69 44
70 3
71 6
72 17
74 1
Tot 1394711
[/code:1]

Garo -

Any chance you could add a total row to your recent post so we can see how many exponents have been cleared by LMH? It would give me a warm, fuzzy feeling, and I'm just not that good at 'rithmetic... :D

And I've got more. [img]http://www.teamprimerib.com/annie/overview030808.gif[/img]

One more thing!

Assuming that all the exponents above were factored to 67 bits by LMH we would find an additional 167453 factors. So lots more factors to be found :)
In reality, the total number of factors found will be larger as many of the exponents will be trial factored deeper than 67 bits. And LMH would probably contribute fewer factors as we won't go all the way to 67 in LMH anyway.

Garo -

Thanks for the update!

Now for some musings:

The factoring limits set by GIMPS seem to tend strongly toward clearing 5/8 of the potential exponents before a LL test. If this trend holds, we expect to find factors for about 2894320 of the 4630913 prime exponents below 79.3M.

Since we have factored 2644927 Mersenne numbers already if we factor 167453 more via LMH up to 67 bits, that will leave just under 72000 Mersenne numbers to be found composite with additional factoring.

OTOH, thanks to garo, we know that LMH is clearing about 500 exponents a week. At that pace, we could complete factoring to 67 bits in about 6.5 years.

Disclaimer: Wild speculation has been used in the creation of these numbers.

[code:1]
Bits Exponents (8/25/03)
57 26643
58 492657
59 352137
60 478204
61 14996
62 12402
63 5226
64 2981
65 3
66 8
67 6
68 6730
69 44
70 3
71 6
72 17
74 1
Tot 1392064
[/code:1]

Since we had a new nofactor.zip published, I thought I'd see how the numbers stacked up and it looks like we're making solid progress, clearing almost 2650 exponents. Also, 73 continues to be the least favorite terminal bit depth. :)

thanks apocalypse!!

Here the update from Sep 1st:

[code:1]
bit depth
57 26643
58 487188
59 323340
60 508148
61 15910
62 14945
63 4744
64 3459
65 3
66 8
67 6
68 6807
69 44
70 4
71 6
72 17
74 1
tot 1391273[/code:1]

Are we allowed to set FactorOverride to digits HIGHER than Primenet would assign them to after we kill off some of the ranges, as something to do for fun, and to get a 73 on that list for you?

I guess that's how the 74 got in there - the normal prime95 limit is 72 for exponents between 71M & 79.3M.

Yes you can set the override to whatever you want. It's just that setting it higher takes a hell of a lot of time.

lets see ... a 69.5M # from 61 to 62 takes 7.5min, so that same # from 62 to 73 would take an additional 7.5*2046 = 15345 minutes, or roughly 11 days.

I'm afraid not! the step from 62 to 63 and then from 64 to 65 MORE than doubles the amount of time required. So it will be more like 20 days.

those the change in FFT sizes used? i'm not completely familiar with the algorithm, and it's only the second week back in classes so i'm not sure my mind would fully understand anything complex this gets in response - but try it and i'll try to comprehend again in a few weeks :)

No it is not the FFT sizes. There was some super efficient algo for non-SSE2 CPUS that was developed that works reall well for < 62 bits. Hence the jump from 62 to 63. 64bits can fit in two words whereas 65 bits need three. So the jump there is due to that.

is there a way to have my computer stop using the SSE2 and use something else to make it more efficient at lower bits?

No unfortunately not. P4 actually sucks at non-SSE2 calculations on a per-clock basis. It only performs better as it uses SSE2 for 64 bits and above. That is why I reommended using a non-P4 for under 62 bits.

how about P3's?

P3s are fine. I think if you just do a quick test at factoring a number to 62 bits on both a P4 and a P3 you will be surprised at the results. For example look at these timing tests I did a while back. the 1333 Athlon outperforms the 2533 P4 upto 62 bits! :shock:

[code:1]

Time taken to complete 14366959 to 0.98%

To Bit On PII 450 On P4 2533 Improv On 1333TB Improv

59 6 2.5 2.4 1.85 3.25
60 12 5 2.4 3.7 3.25
61 24 10 2.4 7.4 3.25
62 48 20 2.4 14.8 3.25
63 170 37.5 4.5 51 3.33
64 340 75 4.5 102 3.33
65 1540 180 8.5 480 3.21
[/code:1]

This data indicates that it is best to do upto 62 bits on a non-P4, maybe even upto 64 bits. And after 64 bits, the P4 smokes due to SSE2.

once my p3 finishes its current assignment from primenet, i'll have some numbers of my own to post about p3 v p4 - yey - dance time :banana:

also, what's a 1333TB?

1.3 GHz Thunderbird Athlon

Even though I am not yet an LMH (have to dig the 200MMX machine out and get it going),

I was wondering, is there any semi-co-ordinated work being done to thin out the predicted "sweet-spots"? Like the range near 33M? I would think that this is one where dealing out narrow bands to multiple people would lend to rapid completetion and then a run again at the next higher bit level.

For example:
The sweet spot peaks at say 33.35M, 3 workers on the team at first.
Sliver up 33.0-33.7 into say 3 chunks to go from 2^60 - 2^61
Turn in results.
Let one person work on the 2 side ranges upto 2^64
Split the center range in half and run up 2^62, then 2^63.
Take the center range and split into 3 pieces, run to 2^64, adding a new body.
Leave one working the two smaller ranges upto 2^66.
Split the center again in half and run to 2^66
Split the range into 3 and add a memeber and run up to 2^67.
Repeat until at least upto the predicted point of cost>benefit.

Turn over sweetspot numbers to a crew with P-1 monsters. 400MB plus machines.

Update from Sept 8:

- 849 new factors found, since the last update.
- most activity on the 58 bit depth.

[code:1]
Bits Depth Diff
---- ------- ------
57 26643 0
58 449775 (37413)
59 342963 19623
60 522670 14522
61 17220 1310
62 15911 966
63 4487 (257)
64 3710 251
65 3 0
66 8 0
67 6 0
68 6953 146
69 44 0
70 6 2
71 6 0
72 18 1
73 0 0
74 1 0
---- ------- ------
Tot: 1390424 (849)
[/code:1]

[quote]Even though I am not yet an LMH (have to dig the 200MMX machine out and get it going),

For example:
The sweet spot peaks at say 33.35M, 3 workers on the team at first.
Sliver up 33.0-33.7 into say 3 chunks to go from 2^60 - 2^61
Turn in results. etc..... [/quote]

33.2-33.6 have been placed in PrimeNet, and are therefore not for usage by people in LMH.

Update from the 21st of September:

57 26491
58 395727
59 350502
60 547489
61 28745
62 22317
63 5326
64 4265
65 3
66 8
67 6
68 7139
69 44
70 6
71 6
72 18
73 0
74 1
---- ------- ------
Tot: 1388093 (2331)

Keep going!...

[code]
Bits Exponents (9/29/03)
57 26483
58 382203
59 342848
60 564292
61 29062
62 25100
63 5621
64 4346
65 3
66 8
67 6
68 7261
69 44
70 6
71 6
72 18
73 0
74 1
---------------
Total 1387308 (785)
[/code]

Some other vital statistics:

In the range of exponents from 25M to 79.3M, we expect to prove about 231991 exponents composite through trial factoring to GIMPS' proscribed factoring limits, and this will save about 4515695 P-90 CPU-years of first time LL tests.

Below 25M, we expect to prove about 7982 exponents composite through trial factoring, and save about 18570 P-90 CPU-years of first time LL tests.

Expected number of factors computed using factoring limits and probability function on [url]www.mersenne.org/math.htm[/url] (10/7/2003) and data from the 9/29/2003 edition of nofactor.cmp

Cost computed with additional range and average cost data on [url]www.mersenne.org/status.htm[/url] (10/7/2003)

Your milage may vary.

[code]
Bits Exponents (10/8/2003)
57 19846
58 376607
59 320506
60 593270
61 28080
62 30499
63 5395
64 4572
65 3
66 8
67 6
68 7394
69 44
70 7
71 6
72 18
73 0
74 1
Total 1386262 (1046)
[/code]
Keep up the good work!

[code]
Bits Exponents (10/23/03)
57 5624
58 369095
59 310528
60 615754
61 25987
62 39845
63 5396
64 4786
65 9
66 8
67 6
68 7661
69 44
70 7
71 6
72 18
73 0
74 1
Total 1384775 (1487)
[/code]

We seem to be moving a lot of exponents up from 57 bits, and 60 bits is rapidly becoming the next plateau. Good work all!

Gosh! Somebody just did some 400000 range of exponents from 29.2 to 29.6M from 57 to 58. I have been carrying this range all the way up o 60 and doing 3 bits takes a lot of time but it sure feels bad to be poached!!

Sorry to hear that. Since the factoring reports don't keep user info, maybe we could get George to tell this other guy he's duplicating work?

Is this updated anymore?

You asked for it, you got it!

[CODE]
Bits Exponents (11/08/03)
57 2688 (-2936)
58 362097 (-6998)
59 288546 (-21982)
60 638679 (22925)
61 27134 (1147)
62 43626 (3781)
63 8364 (2932)
64 4727 (-59)
65 9
66 8
67 6
68 7792 (131)
69 44
70 7
71 6
72 18
73 0
74 1
Total 1383752 (-1023)
[/CODE]

Another little statistics :
[CODE]
Status Average depth no factors

30 Jul 2003 58.94 bit 1395248
09 Nov 2003 59.42 bit 1383752
[/Code]
So, on the average during the last 14 weeks the factoring depth has increased by 0.48 bit. If we assume the same for the next time the average would increase by 1 bit within about 30 weeks and the cost for LMH is therefore doubled in the same time.
That's much more than predicted by Moore's Law and above the actual trend of CPU speeds. So we have to expect a gradual decline in the next year (if not much more computers involved in LMH).
Nevertheless, I guess LMH can achieve an average level of 62 bit within the next 2-2.5 years.

11496 new factors were found , ie. 821 per week or 117 per day. The GIMPS status page exhibit 18674 new factors in that time (including TF,LL,DC and others), so we can assume that at least 60% of the factors reported were obtained by LMH !

[QUOTE][i]Originally posted by hbock [/i]
[B]
[CODE]
Status Average depth no factors

30 Jul 2003 58.94 bit 1395248
09 Nov 2003 59.42 bit 1383752
[/Code]
So, on the average during the last 14 weeks the factoring depth has increased by 0.48 bit. If we assume the same for the next time the average would increase by 1 bit within about 30 weeks and the cost for LMH is therefore doubled in the same time.[/B][/QUOTE]
Since no weighting of bit depths according to difficulty is mentioned, I presume these averages gave equal weight to each exponent, regardless of size -- correct?

But we know that raising the TF bit depth for 2^971-1 from 57 to 58 will involve much more work than raising the TF bit depth for 2^9710011-1 from 57 to 58 did ... about 10,000 times more, offset by the ratio of time necessary for each trial division of 2^9710011-1 compared to time for each trial division of 2^971-1. BTW, is this ratio logarithmic by exponent, at least approximately? ~ log 9710011 / log 971 = ~ 2.3 ?

Assuming a log ratio, then what would be the average bit depths given above if the bit depth for each exponent were weighted by (log exponent)/exponent ? And what would that do to the extrapolated prediction for the 62-bit level?

After that, what about incorporating the ratio of time needed for a trial division in the 2^58 range compared to a trial division in the 2^62 and higher ranges? Iteration times increase significantly from 2^62 to 2^63, then again from 2^64 to 2^65. Of course those ratios depend on CPU type ...

Well, the average factored bit depth is just a statistical value for the database (in that case for exponents 25M-79M). Each exponent is equal weighted with 1 and therefore it doesn't say anything about the CPU time spent to reach or increase this value.

At the moment the work is distributed over all ranges. So, if we assume that each exponent is factored to a distinct value i and for more than 90% i is less 62 bit, then (regardless of the CPUs used) the time to bring this level to i+1 is increased by 2 (compared to a former step from i-1 to i and as a first approximation).
Nevertheless, because most of the work is done by raising exponents from the lowest levels to a higher one, it could be that the factoring speed will continue for awhile, even with about the same computing power. But, when all low level exponents (58/59 bit) are at the 60 bit level or more then we have to expect a significant decline, anyway. Other reason is that the organized LMH is too new and therefore the speed is not yet stable and hard to predict.
And, if we have most of the exponents at 62-64 bit the standard CPU used for LMH will maybe an (old) P4, goodness knows ...

A bit of trivia: there are now more exponents on 60 bits than below 60 bits! This is for exponents above 25M, and for all exponents.

Well done everyone!

[code]
Bits Exponents (11/17/03)
57 2688
58 333877 (-28220)
59 264974 (-23572)
60 673915 (35236)
61 31567 (4433)
62 53183 (9557)
63 8863 (499)
64 4722 (-5)
65 9
66 8
67 20 (14)
68 8074 (282)
69 49 (5)
70 7
71 6
72 18
73 0
74 1
---------------
Total 1381981 (-1771)
[/code]

[code]
Bits Exponents (12/02/03)
57 2688
58 306227 (-27650)
59 259499 (-5475)
60 652992 (-20923)
61 76122 (44555)
62 58865 (5682)
63 10320 (1457)
64 4655 (-67)
65 9
66 8
67 20
68 8370 (296)
69 50 (1)
70 7
71 6
72 18
73 0
74 1
---------------
Total 1379857 (-2124)
[/code]

Note that the range 33.7M to 33.8M is now on Primenet, and should not be reserved.

just a couple q's:

what numbers are still at 57 bits?
is someone working on those numbers?

The exponents at 57 bits are mainly, if not all, on primenet awaiting reservation.

All these 57 bit factored exponents are in the 29M range where garo is working on.
I'm sure we'll have them soon at 60 bit.

25M is the next range waiting for primenet reservation. Some people try to get these exponents at least to 61/62 bit to support the TF process a little (leading edge of LL testing is coming closer). 25.2-25.5M is still available.

I've got an account on primenet that has TF's in the 23M range that are at 57 bits, I thought this is where they were, oh well :smile:

The numbers above only show exponents over 25M. There is a small bunch of exponents between 29.7 and 29.8M that are still at 57 bits.

I haven't worked on that range yet as I was afraid the person who "poached" the rest of the 29M range would turn the results in. (See my post about 15 posts above). But since they haven't , I'll get to work on them tomorrow. It should take a couple of weeks.

A correction to my previous post. The numbers at 57 bits are 29.8 to 29.9M. I've split the range into two and put two computers on it so it should be done in about 10 days.

good .... so in three updates there should no longer be a need for that row of the chart - go lmh :showoff:

[code]
Bits Exponents (12/14/03)
57 2688
58 293363 (-12864)
59 251578 (-7921)
60 661113 (8121)
61 83108 (6986)
62 62816 (3951)
63 10430 (110)
64 4828 (173)
65 9
66 125 (117)
67 37 (17)
68 8831 (461)
69 50
70 8 (1)
71 6
72 18
73 0
74 1
---------------

Total 1379009 (-848)
[/code]

I just submitted the last of the 57 bits results. Too bad I missed this week's update.

eh - i submitted one set on the 24th and one on the 25th - neither of which made this update - so your set for the 27th had no chance ....

Ah! I think a clue can be found in the "update date" on the GIMPS status page. Even though the timestamp on all the files - nofactor.zip, hrf3.zip etc. - is Dec 26 the update date is Dec 23 so I do not think any results after Dec 23rd were included.

The graphs at [URL=http://home.planet.nl/~tha/mersenne/]reflecting the amount of factoring done[/URL] have been updated to include all the 2003 updates.

This is great. Thanks tha.

can someone explain to my what the black and brown lines on this graph represent?

1 number? 100 numbers? I'm lost as to if this gives a count of any sort for these ranges

[QUOTE][i]Originally posted by tom11784 [/i]
[B]can someone explain to my what the black and brown lines on this graph represent?

1 number? 100 numbers? I'm lost as to if this gives a count of any sort for these ranges [/B][/QUOTE]

Each bar represents one or more (in this graph 79,300,000/1280) exponents that have been factored up to the bitlevel written on the vertical axis.

All bars are red with a black line around it. Two or more adjacent bars therefore make a black surface.

You can get the sourcecode in Delphi and the binaries at [url]http://home.planet.nl/~tha/overview.zip[/url]

The program allows you to examine a shorter range at more detail.

neat little program :rolleyes:

Exponents above 25M from nofactor.txt 31/12/2003
[CODE]Bits Exponents Change
57 0 -2687
58 268373 -9840
59 255880 -3960
60 651802 -5041
61 101901 16582
62 72542 3117
63 12419 689
64 4599 -47
65 9 0
66 125 0
67 37 0
68 9490 229
69 50 0
70 9 0
71 6 0
72 18 0
73 0 0
74 1 0
Total 1377261 -958[/CODE]

sweet everything is above at least 57 bits. great job everyone! lets work on removing the 58bits now :). I've got a 3 million range right now (66-69) so theres about 80K numbers there. thats a start i guess :)

Yaay! Congratulations to everyone on finishing 57 bits. For the new year let us resolve to finish 58 bits in 2004.

Are we up to it?

well at the rate of clearing 9840 exponents at 58bits in the past 17 days, it would take roughly 464 days to get all numbers beyond 58

i'm not sure however of the size (28M vs 77M makes a large difference) and what's left, but will look later at that part

on 31-07 there were 584877 numbers at the 58 bit level, half a year later less then half.

if we're gonna try to get rid of all the 58bits this year, which i think is very very likely to happen, i think we should find out which users have the ranges with numbers factored only to 58bits reserved. Then we can see if there's actually any progress going on with these ranges. if not we can release them and have some other people work on them. what do you guys think?

Ranges with exponents at 2^58:

[code]
Exponents Date Assignee

25500000 27000000 3331 03-12-03 bayanne
29200000 29600000 6261 03-11-01 garo
32000000 33000000 6598 03-11-07 tha
35000000 36000000 21168 03-08-21 Benjamin
37000000 38000000 15573 03-04-04 hbock
39500000 40000000 1693 03-04-09 norbert
42057331 43000000 21968 03-06-08 Kevin
46000000 48000000 26042 03-05-18 bhebden
49000000 50000000 7066 03-08-19 asdf
52000000 54000000 20536 03-11-04 1997rj7
55500000 56000000 13052 03-07-18 wpolly
56000000 56500000 11313 03-10-28 andi314
56500000 57000000 10514 03-05-31 ThomRuley
59000000 60000000 25921 03-04-04 garo
62000000 66000000 9
66000000 69000000 77328 03-12-18 antiroach

Total 268373
[/code]

Thanks for the nice overview.
Few days ago I've cleared the leftovers in the 64M range. All others are assigned and I think a lot of them we will have at 60 bit at the end of the year.

[QUOTE][i]Originally posted by hbock [/i]
[B]
Few days ago I've cleared the leftovers in the 64M range.[/B][/QUOTE]

You mean 62M, right?
Otherwise I can clear them, let me know.

nice chart 1997rj7! I've got about 30,000 numbers left in my range. Will send all the results to George because I'd probably be here till the end of the century if i tried submitting using the manual check in :0 Keep up the good work everyone.

P.S - Should we contact the people with these ranges yet or is it still too early?

It seems that all these ranges are in progress, so there is no need to contact anybody at the moment. Many ranges are also being factored from 58 to 60 bit. This takes much more time especially on slower machines running not 24/7.
BTW, it's also not a must that people with the fastest Athlons grab the ranges with the lowest bit levels while there are still other ranges available (eg. 60-62 bit). I mean, we can't and we won't assign that strictly, but it makes more sense and fun for example with a PII or P3 to work below 60 bit (as long the range is not too big).
To contribute more efficiently to GIMPS it would be also nice to raise the entry level for TF, let's say to 62 bit ( maybe later higher) .

Lycorn, I meant these 9 leftovers (62-66M):
[CODE]M64309309 no factor to 2^59, WZ1: 6944ABFC
M64837189 no factor to 2^59, WZ1: 6E4EAF81
M64837217 has a factor: 382178514157598231
M64837247 no factor to 2^59, WZ1: 6E4EAF79
M64837259 no factor to 2^59, WZ1: 6E5AAF7A
M64837351 no factor to 2^59, WZ1: 6E5FAF7E
M64837363 no factor to 2^59, WZ1: 6E4EAF7F
[Fri Jan 02 23:01:44 2004]
M64837387 no factor to 2^59, WZ1: 6E66AF81
M64837397 no factor to 2^59, WZ1: 6E53AF80
[/CODE]
It's submitted but not yet in the data files.

I can speak for bayanne and my ranges. They are being actively woked on.

quick question for the status charts

does that include ALL numbers from 25 to 79.3M, or is there some range not included (maybe 33-35M) because of primenet activity?

edit - if there is a range missing, can you tell me what it is?

(I'm trying to test more of my Matlab skills to produce a chart of the statuses of LMH with each file - not as nice as the graph, but personally useful to me)

The stats include all ranges including the 33.2 to 33.6 ranges that are not being worked on by LMH.

[code]
Bits Exponents (01/08/2004)
58 264373 (-4000)
59 238171 (-17709)
60 671516 (19714)
61 97243 (-4658)
62 78380 (5838)
63 12419
64 4557 (-42)
65 9
66 137 (12)
67 37
68 9703 (213)
69 50
70 9
71 6
72 18
73 0
74 1
---------------

Total 1376629 (-632)
[/code]

Is there any place where older version of the nofactor file are stored for easy access?

If not does anyone still have the Jan 1, 2004 nofactor file that I can access from them? (please feel free to PM or email if you do)

I'm looking to make a chart tracking our progress for the year, and it would be nice to start from Jan 1 instead of Jan 8.

You can get it here:

[url]http://opteron.mersenneforum.org/~ag/nofactor.zip[/url]

[code]Bits Exponents (01/18/2004)
58 259428 (-4945)
59 219851 (-18320)
60 691439 (19923)
61 95708 (-1535)
62 81871 (3491)
63 12420 (1)
64 4819 (262)
65 9
66 205 (68)
67 37
68 10060 (357)
69 50
70 9
71 6
72 18
73 0
74 1
---------------

Total 1375931 (-698)[/code]

[code]Bits Exponents (01/27/2004)
58 125769 (-133659)
59 292287 (72436)
60 732949 (41510)
61 107061 (11353)
62 84576 (2705)
63 14088 (1668)
64 4844 (25)
65 9
66 250 (45)
67 37
68 10335 (275)
69 50
70 9
71 6
72 18
73 0
74 1
---------------

Total 1372289 (-3642)[/code]

anyone interested in seeing some slightly more detailed nofactor data for 25-79.3M exponents can view my charts for the past 4 nofactor files at
[url]http://www.geocities.com/tommyzink/gimps/25000000_79299999/[/url]

Tom,
That is an excellent chart! Thanks.

my latest chart for the new nofactor file is loacted at [url]http://www.geocities.com/tommyzink/gimps/25000000_79299999/2004_02_07.html[/url] for anyone interested

[code]
Bits Exponents (02/07/2004)
58 122864 (-2905)
59 256046 (-36241)
60 767810 (34861)
61 101410 (-5651)
62 90895 (6319)
63 15807 (1719)
64 4910 (66)
65 9
66 280 (30)
67 70 (33)
68 10680 (345)
69 50
70 9
71 6
72 19 (1)
73 0
74 1
---------------

Total 1370866 (-1423)
[/code]

Just a FYI:

If you don't like the box the forum puts around the code tag, use the [ pre ] tag...

[pre]Bits Exponents (02/07/2004)
58 122864 (-2905)
59 256046 (-36241)
60 767810 (34861)
61 101410 (-5651)
62 90895 (6319)
63 15807 (1719)
64 4910 (66)
65 9
66 280 (30)
67 70 (33)
68 10680 (345)
69 50
70 9
71 6
72 19 (1)
73 0
74 1
---------------

Total 1370866 (-1423)[/pre]

[pre]
I'm not too crazy about the box, but it doesn't hurt as long as the message
is not so long that it scrolls inside.
On the other hand, I like the double-spaced look of the <pre> tag even
less. :rolleyes: Does everyone see this post as double-spaced?
[/pre]

[QUOTE=1997rj7][pre]
I'm not too crazy about the box, but it doesn't hurt as long as the message
is not so long that it scrolls inside.
On the other hand, I like the double-spaced look of the <pre> tag even
less. :rolleyes: Does everyone see this post as double-spaced?
[/pre][/QUOTE]

I do (on IE6), but when I put a [ pre ] [ /pre ] tag on every line I end up with this, which looks right to me.
[pre]Bits Exponents (02/07/2004)[/pre]
[pre]58 122864 (-2905)[/pre]
[pre]59 256046 (-36241)[/pre]
[pre]60 767810 (34861)[/pre]
[pre]61 101410 (-5651)[/pre]
[pre]62 90895 (6319)[/pre]
[pre]63 15807 (1719)[/pre]
[pre]64 4910 (66)[/pre]
[pre]65 9[/pre]
[pre]66 280 (30)[/pre]
[pre]67 70 (33)[/pre]
[pre]68 10680 (345)[/pre]
[pre]69 50[/pre]
[pre]70 9[/pre]
[pre]71 6[/pre]
[pre]72 19 (1)[/pre]
[pre]73 0[/pre]
[pre]74 1[/pre]
[pre]---------------[/pre]

[pre]Total 1370866 (-1423)[/pre]

This is obviously tedious by hand, but a program could easily add the necessary tags to every line. The entry in the FAQ about the [ pre ] tag had a different solution, but I couldn't get it to work. [url]http://www.mersenneforum.org/misc.php?do=bbcode#pre[/url]

[QUOTE=1997rj7][pre]
Does everyone see this post as double-spaced?
[/pre][/QUOTE]
Not with IE4.

[QUOTE=1997rj7][pre]
Does everyone see this post as double-spaced?
[/pre][/QUOTE]

Yes (with IE6)
No (with IE5).

[QUOTE=lycorn]Yes (with IE6)
No (with IE5).[/QUOTE]

No with Mozilla 1.6

[code]
Bits Exponents (02/15/2004)
58 121917 (-947)
59 224426 (-31620)
60 797785 (29975)
61 101267 (-143)
62 92317 (1422)
63 16179 (372)
64 4912 (2)
65 9
66 326 (46)
67 70
68 10945 (265)
69 50
70 9
71 7 (1)
72 19
73 0
74 1
---------------

Total 1370239 (-627)
[/code]

Well, I guess I'll stick with the box for now, for the benefit of all the poor IE6 users. :lol:

[code]
Bits Exponents (02/23/2004)
58 111300 (-10617)
59 182811 (-41615)
60 842419 (44634)
61 101393 (126)
62 97420 (5103)
63 16716 (537)
64 5002 (90)
65 225 (216)
66 358 (32)
67 70
68 11221 (276)
69 50
70 9
71 7
72 19
73 0
74 1
---------------

Total 1369021 (-1218)
[/code]

[code]
Bits Exponents (03/01/2004)
58 82450 (-28850)
59 140696 (-42115)
60 905446 (63027)
61 101688 (295)
62 102392 (4972)
63 17047 (331)
64 5080 (78)
65 326 (101)
66 358
67 68 (-2)
68 11475 (254)
69 51 (1)
70 10 (1)
71 7
72 19
73 0
74 1
---------------

Total 1367114 (-1907)
[/code]

[code]
Bits Exponents (03/08/2004)
58 74866 (-7584)
59 132625 (-8071)
60 905337 (-109)
61 114215 (12527)
62 104183 (1791)
63 17515 (468)
64 5046 (-34)
65 476 (150)
66 358
67 68
68 11668 (193)
69 51
70 10
71 7
72 19
73 0
74 1
---------------

Total 1366445 (-669)
[/code]

Exponents above 25M from nofactor.txt 16/3/2004
[CODE]Bits Exponents Change
58 73589 -1277
59 98544 -34081
60 925927 20590
61 118477 4262
62 112313 8130
63 18306 791
64 5000 -46
65 651 175
66 357 -1
67 206 138
68 11939 271
69 50 -1
70 9 -1
71 8 1
72 20 1
73 0 0
74 1 0
Total 1365397 -1048[/CODE]

[code]
Bits Exponents (3/26/2004)
58 70658 (-2931)
59 89194 (-9350)
60 897777 (-28150)
61 154867 (36390)
62 113717 (1404)
63 18781 (475)
64 4855 (-145)
65 823 (172)
66 357
67 924 (718)
68 12217 (278)
69 50
70 9
71 8
72 20
73 0
74 1
---------------

Total 1364258 (-1139)
[/code]

[code]
Bits Exponents (4/11/2004)
58 59142 (-11516)
59 78180 (-11014)
60 886157 (-11620)
61 151665 (-3202)
62 146075 (32358)
63 19281 (500)
64 5063 (208)
65 1268 (445)
66 380 (23)
67 2786 (1862)
68 12582 (365)
69 50
70 9
71 7 (-1)
72 21 (1)
73 0
74 1
---------------

Total 1362667 (-1591)
[/code]

A little while ago, 1997rj7 pointed out that I had a range with numbers still in the 58 bits range. Good news there, I should have everything to 60 bits in about two weeks. From there I can finish taking the range to 63 bits. After that, who knows? :showoff: :showoff:

[code]
Bits Exponents (04/20/2004)
58 58671 (-471)
59 72811 (-5369)
60 852108 (-34049)
61 183067 (31402)
62 150633 (4558)
63 19603 (322)
64 5031 (-32)
65 1700 (432)
66 357 (-23)
67 4556 (1770)
68 12949 (367)
69 50
70 10 (1)
71 7
72 21
73 0
74 1
---------------

Total 1361575 (-1092)
[/code]

Did anyone notice that so far this year, LMH has eliminated 15,054 exponents from the pool of potential Mersenne primes (not counting the ones that haven't been turned in yet)? Let's keep up the good work, everybody.

:banana: :banana: :banana: :banana: :banana:

ThomRuley