¿Si una computadora ha estado buscando, por ejemplo, un número primo realmente grande durante décadas, ¿cómo lo actualizan? ¿Paran el cálculo o...

51st Known Mersenne Prime Discovered

GIMPS Discovers Largest Known Prime Number: 2 82,589,933 -1 BLOWING ROCK, NC, December 21, 2018 -- The Great Internet Mersenne Prime Search (GIMPS) has discovered the largest known prime number, 2 82,589,933 -1, having 24,862,048 digits . A computer volunteered by Patrick Laroche made the find on December 7, 2018. Patrick is one of thousands of volunteers using free GIMPS software available at www.mersenne.org/download/ . The new prime number, also known as M82589933, is calculated by multiplying together 82,589,933 twos, and then subtracting one. It is more than one and a half million digits larger than the previous record prime number , in a special class of extremely rare prime numbers known as Mersenne primes. It is only the 51st known Mersenne prime ever discovered, each increasingly more difficult to find. Mersenne primes were named for the French monk Marin Mersenne , who studied these numbers more than 350 years ago. GIMPS, founded in 1996, has discovered the last 17 Mersenne primes. Volunteers download a free program to search for these primes, with a cash award offered to anyone lucky enough to find a new prime. Prof. Chris Caldwell maintains an authoritative web site on the largest known primes , and has an excellent history of Mersenne primes . A Lucky Find in a Lucky Streak Patrick Laroche is a 35 year old I.T. professional living in Ocala, Florida. For many years, Patrick had used GIMPS software as a free "stress test" for his computer builds. Recently, he started prime hunting on his media server to "give back" to the project. After less than 4 months and on just his fourth try, he discovered the new prime number. By way of comparison, some GIMPS participants have searched for more than 20 years with tens of thousands of attempts but no success. Thus proving that even the "little guy" can compete against those with lots of computing resources. GIMPS has also been extremely lucky over the last 15 years. This is GIMPS' 12th prime discovery between 2 20000000 -1 and 2 85000000 -1, triple the expected number of new primes. One reason to search for new primes is to match actual results with expected results. This anomaly is not necessarily evidence that existing theories on the distribution of Mersenne primes is incorrect. However, if the trend continues it may be worth further investigation. Details on the Discovery and Verification The primality proof took twelve days of non-stop computing on a machine with an Intel i5-4590T CPU. To prove there were no errors in the prime discovery process, the new prime was independently verified using three different programs on three different hardware configurations. Andreas Höglund verified the prime using CUDALucas running on a NVidia V100 GPU in 21 hours. Andreas Höglund also verified the prime using Mlucas running on 16 cores of an Amazon AWS instance in 72 hours. Aaron Blosser also verified it using Prime95 on an Intel 7700K processor in 6 days, 8 hours

Taking checkpoints in batch and BMP programs

You can take checkpoints in batch and BMP programs. Checkpoints are important for recovery and for integrity. Taking checkpoints in batch and BMP programs is important for two reasons: Recovery: Checkpoints establish places in your program from which your program could be restarted, in the event of a program or system failure. If your program abnormally terminates after issuing a checkpoint request, database changes will be backed out to the point at which the checkpoint request was issued. Integrity: Checkpoints also commit the changes that your program has made to the database. In addition to providing places from which to restart your program and committing database changes, issuing checkpoint calls in a BMP program or in a program participating in IMS™ data sharing releases database segments for use by other programs. When a batch or BMP program issues a checkpoint request, IMS writes a record containing a checkpoint ID to the IMS system log. When your application program reaches a point during its execution where you want to make sure that all changes made to that point have been physically entered in the database, issue a checkpoint request. If some condition causes your program to fail before its execution is complete, the database must be restored to its original state. The changes made to the database must be backed out so that the database is not left in a partially updated condition for access by other application programs. If your program runs a long time, you can reduce the number of changes that must be backed out by taking checkpoints in your program. Then, if your program terminates abnormally, only the database updates that occurred after the checkpoint must be backed out. You can also restart the program from the point at which you issued the checkpoint request, instead of having to restart it from the beginning. Issuing a checkpoint call cancels your position in the database. Issue a checkpoint call just before issuing a Get Unique call, which reestablishes your position in the database record after the checkpoint is taken. Types of checkpoints The two types of checkpoint calls are basic and symbolic. Both types commit your program's changes to the database and establish places from which your program can be restarted: Batch and BMP programs can issue basic checkpoint calls using the CHKP call. When you use basic checkpoint calls, you must provide the code for restarting the program after an abnormal termination. Batch and BMP programs can also issue symbolic checkpoint calls. You can issue a symbolic checkpoint call by using the CHKP call. Like the basic checkpoint call, the symbolic checkpoint call commits changes to the database and establishes places from which the program can be restarted. In addition, the symbolic checkpoint call: Works with the Extended Restart call to simplify program restart and recovery. Lets you specify as many as seven data areas in the program to be checkpointed. When you restart the program, the r