XPost: comp.theory, sci.logic, sci.math

On 5/28/2022 10:23 AM, Dennis Bush wrote:

On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote:

On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote:

On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote:

The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final >>>>>>>>>>>>>>>>>> state.

I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not. >>>>>>>>>>>>>>>>>

The distinction that I make between represent and specify >>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas >>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P) >>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not >>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P). >>>>>>>>>>>>>>>>
A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>> source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is given as >>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions. >>>>>>>>>>>>>>> It is given a representation of a computation.

No it is not and you know that it is not. A halt decider is >>>>>>>>>>>>>> given a finite string TM description that specifies a >>>>>>>>>>>>>> sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>> entirely different things (and the former certainly does not >>>>>>>>>>>>> 'specify' the latter). It's given either one or the other. >>>>>>>>>>>>> Make up your mind.

André

_Infinite_Loop()
[000012c2](01) 55 push ebp
[000012c3](02) 8bec mov ebp,esp
[000012c5](02) ebfe jmp 000012c5
[000012c7](01) 5d pop ebp
[000012c8](01) c3 ret
Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>> with the sequence of steps of its correct simulation.

That is not a sequence of configurations. It is a piece of >>>>>>>>>>> assembly code which represents a subroutine which is an
infinite loop. The sequence of configurations would look >>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the following >>>>>>>>> *only* if you (a) interpret it as representing x86 instructions >>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator. >>>>>>>>>

Because no one in their right mind would think of doing it
otherwise those ridiculously self-evident facts need not be stated. >>>>>>>

You are the one who constantly makes much ado about nothing about >>>>>>> the fact that Turing Machines can ONLY accept finite strings as
their inputs and object to anyone who suggests that something might >>>>>>> compute some function which isn't over strings.

You don't seem to understand exactly what a finite string is. A
finite string is simply a sequence of symbols. Given two strings, >>>>>>> you can ask questions like which is longer or whether one is a
substring or permutation of the other, but not much else.

That's because neither strings nor the symbols they are composed of >>>>>>> have any meaning whatsoever. They are just sequences of
uninterpreted tokens. As soon as you start talking about 'sequences >>>>>>> of configurations' or 'numerical values' or anything along those >>>>>>> lines you are no longer talking about finite strings, but about the >>>>>>> entities which those strings represent to a particular TM/program. >>>>>>>
Part of designing a TM involves specifying exactly how a string is >>>>>>> to be interpreted (however 'ridiculously self-evident' it might
seem to you) So yes, they need to be stated.

If it was not for communication context then every single rule of >>>>>>>> grammar would have to be repeated with every sentence and every >>>>>>>> definition of every work would have to be repeated over and over. >>>>>>>>

You keep claiming that the input to the decider is a sequence of >>>>>>>>> configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what *you* >>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
posts ago, but nothing which made this clear. Repeating it over and >>>>>>> over again doesn't add any clarity.

The question originally arose when you objected to the claim that >>>>>>> the input to a halt decider represents a computation (or TM
description/input string pair) and instead insisted that it
specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the
ingredients to a milkshake and because there is a standard practice >>>>>> for making milkshakes they already know when and how the x86
source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a representation of >>>>>>> a computation specifies a sequence of configurations, but that
doesn't explain why you so vehemently objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a
computation. So clearly you mean something else altogether.

André

Because your brain is welded in rebuttal mode you will always act
like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make a
clear sentence because you misuse the English language to hide your
lies.

It is easily provable that the C function H(P,P)==0 is correct on the
basis of the fact correct execution trace of the x86 source-code of
input to H(P,P) shows that P would never reach its "ret" instruction.

Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as >>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below*

#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 // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

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

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

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

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

Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each

of these lines is multiple instructions of the inner H performing the emulation of them.

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

Here is where H makes its error of aborting too soon. Explanation below:

Several different confusions (see below).

If the execution trace of function H() called by function P() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no conditional branch or indexed jump instructions in P().

This condition is not met.

(1) is proven
(2) is proven // Third column shows TOS value of P's machine address
(3) is proven //

There are branches / jumps in the *program* P contained in the function H that can abort.

We are not looking for jumps, we are looking for code that can change
the behavior of P from one invocation to the next.
(a) conditional branch or
(b) indexed jump instructions (where the index can vary)

The outer H is unable to detect that the inner H will do exactly what the outer H does,

None of this could possibly show that the simulated P ever reaches its
"ret" instruction, thus is irrelevant.

We are not asking:
[A] Does P stop running?

We are asking:
[B] Does the simulated P reach its "ret" instruction?

The answer is no.

Because the definition of halting means that a computation completed
normally and reached is final instruction H would correctly abort its simulation of P and return 0.

Halting problem undecidability and infinitely nested simulation (V5)

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


namely abort its simulation and return 0. But the fixed algorithm of H (actually Ha) is unable to see that. H1 simulating this same input *is*
able to see the H embedded in P abort and return 0, causing P to halt.

(4) With no function call returns from H() to P().

This does happen, but the fixed algorithm of H (again Ha) is unable to simulate to the point that this happens.

then the function call from P() to H() is infinitely recursive.

...[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) = 237 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

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 5/28/22 11:48 AM, olcott wrote:

On 5/28/2022 10:23 AM, Dennis Bush wrote:

On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote:

On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>

The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final >>>>>>>>>>>>>>>>>>> state.

I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are >>>>>>>>>>>>>>>>>> not.

The distinction that I make between represent and specify >>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas >>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P) >>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not >>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P). >>>>>>>>>>>>>>>>>
A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>> source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is given as >>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions. >>>>>>>>>>>>>>>> It is given a representation of a computation. >>>>>>>>>>>>>>>>

No it is not and you know that it is not. A halt decider is >>>>>>>>>>>>>>> given a finite string TM description that specifies a >>>>>>>>>>>>>>> sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>>> entirely different things (and the former certainly does not >>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other. >>>>>>>>>>>>>> Make up your mind.

André

_Infinite_Loop()
[000012c2](01)  55              push ebp >>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>> [000012c8](01)  c3              ret
Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>

That is not a sequence of configurations. It is a piece of >>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the following >>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions >>>>>>>>>> and (b) actually execute it on an x86 or some appropriate
emulator.

Because no one in their right mind would think of doing it
otherwise those ridiculously self-evident facts need not be
stated.

You are the one who constantly makes much ado about nothing about >>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>> their inputs and object to anyone who suggests that something might >>>>>>>> compute some function which isn't over strings.

You don't seem to understand exactly what a finite string is. A >>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>> substring or permutation of the other, but not much else.

That's because neither strings nor the symbols they are composed of >>>>>>>> have any meaning whatsoever. They are just sequences of
uninterpreted tokens. As soon as you start talking about 'sequences >>>>>>>> of configurations' or 'numerical values' or anything along those >>>>>>>> lines you are no longer talking about finite strings, but about the >>>>>>>> entities which those strings represent to a particular TM/program. >>>>>>>>
Part of designing a TM involves specifying exactly how a string is >>>>>>>> to be interpreted (however 'ridiculously self-evident' it might >>>>>>>> seem to you) So yes, they need to be stated.

If it was not for communication context then every single rule of >>>>>>>>> grammar would have to be repeated with every sentence and every >>>>>>>>> definition of every work would have to be repeated over and over. >>>>>>>>>

You keep claiming that the input to the decider is a sequence of >>>>>>>>>> configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what *you* >>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few >>>>>>>> posts ago, but nothing which made this clear. Repeating it over and >>>>>>>> over again doesn't add any clarity.

The question originally arose when you objected to the claim that >>>>>>>> the input to a halt decider represents a computation (or TM
description/input string pair) and instead insisted that it
specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the
ingredients to a milkshake and because there is a standard practice >>>>>>> for making milkshakes they already know when and how the x86
source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a representation of >>>>>>>> a computation specifies a sequence of configurations, but that >>>>>>>> doesn't explain why you so vehemently objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a
computation. So clearly you mean something else altogether.

André

Because your brain is welded in rebuttal mode you will always act >>>>>>> like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make a
clear sentence because you misuse the English language to hide your >>>>>> lies.

It is easily provable that the C function H(P,P)==0 is correct on the >>>>> basis of the fact correct execution trace of the x86 source-code of
input to H(P,P) shows that P would never reach its "ret" instruction. >>>>

Again, I say HOW, since the CORRECT emulation of the input to
H(P,P), as
shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below*

#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 // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

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

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

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

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

Starting here is where the trace is incomplete.  The emulation of the
instructions of the inner instance of H are not shown.  Also the lines
below are not emulated by the top level H.  They are emulated by the
inner H called by P.  So in between each of these lines is multiple
instructions of the inner H performing the emulation of them.

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

Here is where H makes its error of aborting too soon.  Explanation below: >>

Several different confusions (see below).

If the execution trace of function H() called by function P() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no conditional branch or indexed jump instructions in P().

This condition is not met.

(1) is proven
(2) is proven // Third column shows TOS value of P's machine address
(3) is proven //

But there is no Valid rule that actually uses (3), so your whole Thesis
is incorrect.

There are branches / jumps in the *program* P contained in the
function H that can abort.

We are not looking for jumps, we are looking for code that can change
the behavior of P from one invocation to the next.
(a) conditional branch or
(b) indexed jump instructions (where the index can vary)

The key is that you don't correctly model H. H(P,P) doesn't just
infinitely simulate its input, it WILL abort it at some point, we know
that because you make the assertion that it does this, and then you
INCORRECT assert that this action is correct.

The outer H is unable to detect that the inner H will do exactly what
the outer H does,

None of this could possibly show that the simulated P ever reaches its
"ret" instruction, thus is irrelevant.

It shows that the CORRECT simulation (not the simulation by H, but by a
CORRECT simulator) of the same input will reach that ret statement.

We are not asking:
[A] Does P stop running?

We are asking:
[B] Does the simulated P reach its "ret" instruction?

No, we SHOULD be asking [C] "does the CORRECT simulation of P reach its
ret instruction", but YOU are asking [D] "does the simulation by H reach
its ret instruction."

[C] is a valid restatement of the halting criteria (with correct being
by definition a UTM).

[] is NOT a valid restatement

The answer is no.

The answer to [C] is yes, so it Halts, the answer to [D] is no, so it
doesn't POOP.

Because the definition of halting means that a computation completed
normally and reached is final instruction H would correctly abort its simulation of P and return 0.

Right, THE COMPUTATION, not an incomplete simulation of it. The
COMPUTATION P(P) Halts, so the CORRECT answer, for a Halting decider H
for H(P,P) is Yes, but your H answers INCORRECTLY 0.

Halting problem undecidability and infinitely nested simulation (V5)

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

A bunch of FALLACIES.

namely abort its simulation and return 0.  But the fixed algorithm of H (actually Ha) is unable to see that.  H1 simulating this same input *is* able to see the H embedded in P abort and return 0, causing P to halt.

Right, the fact that H can't see the halting doesn't mean it doesn't happen.

H1 gets it right and shows that Ha/H was wrong.

(4) With no function call returns from H() to P().

This does happen, but the fixed algorithm of H (again Ha) is unable to
simulate to the point that this happens.

then the function call from P() to H() is infinitely recursive.

...[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) = 237 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 5/28/2022 10:29 AM, Richard Damon wrote:

On 5/28/22 11:05 AM, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote:

On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote:

On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote:

The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>> final state.

I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are >>>>>>>>>>>>>>>>> not.

The distinction that I make between represent and >>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>> specified by P(P).

A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>> source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is given >>>>>>>>>>>>>>> as its input. It is not given a sequence of state >>>>>>>>>>>>>>> transitions. It is given a representation of a computation. >>>>>>>>>>>>>>>

No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>> sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>> other. Make up your mind.

André

_Infinite_Loop()
[000012c2](01)  55              push ebp >>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>> [000012c7](01)  5d              pop ebp
[000012c8](01)  c3              ret
Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>> with the sequence of steps of its correct simulation.

That is not a sequence of configurations. It is a piece of >>>>>>>>>>> assembly code which represents a subroutine which is an
infinite loop. The sequence of configurations would look >>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the
following *only* if you (a) interpret it as representing x86 >>>>>>>>> instructions and (b) actually execute it on an x86 or some
appropriate emulator.

Because no one in their right mind would think of doing it
otherwise those ridiculously self-evident facts need not be stated. >>>>>>>

You are the one who constantly makes much ado about nothing about >>>>>>> the fact that Turing Machines can ONLY accept finite strings as
their inputs and object to anyone who suggests that something
might compute some function which isn't over strings.

You don't seem to understand exactly what a finite string is. A
finite string is simply a sequence of symbols. Given two strings, >>>>>>> you can ask questions like which is longer or whether one is a
substring or permutation of the other, but not much else.

That's because neither strings nor the symbols they are composed >>>>>>> of have any meaning whatsoever. They are just sequences of
uninterpreted tokens. As soon as you start talking about
'sequences of configurations' or 'numerical values' or anything
along those lines you are no longer talking about finite strings, >>>>>>> but about the entities which those strings represent to a
particular TM/program.

Part of designing a TM involves specifying exactly how a string
is to be interpreted (however 'ridiculously self-evident' it
might seem to you) So yes, they need to be stated.

If it was not for communication context then every single rule >>>>>>>> of grammar would have to be repeated with every sentence and
every definition of every work would have to be repeated over
and over.

You keep claiming that the input to the decider is a sequence >>>>>>>>> of configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what
*you* mean by 'specify'. You gave a bit of wishy-washy verbiage a >>>>>>> few posts ago, but nothing which made this clear. Repeating it
over and over again doesn't add any clarity.

The question originally arose when you objected to the claim that >>>>>>> the input to a halt decider represents a computation (or TM
description/input string pair) and instead insisted that it
specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the
ingredients to a milkshake and because there is a standard
practice for making milkshakes they already know when and how the
x86 source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a representation
of a computation specifies a sequence of configurations, but that >>>>>>> doesn't explain why you so vehemently objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a
computation. So clearly you mean something else altogether.

André

Because your brain is welded in rebuttal mode you will always act
like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make a
clear sentence because you misuse the English language to hide your
lies.

It is easily provable that the C function H(P,P)==0 is correct on
the basis of the fact correct execution trace of the x86 source-code
of input to H(P,P) shows that P would never reach its "ret"
instruction.

Again, I say HOW, since the CORRECT emulation of the input to H(P,P),
as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H
is defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below*

No, it isn't, because it LIES.

#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      // push P >> [00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P >> [0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

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

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

Begin Local Halt Decider Simulation   Execution Trace Stored at:212352

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

// The emulated H emulates the first seven instructions of P

So, the following is NOT an emulation of the P that the top level H is emulating, and

Right.

thus NOT part of a CORRECT x86 emulation of the program.

Wrong.

Just like the first invocation of infinite recursion is the root cause
of the infinite recursion the first invocation of infinitely nested x86 emulation is its root cause.


You are basically saying that when a C function H emulates another C
function P and this second C function in

I spent a year of development of the x86utm operating system so that
when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
to an arbitrary recursive depth.

I don't show the 236 pages of the emulation of H because we can simply hypothesize that it merely emulates its input and then verify that this hypothesis is correct on the basis that the emulation of the inputs to
H(P,P) always derive the same execution trace of P.

LIES -> False Results.

FAIL

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

UNSOUND LOGIC. This conclusion based on an INCORRECT logicial deduction.

No proof for the rule has been given.

If the execution trace of function H() called by function P() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no conditional branch or indexed jump instructions in P().

FALSE RULE, No such rules exists based on CONDITIONAL simulation (due to
Halt Deciding). You logic is unsound as it assumes that the H that P
calls never aborts its simulation. The rule that this seems to be based
on needs no conditional in the FULL execution path from one invocation
of H to the next, and there are in the "untraced" H.

(4) With no function call returns from H() to P().
then the function call from P() to H() is infinitely recursive.

...[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) = 237 pages

I have pointed out several ERRORS in you "Proof", where you quote rules
that aren't quite correct.

My guess is you are just going to ignore those comment.

Provide reference for the rules AS YOU USE THEM, or you are just shown
to be a LIAR.

You have shown that you just don't understand the basics of the fields
you are talking about, and that includes the epistemology that you wider argument is based on.

You are shown to have NO knowledge of what Truth actually is, and that
you just don't care about what is actually true, just that you need to
do SOMETHING, no matter how perverse, to try to "prove" your great idea
that can't be true.

YOU FAIL.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 5/28/2022 11:11 AM, Dennis Bush wrote:

On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:

On 5/28/2022 10:29 AM, Richard Damon wrote:

On 5/28/22 11:05 AM, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote:

On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>

The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>>

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>> final state.

I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are >>>>>>>>>>>>>>>>>>> not.

The distinction that I make between represent and >>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>>> specified by P(P).

A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>>> source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is given >>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state >>>>>>>>>>>>>>>>> transitions. It is given a representation of a computation. >>>>>>>>>>>>>>>>>

No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>>>> sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>>> other. Make up your mind.

André

_Infinite_Loop()
[000012c2](01) 55 push ebp
[000012c3](02) 8bec mov ebp,esp
[000012c5](02) ebfe jmp 000012c5
[000012c7](01) 5d pop ebp
[000012c8](01) c3 ret
Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>>

That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the
following *only* if you (a) interpret it as representing x86 >>>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>>> appropriate emulator.

Because no one in their right mind would think of doing it >>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated. >>>>>>>>>

You are the one who constantly makes much ado about nothing about >>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>>> their inputs and object to anyone who suggests that something >>>>>>>>> might compute some function which isn't over strings.

You don't seem to understand exactly what a finite string is. A >>>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>>> substring or permutation of the other, but not much else.

That's because neither strings nor the symbols they are composed >>>>>>>>> of have any meaning whatsoever. They are just sequences of
uninterpreted tokens. As soon as you start talking about
'sequences of configurations' or 'numerical values' or anything >>>>>>>>> along those lines you are no longer talking about finite strings, >>>>>>>>> but about the entities which those strings represent to a
particular TM/program.

Part of designing a TM involves specifying exactly how a string >>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it >>>>>>>>> might seem to you) So yes, they need to be stated.

If it was not for communication context then every single rule >>>>>>>>>> of grammar would have to be repeated with every sentence and >>>>>>>>>> every definition of every work would have to be repeated over >>>>>>>>>> and over.

You keep claiming that the input to the decider is a sequence >>>>>>>>>>> of configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what >>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a >>>>>>>>> few posts ago, but nothing which made this clear. Repeating it >>>>>>>>> over and over again doesn't add any clarity.

The question originally arose when you objected to the claim that >>>>>>>>> the input to a halt decider represents a computation (or TM
description/input string pair) and instead insisted that it
specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the
ingredients to a milkshake and because there is a standard
practice for making milkshakes they already know when and how the >>>>>>>> x86 source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a representation >>>>>>>>> of a computation specifies a sequence of configurations, but that >>>>>>>>> doesn't explain why you so vehemently objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a
computation. So clearly you mean something else altogether.

André

Because your brain is welded in rebuttal mode you will always act >>>>>>>> like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>> clear sentence because you misuse the English language to hide your >>>>>>> lies.

It is easily provable that the C function H(P,P)==0 is correct on
the basis of the fact correct execution trace of the x86 source-code >>>>>> of input to H(P,P) shows that P would never reach its "ret"
instruction.

Again, I say HOW, since the CORRECT emulation of the input to H(P,P), >>>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H >>>>> is defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below*

No, it isn't, because it LIES.

#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 // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

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

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

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

// The emulated H emulates the first seven instructions of P

So, the following is NOT an emulation of the P that the top level H is
emulating, and

Right.

thus NOT part of a CORRECT x86 emulation of the program.

Wrong.

Just like the first invocation of infinite recursion is the root cause
of the infinite recursion the first invocation of infinitely nested x86
emulation is its root cause.


You are basically saying that when a C function H emulates another C
function P and this second C function in

I spent a year of development of the x86utm operating system so that
when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could
correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
to an arbitrary recursive depth.

I don't show the 236 pages of the emulation of H because we can simply
hypothesize that it merely emulates its input

Deceptive use of "H" to refer to multiple unrelated computations.

The fixed algorithm of H, hereafter referred to as Ha, and the P that calls it referred to as Pa, does abort and does not "merely emulate". Hn is what does that. And since Pa doesn't call Hn that means we are no longer deciding on Pa but on Pn.

So your argument boils down to: Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.

A halt decider must only compute the mapping from its input to an accept
or reject state based on the actual behavior specified by this input.

It is the case that the correct x86 emulation of the input to H(P,P) by
H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
proved to be correct.





--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 5/28/22 12:28 PM, olcott wrote:

On 5/28/2022 11:11 AM, Dennis Bush wrote:

On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:

On 5/28/2022 10:29 AM, Richard Damon wrote:

On 5/28/22 11:05 AM, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>

The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>>>

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>>> final state.

I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are >>>>>>>>>>>>>>>>>>>> not.

The distinction that I make between represent and >>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>>>> specified by P(P).

A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>>>> source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is given >>>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state >>>>>>>>>>>>>>>>>> transitions. It is given a representation of a >>>>>>>>>>>>>>>>>> computation.

No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>>>>> sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>>>> other. Make up your mind.

André

_Infinite_Loop()
[000012c2](01)  55              push ebp >>>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>>>> [000012c8](01)  c3              ret >>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>>>

That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the >>>>>>>>>>>> following *only* if you (a) interpret it as representing x86 >>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>>>> appropriate emulator.

Because no one in their right mind would think of doing it >>>>>>>>>>> otherwise those ridiculously self-evident facts need not be >>>>>>>>>>> stated.

You are the one who constantly makes much ado about nothing about >>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>>>> their inputs and object to anyone who suggests that something >>>>>>>>>> might compute some function which isn't over strings.

You don't seem to understand exactly what a finite string is. A >>>>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>>>> substring or permutation of the other, but not much else.

That's because neither strings nor the symbols they are composed >>>>>>>>>> of have any meaning whatsoever. They are just sequences of >>>>>>>>>> uninterpreted tokens. As soon as you start talking about
'sequences of configurations' or 'numerical values' or anything >>>>>>>>>> along those lines you are no longer talking about finite strings, >>>>>>>>>> but about the entities which those strings represent to a
particular TM/program.

Part of designing a TM involves specifying exactly how a string >>>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it >>>>>>>>>> might seem to you) So yes, they need to be stated.

If it was not for communication context then every single rule >>>>>>>>>>> of grammar would have to be repeated with every sentence and >>>>>>>>>>> every definition of every work would have to be repeated over >>>>>>>>>>> and over.

You keep claiming that the input to the decider is a sequence >>>>>>>>>>>> of configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what >>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a >>>>>>>>>> few posts ago, but nothing which made this clear. Repeating it >>>>>>>>>> over and over again doesn't add any clarity.

The question originally arose when you objected to the claim that >>>>>>>>>> the input to a halt decider represents a computation (or TM >>>>>>>>>> description/input string pair) and instead insisted that it >>>>>>>>>> specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the >>>>>>>>> ingredients to a milkshake and because there is a standard
practice for making milkshakes they already know when and how the >>>>>>>>> x86 source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a representation >>>>>>>>>> of a computation specifies a sequence of configurations, but that >>>>>>>>>> doesn't explain why you so vehemently objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a >>>>>>>>>> computation. So clearly you mean something else altogether. >>>>>>>>>>
André

Because your brain is welded in rebuttal mode you will always act >>>>>>>>> like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>>> clear sentence because you misuse the English language to hide your >>>>>>>> lies.

It is easily provable that the C function H(P,P)==0 is correct on >>>>>>> the basis of the fact correct execution trace of the x86 source-code >>>>>>> of input to H(P,P) shows that P would never reach its "ret"
instruction.

Again, I say HOW, since the CORRECT emulation of the input to H(P,P), >>>>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H >>>>>> is defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below* >>>>

No, it isn't, because it LIES.

#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      // push P
[00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P
[0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

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

      machine   stack     stack     machine    assembly >>>>>       address   address   data      code       language
      ========  ========  ========  =========  ============= >>>>> ...[00001372][0010229e][00000000] 55         push ebp
...[00001373][0010229e][00000000] 8bec       mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H >>>>>
Begin Local Halt Decider Simulation   Execution Trace Stored at:212352 >>>>>
// H emulates the first seven instructions of P
...[00001352][0021233e][00212342] 55         push ebp      // enter P
...[00001353][0021233e][00212342] 8bec       mov ebp,esp
...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50         push eax      // push P
...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51         push ecx      // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H >>>>>
// The emulated H emulates the first seven instructions of P

So, the following is NOT an emulation of the P that the top level H is >>>> emulating, and

Right.

thus NOT part of a CORRECT x86 emulation of the program.

Wrong.

Just like the first invocation of infinite recursion is the root cause
of the infinite recursion the first invocation of infinitely nested x86
emulation is its root cause.


You are basically saying that when a C function H emulates another C
function P and this second C function in

I spent a year of development of the x86utm operating system so that
when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could >>> correctly emulate P and P calling H(P,P) and this inner P calling H(P,P) >>> to an arbitrary recursive depth.

I don't show the 236 pages of the emulation of H because we can simply
hypothesize that it merely emulates its input

Deceptive use of "H" to refer to multiple unrelated computations.

The fixed algorithm of H, hereafter referred to as Ha, and the P that
calls it referred to as Pa, does abort and does not "merely emulate".
Hn is what does that.  And since Pa doesn't call Hn that means we are
no longer deciding on Pa but on Pn.

So your argument boils down to:  Ha(Pa,Pa)==0 is correct because
Pn(Pn) does  not halt.

A halt decider must only compute the mapping from its input to an accept
or reject state based on the actual behavior specified by this input.

It is the case that the correct x86 emulation of the input to H(P,P) by
H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
proved to be correct.

Nope, you have the words wrong.

A Halt Decider MUST compute the mapping from its input to an accept or
reject state based on the actual mapping it is supposed to computer,
which becomes the DEFINITION of the behavior specified by its inputs.

For Halting H(M,w) Must accept if and only if M(w) halts.

THAT IS THE "Behavior specified by its inputs"

A Halt Decider CAN only compute something that actually computable, and
we have no promise that Halting is that (in fact, that becomes your
claim to be proven). The fact that H can't actually get the right answer doesn't say the question is wrong, just that the question might be
uncomputable and thus the Halting Theorem asserted.

The CORRECT x86 emulation of the input to H(P,P) will EXACTLY match the behavior of P(P), by the definition of CORRECT EMULATION. The fact that
H can't actually do that is irrelevent.

For this structure of design, NO implementation of H will ever be able
to simulate its input till it reaches that ret instruciton.

BUT, If that H aborts its simulation (and thus forfeit the ability to be
a totally correct simulation) and returns 0, then it can be shown that
the CORRECT simulation will reach that ret.

If H doesn't abort its simulation, it then becomes clear that it fails
to answer, and thus is not a decider.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 5/28/22 12:02 PM, olcott wrote:

On 5/28/2022 10:29 AM, Richard Damon wrote:

On 5/28/22 11:05 AM, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote:

On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>

The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>> final state.

I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of
configurations' mean. Richard is perfectly correct. >>>>>>>>>>>>>>>>>> You, as usual, are not.

The distinction that I make between represent and >>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>> specified by P(P).

A sequence of configurations means a list of x86 >>>>>>>>>>>>>>>>> program steps executed or emulated in the order that >>>>>>>>>>>>>>>>> their source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is given >>>>>>>>>>>>>>>> as its input. It is not given a sequence of state >>>>>>>>>>>>>>>> transitions. It is given a representation of a computation. >>>>>>>>>>>>>>>>

No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>>> sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>> other. Make up your mind.

André

_Infinite_Loop()
[000012c2](01)  55              push ebp >>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>> [000012c8](01)  c3              ret
Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of
tic-tac-toe and there is no possible way to determine that >>>>>>>>>>>>> it does not because the x86 source code of a function has >>>>>>>>>>>>> nothing to do with the sequence of steps of its correct >>>>>>>>>>>>> simulation.

That is not a sequence of configurations. It is a piece of >>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the
following *only* if you (a) interpret it as representing x86 >>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>> appropriate emulator.

Because no one in their right mind would think of doing it
otherwise those ridiculously self-evident facts need not be
stated.

You are the one who constantly makes much ado about nothing
about the fact that Turing Machines can ONLY accept finite
strings as their inputs and object to anyone who suggests that >>>>>>>> something might compute some function which isn't over strings. >>>>>>>>
You don't seem to understand exactly what a finite string is. A >>>>>>>> finite string is simply a sequence of symbols. Given two
strings, you can ask questions like which is longer or whether >>>>>>>> one is a substring or permutation of the other, but not much else. >>>>>>>>
That's because neither strings nor the symbols they are composed >>>>>>>> of have any meaning whatsoever. They are just sequences of
uninterpreted tokens. As soon as you start talking about
'sequences of configurations' or 'numerical values' or anything >>>>>>>> along those lines you are no longer talking about finite
strings, but about the entities which those strings represent to >>>>>>>> a particular TM/program.

Part of designing a TM involves specifying exactly how a string >>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
might seem to you) So yes, they need to be stated.

If it was not for communication context then every single rule >>>>>>>>> of grammar would have to be repeated with every sentence and >>>>>>>>> every definition of every work would have to be repeated over >>>>>>>>> and over.

You keep claiming that the input to the decider is a sequence >>>>>>>>>> of configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what
*you* mean by 'specify'. You gave a bit of wishy-washy verbiage >>>>>>>> a few posts ago, but nothing which made this clear. Repeating it >>>>>>>> over and over again doesn't add any clarity.

The question originally arose when you objected to the claim
that the input to a halt decider represents a computation (or TM >>>>>>>> description/input string pair) and instead insisted that it
specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the
ingredients to a milkshake and because there is a standard
practice for making milkshakes they already know when and how the >>>>>>> x86 source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a representation >>>>>>>> of a computation specifies a sequence of configurations, but
that doesn't explain why you so vehemently objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a
computation. So clearly you mean something else altogether.

André

Because your brain is welded in rebuttal mode you will always act >>>>>>> like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make a
clear sentence because you misuse the English language to hide
your lies.

It is easily provable that the C function H(P,P)==0 is correct on
the basis of the fact correct execution trace of the x86
source-code of input to H(P,P) shows that P would never reach its
"ret" instruction.

Again, I say HOW, since the CORRECT emulation of the input to
H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
Halts, if H is defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below*

No, it isn't, because it LIES.

#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      // push P >>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P >>> [0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

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

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

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

// The emulated H emulates the first seven instructions of P

So, the following is NOT an emulation of the P that the top level H is
emulating, and

Right.

thus NOT part of a CORRECT x86 emulation of the program.

Wrong.

Just like the first invocation of infinite recursion is the root cause
of the infinite recursion the first invocation of infinitely nested x86 emulation is its root cause.

Except you don't understand the definitions.

The second emulation is NOT an emulation by the emulator we are looking
at (At least not if H is how you have defined it), so can't be just
called part of it.

You are basically saying that when a C function H emulates another C
function P and this second C function in

I spent a year of development of the x86utm operating system so that
when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
to an arbitrary recursive depth.

And that is your error. First, this seems to make H no longer a
computation, as its "actual" behavior depends on if it is being emulated
by a copy of H, which is something that H can't actually depend on and
be a computation.

I don't show the 236 pages of the emulation of H because we can simply hypothesize that it merely emulates its input and then verify that this hypothesis is correct on the basis that the emulation of the inputs to
H(P,P) always derive the same execution trace of P.

But then you trace needs to clearly label that, and your analysis needs
to take that into account.

Your rule of "No conditionals in the code of P" just fails when we take
this into account. Once the P is actually a simulated P by a Halt
Decider, EVERY INSTRUCTION becomes a conditional abort point by the
action of that decider.

Your whole argument is premised on that copy of H will never abort, but
we know it would eventually if H is actually a computation, because the
outer one does.

Thus, you whole logic trains is proved both INVALID and UNSOUND.

Part of the issue is you have re-written the definition of Halting (so
it no longer is actually a Halting Definition) to be based on what H can
deduce (when the Halting property of the computation represented by the
inputs to H is NOT dependent on what that instance of H does). The mere
fact that you say H(P,P) == 0 and H1(P,P) == 1 are both correct shows
that what you are calling "Halting" can't be, as it is only a function
of P,P, and not the decider looking at it.

FAIL.

LIES -> False Results.

FAIL

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

UNSOUND LOGIC. This conclusion based on an INCORRECT logicial deduction.

No proof for the rule has been given.

If the execution trace of function H() called by function P() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no conditional branch or indexed jump instructions in P().

FALSE RULE, No such rules exists based on CONDITIONAL simulation (due
to Halt Deciding). You logic is unsound as it assumes that the H that
P calls never aborts its simulation. The rule that this seems to be
based on needs no conditional in the FULL execution path from one
invocation of H to the next, and there are in the "untraced" H.

(4) With no function call returns from H() to P().
then the function call from P() to H() is infinitely recursive.

...[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) = 237 pages

I have pointed out several ERRORS in you "Proof", where you quote
rules that aren't quite correct.

My guess is you are just going to ignore those comment.

Provide reference for the rules AS YOU USE THEM, or you are just shown
to be a LIAR.

You have shown that you just don't understand the basics of the fields
you are talking about, and that includes the epistemology that you
wider argument is based on.

You are shown to have NO knowledge of what Truth actually is, and that
you just don't care about what is actually true, just that you need to
do SOMETHING, no matter how perverse, to try to "prove" your great
idea that can't be true.

YOU FAIL.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 5/28/2022 11:06 AM, Dennis Bush wrote:

On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:

On 5/28/2022 10:23 AM, Dennis Bush wrote:

On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote:

On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>

The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>>

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final >>>>>>>>>>>>>>>>>>>> state.

I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not. >>>>>>>>>>>>>>>>>>>

The distinction that I make between represent and specify >>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas >>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P) >>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not >>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P). >>>>>>>>>>>>>>>>>>
A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>>> source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is given as >>>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions. >>>>>>>>>>>>>>>>> It is given a representation of a computation. >>>>>>>>>>>>>>>>>

No it is not and you know that it is not. A halt decider is >>>>>>>>>>>>>>>> given a finite string TM description that specifies a >>>>>>>>>>>>>>>> sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>>>> entirely different things (and the former certainly does not >>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other. >>>>>>>>>>>>>>> Make up your mind.

André

_Infinite_Loop()
[000012c2](01) 55 push ebp
[000012c3](02) 8bec mov ebp,esp
[000012c5](02) ebfe jmp 000012c5
[000012c7](01) 5d pop ebp
[000012c8](01) c3 ret
Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>>

That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the following >>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions >>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator. >>>>>>>>>>>

Because no one in their right mind would think of doing it >>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated. >>>>>>>>>

You are the one who constantly makes much ado about nothing about >>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>>> their inputs and object to anyone who suggests that something might >>>>>>>>> compute some function which isn't over strings.

You don't seem to understand exactly what a finite string is. A >>>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>>> substring or permutation of the other, but not much else.

That's because neither strings nor the symbols they are composed of >>>>>>>>> have any meaning whatsoever. They are just sequences of
uninterpreted tokens. As soon as you start talking about 'sequences >>>>>>>>> of configurations' or 'numerical values' or anything along those >>>>>>>>> lines you are no longer talking about finite strings, but about the >>>>>>>>> entities which those strings represent to a particular TM/program. >>>>>>>>>
Part of designing a TM involves specifying exactly how a string is >>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might >>>>>>>>> seem to you) So yes, they need to be stated.

If it was not for communication context then every single rule of >>>>>>>>>> grammar would have to be repeated with every sentence and every >>>>>>>>>> definition of every work would have to be repeated over and over. >>>>>>>>>>

You keep claiming that the input to the decider is a sequence of >>>>>>>>>>> configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what *you* >>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few >>>>>>>>> posts ago, but nothing which made this clear. Repeating it over and >>>>>>>>> over again doesn't add any clarity.

The question originally arose when you objected to the claim that >>>>>>>>> the input to a halt decider represents a computation (or TM
description/input string pair) and instead insisted that it
specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the
ingredients to a milkshake and because there is a standard practice >>>>>>>> for making milkshakes they already know when and how the x86
source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a representation of >>>>>>>>> a computation specifies a sequence of configurations, but that >>>>>>>>> doesn't explain why you so vehemently objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a
computation. So clearly you mean something else altogether.

André

Because your brain is welded in rebuttal mode you will always act >>>>>>>> like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>> clear sentence because you misuse the English language to hide your >>>>>>> lies.

It is easily provable that the C function H(P,P)==0 is correct on the >>>>>> basis of the fact correct execution trace of the x86 source-code of >>>>>> input to H(P,P) shows that P would never reach its "ret" instruction. >>>>>

Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as >>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is >>>>> defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below* >>>>
#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 // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

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

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

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

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

Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each of

these lines is multiple instructions of the inner H performing the emulation of them.

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

Here is where H makes its error of aborting too soon. Explanation below: >>>

Several different confusions (see below).

If the execution trace of function H() called by function P() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no conditional branch or indexed jump instructions in P().

This condition is not met.

(1) is proven
(2) is proven // Third column shows TOS value of P's machine address
(3) is proven //

There are branches / jumps in the *program* P contained in the function H that can abort.

We are not looking for jumps, we are looking for code that can change
the behavior of P from one invocation to the next.

And the conditional code of H that checks if its abort criteria is met does *exactly* that.

It is possible that H can change the behavior of P, yet H does not do
that until after its input has already correctly matched an infinite
behavior pattern.

It is easy to verify that H does not change the behavior of P for the
first 14 instructions of P.

The top level H is unable to see that the H called by P will trigger that abort condition if allowed to continue, such as when simulated by a UTM.

(a) conditional branch or
(b) indexed jump instructions (where the index can vary)

The outer H is unable to detect that the inner H will do exactly what the outer H does,

None of this could possibly show that the simulated P ever reaches its
"ret" instruction, thus is irrelevant.

We are not asking:
[A] Does P stop running?

We are by the definition of the problem: does an algorithm exist that can detect if *any* arbitrary algorithm will halt when given a particular input.

No not at all this is false.
A halt decider must only compute the mapping of its input to an accept
or reject state based on the actual behavior specified by this input.

We are asking:
[B] Does the simulated P reach its "ret" instruction?

By this definition, any simulator that aborts and returns non-halting is necessarily correct, such as Ha3(N,5)==0.

The answer is no.

Because the definition of halting means that a computation completed
normally and reached is final instruction H would correctly abort its
simulation of P and return 0.

And since the computation that H(P,P) is deciding on *by definition* is P(P), and the computation P(P) completes, H is incorrect to abort and return 0.

A halt decider must only compute the mapping of its input to an accept
or reject state based on the actual behavior specified by this input.

It is the case that the correct x86 emulation of the input to H(P,P) by
H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
proved to be correct.


--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 5/28/2022 11:35 AM, Richard Damon wrote:

On 5/28/22 12:02 PM, olcott wrote:

On 5/28/2022 10:29 AM, Richard Damon wrote:

On 5/28/22 11:05 AM, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote:

On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>

The input to H is NOT a "sequence of >>>>>>>>>>>>>>>>>>>>> configuratios", but the representation of an >>>>>>>>>>>>>>>>>>>>> algorithm and its input.

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>> final state.

I really don't think you have any idea what terms >>>>>>>>>>>>>>>>>>> like 'represent', 'specify', or 'sequence of >>>>>>>>>>>>>>>>>>> configurations' mean. Richard is perfectly correct. >>>>>>>>>>>>>>>>>>> You, as usual, are not.

The distinction that I make between represent and >>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>>> specified by P(P).

A sequence of configurations means a list of x86 >>>>>>>>>>>>>>>>>> program steps executed or emulated in the order that >>>>>>>>>>>>>>>>>> their source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is >>>>>>>>>>>>>>>>> given as its input. It is not given a sequence of state >>>>>>>>>>>>>>>>> transitions. It is given a representation of a >>>>>>>>>>>>>>>>> computation.

No it is not and you know that it is not. A halt decider >>>>>>>>>>>>>>>> is given a finite string TM description that specifies a >>>>>>>>>>>>>>>> sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>>> other. Make up your mind.

André

_Infinite_Loop()
[000012c2](01)  55              push ebp >>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>>> [000012c8](01)  c3              ret
Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of
tic-tac-toe and there is no possible way to determine that >>>>>>>>>>>>>> it does not because the x86 source code of a function has >>>>>>>>>>>>>> nothing to do with the sequence of steps of its correct >>>>>>>>>>>>>> simulation.

That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the
following *only* if you (a) interpret it as representing x86 >>>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>>> appropriate emulator.

Because no one in their right mind would think of doing it >>>>>>>>>> otherwise those ridiculously self-evident facts need not be >>>>>>>>>> stated.

You are the one who constantly makes much ado about nothing
about the fact that Turing Machines can ONLY accept finite
strings as their inputs and object to anyone who suggests that >>>>>>>>> something might compute some function which isn't over strings. >>>>>>>>>
You don't seem to understand exactly what a finite string is. A >>>>>>>>> finite string is simply a sequence of symbols. Given two
strings, you can ask questions like which is longer or whether >>>>>>>>> one is a substring or permutation of the other, but not much else. >>>>>>>>>
That's because neither strings nor the symbols they are
composed of have any meaning whatsoever. They are just
sequences of uninterpreted tokens. As soon as you start talking >>>>>>>>> about 'sequences of configurations' or 'numerical values' or >>>>>>>>> anything along those lines you are no longer talking about
finite strings, but about the entities which those strings
represent to a particular TM/program.

Part of designing a TM involves specifying exactly how a string >>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it >>>>>>>>> might seem to you) So yes, they need to be stated.

If it was not for communication context then every single rule >>>>>>>>>> of grammar would have to be repeated with every sentence and >>>>>>>>>> every definition of every work would have to be repeated over >>>>>>>>>> and over.

You keep claiming that the input to the decider is a sequence >>>>>>>>>>> of configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what >>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage >>>>>>>>> a few posts ago, but nothing which made this clear. Repeating >>>>>>>>> it over and over again doesn't add any clarity.

The question originally arose when you objected to the claim >>>>>>>>> that the input to a halt decider represents a computation (or >>>>>>>>> TM description/input string pair) and instead insisted that it >>>>>>>>> specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the
ingredients to a milkshake and because there is a standard
practice for making milkshakes they already know when and how
the x86 source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a representation >>>>>>>>> of a computation specifies a sequence of configurations, but >>>>>>>>> that doesn't explain why you so vehemently objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a
computation. So clearly you mean something else altogether.

André

Because your brain is welded in rebuttal mode you will always
act like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>> clear sentence because you misuse the English language to hide
your lies.

It is easily provable that the C function H(P,P)==0 is correct on
the basis of the fact correct execution trace of the x86
source-code of input to H(P,P) shows that P would never reach its
"ret" instruction.

Again, I say HOW, since the CORRECT emulation of the input to
H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
Halts, if H is defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below*

No, it isn't, because it LIES.

#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      // push P >>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P >>>> [0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

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

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

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

// The emulated H emulates the first seven instructions of P

So, the following is NOT an emulation of the P that the top level H
is emulating, and

Right.

thus NOT part of a CORRECT x86 emulation of the program.

Wrong.

Just like the first invocation of infinite recursion is the root cause
of the infinite recursion the first invocation of infinitely nested
x86 emulation is its root cause.

Except you don't understand the definitions.

The second emulation is NOT an emulation by the emulator we are looking
at (At least not if H is how you have defined it), so can't be just
called part of it.

The question is: Would the correct x86 emulation of the input to H(P,P)
ever reach the "ret" instruction of P?

An answer of "no" conclusively proves that H(P,P)==0 is correct.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 5/28/22 12:24 PM, olcott wrote:

On 5/28/2022 11:06 AM, Dennis Bush wrote:

On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:

On 5/28/2022 10:23 AM, Dennis Bush wrote:

On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>

The input to H is NOT a "sequence of configuratios", >>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input. >>>>>>>>>>>>>>>>>>>>>

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>>> final
state.

I really don't think you have any idea what terms like >>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, >>>>>>>>>>>>>>>>>>>> are not.

The distinction that I make between represent and >>>>>>>>>>>>>>>>>>> specify
is that the x86 source-code for P represents P(P) >>>>>>>>>>>>>>>>>>> whereas
the actual correct x86 emulation of the input to H(P,P) >>>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not >>>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P). >>>>>>>>>>>>>>>>>>>
A sequence of configurations means a list of x86 program >>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their >>>>>>>>>>>>>>>>>>> source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is >>>>>>>>>>>>>>>>>> given as
its input. It is not given a sequence of state >>>>>>>>>>>>>>>>>> transitions.
It is given a representation of a computation. >>>>>>>>>>>>>>>>>>

No it is not and you know that it is not. A halt >>>>>>>>>>>>>>>>> decider is
given a finite string TM description that specifies a >>>>>>>>>>>>>>>>> sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>>> not
'specify' the latter). It's given either one or the other. >>>>>>>>>>>>>>>> Make up your mind.

André

_Infinite_Loop()
[000012c2](01) 55 push ebp
[000012c3](02) 8bec mov ebp,esp
[000012c5](02) ebfe jmp 000012c5
[000012c7](01) 5d pop ebp
[000012c8](01) c3 ret
Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of tic-tac-toe >>>>>>>>>>>>>>> and there is no possible way to determine that it does not >>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do >>>>>>>>>>>>>>> with the sequence of steps of its correct simulation. >>>>>>>>>>>>>>

That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the >>>>>>>>>>>> following
*only* if you (a) interpret it as representing x86 instructions >>>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate >>>>>>>>>>>> emulator.

Because no one in their right mind would think of doing it >>>>>>>>>>> otherwise those ridiculously self-evident facts need not be >>>>>>>>>>> stated.

You are the one who constantly makes much ado about nothing about >>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as >>>>>>>>>> their inputs and object to anyone who suggests that something >>>>>>>>>> might
compute some function which isn't over strings.

You don't seem to understand exactly what a finite string is. A >>>>>>>>>> finite string is simply a sequence of symbols. Given two strings, >>>>>>>>>> you can ask questions like which is longer or whether one is a >>>>>>>>>> substring or permutation of the other, but not much else.

That's because neither strings nor the symbols they are
composed of
have any meaning whatsoever. They are just sequences of
uninterpreted tokens. As soon as you start talking about
'sequences
of configurations' or 'numerical values' or anything along those >>>>>>>>>> lines you are no longer talking about finite strings, but
about the
entities which those strings represent to a particular
TM/program.

Part of designing a TM involves specifying exactly how a
string is
to be interpreted (however 'ridiculously self-evident' it might >>>>>>>>>> seem to you) So yes, they need to be stated.

If it was not for communication context then every single >>>>>>>>>>> rule of
grammar would have to be repeated with every sentence and every >>>>>>>>>>> definition of every work would have to be repeated over and >>>>>>>>>>> over.

You keep claiming that the input to the decider is a
sequence of
configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what >>>>>>>>>> *you*
mean by 'specify'. You gave a bit of wishy-washy verbiage a few >>>>>>>>>> posts ago, but nothing which made this clear. Repeating it >>>>>>>>>> over and
over again doesn't add any clarity.

The question originally arose when you objected to the claim that >>>>>>>>>> the input to a halt decider represents a computation (or TM >>>>>>>>>> description/input string pair) and instead insisted that it >>>>>>>>>> specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the >>>>>>>>> ingredients to a milkshake and because there is a standard
practice
for making milkshakes they already know when and how the x86 >>>>>>>>> source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a
representation of
a computation specifies a sequence of configurations, but that >>>>>>>>>> doesn't explain why you so vehemently objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a >>>>>>>>>> computation. So clearly you mean something else altogether. >>>>>>>>>>
André

Because your brain is welded in rebuttal mode you will always act >>>>>>>>> like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make a >>>>>>>> clear sentence because you misuse the English language to hide your >>>>>>>> lies.

It is easily provable that the C function H(P,P)==0 is correct on >>>>>>> the
basis of the fact correct execution trace of the x86 source-code of >>>>>>> input to H(P,P) shows that P would never reach its "ret"
instruction.

Again, I say HOW, since the CORRECT emulation of the input to
H(P,P), as
shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is >>>>>> defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below* >>>>>
#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 // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

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

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H >>>>>
Begin Local Halt Decider Simulation Execution Trace Stored at:212352 >>>>>
// H emulates the first seven instructions of P
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

Starting here is where the trace is incomplete. The emulation of the
instructions of the inner instance of H are not shown. Also the
lines below are not emulated by the top level H. They are emulated
by the inner H called by P. So in between each of these lines is
multiple instructions of the inner H performing the emulation of them. >>>>

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

Here is where H makes its error of aborting too soon. Explanation
below:

Several different confusions (see below).

If the execution trace of function H() called by function P() shows: >>>>> (1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no conditional branch or indexed jump instructions in P().

This condition is not met.

(1) is proven
(2) is proven // Third column shows TOS value of P's machine address
(3) is proven //

There are branches / jumps in the *program* P contained in the
function H that can abort.

We are not looking for jumps, we are looking for code that can change
the behavior of P from one invocation to the next.

And the conditional code of H that checks if its abort criteria is met
does *exactly* that.

It is possible that H can change the behavior of P, yet H does not do
that until after its input has already correctly matched an infinite
behavior pattern.

It is easy to verify that H does not change the behavior of P for the
first 14 instructions of P.

The top level H is unable to see that the H called by P will trigger
that abort condition if allowed to continue, such as when simulated by
a UTM.

(a) conditional branch or
(b) indexed jump instructions (where the index can vary)

The outer H is unable to detect that the inner H will do exactly
what the outer H does,

None of this could possibly show that the simulated P ever reaches its
"ret" instruction, thus is irrelevant.

We are not asking:
[A] Does P stop running?

We are by the definition of the problem:  does an algorithm exist that
can detect if *any* arbitrary algorithm will halt when given a
particular input.

No not at all this is false.
A halt decider must only compute the mapping of its input to an accept
or reject state based on the actual behavior specified by this input.

Word Salad.

A Halt Decider H, given input Wm, the representation of machine M, and w
the input to that machine, needs to compute the Halting property of M
applied to w.

If you want to claim that isn't allowed to be asked, you are DEFINING
the Halting Theorem to be TRUE, as if you are allowed to even ask the
question, you can't have a decider decide it.

Thus, for your "word salad", the "actual behavior speicifed by this
input" means that H(M,w) needs to see as that actual behavior as M(w),
by DEFINITION.

You seem to somehow interprete it as something else, but never actualy
have DEFINED what you mean by that (as is common with most your arguments.

You claim things are true by the meaning of words, but all you show is
that words often don't have precise enough meanings to establish that.

We are asking:
[B] Does the simulated P reach its "ret" instruction?

By this definition, any simulator that aborts and returns non-halting
is necessarily correct, such as Ha3(N,5)==0.

The answer is no.

Because the definition of halting means that a computation completed
normally and reached is final instruction H would correctly abort its
simulation of P and return 0.

And since the computation that H(P,P) is deciding on *by definition*
is P(P), and the computation P(P) completes, H is incorrect to abort
and return 0.

A halt decider must only compute the mapping of its input to an accept
or reject state based on the actual behavior specified by this input.

WORD SALAD

It is the case that the correct x86 emulation of the input to H(P,P) by
H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
proved to be correct.

Nope, the CORRECT x86 emulation of the input th H(P,P) is the emulation
of P(P) which is shown (even by you) to Halt.

Unless you want to actually try to define some other reasonable meaning
for your words, and show that they actually can apply, you are just
spouting falsehoods.

It seems your natural language is the Lie.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 5/28/22 12:49 PM, olcott wrote:

On 5/28/2022 11:35 AM, Richard Damon wrote:

On 5/28/22 12:02 PM, olcott wrote:

On 5/28/2022 10:29 AM, Richard Damon wrote:

On 5/28/22 11:05 AM, olcott wrote:

On 5/28/2022 8:58 AM, Richard Damon wrote:

On 5/28/22 6:26 AM, olcott wrote:

On 5/27/2022 7:33 PM, Richard Damon wrote:

On 5/27/22 7:33 PM, olcott wrote:

On 5/27/2022 6:26 PM, André G. Isaak wrote:

On 2022-05-27 16:42, olcott wrote:

On 5/27/2022 5:26 PM, André G. Isaak wrote:

On 2022-05-27 16:13, olcott wrote:

On 5/27/2022 4:41 PM, André G. Isaak wrote:

On 2022-05-27 15:31, olcott wrote:

On 5/27/2022 4:21 PM, André G. Isaak wrote:

On 2022-05-27 14:38, olcott wrote:

On 5/27/2022 3:06 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:

On 5/27/2022 2:10 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:

On 5/27/2022 1:57 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>

The input to H is NOT a "sequence of >>>>>>>>>>>>>>>>>>>>>> configuratios", but the representation of an >>>>>>>>>>>>>>>>>>>>>> algorithm and its input.

The finite string inputs to a halt decider specify >>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of >>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own >>>>>>>>>>>>>>>>>>>>> final state.

I really don't think you have any idea what terms >>>>>>>>>>>>>>>>>>>> like 'represent', 'specify', or 'sequence of >>>>>>>>>>>>>>>>>>>> configurations' mean. Richard is perfectly correct. >>>>>>>>>>>>>>>>>>>> You, as usual, are not.

The distinction that I make between represent and >>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents >>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the >>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this >>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior >>>>>>>>>>>>>>>>>>> specified by P(P).

A sequence of configurations means a list of x86 >>>>>>>>>>>>>>>>>>> program steps executed or emulated in the order that >>>>>>>>>>>>>>>>>>> their source-code specifies.

Likewise with a TM or the UTM simulation of a TM >>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions. >>>>>>>>>>>>>>>>>>

And this decidedly is *not* what a halt decider is >>>>>>>>>>>>>>>>>> given as its input. It is not given a sequence of >>>>>>>>>>>>>>>>>> state transitions. It is given a representation of a >>>>>>>>>>>>>>>>>> computation.

No it is not and you know that it is not. A halt >>>>>>>>>>>>>>>>> decider is given a finite string TM description that >>>>>>>>>>>>>>>>> specifies a sequence of configurations.

A TM description and a sequence of configurations are >>>>>>>>>>>>>>>> entirely different things (and the former certainly does >>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the >>>>>>>>>>>>>>>> other. Make up your mind.

André

_Infinite_Loop()
[000012c2](01)  55              push ebp >>>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp >>>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5 >>>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp >>>>>>>>>>>>>>> [000012c8](01)  c3              ret >>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of >>>>>>>>>>>>>>> tic-tac-toe and there is no possible way to determine >>>>>>>>>>>>>>> that it does not because the x86 source code of a >>>>>>>>>>>>>>> function has nothing to do with the sequence of steps of >>>>>>>>>>>>>>> its correct simulation.

That is not a sequence of configurations. It is a piece of >>>>>>>>>>>>>> assembly code which represents a subroutine which is an >>>>>>>>>>>>>> infinite loop. The sequence of configurations would look >>>>>>>>>>>>>> something like this:

Yes that code specifies this sequence.

No, it does not. What you have above only generates the >>>>>>>>>>>> following *only* if you (a) interpret it as representing x86 >>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some >>>>>>>>>>>> appropriate emulator.

Because no one in their right mind would think of doing it >>>>>>>>>>> otherwise those ridiculously self-evident facts need not be >>>>>>>>>>> stated.

You are the one who constantly makes much ado about nothing >>>>>>>>>> about the fact that Turing Machines can ONLY accept finite >>>>>>>>>> strings as their inputs and object to anyone who suggests that >>>>>>>>>> something might compute some function which isn't over strings. >>>>>>>>>>
You don't seem to understand exactly what a finite string is. >>>>>>>>>> A finite string is simply a sequence of symbols. Given two >>>>>>>>>> strings, you can ask questions like which is longer or whether >>>>>>>>>> one is a substring or permutation of the other, but not much >>>>>>>>>> else.

That's because neither strings nor the symbols they are
composed of have any meaning whatsoever. They are just
sequences of uninterpreted tokens. As soon as you start
talking about 'sequences of configurations' or 'numerical
values' or anything along those lines you are no longer
talking about finite strings, but about the entities which >>>>>>>>>> those strings represent to a particular TM/program.

Part of designing a TM involves specifying exactly how a
string is to be interpreted (however 'ridiculously
self-evident' it might seem to you) So yes, they need to be >>>>>>>>>> stated.

If it was not for communication context then every single >>>>>>>>>>> rule of grammar would have to be repeated with every sentence >>>>>>>>>>> and every definition of every work would have to be repeated >>>>>>>>>>> over and over.

You keep claiming that the input to the decider is a
sequence of configurations, but that's just plain wrong. >>>>>>>>>>>

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES >>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

But you still haven't provided a coherent definition of what >>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy
verbiage a few posts ago, but nothing which made this clear. >>>>>>>>>> Repeating it over and over again doesn't add any clarity.

The question originally arose when you objected to the claim >>>>>>>>>> that the input to a halt decider represents a computation (or >>>>>>>>>> TM description/input string pair) and instead insisted that it >>>>>>>>>> specifies a sequence of configurations.

Yes of course as everyone knows x86 source-code is one of the >>>>>>>>> ingredients to a milkshake and because there is a standard
practice for making milkshakes they already know when and how >>>>>>>>> the x86 source-code must be applied to make a milkshake.

Now it seems like you are trying to claim that a
representation of a computation specifies a sequence of
configurations, but that doesn't explain why you so vehemently >>>>>>>>>> objected

Your brain is welded in rebuttal mode?

to the claim that the input to a halt decider represents a >>>>>>>>>> computation. So clearly you mean something else altogether. >>>>>>>>>>
André

Because your brain is welded in rebuttal mode you will always >>>>>>>>> act like you never know.

No, YOUR brain is welded in stupid mode. You are unable to make >>>>>>>> a clear sentence because you misuse the English language to hide >>>>>>>> your lies.

It is easily provable that the C function H(P,P)==0 is correct on >>>>>>> the basis of the fact correct execution trace of the x86
source-code of input to H(P,P) shows that P would never reach its >>>>>>> "ret" instruction.

Again, I say HOW, since the CORRECT emulation of the input to
H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
Halts, if H is defined to return 0 from H(P,P).

Richard is one of the two liars.
*The actual behavior of P when correctly emulated by H is shown below* >>>>

No, it isn't, because it LIES.

#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      // push P
[00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P
[0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

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

     machine   stack     stack     machine    assembly >>>>>      address   address   data      code       language >>>>>      ========  ========  ========  =========  =============
...[00001372][0010229e][00000000] 55         push ebp
...[00001373][0010229e][00000000] 8bec       mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P >>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H >>>>>
Begin Local Halt Decider Simulation   Execution Trace Stored at:212352 >>>>>
// H emulates the first seven instructions of P
...[00001352][0021233e][00212342] 55         push ebp      // enter P
...[00001353][0021233e][00212342] 8bec       mov ebp,esp
...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50         push eax      // push P
...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51         push ecx      // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H >>>>>
// The emulated H emulates the first seven instructions of P

So, the following is NOT an emulation of the P that the top level H
is emulating, and

Right.

thus NOT part of a CORRECT x86 emulation of the program.

Wrong.

Just like the first invocation of infinite recursion is the root
cause of the infinite recursion the first invocation of infinitely
nested x86 emulation is its root cause.

Except you don't understand the definitions.

The second emulation is NOT an emulation by the emulator we are
looking at (At least not if H is how you have defined it), so can't be
just called part of it.

The question is: Would the correct x86 emulation of the input to H(P,P)
ever reach the "ret" instruction of P?

An answer of "no" conclusively proves that H(P,P)==0 is correct.

Change in wording again.

Yes, the CORRECT Question is "Would the correct x86 emulation of the
inptu to H(P,P) ever reach the "ret" intstuction of P?"

And the anwer is YES, if H(P,P) aborts its simulation and returns the
value 0.

Thus, the answer H(P,P) == 0 can NOT be correct.


Remember, H is NOT the defintion of the CORRECT simulation. Correct
simulation is what reproduces the exact behavior of the program the
input represents. That is something that does the same as P(P).

Since we are asking what it the corrrect answer if H(P,P) == 0, to see
if it is correct, it is trivial to analyse P(P) to see that it will halt.

We can also emulate it, as you have provided below, and see that a
CORRECT emulation will halt.

The ONLY way this argument fails is if H(P,P) doesn't always return the
same value, but then H fails to meet the requirements to be a decider,
namely that of being an actual computation, so, since it has been
stipulated that H meets the requirements, we don't need to worry about
that case.



On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>

void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{
H_Hat((u32)H_Hat);
}

_H_Hat()
[00000b98](01) 55 push ebp
[00000b99](02) 8bec mov ebp,esp

[00000b9b](01) 51 push ecx

[00000b9c](03) 8b4508 mov eax,[ebp+08]
[00000b9f](01) 50 push eax
[00000ba0](03) 8b4d08 mov ecx,[ebp+08]
[00000ba3](01) 51 push ecx
[00000ba4](05) e88ffdffff call 00000938
[00000ba9](03) 83c408 add esp,+08
[00000bac](03) 8945fc mov [ebp-04],eax
[00000baf](04) 837dfc00 cmp dword [ebp-04],+00
[00000bb3](02) 7402 jz 00000bb7
[00000bb5](02) ebfe jmp 00000bb5
[00000bb7](02) 8be5 mov esp,ebp
[00000bb9](01) 5d pop ebp
[00000bba](01) c3 ret
Size in bytes:(0035) [00000bba]

_main()
[00000bc8](01) 55 push ebp
[00000bc9](02) 8bec mov ebp,esp
[00000bcb](05) 68980b0000 push 00000b98
[00000bd0](05) e8c3ffffff call 00000b98
[00000bd5](03) 83c404 add esp,+04
[00000bd8](02) 33c0 xor eax,eax
[00000bda](01) 5d pop ebp
[00000bdb](01) c3 ret
Size in bytes:(0020) [00000bdb]

===============================
...[00000bc8][001015d4][00000000](01) 55 push ebp ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98 ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98 ...[00000b98][001015c8][001015d4](01) 55 push ebp ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp ...[00000b9b][001015c4][00000000](01) 51 push ecx ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][001015c0][00000b98](01) 50 push eax ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][001015bc][00000b98](01) 51 push ecx ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
Begin Local Halt Decider Simulation at Machine Address:b98 ...[00000b98][00211674][00211678](01) 55 push ebp ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp ...[00000b9b][00211670][00201644](01) 51 push ecx ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0021166c][00000b98](01) 50 push eax ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][00211668][00000b98](01) 51 push ecx ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938 ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp ...[00000b9b][0025c098][0024c06c](01) 51 push ecx ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0025c094][00000b98](01) 50 push eax ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][0025c090][00000b98](01) 51 push ecx ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is processed below:

...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08 ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00 ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7 ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp ...[00000bba][001015d0][00000b98](01) c3 ret ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04 ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax ...[00000bda][001015d8][00100000](01) 5d pop ebp ...[00000bdb][001015dc][00000098](01) c3 ret

SEE IT HALTED!

Number_of_User_Instructions(39)
Number of Instructions Executed(26567)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 5/28/2022 1:10 PM, André G. Isaak wrote:

On 2022-05-28 10:24, olcott wrote:

On 5/28/2022 11:06 AM, Dennis Bush wrote:

And since the computation that H(P,P) is deciding on *by definition*
is P(P), and the computation P(P) completes, H is incorrect to abort
and return 0.

A halt decider must only compute the mapping of its input to an accept
or reject state based on the actual behavior specified by this input.

And what exactly is the above supposed to mean? You still haven't
provided a coherent definition of what you mean by 'specified'. What
does it mean for an input string to specify a behaviour?

André

In other words when I prove what I mean by "specified" 100 times the
fact that you always make sure to ignore what I said is equivalent to me
having never said anything about it.

The behavior specified by an input is the execution trace derived by the correct x86 emulation of this input by its simulating halt decider.

This proves that H(P,P)==0 and H1(P,P)==1.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 5/28/2022 2:21 PM, André G. Isaak wrote:

On 2022-05-28 12:52, olcott wrote:

On 5/28/2022 1:38 PM, André G. Isaak wrote:

On 2022-05-28 12:26, olcott wrote:

On 5/28/2022 1:10 PM, André G. Isaak wrote:

On 2022-05-28 10:24, olcott wrote:

On 5/28/2022 11:06 AM, Dennis Bush wrote:

And since the computation that H(P,P) is deciding on *by
definition* is P(P), and the computation P(P) completes, H is
incorrect to abort and return 0.

A halt decider must only compute the mapping of its input to an
accept or reject state based on the actual behavior specified by
this input.

And what exactly is the above supposed to mean? You still haven't
provided a coherent definition of what you mean by 'specified'.
What does it mean for an input string to specify a behaviour?

André

In other words when I prove what I mean by "specified" 100 times the
fact that you always make sure to ignore what I said is equivalent
to me having never said anything about it.

You can't "prove" what you mean by something. You define what
something is intended to mean. And so far you haven't provided a
definition for 'specify'. When asked you've either hurled insults or
given strange analogies involving milkshakes.

The behavior specified by an input is the execution trace derived by
the correct x86 emulation of this input by its simulating halt decider. >>>

And how exactly do you define 'correct x86 emulation'?

I have told you this many times. Why do you persistently ignore what I
say and then claim that I said nothing?

No, you have not. When asked in the past you've given vaguely worded 'explanations' or unclear examples, but you've never provided anything resembling a definition. A definition would take the form:

A program S correctly emulates an input M, I if and only if ...

*THIS IS THE CORRECT WAY TO ANALYZE IT*
The sequence of instructions that program S emulates is the same
sequence that the x86 machine language input M specifies when it is
being emulated by S.

*THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
The sequence of instructions that program S emulates is the same
sequence that the x86 machine language input M specifies when it is
being emulated by R.




--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 5/28/22 3:27 PM, olcott wrote:

On 5/28/2022 2:21 PM, André G. Isaak wrote:

On 2022-05-28 12:52, olcott wrote:

On 5/28/2022 1:38 PM, André G. Isaak wrote:

On 2022-05-28 12:26, olcott wrote:

On 5/28/2022 1:10 PM, André G. Isaak wrote:

On 2022-05-28 10:24, olcott wrote:

On 5/28/2022 11:06 AM, Dennis Bush wrote:

And since the computation that H(P,P) is deciding on *by
definition* is P(P), and the computation P(P) completes, H is
incorrect to abort and return 0.

A halt decider must only compute the mapping of its input to an
accept or reject state based on the actual behavior specified by >>>>>>> this input.

And what exactly is the above supposed to mean? You still haven't
provided a coherent definition of what you mean by 'specified'.
What does it mean for an input string to specify a behaviour?

André

In other words when I prove what I mean by "specified" 100 times
the fact that you always make sure to ignore what I said is
equivalent to me having never said anything about it.

You can't "prove" what you mean by something. You define what
something is intended to mean. And so far you haven't provided a
definition for 'specify'. When asked you've either hurled insults or
given strange analogies involving milkshakes.

The behavior specified by an input is the execution trace derived
by the correct x86 emulation of this input by its simulating halt
decider.

And how exactly do you define 'correct x86 emulation'?

I have told you this many times. Why do you persistently ignore what
I say and then claim that I said nothing?

No, you have not. When asked in the past you've given vaguely worded
'explanations' or unclear examples, but you've never provided anything
resembling a definition. A definition would take the form:

A program S correctly emulates an input M, I if and only if ...

*THIS IS THE CORRECT WAY TO ANALYZE IT*
The sequence of instructions that program S emulates is the same
sequence that the x86 machine language input M specifies when it is
being emulated by S.

*THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
The sequence of instructions that program S emulates is the same
sequence that the x86 machine language input M specifies when it is
being emulated by R.

So CORRECTNESS is relative to the one doing it?

The ACTUAL correct answer the sequence of instructions that would occur
from a simulator that doesn't stop until the program ends. Yes, this
means that the correct simulation of a non-halting computation is
non-halting and generates an infinite sequence.


So, If S decided to stop after one step, its simulation would still be
correct?

That seems to be what you mean.

That means almost ALL programs can be correctly decided as "Non-Halting"
by a dumb enough.

That definition makes your definition of the halting problem incorrect,
as the Halting behavior of a Compuation is NOT a funciton of the decider
that is deciding it.

Thus you are not working on the halting problem but just your POOP.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)