Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 29 June 2022 at 20:54:28 UTC+1, Ben Bacarisse wrote:
>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>
>> > If we put to one side the fact that a simulation-based halting decider
>> > is invalid* it is a FACT that such a decider, to be considered valid,
>> > should decide on the behaviour of P(P) calling H(P,P). If it can't do
>> > that without invoking "infinite recursion" (or aborting same) then it
>> > isn't simulating P(P) correctly so cannot arrive at a correct halting
>> > decision on P(P).
>> There's a reason the theorem is not stated about functions in some
>> programming language. Such a description would be just too prone to
>> misinterpretation or trickery.
>>
> Initially I thought that was what he was doing. There are all sorts of ways
> you can make it look like a C function is classifying the "pathological"
> input correctly, when of course it is not. But I misjudged PO. It goes
> far deeper than that.

I agree. PO's nonsense goes much deeper than simple misinterpretation or
trickery. Remember that this is someone prepared to assert that

"the fact that a computation halts does not entail that it is a
halting computation"

"Whether a computation is finite is more nuanced than it simply stops
running"

And when he invented his "new halting criterion" he stated both of these
facts about it:

"We can know that my halt deciding criteria is the same as the halting
problem"

and

"This maps to every element of the conventional halting problem set of
non-halting computations and a few more."

Similarly, he said both

"Furthermore I have repeated H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn many
times."

and

"No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
times."

within a few days of each other and he has never even acknowledged this
contradiction much less state which he now stands by.

It helps to keep in mind the full weight of nonsense and
misunderstanding that has built up in PO's mind over the years.

>> If you have to use C then the halting problem is best expressed in terms
>> of programs. A halting decider would be a C program that returns
>> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
>> whether the C program whose source is given in argv[1] halts or not when
>> run with argv[2] as its sole command line argument.
>>
>> It seemed like the polite thing to do to move away from Turing machines
>> (which PO does not understand) to C. But the specification in terms of
>> C functions has allowed PO to indulge his penchant for obfuscation to the
>> point where no one is really sure exactly what mistake he's made.
>>
> Currently we've got a distinction between "the correctly emulated input
> to H" and "the behaviour of P(P) when run". This is just pure
> insanity.

Yes. It's the latest phrasing intended to keep the discussion going.
He as, to all intents and purposes, admitted that no function D can be
written such D(X,Y) == 1 if and only if X(Y) "halts" (i.e. always
returns to its caller) so there's a danger that people won't care about
his "other 'halting' problem". Given that he's ditched the halting
problem, some form of words is needed to keep the replies coming in.

> But I think I see where it comes from. If your dry run doesn't match the
> actual behaviour of the program when executed, then either the dry run was
> wrong or the computer has a fault. If you reject both of those explanations,
> what are you left with? Claiming that the basic rules of programming logic
> are wrong.

I disagree because I don't think any of his confusion comes from a dry
run of anything, but that's just as guess.

My explanation is historical. He's tried "it's an invalid question",
"it only halts because ...", "it wouldn't halt if it weren't stopped"
and "it doesn't halt if line 15 is commented out".

Then we got the re-definition of halting: "A non-halting computation is
every computation that never halts unless its simulation is aborted"
which was a little too clear so that was gradually obfuscated. For me
"the correct simulation of the input to H(P,P)" is just the latest
attempt at obfuscation in a long line of such ruses.

>> He did originally understand that H(X,Y) should report on the "halting"
>> of X(Y), but he's long since abandoned that obvious model.
>>
> He's been driven from it. He still basically knows what a halt decider
> is.

Really? I don't think so. I don't think his mind works in that sort of
abstract way. What evidence have you seen that he know what a halt
decider is? One problem with talking to people like this is that they
cut ans paste definitions which can make it look like they understand.

> He's forced into more and more absurd contortions to try to keep up
> the claim that H is correct.

Totally agree.

--
Ben.

On 6/30/2022 6:20 AM, Malcolm McLean wrote:
> On Wednesday, 29 June 2022 at 20:54:28 UTC+1, Ben Bacarisse wrote:
>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>
>>> If we put to one side the fact that a simulation-based halting decider
>>> is invalid* it is a FACT that such a decider, to be considered valid,
>>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>>> that without invoking "infinite recursion" (or aborting same) then it
>>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>>> decision on P(P).
>> There's a reason the theorem is not stated about functions in some
>> programming language. Such a description would be just too prone to
>> misinterpretation or trickery.
>>
> Initially I thought that was what he was doing. There are all sorts of ways
> you can make it look like a C function is classifying the "pathological"
> input correctly, when of course it is not. But I misjudged PO. It goes
> far deeper than that.
>> If you have to use C then the halting problem is best expressed in terms
>> of programs. A halting decider would be a C program that returns
>> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
>> whether the C program whose source is given in argv[1] halts or not when
>> run with argv[2] as its sole command line argument.
>>
>> It seemed like the polite thing to do to move away from Turing machines
>> (which PO does not understand) to C. But the specification in terms of
>> C functions has allowed PO to indulge his penchant for obfuscation to the
>> point where no one is really sure exactly what mistake he's made.
>>
> Currently we've got a distinction between "the correctly emulated input
> to H" and "the behaviour of P(P) when run". This is just pure insanity.

Not when you look at what the code actually does.

> But I think I see where it comes from. If your dry run doesn't match the
> actual behaviour of the program when executed, then either the dry run was
> wrong or the computer has a fault.

P(P) depends on the return value from H(P,P) and the emulated input to
H(P,P) cannot depend on anything. One path has a conditional branch and
the other path does not have this conditional branch.

> If you reject both of those explanations,
> what are you left with? Claiming that the basic rules of programming logic
> are wrong.

You just have to look at the actual code and see that it is necessarily
correct according to the semantics of the x86 language. If this is
beyond you technical skill then hypothesize that the code is correct.
When we even hypothesize that the code is correct then within this
hypothesis H(P,P)==0 is correct.

Saying that H(P,P)==0 is incorrect disagrees with the semantics of the
x86 language, that is the same as disagreeing with arithmetic.

>>
>> He did originally understand that H(X,Y) should report on the "halting"
>> of X(Y), but he's long since abandoned that obvious model.
>>

As I progress through this my understanding deepens and I make
corrections to my prior views.

> He's been driven from it. He still basically knows what a halt decider is.
> He's forced into more and more absurd contortions to try to keep up
> the claim that H is correct.

Why do you insist on disagreeing with the semantics of the x86 language?

--
Copyright 2022 Pete Olcott

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

On 6/30/2022 6:32 AM, Mikko wrote:
> On 2022-06-29 19:18:05 +0000, Mr Flibble said:
>
>> void Px(u32 x)
>> {
>>    H(x, x);
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H((u32)Px, (u32)Px));
>> }
>  ...
>> it is obvious that Px should always halt if H is a valid halt decider
>> that always returns a decision to its caller (Px).
>
> More generally, Px halts with every x if H is any decider. Conversely,
> if Px does not halt with some x then H is not a decider.
>
> Mikko
>

A function only halts when it reaches its "ret" instruction.

THIS IS VERY BASIC SOFTWARE ENGINEERING:
When-so-ever any function is called in infinite recursion the caller
never returns to this function. That means that H must abort the x86
emulation of its input or this emulation would never stop running.

--
Copyright 2022 Pete Olcott

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

On 6/30/2022 9:42 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 29 June 2022 at 20:54:28 UTC+1, Ben Bacarisse wrote:
>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>>
>>>> If we put to one side the fact that a simulation-based halting decider
>>>> is invalid* it is a FACT that such a decider, to be considered valid,
>>>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>>>> that without invoking "infinite recursion" (or aborting same) then it
>>>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>>>> decision on P(P).
>>> There's a reason the theorem is not stated about functions in some
>>> programming language. Such a description would be just too prone to
>>> misinterpretation or trickery.
>>>
>> Initially I thought that was what he was doing. There are all sorts of ways
>> you can make it look like a C function is classifying the "pathological"
>> input correctly, when of course it is not. But I misjudged PO. It goes
>> far deeper than that.
>
> I agree. PO's nonsense goes much deeper than simple misinterpretation or
> trickery. Remember that this is someone prepared to assert that
>
> "the fact that a computation halts does not entail that it is a
> halting computation"
>
> "Whether a computation is finite is more nuanced than it simply stops
> running"
>

If I ever said that I was incorrect.
The actual truth is that we cannot correctly construe that a sequence of
configurations halts unless it actually reaches its own final state.

> And when he invented his "new halting criterion" he stated both of these
> facts about it:
>
> "We can know that my halt deciding criteria is the same as the halting
> problem"
>
> and
>
> "This maps to every element of the conventional halting problem set of
> non-halting computations and a few more."
>
> Similarly, he said both
>
> "Furthermore I have repeated H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn many
> times."
>
> and
>
> "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
> times."
>
> within a few days of each other and he has never even acknowledged this
> contradiction much less state which he now stands by.
>
> It helps to keep in mind the full weight of nonsense and
> misunderstanding that has built up in PO's mind over the years.

I have said many things that turned out to be incorrect previously. That
is not relevant to my current position. This is my current position on
Linz.

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final
state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.

>>> If you have to use C then the halting problem is best expressed in terms
>>> of programs. A halting decider would be a C program that returns
>>> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
>>> whether the C program whose source is given in argv[1] halts or not when
>>> run with argv[2] as its sole command line argument.
>>>
>>> It seemed like the polite thing to do to move away from Turing machines
>>> (which PO does not understand) to C. But the specification in terms of
>>> C functions has allowed PO to indulge his penchant for obfuscation to the
>>> point where no one is really sure exactly what mistake he's made.
>>>
>> Currently we've got a distinction between "the correctly emulated input
>> to H" and "the behaviour of P(P) when run". This is just pure
>> insanity.
>
> Yes. It's the latest phrasing intended to keep the discussion going.
> He as, to all intents and purposes, admitted that no function D can be
> written such D(X,Y) == 1 if and only if X(Y) "halts" (i.e. always
> returns to its caller) so there's a danger that people won't care about
> his "other 'halting' problem". Given that he's ditched the halting
> problem, some form of words is needed to keep the replies coming in.

int sum(int X, int Y)
{ return X + Y;
}

In the same way that sum(3,4) cannot return the sum of 5 + 8, H(P,P)
cannot determine the halt status of P(P).

P(P) conditionally depends on the return value of H(P,P).
The simulated input to H(P,P) cannot conditionally depend on anything
making its behavior diverge from P(P). The only possible way to disagree
with H(P,P)==0 is to disagree with the semantics of the x86 language.

If one disagrees that H(P,P)==0 not knowing the semantics of the x86
language they are a liar, if they disagree that H(P,P)==0 knowing that
this disagreement contradicts the semantics of the x86 language then
they are a fool. In either case this disagreement is incorrect.

>> But I think I see where it comes from. If your dry run doesn't match the
>> actual behaviour of the program when executed, then either the dry run was
>> wrong or the computer has a fault. If you reject both of those explanations,
>> what are you left with? Claiming that the basic rules of programming logic
>> are wrong.
>
> I disagree because I don't think any of his confusion comes from a dry
> run of anything, but that's just as guess.
>

The bench-check of the behavior of the correctly emulated input to
H(P,P) conclusively proves that P would never reach its "ret"
instruction. This criteria turns that into an axiom:

Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp
[00001203][002120af][002120b3] 8bec mov ebp,esp
[00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
[00001208][002120ab][00001202] 50 push eax // push P
[00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
[0000120c][002120a7][00001202] 51 push ecx // push P
[0000120d][002120a3][00001212] e820feffff call 00001032 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.

> My explanation is historical. He's tried "it's an invalid question",
> "it only halts because ...", "it wouldn't halt if it weren't stopped"
> and "it doesn't halt if line 15 is commented out".
>
> Then we got the re-definition of halting: "A non-halting computation is
> every computation that never halts unless its simulation is aborted"

This remains correct. I rephrased it as this:

Every simulating halt decider correctly simulates its input until it
correctly determines that this simulated input would never reach its
final state.

> which was a little too clear so that was gradually obfuscated. For me
> "the correct simulation of the input to H(P,P)" is just the latest
> attempt at obfuscation in a long line of such ruses.
>
>>> He did originally understand that H(X,Y) should report on the "halting"
>>> of X(Y), but he's long since abandoned that obvious model.
>>>
>> He's been driven from it. He still basically knows what a halt decider
>> is.
>
> Really? I don't think so. I don't think his mind works in that sort of
> abstract way. What evidence have you seen that he know what a halt
> decider is? One problem with talking to people like this is that they
> cut ans paste definitions which can make it look like they understand.
>
>> He's forced into more and more absurd contortions to try to keep up
>> the claim that H is correct.
>
> Totally agree.
>

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.

P(P) is provably not the actual behavior of the actual input to H(P,P).

That people disagree with this proof on the basis of a lack of
understanding of this proof makes them liars.

*Here is the proof that the correctly emulated input to*
*H(P,P) never halts and the directly executed P(P) halts*

On Thu, 30 Jun 2022 09:53:13 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/30/2022 6:32 AM, Mikko wrote:
> > On 2022-06-29 19:18:05 +0000, Mr Flibble said:
> >
> >> void Px(u32 x)
> >> {
> >>    H(x, x);
> >>    return;
> >> }
> >>
> >> int main()
> >> {
> >>    Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >> }
> >  ...
> >> it is obvious that Px should always halt if H is a valid halt
> >> decider that always returns a decision to its caller (Px).
> >
> > More generally, Px halts with every x if H is any decider.
> > Conversely, if Px does not halt with some x then H is not a decider.
> >
> > Mikko
> >
>
> A function only halts when it reaches its "ret" instruction.
>
> THIS IS VERY BASIC SOFTWARE ENGINEERING:
> When-so-ever any function is called in infinite recursion the caller
> never returns to this function. That means that H must abort the x86
> emulation of its input or this emulation would never stop running.
Your error that you keep repeating is that infinite recursion manifests
when calling a valid halt decider from P()/Px(): it doesn't. Infinite
recursion is a problem with your invalid halting non-decider alone.

/Flibble

On 6/30/2022 11:20 AM, Mr Flibble wrote:
> On Thu, 30 Jun 2022 09:53:13 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/30/2022 6:32 AM, Mikko wrote:
>>> On 2022-06-29 19:18:05 +0000, Mr Flibble said:
>>>
>>>> void Px(u32 x)
>>>> {
>>>>    H(x, x);
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>> }
>>>  ...
>>>> it is obvious that Px should always halt if H is a valid halt
>>>> decider that always returns a decision to its caller (Px).
>>>
>>> More generally, Px halts with every x if H is any decider.
>>> Conversely, if Px does not halt with some x then H is not a decider.
>>>
>>> Mikko
>>>
>>
>> A function only halts when it reaches its "ret" instruction.
>>
>> THIS IS VERY BASIC SOFTWARE ENGINEERING:
>> When-so-ever any function is called in infinite recursion the caller
>> never returns to this function. That means that H must abort the x86
>> emulation of its input or this emulation would never stop running.
>
> Your error that you keep repeating is that infinite recursion manifests
> when calling a valid halt decider from P()/Px(): it doesn't. Infinite
> recursion is a problem with your invalid halting non-decider alone.
>
> /Flibble
>

*This is necessarily true thus impossibly false*
Every simulating halt decider correctly simulates its input until it
correctly determines that this simulated input would never reach its
final state.

--
Copyright 2022 Pete Olcott

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

On Thu, 30 Jun 2022 11:29:11 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/30/2022 11:20 AM, Mr Flibble wrote:
> > On Thu, 30 Jun 2022 09:53:13 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/30/2022 6:32 AM, Mikko wrote:
> >>> On 2022-06-29 19:18:05 +0000, Mr Flibble said:
> >>>
> >>>> void Px(u32 x)
> >>>> {
> >>>>    H(x, x);
> >>>>    return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>>    Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>> }
> >>>  ...
> >>>> it is obvious that Px should always halt if H is a valid halt
> >>>> decider that always returns a decision to its caller (Px).
> >>>
> >>> More generally, Px halts with every x if H is any decider.
> >>> Conversely, if Px does not halt with some x then H is not a
> >>> decider.
> >>>
> >>> Mikko
> >>>
> >>
> >> A function only halts when it reaches its "ret" instruction.
> >>
> >> THIS IS VERY BASIC SOFTWARE ENGINEERING:
> >> When-so-ever any function is called in infinite recursion the
> >> caller never returns to this function. That means that H must
> >> abort the x86 emulation of its input or this emulation would never
> >> stop running.
> >
> > Your error that you keep repeating is that infinite recursion
> > manifests when calling a valid halt decider from P()/Px(): it
> > doesn't. Infinite recursion is a problem with your invalid halting
> > non-decider alone.
> >
> > /Flibble
> >
>
> *This is necessarily true thus impossibly false*
> Every simulating halt decider correctly simulates its input until it
> correctly determines that this simulated input would never reach its
> final state.

Simulating halt deciders are invalid for reasons already given.

/Flibble

On Wednesday, June 29, 2022 at 4:36:13 PM UTC-7, olcott wrote:
> On 6/29/2022 6:10 PM, dklei...@gmail.com wrote:
> > On Wednesday, June 29, 2022 at 1:46:15 PM UTC-7, olcott wrote:
> >
> >> C is a little ambiguous across implementation environments, yet C
> >> translated into x86 has precisely specified semantics.
> >>
> > "C translated into x86" is called compilation (assuming x86 means
> > x86 assembly language).
> >>
> >> When C is translated into the x86 language we get a complete directed
> >> graph of all control flow.
> >>
> > Control is usually easier to understand in C than assembler.
> >>
> >> That people say that I am incorrect on the basis of their lack of
> >> understanding of the semantics of the x86 language is dishonest.
> >>
> > Just go read comp.lang.c or one of the others. The semantics laid
> > down in the standards are quite complex and hardly anyone actually
> > understands them. There is no evidence you do.
> All of the the conrol flow semantics of the x86 language comes as a
> ready-made directed graph with integer subscripts.
>
> This is much easier for machine processing.

And these alleged control flow structures are ...... ?

On 6/30/2022 1:17 PM, dklei...@gmail.com wrote:
> On Wednesday, June 29, 2022 at 4:36:13 PM UTC-7, olcott wrote:
>> On 6/29/2022 6:10 PM, dklei...@gmail.com wrote:
>>> On Wednesday, June 29, 2022 at 1:46:15 PM UTC-7, olcott wrote:
>>>
>>>> C is a little ambiguous across implementation environments, yet C
>>>> translated into x86 has precisely specified semantics.
>>>>
>>> "C translated into x86" is called compilation (assuming x86 means
>>> x86 assembly language).
>>>>
>>>> When C is translated into the x86 language we get a complete directed
>>>> graph of all control flow.
>>>>
>>> Control is usually easier to understand in C than assembler.
>>>>
>>>> That people say that I am incorrect on the basis of their lack of
>>>> understanding of the semantics of the x86 language is dishonest.
>>>>
>>> Just go read comp.lang.c or one of the others. The semantics laid
>>> down in the standards are quite complex and hardly anyone actually
>>> understands them. There is no evidence you do.
>> All of the the conrol flow semantics of the x86 language comes as a
>> ready-made directed graph with integer subscripts.
>>
>> This is much easier for machine processing.
>
> And these alleged control flow structures are ...... ?

[0000117d](05) e8f0fdffff call 00000f72
[00001187](02) 7402 jz 0000118b
[00001189](02) ebfe jmp 00001189
[0000118c](01) c3 ret

--
Copyright 2022 Pete Olcott

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

On 6/30/22 12:29 PM, olcott wrote:
> On 6/30/2022 11:20 AM, Mr Flibble wrote:
>> On Thu, 30 Jun 2022 09:53:13 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/30/2022 6:32 AM, Mikko wrote:
>>>> On 2022-06-29 19:18:05 +0000, Mr Flibble said:
>>>>> void Px(u32 x)
>>>>> {
>>>>>     H(x, x);
>>>>>     return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>> }
>>>>    ...
>>>>> it is obvious that Px should always halt if H is a valid halt
>>>>> decider that always returns a decision to its caller (Px).
>>>>
>>>> More generally, Px halts with every x if H is any decider.
>>>> Conversely, if Px does not halt with some x then H is not a decider.
>>>>
>>>> Mikko
>>>
>>> A function only halts when it reaches its "ret" instruction.
>>>
>>> THIS IS VERY BASIC SOFTWARE ENGINEERING:
>>> When-so-ever any function is called in infinite recursion the caller
>>> never returns to this function. That means that H must abort the x86
>>> emulation of its input or this emulation would never stop running.
>> Your error that you keep repeating is that infinite recursion manifests
>> when calling a valid halt decider from P()/Px(): it doesn't.  Infinite
>> recursion is a problem with your invalid halting non-decider alone.
>>
>> /Flibble
>>
>
> *This is necessarily true thus impossibly false*
> Every simulating halt decider correctly simulates its input until it
> correctly determines that this simulated input would never reach its
> final state.
>
>

So, does H fail to meet its requirements by aborting before it actually
proves the result, and thus gives the wrong answer by creating a Halting
P by answering, or does H fail to meet the requirement to actually
answer in finite time by waiting until it can actually prove that it is
non-halting.

Remember, it has been PROVED that ANY finite pattern in the emultion of
the input to H(P,P) if used by that H as a pattern that indicates
non-halting behavior causes the P(P) built on the H that uses that
pattern to Halt.

You make the error of incorrectly assuming that a finite pattern exist
that detects that P(P) is non-halting that can be in the H that it is
built on.

The "Pathological" interconnection between P and H makes sure that there
doesn't exist a pattern that H can use.

Note also, you argument that the input to H(P,P) doesn't represent P(P)
means that P fails to meet its design requirments, as P is specified to
ask H about the halting of P applied to its input, so if the input to
H(P,P) is does not brhave like P(P) you P is defined incorrectly.

So, by your stipulation above, H will just fail to answer to H(P,P) as
there is no pattern that it CAN detect that proves that its input will
never reach its final state, as if H(P,P) ever returns 0, then P(P) will
Halt, so H(P.P) can not correctly return 0.

FAIL.

On 6/30/22 2:22 PM, olcott wrote:
> On 6/30/2022 1:17 PM, dklei...@gmail.com wrote:
>> On Wednesday, June 29, 2022 at 4:36:13 PM UTC-7, olcott wrote:
>>> On 6/29/2022 6:10 PM, dklei...@gmail.com wrote:
>>>> On Wednesday, June 29, 2022 at 1:46:15 PM UTC-7, olcott wrote:
>>>>
>>>>> C is a little ambiguous across implementation environments, yet C
>>>>> translated into x86 has precisely specified semantics.
>>>>>
>>>> "C translated into x86" is called compilation (assuming x86 means
>>>> x86 assembly language).
>>>>>
>>>>> When C is translated into the x86 language we get a complete directed
>>>>> graph of all control flow.
>>>>>
>>>> Control is usually easier to understand in C than assembler.
>>>>>
>>>>> That people say that I am incorrect on the basis of their lack of
>>>>> understanding of the semantics of the x86 language is dishonest.
>>>>>
>>>> Just go read comp.lang.c or one of the others. The semantics laid
>>>> down in the standards are quite complex and hardly anyone actually
>>>> understands them. There is no evidence you do.
>>> All of the the conrol flow semantics of the x86 language comes as a
>>> ready-made directed graph with integer subscripts.
>>>
>>> This is much easier for machine processing.
>>
>> And these alleged control flow structures are ...... ?
>
>
> [0000117d](05)  e8f0fdffff call 00000f72
> [00001187](02)  7402       jz 0000118b
> [00001189](02)  ebfe       jmp 00001189
> [0000118c](01)  c3         ret
>
>

And where is that in the trace of P(P)?

Sounds like you are just serving your Herring Red.

On 6/30/22 10:48 AM, olcott wrote:
> On 6/30/2022 6:20 AM, Malcolm McLean wrote:
>> On Wednesday, 29 June 2022 at 20:54:28 UTC+1, Ben Bacarisse wrote:
>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>>
>>>> If we put to one side the fact that a simulation-based halting decider
>>>> is invalid* it is a FACT that such a decider, to be considered valid,
>>>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>>>> that without invoking "infinite recursion" (or aborting same) then it
>>>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>>>> decision on P(P).
>>> There's a reason the theorem is not stated about functions in some
>>> programming language. Such a description would be just too prone to
>>> misinterpretation or trickery.
>>>
>> Initially I thought that was what he was doing. There are all sorts of
>> ways
>> you can make it look like a C function is classifying the "pathological"
>> input correctly, when of course it is not. But I misjudged PO. It goes
>> far deeper than that.
>>> If you have to use C then the halting problem is best expressed in terms
>>> of programs. A halting decider would be a C program that returns
>>> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
>>> whether the C program whose source is given in argv[1] halts or not when
>>> run with argv[2] as its sole command line argument.
>>>
>>> It seemed like the polite thing to do to move away from Turing machines
>>> (which PO does not understand) to C. But the specification in terms of
>>> C functions has allowed PO to indulge his penchant for obfuscation to
>>> the
>>> point where no one is really sure exactly what mistake he's made.
>>>
>> Currently we've got a distinction between "the correctly emulated input
>> to H" and "the behaviour of P(P) when run". This is just pure insanity.
>
> Not when you look at what the code actually does.

Since you haven't shown it, that is no proof!

>
>> But I think I see where it comes from. If your dry run doesn't match the
>> actual behaviour of the program when executed, then either the dry run
>> was
>> wrong or the computer has a fault.
>
> P(P) depends on the return value from H(P,P) and the emulated input to
> H(P,P) cannot depend on anything. One path has a conditional branch and
> the other path does not have this conditional branch.

Why doesn't the emulated input to H(P,P) depend on what the call to
H(P,P) in it does?

>
>> If you reject both of those explanations,
>> what are you left with? Claiming that the basic rules of programming
>> logic
>> are wrong.
>
> You just have to look at the actual code and see that it is necessarily
> correct according to the semantics of the x86 language. If this is
> beyond you technical skill then hypothesize that the code is correct.
> When we even hypothesize that the code is correct then within this
> hypothesis H(P,P)==0 is correct.

WHAT CODE?

The code of P(P) call H(P,P) which you have sid returns 0 so P(P) Will Halt.

THAT is what the x86 code does. A Call to H does exactly what the code
of H does, which you have stipuated H(P,P) returns 0, and claimed it is
correct. (You can't stipulate correctness).

If H(P,P) returns 0, then the call to H with parameters P and P, will
eventually return 0, as that is a correct x86 emualtion.

Your presumptin that H does a complete and correct emulation is proved
wrong, because that isn't what the other call the H(P,P) did, and H was
claimed to be a pure function of its inputs.

>
> Saying that H(P,P)==0 is incorrect disagrees with the semantics of the
> x86 language, that is the same as disagreeing with arithmetic.

WHAT part of the x86 language says that?

You make the claim, but haven't actually showed any actual x86 execution
that shows it, only your CLAIM that if H does what you say (which is an
immposibility) that you show what you claim.

Until you can show how an x86 processor can perform and ACTUAL complete
and correct emulation of a non-halting process (which will take
emulating an infinte number of instruction) in finite time and then
return the non-halting answer, you prove is just shown to be invalid.

>
>>>
>>> He did originally understand that H(X,Y) should report on the "halting"
>>> of X(Y), but he's long since abandoned that obvious model.
>>>
>
> As I progress through this my understanding deepens and I make
> corrections to my prior views.

And you still have very many errors, reviewing your work is a target
rich environment.

>
>> He's been driven from it. He still basically knows what a halt decider
>> is.
>> He's forced into more and more absurd contortions to try to keep up
>> the claim that H is correct.
>
> Why do you insist on disagreeing with the semantics of the x86 language?
>

He does, you aren't actually using the semantic of the x86 language,
since you don't actually emualate the results of the call to H but just
incorrectly presume what it must do, because you postulate that H does
an impossible task, that of doing infinite work in finite time.

On 6/30/22 10:48 AM, olcott wrote:
> On 6/30/2022 6:20 AM, Malcolm McLean wrote:
>> On Wednesday, 29 June 2022 at 20:54:28 UTC+1, Ben Bacarisse wrote:
>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>>
>>>> If we put to one side the fact that a simulation-based halting decider
>>>> is invalid* it is a FACT that such a decider, to be considered valid,
>>>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>>>> that without invoking "infinite recursion" (or aborting same) then it
>>>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>>>> decision on P(P).
>>> There's a reason the theorem is not stated about functions in some
>>> programming language. Such a description would be just too prone to
>>> misinterpretation or trickery.
>>>
>> Initially I thought that was what he was doing. There are all sorts of
>> ways
>> you can make it look like a C function is classifying the "pathological"
>> input correctly, when of course it is not. But I misjudged PO. It goes
>> far deeper than that.
>>> If you have to use C then the halting problem is best expressed in terms
>>> of programs. A halting decider would be a C program that returns
>>> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
>>> whether the C program whose source is given in argv[1] halts or not when
>>> run with argv[2] as its sole command line argument.
>>>
>>> It seemed like the polite thing to do to move away from Turing machines
>>> (which PO does not understand) to C. But the specification in terms of
>>> C functions has allowed PO to indulge his penchant for obfuscation to
>>> the
>>> point where no one is really sure exactly what mistake he's made.
>>>
>> Currently we've got a distinction between "the correctly emulated input
>> to H" and "the behaviour of P(P) when run". This is just pure insanity.
>
> Not when you look at what the code actually does.

Nope, P(P) Halts if H(P,P) returns 0, so the input to H(P,P) does the
same since the DEFINIION of P is that it is asking H about P called with
its input.

>
>> But I think I see where it comes from. If your dry run doesn't match the
>> actual behaviour of the program when executed, then either the dry run
>> was
>> wrong or the computer has a fault.
>
> P(P) depends on the return value from H(P,P) and the emulated input to
> H(P,P) cannot depend on anything. One path has a conditional branch and
> the other path does not have this conditional branch.

So, you are saying that H doesn't havd any conditional branches?

Or are you still stuck in your error that somehow P doesn't include the
code of H?

If so, the does this function halt?

void R() {
return G();
}

If you can answer about P without including H, why can't you handle R
without knowing G?

>
>> If you reject both of those explanations,
>> what are you left with? Claiming that the basic rules of programming
>> logic
>> are wrong.
>
> You just have to look at the actual code and see that it is necessarily
> correct according to the semantics of the x86 language. If this is
> beyond you technical skill then hypothesize that the code is correct.
> When we even hypothesize that the code is correct then within this
> hypothesis H(P,P)==0 is correct.

So, you are explicitly invoking that fallacy of assuming the conclusion?

You CAN'T "assume the code is correct" to show that the code is correct.

>
> Saying that H(P,P)==0 is incorrect disagrees with the semantics of the
> x86 language, that is the same as disagreeing with arithmetic.
>

HOW?

x86 semantics says that P(P) will halts if H(P,P) returns 0, and that
H(P,P), if H is a pure function of its input will always do the same
thing on all calls, so if the call from main to H(P,P) returns 0, so
does the call in P, and so does emulating that code as an x86 program.

>>>
>>> He did originally understand that H(X,Y) should report on the "halting"
>>> of X(Y), but he's long since abandoned that obvious model.
>>>
>
> As I progress through this my understanding deepens and I make
> corrections to my prior views.

Which, since you insisted on those just as hard, shows the current idea
still can be just as wrong, as they have been proven to be.

>
>> He's been driven from it. He still basically knows what a halt decider
>> is.
>> He's forced into more and more absurd contortions to try to keep up
>> the claim that H is correct.
>
> Why do you insist on disagreeing with the semantics of the x86 language?
>

He doesn't, you do.

On 6/30/22 12:10 PM, olcott wrote:
> On 6/30/2022 9:42 AM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Wednesday, 29 June 2022 at 20:54:28 UTC+1, Ben Bacarisse wrote:
>>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>>>
>>>>> If we put to one side the fact that a simulation-based halting decider
>>>>> is invalid* it is a FACT that such a decider, to be considered valid,
>>>>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>>>>> that without invoking "infinite recursion" (or aborting same) then it
>>>>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>>>>> decision on P(P).
>>>> There's a reason the theorem is not stated about functions in some
>>>> programming language. Such a description would be just too prone to
>>>> misinterpretation or trickery.
>>>>
>>> Initially I thought that was what he was doing. There are all sorts
>>> of ways
>>> you can make it look like a C function is classifying the "pathological"
>>> input correctly, when of course it is not. But I misjudged PO. It goes
>>> far deeper than that.
>>
>> I agree. PO's nonsense goes much deeper than simple misinterpretation or
>> trickery.  Remember that this is someone prepared to assert that
>>
>>    "the fact that a computation halts does not entail that it is a
>>    halting computation"
>>
>>    "Whether a computation is finite is more nuanced than it simply stops
>>    running"
>>
>
> If I ever said that I was incorrect.
> The actual truth is that we cannot correctly construe that a sequence of
> configurations halts unless it actually reaches its own final state.

And we can ot correctly construe that a sequenc of configurations
doesn't halt unless when that sequence is continued indefinitely it will
NEVER reach a final state.

Just because H stops its emulation doesn't mean we don't need to look
farther since halting is DEFINED by the behavior of the actual machine,
not a partial emulation of it. (thus the "by H" part you add is invalid,
if H doesn't actually do a complete and correct emulation, which means
it can't abort its emulation.

Note, that doesn't say that a partial emulation can't prove that some
sequences would never end, but that proof needs to refer to some other
emulation, not the (partial, since it is aborted) emulation done by H.

>
>> And when he invented his "new halting criterion" he stated both of these
>> facts about it:
>>
>>    "We can know that my halt deciding criteria is the same as the halting
>>    problem"
>>
>> and
>>
>>    "This maps to every element of the conventional halting problem set of
>>    non-halting computations and a few more."
>>
>> Similarly, he said both
>>
>>    "Furthermore I have repeated H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn many
>>    times."
>>
>> and
>>
>>    "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>    times."
>>
>> within a few days of each other and he has never even acknowledged this
>> contradiction much less state which he now stands by.
>>
>> It helps to keep in mind the full weight of nonsense and
>> misunderstanding that has built up in PO's mind over the years.
>
> I have said many things that turned out to be incorrect previously. That
> is not relevant to my current position. This is my current position on
> Linz.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final
> state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.

Which is wrong since H^.qy is NOT a final state.

>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
> final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
>

On 2022-06-30 14:53:13 +0000, olcott said:

> On 6/30/2022 6:32 AM, Mikko wrote:
>> On 2022-06-29 19:18:05 +0000, Mr Flibble said:
>>
>>> void Px(u32 x)
>>> {
>>>    H(x, x);
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>> }
>>  ...
>>> it is obvious that Px should always halt if H is a valid halt decider
>>> that always returns a decision to its caller (Px).
>>
>> More generally, Px halts with every x if H is any decider. Conversely,
>> if Px does not halt with some x then H is not a decider.
>>
>> Mikko
>>
>
> A function only halts when it reaches its "ret" instruction.

By that definition a C function never halts as there is no "ret" instruction
in C. There is a return statement but that is not the same, and it is
optional anyway. So by your definition, the C function

void F(in x)
{
}

never halts. Neither does

#include <setjmp.h>
void G(jmp_buf b)
{
longjmp(b, 1);
}

Even some machine language have no "ret" instruction. E.g., I have
written programs in the assembly language of Elliot 803, which has
no ret instruction in its instruction set.

Mikko

On 7/1/22 5:29 AM, Mikko wrote:
> On 2022-06-30 14:53:13 +0000, olcott said:
>
>> On 6/30/2022 6:32 AM, Mikko wrote:
>>> On 2022-06-29 19:18:05 +0000, Mr Flibble said:
>>>
>>>> void Px(u32 x)
>>>> {
>>>>    H(x, x);
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>> }
>>>  ...
>>>> it is obvious that Px should always halt if H is a valid halt decider
>>>> that always returns a decision to its caller (Px).
>>>
>>> More generally, Px halts with every x if H is any decider. Conversely,
>>> if Px does not halt with some x then H is not a decider.
>>>
>>> Mikko
>>>
>>
>> A function only halts when it reaches its "ret" instruction.
>
> By that definition a C function never halts as there is no "ret"
> instruction
> in C. There is a return statement but that is not the same, and it is
> optional anyway. So by your definition, the C function
>
>   void F(in x)
>   {
>   }
>
> never halts. Neither does
>
>   #include <setjmp.h>
>   void G(jmp_buf b)
>   {
>     longjmp(b, 1);
>   }
>
> Even some machine language have no "ret" instruction. E.g., I have
> written programs in the assembly language of Elliot 803, which has
> no ret instruction in its instruction set.
>
> Mikko
>
>

Even better, in x86 assembly you can return to your caller without using
a ret instruction. Don't think any C compliers generate that code, but
you can do it.

Just shows how poorly PO understands the details of "Requirements".

On 7/1/2022 4:29 AM, Mikko wrote:
> On 2022-06-30 14:53:13 +0000, olcott said:
>
>> On 6/30/2022 6:32 AM, Mikko wrote:
>>> On 2022-06-29 19:18:05 +0000, Mr Flibble said:
>>>
>>>> void Px(u32 x)
>>>> {
>>>>    H(x, x);
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>> }
>>>  ...
>>>> it is obvious that Px should always halt if H is a valid halt decider
>>>> that always returns a decision to its caller (Px).
>>>
>>> More generally, Px halts with every x if H is any decider. Conversely,
>>> if Px does not halt with some x then H is not a decider.
>>>
>>> Mikko
>>>
>>
>> A function only halts when it reaches its "ret" instruction.
>
> By that definition a C function never halts as there is no "ret"
> instruction
> in C. There is a return statement but that is not the same, and it is
> optional anyway. So by your definition, the C function
>
>   void F(in x)
>   {
>   }
>

_F()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](01) 5d pop ebp
[00001196](01) c3 ret
Size in bytes:(0005) [00001196]

> never halts. Neither does
>
>   #include <setjmp.h>
>   void G(jmp_buf b)
>   {
>     longjmp(b, 1);
>   }
>
> Even some machine language have no "ret" instruction. E.g., I have
> written programs in the assembly language of Elliot 803, which has
> no ret instruction in its instruction set.
>
> Mikko

It is only pure C functions (no library calls) translated into COFF
object file machine code by the Visual Studio C compiler that can be
used as input to x86utm operating system's halt decider.

--
Copyright 2022 Pete Olcott

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

On 2022-07-01 12:38:34 +0000, olcott said:

> On 7/1/2022 4:29 AM, Mikko wrote:

>> On 2022-06-30 14:53:13 +0000, olcott said:

>>> A function only halts when it reaches its "ret" instruction.

> It is only pure C functions (no library calls) translated into COFF
> object file machine code by the Visual Studio C compiler that can be
> used as input to x86utm operating system's halt decider.

You didn't say that only pure C functions (no library calls) translated
into COFF object file machine code by the Visual Studio C compiler halt.

Mikko

On 7/1/2022 10:18 AM, Mikko wrote:
> On 2022-07-01 12:38:34 +0000, olcott said:
>
>> On 7/1/2022 4:29 AM, Mikko wrote:
>
>>> On 2022-06-30 14:53:13 +0000, olcott said:
>
>>>> A function only halts when it reaches its "ret" instruction.
>
>> It is only pure C functions (no library calls) translated into COFF
>> object file machine code by the Visual Studio C compiler that can be
>> used as input to x86utm operating system's halt decider.
>
> You didn't say that only pure C functions (no library calls) translated
> into COFF object file machine code by the Visual Studio C compiler halt.
>
> Mikko
>

The above is the domain of the halt decider H.

--
Copyright 2022 Pete Olcott

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

On Thursday, June 30, 2022 at 5:10:30 PM UTC+1, olcott wrote:
> 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.

Exactly. H(T, X) must tell us whether T(X) actually halts or not. In particular, H(P, P) must tell us whether P(P) actually halts or not.

> int sum(int X, int Y)
> {
> return X + Y;
> }
>
> In the same way that sum(3,4) cannot return the sum of 5 + 8, H(P,P)
> cannot determine the halt status of P(P).

And here you admit that your H does not do this.
You seem to realise that H(P, P) cannot produce the right answer by definition, but rather than accept that this proves there cannot be a halt decider, you seem to think that your halt decider is somehow exempt from answering this question correctly and that therefore you have a halt decider that meets all the requirements. This is not the case. If your halt decider gets P(P) wrong, then it does not meet the requirements.

> *Here is the proof that the correctly emulated input to*
> *H(P,P) never halts and the directly executed P(P) halts*

If you are saying that an emulation of P(P) will never halt, but that P(P) run directly will halt, then it is not being correctly emulated, because the behaviour is different.

If the emulation is going wrong, H(P, P) needs to tell us about the result of actual P(P), not the result of the emulation.

> P(P) is provably not the actual behavior of the actual input to H(P,P).

You keep saying this. It is a little unclear what you mean, H is a function, and P and P are the arguments supplied to it - what would normally be called the "input". Are you talking about the emulation done by H? Or the result from it?

On 7/1/2022 11:39 AM, Paul N wrote:
> On Thursday, June 30, 2022 at 5:10:30 PM UTC+1, olcott wrote:
>> 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.
>
> Exactly. H(T, X) must tell us whether T(X) actually halts or not. In particular, H(P, P) must tell us whether P(P) actually halts or not.
>

*This is necessarily true thus impossibly false*
Every simulating halt decider that correctly simulates its input until
it correctly determines that this simulated input would never reach its
final state, correctly rejects this input as non-halting.

It is provably not the case when H(P,P) correctly emulates its input
with an x86 emulator that the behavior of the emulated input is the same
as the behavior of the directly executed P(P).

Anyone that disagrees with this is disagreeing with the semantics of the
x86 language.

INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986
https://css.csail.mit.edu/6.858/2019/readings/i386.pdf

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

int main()
{ P(P);
}

_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]

_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
[000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H

Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
[000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.

[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages

--
Copyright 2022 Pete Olcott

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

On Friday, July 1, 2022 at 9:52:10 AM UTC-7, olcott wrote:
>
> Anyone that disagrees with this is disagreeing with the semantics of the
> x86 language.
>
> INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986
> https://css.csail.mit.edu/6.858/2019/readings/i386.pdf
> void P(u32 x)

How is this compatible with requiring the Visual C compiler?

On 7/1/2022 12:41 PM, dklei...@gmail.com wrote:
> On Friday, July 1, 2022 at 9:52:10 AM UTC-7, olcott wrote:
>>
>> Anyone that disagrees with this is disagreeing with the semantics of the
>> x86 language.
>>
>> INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986
>> https://css.csail.mit.edu/6.858/2019/readings/i386.pdf
>> void P(u32 x)
>
> How is this compatible with requiring the Visual C compiler?

The above precisely documents that machine architecture and its machine
code which forms a bijection to Intel 80386 assembly language.

--
Copyright 2022 Pete Olcott

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

On Friday, July 1, 2022 at 5:52:10 PM UTC+1, olcott wrote:
> On 7/1/2022 11:39 AM, Paul N wrote:
> > On Thursday, June 30, 2022 at 5:10:30 PM UTC+1, olcott wrote:
> >> 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.
> >
> > Exactly. H(T, X) must tell us whether T(X) actually halts or not. In particular, H(P, P) must tell us whether P(P) actually halts or not.
> >
> *This is necessarily true thus impossibly false*
> Every simulating halt decider that correctly simulates its input until
> it correctly determines that this simulated input would never reach its
> final state, correctly rejects this input as non-halting.

Yes, but you have not shown us a simulating halt decider that correctly simulates its input until it correctly determines that this simulated input would never reach its final state. You've shown us one which incorrectly determines that P(P) does not reach its final state.

> It is provably not the case when H(P,P) correctly emulates its input
> with an x86 emulator that the behavior of the emulated input is the same
> as the behavior of the directly executed P(P).

How is this provable? You certainly haven't proved it. You have clearly stated numerous times that your H does not correctly emulate its input.

> Anyone that disagrees with this is disagreeing with the semantics of the
> x86 language.

There's nothing in the semantics of the x86 language that says an emulation can have provably different behaviour from the code it is emulating yet still count as "correct".

On 7/1/2022 1:34 PM, Paul N wrote:
> On Friday, July 1, 2022 at 5:52:10 PM UTC+1, olcott wrote:
>> On 7/1/2022 11:39 AM, Paul N wrote:
>>> On Thursday, June 30, 2022 at 5:10:30 PM UTC+1, olcott wrote:
>>>> 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.
>>>
>>> Exactly. H(T, X) must tell us whether T(X) actually halts or not. In particular, H(P, P) must tell us whether P(P) actually halts or not.
>>>
>> *This is necessarily true thus impossibly false*
>> Every simulating halt decider that correctly simulates its input until
>> it correctly determines that this simulated input would never reach its
>> final state, correctly rejects this input as non-halting.
>
> Yes, but you have not shown us a simulating halt decider that correctly simulates its input until it correctly determines that this simulated input would never reach its final state. You've shown us one which incorrectly determines that P(P) does not reach its final state.
>
>> It is provably not the case when H(P,P) correctly emulates its input
>> with an x86 emulator that the behavior of the emulated input is the same
>> as the behavior of the directly executed P(P).
>
> How is this provable?

This proves that the correct and complete x86 emulation of the input to
H(P,P) by H would never reach the "ret" instruction of P.

On 6/14/2022 6:47 AM, Paul N wrote:
> Yes, it is clear to us humans watching
> it that the program is repeating itself.
> Thus we can appreciate that it will never
> reach the final "ret" - indeed, it won't
> even get to the infinite loop identified above.

And it also proves that the directly executed P(P) does reach its final
"ret" instruction.

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

int main()
{ P(P);
}

_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]

_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
[000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H

Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
[000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.

[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages

--
Copyright 2022 Pete Olcott

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