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

[olcott]

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]

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]

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]

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]

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]

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]

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]

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]

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]

typo corrected
> I [no] know that answering YES makes you look utterly foolish and answering NO

[Richard Damon]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

The halting decider of [Strachey 1965] and associated proofs is not
recursive in nature.

/Flibble

[Richard Damon]

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]

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]

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]

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]

*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]

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]

"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]

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]

There is no infinite recursion in [Strachey 1965] and associated proofs
so your decider is wrong to rely on detecting it.

/Flibble

[olcott]

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]

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]

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]

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]

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]

[olcott]

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]

And for Ha(Pa,Pa) that sequence of instruction is by definition Pa(Pa), not Pn(Pn) as you claim:

[Otto J. Makela]

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]

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]

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]

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]

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]

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]

Nope, it fails for H(P,P) and P(P) since P(P) halts when H)P,P) returns 0.

This has been pointed out MANY times, so you are just shown to be a bald
face LIAR, or an IDIOT.

[Richard Damon]

So, you are just proving that yoou don't even understand what a Decider
is, and particularly a Halt Decider.

Nor do you know what the meaning of the word DEFINITION.

YOU FAIL.

[Richard Damon]

Nope, P(P) IS the input to H, since that is what the input represents,
and the input has ALL the information needed to recover ALL the behavior
of that machine.

Remember, you drop the course before you got to the section on
representation because you couldn't understand the material.

[Richard Damon]

On 8/1/22 11:24 AM, olcott wrote:
> 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.

But the inner one would if the input was correcctly simulated to that point.

Just because H can't do it, doesn't mean that it doesn't happen.

>
> 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.
>
>

(3) is FALSE, as explained many times before.

[olcott]

No it is not the input to H.

The behavior of directly executed P(P) is NOT the same behavior
as when H(P,P) correctly simulates its input because the execution
order of P(P) first is reversed when H(P,P) is invoked first.

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

int main()
{

P(P);
}

When P calls H(P,P) this is essentially the first call of
infinite recursion. When H(P,P) simulates its input this
is essentially the second call of infinite recursion.

H can see the infinite recursion specified by its input and
aborts its simulation on that basis. As with all infinite
recursion when any call is aborted the whole sequence stops.
In this case when H(P,P) aborts its simulation it returns to
its caller.

The input to H(P,P) is infinitely recursive (as proven by the fact
the the simulation never stops unless aborted) therefore H did
correctly determine the halt status of this input.

That is was supposed to determine the halt status of a non-input
seems absurd and is rejected on the basis that software engineering
won't allow it.

[olcott]

I count that as a huge breakthrough when 99% of of reviewers reject
everything that I say out-of-hand without even looking at it and
the remaining 1% are so laser focused on finding fault that they hardly
pay any attention to what I say.

> 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
>

The behavior of directly executed P(P) is NOT the same behavior
as when H(P,P) correctly simulates its input because the execution
order of P(P) first is reversed when H(P,P) is invoked first.

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

int main()
{

P(P);
}

When P calls H(P,P) this is essentially the first call of
infinite recursion. When H(P,P) simulates its input this
is essentially the second call of infinite recursion.

H can see the infinite recursion specified by its input and
aborts its simulation on that basis. As with all infinite
recursion when any call is aborted the whole sequence stops.
In this case when H(P,P) aborts its simulation it returns to
its caller.

The input to H(P,P) is infinitely recursive (as proven by the fact
the the simulation never stops unless aborted) therefore H did
correctly determine the halt status of this input.

That is was supposed to determine the halt status of a non-input
seems absurd and is rejected on the basis that software engineering
won't allow it.

[Dennis Bush]

But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:

> > 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
> >

Where I point out you're answering the wrong question.

Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.

> The behavior of directly executed P(P) is NOT the same behavior
> as when H(P,P) correctly simulates its input because the execution
> order of P(P) first is reversed when H(P,P) is invoked first.
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> P(P);
> }
>
> When P calls H(P,P) this is essentially the first call of
> infinite recursion. When H(P,P) simulates its input this
> is essentially the second call of infinite recursion.
>
> H can see the infinite recursion specified by its input and
> aborts its simulation on that basis. As with all infinite
> recursion when any call is aborted the whole sequence stops.
> In this case when H(P,P) aborts its simulation it returns to
> its caller.
>
> The input to H(P,P) is infinitely recursive (as proven by the fact
> the the simulation never stops unless aborted) therefore H did
> correctly determine the halt status of this input.
>
> That is was supposed to determine the halt status of a non-input
> seems absurd and is rejected on the basis that software engineering
> won't allow it.

If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?

[olcott]

You know that never said anything like that:

Try and find a date-and-time stamped quote of me
saying anything like that.

[Dennis Bush]

That's precisely what the comment I've been quoting is saying:

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?

If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.

So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).

[olcott]

You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
A simulating halt decider is always correct to abort the simulation of
any input that it correctly predicts would never otherwise never stop
running.

I know that you know that this correct and true and have no idea what
double-talk you will use to attempt to fool the gullible into believing
that I am wrong.

[Dennis Bush]

No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
of Hn it is essentially the same as a UTM.

> A simulating halt decider is always correct to abort the simulation of
> any input that it correctly predicts would never otherwise never stop
> running.

A simulating halt decider, like any 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

Which means that Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts.

>
> I know that you know that this correct and true and have no idea what
> double-talk you will use to attempt to fool the gullible into believing
> that I am wrong.

The only person who doesn't think you're wrong is you. I don't need to convince anyone else of that.

[Richard Damon]

NO! YOUR logic has Ha looking at Pa as if it swas Pn, because it
presuems (incorrectly) that the H it calls doesn't abort, and thus is
Hn, and the P that calls Hn is Pn.

Yes, that means that Ha, when given Pa,Pa as parameters incorrectly
thinks it is processing Pn,Pn as its parameters.

>
> I know that you know that this correct and true and have no idea what
> double-talk you will use to attempt to fool the gullible into believing
> that I am wrong.
>

Nope, you are the one that is mistaken.

You problem is you have programmed H with the wrong definiton of the
behaivor it presumes the H that P calls, because it INCORRECTLY doesn't
actually simulate that H.

Thus, if it is going to replace the code of H with its equivalent
behavior, it needs to replace it with the ACTUAL equivalent behavionr,
and not that of a different version of itself.

It can't assume that H will keep on simulating until to CORRECTLY
proves its input is non-halting, if it doesn't do that itself.

Your H ASSUMES (incorrectly) that is what it is doing, but that is just
falling for the fallacy of assuming the conclusion.

All you are doing is proving you FAIL at the basic rules of logic.

I could write a book showing most of the logical fallacies using just
examples from your writings.

[olcott]

Yet in the case of H and P that would require a software function to
return the result of analyzing a non-input which from a software
engineering perspective is pure nonsense.

When computer science theory contradicts software engineering facts the
theory must be revised in light of these facts.

int sum(int x, int y) { return x + y; }

sum(3,4) cannot and must not return the result of the sum of 4+5.

[Richard Damon]

On 8/1/22 7:38 PM, olcott wrote:
> On 8/1/2022 6:06 PM, Paul N wrote:
>> 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.
>
> No it is not the input to H.
>
> The behavior of directly executed P(P) is NOT the same behavior
> as when H(P,P) correctly simulates its input because the execution
> order of P(P) first is reversed when H(P,P) is invoked first.
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> When P calls H(P,P) this is essentially the first call of
> infinite recursion. When H(P,P) simulates its input this
> is essentially the second call of infinite recursion.

Maybe "essentially", but only in the sense of not quite. It WOULD be
infiite recursion if H(P,P) doesn't abort its simulation, but since it
does, it isn't.

Not because H aborted its simulation, but because it returns 0 to its
caller, which might be P(P), which makes P(P) Halting.

>
> H can see the infinite recursion specified by its input and
> aborts its simulation on that basis. As with all infinite
> recursion when any call is aborted the whole sequence stops.
> In this case when H(P,P) aborts its simulation it returns to
> its caller.

No, H THINKS it sees infinite recursion because it isn't smart enough to
see that the H that it sees being called WILL abort its simulation too
(if this one does) and thus breaks the recursion that it thinks it sees.

>
> The input to H(P,P) is infinitely recursive (as proven by the fact
> the the simulation never stops unless aborted) therefore H did
> correctly determine the halt status of this input.

Nope, your using the wrong definition. Once H(P,P) includes the
instructions to abort its simulation then because of the "pathological"
self-reference, the input it is simulating will do so also, just after
the point that H simulates.

>
> That is was supposed to determine the halt status of a non-input
> seems absurd and is rejected on the basis that software engineering
> won't allow it.
>
>

It isn't a non-input, it is EXACTLY what the input represents, and that
is what has behavior.

The input EXACTLY preresents P(P), or you are LYING about everything you
have been talking about.

Of course, it seems that most things you say are a lie, so that isn't new.

[Dennis Bush]

You don't get to change the question. The question is what it is. And the question is: does an algorithm exist that can determine if *any* arbitrary algorithm halts given a particular input? I.E. is the halting function computable?

Since you like talking about software engineering, you should know that good software engineering says that a function must implement a specification. The specification for a halt decider is

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

I.E. a halt decider maps the halting function.

>
> When computer science theory contradicts software engineering facts the
> theory must be revised in light of these facts.
> int sum(int x, int y) { return x + y; }
> sum(3,4) cannot and must not return the result of the sum of 4+5.

Just like Ha(Pa,Pa) cannot and must not report if Pn(Pn) halts.

[Richard Damon]

But it ISN'T a "non-input", or you have just defined that NO Halt
decider could exist.

If we can't give H the program P(P) by giving it the defined
representation, then Halt Decider just don't exist. PERIOD.

Your problem is you dropped out of school before you learned about
representations. It isn't that it is a non-input, it is that Peter can't
see that it IS the input, becuase it is beyond your ability to
understand thing.

The world doesn't limit itself to your understanding.

>
> When computer science theory contradicts software engineering facts the
> theory must be revised in light of these facts.

Except that Computer Science Theory DOESN'T contradict Software
Engineering, it just shows that the concept are beyond YOUR ability to
comprehend them BECAUSE YOU ARE AN IDIOT.

>
> int sum(int x, int y) { return x + y; }
> sum(3,4) cannot and must not return the result of the sum of 4+5.
>
>
>

And it isn't being asked to, and neither it H.

FAIL.

[olcott]

The correctly simulated input to H(P,P) cannot possibly reach is "ret"
instruction (final state) and halt even when its simulation is aborted.

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]

When the question is WRONG, I do get to change the question.

When computer science theory contradicts software engineering facts the
theory must be revised in light of these facts.

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.

[Dennis Bush]

Are you saying that it's impossible for a function H to implement the following specification?

[Richard Damon]

Right, which doesn't prove your conclusion, because, as you next
statement shows, halting isn't defined by simulation, but by the actual
execution of the machine.

Only a simulation that actually replicates the machine directly show
halting or non-halting. Thus, an aborted simulation doesn't, in and of
itself, show non-halting.

Yes, it is possible to prove from SOME partial simulations that the
input actually is non-halting, but such a proof needs to be sound and valid.

The fact that P(P) Halts if H(P,P) returns 0, says that ANY proof that
tries to show that H(P,P) returning 0 is correct, MUST be flawed. I have
pointed out the error in the "proof" that you have presented. Your
continuing to make the claim shows that you either are too stupid to
understand the logic, or are just a pathological liar and don't care
what is actually true.

You seem to not understand the difference between actually executing a
Turing Machine and conditionally simulating one, or refuese to let that
difference get in your way of lying about what you are talking about.

>
> 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)
>

Right, THE TURING MACHINE, that is P(P), which HALTS if H(P,P) returns
0, so that can't be the correct answer.

[Richard Damon]

Nope, because the question CAN'T be wrong. If it is impossible to answer
the question, that just means the Halting Function isn't Computable.

You don't seem to understand that that is a thing.

Its just like some Truths can't be proven.

>
> When computer science theory contradicts software engineering facts the
> theory must be revised in light of these facts.
>

But it isn't, you are just to dumb to reconcile the issue.

> 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 describe by the input IS the behavior of P(P).

So, that IS the input.

>
> 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.
>
>

Right, H(M,x) must return 1 if UTM(M,x) Halts, and return 0 if UTM(M,x)
never halts.

UTM(P,P) Halts if H(P,P) returns 0, even thoough H can't reach that
point since it aborts before it gets there.

This means that H(P,P) returning 0 is NOT a correct answer.

The question isn't about the simulation done by H, but the simulation
done by an ACTUAL UTM, which, BY DEFINITION, will behave exactly like
the machine described by the input.

The fact that H can't actually recreate that result and give and answer
just shows that the function being mapped isn't computable, not that the
question is somehow wrong.

Your error is adding in an implicit assumption that H CAN actually
compute the result, when it can't.

As I said, that doesn't make the question wrong, since a fully
legitimate answer is that the mapping isn't computable.

[olcott]

int main()
{
H(P,P); // H is invoked first
P(P); // P is invoked first
}

Thus the input to H(P,P) specifies a different sequence of instructions
than the direct execution of P(P).

The sequence of instructions specified by P(P) is NOT an input to H
because it reverses the order of the invocation of H and P. This
reversed order makes their behavior differ. P(P) halts on its own and
the correctly simulated input to H(P,P) never stops running unless aborted.

Any input to H that never stops running unless aborted is a non-halting
input.

[Richard Damon]

Then H isn't a pure function of its input, BY DEFINITION.

Remember, the DEFINITION of a Pure function is one whose output ONLY
depends on its parameters, and not any other external state, plus the
requirement that it affect no external state of any other function.

Thus, it CAN'T matter to H whether it is called by P or by main.

>
> The sequence of instructions specified by P(P) is NOT an input to H
> because it reverses the order of the invocation of H and P. This
> reversed order makes their behavior differ. P(P) halts on its own and
> the correctly simulated input to H(P,P) never stops running unless aborted.

How is that? H is given the EXACT object code of the entire program of P.

How H is called can't matter if H is a pure function, only its parameters.

Note, "the sequence of instruction specified by the input" STARTS at the
beginning of the simulation, and follows the EXACT sequence the x86
processor would follow. That INCLUDES the sequence of instructions that
happen inside the code of H that P calls.

Yes, the fact that P calls H with a representation of itself puts H in a
bit of a bind, that it the decider eeds to figure out what it is going
to do before it get there, which is what makes the problem non-computable.

The code of H will either need to keep simulating waiting for a state
that it can actually prove is non-halting, and thus simulate forever and
fail to answer, or it needs to stop simulating at some point and guess
an answer, which, because P gets to know the answer by it calling H,
allows P to make whatever H guesses wrong.

Any pattern that H decides proves EITHER Halting or Non-Halting, when it
returns that value, becomes the value that P(P) will get, and it will
act contrary and make that answer wrong.

This is why if H waits till it can actualy PROVE its result, it will
simulate forever and fail to answer, because there is no answer tha tH
can give and be right.

This doesn't say there isn't a right answer, because once you FIX H into
a specific algorithm, you FIX the behavior of H(P,P) and thus of P(P),
so ANOTHER decider, can likely get the right answer, and there ALWAYS is
a right answer, because H needs to either return 1, return 0, or never
return, and all of those have a correct answer for the halting problem.

If H returns 0, then P(P) Halts.
If H returns 1, or never returns, then P(P) is non-halting.

>
> Any input to H that never stops running unless aborted is a non-halting
> input.
>

Close, an input that would never halt running when completely and
correctly simulated by a pure UTM is non-halting.

The fact that H can't simulate it to its final state doesn't mean
anything. We look at the actual H you actually provide and look at the
behavior of that input when given to a real UTM to check if it is
halting or not.

You don't seem to understand the DEFINITION of Halting.

You don't seem to understand what a PURE function is.

You don't seem to understand a LOT of things.

[Skep Dick]

On Tuesday, 2 August 2022 at 03:50:20 UTC+2, olcott wrote:

> int main()
> {
> H(P,P); // H is invoked first
> P(P); // P is invoked first
> }
>
> Thus the input to H(P,P) specifies a different sequence of instructions
> than the direct execution of P(P).

No, it doesn’t.

A(B) means “apply A to B”
B(A(C))) means “Apply B to (apply A to C))”
B(A,C) means the same thing as B(A(C))

Currying. You don’t understand it.

https://en.wikipedia.org/wiki/Currying

[Paul N]

So you accept that your H does not report on what happens when P(P) is executed? Your H only predicts what will happen when your H simulates a call of P(P)?

[olcott]

P(P) halts and the correctly simulated input to H(P,P) by H never halts
because they specify two different sequences of instructions:
one begins with the invocation of H and the other begins with the
invocation of P. In the first case H(P,P) returns 0 to P in the second
case because H is called in infinite recursion it never returns to P.

> Your H only predicts what will happen when your H simulates a call of P(P)?

Likewise sum(3,4) does not report the sum of 4+5 that would violate
software engineering.

*Do you understand that this is true*?
H(P,P) does correctly determine the halt status of the sequence of
instructions that it is presented with.

H(P,P) does not, cannot, should not, and must not report on any sequence
of instructions that it was *NOT* presented with. This violates software
engineering.

[Paul N]

If a simulation is correct, then it is possible to work out what will happen in the real case by looking at what happens in the simulated case. This is part of the point of doing simulations. However, you have said yourself that P(P) behaves differently from your simulation. Thus I do not accept that your simulation is a correct simulation. You seem to think that your simulation is "even better than the real thing" in that you are prepared to trust the results of your simulation even when you know that the actual program being simulated acts differently.

> > Your H only predicts what will happen when your H simulates a call of P(P)?
> Likewise sum(3,4) does not report the sum of 4+5 that would violate
> software engineering.

sum(3, 4) must return 3+4 because 3 and 4 are the arguments provided. 4 and 5 are not.

Likewise, H(P, P) must report on the behaviour of P(P) because P and P are the two arguments provided.

> *Do you understand that this is true*?
> H(P,P) does correctly determine the halt status of the sequence of
> instructions that it is presented with.

No it doesn't - you say that H(P, P) is zero, but that P(P) halts.

> H(P,P) does not, cannot, should not, and must not report on any sequence
> of instructions that it was *NOT* presented with. This violates software
> engineering.

Yes, it must report on what P(P) actually does. You claim it does not.

[olcott]

You are saying that if the simulation of the sequence of instructions
specified by X is correct then we can use this correct simulation of X
to determine what the behavior sequence of instructions specified by Y.

How does that make any sense?

> This is part of the point of doing simulations. However, you have said yourself that P(P) behaves differently from your simulation. Thus I do not accept that your simulation is a correct simulation.

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

There are few things that annoy me more than when people ignore the
verified facts so that they can hold onto their opinion.

int main()
{
H(P,P);
P(P);
}

At the C level we can see that one sequence begins with H and the other
begins with P. To rigidly assume that two different sequences must have
the same behavior is ridiculous.

> You seem to think that your simulation is "even better than the real thing" in that you are prepared to trust the results of your simulation even when you know that the actual program being simulated acts differently.

The correct simulation (as verified line-by-line) of the input to H(P))
by H conclusively proves that it will never stop running unless aborted.

*You can verify this yourself here is the whole system*:
Simply build the project and Halt7.c is automatically compiled with the
command line compiler. This way you can comment out the code that aborts
the simulation and see that it would run forever.

https://www.liarparadox.org/2022_07_22.zip
This is the complete system that compiles under:

Microsoft Visual Studio Community 2017
https://visualstudio.microsoft.com/vs/older-downloads/

>
>>> Your H only predicts what will happen when your H simulates a call of P(P)?
>> Likewise sum(3,4) does not report the sum of 4+5 that would violate
>> software engineering.
>
> sum(3, 4) must return 3+4 because 3 and 4 are the arguments provided. 4 and 5 are not.
>
> Likewise, H(P, P) must report on the behaviour of P(P) because P and P are the two arguments provided.
>
>> *Do you understand that this is true*?
>> H(P,P) does correctly determine the halt status of the sequence of
>> instructions that it is presented with.
>
> No it doesn't - you say that H(P, P) is zero, but that P(P) halts.
>
>> H(P,P) does not, cannot, should not, and must not report on any sequence
>> of instructions that it was *NOT* presented with. This violates software
>> engineering.
>
> Yes, it must report on what P(P) actually does. You claim it does not.

When computer science theory contradicts software engineering facts the
theory must be revised in light of these facts.

H(P,P) does correctly report on the sequence of instructions that it was
presented with that begins with itself. H is run and then P is run.
H cannot report on the sequence where P is run first and then H is run
second.

H1(P,P) (an identical copy of H at a different machine address) returns 1.

[Dennis Bush]

Because both are the same sequence.

> > This is part of the point of doing simulations. However, you have said yourself that P(P) behaves differently from your simulation. Thus I do not accept that your simulation is a correct simulation.
> The line-by-line execution trace of the x86 emulation of the input to
> H(P,P) by H exactly matches the line-by-line x86 source-code of P.

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

Ha3(N,5)==0 is obviously incorrect, so the above claim doesn't prove anything.

>
> There are few things that annoy me more than when people ignore the
> verified facts so that they can hold onto their opinion.

You mean like the fact that Ha(Pa,Pa) is required to report if Pa(Pa) halts?

>
> int main()
> {
> H(P,P);
> P(P);
> }
>
> At the C level we can see that one sequence begins with H and the other
> begins with P. To rigidly assume that two different sequences must have
> the same behavior is ridiculous.

H doesn't start by simulating itself, it starts by simulating P. So the instructions of the direct execution of P are the same as the instructions that H(P,P) is simulating.

> > You seem to think that your simulation is "even better than the real thing" in that you are prepared to trust the results of your simulation even when you know that the actual program being simulated acts differently.
> The correct simulation (as verified line-by-line) of the input to H(P))
> by H conclusively proves that it will never stop running unless aborted.

Correct but not complete, and you need both. The correct *and complete* simulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts.

>
> *You can verify this yourself here is the whole system*:
> Simply build the project and Halt7.c is automatically compiled with the
> command line compiler. This way you can comment out the code that aborts
> the simulation and see that it would run forever.
>
> https://www.liarparadox.org/2022_07_22.zip
> This is the complete system that compiles under:
>
> Microsoft Visual Studio Community 2017
> https://visualstudio.microsoft.com/vs/older-downloads/
> >
> >>> Your H only predicts what will happen when your H simulates a call of P(P)?
> >> Likewise sum(3,4) does not report the sum of 4+5 that would violate
> >> software engineering.
> >
> > sum(3, 4) must return 3+4 because 3 and 4 are the arguments provided. 4 and 5 are not.
> >
> > Likewise, H(P, P) must report on the behaviour of P(P) because P and P are the two arguments provided.
> >
> >> *Do you understand that this is true*?
> >> H(P,P) does correctly determine the halt status of the sequence of
> >> instructions that it is presented with.
> >
> > No it doesn't - you say that H(P, P) is zero, but that P(P) halts.
> >
> >> H(P,P) does not, cannot, should not, and must not report on any sequence
> >> of instructions that it was *NOT* presented with. This violates software
> >> engineering.
> >
> > Yes, it must report on what P(P) actually does. You claim it does not.
> When computer science theory contradicts software engineering facts the
> theory must be revised in light of these facts.

The software engineering fact is that H is does not implement the required specification:

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 didn't answer before so I'll ask again: Is it possible to create an algorithm H that meets the above specification?

> H(P,P) does correctly report on the sequence of instructions that it was
> presented with that begins with itself.

No it doesn't. Contrary to the requirements, Ha(Pa,Pa) is reporting on Pn(Pn) instead of Pa(Pa).

[Mikko]

On 2022-08-01 12:54:04 +0000, olcott said:

> 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 halting problem does not require that. It merely says (or implies --
each author uses different words but they aways mean the same) that
- if H(M, I) returns false and M(I) halts then H is not a halt decider
- if H(M, I) returns true and M(I) doesn't halt then H is not a halt decider
- if H(M, I) returns something else then H is not a halt decider
- if H(M, I) does not return then H is not a halt decider
- otherwise H is a halt decider

Mikko

[Mr Flibble]

I can add to that (my key insight):

- if H(M, I) doesn't signal an exception on pathological
("Impossible Program") input then H is not a halt decider.

/Flibble

[Jeff Barnett]

You, like PO, seem to think that a proper H uses some sort of simulation
and signals exceptions. That isn't true. Take the impossible program
used in the proof that there is no right answer. That result can be
derived by simple analysis - everybody still stroking the mega maniac by
contributing to these threads has done that by studying the symbolic code.

Once again, the proof shows there is no right answer, but there is one
more step to complete the proof: "If there is no right answer for some
problems, then an actual decider simply cannot exist." That proof is not
the only one however. There are a ton of them (proofs) and many show
that desirable deciders about problems of great interest to Software
Engineers, Mathematicians, and Logicians don't exist either.

The results apply to any claim about Universal Deciders which are really
the same class as Deciders.

Assume that you have an H(TM,INPUT) that properly returns a value in
{halts, pathological, infinite-loop} with the stipulation that H halts
for any arguments, i.e., H is the POOP decider that PO has wet dreams
about. QUESTION: What happens if you build H' and H^ from this H? Run it
through the same proof structure that is in Linz and tell us all what
happens. Will PO die a fool or find a place in history? The curious want
to know!
--
Jeff Barnett

[Mr Flibble]

You are wrong: I am extending the definition of what constitutes a
halt decider which is my right as both a computer scientist and a
software engineer.

If the only way to detect pathological input is through the use of a
simulating halt decider then so be it.

/Flibble

[Andy Walker]

On 02/08/2022 18:54, Jeff Barnett wrote:
> Once again, the proof shows there is no right answer, but there is
> one more step to complete the proof: "If there is no right answer for

> some problems, then an actual decider simply cannot exist." [...]

Just to be clear, /given/ a program and its input, there /is/ a
"right answer" to the HP question applied to that program and input.
What the "usual" proof shows is not that there is no right answer, but
that no one TM can always find it.

> Assume that you have an H(TM,INPUT) that properly returns a value in

> {halts, pathological, infinite-loop} [...].

Neither PO nor Flibble has ever given a sensible definition of
what they mean by "pathological", and of course if they do they will
fall foul of Rice's Theorem. Further, there seems somehow to be an
assumption that "infinite loop" is the only way that a program can
fail to halt. If only it was so simple!

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Lange

[Skep Dick]

On Tuesday, 2 August 2022 at 20:17:07 UTC+2, Mr Flibble wrote:
> You are wrong: I am extending the definition of what constitutes a
> halt decider which is my right as both a computer scientist and a
> software engineer.
>
> If the only way to detect pathological input is through the use of a
> simulating halt decider then so be it.

Redefining a shit as sugar won't make it taste any sweeter.

The issue is not about definitions. The issue is... argh. Never mind. You don't really care what the issue is. Do you?

[Mr Flibble]

Actually at the moment the issue *is* about definitions. The only
rebuttal of my solution I have received so far is that my decider isn't
a halt decider because it defines a third outcome: invalid input.

/Flibble

[Mikko]

No, you can't. The problem definition is what it is and you
can't add anything to it, and it says or at least imlies that
if H(M, I) signals an exception it is not a halt decider.

Mikko

[Mr Flibble]

On Tue, 2 Aug 2022 21:41:54 +0300

Yes I can and I have. I have extended the definition of a halt decider.

/Flibble

[Mikko]

If there is two conflicting definitions for the same term the definition
published earlier is the valid one.

Mikko

[Mr Flibble]

On Tue, 2 Aug 2022 21:56:19 +0300

Who says?

/Flibble

[Skep Dick]

No, it's not about definitions.

If it was about definitions then your "halt decider" needs one more output!

Your halting decider needs at least one more output: The output which signals "I am not going to halt on this input"

[Skep Dick]

On Tuesday, 2 August 2022 at 20:56:22 UTC+2, Mikko wrote:
> If there is two conflicting definitions for the same term the definition
> published earlier is the valid one.

Ehh? That's bullshit.

There are no preferential definitions. Equivalent definitions are equivalent. Lambda calculus and Turing machines are equivalent definitions of "computation".

Lambda Calculus and Turing machines are *NOT* equivalent definitions of "computation" to Infinite Time Turing Machines.

A more complete definition is a better definition. And more complete definitions ALWAYS come later.

[Skep Dick]

On Tuesday, 2 August 2022 at 20:38:53 UTC+2, Mr Flibble wrote:

> Actually at the moment the issue *is* about definitions. The only
> rebuttal of my solution I have received so far is that my decider isn't
> a halt decider because it defines a third outcome: invalid input.

You keep making the exact same errors as Olcott. Probably because you are Olcott. He doesn't understand Currying either.

Having one function which answers two different questions( Does it halt? is it valid?) is the same as having two separate deciders.

bool check_validity(P);
bool check_halting(P);

bool answers[2] fibble_decider(P){
answers[0] = check_validity(P);
answers[1] = check_halting(P);
return answers;
}

[Mr Flibble]

How can it be the same? My solution has THREE outcomes whereas your
nonsense has FOUR outcomes. Last time I checked 3 != 4.

/Flibble