M(10^9) to M(2^32) range factored to 2^64

[James Heinrich]

After 962 days of effort, the entire range of 1000M to 4294M (more accurately M(10⁹) to M(2³²-1), or M1000000007 to M4294967291) has been trial-factored to (at least) 2⁶⁴.

• Exponents in range: 152,432,687
• Factored exponents: 75,537,088
• Factors found: 81,394,233
• Estimated effort expended: 124,652 GHz-days

http://www.mersenne.ca/graphs/factor_bits/

Thanks to those who helped the effort.

[retina]

Originally Posted by James Heinrich

... more accurately M(10⁹) to M(10³²-1) ...

Ermm, that is one very large range.

[NBtarheel_33]

Now that we have a more robust server, perhaps we should extend the GIMPS database to include these exponents, if only to provide a unified repository for data on Mersenne numbers. (LL tests on such numbers, of course, are likely decades - probably centuries - in the future.)

[James Heinrich]

Originally Posted by retina

Ermm, that is one very large range.

Oops... fixed.

Originally Posted by NBtarheel_33

Now that we have a more robust server, perhaps we should extend the GIMPS database to include these exponents

My data is freely available should George decide to do so. Currently it would be ~5GB of data, but of course hundreds of millions of new rows. I wouldn't be surprised if it would take a fair bit of rewriting code that expects no exponent can ever be >= 1000M. There's also the possibility that something in the code might freak out with exponents > 2³¹ (signed int).

[TheMawn]

Congratulations.

I think it would be neat to incorporate these results into the new-and-improved GIMPS server also.

[petrw1]

So.......now what?
As is where are your resources heading for now?

I suspect GPU72 may very welcome them.

[James Heinrich]

Don't worry, Chris already staked a claim on them for GPU72

[Mark Rose]

Originally Posted by James Heinrich

There's also the possibility that something in the code might freak out with exponents > 2³¹ (signed int).

If it's the 32 bit version of PHP, ints are limited to [-2^31,2^31-1]. That's usually easily fixed by using the 64 bit version, but there may also be limitations on the database fields, etc.

[James Heinrich]

Originally Posted by Mark Rose

If it's the 32 bit version of PHP, ints are limited to [-2^31,2^31-1]. That's usually easily fixed by using the 64 bit version

Remembering, of course, that the "64-bit" version of PHP on Windows still uses 32-bit ints...
(Rumored to maybe potentially might be fixed in PHP v6, but not before then.)

[Madpoo]

Originally Posted by James Heinrich

My data is freely available should George decide to do so. Currently it would be ~5GB of data, but of course hundreds of millions of new rows. I wouldn't be surprised if it would take a fair bit of rewriting code that expects no exponent can ever be >= 1000M. There's also the possibility that something in the code might freak out with exponents > 2³¹ (signed int).

A good start would be to set it up as a new table at first to avoid issues with existing code.

Factors themselves are stored as text... no worries there (as long as it's not more than 200 digits).

Exponents are stored as int which in SQL will be fine up to 2,147,483,647 (2^31-1), but beyond that we'd have to change it to bigint (2^63-1). As far as SQL goes, for the most part SQL will cast from int to bigint automagically. Problem is, the exponent shows up all over the DB and just one place where it gets missed would break things.

I hadn't thought about the PHP side of things. it's 64-bit, but James raises a good point. If PHP can't handle larger int, then workarounds would be needed. I'd imagine it'd have to accept it as text with some data validation, then every time it interfaces with SQL it can still insert the PHP variable with the "text" value of the exponent, but that's kind of a pain. Especially if it meant reworking old code and verifying a bunch of things.

You could cheat it by using negative ints but it's definitely a cheat and still complicated. If you're doing that you might as well do something that lets you get above 2^32 anyway.

What a horrible PHP mess... that ints are different based on the underlying OS. Yuck.

[Mark Rose]

Originally Posted by Madpoo

What a horrible PHP mess... that ints are different based on the underlying OS. Yuck.

I think it's because:

1. PHP uses longs for its ints
2. Most operating systems use the processor native size for longs, thus a long is 64 bits on a 64 bit architecture, but Microsoft did its own thing, and kept a long as 32 bits