proof errors

[Batalov]

Originally Posted by retina

My conversation with wc:
...
Me: I hate you!

Your conversation with wc sounds very much like the bulk of that famous thread:
"Just to be pedantic, if it's a PROBABLE prime factor then all we know for certain is that we don't actually know the answer"
=
"If the line is not finished (e.g. the human who typed it died in the middle of the line and left it unfi...), then it is not a 'line', so I am not counting it. I am only counting fully factored lines", says wc.

[preda]

Originally Posted by Batalov

Your conversation with wc sounds very much like the bulk of that famous thread:
"Just to be pedantic, if it's a PROBABLE prime factor then all we know for certain is that we don't actually know the answer"
=
"If the line is not finished (e.g. the human who typed it died in the middle of the line and left it unfi...), then it is not a 'line', so I am not counting it. I am only counting fully factored lines", says wc.

There is a simple pragmatic reason for requiring the line-ending, and that is composability of files.

In file A.txt we have:
AAA
BBB
In file B.txt we have:
CCC
DDD

Then one would naturally expect that their concatenation to be
AAA
BBB
CCC
DDD

and not

AAA
BBBCCC
DDD

Also, it is nice to have a way to "append a line" to a text file in a simple way, meaning without having to process the file first.

And one more thing:
If you accept not-newline-terminated lines, then how do you know how many empty lines are there after the final newline in a file? (hah!)

(appending an empty and not-line-terminated line does not, in fact, change the file)

[retina]

Originally Posted by preda

And one more thing:
If you accept not-newline-terminated lines, then how do you know how many empty lines are there after the final newline in a file? (hah!)

Why would I care? I don't care how many blank lines a file has. I just like things to work as expected. If it has a few extra blank lines in places, well so what? It's not like it is some sort of literary work of art or something.

[Aramis Wyler]

Well that's just imprecise, not caring about those lines. Sloppy work, Retina!

[retina]

Originally Posted by Aramis Wyler

Well that's just imprecise, not caring about those lines. Sloppy work, Retina!

Haha, well which do you prefer:

a) Have the program just do-the-right-thing and run the test, or
b) Print an error and do nothing for a few days until you discover it isn't running (because of OCDing it to the extreme)?

Never let perfection get in the way of actually doing things.

[Viliam Furik]

Originally Posted by retina

Haha, well which do you prefer:

a) Have the program just do-the-right-thing and run the test, or
b) Print an error and do nothing for a few days until you discover it isn't running (because of OCDing it to the extreme)?

Never let perfection get in the way of actually doing things.

[kriesel]

Another way of thinking about it is the more tolerant of human error the program is, the more likely the program is to find the next probable prime Mersenne, rather than sit idle and frustrate the user, possibly to the point of choosing to run something else, or run it less and something else more.
The program is good and actively maintained. It doesn't seem to me it ought be necessary to choose between it leaving a gpu idle or kludging it with a batch wrapper.

Uncompromising reliability and performance in the ftt is good. Uncompromising demands upon the user behavior not so much. (No record terminator after the last entry? NO SOUP FOR YOU!)

[preda]

Originally Posted by kriesel

Another way of thinking about it is the more tolerant of human error the program is, the more likely the program is to find the next probable prime Mersenne, rather than sit idle and frustrate the user, possibly to the point of choosing to run something else, or run it less and something else more.
The program is good and actively maintained. It doesn't seem to me it ought be necessary to choose between it leaving a gpu idle or kludging it with a batch wrapper.

Uncompromising reliability and performance in the ftt is good. Uncompromising demands upon the user behavior not so much. (No record terminator after the last entry? NO SOUP FOR YOU!)

Well I did explain the reason for that requirement: new work lines are added by *appending* them to the worktodo.txt file. If the worktodo.txt is not terminated with a newline, the append produces trash.

[axn]

Originally Posted by preda

Well I did explain the reason for that requirement: new work lines are added by *appending* them to the worktodo.txt file. If the worktodo.txt is not terminated with a newline, the append produces trash.

How difficult/complex will it be to rewrite the file handling logics to handle the "missing end-of-line at the end-of-file" condition?

[preda]

Originally Posted by axn

How difficult/complex will it be to rewrite the file handling logics to handle the "missing end-of-line at the end-of-file" condition?

I don't know, probably not trivial due to the need to do the whole dance: write to a new temporary file, rename worktodo to .bak, rename to temp to worktodo. Plus all the traps along the way due to different "newline" between OSes, etc.

Surely somebody will be unhappy about the way that would turn out if I were to do it.

OTOH maybe it's a good sign that we spend so much time discussing the proper way to help the user type the newline that ends the line.. Nothing more important left to do I guess.

[kriesel]

Originally Posted by preda

maybe it's a good sign that we spend so much time discussing the proper way to help the user type the newline that ends the line. Nothing more important left to do I guess.

It's unclear whether your response indicates acceptance of user interest in gpuowl continuing on despite exceptions, or resistance to it. The interest in your program giving up less readily is a sign of how valued your program is, and the users' wish for it to be more reliable and less brittle. It's an area where sustained throughput can be improved despite fallible humans being involved. George has already indicated that optimization of fft speed is near an end. (Excepting nxSP and other possible future adaptation to quirks of specific hardware I suppose. The possibility of accomplishing TF progress with initial PRP iterations as you have for P-1 seems slight, since TF is mod factor, not mod Mp like P-1 and primality tests are.)

The newline termination requirement was applied also to gpuowl's config.txt, which is not normally subject to programs appending content, like more work entries to worktodo.

more than two thirds of code written for systems is devoted to properly detecting and handling exceptions.

https://users.ece.cmu.edu/~koopman/des_s99/exceptions/

As I recall, no other GIMPS application requires the last record of a configuration file or worktodo file to end in a newline, refusing to run in the case of eof not being immediately preceded by newline. Checking now:
Not CUDALucas v2.06beta's CUDALucas.ini or worktodo.txt;
not CUDAPm1 v0.21's or V0.20's cudapm1.ini or worktodo.txt;
not mfaktc v0.21's mfaktc.ini or worktodo.txt;
not mfakto v0.15pre6's mfakto.ini or worktodo.txt;
not mlucas v17.0's worktodo.ini;
not prime95 v30.3b6's local.txt, prime.txt, or worktodo.txt.
(I haven't specifically checked for the issue in CUDALucas or CUDAPm1 fft or threads files, or mlucas .cfg, but those are program generated. Presumably program input is compatible with program output. I've not encountered issues with eol/eof incompatibility, in creating dozens of installations of each.)

Prime95 generally continues with the next work to do if it rejects a worker's worktodo line as invalid. Gpuowl does not.

CUDALucas tries different fft lengths to continue making progress on a worktodo line despite a detected error. Gpuowl does not.

These are valued and useful features. Their incorporation in gpuowl would be useful.
One can work around their absence, and other stability issues, somewhat, such as by batch scripting, multiple instances, etc. at the costs of more user effort, longer latency, or occasional memory issues.

Handling these two exceptions in gpuowl,
worktodo or config line not terminated how Preda would prefer, and
error occurred during performance of first worktodo line,
would make gpuowl's continuing productive execution much more robust than it now is.
Some of the code to adjust to add OS-appropriate record terminator already exists in the handling of a worktodo line completed.
It is likely that most of the client management software have already dealt with the case of worktodo eof not immediately preceded by newline.