mfaktc: a CUDA program for Mersenne prefactoring

[James Heinrich]

Originally Posted by Dubslow

(Based on bit length and factors of q-1, I'd say it was found in P-1 stage 2.)

Could be either P-1 or TF, but P-1 is more likely. If you knew the correct P-1 bounds, however, it would be 27x less effort to find it via P-1 than TF (from zero). The factor would be found with default P-1 bounds.
http://mersenne-aries.sili.net/expon...tails=42717929

[ckdo]

Originally Posted by Uncwilly

Just as an aside, the calculations in your worktodo balancer for seem off.

Use the source, Luke:

if (preg_match('#^Factor=(|N/A,|[A-F0-9]{32},)([0-9]{4,10}),([0-9]{1,2}),([0-9]{2})$#i', $line, $matches)) {
            @list($all, $aid, $exponent, $tf1, $tf2) = $matches;
            $key = count($GoodAssignmentsLine);
            $GoodAssignmentsLine[$key] = $line;
            $GoodAssignmentsWork[$key] = (($_REQUEST['easyis'] == 'small') ? $exponent : CalcGHzDaysTrialFactor($exponent, $tf1, $tf2));
        }

It adds up the exponents. (And then it gets the hose again.)

[James Heinrich]

Originally Posted by ckdo

It adds up the exponents.

That's what I get for adding features later on and not checking for side effects I've fixed it now.
(The original incarnation of the balancer did not have a variable definition of "easy", it was just the GHz-days effort, so adding it up made perfect sense.)

[chalsall]

Originally Posted by James Heinrich

I happily volunteer my time and PHP expertise to the effort. My own site already parses any and all data from results.txt, so I'm quite familiar with the issues involved.

Incidentally, I also volunteer my services to help rework the reports.

Please let me know what I can do to help in any way; PHP programming is what I've been doing for the last 11 years.

I support the suggestion that James is enabled to help you (George) and Scott with additional development work.

I would also be willing to donate my time to assist James (but without access). While I don't do PHP (except when I have to; and only then under protest -- I'm a Perl guy) I do do Regular Expressions (RegEx) and SQL for a living.

[Prime95]

Originally Posted by chalsall

I support the suggestion that James is enabled to help you (George) and Scott with additional development work.

James and I are working on the details.

[apsen]

Originally Posted by Prime95

That is precisely why you're having trouble. If you submit the "no factor" and "has a factor" together you shouldn't have a problem

What if there're no "no factor lines".

BTW I started doing this after my regular submission were assigned to P-1. From my results page they seem to be at the lowest bit level of an assignment.

What if while reporting "has a factor" result at the lowest bit level of an assignment I swap the lines in manual submission like this:

found 1 factor(s) for M57841799 from 2^71 to 2^72 [mfaktc 0.17-Win apsen barrett79_mul32]
M57841799 has a factor: 2692557022299923757047

Would that work?

If not what would happen if I add false "no factor" line for previously completed bit levels in front. Like:

no factor for M57841799 from 2^70 to 2^71 [mfaktc 0.17-Win apsen 71bit_mul24]
M57841799 has a factor: 2692557022299923757047
found 1 factor(s) for M57841799 from 2^71 to 2^72 [mfaktc 0.17-Win apsen barrett79_mul32]

[Christenson]

This is why I like the idea that each line is a complete, true, and accurate statement, thus:

M57841799 has a factor: 265255702299923757047 [mfaktc 0.18-Win Christenson]
found exactly 1 factor(s) for M57841799 from 2^71 to 2^72 [mfaktc 0.18-Win Christenson]
found at least 1 factor for M57841799 from 2^71 to 2^72 [mfaktc 0.18-Win Christenson]

This way we know if you completed the bit level, what you found, and how you found it, no scrambling of lines from results.txt.

[James Heinrich]

Originally Posted by Prime95

James and I are working on the details.

It looks like I'll be able to help George revise the parsing logic in the near future. Don't expect anything changed today or tomorrow, but if we can collectively decide on a standardized format for the results (by the end of this week, let's say), I'll see if I can get the results parser to understand it all correctly within a few weeks.

[Christenson]

Hey Oliver:

Just noticed an overflow in the class-by-class status reporting....suddenly got a huge number of seconds reported for the time field that had nothing to do with what was happening on my wristwatch. This is on Linux 64, mfaktc-0.17, under xubuntu 10.10. The box has been up for about 4 days, and runing mfaktc for most of that time.

Eric



This hapened

[TheJudger]

Hi Eric,

I know this bug. It doesn't matter how long mfaktc is running (actually I've noticed this rarely while developing with some *very short* runs)

I'll take a look at this.

Oliver

[Uncwilly]

Originally Posted by ckdo

Use the source, Luke:

It adds up the exponents. (And then it gets the hose again.)

Originally Posted by James Heinrich

That's what I get for adding features later on and not checking for side effects I've fixed it now.
(The original incarnation of the balancer did not have a variable definition of "easy", it was just the GHz-days effort, so adding it up made perfect sense.)

It seems that the fix broke the 'easy' definition part. It sorts inverted.