Richard Heathfield <rjh@cpax.org.uk> writes:
On 06/09/2025 14:36, Ben Bacarisse wrote:
<snip>
My point has nothing to do with his (or your) consistency
of use. My aim was to encourage use consistent with all the published
work on the subject.
Naturally you won't find me unco-operative, but it does seem to imply that, >> having redefined "reject" as "decide it doesn't halt", we need a new word
to cover the concept of turning down a program for being ungrammatical or
asyntactical or whatever.
Decision problems are usually stated so that accept/reject is all you
need. In the case of halting one might state that inputs that are
accepted are those that represent halting TM/input pairs.
Everything
else would be rejected. In that context "rejection" would include
inputs that don't represent valid TM/input pairs.
Obviously one could choose to have many reasons for rejecting an input
as not a member of the set being decided, but there's no theoretical advantage in making the decider tell you about them. If, for some
reason, you really want to complicate the theory with these details then
the decider could have several rejecting states, each for a different
reason to reject an input. Or one could switch the model and have the decider signal membership or non-membership by leaving some specific
result on the tape. But none of the these do anything so simplify the theorems or their proofs.
[Sorry for the delay. I'm not really keeping up with all the group. It seems to be an endless re-hash of the same material from decades ago.]
It is not the behavior of some machine somewhere
else that is "represented" by the finite string.
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 1,070 |
Nodes: | 10 (0 / 10) |
Uptime: | 161:05:24 |
Calls: | 13,734 |
Calls today: | 2 |
Files: | 186,966 |
D/L today: |
843 files (303M bytes) |
Messages: | 2,418,725 |