From Newsgroup: sci.logic

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then

H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

Python <python@invalid.org> writes:

Olcott (annotated):

If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running

[comment: as D halts, the simulation is faulty, Pr. Sipser has been
fooled by Olcott shell game confusion "pretending to simulate" and
"correctly simulate"]

unless aborted then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.

I don't think that is the shell game. PO really /has/ an H (it's
trivial to do for this one case) that correctly determines that P(P)
*would* never stop running *unless* aborted. He knows and accepts that
P(P) actually does stop.

I have clarified my words in the intervening years
and now fully addressed the persistent objection.

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

DD correctly simulated by HHH cannot possibly reach its
own "return" instruction final halt state thus is correctly
rejected as non-halting.

This is not actually contradicted by the fact that the
directly executed DD() does halt because directly
executed Turing machines are not actually in the domain
of any Turing machine based decider.

Even though most proofs such as Linz state that the
decider must report on the behavior of the directly
executed machine on the basis of the proxy of the
machine description this machine description it not
always a perfect proxy as I have shown.

When it is not a perfect proxy then the behavior of
the directly executed machine is over-ruled and superseded
by the behavior specified by the input finite string.

Turing machine deciders are required to compute the
mapping from their inputs. They can safely ignore
non-inputs such as direct executions.

https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

*Linz definition of the -n machine*
q0 WM reo* -nq0 WM WM reo* -nreR,
if M applied to WM halts, and
q0 WM reo* -nq0 WM WM reo* -n y1 qn y2,
if M applied to WM does not halt.

When -n is applied to its own machine description WM
it is required to report on the behavior of its own
direct execution: M applied to WM.

No Turing machine H can ever directly report on the
behavior of any directly executed Turing machine D.
Instead they use the proxy of the finite string
machine description.

The ultimate measure that Turing machine deciders
must use is the behavior specified by their input.

The behavior of DD simulated by HHH is the behavior
specified by the input to HHH(DD). The behavior of
the direct execution of DD() is not and cannot be
an input thus is irrelevant.
--
Copyright 2024 Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 7/25/25 9:25 PM, olcott wrote:

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
-a-a-a If simulating halt decider H correctly simulates its
-a-a-a input D until H correctly determines that its simulated D
-a-a-a would never stop running unless aborted then

-a-a-a H can abort its simulation of D and correctly report that D
-a-a-a specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

Python <python@invalid.org> writes:

Olcott (annotated):

-a-a If simulating halt decider H correctly simulates its input D until H >>> -a-a correctly determines that its simulated D would never stop running

-a-a [comment: as D halts, the simulation is faulty, Pr. Sipser has been >>> -a-a-a fooled by Olcott shell game confusion "pretending to simulate" and >>> -a-a-a "correctly simulate"]

-a-a unless aborted then H can abort its simulation of D and correctly
-a-a report that D specifies a non-halting sequence of configurations.

I don't think that is the shell game.-a PO really /has/ an H (it's
trivial to do for this one case) that correctly determines that P(P)
*would* never stop running *unless* aborted.-a He knows and accepts that
P(P) actually does stop.

I have clarified my words in the intervening years
and now fully addressed the persistent objection.

You mean you admitted that you LIED, but won't use that word.

The problem is you need to change the meaning of words of art, something
you are not allowed to do.

int DD()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a return Halt_Status;
}

DD correctly simulated by HHH cannot possibly reach its
own "return" instruction final halt state thus is correctly
rejected as non-halting.

But since HHH has been specifed (implicitly) by your statement that
Halt7.c has been incuded, or else your whole claim is a category error
as DD is not a program without a defintion of HHH.

This is not actually contradicted by the fact that the
directly executed DD() does halt because directly
executed Turing machines are not actually in the domain
of any Turing machine based decider.

Which is just a LIE.

SOmething you should know if you ever looked at a picture or played
music on your computer, as those are not strings of 1s and 0s which is
the only thing your computer deals with.

Even though most proofs such as Linz state that the
decider must report on the behavior of the directly
executed machine on the basis of the proxy of the
machine description this machine description it not
always a perfect proxy as I have shown.

No, you have shown that you made a bad rule of representation or use of
the rule, and thus the fault is yours.

If the input does not actually fully specify the behavior of the direct execution, then either the input was faulty (and you decided how to make
it) or the representation system was faulty.

Remember, the test of a valid representation system is that you can make
a UTM that uses that representation and reproduce the full behavior of
ANY program.

x86 code is a valid representation, but it does require that ALL the
code be included.

THe problem is you built an input that wasn't a complete representation
of a program, and talk about inputs that are not progras, and thus
commit the category error.

The input for DD must include the code for HHH, which you try to avoid.

When it is not a perfect proxy then the behavior of
the directly executed machine is over-ruled and superseded
by the behavior specified by the input finite string.

And if it is npt a perfect proxy, the error was in the person that made
the proxy, which was you.

Turing machine deciders are required to compute the
mapping from their inputs. They can safely ignore
non-inputs such as direct executions.

But Direct Execution *IS* specified by the proper input.

If you want to add 11 and 12, you can't call add(1, 2), which omitted
part of the numbers.

Sorry, you are just showing your stupidity.

https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

*Linz definition of the -n machine*
q0 WM reo* -nq0 WM WM reo* -nreR,
-a-a if M applied to WM halts, and
q0 WM reo* -nq0 WM WM reo* -n y1 qn y2,
-a-a if M applied to WM does not halt.

When -n is applied to its own machine description WM
it is required to report on the behavior of its own
direct execution: M applied to WM.

Right, something that results in non-computability, so is a flaw in the algorithm.

No Turing machine H can ever directly report on the
behavior of any directly executed Turing machine D.
Instead they use the proxy of the finite string
machine description.

Sure it can. HHH1 does.

You are just proving you are just a liar.

The ultimate measure that Turing machine deciders
must use is the behavior specified by their input.

WHICH IS DEFINED BY THE DIRECT EXECUTION OF THE PROGRAM THE INPUT
REPRESENTS.

The behavior of DD simulated by HHH is the behavior
specified by the input to HHH(DD). The behavior of
the direct execution of DD() is not and cannot be
an input thus is irrelevant.

Nope, that is just an admission that you don't know the meaning of the
words, and thus made yourself into a pathological liar.

When you start with lies, your world is just lies.

--- Synchronet 3.21a-Linux NewsLink 1.2