On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:
> On 5/28/2022 10:29 AM, Richard Damon wrote:
> >
> > On 5/28/22 11:05 AM, olcott wrote:
> >> On 5/28/2022 8:58 AM, Richard Damon wrote:
> >>>
> >>> On 5/28/22 6:26 AM, olcott wrote:
> >>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
> >>>>> On 5/27/22 7:33 PM, olcott wrote:
> >>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
> >>>>>>> On 2022-05-27 16:42, olcott wrote:
> >>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
> >>>>>>>>> On 2022-05-27 16:13, olcott wrote:
> >>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
> >>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
> >>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
> >>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
> >>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
> >>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
> >>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
> >>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
> >>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
> >>>>>>>>>>>>>>>>>> final state.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
> >>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
> >>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are
> >>>>>>>>>>>>>>>>> not.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The distinction that I make between represent and
> >>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
> >>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
> >>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
> >>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
> >>>>>>>>>>>>>>>> specified by P(P).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
> >>>>>>>>>>>>>>>> steps executed or emulated in the order that their
> >>>>>>>>>>>>>>>> source-code specifies.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
> >>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given
> >>>>>>>>>>>>>>> as its input. It is not given a sequence of state
> >>>>>>>>>>>>>>> transitions. It is given a representation of a computation.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
> >>>>>>>>>>>>>> is given a finite string TM description that specifies a
> >>>>>>>>>>>>>> sequence of configurations.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> A TM description and a sequence of configurations are
> >>>>>>>>>>>>> entirely different things (and the former certainly does
> >>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
> >>>>>>>>>>>>> other. Make up your mind.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> André
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>> [000012c2](01) 55 push ebp
> >>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
> >>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
> >>>>>>>>>>>> [000012c7](01) 5d pop ebp
> >>>>>>>>>>>> [000012c8](01) c3 ret
> >>>>>>>>>>>> Size in bytes:(0007) [000012c8]
> >>>>>>>>>>>>
> >>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
> >>>>>>>>>>>> and there is no possible way to determine that it does not
> >>>>>>>>>>>> because the x86 source code of a function has nothing to do
> >>>>>>>>>>>> with the sequence of steps of its correct simulation.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> That is not a sequence of configurations. It is a piece of
> >>>>>>>>>>> assembly code which represents a subroutine which is an
> >>>>>>>>>>> infinite loop. The sequence of configurations would look
> >>>>>>>>>>> something like this:
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Yes that code specifies this sequence.
> >>>>>>>>>
> >>>>>>>>> No, it does not. What you have above only generates the
> >>>>>>>>> following *only* if you (a) interpret it as representing x86
> >>>>>>>>> instructions and (b) actually execute it on an x86 or some
> >>>>>>>>> appropriate emulator.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Because no one in their right mind would think of doing it
> >>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
> >>>>>>>
> >>>>>>> You are the one who constantly makes much ado about nothing about
> >>>>>>> the fact that Turing Machines can ONLY accept finite strings as
> >>>>>>> their inputs and object to anyone who suggests that something
> >>>>>>> might compute some function which isn't over strings.
> >>>>>>>
> >>>>>>> You don't seem to understand exactly what a finite string is. A
> >>>>>>> finite string is simply a sequence of symbols. Given two strings,
> >>>>>>> you can ask questions like which is longer or whether one is a
> >>>>>>> substring or permutation of the other, but not much else.
> >>>>>>>
> >>>>>>> That's because neither strings nor the symbols they are composed
> >>>>>>> of have any meaning whatsoever. They are just sequences of
> >>>>>>> uninterpreted tokens. As soon as you start talking about
> >>>>>>> 'sequences of configurations' or 'numerical values' or anything
> >>>>>>> along those lines you are no longer talking about finite strings,
> >>>>>>> but about the entities which those strings represent to a
> >>>>>>> particular TM/program.
> >>>>>>>
> >>>>>>> Part of designing a TM involves specifying exactly how a string
> >>>>>>> is to be interpreted (however 'ridiculously self-evident' it
> >>>>>>> might seem to you) So yes, they need to be stated.
> >>>>>>>
> >>>>>>>
> >>>>>>>> If it was not for communication context then every single rule
> >>>>>>>> of grammar would have to be repeated with every sentence and
> >>>>>>>> every definition of every work would have to be repeated over
> >>>>>>>> and over.
> >>>>>>>>
> >>>>>>>>> You keep claiming that the input to the decider is a sequence
> >>>>>>>>> of configurations, but that's just plain wrong.
> >>>>>>>>
> >>>>>>>> The input to a decider
> >>>>>>>>
> >>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>> A sequence of configirations
> >>>>>>>>
> >>>>>>>> Did you notice that I said SPECFIES this time ???
> >>>>>>>
> >>>>>>> But you still haven't provided a coherent definition of what
> >>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a
> >>>>>>> few posts ago, but nothing which made this clear. Repeating it
> >>>>>>> over and over again doesn't add any clarity.
> >>>>>>
> >>>>>>> The question originally arose when you objected to the claim that
> >>>>>>> the input to a halt decider represents a computation (or TM
> >>>>>>> description/input string pair) and instead insisted that it
> >>>>>>> specifies a sequence of configurations.
> >>>>>>>
> >>>>>>
> >>>>>> Yes of course as everyone knows x86 source-code is one of the
> >>>>>> ingredients to a milkshake and because there is a standard
> >>>>>> practice for making milkshakes they already know when and how the
> >>>>>> x86 source-code must be applied to make a milkshake.
> >>>>>>
> >>>>>>> Now it seems like you are trying to claim that a representation
> >>>>>>> of a computation specifies a sequence of configurations, but that
> >>>>>>> doesn't explain why you so vehemently objected
> >>>>>>
> >>>>>> Your brain is welded in rebuttal mode?
> >>>>>>
> >>>>>>> to the claim that the input to a halt decider represents a
> >>>>>>> computation. So clearly you mean something else altogether.
> >>>>>>>
> >>>>>>> André
> >>>>>>>
> >>>>>>
> >>>>>> Because your brain is welded in rebuttal mode you will always act
> >>>>>> like you never know.
> >>>>>>
> >>>>>
> >>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
> >>>>> clear sentence because you misuse the English language to hide your
> >>>>> lies.
> >>>>
> >>>> It is easily provable that the C function H(P,P)==0 is correct on
> >>>> the basis of the fact correct execution trace of the x86 source-code
> >>>> of input to H(P,P) shows that P would never reach its "ret"
> >>>> instruction.
> >>>
> >>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P),
> >>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H
> >>> is defined to return 0 from H(P,P).
> >>
> >> Richard is one of the two liars.
> >> *The actual behavior of P when correctly emulated by H is shown below*
> >
> >
> > No, it isn't, because it LIES.
> >>
> >> #include <stdint.h>
> >> #define u32 uint32_t
> >>
> >> void P(u32 x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H((u32)P, (u32)P));
> >> }
> >>
> >> _P()
> >> [00001352](01) 55 push ebp
> >> [00001353](02) 8bec mov ebp,esp
> >> [00001355](03) 8b4508 mov eax,[ebp+08]
> >> [00001358](01) 50 push eax // push P
> >> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >> [0000135c](01) 51 push ecx // push P
> >> [0000135d](05) e840feffff call 000011a2 // call H
> >> [00001362](03) 83c408 add esp,+08
> >> [00001365](02) 85c0 test eax,eax
> >> [00001367](02) 7402 jz 0000136b
> >> [00001369](02) ebfe jmp 00001369
> >> [0000136b](01) 5d pop ebp
> >> [0000136c](01) c3 ret
> >> Size in bytes:(0027) [0000136c]
> >>
> >> _main()
> >> [00001372](01) 55 push ebp
> >> [00001373](02) 8bec mov ebp,esp
> >> [00001375](05) 6852130000 push 00001352 // push P
> >> [0000137a](05) 6852130000 push 00001352 // push P
> >> [0000137f](05) e81efeffff call 000011a2 // call H
> >> [00001384](03) 83c408 add esp,+08
> >> [00001387](01) 50 push eax
> >> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
> >> [0000138d](05) e8e0f0ffff call 00000472 // call Output
> >> [00001392](03) 83c408 add esp,+08
> >> [00001395](02) 33c0 xor eax,eax
> >> [00001397](01) 5d pop ebp
> >> [00001398](01) c3 ret
> >> Size in bytes:(0039) [00001398]
> >>
> >> machine stack stack machine assembly
> >> address address data code language
> >> ======== ======== ======== ========= =============
> >> ...[00001372][0010229e][00000000] 55 push ebp
> >> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
> >> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> >> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> >> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
> >>
> >> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
> >>
> >> // H emulates the first seven instructions of P
> >> ...[00001352][0021233e][00212342] 55 push ebp // enter P
> >> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
> >> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
> >> ...[00001358][0021233a][00001352] 50 push eax // push P
> >> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
> >> ...[0000135c][00212336][00001352] 51 push ecx // push P
> >> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
> >>
> >> // The emulated H emulates the first seven instructions of P
> > So, the following is NOT an emulation of the P that the top level H is
> > emulating, and
> Right.
> > thus NOT part of a CORRECT x86 emulation of the program.
> Wrong.
>
> Just like the first invocation of infinite recursion is the root cause
> of the infinite recursion the first invocation of infinitely nested x86
> emulation is its root cause.
>
>
> You are basically saying that when a C function H emulates another C
> function P and this second C function in
>
> I spent a year of development of the x86utm operating system so that
> when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could
> correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
> to an arbitrary recursive depth.
>
> I don't show the 236 pages of the emulation of H because we can simply
> hypothesize that it merely emulates its input

On 5/28/2022 11:06 AM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:
>> On 5/28/2022 10:23 AM, Dennis Bush wrote:
>>> On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>
>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final
>>>>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The distinction that I make between represent and specify
>>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas
>>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not
>>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
>>>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions.
>>>>>>>>>>>>>>>>> It is given a representation of a computation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>>>>>>>>>> given a finite string TM description that specifies a
>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>> entirely different things (and the former certainly does not
>>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other.
>>>>>>>>>>>>>>> Make up your mind.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>> [000012c2](01) 55 push ebp
>>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
>>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
>>>>>>>>>>>>>> [000012c8](01) c3 ret
>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>
>>>>>>>>>>> No, it does not. What you have above only generates the following
>>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions
>>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
>>>>>>>>>
>>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>>> their inputs and object to anyone who suggests that something might
>>>>>>>>> compute some function which isn't over strings.
>>>>>>>>>
>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>>
>>>>>>>>> That's because neither strings nor the symbols they are composed of
>>>>>>>>> have any meaning whatsoever. They are just sequences of
>>>>>>>>> uninterpreted tokens. As soon as you start talking about 'sequences
>>>>>>>>> of configurations' or 'numerical values' or anything along those
>>>>>>>>> lines you are no longer talking about finite strings, but about the
>>>>>>>>> entities which those strings represent to a particular TM/program.
>>>>>>>>>
>>>>>>>>> Part of designing a TM involves specifying exactly how a string is
>>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might
>>>>>>>>> seem to you) So yes, they need to be stated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If it was not for communication context then every single rule of
>>>>>>>>>> grammar would have to be repeated with every sentence and every
>>>>>>>>>> definition of every work would have to be repeated over and over.
>>>>>>>>>>
>>>>>>>>>>> You keep claiming that the input to the decider is a sequence of
>>>>>>>>>>> configurations, but that's just plain wrong.
>>>>>>>>>>
>>>>>>>>>> The input to a decider
>>>>>>>>>>
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> A sequence of configirations
>>>>>>>>>>
>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>
>>>>>>>>> But you still haven't provided a coherent definition of what *you*
>>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
>>>>>>>>> posts ago, but nothing which made this clear. Repeating it over and
>>>>>>>>> over again doesn't add any clarity.
>>>>>>>>
>>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>> ingredients to a milkshake and because there is a standard practice
>>>>>>>> for making milkshakes they already know when and how the x86
>>>>>>>> source-code must be applied to make a milkshake.
>>>>>>>>
>>>>>>>>> Now it seems like you are trying to claim that a representation of
>>>>>>>>> a computation specifies a sequence of configurations, but that
>>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>>
>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>
>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>>> like you never know.
>>>>>>>>
>>>>>>>
>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>> clear sentence because you misuse the English language to hide your
>>>>>>> lies.
>>>>>>
>>>>>> It is easily provable that the C function H(P,P)==0 is correct on the
>>>>>> basis of the fact correct execution trace of the x86 source-code of
>>>>>> input to H(P,P) shows that P would never reach its "ret" instruction.
>>>>>
>>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as
>>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
>>>>> defined to return 0 from H(P,P).
>>>> Richard is one of the two liars.
>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001352](01) 55 push ebp
>>>> [00001353](02) 8bec mov ebp,esp
>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>> [00001358](01) 50 push eax // push P
>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000135c](01) 51 push ecx // push P
>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>> [00001362](03) 83c408 add esp,+08
>>>> [00001365](02) 85c0 test eax,eax
>>>> [00001367](02) 7402 jz 0000136b
>>>> [00001369](02) ebfe jmp 00001369
>>>> [0000136b](01) 5d pop ebp
>>>> [0000136c](01) c3 ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> _main()
>>>> [00001372](01) 55 push ebp
>>>> [00001373](02) 8bec mov ebp,esp
>>>> [00001375](05) 6852130000 push 00001352 // push P
>>>> [0000137a](05) 6852130000 push 00001352 // push P
>>>> [0000137f](05) e81efeffff call 000011a2 // call H
>>>> [00001384](03) 83c408 add esp,+08
>>>> [00001387](01) 50 push eax
>>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
>>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
>>>> [00001392](03) 83c408 add esp,+08
>>>> [00001395](02) 33c0 xor eax,eax
>>>> [00001397](01) 5d pop ebp
>>>> [00001398](01) c3 ret
>>>> Size in bytes:(0039) [00001398]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> ...[00001372][0010229e][00000000] 55 push ebp
>>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>>>
>>>> // H emulates the first seven instructions of P
>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>>>> ...[00001358][0021233a][00001352] 50 push eax // push P
>>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>
>>> Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each of these lines is multiple instructions of the inner H performing the emulation of them.
>>>
>>>>
>>>> // The emulated H emulates the first seven instructions of P
>>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>>>> ...[00001358][0025cd62][00001352] 50 push eax // push P
>>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> Here is where H makes its error of aborting too soon. Explanation below:
>>>
>> Several different confusions (see below).
>>>>
>>>> If the execution trace of function H() called by function P() shows:
>>>> (1) Function H() is called twice in sequence from the same machine
>>>> address of P().
>>>> (2) With the same parameters to H().
>>>> (3) With no conditional branch or indexed jump instructions in P().
>>>
>>> This condition is not met.
>> (1) is proven
>> (2) is proven // Third column shows TOS value of P's machine address
>> (3) is proven //
>>> There are branches / jumps in the *program* P contained in the function H that can abort.
>> We are not looking for jumps, we are looking for code that can change
>> the behavior of P from one invocation to the next.
>
> And the conditional code of H that checks if its abort criteria is met does *exactly* that.

On Saturday, 28 May 2022 at 13:18:28 UTC+1, Andy Walker wrote:
> On 28/05/2022 11:46, Mikko wrote:
> > On 2022-05-28 08:41:42 +0000, Malcolm McLean said:
> [... various restrictions ...]
> >> Now, unless I've nodded, I ought to be able to produce a very simple Turing
> >> machine which solves the halting problem for this domain.
> > You must also exclude directly and indirectly recursive functions.
> > In addition, the loop variable of a for loop must not be modified
> > in the loop and its address must not be given to a function that
> > does not promise to regard it as an address to a constant.
> What the pair of you are saying is, in effect, that there is a
> significant subset of programs which are guaranteed to halt, and for
> which the HP is therefore trivial. Such programs even include many of
> practical [eg engineering] interest. This is true, and uncontroversial.
> There are also significant subsets of programs which are guaranteed not
> to halt [at least in normal circumstances and short of hardware failure
> or intervention]. But, no matter how you slice and dice, there is also
> a substantial subset of programs whose behaviour cannot be determined
> by an algorithmic examination of the code [inc input]; and the attack
> on the HP via emulation and Busy Beavers shows clearly that a lot of
> /very/ simple programs, and indeed problems, fall into this category.
> [Not least because a UTM is a very simple program, and any complexity
> relates to its input, which /could/ be a representation of a UTM and
> /its/ input, which could be ....]
>
> As ever, although the HP is expressed in terms of halting, it
> equally applies to problems such as "Does my program ever reach line
> 23?", or "Does it ever produce any output?" or "Does it produce the
> same output as your program?", which may be of more practical interest.
> Yes, in line with what Malcolm is proposing, it's possible to produce
> analysers, perhaps even of commercial interest, which often say useful
> things about some code; but there are always areas of doubt, and
> every time you explore one of these another can of worms opens up.
>
> A partial answer for practical programming lies in disciplined
> code, with carefully designed pre- and post-conditions, etc., etc. But
> that doesn't help with programs written without that discipline, and it
> doesn't help to solve the Goldbach Conjecture.
>
PO seemed to be going down the route of saying that some programs
are not in the domain of his halt decider. Whilst that prompted ridicule,
it's not actually an inherently bad approach, depending what you want
to achieve.

On 5/28/2022 11:11 AM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:
>> On 5/28/2022 10:29 AM, Richard Damon wrote:
>>>
>>> On 5/28/22 11:05 AM, olcott wrote:
>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>
>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are
>>>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given
>>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state
>>>>>>>>>>>>>>>>> transitions. It is given a representation of a computation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
>>>>>>>>>>>>>>>> is given a finite string TM description that specifies a
>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>> [000012c2](01) 55 push ebp
>>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
>>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
>>>>>>>>>>>>>> [000012c8](01) c3 ret
>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>
>>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>>>> appropriate emulator.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
>>>>>>>>>
>>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>>> their inputs and object to anyone who suggests that something
>>>>>>>>> might compute some function which isn't over strings.
>>>>>>>>>
>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>>
>>>>>>>>> That's because neither strings nor the symbols they are composed
>>>>>>>>> of have any meaning whatsoever. They are just sequences of
>>>>>>>>> uninterpreted tokens. As soon as you start talking about
>>>>>>>>> 'sequences of configurations' or 'numerical values' or anything
>>>>>>>>> along those lines you are no longer talking about finite strings,
>>>>>>>>> but about the entities which those strings represent to a
>>>>>>>>> particular TM/program.
>>>>>>>>>
>>>>>>>>> Part of designing a TM involves specifying exactly how a string
>>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
>>>>>>>>> might seem to you) So yes, they need to be stated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If it was not for communication context then every single rule
>>>>>>>>>> of grammar would have to be repeated with every sentence and
>>>>>>>>>> every definition of every work would have to be repeated over
>>>>>>>>>> and over.
>>>>>>>>>>
>>>>>>>>>>> You keep claiming that the input to the decider is a sequence
>>>>>>>>>>> of configurations, but that's just plain wrong.
>>>>>>>>>>
>>>>>>>>>> The input to a decider
>>>>>>>>>>
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> A sequence of configirations
>>>>>>>>>>
>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>
>>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a
>>>>>>>>> few posts ago, but nothing which made this clear. Repeating it
>>>>>>>>> over and over again doesn't add any clarity.
>>>>>>>>
>>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>>> practice for making milkshakes they already know when and how the
>>>>>>>> x86 source-code must be applied to make a milkshake.
>>>>>>>>
>>>>>>>>> Now it seems like you are trying to claim that a representation
>>>>>>>>> of a computation specifies a sequence of configurations, but that
>>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>>
>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>
>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>>> like you never know.
>>>>>>>>
>>>>>>>
>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>> clear sentence because you misuse the English language to hide your
>>>>>>> lies.
>>>>>>
>>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>>> the basis of the fact correct execution trace of the x86 source-code
>>>>>> of input to H(P,P) shows that P would never reach its "ret"
>>>>>> instruction.
>>>>>
>>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P),
>>>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H
>>>>> is defined to return 0 from H(P,P).
>>>>
>>>> Richard is one of the two liars.
>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>
>>>
>>> No, it isn't, because it LIES.
>>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001352](01) 55 push ebp
>>>> [00001353](02) 8bec mov ebp,esp
>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>> [00001358](01) 50 push eax // push P
>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000135c](01) 51 push ecx // push P
>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>> [00001362](03) 83c408 add esp,+08
>>>> [00001365](02) 85c0 test eax,eax
>>>> [00001367](02) 7402 jz 0000136b
>>>> [00001369](02) ebfe jmp 00001369
>>>> [0000136b](01) 5d pop ebp
>>>> [0000136c](01) c3 ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> _main()
>>>> [00001372](01) 55 push ebp
>>>> [00001373](02) 8bec mov ebp,esp
>>>> [00001375](05) 6852130000 push 00001352 // push P
>>>> [0000137a](05) 6852130000 push 00001352 // push P
>>>> [0000137f](05) e81efeffff call 000011a2 // call H
>>>> [00001384](03) 83c408 add esp,+08
>>>> [00001387](01) 50 push eax
>>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
>>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
>>>> [00001392](03) 83c408 add esp,+08
>>>> [00001395](02) 33c0 xor eax,eax
>>>> [00001397](01) 5d pop ebp
>>>> [00001398](01) c3 ret
>>>> Size in bytes:(0039) [00001398]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> ...[00001372][0010229e][00000000] 55 push ebp
>>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>>>
>>>> // H emulates the first seven instructions of P
>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>>>> ...[00001358][0021233a][00001352] 50 push eax // push P
>>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>
>>>> // The emulated H emulates the first seven instructions of P
>>> So, the following is NOT an emulation of the P that the top level H is
>>> emulating, and
>> Right.
>>> thus NOT part of a CORRECT x86 emulation of the program.
>> Wrong.
>>
>> Just like the first invocation of infinite recursion is the root cause
>> of the infinite recursion the first invocation of infinitely nested x86
>> emulation is its root cause.
>>
>>
>> You are basically saying that when a C function H emulates another C
>> function P and this second C function in
>>
>> I spent a year of development of the x86utm operating system so that
>> when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could
>> correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
>> to an arbitrary recursive depth.
>>
>> I don't show the 236 pages of the emulation of H because we can simply
>> hypothesize that it merely emulates its input
>
> Deceptive use of "H" to refer to multiple unrelated computations.
>
> The fixed algorithm of H, hereafter referred to as Ha, and the P that calls it referred to as Pa, does abort and does not "merely emulate". Hn is what does that. And since Pa doesn't call Hn that means we are no longer deciding on Pa but on Pn.
>
> So your argument boils down to: Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.
>

On 5/28/2022 11:25 AM, Malcolm McLean wrote:
> On Saturday, 28 May 2022 at 13:18:28 UTC+1, Andy Walker wrote:
>> On 28/05/2022 11:46, Mikko wrote:
>>> On 2022-05-28 08:41:42 +0000, Malcolm McLean said:
>> [... various restrictions ...]
>>>> Now, unless I've nodded, I ought to be able to produce a very simple Turing
>>>> machine which solves the halting problem for this domain.
>>> You must also exclude directly and indirectly recursive functions.
>>> In addition, the loop variable of a for loop must not be modified
>>> in the loop and its address must not be given to a function that
>>> does not promise to regard it as an address to a constant.
>> What the pair of you are saying is, in effect, that there is a
>> significant subset of programs which are guaranteed to halt, and for
>> which the HP is therefore trivial. Such programs even include many of
>> practical [eg engineering] interest. This is true, and uncontroversial.
>> There are also significant subsets of programs which are guaranteed not
>> to halt [at least in normal circumstances and short of hardware failure
>> or intervention]. But, no matter how you slice and dice, there is also
>> a substantial subset of programs whose behaviour cannot be determined
>> by an algorithmic examination of the code [inc input]; and the attack
>> on the HP via emulation and Busy Beavers shows clearly that a lot of
>> /very/ simple programs, and indeed problems, fall into this category.
>> [Not least because a UTM is a very simple program, and any complexity
>> relates to its input, which /could/ be a representation of a UTM and
>> /its/ input, which could be ....]
>>
>> As ever, although the HP is expressed in terms of halting, it
>> equally applies to problems such as "Does my program ever reach line
>> 23?", or "Does it ever produce any output?" or "Does it produce the
>> same output as your program?", which may be of more practical interest.
>> Yes, in line with what Malcolm is proposing, it's possible to produce
>> analysers, perhaps even of commercial interest, which often say useful
>> things about some code; but there are always areas of doubt, and
>> every time you explore one of these another can of worms opens up.
>>
>> A partial answer for practical programming lies in disciplined
>> code, with carefully designed pre- and post-conditions, etc., etc. But
>> that doesn't help with programs written without that discipline, and it
>> doesn't help to solve the Goldbach Conjecture.
>>
> PO seemed to be going down the route of saying that some programs
> are not in the domain of his halt decider. Whilst that prompted ridicule,
> it's not actually an inherently bad approach, depending what you want
> to achieve.

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.

NON-INPUTS DO NOT COUNT
NON-INPUTS DO NOT COUNT
NON-INPUTS DO NOT COUNT

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

--
Copyright 2022 Pete Olcott

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

On Saturday, May 28, 2022 at 12:25:05 PM UTC-4, olcott wrote:
> On 5/28/2022 11:06 AM, Dennis Bush wrote:
> > On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:
> >> On 5/28/2022 10:23 AM, Dennis Bush wrote:
> >>> On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
> >>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
> >>>>>
> >>>>> On 5/28/22 6:26 AM, olcott wrote:
> >>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
> >>>>>>> On 5/27/22 7:33 PM, olcott wrote:
> >>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
> >>>>>>>>> On 2022-05-27 16:42, olcott wrote:
> >>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
> >>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
> >>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
> >>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
> >>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
> >>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
> >>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
> >>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
> >>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final
> >>>>>>>>>>>>>>>>>>>> state.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
> >>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
> >>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The distinction that I make between represent and specify
> >>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas
> >>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P)
> >>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not
> >>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
> >>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
> >>>>>>>>>>>>>>>>>> source-code specifies.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
> >>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
> >>>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions.
> >>>>>>>>>>>>>>>>> It is given a representation of a computation.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider is
> >>>>>>>>>>>>>>>> given a finite string TM description that specifies a
> >>>>>>>>>>>>>>>> sequence of configurations.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> A TM description and a sequence of configurations are
> >>>>>>>>>>>>>>> entirely different things (and the former certainly does not
> >>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other..
> >>>>>>>>>>>>>>> Make up your mind.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> André
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>> [000012c2](01) 55 push ebp
> >>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
> >>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
> >>>>>>>>>>>>>> [000012c8](01) c3 ret
> >>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
> >>>>>>>>>>>>>> and there is no possible way to determine that it does not
> >>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
> >>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
> >>>>>>>>>>>>> assembly code which represents a subroutine which is an
> >>>>>>>>>>>>> infinite loop. The sequence of configurations would look
> >>>>>>>>>>>>> something like this:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes that code specifies this sequence.
> >>>>>>>>>>>
> >>>>>>>>>>> No, it does not. What you have above only generates the following
> >>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions
> >>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Because no one in their right mind would think of doing it
> >>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
> >>>>>>>>>
> >>>>>>>>> You are the one who constantly makes much ado about nothing about
> >>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
> >>>>>>>>> their inputs and object to anyone who suggests that something might
> >>>>>>>>> compute some function which isn't over strings.
> >>>>>>>>>
> >>>>>>>>> You don't seem to understand exactly what a finite string is. A
> >>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
> >>>>>>>>> you can ask questions like which is longer or whether one is a
> >>>>>>>>> substring or permutation of the other, but not much else.
> >>>>>>>>>
> >>>>>>>>> That's because neither strings nor the symbols they are composed of
> >>>>>>>>> have any meaning whatsoever. They are just sequences of
> >>>>>>>>> uninterpreted tokens. As soon as you start talking about 'sequences
> >>>>>>>>> of configurations' or 'numerical values' or anything along those
> >>>>>>>>> lines you are no longer talking about finite strings, but about the
> >>>>>>>>> entities which those strings represent to a particular TM/program.
> >>>>>>>>>
> >>>>>>>>> Part of designing a TM involves specifying exactly how a string is
> >>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might
> >>>>>>>>> seem to you) So yes, they need to be stated.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> If it was not for communication context then every single rule of
> >>>>>>>>>> grammar would have to be repeated with every sentence and every
> >>>>>>>>>> definition of every work would have to be repeated over and over.
> >>>>>>>>>>
> >>>>>>>>>>> You keep claiming that the input to the decider is a sequence of
> >>>>>>>>>>> configurations, but that's just plain wrong.
> >>>>>>>>>>
> >>>>>>>>>> The input to a decider
> >>>>>>>>>>
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> A sequence of configirations
> >>>>>>>>>>
> >>>>>>>>>> Did you notice that I said SPECFIES this time ???
> >>>>>>>>>
> >>>>>>>>> But you still haven't provided a coherent definition of what *you*
> >>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
> >>>>>>>>> posts ago, but nothing which made this clear. Repeating it over and
> >>>>>>>>> over again doesn't add any clarity.
> >>>>>>>>
> >>>>>>>>> The question originally arose when you objected to the claim that
> >>>>>>>>> the input to a halt decider represents a computation (or TM
> >>>>>>>>> description/input string pair) and instead insisted that it
> >>>>>>>>> specifies a sequence of configurations.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Yes of course as everyone knows x86 source-code is one of the
> >>>>>>>> ingredients to a milkshake and because there is a standard practice
> >>>>>>>> for making milkshakes they already know when and how the x86
> >>>>>>>> source-code must be applied to make a milkshake.
> >>>>>>>>
> >>>>>>>>> Now it seems like you are trying to claim that a representation of
> >>>>>>>>> a computation specifies a sequence of configurations, but that
> >>>>>>>>> doesn't explain why you so vehemently objected
> >>>>>>>>
> >>>>>>>> Your brain is welded in rebuttal mode?
> >>>>>>>>
> >>>>>>>>> to the claim that the input to a halt decider represents a
> >>>>>>>>> computation. So clearly you mean something else altogether.
> >>>>>>>>>
> >>>>>>>>> André
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Because your brain is welded in rebuttal mode you will always act
> >>>>>>>> like you never know.
> >>>>>>>>
> >>>>>>>
> >>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
> >>>>>>> clear sentence because you misuse the English language to hide your
> >>>>>>> lies.
> >>>>>>
> >>>>>> It is easily provable that the C function H(P,P)==0 is correct on the
> >>>>>> basis of the fact correct execution trace of the x86 source-code of
> >>>>>> input to H(P,P) shows that P would never reach its "ret" instruction.
> >>>>>
> >>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as
> >>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
> >>>>> defined to return 0 from H(P,P).
> >>>> Richard is one of the two liars.
> >>>> *The actual behavior of P when correctly emulated by H is shown below*
> >>>>
> >>>> #include <stdint.h>
> >>>> #define u32 uint32_t
> >>>>
> >>>> void P(u32 x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>> }
> >>>>
> >>>> _P()
> >>>> [00001352](01) 55 push ebp
> >>>> [00001353](02) 8bec mov ebp,esp
> >>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>> [00001358](01) 50 push eax // push P
> >>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [0000135c](01) 51 push ecx // push P
> >>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>> [00001362](03) 83c408 add esp,+08
> >>>> [00001365](02) 85c0 test eax,eax
> >>>> [00001367](02) 7402 jz 0000136b
> >>>> [00001369](02) ebfe jmp 00001369
> >>>> [0000136b](01) 5d pop ebp
> >>>> [0000136c](01) c3 ret
> >>>> Size in bytes:(0027) [0000136c]
> >>>>
> >>>> _main()
> >>>> [00001372](01) 55 push ebp
> >>>> [00001373](02) 8bec mov ebp,esp
> >>>> [00001375](05) 6852130000 push 00001352 // push P
> >>>> [0000137a](05) 6852130000 push 00001352 // push P
> >>>> [0000137f](05) e81efeffff call 000011a2 // call H
> >>>> [00001384](03) 83c408 add esp,+08
> >>>> [00001387](01) 50 push eax
> >>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
> >>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
> >>>> [00001392](03) 83c408 add esp,+08
> >>>> [00001395](02) 33c0 xor eax,eax
> >>>> [00001397](01) 5d pop ebp
> >>>> [00001398](01) c3 ret
> >>>> Size in bytes:(0039) [00001398]
> >>>>
> >>>> machine stack stack machine assembly
> >>>> address address data code language
> >>>> ======== ======== ======== ========= =============
> >>>> ...[00001372][0010229e][00000000] 55 push ebp
> >>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
> >>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> >>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> >>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
> >>>>
> >>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
> >>>>
> >>>> // H emulates the first seven instructions of P
> >>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
> >>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
> >>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
> >>>> ...[00001358][0021233a][00001352] 50 push eax // push P
> >>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
> >>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
> >>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
> >>>
> >>> Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each of these lines is multiple instructions of the inner H performing the emulation of them.
> >>>
> >>>>
> >>>> // The emulated H emulates the first seven instructions of P
> >>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
> >>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> >>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> >>>> ...[00001358][0025cd62][00001352] 50 push eax // push P
> >>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> >>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
> >>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> >>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >>>
> >>> Here is where H makes its error of aborting too soon. Explanation below:
> >>>
> >> Several different confusions (see below).
> >>>>
> >>>> If the execution trace of function H() called by function P() shows:
> >>>> (1) Function H() is called twice in sequence from the same machine
> >>>> address of P().
> >>>> (2) With the same parameters to H().
> >>>> (3) With no conditional branch or indexed jump instructions in P().
> >>>
> >>> This condition is not met.
> >> (1) is proven
> >> (2) is proven // Third column shows TOS value of P's machine address
> >> (3) is proven //
> >>> There are branches / jumps in the *program* P contained in the function H that can abort.
> >> We are not looking for jumps, we are looking for code that can change
> >> the behavior of P from one invocation to the next.
> >
> > And the conditional code of H that checks if its abort criteria is met does *exactly* that.
> It is possible that H can change the behavior of P,
>

On Saturday, May 28, 2022 at 12:31:41 PM UTC-4, olcott wrote:
> On 5/28/2022 11:25 AM, Malcolm McLean wrote:
> > On Saturday, 28 May 2022 at 13:18:28 UTC+1, Andy Walker wrote:
> >> On 28/05/2022 11:46, Mikko wrote:
> >>> On 2022-05-28 08:41:42 +0000, Malcolm McLean said:
> >> [... various restrictions ...]
> >>>> Now, unless I've nodded, I ought to be able to produce a very simple Turing
> >>>> machine which solves the halting problem for this domain.
> >>> You must also exclude directly and indirectly recursive functions.
> >>> In addition, the loop variable of a for loop must not be modified
> >>> in the loop and its address must not be given to a function that
> >>> does not promise to regard it as an address to a constant.
> >> What the pair of you are saying is, in effect, that there is a
> >> significant subset of programs which are guaranteed to halt, and for
> >> which the HP is therefore trivial. Such programs even include many of
> >> practical [eg engineering] interest. This is true, and uncontroversial.
> >> There are also significant subsets of programs which are guaranteed not
> >> to halt [at least in normal circumstances and short of hardware failure
> >> or intervention]. But, no matter how you slice and dice, there is also
> >> a substantial subset of programs whose behaviour cannot be determined
> >> by an algorithmic examination of the code [inc input]; and the attack
> >> on the HP via emulation and Busy Beavers shows clearly that a lot of
> >> /very/ simple programs, and indeed problems, fall into this category.
> >> [Not least because a UTM is a very simple program, and any complexity
> >> relates to its input, which /could/ be a representation of a UTM and
> >> /its/ input, which could be ....]
> >>
> >> As ever, although the HP is expressed in terms of halting, it
> >> equally applies to problems such as "Does my program ever reach line
> >> 23?", or "Does it ever produce any output?" or "Does it produce the
> >> same output as your program?", which may be of more practical interest.
> >> Yes, in line with what Malcolm is proposing, it's possible to produce
> >> analysers, perhaps even of commercial interest, which often say useful
> >> things about some code; but there are always areas of doubt, and
> >> every time you explore one of these another can of worms opens up.
> >>
> >> A partial answer for practical programming lies in disciplined
> >> code, with carefully designed pre- and post-conditions, etc., etc. But
> >> that doesn't help with programs written without that discipline, and it
> >> doesn't help to solve the Goldbach Conjecture.
> >>
> > PO seemed to be going down the route of saying that some programs
> > are not in the domain of his halt decider. Whilst that prompted ridicule,
> > it's not actually an inherently bad approach, depending what you want
> > to achieve.
> 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.
> NON-INPUTS DO NOT COUNT
> NON-INPUTS DO NOT COUNT
> NON-INPUTS DO NOT COUNT

Then why is Ha(Pa,Pa) deciding on the behavior of Pn(Pn)?

> It is the case that the correct x86 emulation of the input to H(P,P) by
> H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
> proved to be correct.
>
>
>
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

On 5/28/22 12:02 PM, olcott wrote:
> On 5/28/2022 10:29 AM, Richard Damon wrote:
>>
>> On 5/28/22 11:05 AM, olcott wrote:
>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>
>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of
>>>>>>>>>>>>>>>>>> configurations' mean. Richard is perfectly correct.
>>>>>>>>>>>>>>>>>> You, as usual, are not.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86
>>>>>>>>>>>>>>>>> program steps executed or emulated in the order that
>>>>>>>>>>>>>>>>> their source-code specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given
>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state
>>>>>>>>>>>>>>>> transitions. It is given a representation of a computation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
>>>>>>>>>>>>>>> is given a finite string TM description that specifies a
>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>> [000012c2](01)  55              push ebp
>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>>>>>>>> [000012c8](01)  c3              ret
>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>
>>>>>>>>>>>>> So then the above x86 code may specify a game of
>>>>>>>>>>>>> tic-tac-toe and there is no possible way to determine that
>>>>>>>>>>>>> it does not because the x86 source code of a function has
>>>>>>>>>>>>> nothing to do with the sequence of steps of its correct
>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>> something like this:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>
>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>>> appropriate emulator.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>> stated.
>>>>>>>>
>>>>>>>> You are the one who constantly makes much ado about nothing
>>>>>>>> about the fact that Turing Machines can ONLY accept finite
>>>>>>>> strings as their inputs and object to anyone who suggests that
>>>>>>>> something might compute some function which isn't over strings.
>>>>>>>>
>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>> finite string is simply a sequence of symbols. Given two
>>>>>>>> strings, you can ask questions like which is longer or whether
>>>>>>>> one is a substring or permutation of the other, but not much else.
>>>>>>>>
>>>>>>>> That's because neither strings nor the symbols they are composed
>>>>>>>> of have any meaning whatsoever. They are just sequences of
>>>>>>>> uninterpreted tokens. As soon as you start talking about
>>>>>>>> 'sequences of configurations' or 'numerical values' or anything
>>>>>>>> along those lines you are no longer talking about finite
>>>>>>>> strings, but about the entities which those strings represent to
>>>>>>>> a particular TM/program.
>>>>>>>>
>>>>>>>> Part of designing a TM involves specifying exactly how a string
>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
>>>>>>>> might seem to you) So yes, they need to be stated.
>>>>>>>>
>>>>>>>>
>>>>>>>>> If it was not for communication context then every single rule
>>>>>>>>> of grammar would have to be repeated with every sentence and
>>>>>>>>> every definition of every work would have to be repeated over
>>>>>>>>> and over.
>>>>>>>>>
>>>>>>>>>> You keep claiming that the input to the decider is a sequence
>>>>>>>>>> of configurations, but that's just plain wrong.
>>>>>>>>>
>>>>>>>>> The input to a decider
>>>>>>>>>
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> A sequence of configirations
>>>>>>>>>
>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>
>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage
>>>>>>>> a few posts ago, but nothing which made this clear. Repeating it
>>>>>>>> over and over again doesn't add any clarity.
>>>>>>>
>>>>>>>> The question originally arose when you objected to the claim
>>>>>>>> that the input to a halt decider represents a computation (or TM
>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>> specifies a sequence of configurations.
>>>>>>>>
>>>>>>>
>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>> practice for making milkshakes they already know when and how the
>>>>>>> x86 source-code must be applied to make a milkshake.
>>>>>>>
>>>>>>>> Now it seems like you are trying to claim that a representation
>>>>>>>> of a computation specifies a sequence of configurations, but
>>>>>>>> that doesn't explain why you so vehemently objected
>>>>>>>
>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>
>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>> like you never know.
>>>>>>>
>>>>>>
>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>> clear sentence because you misuse the English language to hide
>>>>>> your lies.
>>>>>
>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>> the basis of the fact correct execution trace of the x86
>>>>> source-code of input to H(P,P) shows that P would never reach its
>>>>> "ret" instruction.
>>>>
>>>> Again, I say HOW, since the CORRECT emulation of the input to
>>>> H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
>>>> Halts, if H is defined to return 0 from H(P,P).
>>>
>>> Richard is one of the two liars.
>>> *The actual behavior of P when correctly emulated by H is shown below*
>>
>>
>> No, it isn't, because it LIES.
>>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> _main()
>>> [00001372](01)  55              push ebp
>>> [00001373](02)  8bec            mov ebp,esp
>>> [00001375](05)  6852130000      push 00001352 // push P
>>> [0000137a](05)  6852130000      push 00001352 // push P
>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>> [00001384](03)  83c408          add esp,+08
>>> [00001387](01)  50              push eax
>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>> [00001392](03)  83c408          add esp,+08
>>> [00001395](02)  33c0            xor eax,eax
>>> [00001397](01)  5d              pop ebp
>>> [00001398](01)  c3              ret
>>> Size in bytes:(0039) [00001398]
>>>
>>>      machine   stack     stack     machine    assembly
>>>      address   address   data      code       language
>>>      ========  ========  ========  =========  =============
>>> ...[00001372][0010229e][00000000] 55         push ebp
>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>
>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>
>>> // H emulates the first seven instructions of P
>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>
>>> // The emulated H emulates the first seven instructions of P
>> So, the following is NOT an emulation of the P that the top level H is
>> emulating, and
>
> Right.
>
>> thus NOT part of a CORRECT x86 emulation of the program.
>
> Wrong.
>
> Just like the first invocation of infinite recursion is the root cause
> of the infinite recursion the first invocation of infinitely nested x86
> emulation is its root cause.
>

On Saturday, May 28, 2022 at 12:29:01 PM UTC-4, olcott wrote:
> On 5/28/2022 11:11 AM, Dennis Bush wrote:
> > On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:
> >> On 5/28/2022 10:29 AM, Richard Damon wrote:
> >>>
> >>> On 5/28/22 11:05 AM, olcott wrote:
> >>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
> >>>>>
> >>>>> On 5/28/22 6:26 AM, olcott wrote:
> >>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
> >>>>>>> On 5/27/22 7:33 PM, olcott wrote:
> >>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
> >>>>>>>>> On 2022-05-27 16:42, olcott wrote:
> >>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
> >>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
> >>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
> >>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
> >>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
> >>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
> >>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
> >>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
> >>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
> >>>>>>>>>>>>>>>>>>>> final state.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
> >>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
> >>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are
> >>>>>>>>>>>>>>>>>>> not.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The distinction that I make between represent and
> >>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
> >>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
> >>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
> >>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
> >>>>>>>>>>>>>>>>>> specified by P(P).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
> >>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
> >>>>>>>>>>>>>>>>>> source-code specifies.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
> >>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given
> >>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state
> >>>>>>>>>>>>>>>>> transitions. It is given a representation of a computation.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
> >>>>>>>>>>>>>>>> is given a finite string TM description that specifies a
> >>>>>>>>>>>>>>>> sequence of configurations.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> A TM description and a sequence of configurations are
> >>>>>>>>>>>>>>> entirely different things (and the former certainly does
> >>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
> >>>>>>>>>>>>>>> other. Make up your mind.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> André
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>> [000012c2](01) 55 push ebp
> >>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
> >>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
> >>>>>>>>>>>>>> [000012c8](01) c3 ret
> >>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
> >>>>>>>>>>>>>> and there is no possible way to determine that it does not
> >>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
> >>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
> >>>>>>>>>>>>> assembly code which represents a subroutine which is an
> >>>>>>>>>>>>> infinite loop. The sequence of configurations would look
> >>>>>>>>>>>>> something like this:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes that code specifies this sequence.
> >>>>>>>>>>>
> >>>>>>>>>>> No, it does not. What you have above only generates the
> >>>>>>>>>>> following *only* if you (a) interpret it as representing x86
> >>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
> >>>>>>>>>>> appropriate emulator.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Because no one in their right mind would think of doing it
> >>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
> >>>>>>>>>
> >>>>>>>>> You are the one who constantly makes much ado about nothing about
> >>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
> >>>>>>>>> their inputs and object to anyone who suggests that something
> >>>>>>>>> might compute some function which isn't over strings.
> >>>>>>>>>
> >>>>>>>>> You don't seem to understand exactly what a finite string is. A
> >>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
> >>>>>>>>> you can ask questions like which is longer or whether one is a
> >>>>>>>>> substring or permutation of the other, but not much else.
> >>>>>>>>>
> >>>>>>>>> That's because neither strings nor the symbols they are composed
> >>>>>>>>> of have any meaning whatsoever. They are just sequences of
> >>>>>>>>> uninterpreted tokens. As soon as you start talking about
> >>>>>>>>> 'sequences of configurations' or 'numerical values' or anything
> >>>>>>>>> along those lines you are no longer talking about finite strings,
> >>>>>>>>> but about the entities which those strings represent to a
> >>>>>>>>> particular TM/program.
> >>>>>>>>>
> >>>>>>>>> Part of designing a TM involves specifying exactly how a string
> >>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
> >>>>>>>>> might seem to you) So yes, they need to be stated.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> If it was not for communication context then every single rule
> >>>>>>>>>> of grammar would have to be repeated with every sentence and
> >>>>>>>>>> every definition of every work would have to be repeated over
> >>>>>>>>>> and over.
> >>>>>>>>>>
> >>>>>>>>>>> You keep claiming that the input to the decider is a sequence
> >>>>>>>>>>> of configurations, but that's just plain wrong.
> >>>>>>>>>>
> >>>>>>>>>> The input to a decider
> >>>>>>>>>>
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>> A sequence of configirations
> >>>>>>>>>>
> >>>>>>>>>> Did you notice that I said SPECFIES this time ???
> >>>>>>>>>
> >>>>>>>>> But you still haven't provided a coherent definition of what
> >>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a
> >>>>>>>>> few posts ago, but nothing which made this clear. Repeating it
> >>>>>>>>> over and over again doesn't add any clarity.
> >>>>>>>>
> >>>>>>>>> The question originally arose when you objected to the claim that
> >>>>>>>>> the input to a halt decider represents a computation (or TM
> >>>>>>>>> description/input string pair) and instead insisted that it
> >>>>>>>>> specifies a sequence of configurations.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Yes of course as everyone knows x86 source-code is one of the
> >>>>>>>> ingredients to a milkshake and because there is a standard
> >>>>>>>> practice for making milkshakes they already know when and how the
> >>>>>>>> x86 source-code must be applied to make a milkshake.
> >>>>>>>>
> >>>>>>>>> Now it seems like you are trying to claim that a representation
> >>>>>>>>> of a computation specifies a sequence of configurations, but that
> >>>>>>>>> doesn't explain why you so vehemently objected
> >>>>>>>>
> >>>>>>>> Your brain is welded in rebuttal mode?
> >>>>>>>>
> >>>>>>>>> to the claim that the input to a halt decider represents a
> >>>>>>>>> computation. So clearly you mean something else altogether.
> >>>>>>>>>
> >>>>>>>>> André
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Because your brain is welded in rebuttal mode you will always act
> >>>>>>>> like you never know.
> >>>>>>>>
> >>>>>>>
> >>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
> >>>>>>> clear sentence because you misuse the English language to hide your
> >>>>>>> lies.
> >>>>>>
> >>>>>> It is easily provable that the C function H(P,P)==0 is correct on
> >>>>>> the basis of the fact correct execution trace of the x86 source-code
> >>>>>> of input to H(P,P) shows that P would never reach its "ret"
> >>>>>> instruction.
> >>>>>
> >>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P),
> >>>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H
> >>>>> is defined to return 0 from H(P,P).
> >>>>
> >>>> Richard is one of the two liars.
> >>>> *The actual behavior of P when correctly emulated by H is shown below*
> >>>
> >>>
> >>> No, it isn't, because it LIES.
> >>>>
> >>>> #include <stdint.h>
> >>>> #define u32 uint32_t
> >>>>
> >>>> void P(u32 x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>> }
> >>>>
> >>>> _P()
> >>>> [00001352](01) 55 push ebp
> >>>> [00001353](02) 8bec mov ebp,esp
> >>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>> [00001358](01) 50 push eax // push P
> >>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [0000135c](01) 51 push ecx // push P
> >>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>> [00001362](03) 83c408 add esp,+08
> >>>> [00001365](02) 85c0 test eax,eax
> >>>> [00001367](02) 7402 jz 0000136b
> >>>> [00001369](02) ebfe jmp 00001369
> >>>> [0000136b](01) 5d pop ebp
> >>>> [0000136c](01) c3 ret
> >>>> Size in bytes:(0027) [0000136c]
> >>>>
> >>>> _main()
> >>>> [00001372](01) 55 push ebp
> >>>> [00001373](02) 8bec mov ebp,esp
> >>>> [00001375](05) 6852130000 push 00001352 // push P
> >>>> [0000137a](05) 6852130000 push 00001352 // push P
> >>>> [0000137f](05) e81efeffff call 000011a2 // call H
> >>>> [00001384](03) 83c408 add esp,+08
> >>>> [00001387](01) 50 push eax
> >>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
> >>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
> >>>> [00001392](03) 83c408 add esp,+08
> >>>> [00001395](02) 33c0 xor eax,eax
> >>>> [00001397](01) 5d pop ebp
> >>>> [00001398](01) c3 ret
> >>>> Size in bytes:(0039) [00001398]
> >>>>
> >>>> machine stack stack machine assembly
> >>>> address address data code language
> >>>> ======== ======== ======== ========= =============
> >>>> ...[00001372][0010229e][00000000] 55 push ebp
> >>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
> >>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> >>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> >>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
> >>>>
> >>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
> >>>>
> >>>> // H emulates the first seven instructions of P
> >>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
> >>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
> >>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
> >>>> ...[00001358][0021233a][00001352] 50 push eax // push P
> >>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
> >>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
> >>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
> >>>>
> >>>> // The emulated H emulates the first seven instructions of P
> >>> So, the following is NOT an emulation of the P that the top level H is
> >>> emulating, and
> >> Right.
> >>> thus NOT part of a CORRECT x86 emulation of the program.
> >> Wrong.
> >>
> >> Just like the first invocation of infinite recursion is the root cause
> >> of the infinite recursion the first invocation of infinitely nested x86
> >> emulation is its root cause.
> >>
> >>
> >> You are basically saying that when a C function H emulates another C
> >> function P and this second C function in
> >>
> >> I spent a year of development of the x86utm operating system so that
> >> when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could
> >> correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
> >> to an arbitrary recursive depth.
> >>
> >> I don't show the 236 pages of the emulation of H because we can simply
> >> hypothesize that it merely emulates its input
> >
> > Deceptive use of "H" to refer to multiple unrelated computations.
> >
> > The fixed algorithm of H, hereafter referred to as Ha, and the P that calls it referred to as Pa, does abort and does not "merely emulate". Hn is what does that. And since Pa doesn't call Hn that means we are no longer deciding on Pa but on Pn.
> >
> > So your argument boils down to: Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.
> >
> A halt decider must only compute the mapping from its input to an accept
> or reject state based on the actual behavior specified by this input.

On 5/28/2022 11:33 AM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 12:25:05 PM UTC-4, olcott wrote:
>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>> On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:
>>>> On 5/28/2022 10:23 AM, Dennis Bush wrote:
>>>>> On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
>>>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final
>>>>>>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The distinction that I make between represent and specify
>>>>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas
>>>>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not
>>>>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
>>>>>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions.
>>>>>>>>>>>>>>>>>>> It is given a representation of a computation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>>>>>>>>>>>> given a finite string TM description that specifies a
>>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>>>> entirely different things (and the former certainly does not
>>>>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other.
>>>>>>>>>>>>>>>>> Make up your mind.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>> [000012c2](01) 55 push ebp
>>>>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
>>>>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
>>>>>>>>>>>>>>>> [000012c8](01) c3 ret
>>>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, it does not. What you have above only generates the following
>>>>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions
>>>>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
>>>>>>>>>>>
>>>>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>>>>> their inputs and object to anyone who suggests that something might
>>>>>>>>>>> compute some function which isn't over strings.
>>>>>>>>>>>
>>>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>>>>
>>>>>>>>>>> That's because neither strings nor the symbols they are composed of
>>>>>>>>>>> have any meaning whatsoever. They are just sequences of
>>>>>>>>>>> uninterpreted tokens. As soon as you start talking about 'sequences
>>>>>>>>>>> of configurations' or 'numerical values' or anything along those
>>>>>>>>>>> lines you are no longer talking about finite strings, but about the
>>>>>>>>>>> entities which those strings represent to a particular TM/program.
>>>>>>>>>>>
>>>>>>>>>>> Part of designing a TM involves specifying exactly how a string is
>>>>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might
>>>>>>>>>>> seem to you) So yes, they need to be stated.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> If it was not for communication context then every single rule of
>>>>>>>>>>>> grammar would have to be repeated with every sentence and every
>>>>>>>>>>>> definition of every work would have to be repeated over and over.
>>>>>>>>>>>>
>>>>>>>>>>>>> You keep claiming that the input to the decider is a sequence of
>>>>>>>>>>>>> configurations, but that's just plain wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> The input to a decider
>>>>>>>>>>>>
>>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>>> A sequence of configirations
>>>>>>>>>>>>
>>>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>>>
>>>>>>>>>>> But you still haven't provided a coherent definition of what *you*
>>>>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
>>>>>>>>>>> posts ago, but nothing which made this clear. Repeating it over and
>>>>>>>>>>> over again doesn't add any clarity.
>>>>>>>>>>
>>>>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>>>> ingredients to a milkshake and because there is a standard practice
>>>>>>>>>> for making milkshakes they already know when and how the x86
>>>>>>>>>> source-code must be applied to make a milkshake.
>>>>>>>>>>
>>>>>>>>>>> Now it seems like you are trying to claim that a representation of
>>>>>>>>>>> a computation specifies a sequence of configurations, but that
>>>>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>>>>
>>>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>>>
>>>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>>>>> like you never know.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>>>> clear sentence because you misuse the English language to hide your
>>>>>>>>> lies.
>>>>>>>>
>>>>>>>> It is easily provable that the C function H(P,P)==0 is correct on the
>>>>>>>> basis of the fact correct execution trace of the x86 source-code of
>>>>>>>> input to H(P,P) shows that P would never reach its "ret" instruction.
>>>>>>>
>>>>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as
>>>>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
>>>>>>> defined to return 0 from H(P,P).
>>>>>> Richard is one of the two liars.
>>>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>>>>
>>>>>> #include <stdint.h>
>>>>>> #define u32 uint32_t
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> _P()
>>>>>> [00001352](01) 55 push ebp
>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>> [00001358](01) 50 push eax // push P
>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>> [0000136b](01) 5d pop ebp
>>>>>> [0000136c](01) c3 ret
>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>
>>>>>> _main()
>>>>>> [00001372](01) 55 push ebp
>>>>>> [00001373](02) 8bec mov ebp,esp
>>>>>> [00001375](05) 6852130000 push 00001352 // push P
>>>>>> [0000137a](05) 6852130000 push 00001352 // push P
>>>>>> [0000137f](05) e81efeffff call 000011a2 // call H
>>>>>> [00001384](03) 83c408 add esp,+08
>>>>>> [00001387](01) 50 push eax
>>>>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
>>>>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
>>>>>> [00001392](03) 83c408 add esp,+08
>>>>>> [00001395](02) 33c0 xor eax,eax
>>>>>> [00001397](01) 5d pop ebp
>>>>>> [00001398](01) c3 ret
>>>>>> Size in bytes:(0039) [00001398]
>>>>>>
>>>>>> machine stack stack machine assembly
>>>>>> address address data code language
>>>>>> ======== ======== ======== ========= =============
>>>>>> ...[00001372][0010229e][00000000] 55 push ebp
>>>>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
>>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>>>
>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>>>>>
>>>>>> // H emulates the first seven instructions of P
>>>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>>>>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>>>>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>>>>>> ...[00001358][0021233a][00001352] 50 push eax // push P
>>>>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>>>>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>>>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>>
>>>>> Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each of these lines is multiple instructions of the inner H performing the emulation of them.
>>>>>
>>>>>>
>>>>>> // The emulated H emulates the first seven instructions of P
>>>>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>>>>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>>>>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>>>>>> ...[00001358][0025cd62][00001352] 50 push eax // push P
>>>>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>>>>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
>>>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>
>>>>> Here is where H makes its error of aborting too soon. Explanation below:
>>>>>
>>>> Several different confusions (see below).
>>>>>>
>>>>>> If the execution trace of function H() called by function P() shows:
>>>>>> (1) Function H() is called twice in sequence from the same machine
>>>>>> address of P().
>>>>>> (2) With the same parameters to H().
>>>>>> (3) With no conditional branch or indexed jump instructions in P().
>>>>>
>>>>> This condition is not met.
>>>> (1) is proven
>>>> (2) is proven // Third column shows TOS value of P's machine address
>>>> (3) is proven //
>>>>> There are branches / jumps in the *program* P contained in the function H that can abort.
>>>> We are not looking for jumps, we are looking for code that can change
>>>> the behavior of P from one invocation to the next.
>>>
>>> And the conditional code of H that checks if its abort criteria is met does *exactly* that.
>> It is possible that H can change the behavior of P,
>>
>
> False premise. The behavior of H (actually Ha) *is* the behavior of P (actually Pa) as we're talking about complete computations, not individual functions. And the behavior of Pa(Pa) is that its embedded copy of Ha will as per its fixed algorithm abort and return 0 causing Pa(Pa) to halt.
>
> That Ha is unable to see that simply means that Ha is wrong.
>
>
>> yet H does not do
>> that until after its input has already correctly matched an infinite
>> behavior pattern.
>>
>> It is easy to verify that H does not change the behavior of P for the
>> first 14 instructions of P.
>>> The top level H is unable to see that the H called by P will trigger that abort condition if allowed to continue, such as when simulated by a UTM.
>>>
>>>> (a) conditional branch or
>>>> (b) indexed jump instructions (where the index can vary)
>>>>> The outer H is unable to detect that the inner H will do exactly what the outer H does,
>>>> None of this could possibly show that the simulated P ever reaches its
>>>> "ret" instruction, thus is irrelevant.
>>>>
>>>> We are not asking:
>>>> [A] Does P stop running?
>>>
>>> We are by the definition of the problem: does an algorithm exist that can detect if *any* arbitrary algorithm will halt when given a particular input.
>> No not at all this is false.
>> A halt decider must only compute the mapping of its input to an accept
>> or reject state based on the actual behavior specified by this input.
>
> And by the problem definition the actual behavior specified by the input is the behavior of Pa(Pa)
>
>>>
>>>>
>>>> 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.
>
> And by the problem definition the actual behavior specified by the input is the behavior of Pa(Pa)
>
>>
>> It is the case that the correct x86 emulation of the input to H(P,P) by
>> H
>
> Which is does NOT do as demonstrated by Pa(Pa) halting, UTM(Pa,Pa) halting, and H1(Pa,Pa) reaching a final state and returning 1.
>
>> would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
>> proved to be correct.
>

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

> On Saturday, 28 May 2022 at 13:18:28 UTC+1, Andy Walker wrote:

>> As ever, although the HP is expressed in terms of halting, it
>> equally applies to problems such as "Does my program ever reach line
>> 23?", or "Does it ever produce any output?" or "Does it produce the
>> same output as your program?", which may be of more practical interest.
>> Yes, in line with what Malcolm is proposing, it's possible to produce
>> analysers, perhaps even of commercial interest, which often say useful
>> things about some code; but there are always areas of doubt, and
>> every time you explore one of these another can of worms opens up.

And there are other natural undecidable problems such an the ambiguity
or otherwise of certain grammars, the word problem for groups and so on
(not to mention the Entscheidungsproblem).

>> A partial answer for practical programming lies in disciplined
>> code, with carefully designed pre- and post-conditions, etc., etc.

Part of the etc., etc. often forgotten is to find, where possible, a
bounded, strictly monotonic, integer-valued expression of the loop
count. For example, in many sort algorithms the count of out of place
values is non-negative and strictly decreasing.

>> But
>> that doesn't help with programs written without that discipline, and it
>> doesn't help to solve the Goldbach Conjecture.
>>
> PO seemed to be going down the route of saying that some programs
> are not in the domain of his halt decider. Whilst that prompted ridicule,
> it's not actually an inherently bad approach, depending what you want
> to achieve.

I suspect it prompted ridicule (if indeed it did) from people who know
what PO is claiming to have achieved. He's not interested in any
practical half-way house; he's been saying that the theorem is wrong,
and that he's refuted every proof (even without having read some of
them) for 18 years.

--
Ben.

On 5/28/22 12:28 PM, olcott wrote:
> On 5/28/2022 11:11 AM, Dennis Bush wrote:
>> On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:
>>> On 5/28/2022 10:29 AM, Richard Damon wrote:
>>>>
>>>> On 5/28/22 11:05 AM, olcott wrote:
>>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are
>>>>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given
>>>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state
>>>>>>>>>>>>>>>>>> transitions. It is given a representation of a
>>>>>>>>>>>>>>>>>> computation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
>>>>>>>>>>>>>>>>> is given a finite string TM description that specifies a
>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>> [000012c2](01)  55              push ebp
>>>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>>>>>>>>>> [000012c8](01)  c3              ret
>>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>>>>> appropriate emulator.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>>>> stated.
>>>>>>>>>>
>>>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>>>> their inputs and object to anyone who suggests that something
>>>>>>>>>> might compute some function which isn't over strings.
>>>>>>>>>>
>>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>>>
>>>>>>>>>> That's because neither strings nor the symbols they are composed
>>>>>>>>>> of have any meaning whatsoever. They are just sequences of
>>>>>>>>>> uninterpreted tokens. As soon as you start talking about
>>>>>>>>>> 'sequences of configurations' or 'numerical values' or anything
>>>>>>>>>> along those lines you are no longer talking about finite strings,
>>>>>>>>>> but about the entities which those strings represent to a
>>>>>>>>>> particular TM/program.
>>>>>>>>>>
>>>>>>>>>> Part of designing a TM involves specifying exactly how a string
>>>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
>>>>>>>>>> might seem to you) So yes, they need to be stated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> If it was not for communication context then every single rule
>>>>>>>>>>> of grammar would have to be repeated with every sentence and
>>>>>>>>>>> every definition of every work would have to be repeated over
>>>>>>>>>>> and over.
>>>>>>>>>>>
>>>>>>>>>>>> You keep claiming that the input to the decider is a sequence
>>>>>>>>>>>> of configurations, but that's just plain wrong.
>>>>>>>>>>>
>>>>>>>>>>> The input to a decider
>>>>>>>>>>>
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> A sequence of configirations
>>>>>>>>>>>
>>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>>
>>>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a
>>>>>>>>>> few posts ago, but nothing which made this clear. Repeating it
>>>>>>>>>> over and over again doesn't add any clarity.
>>>>>>>>>
>>>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>>>> practice for making milkshakes they already know when and how the
>>>>>>>>> x86 source-code must be applied to make a milkshake.
>>>>>>>>>
>>>>>>>>>> Now it seems like you are trying to claim that a representation
>>>>>>>>>> of a computation specifies a sequence of configurations, but that
>>>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>>>
>>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>>
>>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>>>> like you never know.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>>> clear sentence because you misuse the English language to hide your
>>>>>>>> lies.
>>>>>>>
>>>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>>>> the basis of the fact correct execution trace of the x86 source-code
>>>>>>> of input to H(P,P) shows that P would never reach its "ret"
>>>>>>> instruction.
>>>>>>
>>>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P),
>>>>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H
>>>>>> is defined to return 0 from H(P,P).
>>>>>
>>>>> Richard is one of the two liars.
>>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>>
>>>>
>>>> No, it isn't, because it LIES.
>>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>>     return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01)  55              push ebp
>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001358](01)  50              push eax      // push P
>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [0000135c](01)  51              push ecx      // push P
>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>> [00001362](03)  83c408          add esp,+08
>>>>> [00001365](02)  85c0            test eax,eax
>>>>> [00001367](02)  7402            jz 0000136b
>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>> [0000136b](01)  5d              pop ebp
>>>>> [0000136c](01)  c3              ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> _main()
>>>>> [00001372](01)  55              push ebp
>>>>> [00001373](02)  8bec            mov ebp,esp
>>>>> [00001375](05)  6852130000      push 00001352 // push P
>>>>> [0000137a](05)  6852130000      push 00001352 // push P
>>>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>>>> [00001384](03)  83c408          add esp,+08
>>>>> [00001387](01)  50              push eax
>>>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>>>> [00001392](03)  83c408          add esp,+08
>>>>> [00001395](02)  33c0            xor eax,eax
>>>>> [00001397](01)  5d              pop ebp
>>>>> [00001398](01)  c3              ret
>>>>> Size in bytes:(0039) [00001398]
>>>>>
>>>>>       machine   stack     stack     machine    assembly
>>>>>       address   address   data      code       language
>>>>>       ========  ========  ========  =========  =============
>>>>> ...[00001372][0010229e][00000000] 55         push ebp
>>>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>>
>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>>>
>>>>> // H emulates the first seven instructions of P
>>>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>>
>>>>> // The emulated H emulates the first seven instructions of P
>>>> So, the following is NOT an emulation of the P that the top level H is
>>>> emulating, and
>>> Right.
>>>> thus NOT part of a CORRECT x86 emulation of the program.
>>> Wrong.
>>>
>>> Just like the first invocation of infinite recursion is the root cause
>>> of the infinite recursion the first invocation of infinitely nested x86
>>> emulation is its root cause.
>>>
>>>
>>> You are basically saying that when a C function H emulates another C
>>> function P and this second C function in
>>>
>>> I spent a year of development of the x86utm operating system so that
>>> when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could
>>> correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
>>> to an arbitrary recursive depth.
>>>
>>> I don't show the 236 pages of the emulation of H because we can simply
>>> hypothesize that it merely emulates its input
>>
>> Deceptive use of "H" to refer to multiple unrelated computations.
>>
>> The fixed algorithm of H, hereafter referred to as Ha, and the P that
>> calls it referred to as Pa, does abort and does not "merely emulate".
>> Hn is what does that.  And since Pa doesn't call Hn that means we are
>> no longer deciding on Pa but on Pn.
>>
>> So your argument boils down to:  Ha(Pa,Pa)==0 is correct because
>> Pn(Pn) does  not halt.
>>
>
> A halt decider must only compute the mapping from its input to an accept
> or reject state based on the actual behavior specified by this input.
>
> It is the case that the correct x86 emulation of the input to H(P,P) by
> H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
> proved to be correct.
>

On Saturday, May 28, 2022 at 12:38:57 PM UTC-4, olcott wrote:
> On 5/28/2022 11:33 AM, Dennis Bush wrote:
> > On Saturday, May 28, 2022 at 12:25:05 PM UTC-4, olcott wrote:
> >> On 5/28/2022 11:06 AM, Dennis Bush wrote:
> >>> On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:
> >>>> On 5/28/2022 10:23 AM, Dennis Bush wrote:
> >>>>> On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
> >>>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
> >>>>>>>
> >>>>>>> On 5/28/22 6:26 AM, olcott wrote:
> >>>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
> >>>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
> >>>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
> >>>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
> >>>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
> >>>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
> >>>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
> >>>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
> >>>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
> >>>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
> >>>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final
> >>>>>>>>>>>>>>>>>>>>>> state.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
> >>>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
> >>>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The distinction that I make between represent and specify
> >>>>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas
> >>>>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P)
> >>>>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not
> >>>>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
> >>>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
> >>>>>>>>>>>>>>>>>>>> source-code specifies.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
> >>>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
> >>>>>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions.
> >>>>>>>>>>>>>>>>>>> It is given a representation of a computation.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider is
> >>>>>>>>>>>>>>>>>> given a finite string TM description that specifies a
> >>>>>>>>>>>>>>>>>> sequence of configurations.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
> >>>>>>>>>>>>>>>>> entirely different things (and the former certainly does not
> >>>>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other.
> >>>>>>>>>>>>>>>>> Make up your mind.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> André
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>>>> [000012c2](01) 55 push ebp
> >>>>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
> >>>>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
> >>>>>>>>>>>>>>>> [000012c8](01) c3 ret
> >>>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
> >>>>>>>>>>>>>>>> and there is no possible way to determine that it does not
> >>>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
> >>>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
> >>>>>>>>>>>>>>> assembly code which represents a subroutine which is an
> >>>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
> >>>>>>>>>>>>>>> something like this:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Yes that code specifies this sequence.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No, it does not. What you have above only generates the following
> >>>>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions
> >>>>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Because no one in their right mind would think of doing it
> >>>>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
> >>>>>>>>>>>
> >>>>>>>>>>> You are the one who constantly makes much ado about nothing about
> >>>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
> >>>>>>>>>>> their inputs and object to anyone who suggests that something might
> >>>>>>>>>>> compute some function which isn't over strings.
> >>>>>>>>>>>
> >>>>>>>>>>> You don't seem to understand exactly what a finite string is. A
> >>>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
> >>>>>>>>>>> you can ask questions like which is longer or whether one is a
> >>>>>>>>>>> substring or permutation of the other, but not much else.
> >>>>>>>>>>>
> >>>>>>>>>>> That's because neither strings nor the symbols they are composed of
> >>>>>>>>>>> have any meaning whatsoever. They are just sequences of
> >>>>>>>>>>> uninterpreted tokens. As soon as you start talking about 'sequences
> >>>>>>>>>>> of configurations' or 'numerical values' or anything along those
> >>>>>>>>>>> lines you are no longer talking about finite strings, but about the
> >>>>>>>>>>> entities which those strings represent to a particular TM/program.
> >>>>>>>>>>>
> >>>>>>>>>>> Part of designing a TM involves specifying exactly how a string is
> >>>>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might
> >>>>>>>>>>> seem to you) So yes, they need to be stated.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> If it was not for communication context then every single rule of
> >>>>>>>>>>>> grammar would have to be repeated with every sentence and every
> >>>>>>>>>>>> definition of every work would have to be repeated over and over.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> You keep claiming that the input to the decider is a sequence of
> >>>>>>>>>>>>> configurations, but that's just plain wrong.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The input to a decider
> >>>>>>>>>>>>
> >>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> >>>>>>>>>>>> A sequence of configirations
> >>>>>>>>>>>>
> >>>>>>>>>>>> Did you notice that I said SPECFIES this time ???
> >>>>>>>>>>>
> >>>>>>>>>>> But you still haven't provided a coherent definition of what *you*
> >>>>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
> >>>>>>>>>>> posts ago, but nothing which made this clear. Repeating it over and
> >>>>>>>>>>> over again doesn't add any clarity.
> >>>>>>>>>>
> >>>>>>>>>>> The question originally arose when you objected to the claim that
> >>>>>>>>>>> the input to a halt decider represents a computation (or TM
> >>>>>>>>>>> description/input string pair) and instead insisted that it
> >>>>>>>>>>> specifies a sequence of configurations.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
> >>>>>>>>>> ingredients to a milkshake and because there is a standard practice
> >>>>>>>>>> for making milkshakes they already know when and how the x86
> >>>>>>>>>> source-code must be applied to make a milkshake.
> >>>>>>>>>>
> >>>>>>>>>>> Now it seems like you are trying to claim that a representation of
> >>>>>>>>>>> a computation specifies a sequence of configurations, but that
> >>>>>>>>>>> doesn't explain why you so vehemently objected
> >>>>>>>>>>
> >>>>>>>>>> Your brain is welded in rebuttal mode?
> >>>>>>>>>>
> >>>>>>>>>>> to the claim that the input to a halt decider represents a
> >>>>>>>>>>> computation. So clearly you mean something else altogether.
> >>>>>>>>>>>
> >>>>>>>>>>> André
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Because your brain is welded in rebuttal mode you will always act
> >>>>>>>>>> like you never know.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
> >>>>>>>>> clear sentence because you misuse the English language to hide your
> >>>>>>>>> lies.
> >>>>>>>>
> >>>>>>>> It is easily provable that the C function H(P,P)==0 is correct on the
> >>>>>>>> basis of the fact correct execution trace of the x86 source-code of
> >>>>>>>> input to H(P,P) shows that P would never reach its "ret" instruction.
> >>>>>>>
> >>>>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as
> >>>>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
> >>>>>>> defined to return 0 from H(P,P).
> >>>>>> Richard is one of the two liars.
> >>>>>> *The actual behavior of P when correctly emulated by H is shown below*
> >>>>>>
> >>>>>> #include <stdint.h>
> >>>>>> #define u32 uint32_t
> >>>>>>
> >>>>>> void P(u32 x)
> >>>>>> {
> >>>>>> if (H(x, x))
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>> }
> >>>>>>
> >>>>>> _P()
> >>>>>> [00001352](01) 55 push ebp
> >>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>> [00001358](01) 50 push eax // push P
> >>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>> [0000136b](01) 5d pop ebp
> >>>>>> [0000136c](01) c3 ret
> >>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>
> >>>>>> _main()
> >>>>>> [00001372](01) 55 push ebp
> >>>>>> [00001373](02) 8bec mov ebp,esp
> >>>>>> [00001375](05) 6852130000 push 00001352 // push P
> >>>>>> [0000137a](05) 6852130000 push 00001352 // push P
> >>>>>> [0000137f](05) e81efeffff call 000011a2 // call H
> >>>>>> [00001384](03) 83c408 add esp,+08
> >>>>>> [00001387](01) 50 push eax
> >>>>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
> >>>>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
> >>>>>> [00001392](03) 83c408 add esp,+08
> >>>>>> [00001395](02) 33c0 xor eax,eax
> >>>>>> [00001397](01) 5d pop ebp
> >>>>>> [00001398](01) c3 ret
> >>>>>> Size in bytes:(0039) [00001398]
> >>>>>>
> >>>>>> machine stack stack machine assembly
> >>>>>> address address data code language
> >>>>>> ======== ======== ======== ========= =============
> >>>>>> ...[00001372][0010229e][00000000] 55 push ebp
> >>>>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
> >>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> >>>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> >>>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
> >>>>>>
> >>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
> >>>>>>
> >>>>>> // H emulates the first seven instructions of P
> >>>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
> >>>>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
> >>>>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
> >>>>>> ...[00001358][0021233a][00001352] 50 push eax // push P
> >>>>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
> >>>>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
> >>>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
> >>>>>
> >>>>> Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each of these lines is multiple instructions of the inner H performing the emulation of them.
> >>>>>
> >>>>>>
> >>>>>> // The emulated H emulates the first seven instructions of P
> >>>>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
> >>>>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> >>>>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> >>>>>> ...[00001358][0025cd62][00001352] 50 push eax // push P
> >>>>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> >>>>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
> >>>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> >>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >>>>>
> >>>>> Here is where H makes its error of aborting too soon. Explanation below:
> >>>>>
> >>>> Several different confusions (see below).
> >>>>>>
> >>>>>> If the execution trace of function H() called by function P() shows:
> >>>>>> (1) Function H() is called twice in sequence from the same machine
> >>>>>> address of P().
> >>>>>> (2) With the same parameters to H().
> >>>>>> (3) With no conditional branch or indexed jump instructions in P()..
> >>>>>
> >>>>> This condition is not met.
> >>>> (1) is proven
> >>>> (2) is proven // Third column shows TOS value of P's machine address
> >>>> (3) is proven //
> >>>>> There are branches / jumps in the *program* P contained in the function H that can abort.
> >>>> We are not looking for jumps, we are looking for code that can change
> >>>> the behavior of P from one invocation to the next.
> >>>
> >>> And the conditional code of H that checks if its abort criteria is met does *exactly* that.
> >> It is possible that H can change the behavior of P,
> >>
> >
> > False premise. The behavior of H (actually Ha) *is* the behavior of P (actually Pa) as we're talking about complete computations, not individual functions. And the behavior of Pa(Pa) is that its embedded copy of Ha will as per its fixed algorithm abort and return 0 causing Pa(Pa) to halt.
> >
> > That Ha is unable to see that simply means that Ha is wrong.
> >
> >
> >> yet H does not do
> >> that until after its input has already correctly matched an infinite
> >> behavior pattern.
> >>
> >> It is easy to verify that H does not change the behavior of P for the
> >> first 14 instructions of P.
> >>> The top level H is unable to see that the H called by P will trigger that abort condition if allowed to continue, such as when simulated by a UTM.
> >>>
> >>>> (a) conditional branch or
> >>>> (b) indexed jump instructions (where the index can vary)
> >>>>> The outer H is unable to detect that the inner H will do exactly what the outer H does,
> >>>> None of this could possibly show that the simulated P ever reaches its
> >>>> "ret" instruction, thus is irrelevant.
> >>>>
> >>>> We are not asking:
> >>>> [A] Does P stop running?
> >>>
> >>> We are by the definition of the problem: does an algorithm exist that can detect if *any* arbitrary algorithm will halt when given a particular input.
> >> No not at all this is false.
> >> A halt decider must only compute the mapping of its input to an accept
> >> or reject state based on the actual behavior specified by this input.
> >
> > And by the problem definition the actual behavior specified by the input is the behavior of Pa(Pa)
> >
> >>>
> >>>>
> >>>> 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.
> >
> > And by the problem definition the actual behavior specified by the input is the behavior of Pa(Pa)
> >
> >>
> >> It is the case that the correct x86 emulation of the input to H(P,P) by
> >> H
> >
> > Which is does NOT do as demonstrated by Pa(Pa) halting, UTM(Pa,Pa) halting, and H1(Pa,Pa) reaching a final state and returning 1.
> >
> >> would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
> >> proved to be correct.
> >
> Both of the following are verified facts,

On 5/28/22 12:25 PM, Malcolm McLean wrote:
> On Saturday, 28 May 2022 at 13:18:28 UTC+1, Andy Walker wrote:
>> On 28/05/2022 11:46, Mikko wrote:
>>> On 2022-05-28 08:41:42 +0000, Malcolm McLean said:
>> [... various restrictions ...]
>>>> Now, unless I've nodded, I ought to be able to produce a very simple Turing
>>>> machine which solves the halting problem for this domain.
>>> You must also exclude directly and indirectly recursive functions.
>>> In addition, the loop variable of a for loop must not be modified
>>> in the loop and its address must not be given to a function that
>>> does not promise to regard it as an address to a constant.
>> What the pair of you are saying is, in effect, that there is a
>> significant subset of programs which are guaranteed to halt, and for
>> which the HP is therefore trivial. Such programs even include many of
>> practical [eg engineering] interest. This is true, and uncontroversial.
>> There are also significant subsets of programs which are guaranteed not
>> to halt [at least in normal circumstances and short of hardware failure
>> or intervention]. But, no matter how you slice and dice, there is also
>> a substantial subset of programs whose behaviour cannot be determined
>> by an algorithmic examination of the code [inc input]; and the attack
>> on the HP via emulation and Busy Beavers shows clearly that a lot of
>> /very/ simple programs, and indeed problems, fall into this category.
>> [Not least because a UTM is a very simple program, and any complexity
>> relates to its input, which /could/ be a representation of a UTM and
>> /its/ input, which could be ....]
>>
>> As ever, although the HP is expressed in terms of halting, it
>> equally applies to problems such as "Does my program ever reach line
>> 23?", or "Does it ever produce any output?" or "Does it produce the
>> same output as your program?", which may be of more practical interest.
>> Yes, in line with what Malcolm is proposing, it's possible to produce
>> analysers, perhaps even of commercial interest, which often say useful
>> things about some code; but there are always areas of doubt, and
>> every time you explore one of these another can of worms opens up.
>>
>> A partial answer for practical programming lies in disciplined
>> code, with carefully designed pre- and post-conditions, etc., etc. But
>> that doesn't help with programs written without that discipline, and it
>> doesn't help to solve the Goldbach Conjecture.
>>
> PO seemed to be going down the route of saying that some programs
> are not in the domain of his halt decider. Whilst that prompted ridicule,
> it's not actually an inherently bad approach, depending what you want
> to achieve.

For a "Practical" Halt Decider, yes.

For a Theoretical Counter to the Halting Theorem Prrof, it makes it
ineligable.

On 5/28/22 12:31 PM, olcott wrote:
> On 5/28/2022 11:25 AM, Malcolm McLean wrote:
>> On Saturday, 28 May 2022 at 13:18:28 UTC+1, Andy Walker wrote:
>>> On 28/05/2022 11:46, Mikko wrote:
>>>> On 2022-05-28 08:41:42 +0000, Malcolm McLean said:
>>> [... various restrictions ...]
>>>>> Now, unless I've nodded, I ought to be able to produce a very
>>>>> simple Turing
>>>>> machine which solves the halting problem for this domain.
>>>> You must also exclude directly and indirectly recursive functions.
>>>> In addition, the loop variable of a for loop must not be modified
>>>> in the loop and its address must not be given to a function that
>>>> does not promise to regard it as an address to a constant.
>>> What the pair of you are saying is, in effect, that there is a
>>> significant subset of programs which are guaranteed to halt, and for
>>> which the HP is therefore trivial. Such programs even include many of
>>> practical [eg engineering] interest. This is true, and uncontroversial.
>>> There are also significant subsets of programs which are guaranteed not
>>> to halt [at least in normal circumstances and short of hardware failure
>>> or intervention]. But, no matter how you slice and dice, there is also
>>> a substantial subset of programs whose behaviour cannot be determined
>>> by an algorithmic examination of the code [inc input]; and the attack
>>> on the HP via emulation and Busy Beavers shows clearly that a lot of
>>> /very/ simple programs, and indeed problems, fall into this category.
>>> [Not least because a UTM is a very simple program, and any complexity
>>> relates to its input, which /could/ be a representation of a UTM and
>>> /its/ input, which could be ....]
>>>
>>> As ever, although the HP is expressed in terms of halting, it
>>> equally applies to problems such as "Does my program ever reach line
>>> 23?", or "Does it ever produce any output?" or "Does it produce the
>>> same output as your program?", which may be of more practical interest.
>>> Yes, in line with what Malcolm is proposing, it's possible to produce
>>> analysers, perhaps even of commercial interest, which often say useful
>>> things about some code; but there are always areas of doubt, and
>>> every time you explore one of these another can of worms opens up.
>>>
>>> A partial answer for practical programming lies in disciplined
>>> code, with carefully designed pre- and post-conditions, etc., etc. But
>>> that doesn't help with programs written without that discipline, and it
>>> doesn't help to solve the Goldbach Conjecture.
>>>
>> PO seemed to be going down the route of saying that some programs
>> are not in the domain of his halt decider. Whilst that prompted ridicule,
>> it's not actually an inherently bad approach, depending what you want
>> to achieve.
>
>
> 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.
>
> NON-INPUTS DO NOT COUNT
> NON-INPUTS DO NOT COUNT
> NON-INPUTS DO NOT COUNT
>
> 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.
>

And in what way is the "representation" or P/H^ not an input?

The problem is Given a representation, determine the halitng behavior.
Thus the behavior of the machine represented by the input not a
"non-input" but the goal of the decider itself. If it isn't, then it
isn't a Halt Decider.

"The Actual Behavior specified by this input" for H(M,w) is the behavior
of M(w) BY DEFINITION, so this CAN'T be just defined as a "NON-INPUT",
unless you want to just define that Halt Decider just can't exist.

FAIL.

On 5/28/2022 11:35 AM, Richard Damon wrote:
> On 5/28/22 12:02 PM, olcott wrote:
>> On 5/28/2022 10:29 AM, Richard Damon wrote:
>>>
>>> On 5/28/22 11:05 AM, olcott wrote:
>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>
>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of
>>>>>>>>>>>>>>>>>>>>> configuratios", but the representation of an
>>>>>>>>>>>>>>>>>>>>> algorithm and its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms
>>>>>>>>>>>>>>>>>>> like 'represent', 'specify', or 'sequence of
>>>>>>>>>>>>>>>>>>> configurations' mean. Richard is perfectly correct.
>>>>>>>>>>>>>>>>>>> You, as usual, are not.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86
>>>>>>>>>>>>>>>>>> program steps executed or emulated in the order that
>>>>>>>>>>>>>>>>>> their source-code specifies.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is
>>>>>>>>>>>>>>>>> given as its input. It is not given a sequence of state
>>>>>>>>>>>>>>>>> transitions. It is given a representation of a
>>>>>>>>>>>>>>>>> computation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
>>>>>>>>>>>>>>>> is given a finite string TM description that specifies a
>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>> [000012c2](01)  55              push ebp
>>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>>>>>>>>> [000012c8](01)  c3              ret
>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So then the above x86 code may specify a game of
>>>>>>>>>>>>>> tic-tac-toe and there is no possible way to determine that
>>>>>>>>>>>>>> it does not because the x86 source code of a function has
>>>>>>>>>>>>>> nothing to do with the sequence of steps of its correct
>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>
>>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>>>> appropriate emulator.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>>> stated.
>>>>>>>>>
>>>>>>>>> You are the one who constantly makes much ado about nothing
>>>>>>>>> about the fact that Turing Machines can ONLY accept finite
>>>>>>>>> strings as their inputs and object to anyone who suggests that
>>>>>>>>> something might compute some function which isn't over strings.
>>>>>>>>>
>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>> finite string is simply a sequence of symbols. Given two
>>>>>>>>> strings, you can ask questions like which is longer or whether
>>>>>>>>> one is a substring or permutation of the other, but not much else.
>>>>>>>>>
>>>>>>>>> That's because neither strings nor the symbols they are
>>>>>>>>> composed of have any meaning whatsoever. They are just
>>>>>>>>> sequences of uninterpreted tokens. As soon as you start talking
>>>>>>>>> about 'sequences of configurations' or 'numerical values' or
>>>>>>>>> anything along those lines you are no longer talking about
>>>>>>>>> finite strings, but about the entities which those strings
>>>>>>>>> represent to a particular TM/program.
>>>>>>>>>
>>>>>>>>> Part of designing a TM involves specifying exactly how a string
>>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
>>>>>>>>> might seem to you) So yes, they need to be stated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If it was not for communication context then every single rule
>>>>>>>>>> of grammar would have to be repeated with every sentence and
>>>>>>>>>> every definition of every work would have to be repeated over
>>>>>>>>>> and over.
>>>>>>>>>>
>>>>>>>>>>> You keep claiming that the input to the decider is a sequence
>>>>>>>>>>> of configurations, but that's just plain wrong.
>>>>>>>>>>
>>>>>>>>>> The input to a decider
>>>>>>>>>>
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> A sequence of configirations
>>>>>>>>>>
>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>
>>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage
>>>>>>>>> a few posts ago, but nothing which made this clear. Repeating
>>>>>>>>> it over and over again doesn't add any clarity.
>>>>>>>>
>>>>>>>>> The question originally arose when you objected to the claim
>>>>>>>>> that the input to a halt decider represents a computation (or
>>>>>>>>> TM description/input string pair) and instead insisted that it
>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>>> practice for making milkshakes they already know when and how
>>>>>>>> the x86 source-code must be applied to make a milkshake.
>>>>>>>>
>>>>>>>>> Now it seems like you are trying to claim that a representation
>>>>>>>>> of a computation specifies a sequence of configurations, but
>>>>>>>>> that doesn't explain why you so vehemently objected
>>>>>>>>
>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>
>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because your brain is welded in rebuttal mode you will always
>>>>>>>> act like you never know.
>>>>>>>>
>>>>>>>
>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>> clear sentence because you misuse the English language to hide
>>>>>>> your lies.
>>>>>>
>>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>>> the basis of the fact correct execution trace of the x86
>>>>>> source-code of input to H(P,P) shows that P would never reach its
>>>>>> "ret" instruction.
>>>>>
>>>>> Again, I say HOW, since the CORRECT emulation of the input to
>>>>> H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
>>>>> Halts, if H is defined to return 0 from H(P,P).
>>>>
>>>> Richard is one of the two liars.
>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>
>>>
>>> No, it isn't, because it LIES.
>>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001352](01)  55              push ebp
>>>> [00001353](02)  8bec            mov ebp,esp
>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>> [00001358](01)  50              push eax      // push P
>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>> [0000135c](01)  51              push ecx      // push P
>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>> [00001362](03)  83c408          add esp,+08
>>>> [00001365](02)  85c0            test eax,eax
>>>> [00001367](02)  7402            jz 0000136b
>>>> [00001369](02)  ebfe            jmp 00001369
>>>> [0000136b](01)  5d              pop ebp
>>>> [0000136c](01)  c3              ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> _main()
>>>> [00001372](01)  55              push ebp
>>>> [00001373](02)  8bec            mov ebp,esp
>>>> [00001375](05)  6852130000      push 00001352 // push P
>>>> [0000137a](05)  6852130000      push 00001352 // push P
>>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>>> [00001384](03)  83c408          add esp,+08
>>>> [00001387](01)  50              push eax
>>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>>> [00001392](03)  83c408          add esp,+08
>>>> [00001395](02)  33c0            xor eax,eax
>>>> [00001397](01)  5d              pop ebp
>>>> [00001398](01)  c3              ret
>>>> Size in bytes:(0039) [00001398]
>>>>
>>>>      machine   stack     stack     machine    assembly
>>>>      address   address   data      code       language
>>>>      ========  ========  ========  =========  =============
>>>> ...[00001372][0010229e][00000000] 55         push ebp
>>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>
>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>>
>>>> // H emulates the first seven instructions of P
>>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>
>>>> // The emulated H emulates the first seven instructions of P
>>> So, the following is NOT an emulation of the P that the top level H
>>> is emulating, and
>>
>> Right.
>>
>>> thus NOT part of a CORRECT x86 emulation of the program.
>>
>> Wrong.
>>
>> Just like the first invocation of infinite recursion is the root cause
>> of the infinite recursion the first invocation of infinitely nested
>> x86 emulation is its root cause.
>>
>
> Except you don't understand the definitions.
>
> The second emulation is NOT an emulation by the emulator we are looking
> at (At least not if H is how you have defined it), so can't be just
> called part of it.
>

On 5/28/22 12:24 PM, olcott wrote:
> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>> On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:
>>> On 5/28/2022 10:23 AM, Dennis Bush wrote:
>>>> On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
>>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual,
>>>>>>>>>>>>>>>>>>>> are not.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>>>> specify
>>>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P)
>>>>>>>>>>>>>>>>>>> whereas
>>>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not
>>>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is
>>>>>>>>>>>>>>>>>> given as
>>>>>>>>>>>>>>>>>> its input. It is not given a sequence of state
>>>>>>>>>>>>>>>>>> transitions.
>>>>>>>>>>>>>>>>>> It is given a representation of a computation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt
>>>>>>>>>>>>>>>>> decider is
>>>>>>>>>>>>>>>>> given a finite string TM description that specifies a
>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other.
>>>>>>>>>>>>>>>> Make up your mind.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>> [000012c2](01) 55 push ebp
>>>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
>>>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
>>>>>>>>>>>>>>> [000012c8](01) c3 ret
>>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>>>> following
>>>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions
>>>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate
>>>>>>>>>>>> emulator.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>>>> stated.
>>>>>>>>>>
>>>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>>>> their inputs and object to anyone who suggests that something
>>>>>>>>>> might
>>>>>>>>>> compute some function which isn't over strings.
>>>>>>>>>>
>>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>>>
>>>>>>>>>> That's because neither strings nor the symbols they are
>>>>>>>>>> composed of
>>>>>>>>>> have any meaning whatsoever. They are just sequences of
>>>>>>>>>> uninterpreted tokens. As soon as you start talking about
>>>>>>>>>> 'sequences
>>>>>>>>>> of configurations' or 'numerical values' or anything along those
>>>>>>>>>> lines you are no longer talking about finite strings, but
>>>>>>>>>> about the
>>>>>>>>>> entities which those strings represent to a particular
>>>>>>>>>> TM/program.
>>>>>>>>>>
>>>>>>>>>> Part of designing a TM involves specifying exactly how a
>>>>>>>>>> string is
>>>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might
>>>>>>>>>> seem to you) So yes, they need to be stated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> If it was not for communication context then every single
>>>>>>>>>>> rule of
>>>>>>>>>>> grammar would have to be repeated with every sentence and every
>>>>>>>>>>> definition of every work would have to be repeated over and
>>>>>>>>>>> over.
>>>>>>>>>>>
>>>>>>>>>>>> You keep claiming that the input to the decider is a
>>>>>>>>>>>> sequence of
>>>>>>>>>>>> configurations, but that's just plain wrong.
>>>>>>>>>>>
>>>>>>>>>>> The input to a decider
>>>>>>>>>>>
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> A sequence of configirations
>>>>>>>>>>>
>>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>>
>>>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>>>> *you*
>>>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
>>>>>>>>>> posts ago, but nothing which made this clear. Repeating it
>>>>>>>>>> over and
>>>>>>>>>> over again doesn't add any clarity.
>>>>>>>>>
>>>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>>>> practice
>>>>>>>>> for making milkshakes they already know when and how the x86
>>>>>>>>> source-code must be applied to make a milkshake.
>>>>>>>>>
>>>>>>>>>> Now it seems like you are trying to claim that a
>>>>>>>>>> representation of
>>>>>>>>>> a computation specifies a sequence of configurations, but that
>>>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>>>
>>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>>
>>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>>>> like you never know.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>>> clear sentence because you misuse the English language to hide your
>>>>>>>> lies.
>>>>>>>
>>>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>>>> the
>>>>>>> basis of the fact correct execution trace of the x86 source-code of
>>>>>>> input to H(P,P) shows that P would never reach its "ret"
>>>>>>> instruction.
>>>>>>
>>>>>> Again, I say HOW, since the CORRECT emulation of the input to
>>>>>> H(P,P), as
>>>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
>>>>>> defined to return 0 from H(P,P).
>>>>> Richard is one of the two liars.
>>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01) 55 push ebp
>>>>> [00001353](02) 8bec mov ebp,esp
>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>> [00001358](01) 50 push eax // push P
>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>> [0000135c](01) 51 push ecx // push P
>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>> [00001362](03) 83c408 add esp,+08
>>>>> [00001365](02) 85c0 test eax,eax
>>>>> [00001367](02) 7402 jz 0000136b
>>>>> [00001369](02) ebfe jmp 00001369
>>>>> [0000136b](01) 5d pop ebp
>>>>> [0000136c](01) c3 ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> _main()
>>>>> [00001372](01) 55 push ebp
>>>>> [00001373](02) 8bec mov ebp,esp
>>>>> [00001375](05) 6852130000 push 00001352 // push P
>>>>> [0000137a](05) 6852130000 push 00001352 // push P
>>>>> [0000137f](05) e81efeffff call 000011a2 // call H
>>>>> [00001384](03) 83c408 add esp,+08
>>>>> [00001387](01) 50 push eax
>>>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
>>>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
>>>>> [00001392](03) 83c408 add esp,+08
>>>>> [00001395](02) 33c0 xor eax,eax
>>>>> [00001397](01) 5d pop ebp
>>>>> [00001398](01) c3 ret
>>>>> Size in bytes:(0039) [00001398]
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> ...[00001372][0010229e][00000000] 55 push ebp
>>>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>>
>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>>>>
>>>>> // H emulates the first seven instructions of P
>>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>>>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>>>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>>>>> ...[00001358][0021233a][00001352] 50 push eax // push P
>>>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>
>>>> Starting here is where the trace is incomplete. The emulation of the
>>>> instructions of the inner instance of H are not shown. Also the
>>>> lines below are not emulated by the top level H. They are emulated
>>>> by the inner H called by P. So in between each of these lines is
>>>> multiple instructions of the inner H performing the emulation of them.
>>>>
>>>>>
>>>>> // The emulated H emulates the first seven instructions of P
>>>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>>>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>>>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>>>>> ...[00001358][0025cd62][00001352] 50 push eax // push P
>>>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
>>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> Here is where H makes its error of aborting too soon. Explanation
>>>> below:
>>>>
>>> Several different confusions (see below).
>>>>>
>>>>> If the execution trace of function H() called by function P() shows:
>>>>> (1) Function H() is called twice in sequence from the same machine
>>>>> address of P().
>>>>> (2) With the same parameters to H().
>>>>> (3) With no conditional branch or indexed jump instructions in P().
>>>>
>>>> This condition is not met.
>>> (1) is proven
>>> (2) is proven // Third column shows TOS value of P's machine address
>>> (3) is proven //
>>>> There are branches / jumps in the *program* P contained in the
>>>> function H that can abort.
>>> We are not looking for jumps, we are looking for code that can change
>>> the behavior of P from one invocation to the next.
>>
>> And the conditional code of H that checks if its abort criteria is met
>> does *exactly* that.
>
> It is possible that H can change the behavior of P, yet H does not do
> that until after its input has already correctly matched an infinite
> behavior pattern.
>
> It is easy to verify that H does not change the behavior of P for the
> first 14 instructions of P.
>
>> The top level H is unable to see that the H called by P will trigger
>> that abort condition if allowed to continue, such as when simulated by
>> a UTM.
>>
>>> (a) conditional branch or
>>> (b) indexed jump instructions (where the index can vary)
>>>> The outer H is unable to detect that the inner H will do exactly
>>>> what the outer H does,
>>> None of this could possibly show that the simulated P ever reaches its
>>> "ret" instruction, thus is irrelevant.
>>>
>>> We are not asking:
>>> [A] Does P stop running?
>>
>> We are by the definition of the problem:  does an algorithm exist that
>> can detect if *any* arbitrary algorithm will halt when given a
>> particular input.
>
> No not at all this is false.
> A halt decider must only compute the mapping of its input to an accept
> or reject state based on the actual behavior specified by this input.