On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:of these lines is multiple instructions of the inner H performing the emulation of them.
On 5/28/2022 8:58 AM, Richard Damon wrote:
Richard is one of the two liars.
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:You are the one who constantly makes much ado about nothing about >>>>>>> the fact that Turing Machines can ONLY accept finite strings as
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: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.
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. >>>>>>>>>>>>>>>
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. >>>>>>>
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).
*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
// 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:
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.
There are branches / jumps in the *program* P contained in the function H that can abort.
The outer H is unable to detect that the inner H will do exactly what the outer H does,
(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
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:
Richard is one of the two liars.
On 5/28/22 6:26 AM, olcott wrote:
On 5/27/2022 7:33 PM, Richard Damon wrote:Again, I say HOW, since the CORRECT emulation of the input to
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: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. >>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>
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. >>>>
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).
*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
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:You are the one who constantly makes much ado about nothing about >>>>>>> the fact that Turing Machines can ONLY accept finite strings as
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: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. >>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>
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. >>>>>>>
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.
So, the following is NOT an emulation of the P that the top level H is emulating, and
#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
thus NOT part of a CORRECT x86 emulation of the program.
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.
On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:
On 5/28/2022 10:29 AM, Richard Damon wrote:
Right.
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: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.
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: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. >>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>
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 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.
So, the following is NOT an emulation of the P that the top level H is
#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
emulating, and
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.
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:
Right.
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: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.
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. >>>>>>>>>>>>>>>>>>
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.
So, the following is NOT an emulation of the P that the top level H is >>>> emulating, and
#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
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.
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: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. >>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>
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.
So, the following is NOT an emulation of the P that the top level H is
#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
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.
On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:these lines is multiple instructions of the inner H performing the emulation of them.
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:
Richard is one of the two liars.
On 5/28/22 6:26 AM, olcott wrote:
On 5/27/2022 7:33 PM, Richard Damon wrote: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).
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: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.
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: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. >>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>
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 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. >>>>>
*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
Several different confusions (see below).
// 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: >>>
(1) is proven
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.
(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.
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.
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.
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: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.
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. >>>>>>>>>>>>>>>>>
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.
So, the following is NOT an emulation of the P that the top level H
#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
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.
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:Several different confusions (see below).
On 5/28/2022 8:58 AM, Richard Damon wrote:
Richard is one of the two liars.
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:And this decidedly is *not* what a halt decider is >>>>>>>>>>>>>>>>>> given as
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. >>>>>>>>>>>>>>>>>>
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).
*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:
(1) is proven
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.
(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 theWe are not looking for jumps, we are looking for code that can change
function H that can abort.
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 exactlyNone of this could possibly show that the simulated P ever reaches its
what the outer H does,
"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.
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: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.
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. >>>>>>>>>>>>>>>>>>
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 aThe input to a decider
sequence of configurations, but that's just plain wrong. >>>>>>>>>>>
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.
So, the following is NOT an emulation of the P that the top level H
#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
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.
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
[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
...[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
Number_of_User_Instructions(39)
Number of Instructions Executed(26567)
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é
On 2022-05-28 12:52, olcott wrote:*THIS IS THE CORRECT WAY TO ANALYZE IT*
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 byAnd how exactly do you define 'correct x86 emulation'?
the correct x86 emulation of this input by its simulating halt decider. >>>
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 ...
On 5/28/2022 2:21 PM, André G. Isaak wrote:
On 2022-05-28 12:52, olcott wrote:*THIS IS THE CORRECT WAY TO ANALYZE IT*
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 ...
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 366 |
Nodes: | 16 (2 / 14) |
Uptime: | 17:12:45 |
Calls: | 7,812 |
Files: | 12,927 |
Messages: | 5,766,217 |