Register FAQ Search Today's Posts Mark Forums Read

2018-02-04, 13:27   #1398
VictordeHolland

"Victor de Hollander"
Aug 2011
the Netherlands

49816 Posts

Quote:
 Originally Posted by Madpoo It sounds like whatever program generated that output decided to generate an extra line of useless text.
If it creates problems with parsing (I haven't noticed this behaviour before), I'd better delete them.

Anybody know how I can stop MFAKTC v0.21 CUDA8.0 from writing the line:
"1 factor in range 2^x to 2^y" to the results.txt?

2018-02-04, 20:55   #1399
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

3×11×97 Posts

Quote:
 Originally Posted by Madpoo What were your expectations? The manual results will parse each line as one result for one test (it ignores the date stamp lines).
Mostly true, but not entirely. For historical reasons, Prime95 output is full of multi-line output like this (factor on one line, summary on the next), and even worse with things like P-1 where it would list the bounds used on one line and then then factor by itself on the next line. ECM is even worse, splitting the details across three lines (curve/stage; sigma/b1/b2; factor). More recent versions of Prime95 have amended the has-a-factor line to include the relevant details on one line (at least for P-1).

Quote:
 Originally Posted by Madpoo The 2nd line is meaningless... "found 1 factor for exponent ###" means nothing on it's own. What's the factor? Why are you telling me this? It sounds like whatever program generated that output decided to generate an extra line of useless text. Oh well.
This output is fairly universal, originally from Prime95 and later copied by mfakt*

I did make a change recently to the manual form to try and fix an issue where submitting a composite factor in a TF range would prevent it recognizing that TF had been completed across that range, but I have now reverted the change and will investigate further how to implement it better.

Last fiddled with by James Heinrich on 2018-02-04 at 20:58

2018-02-04, 20:56   #1400
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

320110 Posts

Quote:
 Originally Posted by VictordeHolland If it creates problems with parsing (I haven't noticed this behaviour before), I'd better delete them. Anybody know how I can stop MFAKTC v0.21 CUDA8.0 from writing the line: "1 factor in range 2^x to 2^y" to the results.txt?
Please don't change anything, keep submitting your results as you always have, including those lines.

2018-02-05, 00:27   #1401
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

3·11·97 Posts

Quote:
 Originally Posted by James Heinrich but I have now reverted the change and will investigate further how to implement it better.
I have updated the manual form to be more precise in what I was trying to accomplish: if a has-a-factor line is submitted where the range was completely tested (not just up to the point where the factor was found) then the bitlevel should be updated on the server (in case someone wants to continue checking for further factors at higher bitlevels). It should no longer give false no-factor-found warnings. Let me know if you run into any problems.

2018-02-05, 04:50   #1402
Serpentine Vermin Jar

Jul 2014

29·113 Posts

Quote:
 Originally Posted by James Heinrich I have updated the manual form to be more precise in what I was trying to accomplish: if a has-a-factor line is submitted where the range was completely tested (not just up to the point where the factor was found) then the bitlevel should be updated on the server (in case someone wants to continue checking for further factors at higher bitlevels). It should no longer give false no-factor-found warnings. Let me know if you run into any problems.
Thanks James. I guess it wasn't entirely useless in that greater context. I thought there was something like an asterisk on the main result line that indicated if factoring in the range continued even after the first factor was found. Maybe that's specific to a certain GPU program though.

2018-02-05, 05:12   #1403
Dubslow

"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

3·29·83 Posts

Quote:
 Originally Posted by Madpoo Thanks James. I guess it wasn't entirely useless in that greater context. I thought there was something like an asterisk on the main result line that indicated if factoring in the range continued even after the first factor was found. Maybe that's specific to a certain GPU program though.
The asterisk indicates the TFing was ceased at the factor -- the range in which the factor exists is incomplete, when the asterisk exists. Otherwise, if the asterisk doesn't exist with the complete bit level result line, then the entire bit level was TFed (and didn't stop at the factor found).

2018-02-05, 05:27   #1404
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

11·433 Posts

Quote:
 Originally Posted by VictordeHolland If it creates problems with parsing (I haven't noticed this behaviour before), I'd better delete them. Anybody know how I can stop MFAKTC v0.21 CUDA8.0 from writing the line: "1 factor in range 2^x to 2^y" to the results.txt?
Please don't try to stop that. It's what communicates to the primenet server that a bit range for an exponent has been fully trial factored. There are many exponents that have recorded factoring efforts by several people. It's how the server limits wasteful duplication of effort. Take a look at https://www.mersenne.org/report_expo...exp_hi=&full=1 for an example. Although that example did not have a factor., some people find it useful or interesting to search for additional factors. See http://www.mersenne.ca/manyfactors.php

However, if you are determined to suppress that line or stop immediately upon finding one factor, see StopAfterFactor in the ini file.

Last fiddled with by kriesel on 2018-02-05 at 05:31

 2018-02-05, 12:45 #1405 kruoli     "Oliver" Sep 2017 Porta Westfalica, DE 3×53 Posts When submitting a factor in the result form of mersenne.org, it gives: Code: Notice: Undefined variable: mfaktco in C:\inetpub\www\manual_result\default.php on line 285 Notice: Undefined variable: mfaktco in C:\inetpub\www\manual_result\default.php on line 286
2018-02-05, 15:25   #1406
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

3·11·97 Posts

Quote:
 Originally Posted by kruoli When submitting a factor in the result form of mersenne.org, it gives: "Undefined variable: mfaktco"
Thanks, fixed.

Quote:
 Originally Posted by Madpoo I thought there was something like an asterisk on the main result line that indicated if factoring in the range continued even after the first factor was found. Maybe that's specific to a certain GPU program though.
As Dubslow said, the asterisk indicates TF was stopped after finding the factor, absence of asterisk implies the bitrange was completed. This applies to mfaktc and mfakto since about 2011. The result line format was discussed on the forum somewhere, but I can't find the thread right now.

2018-02-05, 20:59   #1407
Serpentine Vermin Jar

Jul 2014

29·113 Posts

Quote:
 Originally Posted by James Heinrich As Dubslow said, the asterisk indicates TF was stopped after finding the factor, absence of asterisk implies the bitrange was completed. This applies to mfaktc and mfakto since about 2011. The result line format was discussed on the forum somewhere, but I can't find the thread right now.
Hmm... it's unfortunate that it's not the other way around, since a missing asterisk in any other program probably means it stopped after finding a factor (or the behavior is unknown). Oh well. Too late now. LOL

 2018-02-05, 21:04 #1408 James Heinrich     "James Heinrich" May 2004 ex-Northern Ontario 3×11×97 Posts Ideally perhaps it should have been some flag to say that factoring stopped after the factor, and a different flag to say that the bitlevel was completed (and a lack of either flag would indicate status unknown), but it's not really a big problem since the new result line format was introduced with a certain version of mfaktc and mfakto, and only those programs use that particular result format, and so we can still be certain as to whether the bitlevel was completed or not. TF results from non-mfakt* programs (Prime95, etc) may be ambiguous as to whether the bitlevel was completed or not so we have to assume that it wasn't. These days I don't think it's a big deal since I presume the vast majority of TF is done with mfakt* Last fiddled with by James Heinrich on 2018-02-05 at 21:05

 Similar Threads Thread Thread Starter Forum Replies Last Post ewmayer Lounge 39 2015-05-19 01:08 ewmayer Science & Technology 41 2014-04-16 11:54 cheesehead Soap Box 56 2013-06-29 01:42 cheesehead Soap Box 61 2013-06-11 04:30 Dubslow Programming 19 2012-05-31 17:49

All times are UTC. The time now is 14:05.

Fri Dec 4 14:05:33 UTC 2020 up 1 day, 10:16, 0 users, load averages: 1.85, 2.11, 2.13