[QUOTE=Madpoo;479222]It sounds like whatever program generated that output decided to generate an extra line of useless text.[/QUOTE]
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?

[QUOTE=Madpoo;479222]What were your expectations? The manual results will parse each line as one result for one test (it ignores the date stamp lines).[/QUOTE]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=Madpoo;479222]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? :smile: It sounds like whatever program generated that output decided to generate an extra line of useless text. Oh well.[/QUOTE]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.

[QUOTE=VictordeHolland;479237]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?[/QUOTE]Please don't change anything, keep submitting your results as you always have, including those lines.

[QUOTE=James Heinrich;479268]but I have now reverted the change and will investigate further how to implement it better.[/QUOTE]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.

[QUOTE=James Heinrich;479283]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.[/QUOTE]

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.

[QUOTE=Madpoo;479303]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.[/QUOTE]

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).

[QUOTE=VictordeHolland;479237]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?[/QUOTE]

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 [URL]https://www.mersenne.org/report_exponent/?exp_lo=77232917&exp_hi=&full=1[/URL] for an example. Although that example did not have a factor., some people find it useful or interesting to search for additional factors. See [URL]http://www.mersenne.ca/manyfactors.php[/URL]

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

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[/CODE]

[QUOTE=kruoli;479321]When submitting a factor in the result form of mersenne.org, it gives: "Undefined variable: mfaktco"[/QUOTE]Thanks, fixed.

[QUOTE=Madpoo;479303]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.[/QUOTE]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.

[QUOTE=James Heinrich;479337]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.[/QUOTE]

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. :smile: Too late now. LOL

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*