Reviewers interested in an honest dialogue will acknowledge these key facts:

399 views
Skip to first unread message

olcott

unread,
Jul 31, 2022, 1:16:00 PMJul 31
to
typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

Key Fact (1) When H is a simulating halt decider that correctly
simulates its input with an x86 emulator, the simulation will never stop
running until H(P,P) aborts its emulation of its input:

(1) Executed H(P,P) simulates its input with an x86 emulator.
(2) Emulated P calls emulated H(P,P) to do this again.
(3) Emulated H(P,P) simulates its input with an x86 emulator.
(4) Emulated P calls emulated H(P,P) to do this again.
(5) Emulated H(P,P) simulates its input with an x86 emulator...

Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
by H cannot possibly reach its own "ret" instruction whether or not H
aborts its simulation.

All those not agreeing with the above Key Facts are either:
(a) Not interested in an honest dialogue or
(b) Have insufficient software engineering technical competence
Both will be ignored.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Mr Flibble

unread,
Jul 31, 2022, 1:18:44 PMJul 31
to
You keep making the same mistake: [Strachey 1965] and associated HP
proofs are not recursive in nature. A simulating halt decider need not
be recursive in nature and I have indeed designed such a decider:

https://github.com/i42output/halting-problem#readme

/Flibble


Dennis Bush

unread,
Jul 31, 2022, 1:41:15 PMJul 31
to
Since the fixed algorithm of H aborts its simulation, we'll call it Ha. Since P calls this fixed Ha, we'll call it Pa.

By the definition of what a halt decider is required to do:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.

It doesn't matter how Ha gets this wrong answer. It only matters that Ha(Pa,Pa)==0 is wrong by definition.


Ha(Pa,Pa)

Richard Damon

unread,
Jul 31, 2022, 1:44:29 PMJul 31
to
On 7/31/22 1:15 PM, olcott wrote:
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> Key Fact (1) When H is a simulating halt decider that correctly
> simulates its input with an x86 emulator, the simulation will never stop
> running until H(P,P) aborts its emulation of its input:
>
> (1) Executed H(P,P)  simulates its   input with an x86 emulator.
> (2) Emulated P calls emulated H(P,P) to do this again.
> (3) Emulated H(P,P)  simulates its   input with an x86 emulator.
> (4) Emulated P calls emulated H(P,P) to do this again.
> (5) Emulated H(P,P)  simulates its   input with an x86 emulator...

This is what happens if H doesn't abort its simulation. If H ever does
abort its simulation, this is NOT what happens.

Note, an H that simulates until it can CORRECTLY determine that its
input is non-halting, will match this pattern, because it will NEVER in
finite time be able to actually correctly prove the input is
non-halting, as ANY pattern that is defined (incorrectly) as
non-halting, if it is seen by H in the simulation, and H stops its
simulation and returns 0, causes the actual program P(P) to Halt.

Since that is the actual meaning of the question H(P,P) if H is actually
a Halt Decider, that proves that H is incorrect to return 0 from H(P,P)
to say that P(P) is non-halting, since it is Halting.

If you want to repeat you LIE that the input to H(P,P) generate a
different sequence of configurations that P(P), please provide the FIRST
configuration in the sequence that is different, and is actually the
result of a CORRECT simulation of the input.

Note, the implication that H(P,P) seeing a call to H(P,P) is "proof"
that its input is non-halting is proved incorrect and invalid, and your
"proof" of this is based on assuming it, and thus falls into the fallacy
of the assumption of the conclusion.

>
> Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
> by H cannot possibly reach its own "ret" instruction whether or not H
> aborts its simulation.

No, that is only true if H doesn't abort its simuation.

If H aborts its simulation, then a correct and complete simulation of
the input will reach the return instruction.

Yes, a correct BUT PARTIAL simulation might not reach the return
instruction, but a PARTIAL simulation, by itself, never proves
non-halting. (It might provide information that can be used to prove
non-hatling, b

Note, H can't do that, because if H aborts its simulation, it does not
do a COMPLETE and correct simulation.

>
> All those not agreeing with the above Key Facts are either:
> (a) Not interested in an honest dialogue or
> (b) Have insufficient software engineering technical competence
> Both will be ignored.
>

Nope, just shows that YOU don't understand what you are saying and that
YOU have insufficient technical competence.

Note, anyone saying they won't talk to people who disagree with them and
their "facts", even though those people are showing WHY those "facts"
are incorrect, is just showing that they are totally ignorant and want
to stay that way.

You are just sealing your reputation as a totally ignorant person with
no grasp of what is real. You seem to have successfully gaslite yourself
into beleiving your own lies and are unable to see your errors.

olcott

unread,
Jul 31, 2022, 1:54:23 PMJul 31
to
So in other words you are asserting that the correctly simulated input
to H(P,P) correctly simulated by H would stop running without H ever
aborting this simulation.

I would say that this would put you in the insufficient software
engineering technical competence category.

Richard Damon

unread,
Jul 31, 2022, 2:02:15 PMJul 31
to
If H is defined to NEVER stop until it can CORRECTLY abort its
simulation, then it will never abort its simulation of P(P), and thus
never return the "correct" answer of 0.

So, you are right, that given THAT defininition of H (which doesn't
match the code you have posted) it is true that the correct and complete
simulation of the input to H(P,P) will never reach the return
instruction, because this H is the Hn that has been previously
described. Note, This H will never return an answer for H(P,P) because
there IS NO correct finite pattern for H to detect to stop its
simulation to return 0.

>
> I would say that this would put you in the insufficient software
> engineering technical competence category.
>

Nope, YOU have the insufficient software engineering technical
competence to know that you need to analyize the program before you and
not an idealized version that behaves differently.

Dennis Bush

unread,
Jul 31, 2022, 2:04:56 PMJul 31
to
I am saying that Ha correctly decides that there is no implementation of the function H that can simulate the function P(P) to a final state. And that is not the question that the halting problem is asking.

Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.

olcott

unread,
Jul 31, 2022, 2:11:44 PMJul 31
to
On 7/31/2022 12:44 PM, Richard Damon wrote:
> On 7/31/22 1:15 PM, olcott wrote:
>> typedef void (*ptr)();
>> int H(ptr p, ptr i); // simulating halt decider
>>
>> void P(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(P, P));
>> }
>>
>> Key Fact (1) When H is a simulating halt decider that correctly
>> simulates its input with an x86 emulator, the simulation will never
>> stop running until H(P,P) aborts its emulation of its input:
>>
>> (1) Executed H(P,P)  simulates its   input with an x86 emulator.
>> (2) Emulated P calls emulated H(P,P) to do this again.
>> (3) Emulated H(P,P)  simulates its   input with an x86 emulator.
>> (4) Emulated P calls emulated H(P,P) to do this again.
>> (5) Emulated H(P,P)  simulates its   input with an x86 emulator...
>
> This is what happens if H doesn't abort its simulation. If H ever does
> abort its simulation, this is NOT what happens.

Good, I agree.

>
> Note, an H that simulates until it can CORRECTLY determine that its
> input is non-halting, will match this pattern, because it will NEVER in
> finite time be able to actually correctly prove the input is
> non-halting, as ANY pattern that is defined (incorrectly) as
> non-halting, if it is seen by H in the simulation, and H stops its
> simulation and returns 0, causes the actual program P(P) to Halt.
>
> Since that is the actual meaning of the question H(P,P) if H is actually
> a Halt Decider, that proves that H is incorrect to return 0 from H(P,P)
> to say that P(P) is non-halting, since it is Halting.
>
> If you want to repeat you LIE that the input to H(P,P) generate a
> different sequence of configurations that P(P), please provide the FIRST
> configuration in the sequence that is different, and is actually the
> result of a CORRECT simulation of the input.
>
> Note, the implication that H(P,P) seeing a call to H(P,P) is "proof"
> that its input is non-halting is proved incorrect and invalid, and your
> "proof" of this is based on assuming it, and thus falls into the fallacy
> of the assumption of the conclusion.
>
>>
>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>> simulated by H cannot possibly reach its own "ret" instruction whether
>> or not H aborts its simulation.
>
> No, that is only true if H doesn't abort its simuation.

So you believe that when H aborts its simulation this causes the
simulated P to reach its "ret" instruction even after it has been
aborted before reaching this instruction?

Unless you reverse your position technically competent reviewers will
understand that you are not a sufficiently technically competent reviewer.

>
> If H aborts its simulation, then a correct and complete simulation of
> the input will reach the return instruction.

If H aborts its simulation of P then the simulated P that is no longer
running will continue several more execution steps and reach its "ret"
instruction even though it has been forced to stop running before ever
reaching the "ret" instruction.

>
> Yes, a correct BUT PARTIAL simulation might not reach the return
> instruction, but a PARTIAL simulation, by itself, never proves
> non-halting. (It might provide information that can be used to prove
> non-hatling, b
>
> Note, H can't do that, because if H aborts its simulation, it does not
> do a COMPLETE and correct simulation.
>
>>
>> All those not agreeing with the above Key Facts are either:
>> (a) Not interested in an honest dialogue or
>> (b) Have insufficient software engineering technical competence
>> Both will be ignored.
>>
>
> Nope, just shows that YOU don't understand what you are saying and that
> YOU have insufficient technical competence.
>
> Note, anyone saying they won't talk to people who disagree with them and
> their "facts", even though those people are showing WHY those "facts"
> are incorrect, is just showing that they are totally ignorant and want
> to stay that way.
>
> You are just sealing your reputation as a totally ignorant person with
> no grasp of what is real. You seem to have successfully gaslite yourself
> into beleiving your own lies and are unable to see your errors.


olcott

unread,
Jul 31, 2022, 2:26:29 PMJul 31
to
Likewise with every other non-halting input such as Infinite_Loop() and
Infinite_Recursion().

void Infinite_Loop()
{
HERE: goto HERE;
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

void Infinite_Recursion(int N)
{
Infinite_Recursion(N);
}

_Infinite_Recursion()
[000010f2](01) 55 push ebp
[000010f3](02) 8bec mov ebp,esp
[000010f5](03) 8b4508 mov eax,[ebp+08]
[000010f8](01) 50 push eax
[000010f9](05) e8f4ffffff call 000010f2
[000010fe](03) 83c404 add esp,+04
[00001101](01) 5d pop ebp
[00001102](01) c3 ret
Size in bytes:(0017) [00001102]

> And that is not the question that the halting problem is asking.
>
> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.

*THIS IS A YES OR NO QUESTION*
So in other words you are asserting that the correctly simulated input
to H(P,P) correctly simulated by H would stop running without H ever
aborting this simulation.

I no that answering YES makes you look utterly foolish and answering NO
has you agreeing with me and you really really hate to do that.
Continuing to dodge this question reaffirms your dishonesty.

olcott

unread,
Jul 31, 2022, 2:28:07 PMJul 31
to
typo corrected
> I [no] know that answering YES makes you look utterly foolish and answering NO

Richard Damon

unread,
Jul 31, 2022, 2:30:22 PMJul 31
to
No, it causes the ACTUAL P, and the correct and COMPLETE simulation of
the input to H(P,P) to reach the return instruction.

You somehow don't seem to understand the difference between a PARTIAL
simulation cause by the simulator aborting its operation, and a COMPLETE
simulation.

Since Halting is defined by the behavior of the ACTUAL MACHINE, (or
equivalently by the correct AND COMPLETE simulation), this is the
behaivior a true Halting Decider must be answering about.

I have agreed that *H* can't get there, but that just proves that H
can't prove the input Halts. Only an IDIOT thinks that hypothetical
machines that aren't part of the problem tell us more about the machine
we are looking at the the actual machine.

H(P,P) is being asked about P(P). (your definition of P proves this).

Halt deciders must ACCEPT (return 0) it the machine being asked about
will halt.

P(P) Halts if H(P,P) returns 0.

Therefore, H(P,P) returning 0 is INCORRECT, as its input represents P(P)
(or you are just being a LIAR) and that halts, so H(P,P) must have
accepted this input to have been correct.

Dennis Bush

unread,
Jul 31, 2022, 2:35:20 PMJul 31
to
I see you're now talking about an H that doesn't abort, so that means H is now Hn and P is now Pn. So lets restate the above to be clear about what you mean:

> So in other words you are asserting that the correctly simulated input
> to Hn(Pn,Pn) correctly simulated by Hn would stop running without Hn ever
> aborting this simulation.

No, it would not stop running because Hn doesn't abort. And because Hn doesn't abort, it can't answer that Pn(Pn) halts and is wrong by virtue of not answering.

Richard Damon

unread,
Jul 31, 2022, 2:37:09 PMJul 31
to
And, since H is claimed to be a Halt Decider, that question is
irrelevent and a Red Herring and a Strawman


>
> I no that answering YES makes you look utterly foolish and answering NO
> has you agreeing with me and you really really hate to do that.
> Continuing to dodge this question reaffirms your dishonesty.
>

Your insistance on getting answers to irrelevent question just proves
that you arent intereseted in the actual truth.

NO ONE has said that *H* can simulate the input to the return
instruction, and you instance in implying that people are saying that
just shows your lack of Honesty.

People don't disagree that H can't simulate to the return instruction,
just that this implies your conclusion. That you don't get this
distinction shows your (lack of) intelegence.

BTW, simple question, Will you stop lying on Usenet?
Answer Yes or No, or you are just using a dishonest dodge.

olcott

unread,
Jul 31, 2022, 2:40:02 PMJul 31
to
There is only a simulated P in the following:

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

So you agree that the input to H(P,P) that is correctly simulated by H
cannot possibly reach the "ret" instruction of this simulated P whether
or not H aborts its simulation or not?

Dennis Bush

unread,
Jul 31, 2022, 2:43:51 PMJul 31
to
Yes, I agree that there is no implementation of the function H that can simulate the function call P(P) to a final state. Which has nothing to do with the requirements of a halt decider.

olcott

unread,
Jul 31, 2022, 2:48:58 PMJul 31
to
OK great we are finally on the same page on one key point.

void Infinite_Loop()
{
HERE: goto HERE;
}

void Infinite_Recursion(int N)
{
Infinite_Recursion(N);
}

Do you understand that every input (*such as the above two examples*) to
a simulating halt decider that would never stop running unless and until
this SHD aborts its simulation is an input that specifies non-halting
behavior?

If NO, then do you understand that it does apply to the above two examples?

Richard Damon

unread,
Jul 31, 2022, 2:59:39 PMJul 31
to
Right, but that doesn;t mean the PROGRAM P(P) doesn't actually have the
ability to exist.

we just need to change main() to

int main() {
Output("Input_Halts = ", H(P,P));
P(P);
Output("P(P) Halted");
}

To make it come into existance.

If this isn't allowed, you system isn't Turing complete and you
"universe" you are defining worthless to talk about the Halting Problem.

>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> So you agree that the input to H(P,P) that is correctly simulated by H
> cannot possibly reach the "ret" instruction of this simulated P whether
> or not H aborts its simulation or not?
>

Yes, "BY H".

But that DOESN'T prove the the input represents a non-halting input,
since P(P) IS the machine represented by the input, and P(P) Halts if
H(P,P) returns 0

If you repeat you claim that the input to H(P,P) does NOT represent P(P)
then you need to explain why you are LYING that P is built by the
requrements of the proof you are claiming to counterdict when it
specifically is calling H(P,P) to ask it about the compuation P(P).

I have NO Problems with you claiming H is a correct POOP decider, if
POOP is based on the simulation as done by H instead of the actual
definiton of Halting which is based on the behavior of the machine the
input represents. That just isn't an interesting claim.

So, will you stop lying on Usenet? (Yes or No)

Mr Flibble

unread,
Jul 31, 2022, 3:12:17 PMJul 31
to
You are wrong to agree with Olcott on that point as a simulating halt
decider needn't be recursive in nature, as I have shown:

https://github.com/i42output/halting-problem#readme

/Flibble

Dennis Bush

unread,
Jul 31, 2022, 3:26:52 PMJul 31
to
There was never disagreement on this.

> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
> void Infinite_Recursion(int N)
> {
> Infinite_Recursion(N);
> }
>
> Do you understand that every input (*such as the above two examples*) to
> a simulating halt decider that would never stop running unless and until
> this SHD aborts its simulation is an input that specifies non-halting
> behavior?

Whether the function H can simulate a particular function call to a final state is unrelated to whether a computations halts, which is what the halting problem is about.

Ha(Infinite_Loop)==0 is correct because Infinite_Loop() does not halt
Ha(Infinite_Recursion,N)==0 is correct because Infinite_Recursion(N) does not halt
Ha(Pa,Pa)==0 is not correct because Pa(Pa) halts.

olcott

unread,
Jul 31, 2022, 8:53:39 PMJul 31
to
In other words you are saying that this is incorrect:
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

Richard Damon

unread,
Jul 31, 2022, 9:07:25 PMJul 31
to
No, just that the "Actual Behvior" is determined by the actual behavior
of the program the input represents, and some "partial simulation done
by H + some questionable logic".

I.E. the actual behavior of the input of H(P,P) is determined by P(P),
since that IS what the input is, not by the partial simulation done by H
and it incorrect logic that simulating the input of H(P,P) to a call to
H(P,P) means the input has infinite recursion.

You STILL haven't even attempted to answer the challange to show the
first point where the correct behavior of the simulation of the innput
to H(P,P) differs from the actual execution of P(P).

You point to the call of H(P,P) inside it, but the CORRECT simulation of
that call goes into H, just as the direct execution does (even if your
system doesn't show that as part of the trace). Saying the call does
something other than what the call actually does just shows that H is
INCORRECT about what its input does.

olcott

unread,
Jul 31, 2022, 9:13:13 PMJul 31
to
Within these halt deciding principles it does:

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

olcott

unread,
Jul 31, 2022, 9:27:02 PMJul 31
to
In other words you do not believe that the correct simulation of an
input necessarily has the exact same sequence of instructions that are
specified by this input, thus you reject the concept of UTM simulation.

Richard Damon

unread,
Jul 31, 2022, 9:29:18 PMJul 31
to
And the ACTUAL BEHAVIOR of the input to H(M,x) is the behavior of M(x).
DEFINITION.

If you disagree, you are admitting that H isn't a Halt Decider, because
you criteria doesn't match the one DEFINED for a Halt Decider.

You STILL Haven't show where you thing the first point of divergance
between the ACTUAL excution of P(P) and the simulation of H(P,P) occurs
and that H is CORRECTLY SIMULATING.

So, that claim is still just one of your blantant lies.

> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)

Right, The Turing Machine, that is the M(x) or P(P) not the simulation
of the input done by the decider.

>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
>

So, all you have done is admit that don't understand what a Halt Decider
does, because you claim it needs to follow a different criteria than
what it must follow.

Note, you "proof" that the input to H(P,P) has a different behavior than
P(P) really is just proving that a Halt Decider can't correctly answer
that problem, not that you get to change the problem, as that just isn't
allowed.

Richard Damon

unread,
Jul 31, 2022, 9:36:28 PMJul 31
to
No. a COMPLETE and correct simulation will recreate the behavior of the
input. The COMPLETE part is important.

You H doesn't do a COMPLETE and correct simulation (at least when it
answers non-hatling) so the behavior of the simulation doesn't show the
behavior of the input.

Note, YOU reject that a definition of what H needs to do is:

H(M,x) accept if UTM(M,x) Halts, and reject if UTM(Mx) will never halt.

since BY DEFINITION the behavior of UTM(M,x) matches M(x), so UTM(P,P)
matches P(P), so the behavior of the input to H(P,P) would be the
behavior of P(P) which you reject as it shows you to be wrong.

Note, one key part is even with a UTM, the actual behavior of the
Program is the defining operation, and the UTM's behavior only a usable
substitute if it matches.

This means if U(M,x) doesn't match M(x) then U is shown to NOT be a UTM.

THis is just another example of you twisting someones words, mostly
because you don't understand anything that people are saying.

It is just one of your forms of lying.

olcott

unread,
Jul 31, 2022, 9:52:48 PMJul 31
to
Yet the execution trace of the provably correct** simulation of the
input to H(P,P) by H proves otherwise.

A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.

The ultimate measure of the behavior of the input to H(P,P) is the
provably correct** simulation of this input by H.

** line-by-line the execution trace of the simulation of the input to
H(P,P) by H exactly matches line-by-line of the x86 source-code of P.

Prior to my very extensive work with simulating halt deciders it seems
that no one ever noticed that these behaviors possible could diverge so
they used what they thought was a good proxy for the actual behavior of
the actual input to H. It turns out that this proxy was imperfect.

It seems to me that the input that was specifically designed to have a
"pathological" relationship to H is the only exception to the rule where
the actual behavior of the actual input diverges from the behavior of
the direct execution of this same input.

olcott

unread,
Jul 31, 2022, 10:00:34 PMJul 31
to
Not at all, as long as the partial simulation correctly matches any
correct infinite behavior pattern then there is no need to wait until
the end of time to see that an infinite loop never halts.

Dennis Bush

unread,
Jul 31, 2022, 10:18:37 PMJul 31
to
Correct but not complete, so H's simulation is not definitive.

> A halt decider must compute the mapping from its inputs to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these inputs.

Which by the definition of what a halt decider is required to compute:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

Is stipulated to be the behavior of X(Y)

> The ultimate measure of the behavior of the input to H(P,P) is the
> provably correct** simulation of this input by H.

FALSE. It is the behavior of the machine that the input represents, i.e. Pa(Pa)

>
> ** line-by-line the execution trace of the simulation of the input to
> H(P,P) by H exactly matches line-by-line of the x86 source-code of P.

The line-by-line execution trace of the simulation of the input to Ha3(N,5) by Ha3 exactly matches line-by-line the source-code of N.

Therefore, according to you, Ha3(N,5)==0 is correct.

Agreed?

>
> Prior to my very extensive work with simulating halt deciders it seems
> that no one ever noticed that these behaviors possible could diverge so
> they used what they thought was a good proxy for the actual behavior of
> the actual input to H. It turns out that this proxy was imperfect.

They don't diverge. You only think they do because you believe that Ha(Pa,Pa) must report the halt status of Pn(Pn).

>
> It seems to me that the input that was specifically designed to have a
> "pathological" relationship to H is the only exception to the rule where
> the actual behavior of the actual input diverges from the behavior of
> the direct execution of this same input.

Nope, it just shows that it is impossible for Ha to be correct about Pa.

Dennis Bush

unread,
Jul 31, 2022, 10:20:02 PMJul 31
to
But it doesn't match an infinite behavior pattern as demonstrated by Pa(Pa) halting, or equivalently the correct and COMPLETE simulation by UTM(Pa,Pa).

Richard Damon

unread,
Jul 31, 2022, 10:30:28 PMJul 31
to
But the pattern is only a CORRECT infinite behavior pattern if the
PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
H(P,P) aborts its simulation.

This is the ERROR you have in your logic.

Try to PROVE that your "rule (3)" is actually correct.

We KNOW it is incorrect, as even you have admitted that P(P) Halts if
H(P,P) returns 0, so H(P,P) returning 0 must be incorrect.

Since the behavior of the input to H(P,P) MUST be the behavior of P(P)
or your P is definie incorrectly, you haven't shown what pattern you
want to match that is actually correct!

Your claimed case of if the simulaton of the input to H(P,P) sees a call
to H(P,P) with no conditionals is an incorrect rule as the simple test
that P(P) Halts if H(P,P) returns 0, so P(P) CAN'T be caught in infinite
recursion.

You claim that they behave differently is disproved by the DEFINITION
specified abort, it is what YOU had P do to ask about P(P).

You also have been unable to point to the FIRST instruction that was
correctly simulated that shows the difference.

The difference happens at the call to H, where the direct exection goes
into H (even if you trace doesn't show it, that it just a bug in your
trace code) and eventually that H returns 0, but the simulation routine
does actually simulate that code but INCORRECTLY assumes a behavior
different than what actually happens. You can decide if that is it doing
an incorrect simulation or just unsound logic on the results of the
simulation.

In either case, your H is proved to be INCORRECT, and the claim that the
input behaves differently than the machine it is a description of proven
incorrect, at least if H is supposed to be a Halt Decider.

Thus, you claim is just WRONG. H(P,P) returning 0 is INCORRECT because
P(P) Halts if H(P,P) returns 0.

Your UNSOUND argument, matching your UNSOUND mind, just doesn't
establish anything.

The right answer that a halt decider deciding on P(P) where H(P,P)
returns 0 IS accept(1), as P(P) Halts, as does a complete and correct
simulation of the input to H(P,P) (even if H doesn't do that since it
aborted it simulation too soon to return the value 0)

It doesn't matter that with a DIFFERENT decider, that you also call H,
but other call things like Hn (since it never aborts) and the P built on
that (which others call Pn because it is based on Hn) will be
non-halting because Pn(Pn) will call Hn(Pn,Pn) which will simulate
Pn(Pn) which will call Hn(Pn,Pn) ... to infinity.

The problem is that the P you are looking at (which others call Pa since
it is based oh the Ha version of your H that does abort) is Pa, and
Pa(Pa) will halt since Ha(Pa,Pa) return 0 (incorrectly) because it
confused Pa with Pn.

The confusion comes because the code for the "C Function" of Pa and Pn
are the same, the difference between the PROGRAM Pa and Pn are which
version of H they are linked with (which should have been given
different names so the code for Pa and Pn would be different).

Note, by the basic software principle of C programming, there CAN'T be
two functions by the same name in a given program, so the Ha variant of
H can NEVER just assume it is seeing a call to Hn, and thus your
"infinite simulation" rule is invalid, as that only works for Hn.

olcott

unread,
Jul 31, 2022, 10:32:39 PMJul 31
to
That is like checking for black dogs in your living room by looking for
white cats in your kitchen.

A halt decider must only examine the sequence of instructions that it
was presented with, not any other sequence.

When H(P,P) correctly simulates its input this input presents the
infinite recursion control flow behavior pattern to H.

If the execution trace of function Y() shows:
(1) Function X() is called twice in sequence from the same machine
address of Y().
(2) With the same arguments to X().
(3) With no control flow instructions between the invocation of Y() and
its call to X().

Then the function call from Y() to X() is infinitely recursive.

Richard Damon

unread,
Jul 31, 2022, 10:44:24 PMJul 31
to
WHERE??

It shows P(P) calling H(P,P).

We KNOW from elsewhere in the trace that H(P,P) will return 0 to main,
thus, H(P,P) MUST return 0 to P or the simulation is actually INCORRECT,
or at least the logic used to extend past the point of simulation to
predict the final behavior is UNSOUND.

>
> A halt decider must compute the mapping from its inputs to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these inputs.

And the actual behavior of the input to H(P,P) is the actual behavior of
the program P(P) or you problem is incorrectly defined, because that is
the call that P makes to ask that question.

Thus since P(P) Halts if H(P,P) returns 0, H(P,P) returning 0 can NOT be
a correct answer. DEFINITION.

>
> The ultimate measure of the behavior of the input to H(P,P) is the
> provably correct** simulation of this input by H.

Nope, H can't actually PROVE any behavior by its PARTIAL simulation of P.

THAT IS A FACT.

It has been pointed out that your H's simulation can't distinguish
between the two programs:

void P1(ptr x) {
H(x, x);
}

and

void P0(ptr x) {
H(x,x);
LOOP: goto LOOP;
}

since the first is PROVABLE Halting if H is a decider, and the second is
PROBABLY non-halting if H is a decider, and both generate identical
traces as far as H is concerned, that PROVES that H doesn't have the
information it needs to prove its answser, and CAN'T get it by its design.

>
> ** line-by-line the execution trace of the simulation of the input to
> H(P,P) by H exactly matches line-by-line of the x86 source-code of P.

Which is insufficent to prove your point.

>
> Prior to my very extensive work with simulating halt deciders it seems
> that no one ever noticed that these behaviors possible could diverge so
> they used what they thought was a good proxy for the actual behavior of
> the actual input to H. It turns out that this proxy was imperfect.
>
> It seems to me that the input that was specifically designed to have a
> "pathological" relationship to H is the only exception to the rule where
> the actual behavior of the actual input diverges from the behavior of
> the direct execution of this same input.
>

Nope, you just don't understand what you are doing. You don't even seem
to understand that very basic aspects of this theory

You seem to have a problem with understanding REQUIRMENTS.

H needs to be able to answer about a MACHINE, and needs to define how to
provide the reprentation of any machine to it.

You have chosen the x86 binary code of the program.

Thus code DOES exactly specify the behavior of the Program, and the
CORRECT and COMPLETE simulation of that input demonstrates it.

The fact that H can't get that result, just shows that the function it
is trying to compute is in fact, not a computable function, which is
what that halting theorem says.

Your "error" you find in the proxy is just proving in a round about
manner, that H can't actually answer the Halting Problem for that input.

Since there seems to be no way to ask H about P(P), it just fails to get
the right answer for that question, and thus can't be a counter example
to the proof.

You failure to understand that just shows you are ignorant in
understanding how logic works.

Mr Flibble

unread,
Jul 31, 2022, 10:45:17 PMJul 31
to
The halting decider of [Strachey 1965] and associated proofs is not
recursive in nature.

/Flibble

Richard Damon

unread,
Jul 31, 2022, 10:47:21 PMJul 31
to
FALSE premises -> UNSOUND LOGIC.

Note, rule (3) might happen to hold in your example case, but it doesn't
hold for the more general case of H that you apply it to.

You are just committing the fallacy of proof by example, show how dumb
you are.

ROOKIE mistake.

Dennis Bush

unread,
Jul 31, 2022, 10:58:32 PMJul 31
to
Then why do you insist that Ha(Pa,Pa) must report the halt status of Pn(Pn)?

On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> H(P,P) is asking would the input that I correctly emulate ever reach its
> "ret" instruction (final state) if I never stopped emulating it?

Bottom line: Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.


>
> When H(P,P) correctly simulates its input this input presents the
> infinite recursion control flow behavior pattern to H.
>
> If the execution trace of function Y() shows:
> (1) Function X() is called twice in sequence from the same machine
> address of Y().
> (2) With the same arguments to X().
> (3) With no control flow instructions between the invocation of Y() and
> its call to X().

And again you're lying by attempting to make your point with a criteria you've implicitly admitted is incorrect by your failure to respond to explanations as to why it is wrong.

olcott

unread,
Jul 31, 2022, 11:46:44 PMJul 31
to
H(P,P) correctly predicts that its correct and complete simulation of
its input would never reach the "ret" instruction of this input.

> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>> H(P,P) is asking would the input that I correctly emulate ever reach its
>> "ret" instruction (final state) if I never stopped emulating it?
>
> Bottom line: Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>
>
>>
>> When H(P,P) correctly simulates its input this input presents the
>> infinite recursion control flow behavior pattern to H.
>>
>> If the execution trace of function Y() shows:
>> (1) Function X() is called twice in sequence from the same machine
>> address of Y().
>> (2) With the same arguments to X().
>> (3) With no control flow instructions between the invocation of Y() and
>> its call to X().
>
> And again you're lying by attempting to make your point with a criteria
> you've implicitly admitted is incorrect by your failure to respond to
> explanations as to why it is wrong.

I never explicitly or implicitly admitted that the following criteria is
incorrect and when I called you out on to provide an time and date stamp
quote of me admitting this you utterly failed because there was no such
quote.

On 7/30/2022 2:37 PM, Dennis Bush wrote:
> On Saturday, July 30, 2022 at 3:29:24 PM UTC-4, olcott wrote:
>> If the execution trace of function Y() shows:
>> (1) Function X() is called twice in sequence from the same machine
>> address of Y().
>> (2) With the same arguments to X().
>> (3) With no control flow instructions between the
>> invocation of Y() and its call to X().
>
> So I see you're back to actively lying about your results by using a
> criteria you've admitted is invalid.

I have never lied and when I called you out on this you had to retract
your words: (I never admitted that the criteria is incorrect and
indeed it is correct, there are never any false positives).

Richard Damon

unread,
Aug 1, 2022, 7:17:58 AMAug 1
to
No, it doesn't.

Simple fact, If H(P,P) aborts its simulation then it doesn't abort its
simulation, thus the "its" part is non-sense. If it aborts, then that
exact same program CAN'T completely simulate.

Also, if H(P,P) returns 0, then it can be shown that THE (and there is
only one) correct and complete simulate reachs the Return instrustion,
as it EXACTLY follows the behavior of P(P) (since that is the definition
of CORRECT), just like P(P) will halt if H(P,P) returns 0.

>
>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>> "ret" instruction (final state) if I never stopped emulating it?
>>
>> Bottom line: Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>
>>
>>>
>>> When H(P,P) correctly simulates its input this input presents the
>>> infinite recursion control flow behavior pattern to H.
>>>
>>> If the execution trace of function Y() shows:
>>> (1) Function X() is called twice in sequence from the same machine
>>> address of Y().
>>> (2) With the same arguments to X().
>>> (3) With no control flow instructions between the invocation of Y() and
>>> its call to X().
>>
>> And again you're lying by attempting to make your point with a
>> criteria you've implicitly admitted is incorrect by your failure to
>> respond to explanations as to why it is wrong.
>
> I never explicitly or implicitly admitted that the following criteria is
> incorrect and when I called you out on to provide an time and date stamp
> quote of me admitting this you utterly failed because there was no such
> quote.

Just shows you don't know what you are talking about.

Yes, you don't explicitly admit that the criteria is incorrect, but when
you state that H(P,P) doesn't look at the behavior of P(P) even though
that is the requirement of the call to H in P, that EXPLICIT statement
says you CAN'T be working on the halting problem because you deny one of
the requrements of the proof. That is an IMPLICT admission of not
working on the problem.

Your statement just proves that you are too ignorant of the meaning of
the words to understand that.

>
> On 7/30/2022 2:37 PM, Dennis Bush wrote:
> > On Saturday, July 30, 2022 at 3:29:24 PM UTC-4, olcott wrote:
> >> If the execution trace of function Y() shows:
> >> (1) Function X() is called twice in sequence from the same machine
> >> address of Y().
> >> (2) With the same arguments to X().
> >> (3) With no control flow instructions between the
> >> invocation of Y() and its call to X().
> >
> > So I see you're back to actively lying about your results by using a
> > criteria you've admitted is invalid.
>
> I have never lied and when I called you out on this you had to retract
> your words: (I never admitted that the criteria is incorrect and
> indeed it is correct, there are never any false positives).
>
>

That is a LIE. You have been called out on a number of DIRECT lies.

In fact, almost every time you say you have "proved" something, it is a
lie, as you don't put your "proofs" in the format of an actual proof, so
they aren't actually proofs. The biggest problem is that you never show
where your initial premsises come from, and when someone questions one,
you ignore that. That action EXPLICITLY invalidiates your proofs, and
makes them unsound.

You are just not working at all in the field of Formal Logic, so not in
the right county to be working on the Halting Problem.

You are just proving your IGNORANCE of how formal logic works, thinking
it is just a debating society.

olcott

unread,
Aug 1, 2022, 8:08:13 AMAug 1
to
*When you deny basic facts than I have to stop talking to you*
*When you deny basic facts than I have to stop talking to you*
*When you deny basic facts than I have to stop talking to you*
*When you deny basic facts than I have to stop talking to you*
*When you deny basic facts than I have to stop talking to you*

H(P,P) correctly aborts its simulation when the simulated input matches
correctly this correct generic infinite recursion behavior pattern:

If the execution trace of function Y() shows:
(1) Function X() is called twice in sequence from the same machine
address of Y().
(2) With the same arguments to X().
(3) With no control flow instructions between the invocation of Y() and
its call to X().



Hs(Ps,Ps) is a purely hypothetical halt decider that is exactly the same
as H(P,P) except that it never aborts its simulation, it also matches
the same infinite recursion behavior pattern and reports that is input
does not halt through an output mechanism instead of a return value.
This could be a TM writing 0 to a tape location. This tape location is
initialized to blank, thus as soon as a 1 or a 0 is written to it the
decider has made its decision.

In no possible case does of either H(P,P) or Hs(Ps,Ps) does the
simulated P / Ps ever reach its "ret" instruction final state.

Otto J. Makela

unread,
Aug 1, 2022, 8:09:08 AMAug 1
to
olcott <No...@NoWhere.com> wrote:

> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> Key Fact (1) When H is a simulating halt decider that correctly
> simulates its input with an x86 emulator, the simulation will never
> stop running until H(P,P) aborts its emulation of its input:
>
> (1) Executed H(P,P) simulates its input with an x86 emulator.
> (2) Emulated P calls emulated H(P,P) to do this again.
> (3) Emulated H(P,P) simulates its input with an x86 emulator.
> (4) Emulated P calls emulated H(P,P) to do this again.
> (5) Emulated H(P,P) simulates its input with an x86 emulator...
>
> Key Fact (2) Furthermore the input to H(P,P) that is correctly
> simulated by H cannot possibly reach its own "ret" instruction whether
> or not H aborts its simulation.
>
> All those not agreeing with the above Key Facts are either:
> (a) Not interested in an honest dialogue or
> (b) Have insufficient software engineering technical competence
> Both will be ignored.

Let us assume, for the sake of discussion that I accept these both
(we will need to return to these points a bit later, though).

Let us compile this program using your H() decider.
When you run this program, what is the output of main()?

--
/* * * Otto J. Makela <o...@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

olcott

unread,
Aug 1, 2022, 8:13:56 AMAug 1
to
"Input_Halts = 0"

#include <stdint.h>
typedef void (*ptr)();

void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

*Matched infinite recursion detection criteria*
(1) P() calls H(P,P) twice in sequence.
(2) With the same arguments.
(3) With no control flow instructions in P preceding its invocation of
H(P,P) that could escape repeated simulations.

...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) = 237 pages

Dennis Bush

unread,
Aug 1, 2022, 8:22:15 AMAug 1
to
Which is not what a halt decider is required to do. Ha(Pa,Pa) is required to report if Pa(Pa) halts.

Pa(Pa) halts, therefore Ha(Pa,Pa)==0 is wrong.

> > On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> >> H(P,P) is asking would the input that I correctly emulate ever reach its
> >> "ret" instruction (final state) if I never stopped emulating it?
> >
> > Bottom line: Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >
> >
> >>
> >> When H(P,P) correctly simulates its input this input presents the
> >> infinite recursion control flow behavior pattern to H.
> >>
> >> If the execution trace of function Y() shows:
> >> (1) Function X() is called twice in sequence from the same machine
> >> address of Y().
> >> (2) With the same arguments to X().
> >> (3) With no control flow instructions between the invocation of Y() and
> >> its call to X().
> >
> > And again you're lying by attempting to make your point with a criteria
> > you've implicitly admitted is incorrect by your failure to respond to
> > explanations as to why it is wrong.
> I never explicitly or implicitly admitted that the following criteria is
> incorrect and when I called you out on to provide an time and date stamp
> quote of me admitting this you utterly failed because there was no such
> quote.

You absolutely implicitly admitted as much, and I did provide a quote of this implicit admission:

On Saturday, July 30, 2022 at 4:03:14 PM UTC-4, Dennis Bush wrote:
> On Saturday, July 30, 2022 at 3:56:10 PM UTC-4, olcott wrote:
> > Paste a date-time-stamped quote of me saying that the above criteria is
> > not valid.
> You did implicitly when it was explained why it was wrong:
>
> On Wednesday, July 27, 2022 at 3:09:51 PM UTC-4, Dennis Bush wrote:
> > On Wednesday, July 27, 2022 at 2:46:26 PM UTC-4, olcott wrote:
> > > Below I show that pattern that any expert of the x86 language can spot
> > > as specifying infinitely recursive simulation right below.
> > And your pattern is incorrect as proved by UTM(Pa,Pa) halting, and as several people have explained to you.
> >
> > It's not enough that there are no instructions in the function P prior to the call to the function H that branch. There have to be no instructions *between successive calls to H* that branch, and there are *several* functions in the function H as well as other functions that it calls.
> >
> > So this explains why your criteria 3 is wrong. Failure to explain why the above is wrong will be taken as admission that your criteria 3 is invalid.
>
> And you chose not to explain why the refutation is wrong:
>
> On Wednesday, July 27, 2022 at 3:36:14 PM UTC-4, Dennis Bush wrote:
> > I noticed that you failed to explain why my description of your criteria 3 is wrong. That means you implicitly admit that it is in fact wrong. That also means that if you use it again to make your argument that you're explicitly lying.

Just to spell it out, the above shows where I explained why point 3 is wrong and challenged you to refute my explanation, with a failure to do so taken as an admission that it is correct. It also shows where I pointed out that you in fact failed to do so.

In other words, the above is your implicit admission that point 3 is incorrect.

But I'll give you one more chance: explain why my description of point 3 being incorrect is wrong. Failure to do so will be taken as an admission by you that my explanation is correct and that point 3 is invalid.

And if you later claim that you never made such an implicit admission, I will point to this message as proof to the contrary.

>
> On 7/30/2022 2:37 PM, Dennis Bush wrote:
> > On Saturday, July 30, 2022 at 3:29:24 PM UTC-4, olcott wrote:
> >> If the execution trace of function Y() shows:
> >> (1) Function X() is called twice in sequence from the same machine
> >> address of Y().
> >> (2) With the same arguments to X().
> >> (3) With no control flow instructions between the
> >> invocation of Y() and its call to X().
> >
> > So I see you're back to actively lying about your results by using a
> > criteria you've admitted is invalid.
>
> I have never lied and when I called you out on this you had to retract
> your words: (I never admitted that the criteria is incorrect and
> indeed it is correct, there are never any false positives).

I never retracted anything, see above.

Mr Flibble

unread,
Aug 1, 2022, 8:46:15 AMAug 1
to
There is no infinite recursion in [Strachey 1965] and associated proofs
so your decider is wrong to rely on detecting it.

/Flibble


olcott

unread,
Aug 1, 2022, 8:54:10 AMAug 1
to
On 8/1/2022 7:22 AM, Dennis Bush wrote:
> On Sunday, July 31, 2022 at 11:46:44 PM UTC-4, olcott wrote:
>> On 7/31/2022 9:58 PM, Dennis Bush wrote:
>>> On Sunday, July 31, 2022 at 10:32:39 PM UTC-4, olcott wrote:
>>>> On 7/31/2022 9:20 PM, Dennis Bush wrote:
>>>>> On Sunday, July 31, 2022 at 10:00:34 PM UTC-4, olcott wrote:
>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:

>>> Then why do you insist that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>
>> H(P,P) correctly predicts that its correct and complete simulation of
>> its input would never reach the "ret" instruction of this input.
>
> Which is not what a halt decider is required to do. Ha(Pa,Pa) is required to report if Pa(Pa) halts.
>

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

When we accept the concept of a UTM then we know that the actual
behavior of the actual input is ultimately determined by the correct
simulation that H(P,P) performs on its input.

This simulation is verified as correct in that the line-by-line
execution trace of the simulated input exactly matches the line-by-line
x86 source-code of P specifies.

H must only compute the mapping from the sequence of instructions that
it is presented with and not allowed to compute any other mapping.

int sum(int x, int y) { return x + y; }
sum(3,4) must return the sum of 3+4 and its not allowed to return the
sum of 4+5.
So the post just my words and nothing else:
where I explicitly admitted that my criteria is invalid.
You know that no such admission exists.

When you say that I did X knowing full well that I did not do X what do
we have? (a) a box of chocolates (b) a hungry cat (c) a lie

THIS CRITERIA IS PERFECT IN THAT IS HAS NO FALSE POSITIVES
EVERY SINGLE TIME THAT THIS CRITERIA IS MATCHED WE HAVE INFINITE RECURSION
If the execution trace of function Y() shows:
(1) Function X() is called twice in sequence from the same machine
address of Y().
(2) With the same arguments to X().
(3) With no control flow instructions between the invocation of Y() and
its call to X().

Then the function call from Y() to X() is infinitely recursive.


Otto J. Makela

unread,
Aug 1, 2022, 8:56:22 AMAug 1
to
olcott <No...@NoWhere.com> wrote:

> On 8/1/2022 7:09 AM, Otto J. Makela wrote:
>> Let us assume, for the sake of discussion that I accept these both
>> (we will need to return to these points a bit later, though).
>> Let us compile this program using your H() decider.
>> When you run this program, what is the output of main()?
>
> "Input_Halts = 0"

So the call of H(P,P) in main() returned 0.

Why isn't that incorrect, since the first thing P(P) does
is call H(P,P) and if this returns 0 it exits normally?

Dennis Bush

unread,
Aug 1, 2022, 9:11:04 AMAug 1
to
On Monday, August 1, 2022 at 8:54:10 AM UTC-4, olcott wrote:
> On 8/1/2022 7:22 AM, Dennis Bush wrote:
> > On Sunday, July 31, 2022 at 11:46:44 PM UTC-4, olcott wrote:
> >> On 7/31/2022 9:58 PM, Dennis Bush wrote:
> >>> On Sunday, July 31, 2022 at 10:32:39 PM UTC-4, olcott wrote:
> >>>> On 7/31/2022 9:20 PM, Dennis Bush wrote:
> >>>>> On Sunday, July 31, 2022 at 10:00:34 PM UTC-4, olcott wrote:
> >>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>
> >>> Then why do you insist that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>
> >> H(P,P) correctly predicts that its correct and complete simulation of
> >> its input would never reach the "ret" instruction of this input.
> >
> > Which is not what a halt decider is required to do. Ha(Pa,Pa) is required to report if Pa(Pa) halts.
> >
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.

FALSE. A halt decider is required to map the halting function:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

So Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.

olcott

unread,
Aug 1, 2022, 9:18:07 AMAug 1
to
On 8/1/2022 7:56 AM, Otto J. Makela wrote:
> olcott <No...@NoWhere.com> wrote:
>
>> On 8/1/2022 7:09 AM, Otto J. Makela wrote:
>>> Let us assume, for the sake of discussion that I accept these both
>>> (we will need to return to these points a bit later, though).
>>> Let us compile this program using your H() decider.
>>> When you run this program, what is the output of main()?
>>
>> "Input_Halts = 0"
>
> So the call of H(P,P) in main() returned 0.
>
> Why isn't that incorrect, since the first thing P(P) does
> is call H(P,P) and if this returns 0 it exits normally?
>

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

When we accept the concept of a UTM then we know that the actual
behavior of the actual input is ultimately determined by the correct
simulation that H(P,P) performs on its input.

This simulation is verified as correct in that the line-by-line
execution trace of the simulated input exactly matches the line-by-line
x86 source-code of P specifies.

H must only compute the mapping from the sequence of instructions that
it is presented with and not allowed to compute any other mapping.

int sum(int x, int y) { return x + y; }
sum(3,4) must return the sum of 3+4 and its not allowed to return the
sum of 4+5.

The correctly simulated input to H(P,P) remains stuck in infinite
recursion until H aborts its simulation. In every case where H must
abort its simulation to prevent the infinite simulation of its input H
is correct to abort this simulation and report non-halting.

olcott

unread,
Aug 1, 2022, 9:20:48 AMAug 1
to
When we accept the concept of a UTM then we know that the actual
behavior of the actual input is ultimately determined by the correct
simulation that H(P,P) performs on its input.

This simulation is verified as correct in that the line-by-line
execution trace of the simulated input exactly matches the line-by-line
x86 source-code of P specifies.

H must only compute the mapping from the sequence of instructions that
it is presented with and not allowed to compute any other mapping.

int sum(int x, int y) { return x + y; }
sum(3,4) must return the sum of 3+4 and its not allowed to return the
sum of 4+5.

The correctly simulated input to H(P,P) remains stuck in infinite
recursion until H aborts its simulation. In every case where H must
abort its simulation to prevent the infinite simulation of its input H
is correct to abort this simulation and report non-halting.


Dennis Bush

unread,
Aug 1, 2022, 9:26:42 AMAug 1
to

olcott

unread,
Aug 1, 2022, 9:34:52 AMAug 1
to
H must only compute the mapping from the sequence of instructions that
it is presented with and not allowed to compute any other mapping.

int sum(int x, int y) { return x + y; }
sum(3,4) must return the sum of 3+4 and its not allowed to return the
sum of 4+5.


Dennis Bush

unread,
Aug 1, 2022, 9:36:06 AMAug 1
to
And for Ha(Pa,Pa) that sequence of instruction is by definition Pa(Pa), not Pn(Pn) as you claim:

Otto J. Makela

unread,
Aug 1, 2022, 9:54:31 AMAug 1
to
olcott <No...@NoWhere.com> wrote:

> On 8/1/2022 7:56 AM, Otto J. Makela wrote:
>> olcott <No...@NoWhere.com> wrote:
>>> On 8/1/2022 7:09 AM, Otto J. Makela wrote:
>>>> Let us assume, for the sake of discussion that I accept these both
>>>> (we will need to return to these points a bit later, though).
>>>> Let us compile this program using your H() decider.
>>>> When you run this program, what is the output of main()?
>>> "Input_Halts = 0"
>> So the call of H(P,P) in main() returned 0.
>> Why isn't that incorrect, since the first thing P(P) does
>> is call H(P,P) and if this returns 0 it exits normally?
[...]
> The correctly simulated input to H(P,P) remains stuck in infinite
> recursion until H aborts its simulation. In every case where H must
> abort its simulation to prevent the infinite simulation of its input H
> is correct to abort this simulation and report non-halting.

Why does the correctly simulated H(P,P) not similarly detect infinite
recursion (inside the simulation) and return 0?

olcott

unread,
Aug 1, 2022, 11:24:10 AMAug 1
to
On 8/1/2022 8:54 AM, Otto J. Makela wrote:
> olcott <No...@NoWhere.com> wrote:
>
>> On 8/1/2022 7:56 AM, Otto J. Makela wrote:
>>> olcott <No...@NoWhere.com> wrote:
>>>> On 8/1/2022 7:09 AM, Otto J. Makela wrote:
>>>>> Let us assume, for the sake of discussion that I accept these both
>>>>> (we will need to return to these points a bit later, though).
>>>>> Let us compile this program using your H() decider.
>>>>> When you run this program, what is the output of main()?
>>>> "Input_Halts = 0"
>>> So the call of H(P,P) in main() returned 0.
>>> Why isn't that incorrect, since the first thing P(P) does
>>> is call H(P,P) and if this returns 0 it exits normally?
> [...]
>> The correctly simulated input to H(P,P) remains stuck in infinite
>> recursion until H aborts its simulation. In every case where H must
>> abort its simulation to prevent the infinite simulation of its input H
>> is correct to abort this simulation and report non-halting.
>
> Why does the correctly simulated H(P,P) not similarly detect infinite
> recursion (inside the simulation) and return 0?
>

Of the nested simulations the outermost one sees that the infinite
recursion criteria is met first.

If the execution trace of function Y() shows:
(1) Function X() is called twice in sequence from the same machine
address of Y().
(2) With the same arguments to X().
(3) With no control flow instructions between the invocation of Y() and
its call to X().

Then the function call from Y() to X() is infinitely recursive.


olcott

unread,
Aug 1, 2022, 6:34:37 PMAug 1
to
So then you agree the H(P,P) does correctly determine the halt status of
its input, yet disagree that H is supposed to examine its input instead
it must examine the behavior of the non-input P(P) ?

Dennis Bush

unread,
Aug 1, 2022, 7:06:15 PMAug 1
to
Sure, Ha(Pa,Pa) reports the halt status of "its input". But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

You're the one that thinks that Ha(Pa,Pa) is supposed to examine the behavior of the non-input Pn(Pn).

Paul N

unread,
Aug 1, 2022, 7:06:30 PMAug 1
to
On Monday, August 1, 2022 at 11:34:37 PM UTC+1, olcott wrote:
> So then you agree the H(P,P) does correctly determine the halt status of
> its input, yet disagree that H is supposed to examine its input instead
> it must examine the behavior of the non-input P(P) ?

The first argument in the call H(P, P) is P. The second argument is also P. Thus H(P, P) is supposed to determine whether P(P) halts or not. That is the "input" to H.

Richard Damon

unread,
Aug 1, 2022, 7:11:49 PMAug 1
to
No, YOU deny the basic facts, and thus prove yourself to be a liar.

If you statements were true, you would be able to provide proofs or
sources from them, but you can't.

You DENY that the behavior of the input to H(P,P) matches the behavior
of the computation P(P), even though you actually USE that matching in
your definition of the function P. Thus, you are denying a truth that
you have accepted. Thus you mind is stuck in a contradiction, as is your
logic.

>
> H(P,P) correctly aborts its simulation when the simulated input matches
> correctly this correct generic infinite recursion behavior pattern:
>
> If the execution trace of function Y() shows:
> (1) Function X() is called twice in sequence from the same machine
> address of Y().
> (2) With the same arguments to X().
> (3) With no control flow instructions between the invocation of Y() and
> its call to X().
>
>

Yep, you same LIE, that you can not prove or provide a source for you
claim (3).

This has been pointed out MANY times, but you stick to the UNFOUNDED and
INCORRECT claim, thus proving you don't care about what is actually
True, just what you claim.


>
> Hs(Ps,Ps) is a purely hypothetical halt decider that is exactly the same
> as H(P,P) except that it never aborts its simulation, it also matches
> the same infinite recursion behavior pattern and reports that is input
> does not halt through an output mechanism instead of a return value.
> This could be a TM writing 0 to a tape location. This tape location is
> initialized to blank, thus as soon as a 1 or a 0 is written to it the
> decider has made its decision.

Fallacy of Proof by Example. The fact that you show that H would be
correcf to decide on H(Ps,Ps) since Hs(Ps,Ps) not aborting makes Ps(Ps)
non-halting does say ANYTHING about P(P).

You are as UNSOUND as your logic.

>
> In no possible case does of either H(P,P) or Hs(Ps,Ps) does the
> simulated P / Ps ever reach its "ret" instruction final state.
>

WRONG, UTM(P,P) will reach the halt.

THAT is a correct and COMPLETE simulation, which PROVES the input
represents a Halting Computation

You are showing yourself to be a pitiful man, except you show it seems
to be deliberate, so it doesn't really invoke pity anymore, just that
you are proving yourself to be a FOOL.

Richard Damon

unread,
Aug 1, 2022, 7:13:10 PMAug 1