Liste des Groupes | Revenir à theory |
On 5/23/2025 10:55 PM, Keith Thompson wrote:But the above is not a "program", and thus can not be simulated correctly. To make it one, we need to add the contents of HHH to the program and the input.Ben Bacarisse <ben@bsb.me.uk> writes:Good and correct. You are one of my best reviewers.Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:>On 23/05/2025 19:37, Keith Thompson wrote:>Ben Bacarisse <ben@bsb.me.uk> writes:>Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]And the big picture is that this can be done because false is theHmm. I don't read that the way you do. Did I miss something?
correct halting decision for some halting computations. He has said
this explicitly (as I have posted before) but he has also explained it
in words:
>
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said Sipser
would be interpreting the oft-quoted "Sipser quote". I don't think you've
missed anything particularly.
Maybe it makes less sense out of the context it was posted in. This was
when he was being less obtuse. The computation in question only halts
because it is halted by the decider on which it is built. It is a
halting computation, but according to PO it can reported as not halting
because of what would happen if it were not halted by the decider from
which it is derived.
I think you're misreading it (or, if you prefer, I have yet to be
convinced that I'm misreading it).
>
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
>
Call the "halt decider" H, and the input I. If you perform the
computation specified by I, it never halts. olcott's statement
is that if H correctly determines that I never halts (assume for
now that that's possible), then H can correctly report that I
never halts. This is true, tautological, and uninteresting.
>
There is *another* computation, I-simulated-by-H. This computation
may halt if H decides to halt it. But I-simulated-by-H is not I.
H's alleged job is to determine the halting status of I, not the
halting status of I-simulated-by-H.
>
I think you're saying that H *incorrectly* reports that
I-simulated-by-H never halts. My interpretation is that H
*correctly* reports that I never halts.
>
The above is based only on that isolated statement, without reference
to olcott's other claims. Moving on to the larger context:
>
If a general solution to the halting problem were possible (we
know it isn't), a simulating halt decider could be one possible
way to approach it. It is, I suppose, a tempting idea. You could
imagine a simulator that runs a program one step at a time, and
after each step, reports that it just halted if it has, or performs
some analysis that attempts to determine that it will never halt.
If it's able to make that determination, the simulator can halt
and correctly report that the simulated program never halts.
>
If the program runs on a machine with a finite number of states, thisMost TM's seem to have a finite number of states.
is actually possible; a repeated state implies that the program is
in an infinite loop. The problem is that a Turing machine is not
limited to a finite number of states (including the state of the
tape), and such an analysis is not possible in the general case.
I think olcott thinks it is possible.
>
They have unlimited tape.
_DDD()Subsequent wordings have all been about hiding this. Just prior to this>
wording was the even more explicit claim that non-halting is correct
because of what "would happen if line 15 were commented out". It's
always been about what would be the correct decision were the
computation not what it actually is.
Sure, I have no doubt that olcott has written contradictory things
(to the extent that they're clear enough to be contradictory).
I just don't think he's done is on the case of this specific
statement.
>
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD simulated by HHH according to the semantics of
he x86 language remains in recursive emulation until
stopped.
>I suppose Ben quoted PO saying this, because PO /uses/ it to justify that a>
particular /halting/ computation will never halt,
He may be doing that now, but he used to use this form of words to
justify why non-halting is the correct result for some halting
computations. Obviously, to keep people talking he has had to scramble
to get away from what he has said in the past without repudiating it.
No crank likes admit they were ever wrong.
Agreed.
>
Les messages affichés proviennent d'usenet.