On Strachey

[Mr Flibble]

Strachey's "Impossible Program" [Strachey, 1965] is indeed impossible
but not for the reason Strachey suggests. Strachey's impossible program
is impossible not due to the contradiction he posits but is instead
impossible due to an invalid infinite recursion (a category error
in this case) which prevents the contradiction from ever being realised.
As Strachey claims his "Impossible Program" proof is based on
communication he had with Turing it seems reasonable to assume that
Turing's proof has the same flaw.

I suppose at some point I should stop trolling and actually read what
Turing wrote so I don't have to rely on what seems reasonable. :D

/Flibble

[olcott]

What Turing wrote never mentions halting:
https://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf

This proof is the clearest one that provide all of its details as
explicit state transitions:
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

All of the experts will agree that it is accurately specifies the
halting theorem.

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

On Thu, 5 May 2022 16:30:41 -0500
olcott <polc...@gmail.com> wrote:

> On 5/5/2022 2:45 PM, Mr Flibble wrote:
> > Strachey's "Impossible Program" [Strachey, 1965] is indeed
> > impossible but not for the reason Strachey suggests. Strachey's
> > impossible program is impossible not due to the contradiction he
> > posits but is instead impossible due to an invalid infinite
> > recursion (a category error in this case) which prevents the
> > contradiction from ever being realised. As Strachey claims his
> > "Impossible Program" proof is based on communication he had with
> > Turing it seems reasonable to assume that Turing's proof has the
> > same flaw.
> >
> > I suppose at some point I should stop trolling and actually read
> > what Turing wrote so I don't have to rely on what seems reasonable.
> > :D
> >
> > /Flibble
> >
>
> What Turing wrote never mentions halting:
> https://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf

"Alan Turing proved in 1936 that a general algorithm to solve the
halting problem for all possible program-input pairs cannot exist"
[Wikipedia, 2022]

/Flibble

[olcott]

Yes what you said is equally true:
https://www.sciencedirect.com/science/article/pii/S235222082100050X

[Mr Flibble]

On Thu, 5 May 2022 16:48:21 -0500

The fact it wasn't called The Halting Problem when Turing wrote his
paper doesn't really change any facts on the ground?

/Flibble

[olcott]

Right, so it proves that you are right and Ben is wrong.
What Turing wrote in 1936 is now known as the halting theorem.

[Ben]

>>> Yes what you said is equally true:
>>> https://www.sciencedirect.com/science/article/pii/S235222082100050X
>>
>> The fact it wasn't called The Halting Problem when Turing wrote his
>> paper doesn't really change any facts on the ground?
>

> Right, so it proves that you are right and Ben is wrong.
> What Turing wrote in 1936 is now known as the halting theorem.

Two people who have not read the paper have persuaded themselves that
someone who has must be wrong about it. Is there any need for facts?

Turing's 1936 paper is not about halting. It proves a related theorem
about the outputs -- the symbols a TM writes to the tape. Did Turing
know, in 1936, that halting could not be decided? Almost certainly.
But he didn't prove it because his concern was about the strings
written, even those that are not finite.

(It also uses a term, "cycle-free" that is likely to mislead the casual
reader.)

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

[olcott]

Turing's paper is construed to be the foundation of the halting theorem
even though the term halting was not applied to it until 1958.
https://www.sciencedirect.com/science/article/pii/S235222082100050X

[Mr Flibble]

On Fri, 06 May 2022 02:34:35 +0100
Ben <ben.u...@bsb.me.uk> wrote:

> Two people who have not read the paper have persuaded themselves that
> someone who has must be wrong about it. Is there any need for facts?
>
> Turing's 1936 paper is not about halting.

[Wikipedia, 2022] disagrees with you:

"Alan Turing proved in 1936 that a general algorithm to solve the

halting problem for all possible program-input pairs cannot exist."

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

/Flibble

[Ben]

And? People like you write wikipedia articles.

This seems like a very odd debate since you could simply see for your
self. Academics (like Turing) publish papers so we can all see what
they are saying.

--
Ben.

[Ben]

It is not only construed to be, it /is/ the foundation of the halting
theorem.

[Jeff Barnett]

I pulled Davis /The undecidable/ off the shelf recently - it includes
The Turing paper. I think that you have been referring to Chapter or
Section 8 and that is as close to mucking about with halting as he got.
Your reading is, of course, correct. The fact that the idiot and his
sock puppet were the other side of the dialogue, kept me from butting in
for a few reasons: 1) the term "cycle-free" being used as you noted
above and 2) the use of a "diagonal argument" for what he did prove.
Both terms, I thought, would drive the two/one to utter madness and
confusion since we've seen that diagonal arguments are beyond their
comprehension and cycle-free would conjure visions of infinite recursion
and the "Demons of the Christmas story about Scrooge". When ignorant of
or confronted with words not understood they go into a most interesting
tail (or is that tale) spin. So I passed. Since you broached the topic,
I thought what the hell .....
--
Jeff Barnett

[Mikko]

On 2022-05-05 19:45:51 +0000, Mr Flibble said:

> Strachey's "Impossible Program" [Strachey, 1965] is indeed impossible
> but not for the reason Strachey suggests. Strachey's impossible program
> is impossible not due to the contradiction he posits but is instead
> impossible due to an invalid infinite recursion (a category error
> in this case) which prevents the contradiction from ever being realised.
> As Strachey claims his "Impossible Program" proof is based on
> communication he had with Turing it seems reasonable to assume that
> Turing's proof has the same flaw.

A category error does not lead to an infinite recursion. A category error
is detected by the compiler, which then doesn't compile it, so no recursion
is executed.

An infinite recursion typically results in a stack overflow abort but
sometimes can be a valid structure in a program. Some programs are
required to never stop and an infinite tail recursion may be one way to
achieve that.

> I suppose at some point I should stop trolling and actually read what
> Turing wrote so I don't have to rely on what seems reasonable. :D

You needn't stop trolling in order to read what Turing wrote. But you
might be a more successfull troll if you switch to a less competed topic.

Mikko

[Mr Flibble]

On Fri, 06 May 2022 03:50:46 +0100
Ben <ben.u...@bsb.me.uk> wrote:

> Mr Flibble <fli...@reddwarf.jmc> writes:
>
> > On Fri, 06 May 2022 02:34:35 +0100
> > Ben <ben.u...@bsb.me.uk> wrote:
> >
> >> Two people who have not read the paper have persuaded themselves
> >> that someone who has must be wrong about it. Is there any need
> >> for facts?
> >>
> >> Turing's 1936 paper is not about halting.
> >
> > [Wikipedia, 2022] disagrees with you:
> >
> > "Alan Turing proved in 1936 that a general algorithm to solve the
> > halting problem for all possible program-input pairs cannot exist."
> >
> > https://en.wikipedia.org/wiki/Halting_problem
>
> And? People like you write wikipedia articles.

Most Wikipedia articles crowd source peer review by multiple experts in
their field: who should I trust? Those experts or random guy on
Usenet? I think the answer is obvious.

If you think the Wikipedia is incorrect then either correct it and have
your corrections peer reviewed or shut the fuck up.

/Flibble

[Mr Flibble]

On Fri, 6 May 2022 16:09:13 +0300
Mikko <mikko....@iki.fi> wrote:

> On 2022-05-05 19:45:51 +0000, Mr Flibble said:
>
> > Strachey's "Impossible Program" [Strachey, 1965] is indeed
> > impossible but not for the reason Strachey suggests. Strachey's
> > impossible program is impossible not due to the contradiction he
> > posits but is instead impossible due to an invalid infinite
> > recursion (a category error in this case) which prevents the
> > contradiction from ever being realised. As Strachey claims his
> > "Impossible Program" proof is based on communication he had with
> > Turing it seems reasonable to assume that Turing's proof has the
> > same flaw.
>
> A category error does not lead to an infinite recursion. A category
> error is detected by the compiler, which then doesn't compile it, so
> no recursion is executed.

The category error (as an invalid infinite recursion) is in the
definition of the proof itself: it is NOT some function call-like
infinite recursion that gets executed at runtime.

> An infinite recursion typically results in a stack overflow abort but
> sometimes can be a valid structure in a program. Some programs are
> required to never stop and an infinite tail recursion may be one way
> to achieve that.

As I said the category error is not runtime function call-like infinite
recursion.

/Flibble

[Mr Flibble]

Gas.

/Flibble

[Mikko]

On 2022-05-06 13:59:44 +0000, Mr Flibble said:

> On Fri, 6 May 2022 16:09:13 +0300
> Mikko <mikko....@iki.fi> wrote:
>
>> On 2022-05-05 19:45:51 +0000, Mr Flibble said:
>>
>>> Strachey's "Impossible Program" [Strachey, 1965] is indeed
>>> impossible but not for the reason Strachey suggests. Strachey's
>>> impossible program is impossible not due to the contradiction he
>>> posits but is instead impossible due to an invalid infinite
>>> recursion (a category error in this case) which prevents the
>>> contradiction from ever being realised.

Although the sentence containing the alleged "category error" is not
identifed, this seems to say that it is in the "Impossible program".

> The category error (as an invalid infinite recursion) is in the
> definition of the proof itself: it is NOT some function call-like
> infinite recursion that gets executed at runtime.

However, this says that it is elsewhere but still does not identify
the sentence. Claims of the type "there is a thing that is distinct
from everything one could mention" are not credible without a very
good proof.

Mikko

[olcott]

This paper makes all these things concrete in the x86utm operating system.

Halting problem undecidability and infinitely nested simulation
May 2021

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

[olcott]

Ben really hates to get down to the essence of things he loves to
quibble over tiny little inessential details. It is currently understood
that Turing's 1936 paper does establish what is now known as the halting
theorem.

[olcott]

It is certainly a Category error in Gödel's G, Tarski's p and the Liar
Paradox. {G, p, LP} are incorrectly placed in the category of a logic
sentence / truth bearer.

Incomplete(F) ↔ ∃G ((F ⊬ G) ∧ (F ⊬ ¬G)).

If a math formula has infinitely recursive definition it is simply
incorrect. If a TM / input pair specifies infinitely nested simulation
halt decider H can spot this and reject it.

[olcott]

On 5/6/2022 8:09 AM, Mikko wrote:
> On 2022-05-05 19:45:51 +0000, Mr Flibble said:
>
>> Strachey's "Impossible Program" [Strachey, 1965] is indeed impossible
>> but not for the reason Strachey suggests. Strachey's impossible program
>> is impossible not due to the contradiction he posits but is instead
>> impossible due to an invalid infinite recursion (a category error
>> in this case) which prevents the contradiction from ever being realised.
>> As Strachey claims his "Impossible Program" proof is based on
>> communication he had with Turing it seems reasonable to assume that
>> Turing's proof has the same flaw.
>
> A category error does not lead to an infinite recursion. A category error
> is detected by the compiler, which then doesn't compile it, so no recursion
> is executed.
>
> An infinite recursion typically results in a stack overflow abort but
> sometimes can be a valid structure in a program. Some programs are
> required to never stop and an infinite tail recursion may be one way to
> achieve that.
>

This paper shows all of the details of the actual issue using C/x86 code
for H and P that is directly executed in the x86utm operating system.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation


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

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
}

int main()
{
int halts = H(P,P);

}

>> I suppose at some point I should stop trolling and actually read what
>> Turing wrote so I don't have to rely on what seems reasonable. :D
>
> You needn't stop trolling in order to read what Turing wrote. But you
> might be a more successfull troll if you switch to a less competed topic.
>
> Mikko
>
>
>

[Ben]

Mr Flibble <fli...@reddwarf.jmc> writes:

> On Fri, 06 May 2022 03:50:46 +0100
> Ben <ben.u...@bsb.me.uk> wrote:
>
>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>
>> > On Fri, 06 May 2022 02:34:35 +0100
>> > Ben <ben.u...@bsb.me.uk> wrote:
>> >
>> >> Two people who have not read the paper have persuaded themselves
>> >> that someone who has must be wrong about it. Is there any need
>> >> for facts?
>> >>
>> >> Turing's 1936 paper is not about halting.
>> >
>> > [Wikipedia, 2022] disagrees with you:
>> >
>> > "Alan Turing proved in 1936 that a general algorithm to solve the
>> > halting problem for all possible program-input pairs cannot exist."
>> >
>> > https://en.wikipedia.org/wiki/Halting_problem
>>
>> And? People like you write wikipedia articles.
>
> Most Wikipedia articles crowd source peer review by multiple experts in
> their field: who should I trust? Those experts or random guy on
> Usenet? I think the answer is obvious.

I never said you should trust me. I said you could just read the paper
and find out for yourself.

> If you think the Wikipedia is incorrect then either correct it and have
> your corrections peer reviewed or shut the fuck up.

Or I can just suggest you find out for yourself and leave it at that
because, as I have already said, the article also quotes Copleland:

"It is often said that Turing stated and proved the halting theorem in
'On Computable Numbers', but strictly this is not true"

so I don't feel an edit is needed.

--
Ben.

[Ben]

olcott <polc...@gmail.com> writes:

> On 5/6/2022 8:56 AM, Mr Flibble wrote:
>> On Fri, 06 May 2022 03:50:46 +0100
>> Ben <ben.u...@bsb.me.uk> wrote:
>>
>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>>
>>>> On Fri, 06 May 2022 02:34:35 +0100
>>>> Ben <ben.u...@bsb.me.uk> wrote:
>>>>
>>>>> Two people who have not read the paper have persuaded themselves
>>>>> that someone who has must be wrong about it. Is there any need
>>>>> for facts?
>>>>>
>>>>> Turing's 1936 paper is not about halting.
>>>>
>>>> [Wikipedia, 2022] disagrees with you:
>>>>
>>>> "Alan Turing proved in 1936 that a general algorithm to solve the
>>>> halting problem for all possible program-input pairs cannot exist."
>>>>
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> And? People like you write wikipedia articles.
>> Most Wikipedia articles crowd source peer review by multiple experts in
>> their field: who should I trust? Those experts or random guy on
>> Usenet? I think the answer is obvious.
>> If you think the Wikipedia is incorrect then either correct it and have
>> your corrections peer reviewed or shut the fuck up.
>> /Flibble
>>
>
> Ben really hates to get down to the essence of things he loves to
> quibble over tiny little inessential details.

So why did I go even further than you did to say of the result in that
paper:

"It is not only construed to be, it /is/ the foundation of the halting

theorem."?

> It is currently understood that Turing's 1936 paper does establish
> what is now known as the halting theorem.

Yes, provided you are not using established to mean proved as some
people do. Turing proved a very closely related result from with the
halting theorem would follow as a corollary.

The halting theorem follows, trivially, from lots of simpler theorems,
none of which have you bothered to read. In Linz, the theorem is
presented as a corollary of a simpler theorem in chapter 11.

[olcott]

11.3, 11.4, and 11.5. I will look at them.

[Ben]

Goodness! A good move. Why the change of heart?

[olcott]

On 5/6/2022 8:07 PM, Ben wrote:
> olcott <polc...@gmail.com> writes:
>
>> On 5/6/2022 7:11 PM, Ben wrote:
>
>>> The halting theorem follows, trivially, from lots of simpler theorems,
>>> none of which have you bothered to read. In Linz, the theorem is
>>> presented as a corollary of a simpler theorem in chapter 11.
>>
>> 11.3, 11.4, and 11.5. I will look at them.
>
> Goodness! A good move. Why the change of heart?
>

There is enough progress now that I don't have to have an absolutely
single-minded focus.

THIS IS AN EASILY VERIFIABLE FACT:
Both H() and H1() take the machine code of P as input parameters and
correctly compute the mapping from this input to an accept ore reject
state on the basis of the actual behavior that these inputs actually
specify.

This makes them correct halt deciders for this input. I have correctly
refuted the halting theorem on the basis of the above facts. That people
here insist on contradicting facts that they know are true is not any
actual rebuttal at all.

[Richard Damon]

On 5/6/22 9:34 PM, olcott wrote:
> On 5/6/2022 8:07 PM, Ben wrote:
>> olcott <polc...@gmail.com> writes:
>>
>>> On 5/6/2022 7:11 PM, Ben wrote:
>>
>>>> The halting theorem follows, trivially, from lots of simpler theorems,
>>>> none of which have you bothered to read.  In Linz, the theorem is
>>>> presented as a corollary of a simpler theorem in chapter 11.
>>>
>>> 11.3, 11.4, and 11.5. I will look at them.
>>
>> Goodness!  A good move.  Why the change of heart?
>>
>
> There is enough progress now that I don't have to have an absolutely
> single-minded focus.
>
> THIS IS AN EASILY VERIFIABLE FACT:
> Both H() and H1() take the machine code of P as input parameters and
> correctly compute the mapping from this input to an accept ore reject
> state on the basis of the actual behavior that these inputs actually
> specify.
>
> This makes them correct halt deciders for this input. I have correctly
> refuted the halting theorem on the basis of the above facts. That people
> here insist on contradicting facts that they know are true is not any
> actual rebuttal at all.
>

No, to be correct Halt Deciders, they need to compute the HALTING
FUNCTION of that input, which is the behavior of the machine + input
represented by their input, in this case P(P).

Since you claim that this is not what they compute (because you say they
can't), they are not Halt Decider.

Since your definition of "Correct Simulation" disagrees with the
definiton used by the Halting Problem, you are not working on it, but on
your POOP, and you can't actually say anything about halting based on
your work.

Note, the definition of Halting refers to the behavior of a Machine, and
that machine is what the first part of the input represents, which is P.
Since you say P isn't the input, then your representation doesn't match
that needed to be a Halt Decider, it is just that simple.

Maybe once you try to write an actual Turing Machine and understand the
difference between the actual tape and what it represents, maybe you
will understand.

[Ben]

olcott <polc...@gmail.com> writes:

> On 5/6/2022 8:07 PM, Ben wrote:
>> olcott <polc...@gmail.com> writes:
>>
>>> On 5/6/2022 7:11 PM, Ben wrote:
>>
>>>> The halting theorem follows, trivially, from lots of simpler theorems,
>>>> none of which have you bothered to read. In Linz, the theorem is
>>>> presented as a corollary of a simpler theorem in chapter 11.
>>>
>>> 11.3, 11.4, and 11.5. I will look at them.
>> Goodness! A good move. Why the change of heart?
>
> There is enough progress now that I don't have to have an absolutely
> single-minded focus.

Progress?

> THIS IS AN EASILY VERIFIABLE FACT:
> Both H() and H1() take the machine code of P as input parameters and
> correctly compute the mapping from this input to an accept ore reject
> state on the basis of the actual behavior that these inputs actually
> specify.

But H does not decide the halting of P(P). What ever you are hiding by
all that waffle, it's just a way to avoid having to say that H(P,P) ==
false even though P(P) halts.

You've recently tried to imply that it's somehow invalid for is to even
ask for a D such that D(X,Y) == true if and only if X(Y) halts and false
otherwise, because X(Y) is not "an input". But that's just a recent
ruse. You've known how the C-version of the halting problem is defined
for years.

[olcott]

On 5/7/2022 5:47 PM, Ben wrote:
> olcott <polc...@gmail.com> writes:
>
>> On 5/6/2022 8:07 PM, Ben wrote:
>>> olcott <polc...@gmail.com> writes:
>>>
>>>> On 5/6/2022 7:11 PM, Ben wrote:
>>>
>>>>> The halting theorem follows, trivially, from lots of simpler theorems,
>>>>> none of which have you bothered to read. In Linz, the theorem is
>>>>> presented as a corollary of a simpler theorem in chapter 11.
>>>>
>>>> 11.3, 11.4, and 11.5. I will look at them.
>>> Goodness! A good move. Why the change of heart?
>>
>> There is enough progress now that I don't have to have an absolutely
>> single-minded focus.
>
> Progress?
>
>> THIS IS AN EASILY VERIFIABLE FACT:
>> Both H() and H1() take the machine code of P as input parameters and
>> correctly compute the mapping from this input to an accept ore reject
>> state on the basis of the actual behavior that these inputs actually
>> specify.
>
> But H does not decide the halting of P(P).

int sum(int N , int M)
{
return (N + M);
}

It is not supposed to in the same way that sum(3,4) is not supposed to
provide the sum of (5,7).

Why is this so difficult for you?

You know that if anyone insisted that sum(3,4) must return the value of
sum(5,7) that they are wrong.

Why is it so hard to understand that H(P,P) must provide the halt status
of its actual input on the basis of the actual behavior specified by
this actual input?

It is just like you are insisting that you know for sure that sum(3,4)
is definitely 12. How nuts is that?

> What ever you are hiding by
> all that waffle, it's just a way to avoid having to say that H(P,P) ==
> false even though P(P) halts.
>
> You've recently tried to imply that it's somehow invalid for is to even
> ask for a D such that D(X,Y) == true if and only if X(Y) halts and false
> otherwise, because X(Y) is not "an input". But that's just a recent
> ruse. You've known how the C-version of the halting problem is defined
> for years.
>


--

[Dennis Bush]

Then why do you insist that H(P,P) must return the value of H(Pn,Pn)?

>
> Why is it so hard to understand that H(P,P) must provide the halt status
> of its actual input on the basis of the actual behavior specified by
> this actual input?

The *definition* of the problem states that the actual behavior of the actual input to H(P,P) is P(P).

You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.

If by "the actual behavior of the actual input" you mean "can the decider simulate the input to a final state", then that means that any simulating halt decider that reports non-halting is necessarily correct, which means that Ha3(N,5) == false is necessarily correct because by your definition "the actual behavior of the actual input" to Ha3(N,5) is non-halting.

Or you can just admit that H is unable to meet the requirements as specified:

H(P,P) == true if and only if P(P) halts, and
H(P,P) == false if and only if P(P) does not halt

And yes, H is expected by this definition to decide on non-inputs because the inputs represent non-inputs.

[Ben]

olcott <No...@NoWhere.com> writes:

> On 5/7/2022 5:47 PM, Ben wrote:
>> olcott <polc...@gmail.com> writes:
>>
>>> On 5/6/2022 8:07 PM, Ben wrote:
>>>> olcott <polc...@gmail.com> writes:
>>>>
>>>>> On 5/6/2022 7:11 PM, Ben wrote:
>>>>
>>>>>> The halting theorem follows, trivially, from lots of simpler theorems,
>>>>>> none of which have you bothered to read. In Linz, the theorem is
>>>>>> presented as a corollary of a simpler theorem in chapter 11.
>>>>>
>>>>> 11.3, 11.4, and 11.5. I will look at them.
>>>> Goodness! A good move. Why the change of heart?
>>>
>>> There is enough progress now that I don't have to have an absolutely
>>> single-minded focus.
>> Progress?
>>
>>> THIS IS AN EASILY VERIFIABLE FACT:
>>> Both H() and H1() take the machine code of P as input parameters and
>>> correctly compute the mapping from this input to an accept ore reject
>>> state on the basis of the actual behavior that these inputs actually
>>> specify.
>>
>> But H does not decide the halting of P(P).
>
> int sum(int N , int M)
> {
> return (N + M);
> }
>
> It is not supposed to in the same way that sum(3,4) is not supposed to
> provide the sum of (5,7).

You don't get to say. The problem you took on already existed. You've
only recently started this silly H(X,Y) is not supposed to provide the
halting of X(Y) after you where getting nowhere trying to persuade the
world that the wrong answer was the right one (because of what would
happen if...).

This is, I suppose, as close to an admission as you will ever make that
a halt decider that /is/ supposed to report on the halting of the
function call in question cant not exit.

> Why is this so difficult for you?
>
> You know that if anyone insisted that sum(3,4) must return the value
> of sum(5,7) that they are wrong.

Just as I know that Halts(X,Y) == false, even though X(Y) halts, is
wrong. It's wrong simply by definition.

> Why is it so hard to understand that H(P,P) must provide the halt
> status of its actual input on the basis of the actual behavior
> specified by this actual input?

You don't get to choose what H must decide. What the "input" (actually
the arguments) specify is defined by us, no you. We picked the problem,
you failed to find a solution. The behaviour that H(X,Y) must determine
is that of the call X(Y). Your H is wrong by definition.

[olcott]

The definition of decider requires it to based its decision on whatever
its input specifies.

Both H(P,P) and H1(P,P) use this exact literal byte string as their
input therefore it seems enormously dishonest of you to refer to the
same literal string using different subscripts indicating a difference
of the same string with itself.

558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]

>>
>> Why is it so hard to understand that H(P,P) must provide the halt status
>> of its actual input on the basis of the actual behavior specified by
>> this actual input?
>
> The *definition* of the problem states that the actual behavior of the actual input to H(P,P) is P(P).

Whomever wrote that definition also knows that

THIS IS SET IN STONE:
All deciders only compute the mapping from their input parameters to an
accept/reject state on the basis of the actual properties actually
specified by this input

THIS LOGICALLY FOLLOWS FROM THAT:
Since a halt decider is a type of decider this means that all halt
deciders only compute the mapping from their input parameters to an
accept/reject state on the basis of the actual behavior actually
specified by this input.

This means that they simply made the false assumption that the correctly
simulated input to every simulating halt decider must always have
exactly the same behavior as the direct execution of this input.

It is a weird exception that they never noticed because they never
bothered to pursue simulating halt deciders applied to the HP to its
logical conclusion.

> You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.
>

I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
I say that the correctly simulated input to H(P,P) never reaches its
final state (thus never halts) whether or not its simulation is aborted.

> If by "the actual behavior of the actual input" you mean "can the decider simulate the input to a final state", then that means that any simulating halt decider that reports non-halting is necessarily correct,

Although technically correct use of terms I consider this utterly
ridiculous to say that a decider decides when all it does it guess.

I don't consider that a decder has decided anything unless it also
proves that its decision is correct. H(P,P)==false does that.
H1(P,P)==true also does that.

> which means that Ha3(N,5) == false is necessarily correct because by your definition "the

Can we please quite talking about you crackpot H3 that was intentionally
designed to get the wrong answer ???

actual behavior of the actual input" to Ha3(N,5) is non-halting.
>
> Or you can just admit that H is unable to meet the requirements as specified:
>
> H(P,P) == true if and only if P(P) halts, and
> H(P,P) == false if and only if P(P) does not halt
>

The requirements contradict the definition of a decider.
The author of these requirements was not aware of that.

> And yes, H is expected by this definition to decide on non-inputs because the inputs represent non-inputs.

That is exactly the same as requiring sum(3,4) to return 12, quite nuts.

[Dennis Bush]

Which in the case of H(P,P) is *defined* to be P(P)

>
> Both H(P,P) and H1(P,P) use this exact literal byte string as their
> input therefore it seems enormously dishonest of you to refer to the
> same literal string using different subscripts indicating a difference
> of the same string with itself.

What I was saying is that you think that H sees infinite simulation which only exists in Pn(Pn)

Which in the case of H(P,P) is *defined* to be P(P)

>
> THIS LOGICALLY FOLLOWS FROM THAT:
> Since a halt decider is a type of decider this means that all halt
> deciders only compute the mapping from their input parameters to an
> accept/reject state on the basis of the actual behavior actually
> specified by this input.

Which in the case of H(P,P) is *defined* to be P(P)

>
> This means that they simply made the false assumption that the correctly
> simulated input to every simulating halt decider must always have
> exactly the same behavior as the direct execution of this input.

There is no assumption. A correct simulation of a machine is DEFINED to have the exact same behavior as the actual machine. What good would a simulation be if that wasn't the case?

>
> It is a weird exception that they never noticed because they never
> bothered to pursue simulating halt deciders applied to the HP to its
> logical conclusion.

Just because H(P,P) is unable to simulate its input to a final state doesn't mean it's correct.

> > You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.
> >
> I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
> I say that the correctly simulated input to H(P,P) never reaches its
> final state (thus never halts) whether or not its simulation is aborted.

That is false, because the correctly simulated to input to H(P,P) is performed by H1(P,P) which does reach a final state.

If by "whether or not its simulation is aborted" you mean if the H embedded in P is changed, that can't happen as it changes the input. What it sounds like you mean by this is that Hi(Pi,Pi) either does not halt or always returns false for any Hi and the corresponding Pi built from it. Just because all of these unrelated H's return false for their corresponding P's doesn't make them all correct. This is like treating "hello world" and minesweeper the same.

> > If by "the actual behavior of the actual input" you mean "can the decider simulate the input to a final state", then that means that any simulating halt decider that reports non-halting is necessarily correct,
> Although technically correct use of terms I consider this utterly
> ridiculous to say that a decider decides when all it does it guess.

And guessing is exactly what H is doing, and it guesses wrong.

>
> I don't consider that a decder has decided anything unless it also
> proves that its decision is correct. H(P,P)==false does that.
> H1(P,P)==true also does that.

FALSE. H1(P,P)==true proves that H(P,P)==false is wrong. The simulation performed by both is identical up to the point that H aborts. H1 is then able to continue simulating past the point that H aborted and reach a final state, proving that H(P,P) == false is wrong.

If H1(P,P) == true doesn't prove H(P,P) == false incorrect then Ha7(N,5) == true doesn't prove Ha3(N,5) == false incorrect.

> > which means that Ha3(N,5) == false is necessarily correct because by your definition "the
> Can we please quite talking about you crackpot H3 that was intentionally
> designed to get the wrong answer ???
> actual behavior of the actual input" to Ha3(N,5) is non-halting.

I'm not the one saying Ha3 is correct. You are, by your definition of what the right answer should be. That's why I keep talking about it. It's wrong in EXACTLY the same way H is wrong, specifically it aborts too soon. You don't like talking about Ha3 because you can't clearly state why it is wrong without also proving that H is wrong.

> >
> > Or you can just admit that H is unable to meet the requirements as specified:
> >
> > H(P,P) == true if and only if P(P) halts, and
> > H(P,P) == false if and only if P(P) does not halt
> >
> The requirements contradict the definition of a decider.
> The author of these requirements was not aware of that.

Doesn't matter, as that is the definition of the problem. You don't get to say it's wrong. Just because the requirements can't be met (as the proof shows) doesn't mean they're wrong.

> > And yes, H is expected by this definition to decide on non-inputs because the inputs represent non-inputs.
> That is exactly the same as requiring sum(3,4) to return 12, quite nuts.

If sum is required to return the product of its arguments (despite its name), then yes.

[olcott]

In this case it is the same as if {dogs} are defined to be {cats}.

>>
>> Both H(P,P) and H1(P,P) use this exact literal byte string as their
>> input therefore it seems enormously dishonest of you to refer to the
>> same literal string using different subscripts indicating a difference
>> of the same string with itself.
>
> What I was saying is that you think that H sees infinite simulation which only exists in Pn(Pn)

All that crazy bullshit about subscripted names of subscripts is
extremely deceptive

I am ONLY referring to this literal string:
558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
as x86 machine code correctly simulated by H(P,P) and H1(P,P).

In this case it is the same as if {dogs} are defined to be {cats}.

>
>>
>> THIS LOGICALLY FOLLOWS FROM THAT:
>> Since a halt decider is a type of decider this means that all halt
>> deciders only compute the mapping from their input parameters to an
>> accept/reject state on the basis of the actual behavior actually
>> specified by this input.
>
> Which in the case of H(P,P) is *defined* to be P(P)
>

In this case it is the same as if {dogs} are defined to be {cats}.
If anyone assigns non-decider properties to a decider they are wrong in
the same way that it is wrong to assign {cat} properties to a {dog}.

>>
>> This means that they simply made the false assumption that the correctly
>> simulated input to every simulating halt decider must always have
>> exactly the same behavior as the direct execution of this input.
>
> There is no assumption. A correct simulation of a machine is DEFINED to have the exact same behavior as the actual machine. What good would a simulation be if that wasn't the case?
>
>>
>> It is a weird exception that they never noticed because they never
>> bothered to pursue simulating halt deciders applied to the HP to its
>> logical conclusion.
>
> Just because H(P,P) is unable to simulate its input to a final state doesn't mean it's correct.
>
>
>>> You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.
>>>
>> I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
>> I say that the correctly simulated input to H(P,P) never reaches its
>> final state (thus never halts) whether or not its simulation is aborted.
>
> That is false, because the correctly simulated to input to H(P,P) is performed by H1(P,P) which does reach a final state.

H(P,P) does correctly map the behavior of its inputs to its reject state
this is a verifiable fact.

H1(P,P) does correctly map the behavior of its inputs to its accept
state this is a verifiable fact.

I am probably not going to bother to talk to people that insist on
disagreeing with verified facts.

[Richard Damon]

Please give your exact definition of a decider that you are using.

>
> Both H(P,P) and H1(P,P) use this exact literal byte string as their
> input therefore it seems enormously dishonest of you to refer to the
> same literal string using different subscripts indicating a difference
> of the same string with itself.

except that byte string isn't a fully specified program, so you have an
error in you definition.

This input references something outside of it, so that program segment
can have virtually any behavior imaginable.


(Note, call to 0000826 is NOT the same as a "Call H" instruction, as not
all machines have your H at that address.)

But the only ACTUAL PROPERTY that it needs to look at is the behavior of
the program the input represents, whether it halts or not.

Now, if that byte string included the required copy of the code of H,
and that H was actually a difinite program like you claim it is, then
this halting property is actually well defined, we can just run this
program and see if it halts.

Now,

>
> THIS LOGICALLY FOLLOWS FROM THAT:
> Since a halt decider is a type of decider this means that all halt
> deciders only compute the mapping from their input parameters to an
> accept/reject state on the basis of the actual behavior actually
> specified by this input.

Right, would the program (the WHOLE PROGRAM, so we need the WHOLE
PROGRAM) run to a halt when exectuted.

Since P(P) does halt if H(P,P) returns false, we can see that H(P,P)
returning false must be wrong, as it would have needed to have returned
true for that exact byte sequence input.

>
> This means that they simply made the false assumption that the correctly
> simulated input to every simulating halt decider must always have
> exactly the same behavior as the direct execution of this input.

Nope, YOU are making the error, because your logic isn't about *A*
program H.

>
> It is a weird exception that they never noticed because they never
> bothered to pursue simulating halt deciders applied to the HP to its
> logical conclusion.

Nope, not an execptiion, just a flaw in your logic because your H isn't
an actual finite definite algorthm.

>
>> You *say* there is infinite simulation but there is not *because* the
>> copy of H inside P *will* abort.
>>
>
> I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
> I say that the correctly simulated input to H(P,P) never reaches its
> final state (thus never halts) whether or not its simulation is aborted.

Nope, because you use the wrong definition for too many things.

You H is NOT a computation, because it doesn't have a finite fixed
algorithm, but uses words that requrie it to look into the future with
some sort of crystal ball.

You do not define "Correct Simulation", perhaps because the thing you
are simulating isn't a computation because it is based on your H which
isn't one.

>
>> If by "the actual behavior of the actual input" you mean "can the
>> decider simulate the input to a final state", then that means that any
>> simulating halt decider that reports non-halting is necessarily correct,
>
> Although technically correct use of terms I consider this utterly
> ridiculous to say that a decider decides when all it does it guess.
>
> I don't consider that a decder has decided anything unless it also
> proves that its decision is correct. H(P,P)==false does that.
> H1(P,P)==true also does that.

Then show an ACTUAL proof.

Note, H needs to prove that the P built on it will not halt. Not that H
can not simulate P to its final state. Since H(P,P) is claiming false is
the right answer, its proof needs to be compatible with the H(P,P)
inside P returning that same value.

>
>> which means that Ha3(N,5) == false is necessarily correct because by
>> your definition "the
>
> Can we please quite talking about you crackpot H3 that was intentionally
> designed to get the wrong answer ???
>
> actual behavior of the actual input" to Ha3(N,5) is non-halting.
>>
>> Or you can just admit that H is unable to meet the requirements as
>> specified:
>>
>> H(P,P) == true if and only if P(P) halts, and
>> H(P,P) == false if and only if P(P) does not halt
>>
>
> The requirements contradict the definition of a decider.
> The author of these requirements was not aware of that.

Nok YOUR requirements contradict the definiton of a Halting Decider, (or
any specfic type of decider) as the answer to a XX Decider, must be
based on the XX mapping of the input to the decide, and the Halting
Mapping of P,P is to if P(P) Halts. If you are trying to show that it is
impossible to even properlly ask an H that question, then you have just
admitted that a Halt Decider is impossible, as if you can't even ask the
right question, you can't expect it to be able to give the right answer.

Maybe H correctly computes that alternate mapping you have defined, your
Other Problem mapping, but that just makes your H a POOP decider, not a
Halting Decider.

[Richard Damon]

On 5/7/22 8:19 PM, olcott wrote:

Except that isn't the correct string for either Pn or Pa, as we need the
contents of memory address 826 and beyond, or the program isn't actually
specifed by this input.

This is your fatal flaw in your "proof".

Your system is built on broken definitions.

[Dennis Bush]

So no rebuttal, just a bad analogy.

> >>
> >> Both H(P,P) and H1(P,P) use this exact literal byte string as their
> >> input therefore it seems enormously dishonest of you to refer to the
> >> same literal string using different subscripts indicating a difference
> >> of the same string with itself.
> >
> > What I was saying is that you think that H sees infinite simulation which only exists in Pn(Pn)
> All that crazy bullshit about subscripted names of subscripts is
> extremely deceptive

No, just the opposite. It makes it clear *exactly* which computation we're talking about, so it prevents YOU from being deceptive.

>
> I am ONLY referring to this literal string:
> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
> as x86 machine code correctly simulated by H(P,P) and H1(P,P).

No you're not. You're also referring to the literal string which is the fixed code of H which aborts as that is part of the program P. So from here on, we'll refer to H as Ha and P as Pa to make that point clear.

For a separate H that never aborts which we'll call Hn, and Pn which calls that Hn, infinite simulation *does* happens so Ha(Pn,Pn) does correctly report non-halting. Your error is that you think this has anything to do with Ha(Pa,Pa) which is the case that matters.

Again, no rebuttal, just a bad analogy.

> >
> >>
> >> THIS LOGICALLY FOLLOWS FROM THAT:
> >> Since a halt decider is a type of decider this means that all halt
> >> deciders only compute the mapping from their input parameters to an
> >> accept/reject state on the basis of the actual behavior actually
> >> specified by this input.
> >
> > Which in the case of H(P,P) is *defined* to be P(P)
> >
> In this case it is the same as if {dogs} are defined to be {cats}.
> If anyone assigns non-decider properties to a decider they are wrong in
> the same way that it is wrong to assign {cat} properties to a {dog}.

And again no rebuttal, just a bad analogy. Given that this is the third time you've done this, I'll take this as an admission of defeat.

> >>
> >> This means that they simply made the false assumption that the correctly
> >> simulated input to every simulating halt decider must always have
> >> exactly the same behavior as the direct execution of this input.
> >
> > There is no assumption. A correct simulation of a machine is DEFINED to have the exact same behavior as the actual machine. What good would a simulation be if that wasn't the case?
> >
> >>
> >> It is a weird exception that they never noticed because they never
> >> bothered to pursue simulating halt deciders applied to the HP to its
> >> logical conclusion.
> >
> > Just because H(P,P) is unable to simulate its input to a final state doesn't mean it's correct.
> >
> >
> >>> You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.
> >>>
> >> I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
> >> I say that the correctly simulated input to H(P,P) never reaches its
> >> final state (thus never halts) whether or not its simulation is aborted.
> >
> > That is false, because the correctly simulated to input to H(P,P) is performed by H1(P,P) which does reach a final state.
> H(P,P) does correctly map the behavior of its inputs to its reject state
> this is a verifiable fact.

FALSE, because it is counter to the defined mapping for the halting function. Pa(Pa) halts, so Ha(Pa,Pa) == false is wrong.

>
> H1(P,P) does correctly map the behavior of its inputs to its accept
> state this is a verifiable fact.

This is true.

>
> I am probably not going to bother to talk to people that insist on
> disagreeing with verified facts.

At least you won't be talking to yourself.

[olcott]

I am only referring to this literal string:
558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

as an input to H(P,P) and H1(P,P). It is 100% perfectly concrete thus
utterly impervious to even extremely well-crafted attempts at deception
through the strawman error. Any attempt to get around this will be
construed as (and labeled) a bald-faced lie by a bald-faced liar.

It is a verified fact that at least Linz claims that H must report on Ĥ
applied to ⟨Ĥ⟩.


It is also a verified fact that this same requirement directly
contradicts the definition of decider that must map its actual inputs to
an accept/reject state based on the actual behavior of these actual inputs.

When the author or a textbook disagrees with computer science
definitions it is not computer science that is on the losing side of this.

[Dennis Bush]

That string is 100% NOT concrete because it doesn't specify the function that it is calling. It therefore doesn't specify a complete computation, so NO that is not the only thing you're referring to. The H that it calls is a part of it and is therefore immutable. So YES, H is Ha and P is Pa because the fixed algorithm of H aborts and P calls this fixed H.

You seem to be using this to say:

For each i: because each Hi(Pi,Pi) == false, and because Hn(Pn,Pn) does not halt, then each Hi(Pi,Pi) == false is correct.

Each Pi is distinct from each other, and each Hi is distinct from each other. That each Hi is unable to simulate the Pi built from it to a final state proves nothing regarding whether each of them is correct to return false. "Hello world" and Minesweeper are not the same program, so one can't be used to make conclusions about the other.

As it is required to.

>
>
> It is also a verified fact that this same requirement directly
> contradicts the definition of decider that must map its actual inputs to
> an accept/reject state based on the actual behavior of these actual inputs.

It does not, because the actual behavior of the actual inputs is defined to be the machine that those inputs represent.

>
> When the author or a textbook disagrees with computer science
> definitions it is not computer science that is on the losing side of this.

It doesn't. You just don't understand the definitions.

[olcott]

I did not freaking say that this finite string specifies every freaking
detail of the whole freaking system nitwit. This finite string as x86
code specifies every one of its own bytes.

It therefore doesn't specify a complete computation,

It knows you screwy and deceptive naming conventions on their ass.
These hexadecimal bytes are the stipulated as the input to H and H1.
558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

> so NO that is not the only thing you're referring to. The H that it calls is a part of it and is therefore immutable. So YES, H is Ha and P is Pa because the fixed algorithm of H aborts and P calls this fixed H.
>

These are verified facts:
H(P,P)==false is provably correct.
Ha(P,P)==true is provably correct.

I have a guy that I want you to arrest, his name is in my head.
I am going to write down the name of some other guy, but I want
you to arrest the guy who is named in my head. I won't tell you
his name.

All halt deciders only compute the mapping from their inputs to their
own accept/reject state on the basis of the actual behavior actually
specified by the correct simulation of this input by the halt decider.

>
>>
>> When the author or a textbook disagrees with computer science
>> definitions it is not computer science that is on the losing side of this.
>
> It doesn't. You just don't understand the definitions.
>
>

[Dennis Bush]

Not the whole system, just the computation to be decided on, and that computation includes the FIXED code of H that aborts its simulation, i.e. Ha.

>> It therefore doesn't specify a complete computation,
> It knows you screwy and deceptive naming conventions on their ass.

You're projecting. The naming convention prevents YOU from being deceptive and claiming that P is the same computation no matter what the implementation of the called H is.

The P to be decided on has a fixed algorithm. This means the H it calls / has a copy of also has a fixed algorithm. So we refer to that fixed H as Ha and the fixed P that calls it is referred to as Pa.

Ha(Pa,Pa) does not perform a correct simulation because it doesn't simulate for long enough. Hb(Pa,Pa) does simulate that same input to a final state.

> These hexadecimal bytes are the stipulated as the input to H and H1.
> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

FALSE. The input to a halt decider is the representation of a COMPLETE program/computation, and that is incomplete.

Just because a bunch of completely unrelated H's cannot simulate the completely unrelated P's built on them to a final state doesn't mean that all of them are correct.

> > so NO that is not the only thing you're referring to. The H that it calls is a part of it and is therefore immutable. So YES, H is Ha and P is Pa because the fixed algorithm of H aborts and P calls this fixed H.
> >
> These are verified facts:
> H(P,P)==false is provably correct.
> Ha(P,P)==true is provably correct.

As proved previously, Hb(Pa,Pa) == true proves that Ha(Pa,Pa) == false is wrong. If you disagree then that means you agree that Ha3(N,5) == false is correct because Ha7(N,5) == true doesn't disprove it.

Another bad analogy with no explanation.

>
> All halt deciders only compute the mapping from their inputs to their
> own accept/reject state on the basis of the actual behavior actually
> specified by the correct simulation of this input

Which is performed by an actual UTM, or alternately by a simulator that can simulate the input to a final state.

> by the halt decider.

Assuming the halt decider does a correct simulation

[olcott]

Thee is no Pa, Pb, Pc, there is only this P:
558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

There is no Ha, Hb, Hc, there is only H and H1.

[Dennis Bush]

So if that's enough information to decide on, then tell me if this halts:

void F()
{
X()
}

You can't, because X isn't specified. In the same way, the string you give above doesn't specify H, and H is part of P.

The complete code of P must be fixed, which means the H it calls must be fixed.

Given Hn that never aborts, Pn is built from it. Pn(Pn) does not halt due to infinite simulation. You built Ha (which you call H) to detect this so that Ha(Pn,Pn) correctly returns false. Then Pa (which you call P) is built from Ha.

Ha(Pa,Pa) returns false because it *thinks* there is infinite simulation. There is not. Hb, which simulates for k more steps than Ha, can simulate past the point where Ha aborts, and Hb(Pa,Pa) == true, proving that Ha(Pa,Pa) == false is wrong.

>
> There is no Ha, Hb, Hc, there is only H and H1.

There absolutely is, as your wording of "whether or not H aborts" implies. This also means that the P that call each of these is distinct.

[olcott]

I am only talking about H(P,P) and H1(P,P) where P is this literal
string as x86 machine language:
558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

Any replies diverging from this will simply be ignored without comment
as attempts to deceive using the strawman error

[Dennis Bush]

Again, not a complete computation, so not enough information to decide on. You seem to think that all "P" constructs are the same no matter how different the H it is built on is.

Just because:

H1(P1,P1) == false
H2(P2,P2) == false
H3(P3,P3) == false
H4(P4,P4) == false
H5(P5,P5) == false
...

Doesn't mean all of them are correct.

>
> Any replies diverging from this will simply be ignored without comment
> as attempts to deceive using the strawman error

Projection. You're the one attempting to deceive by using "P" and "H" to refer to multiple different computations at the same time.

You can't talk about P without talking about the *specific* H that it calls. Ha(Pa,Pa) == false is wrong as proved by Hb(Pa,Pa) == true

[olcott]

Within the context of my paper it is a complete computation for H(P,P).
I am updating the paper to include H1(P,P).

>
> Just because:
>
> H1(P1,P1) == false
> H2(P2,P2) == false
> H3(P3,P3) == false
> H4(P4,P4) == false
> H5(P5,P5) == false
> ...
>
> Doesn't mean all of them are correct.
>
>>
>> Any replies diverging from this will simply be ignored without comment
>> as attempts to deceive using the strawman error
>
> Projection. You're the one attempting to deceive by using "P" and "H" to refer to multiple different computations at the same time.
>
> You can't talk about P without talking about the *specific* H that it calls. Ha(Pa,Pa) == false is wrong as proved by Hb(Pa,Pa) == true
>

[Dennis Bush]

So if H is the *specific* decider that can detect infinite simulation in Pn(Pn), then we'll refer to it as Ha to clarify that point, and we'll refer to the P that calls it as Pa to clarify.

Ha(Pa,Pa) returns false because it *thinks* there is infinite simulation. There is not. Hb, which simulates for k more steps than Ha, can simulate past the point where Ha aborts. Hb(Pa,Pa) == true after simulating to a final state, proving that Ha(Pa,Pa) == false is wrong.

[olcott]

I am talking about the literal string of "H" being applied to this
literal string: 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

and

The literal string of "H1" being applied to this literal string:
558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

Perhaps you were unaware that literal strings do not vary and are thus
not variables.

[Dennis Bush]

And to complete the computation being evaluated, what is the *exact*, FIXED algorithm of H? If it is Ha, then Ha(Pa,Pa) == false is wrong as demonstrated by Hb(Pa,Pa) == true.

If H is using some other algorithm, then specify the *exact* algorithm.

[olcott]

H and H1 are both literal byte strings that emulate their literal byte
string input in pure x86 emulation mode until the behavior of this
emulated literal byte string input shows that it would never reach its
own final state (0xc3 ret instruction).

[Dennis Bush]

So in other words, the fixed algorithm of H looks for what it thinks is infinite simulation. So H is Ha, which means P is Pa.

Hb can then be constructed to simulate for k more steps than Ha and calculate Hb(Pa,Pa) == true, proving Ha(Pa,Pa) == false wrong.

[olcott]

Begin Local Halt Decider Simulation
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000009d6][00211368][0021136c] 55 push ebp // enter P
...[000009d7][00211368][0021136c] 8bec mov ebp,esp
...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
...[000009dc][00211364][000009d6] 50 push eax // Push P
...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][00211360][000009d6] 51 push ecx // Push P
...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The fact that P calls the same function from its same machine address
with identical input parameters conclusively proves that P is stuck in
infinite recursion.

[Dennis Bush]

First, it's not recursion, infinite or otherwise. It's nested simulation, and the conditions that are part of the simulation are relevant.

And it's not infinite nested simulation because Hb simulates Pa past the point where Ha aborts, sees that the embedded copy of Ha aborts, and sees Pa halt. So Ha is wrong.

[wij]

Your coding is invalid, because H is now shown to exist.

[wij]

Your coding is invalid, because H is not shown to exist (call what or who?).

[Jeff Barnett]

On 5/9/2022 3:19 PM, olcott wrote:

SNIP

Let's say that H looks like

Procedure H(args...)
Declare foo Own integer initially 10,000;
foo <- foo - 1;
If foo = 0 then signal ("halt 10000");
do stuff .....
Return ;
End H;

Then your simulation is total crap. Put up (show H, your coding is known
untrustworthy) or shut up (this option would be most appreciated). If
you don't know what "Own" is, ask Ben. So far, he's been charitable with
his time and might help you. Or you can try Google.

[By the way, there was an ambiguity about Own in an Algol spec that
might be in play here since you claim that H is in a recursive loop.
Fortunately, that will not effect the point of the above, it will just
strengthen the effect no matter what the interpretation.]
--
Jeff Barnett

[olcott]

I provide all of the details proving that this H does exist.

[olcott]

Infinitely nested simulation matches the infinite recursion infinite
behavior pattern. If H verified that the function that P calls is itself
then H could distinguish the difference. It need not do this infinite
behavior is all that it needs to know.

>
> And it's not infinite nested simulation because Hb simulates Pa past the point where Ha aborts, sees that the embedded copy of Ha aborts, and sees Pa halt. So Ha is wrong.

This is factually incorrect. The outermost H sees the infinite behavior
pattern first and knows that if it doesn't abort the simulation of its
input after a fixed number of simulations that the input will never
stop. I set this fixed number at the minimum of 2.

[wij]

Sorry, I don't think anyone had ever seen one.
Before your H is shown to exist for the test, your argument is void.

[olcott]

It is already stipulated (and verifiable) that H(P,P) correctly emulates
its input until it aborts the emulation of this input.

We can verify that H(P,P) correctly emulates its input on the basis that
the execution trace provided by H exactly matches the behavior specified
by the x86 source-code of P.

> Put up (show H, your coding is known
> untrustworthy) or shut up (this option would be most appreciated). If
> you don't know what "Own" is, ask Ben. So far, he's been charitable with
> his time and might help you. Or you can try Google.
>
> [By the way, there was an ambiguity about Own in an Algol spec that
> might be in play here since you claim that H is in a recursive loop.
> Fortunately, that will not effect the point of the above, it will just
> strengthen the effect no matter what the interpretation.]
> --
> Jeff Barnett

[olcott]

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

[wij]

"H is here" does not mean "I provide all of the details proving that this H does exist."
Where is your H that can stand the HP test?

[Dennis Bush]

Pa doesn't call itself. It calls Ha which simulates Pa, and the simulation performed by Ha *will* abort.

> >
> > And it's not infinite nested simulation because Hb simulates Pa past the point where Ha aborts, sees that the embedded copy of Ha aborts, and sees Pa halt. So Ha is wrong.
> This is factually incorrect. The outermost H sees the infinite behavior
> pattern first and knows that if it doesn't abort the simulation of its
> input after a fixed number of simulations that the input will never
> stop. I set this fixed number at the minimum of 2.

There is no "if it doesn't abort" because then you're talking about Pn instead of Pa. Because Pa contains a copy of Ha, you can't talk about what would happen if Ha did something different. Ha has a *fixed* algorithm, so it *does* abort, meaning the embedded copy in Pa will also abort. So there is no infinite simulation pattern to be found and Ha aborts too soon as Hb demonstrates.

[olcott]

We can verify that H(P,P) correctly emulates its input on the basis that
the execution trace provided by H exactly matches the behavior specified
by the x86 source-code of 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
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[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]

The execution trace that H(P,P) bases its halt status decision on
Begin Local Halt Decider Simulation Execution Trace Stored at:25cd7a
...[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
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
...[00001352][002a778e][002a7792] 55 push ebp // enter P
...[00001353][002a778e][002a7792] 8bec mov ebp,esp
...[00001355][002a778e][002a7792] 8b4508 mov eax,[ebp+08]
...[00001358][002a778a][00001352] 50 push eax // push P
...[00001359][002a778a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][002a7786][00001352] 51 push ecx // push P
...[0000135d][002a7782][00001362] e840feffff call 000011a2 // call H

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion non-halting behavior pattern.

[wij]

This is not H (a halting decider).
To refute HP, a H has to exist to refute. If H does not exist, no rebuttal.
Show your H to prove the rebuttal of conventional HP proof.

[olcott]

I am only talking about the actual behavior of the literal string H and
H1 applied to the literal string P. If you talk about anything else you
are talking to yourself and not me.

The literal string H could have hypothetically been defined with any
element of an infinite set of different behaviors.

H always bases its halt status decision on what the behavior of its
input would be if no H ever aborted the simulation of its input.

If in this case the input would never reach its own final state then H
rejects this input.

[olcott]

It does correctly decide the one "impossible" input basis of all of the
proofs, thus refuting all of these proofs.

> To refute HP, a H has to exist to refute. If H does not exist, no rebuttal.
> Show your H to prove the rebuttal of conventional HP proof.

[wij]

"it" does not exist. Show your POOH.

To refute HP, a H has to exist to refute. If H does not exist, no real rebuttal exist.

[olcott]

There is no need to show the hundreds of pages of source code for H
(including the open source x86 emulator) or the hundreds of pages of
execution trace of H because it is easily verified that:

H(P,P) correctly emulates its input on the basis that the execution
trace provided by H exactly matches the behavior specified by the x86
source-code of P.

It is also easy to verify that this trace specifies the infinite
behavior pattern of P:

[Richard Damon]

No it doesn't, not for the *PROGRAM* P, which is what H is supposed to
be taking in.

>
> It therefore doesn't specify a complete computation,

SO you ADMIT that the input isn't actually the representation of P(P)?

>
> It knows you screwy and deceptive naming conventions on their ass.
> These hexadecimal bytes are the stipulated as the input to H and H1.
> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

But if it isn't representing P(P), then WHO CARES!!

We are interested in seeing if H can get the right answer to P(P) (or H^
applied to <H^>)

if this input doesn't actually represent P, then what use is it?

>
>> so NO that is not the only thing you're referring to.  The H that it
>> calls is a part of it and is therefore immutable.  So YES, H is Ha and
>> P is Pa because the fixed algorithm of H aborts and P calls this fixed H.
>>
>
> These are verified facts:
> H(P,P)==false is provably correct.
> Ha(P,P)==true is provably correct.

Since you just said the input doesn't fully specify P, who cares.

we need to give H that ACTUAL representation of the PROGRAM P and the
input to P of that same representation.

>
>> You seem to be using this to say:
>>
>> For each i: because each Hi(Pi,Pi) == false, and because Hn(Pn,Pn)
>> does not halt, then each Hi(Pi,Pi) == false is correct.
>>
>> Each Pi is distinct from each other, and each Hi is distinct from each
>> other.  That each Hi is unable to simulate the Pi built from it to a
>> final state proves nothing regarding whether each of them is correct
>> to return false.  "Hello world" and Minesweeper are not the same
>> program, so one can't be used to make conclusions about the other.
>>
>>
>>>>
>>>> For a separate H that never aborts which we'll call Hn, and Pn which
>>>> calls that Hn, infinite simulation *does* happens so Ha(Pn,Pn) does
>>>> correctly report non-halting. Your error is that you think this has
>>>> anything to do with Ha(Pa,Pa) which is the case that matters.
>>>>
>>>>>>>
>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>>
>>>>>>> _P()
>>>>>>> [000009d6](01) 55 push ebp
>>>>>>> [000009d7](02) 8bec mov ebp,esp
>>>>>>> [000009d9](03) 8b4508 mov eax,[ebp+08]
>>>>>>> [000009dc](01) 50 push eax // push P
>>>>>>> [000009dd](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>> [000009e0](01) 51 push ecx // push P
>>>>>>> [000009e1](05) e840feffff call 00000826 // call H
>>>>>>> [000009e6](03) 83c408 add esp,+08
>>>>>>> [000009e9](02) 85c0 test eax,eax
>>>>>>> [000009eb](02) 7402 jz 000009ef
>>>>>>> [000009ed](02) ebfe jmp 000009ed
>>>>>>> [000009ef](01) 5d pop ebp
>>>>>>> [000009f0](01) c3 ret // Final state
>>>>>>> Size in bytes:(0027) [000009f0]
>>>>>>>>>
>>>>>>>>> Why is it so hard to understand that H(P,P) must provide the
>>>>>>>>> halt status
>>>>>>>>> of its actual input on the basis of the actual behavior
>>>>>>>>> specified by
>>>>>>>>> this actual input?
>>>>>>>>
>>>>>>>> The *definition* of the problem states that the actual behavior
>>>>>>>> of the actual input to H(P,P) is P(P).
>>>>>>> Whomever wrote that definition also knows that
>>>>>>>
>>>>>>> THIS IS SET IN STONE:
>>>>>>> All deciders only compute the mapping from their input parameters
>>>>>>> to an
>>>>>>> accept/reject state on the basis of the actual properties actually
>>>>>>> specified by this input

>>>>>>
>>>>>> Which in the case of H(P,P) is *defined* to be P(P)
>>>>> In this case it is the same as if {dogs} are defined to be {cats}.
>>>>

>>>> Again, no rebuttal, just a bad analogy.
>>>>
>>>>>>
>>>>>>>
>>>>>>> THIS LOGICALLY FOLLOWS FROM THAT:
>>>>>>> Since a halt decider is a type of decider this means that all halt
>>>>>>> deciders only compute the mapping from their input parameters to an
>>>>>>> accept/reject state on the basis of the actual behavior actually
>>>>>>> specified by this input.

>>>>>>
>>>>>> Which in the case of H(P,P) is *defined* to be P(P)
>>>>>>
>>>>> In this case it is the same as if {dogs} are defined to be {cats}.

>>>>> If anyone assigns non-decider properties to a decider they are
>>>>> wrong in
>>>>> the same way that it is wrong to assign {cat} properties to a {dog}.
>>>>
>>>> And again no rebuttal, just a bad analogy. Given that this is the
>>>> third time you've done this, I'll take this as an admission of defeat.
>>> It is a verified fact that at least Linz claims that H must report on Ĥ
>>> applied to ⟨Ĥ⟩.
>>
>> As it is required to.
>>
>>>
>>>
>>> It is also a verified fact that this same requirement directly
>>> contradicts the definition of decider that must map its actual inputs to
>>> an accept/reject state based on the actual behavior of these actual
>>> inputs.
>>
>> It does not, because the actual behavior of the actual inputs is
>> defined to be the machine that those inputs represent.
>
> I have a guy that I want you to arrest, his name is in my head.
> I am going to write down the name of some other guy, but I want
> you to arrest the guy who is named in my head. I won't tell you
> his name.

Yep, that is an impossible problem, JUST LIKE THE HALTING PROBLEM IS.

>
> All halt deciders only compute the mapping from their inputs to their
> own accept/reject state on the basis of the actual behavior actually
> specified by the correct simulation of this input by the halt decider.

And the ACTUAL BEHAVIOR of their input is DEFINED as the running of the
program that input represents. Just because H can't recreate it doesn't
make that definition untrue, just impossible.

Like you actually thinking.

>
>>
>>>
>>> When the author or a textbook disagrees with computer science
>>> definitions it is not computer science that is on the losing side of
>>> this.
>>
>> It doesn't.  You just don't understand the definitions.
>>
>>
>
>

[Richard Damon]

On 5/9/22 12:05 PM, olcott wrote:
> On 5/9/2022 11:02 AM, Dennis Bush wrote:

>> Not the whole system, just the computation to be decided on, and that
>> computation includes the FIXED code of H that aborts its simulation,
>> i.e. Ha.
>
>
> Thee is no Pa, Pb, Pc, there is only this P:
> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

Which when run has undefined behavior as it calls an uninitialzed memory
location.

You don't seem to actually understand x86 asssembly.

>
> There is no Ha, Hb, Hc, there is only H and H1.
>
>

[Richard Damon]

On 5/9/22 12:39 PM, olcott wrote:
> On 5/9/2022 11:30 AM, Dennis Bush wrote:

>> So if that's enough information to decide on, then tell me if this halts:
>>
>> void F()
>> {
>>    X()
>> }
>>
>
> I am only talking about H(P,P) and H1(P,P) where P is this literal
> string as x86 machine language:
> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>

> Any replies diverging from this will simply be ignored without comment
> as attempts to deceive using the strawman error
>
>

Which just shows your system might not be Turing Complete, so totally
invalid for the proof.

[wij]

You choose to refute the conventional HP, and says that there is no need to show
the hundreds of pages of H...,etc. How do you expect the reviewer/the world
to verify POOH (a claim?) by 'claim'?

> H(P,P) correctly emulates its input on the basis that the execution
> trace provided by H exactly matches the behavior specified by the x86
> source-code of P.
> It is also easy to verify that this trace specifies the infinite
> behavior pattern of P:
> H sees that P is calling the same function from the same machine address
> with identical parameters, twice in sequence. This is the infinite
> recursion non-halting behavior pattern.

Invalid claim. Because H is not shown to exist.

[Richard Damon]

And the following is INCORRECT unless H just call/jumps to P, and thus
is unable to abort its "simulation" of it.

> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H

Which is then contradicted by this, so the trace is just incorrect.

> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> The fact that P calls the same function from its same machine address
> with identical input parameters conclusively proves that P is stuck in
> infinite recursion.
>

Nope. Not in this context when the function it calls isn't calling P
back, but conditionally simulating it.

That conditional breaks your rule. (Prove it otherwise with a reliavle
source).

[Dennis Bush]

But to talk about a specific P you need to talk about a specific H with a fixed algorithm. And since Ha aborts, Ha(Pa,Pa) == false is wrong because Pa(Pa) halts. It doesn't matter what some other H or some other P does.

You seem to be saying given:
H1(P1,P1) == false
H2(P2,P2) == false
H3(P3,P3) == false
H4(P4,P4) == false
....
That since they all answer false that they must all be correct. Each of these P's is completely independent of each other so one has nothing to do with whether or not another halts.

Minesweeper and HelloWorld are not the same, so Minesweeper^ and HelloWorld^ are not the same.

>
> H always bases its halt status decision on what the behavior of its
> input would be if no H ever aborted the simulation of its input.

It doesn't matter what H1(P1,P1) or H2(P2,P2) does when it comes to determining if Ha(Pa,Pa) gave the right answer.

So the above can only mean that non-halting is correct if no simulator given the *same* input can simulate to completion.
By that definition, since Hb(Pa,Pa) == true that means at least one H ran this input to completion, so Ha(Pa,Pa) == false is wrong.

[Richard Damon]

Nope, you are using incorrect logic. Yes, H can prove that if all copies
of H never abort their simulation of the input, then P would be
non-halting, but that doesn't mean that if all copies of H do abort
their simulation of the input that it is still non-halting.

You basically have this erroneous logic arguement

p: H doesn't abort its simulation
q: P will be non-halting

H has shown that: p -> q

Then H decides that: !p (Because H WILL abort its simulation)

and you are from that concluding:

q

That isn't sound logic.

[Richard Damon]

Except we don't apply the "string" H to the input P, we apply the
PROGRAM H to the string P

And if you are only looking at the behavior of H when applied to the
string P, you aren't talking about the Halting of P, but of H.

>
> The literal string H could have hypothetically been defined with any
> element of an infinite set of different behaviors.
>
> H always bases its halt status decision on what the behavior of its
> input would be if no H ever aborted the simulation of its input.

And then it is wrong, because H does abort, so you are using unsound
logic or a invalid definiton.

>
> If in this case the input would never reach its own final state then H
> rejects this input.
>

So you are just talking about POOP.

[Richard Damon]

Except it doesn't.

H needs to get the right answer for H^ applied to <H^> or its equivalent.

Your H doesn't. it seems you H can't even be given the needed question.

So, you FAIL.

All you have shown is you don't know what the Halting Problem actually is.

[Jeff Barnett]

You can stipulate all you want. However, you are unreliable so lets
ignore that. Since you haven't shown your H and I've shown you mine, I
win. For the next lesson, we are told that "....." contains "H(.....)"
and that form is sometimes executed. All it proves is that your test in
your code does not justify the conclusion in re infinite recursion.

You can not and have not convinced anyone. And you wont unless some well
written code (insert guffaw here) that justifies your claims. It's time
to put up or shut up (second choice is best for you). I can change my H
slightly to assure H is not called with the same argument but the
argument will have the same address. Then what? You try to change the
definition of halting again? Or what a halt decider must do?

[olcott]

On 5/9/2022 5:12 PM, Jeff Barnett wrote:

We can verify that H(P,P) correctly emulates its input on the basis that
the execution trace provided by H exactly matches the behavior specified
by the x86 source-code of P.

That you are unwilling do do this proves your insincerity.
It is already succinctly proved in the material that was provided.

> If
> you don't know what "Own" is, ask Ben. So far, he's been charitable with
> his time and might help you. Or you can try Google.
>
> [By the way, there was an ambiguity about Own in an Algol spec that
> might be in play here since you claim that H is in a recursive loop.
> Fortunately, that will not effect the point of the above, it will just
> strengthen the effect no matter what the interpretation.]
> --
> Jeff Barnett

[Richard Damon]

You can't stipu;ate that your answer is correct.

The actual affect of that sipulation is that your H never halts (if you
use the actual Halting Property as your criteria) since if H aborts its
simulation and says non-halting the input becomes Halting.

>
> We can verify that H(P,P) correctly emulates its input on the basis that
> the execution trace provided by H exactly matches the behavior specified
> by the x86 source-code of P.

Nope. Since the ACTUAL behavior of calling H is the execution of H and
of H SIMULATING P, not P actually running.

The ONLY way you can get the trace you show is if H jumps to/calls P, at
which point it can never 'abort' that 'simulation' since it is no longer
in control.

If the embedded copy does that, but the master copy does an actual
simulation, then you didn't put a correct copy of H into P, or H isn't
actually a computation, taking some hidden input.

FAIL

[Dennis Bush]

Let's test that. Code up Ha3(N,5). You'll find that the execution trace provided by Ha3 exactly matches the behavior specified by the x86 source code of N.

So then according to you, by your criteria of a correct simulation, Ha3(N,5) == false is correct.

If you believe that's nonsense, then that means your criteria for correct emulation is invalid and therefore can't be used to show that Ha(Pa,Pa) == false is correct.

[olcott]

(a) Verify that the execution trace of P by H is correct by comparing
this execution trace to the ax86 source-code of P.

(b) Verify that this execution trace shows that P is stuck in infinitely
nested simulation (a non-halting behavior).

#include <stdint.h>
#define u32 uint32_t

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

int main()
{
Output("Input_Halts = ", H((u32)P, (u32)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
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[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
...[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

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

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite

recursion (infinitely nested simulation) non-halting behavior pattern.

...[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_User_Instructions(1)
Number of Instructions Executed(15892)

>> H(P,P) correctly emulates its input on the basis that the execution
>> trace provided by H exactly matches the behavior specified by the x86
>> source-code of P.
>> It is also easy to verify that this trace specifies the infinite
>> behavior pattern of P:
>> H sees that P is calling the same function from the same machine address
>> with identical parameters, twice in sequence. This is the infinite
>> recursion non-halting behavior pattern.
>
> Invalid claim. Because H is not shown to exist.
>
>>
>>
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer

[Richard Damon]

Which fails,. P calls H, so the trace actually needs to show what H does.

It then shows a trace as if H actualls CALL P, which if it does, it
can't abort the operation, so is obviously incorrect.

Since the execution trace is OBVIOUSLY incorrect, in can not be use to
make any accurate predictions of the behavior of P(P).

> (b) Verify that this execution trace shows that P is stuck in infinitely
> nested simulation (a non-halting behavior).

IF we say that H is JUST a call to P(P) (as the trace implies) then yes,
P(P) is stuck in ifnititely nested EXCUCTION behavior, but H also has no
ability to end this loop either, so fails to answer.

Any other behavior by H means the trace is just a LIE.

How do we get form the above to the below.

Unless H just actually calls its input, this trace is NOT correct.

We SHOULD have a trace of H simulating P,P not the execution of P(P)
unless that is actually what H does (at which point it can't abort).

So, this trace is just a LIE.

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

Proof that H doesn't just call its input, and thus the trace is a LIE.

>
> H sees that P is calling the same function from the same machine address
> with identical parameters, twice in sequence. This is the infinite
> recursion (infinitely nested simulation) non-halting behavior pattern.

No, H as done some incorrect tracing and incorrectly assumed that this
is an infinite recursion, not seeing that actual truth.