SievePrimes is too big for the current assignment

[mattmill30]

I'm entitled to run the TF out of curiosity if I wish.

I'm reporting a bug, which Oliver may wish to investigate.

I've realised the error resulted from stages=0 having been set, so rather than performing ^67-^68 mfakto was performing ^67-^71, for which the checksum was invalid.

Really the software needs to either report that the checkpoint is for a different bit range, or simply ignore the checkpoint because it's not relevant. The main issue with the present functionality is multiple instances of mfakto can't be run on different bit levels of the same exponent, because the checkpoints are changed to .bad-<checksum>.

Ideally the software should check for a bit-range relevant checkpoint and if none can be found then report whether a checkpoint exists for a different bit range, so it's clear when the software has made every attempt to locate a bit-level relevant checkpoint and has ultimately ignored all checkpoints for that exponent.

[kladner]

Originally Posted by mattmill30

I'm entitled to run the TF out of curiosity if I wish.

I'm reporting a bug, which Oliver may wish to investigate.

.....

You are indeed entitled to run whatever you wish. Likewise, Oliver is entitled to set limits on what he will devote coding effort to.

Remember what the aim of the project is: finding primes. Finding a single factor fulfills that aim by rejecting a candidate. Complete factoring is a sideline which some folks pursue. It does not advance the core purpose of the project.

[mattmill30]

Hopefully the issue that I'm reporting, which affects the functionality of the software for all exponents, won't be overshadowed by a debate over my decision to test a particular exponent.

The issue prevents multiple mfakto instances with SieveOnGPU=0 set from testing different bit-levels of the same exponent, which is useful for fully utilising a chipset GPU without experiencing the console GUI performance hit.

[retina]

Originally Posted by kladner

... the project ...

I'm sure everyone has a different idea about what their particular "project" is. In fact there are multiple projects that run concurrently that are supported by this board.

[TheJudger]

Originally Posted by mattmill30

M106033.ckp.bad-548CDAF8:
106033 67 68 4620 mfakto 0.15pre6-Win: 1815 0 C6551A27
returned
'Cannot use checkpoint file "M106033.ckp": Content "106033 67 68 4620 mfakto 0.15
pre6-Win: 1815 0 C6551A27
" does not match expected "106033 67 71 4620 ".
Renamed bad checkpoint file "M106033.ckp" to "M106033.ckp.bad-548CDAF8"'

Originally Posted by mattmill30

Really the software needs to either report that the checkpoint is for a different bit range, or simply ignore the checkpoint because it's not relevant. The main issue with the present functionality is multiple instances of mfakto can't be run on different bit levels of the same exponent, because the checkpoints are changed to .bad-<checksum>.

Actually mfakto did what you requested and instead of deleting the checkpoint file (mfaktc would do this) it renamed it thus it can write a valid checkpoint file.
About multiple instances on the same exponent... mfaktc and mfakto can do this but you just need to start them in different directories (which is recommended even if you run on different exponents for mfaktc)

Oliver

P.S. I'm not a fan of automagic software actually I try to KISS.

[kladner]

Originally Posted by retina

I'm sure everyone has a different idea about what their particular "project" is. In fact there are multiple projects that run concurrently that are supported by this board.

True dat. However, the core mission is still stated as involving Mersenne Primes. Clearly, this is related to many other mathematical interests, which are amply represented. However, also, as with other kinds of participation, programming is purely voluntary. (And I trust the author's opinion as to what is necessary.)

[GP2]

Originally Posted by mattmill30

I'm entitled to run the TF out of curiosity if I wish.

You are indeed.

But what people are trying to tell you is that all the small exponents like these have been scanned and combed through so thoroughly (using a couple of thousand ECM "curves") that the odds of finding some still-undiscovered factor as small as 67 bits are less than the odds of winning a multi-million dollar Powerball jackpot. The smallest factors are almost certainly at least 95 bits, probably considerably more.

Given this reality, the author of the program will most likely greet your bug report with a shrug. You won't really accomplish anything by doing TF on these except contributing to global warming.

PS, the way ECM works is like taking shots in the dark. Each factor is like a target that you're trying to hit, but can't see. Some targets might be near (small factors), but most are pretty far (larger factors). You're blindfolded and you have a laser pointer, and you swivel around and aim in some random direction and fire the laser. If you repeat that hundreds or thousands of times without hitting any targets (each time firing in a different randomly chosen direction), then after a while you can be pretty sure that you've eliminated the possibility of any targets being nearby, although you can only be 99.99999999...% sure and never exactly 100%.

You might take X number of shots and say, OK, I'm pretty sure there are no targets within 10 feet. Then you take Y more shots and say, now I'm pretty sure there are no targets within 100 feet. There is a formula that lets you quantify this mathematically in a precise way. On the other hand, faraway targets might still be out there, they're so far away that they look tiny and you either need a really lucky shot to hit one or you need to take many, many shots and hope to get lucky once. However if you're very unlucky, the nearest target might be hundreds of miles away or even millions of miles away, completely out of range in any realistic scenario. There's no way to know in advance.

By contrast, TF is like walking blindfolded and pacing all over every square inch of some terrain. If a target exists, you'll bump into it. So if you don't bump into anything, you can be 100% sure that no targets (factors) exist on the territory you've walked over. The catch is, the amount of ground you can cover by walking is much smaller than the range of a laser beam. And every time you increase your TF limit by 1 bit, you double the amount of terrain you have to walk over, so at some point it just gets impractical to continue.

[Mark Rose]

So ECM uses lasers... that sounds like fun!

[LaurV]

Originally Posted by mattmill30

I'm entitled to run the TF out of curiosity if I wish.
I'm reporting a bug, which Oliver may wish to investigate.

Indeed you are entitled to use your hardware as you like. Your money, your electricity, etc. This may have a very good didactic purpose (many of us did it in our beginnings, TF is so easy to implement). But Oliver better not waste his time. The program is done and optimized for higher exponents. If you really wish to TF so low expos, there are dedicated/third party versions of mfaktc which can TF from exponents larger that 2000 and up. They are still doing CPU sieving (at least those I have), therefore are slower than the actual GPU-sieving beast, but they are still running circles around CPU TF, and (@Curtis) they are tested, bcp, me, and many others, found hundreds factors in 2k..100k..1M range.

But, as other people said, unless you have a new algorithm, or you look for fake credits, TF in this range is futile. I say fake credits because you can report "no factor to 65" without doing any work, for all exponents in the ECM range, get millions of credit, and still be right with a very high probability. So much ECM has been done...

[mattmill30]

Originally Posted by mattmill30

The issue prevents multiple mfakto instances with SieveOnGPU=0 set from testing different bit-levels of the same exponent, which is useful for fully utilising a chipset GPU without experiencing the console GUI performance hit.

Originally Posted by TheJudger

Actually mfakto did what you requested and instead of deleting the checkpoint file (mfaktc would do this) it renamed it thus it can write a valid checkpoint file.
About multiple instances on the same exponent... mfaktc and mfakto can do this but you just need to start them in different directories (which is recommended even if you run on different exponents for mfaktc)

What I'm describing for example is the ability to load different bit-level checkpoints for a single exponent simultaneously in multiple instances whilst SieveOnGPU=0. e.g.

$ mfakto.exe -tf 156066943 68 69
$ mfakto.exe -tf 156066943 69 70

Originally Posted by mattmill30

Really the software needs to either report that the checkpoint is for a different bit range, or simply ignore the checkpoint because it's not relevant. The main issue with the present functionality is multiple instances of mfakto can't be run on different bit levels of the same exponent, because the checkpoints are changed to .bad-<checksum>.

Ideally the software should check for a bit-range relevant checkpoint and if none can be found then report whether a checkpoint exists for a different bit range, so it's clear when the software has made every attempt to locate a bit-level relevant checkpoint and has ultimately ignored all checkpoints for that exponent.

Originally Posted by TheJudger

P.S. I'm not a fan of automagic software actually I try to KISS.

I'm suggesting that the checkpoint mechanism for mfackt* be changed to support multiple lines within a single exponent checkpoint file, and respond in one of five ways:

1. If one of the lines matches the full bit-range being TF'd and the checksum is valid, the TF continues from the class in the checkpoint;
2. If one of the lines matches the full bit-range being TF'd and the checksum is invalid, the line is hashed-out and the ckp.bu is considered;
3. If one of the lines matches the full bit range being TF'd and the checksum in both ckp and ckp.bu is invalid, both lines are hashed-out and the TF restarts from class 0;
4. If one of the lines partially matches the bit-range being TF'd, the above error is queued whilst the remainder of the checkpoint file is considered, and if no fully matching line is found the error is output; but the lines are not hashed-out;
5. If one of the lines does not fully/partially match the bit range being TF'd, the remainder of the checkpoint file is considered; but the lines are not hashed-out.

[thyw]

Originally Posted by mattmill30

What I'm describing for example is the ability to load different bit-level checkpoints for a single exponent simultaneously in multiple instances whilst SieveOnGPU=0. e.g.

$ mfakto.exe -tf 156066943 68 69
$ mfakto.exe -tf 156066943 69 70

I'm suggesting that the checkpoint mechanism for mfackt* be changed to support multiple lines within a single exponent checkpoint file, and respond in one of five ways:

1. If one of the lines matches the full bit-range being TF'd and the checksum is valid, the TF continues from the class in the checkpoint;
2. If one of the lines matches the full bit-range being TF'd and the checksum is invalid, the line is hashed-out and the ckp.bu is considered;
3. If one of the lines matches the full bit range being TF'd and the checksum in both ckp and ckp.bu is invalid, both lines are hashed-out and the TF restarts from class 0;
4. If one of the lines partially matches the bit-range being TF'd, the above error is queued whilst the remainder of the checkpoint file is considered, and if no fully matching line is found the error is output; but the lines are not hashed-out;
5. If one of the lines does not fully/partially match the bit range being TF'd, the remainder of the checkpoint file is considered; but the lines are not hashed-out.

Do you know about "Stages=" and "StopafterFactor="? Also, if i understand it correctly, you would like to load checkpoints with multiple instances by a "master" client?? So those 5 rules are: already implemented or conflict the idea of an "assigment", since it's two separated (with each own checkpoints), and you want these into 1 checkpoint.
And consider TF as a short job, it's fast and you wouldn't want to hang onto failed savefiles It would be messy.
As far as i know 1 instance can "only" work at one assigment at a time.
Each instance will load it's own checkpoint in the current assigment. So what you want is a way to split then distribute assigments into different folders' (instances) worktodos.
I'm do not know too much about scripting bit it's definitely possible.
//Btw is there any tool to do this? I don't know what misfit or other automatic clients are capable of.

Short:
mfakt* already does some savefile checking afaik.
$ mfakto.exe -tf 156066943 68 69
$ mfakto.exe -tf 156066943 69 70
are TWO different assigments. The first one finishes; writes to results.txt; deletes checkpoint; scans for next assigment, creates checkpoint for the 2nd one... Also if you find a factor in the first one you probably wouldn't want to run the latter one. Also see "StopAfterFactor="