On 5/28/2022 12:05 PM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 12:58:31 PM UTC-4, olcott wrote:
>> On 5/28/2022 11:37 AM, Dennis Bush wrote:
>>> 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.
>>>
>>> Which by the problem definition is the behavior of Pa(Pa)
>> Ah so you disagree with the definition of a decider.
>
> A halt decider, by definition, maps the halting function. The halting function includes the following mappings:
>
> N(5) -> halting
> Pa(Pa) -> halting
> P1(P1), where P1 calls H1 -> halting
> Pn(Pn) -> non-halting
>
> Can you claim that Ha maps this function? If not, it is not a halt decider.
>
>>>>
>>>> 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) simulating to a final state and returning 1.
>> Ah so you are saying that the behavior of sequences of configurations
>> that are provably not equivalent
>
> You've made no such proof. You've only claimed that they are different because Ha is unable to simulate Pa(Pa) to completion.

On Saturday, May 28, 2022 at 1:10:12 PM UTC-4, olcott wrote:
> On 5/28/2022 11:43 AM, Dennis Bush wrote:
> > 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,
> >
> > FALSE
> >
> >> Which one do you disagree with?
> >>
> >> 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.
> >
> > And by the problem definition the actual behavior specified by the input is the behavior of Pa(Pa)
> In other words you fundamentally disagree with the x86 language.
> It is the case that the correct x86 emulation of the input to H(P,P) by
> H

On 5/28/22 1:15 PM, olcott wrote:
> On 5/28/2022 12:05 PM, Dennis Bush wrote:
>> On Saturday, May 28, 2022 at 12:58:31 PM UTC-4, olcott wrote:
>>> On 5/28/2022 11:37 AM, Dennis Bush wrote:
>>>> 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.
>>>>
>>>> Which by the problem definition is the behavior of Pa(Pa)
>>> Ah so you disagree with the definition of a decider.
>>
>> A halt decider, by definition, maps the halting function.  The halting
>> function includes the following mappings:
>>
>> N(5) -> halting
>> Pa(Pa) -> halting
>> P1(P1), where P1 calls H1 -> halting
>> Pn(Pn) -> non-halting
>>
>> Can you claim that Ha maps this function?  If not, it is not a halt
>> decider.
>>
>>>>>
>>>>> 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) simulating to a final state and returning 1.
>>> Ah so you are saying that the behavior of sequences of configurations
>>> that are provably not equivalent
>>
>> You've made no such proof.  You've only claimed that they are
>> different because Ha is unable to simulate Pa(Pa) to completion.
>
> I proved that H(P,P)==0 and H1(P,P)==1 therefore I have proved that the
> correct x86 emulation of the input to H(P,P) is not equivalent to the
> direct execution of P(P).
>
> It seems that most of your fake rebuttals are based on simply ignoring
> when I correctly point out your mistakes.
>

On Saturday, May 28, 2022 at 1:15:42 PM UTC-4, olcott wrote:
> On 5/28/2022 12:05 PM, Dennis Bush wrote:
> > On Saturday, May 28, 2022 at 12:58:31 PM UTC-4, olcott wrote:
> >> On 5/28/2022 11:37 AM, Dennis Bush wrote:
> >>> 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..
> >>>
> >>> Which by the problem definition is the behavior of Pa(Pa)
> >> Ah so you disagree with the definition of a decider.
> >
> > A halt decider, by definition, maps the halting function. The halting function includes the following mappings:
> >
> > N(5) -> halting
> > Pa(Pa) -> halting
> > P1(P1), where P1 calls H1 -> halting
> > Pn(Pn) -> non-halting
> >
> > Can you claim that Ha maps this function? If not, it is not a halt decider.
> >
> >>>>
> >>>> 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) simulating to a final state and returning 1.
> >> Ah so you are saying that the behavior of sequences of configurations
> >> that are provably not equivalent
> >
> > You've made no such proof. You've only claimed that they are different because Ha is unable to simulate Pa(Pa) to completion.
> I proved that H(P,P)==0 and H1(P,P)==1

On 5/28/2022 12:17 PM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 1:10:12 PM UTC-4, olcott wrote:
>> On 5/28/2022 11:43 AM, Dennis Bush wrote:
>>> 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,
>>>
>>> FALSE
>>>
>>>> Which one do you disagree with?
>>>>
>>>> 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.
>>>
>>> And by the problem definition the actual behavior specified by the input is the behavior of Pa(Pa)
>> In other words you fundamentally disagree with the x86 language.
>> It is the case that the correct x86 emulation of the input to H(P,P) by
>> H
>
> Which is does not do. As previously proved, Ha is unable to take into account that the Ha embedded in Pa will do exactly what the outer Ha will do.

On 5/28/2022 12:22 PM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 1:15:42 PM UTC-4, olcott wrote:
>> On 5/28/2022 12:05 PM, Dennis Bush wrote:
>>> On Saturday, May 28, 2022 at 12:58:31 PM UTC-4, olcott wrote:
>>>> On 5/28/2022 11:37 AM, Dennis Bush wrote:
>>>>> 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.
>>>>>
>>>>> Which by the problem definition is the behavior of Pa(Pa)
>>>> Ah so you disagree with the definition of a decider.
>>>
>>> A halt decider, by definition, maps the halting function. The halting function includes the following mappings:
>>>
>>> N(5) -> halting
>>> Pa(Pa) -> halting
>>> P1(P1), where P1 calls H1 -> halting
>>> Pn(Pn) -> non-halting
>>>
>>> Can you claim that Ha maps this function? If not, it is not a halt decider.
>>>
>>>>>>
>>>>>> 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) simulating to a final state and returning 1.
>>>> Ah so you are saying that the behavior of sequences of configurations
>>>> that are provably not equivalent
>>>
>>> You've made no such proof. You've only claimed that they are different because Ha is unable to simulate Pa(Pa) to completion.
>> I proved that H(P,P)==0 and H1(P,P)==1
>
> FALSE. You've only shown that Ha is unable to see that the copy of Ha embedded in Pa will abort if allowed to continue as H1(Pa,Pa) demonstrates.

On 5/28/22 1:29 PM, olcott wrote:
> On 5/28/2022 12:17 PM, Dennis Bush wrote:
>> On Saturday, May 28, 2022 at 1:10:12 PM UTC-4, olcott wrote:
>>> On 5/28/2022 11:43 AM, Dennis Bush wrote:
>>>> 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,
>>>>
>>>> FALSE
>>>>
>>>>> Which one do you disagree with?
>>>>>
>>>>> 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.
>>>>
>>>> And by the problem definition the actual behavior specified by the
>>>> input is the behavior of Pa(Pa)
>>> In other words you fundamentally disagree with the x86 language.
>>> It is the case that the correct x86 emulation of the input to H(P,P) by
>>> H
>>
>> Which is does not do.  As previously proved, Ha is unable to take into
>> account that the Ha embedded in Pa will do exactly what the outer Ha
>> will do.
>
> I pointed out your error many times before.
>
> When brain dead morons make sure to always ignore my corrections to
> their error I repeat their error many times so that when they ignore it
> again they look foolish.
>
> H is only determining whether or not its correct x86 emulation of its
> input would ever reach the "ret" instruction of this input.
>
> H is only determining whether or not its correct x86 emulation of its
> input would ever reach the "ret" instruction of this input.
>
> H is only determining whether or not its correct x86 emulation of its
> input would ever reach the "ret" instruction of this input.
>
> H is only determining whether or not its correct x86 emulation of its
> input would ever reach the "ret" instruction of this input.
>
>>> would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
>>> proved to be correct.
>>>
>>>>
>>>>> It is the case that the correct x86 emulation of the input to
>>>>> H(P,P) by
>>>>> H
>>>>
>>>> Correct emulation only correct in your head. As previously proved,
>>>> Ha is unable to take into account that the Ha embedded in Pa will do
>>>> exactly what the outer Ha will do.
>>> So you say that even though it has been proved
>>
>> FALSE.  As previously proved, Ha is unable to take into account that
>> the Ha embedded in Pa will do exactly what the outer Ha will do.
>
> THIS DOES NOT MAKE ANY DIFFERENCE
> THIS DOES NOT MAKE ANY DIFFERENCE
> THIS DOES NOT MAKE ANY DIFFERENCE
> THIS DOES NOT MAKE ANY DIFFERENCE
> THIS DOES NOT MAKE ANY DIFFERENCE

On 5/28/22 1:33 PM, olcott wrote:
> On 5/28/2022 12:22 PM, Dennis Bush wrote:
>> On Saturday, May 28, 2022 at 1:15:42 PM UTC-4, olcott wrote:
>>> On 5/28/2022 12:05 PM, Dennis Bush wrote:
>>>> On Saturday, May 28, 2022 at 12:58:31 PM UTC-4, olcott wrote:
>>>>> On 5/28/2022 11:37 AM, Dennis Bush wrote:
>>>>>> 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.
>>>>>>
>>>>>> Which by the problem definition is the behavior of Pa(Pa)
>>>>> Ah so you disagree with the definition of a decider.
>>>>
>>>> A halt decider, by definition, maps the halting function. The
>>>> halting function includes the following mappings:
>>>>
>>>> N(5) -> halting
>>>> Pa(Pa) -> halting
>>>> P1(P1), where P1 calls H1 -> halting
>>>> Pn(Pn) -> non-halting
>>>>
>>>> Can you claim that Ha maps this function? If not, it is not a halt
>>>> decider.
>>>>
>>>>>>>
>>>>>>> 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) simulating to a final state and returning 1.
>>>>> Ah so you are saying that the behavior of sequences of configurations
>>>>> that are provably not equivalent
>>>>
>>>> You've made no such proof. You've only claimed that they are
>>>> different because Ha is unable to simulate Pa(Pa) to completion.
>>> I proved that H(P,P)==0 and H1(P,P)==1
>>
>> FALSE.  You've only shown that Ha is unable to see that the copy of Ha
>> embedded in Pa will abort if allowed to continue as H1(Pa,Pa)
>> demonstrates.
>
> If I am wrong then that means that you can show that the correct x86
> emulation of the input to H(P,P) does reach its final "ret" instruction
> even though the provably correct execution trace of the provable correct
> x86 emulation of the input to H(P,P) conclusively proves otherwise.
>
>
Like

On 5/28/2022 12:46 PM, Richard Damon wrote:
> On 5/28/22 1:33 PM, olcott wrote:
>> On 5/28/2022 12:22 PM, Dennis Bush wrote:
>>> On Saturday, May 28, 2022 at 1:15:42 PM UTC-4, olcott wrote:
>>>> On 5/28/2022 12:05 PM, Dennis Bush wrote:
>>>>> On Saturday, May 28, 2022 at 12:58:31 PM UTC-4, olcott wrote:
>>>>>> On 5/28/2022 11:37 AM, Dennis Bush wrote:
>>>>>>> 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.
>>>>>>>
>>>>>>> Which by the problem definition is the behavior of Pa(Pa)
>>>>>> Ah so you disagree with the definition of a decider.
>>>>>
>>>>> A halt decider, by definition, maps the halting function. The
>>>>> halting function includes the following mappings:
>>>>>
>>>>> N(5) -> halting
>>>>> Pa(Pa) -> halting
>>>>> P1(P1), where P1 calls H1 -> halting
>>>>> Pn(Pn) -> non-halting
>>>>>
>>>>> Can you claim that Ha maps this function? If not, it is not a halt
>>>>> decider.
>>>>>
>>>>>>>>
>>>>>>>> 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) simulating to a final state and
>>>>>>> returning 1.
>>>>>> Ah so you are saying that the behavior of sequences of configurations
>>>>>> that are provably not equivalent
>>>>>
>>>>> You've made no such proof. You've only claimed that they are
>>>>> different because Ha is unable to simulate Pa(Pa) to completion.
>>>> I proved that H(P,P)==0 and H1(P,P)==1
>>>
>>> FALSE.  You've only shown that Ha is unable to see that the copy of
>>> Ha embedded in Pa will abort if allowed to continue as H1(Pa,Pa)
>>> demonstrates.
>>
>> If I am wrong then that means that you can show that the correct x86
>> emulation of the input to H(P,P) does reach its final "ret"
>> instruction even though the provably correct execution trace of the
>> provable correct x86 emulation of the input to H(P,P) conclusively
>> proves otherwise.
>>
>>
> Like
>
> On 4/27/21 12:55 AM, olcott wrote:
> Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> > void H_Hat(u32 P)
> > {
> >  u32 Input_Halts = Halts(P, P);
> >  if (Input_Halts)
> >    HERE: goto HERE;
> > }
> >
> >
> > int main()
> > {
> >  H_Hat((u32)H_Hat);
> > }
> >
> >
> > _H_Hat()
> > [00000b98](01)  55                      push ebp
> > [00000b99](02)  8bec                    mov ebp,esp
> >
> [00000b9b](01)  51                      push ecx
> > [00000b9c](03)  8b4508                  mov eax,[ebp+08]
> > [00000b9f](01)  50                      push eax
> > [00000ba0](03)  8b4d08                  mov ecx,[ebp+08]
> > [00000ba3](01)  51                      push ecx
> > [00000ba4](05)  e88ffdffff              call 00000938
> > [00000ba9](03)  83c408                  add esp,+08
> > [00000bac](03)  8945fc                  mov [ebp-04],eax
> > [00000baf](04)  837dfc00                cmp dword [ebp-04],+00
> > [00000bb3](02)  7402                    jz 00000bb7
> > [00000bb5](02)  ebfe                    jmp 00000bb5
> > [00000bb7](02)  8be5                    mov esp,ebp
> > [00000bb9](01)  5d                      pop ebp
> > [00000bba](01)  c3                      ret
> > Size in bytes:(0035) [00000bba]
> >
> > _main()
> > [00000bc8](01)  55                      push ebp
> > [00000bc9](02)  8bec                    mov ebp,esp
> > [00000bcb](05)  68980b0000          push 00000b98
> > [00000bd0](05)  e8c3ffffff              call 00000b98
> > [00000bd5](03)  83c404                  add esp,+04
> > [00000bd8](02)  33c0                    xor eax,eax
> > [00000bda](01)  5d                      pop ebp
> > [00000bdb](01)  c3                      ret
> > Size in bytes:(0020) [00000bdb]
> >
> > ===============================
> > ...[00000bc8][001015d4][00000000](01)  55         push ebp
> > ...[00000bc9][001015d4][00000000](02)  8bec       mov ebp,esp
> > ...[00000bcb][001015d0][00000b98](05)  68980b0000 push 00000b98
> > ...[00000bd0][001015cc][00000bd5](05)  e8c3ffffff call 00000b98
> > ...[00000b98][001015c8][001015d4](01)  55         push ebp
> > ...[00000b99][001015c8][001015d4](02)  8bec       mov ebp,esp
> > ...[00000b9b][001015c4][00000000](01)  51         push ecx
> > ...[00000b9c][001015c4][00000000](03)  8b4508     mov  eax,[ebp+08]
> > ...[00000b9f][001015c0][00000b98](01)  50         push eax
> > ...[00000ba0][001015c0][00000b98](03)  8b4d08     mov ecx,[ebp+08]
> > ...[00000ba3][001015bc][00000b98](01)  51         push ecx
> > ...[00000ba4][001015b8][00000ba9](05)  e88ffdffff call 00000938
> > Begin Local Halt Decider Simulation at Machine Address:b98
> > ...[00000b98][00211674][00211678](01)  55         push ebp
> > ...[00000b99][00211674][00211678](02)  8bec       mov ebp,esp
> > ...[00000b9b][00211670][00201644](01)  51         push ecx
> > ...[00000b9c][00211670][00201644](03)  8b4508     mov eax,[ebp+08]
> > ...[00000b9f][0021166c][00000b98](01)  50         push eax
> > ...[00000ba0][0021166c][00000b98](03)  8b4d08     mov ecx,[ebp+08]
> > ...[00000ba3][00211668][00000b98](01)  51         push ecx
> > ...[00000ba4][00211664][00000ba9](05)  e88ffdffff call 00000938
> > ...[00000b98][0025c09c][0025c0a0](01)  55         push ebp
> > ...[00000b99][0025c09c][0025c0a0](02)  8bec       mov ebp,esp
> > ...[00000b9b][0025c098][0024c06c](01)  51         push ecx
> > ...[00000b9c][0025c098][0024c06c](03)  8b4508     mov eax,[ebp+08]
> > ...[00000b9f][0025c094][00000b98](01)  50         push eax
> > ...[00000ba0][0025c094][00000b98](03)  8b4d08     mov ecx,[ebp+08]
> > ...[00000ba3][0025c090][00000b98](01)  51         push ecx
> > ...[00000ba4][0025c08c][00000ba9](05)  e88ffdffff call 00000938
> > Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> Above decision was from the call the Halts inside H_Hat, deciding that
> H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
> processed below:
>
> > ...[00000ba9][001015c4][00000000](03)  83c408     add esp,+08
> > ...[00000bac][001015c4][00000000](03)  8945fc     mov [ebp-04],eax
> > ...[00000baf][001015c4][00000000](04)  837dfc00   cmp dword [ebp-04],+00
> > ...[00000bb3][001015c4][00000000](02)  7402       jz 00000bb7
> > ...[00000bb7][001015c8][001015d4](02)  8be5       mov esp,ebp
> > ...[00000bb9][001015cc][00000bd5](01)  5d         pop ebp
> > ...[00000bba][001015d0][00000b98](01)  c3         ret
> > ...[00000bd5][001015d4][00000000](03)  83c404     add esp,+04
> > ...[00000bd8][001015d4][00000000](02)  33c0       xor eax,eax
> > ...[00000bda][001015d8][00100000](01)  5d         pop ebp
> > ...[00000bdb][001015dc][00000098](01)  c3         ret
>
> SEE IT HALTED!
>
> > Number_of_User_Instructions(39)
> > Number of Instructions Executed(26567)
>

On 2022-05-28 10:24, olcott wrote:
> On 5/28/2022 11:06 AM, Dennis Bush wrote:

>> And since the computation that H(P,P) is deciding on *by definition*
>> is P(P), and the computation P(P) completes, H is incorrect to abort
>> and return 0.
>
> A halt decider must only compute the mapping of its input to an accept
> or reject state based on the actual behavior specified by this input.

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

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 5/28/2022 1:10 PM, André G. Isaak wrote:
> On 2022-05-28 10:24, olcott wrote:
>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>
>>> And since the computation that H(P,P) is deciding on *by definition*
>>> is P(P), and the computation P(P) completes, H is incorrect to abort
>>> and return 0.
>>
>> A halt decider must only compute the mapping of its input to an accept
>> or reject state based on the actual behavior specified by this input.
>
> And what exactly is the above supposed to mean? You still haven't
> provided a coherent definition of what you mean by 'specified'. What
> does it mean for an input string to specify a behaviour?
>
> André
>

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

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

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

--
Copyright 2022 Pete Olcott

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

On 2022-05-28 12:26, olcott wrote:
> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>> On 2022-05-28 10:24, olcott wrote:
>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>
>>>> And since the computation that H(P,P) is deciding on *by definition*
>>>> is P(P), and the computation P(P) completes, H is incorrect to abort
>>>> and return 0.
>>>
>>> A halt decider must only compute the mapping of its input to an
>>> accept or reject state based on the actual behavior specified by this
>>> input.
>>
>> And what exactly is the above supposed to mean? You still haven't
>> provided a coherent definition of what you mean by 'specified'. What
>> does it mean for an input string to specify a behaviour?
>>
>> André
>>
>
> In other words when I prove what I mean by "specified" 100 times the
> fact that you always make sure to ignore what I said is equivalent to me
> having never said anything about it.

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

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

And how exactly do you define 'correct x86 emulation'? given that you
don't require the correct emulation of a program to match the actual
behaviour of that program when run independently you clearly mean
something different from everyone else, but you've never explained which
criteria you use to decide whether a given emulation is correct.

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

No, it does not. A proof requires premises and some demonstration that
the conclusion follows from those premises based on accepted rules of
inference.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On Saturday, May 28, 2022 at 2:26:33 PM UTC-4, olcott wrote:
> On 5/28/2022 1:10 PM, André G. Isaak wrote:
> > On 2022-05-28 10:24, olcott wrote:
> >> On 5/28/2022 11:06 AM, Dennis Bush wrote:
> >
> >>> And since the computation that H(P,P) is deciding on *by definition*
> >>> is P(P), and the computation P(P) completes, H is incorrect to abort
> >>> and return 0.
> >>
> >> A halt decider must only compute the mapping of its input to an accept
> >> or reject state based on the actual behavior specified by this input.
> >
> > And what exactly is the above supposed to mean? You still haven't
> > provided a coherent definition of what you mean by 'specified'. What
> > does it mean for an input string to specify a behaviour?
> >
> > André
> >
> In other words when I prove what I mean by "specified" 100 times the
> fact that you always make sure to ignore what I said is equivalent to me
> having never said anything about it.
>
> The behavior specified by an input is the execution trace derived by the
> correct x86 emulation of this input by its simulating halt decider.

In other words, to prove that a decider is correct, you have to start by assuming it performed a correct simulation.

INVALID, as you're assuming your conclusion.

So we're left with the actual definition of a correct simulation, which is to match the behavior of the machine it is simulating.

So for Ha(Pa,Pa), a correct simulation would match the behavior of Pa(Pa). It does not, so Ha(Pa,Pa)==0 is wrong.

>
> This proves that H(P,P)==0 and H1(P,P)==1.
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

On 5/28/2022 1:38 PM, André G. Isaak wrote:
> On 2022-05-28 12:26, olcott wrote:
>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>> On 2022-05-28 10:24, olcott wrote:
>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>
>>>>> And since the computation that H(P,P) is deciding on *by
>>>>> definition* is P(P), and the computation P(P) completes, H is
>>>>> incorrect to abort and return 0.
>>>>
>>>> A halt decider must only compute the mapping of its input to an
>>>> accept or reject state based on the actual behavior specified by
>>>> this input.
>>>
>>> And what exactly is the above supposed to mean? You still haven't
>>> provided a coherent definition of what you mean by 'specified'. What
>>> does it mean for an input string to specify a behaviour?
>>>
>>> André
>>>
>>
>> In other words when I prove what I mean by "specified" 100 times the
>> fact that you always make sure to ignore what I said is equivalent to
>> me having never said anything about it.
>
> You can't "prove" what you mean by something. You define what something
> is intended to mean. And so far you haven't provided a definition for
> 'specify'. When asked you've either hurled insults or given strange
> analogies involving milkshakes.
>
>> The behavior specified by an input is the execution trace derived by
>> the correct x86 emulation of this input by its simulating halt decider.
>
> And how exactly do you define 'correct x86 emulation'?

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

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

The x86 emulation of the input to H(P,P) is proven to be correct when it
corresponds to the behavior specified by the above code.

If (for example) the above code specifies "push ebp" and the x86
emulator emulates "push ebp" then the emulation of this instruction is
correct.

If (for example) the above code specifies "push ebp" and the x86
emulator emulates "push ecx" then the emulation of this instruction is
incorrect.

int sum(int x, int y)
{ return x + y;
}

It is like you don't understand that sum(3,4) must return 7.

> given that you
> don't require the correct emulation of a program to match the actual
> behaviour of that program when run independently you clearly mean
> something different from everyone else, but you've never explained which
> criteria you use to decide whether a given emulation is correct.
>
>> This proves that H(P,P)==0 and H1(P,P)==1.
>
> No, it does not. A proof requires premises and some demonstration that
> the conclusion follows from those premises based on accepted rules of
> inference.
>
> André
>

--
Copyright 2022 Pete Olcott

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

On 5/28/2022 1:41 PM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 2:26:33 PM UTC-4, olcott wrote:
>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>> On 2022-05-28 10:24, olcott wrote:
>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>
>>>>> And since the computation that H(P,P) is deciding on *by definition*
>>>>> is P(P), and the computation P(P) completes, H is incorrect to abort
>>>>> and return 0.
>>>>
>>>> A halt decider must only compute the mapping of its input to an accept
>>>> or reject state based on the actual behavior specified by this input.
>>>
>>> And what exactly is the above supposed to mean? You still haven't
>>> provided a coherent definition of what you mean by 'specified'. What
>>> does it mean for an input string to specify a behaviour?
>>>
>>> André
>>>
>> In other words when I prove what I mean by "specified" 100 times the
>> fact that you always make sure to ignore what I said is equivalent to me
>> having never said anything about it.
>>
>> The behavior specified by an input is the execution trace derived by the
>> correct x86 emulation of this input by its simulating halt decider.
>
> In other words, to prove that a decider is correct, you have to start by assuming it performed a correct simulation.

We hypothesize that H(P,P) is performing a correct x86 emulation of its
input and then verify that the execution trace of the input to H(P,P)
matches what the x86 source-code of P specifies.

Since I have told you this many many times you must be dishonest in that
you never noticed that I said this once.

>
> INVALID, as you're assuming your conclusion.
>
> So we're left with the actual definition of a correct simulation, which is to match the behavior of the machine it is simulating.
>
> So for Ha(Pa,Pa), a correct simulation would match the behavior of Pa(Pa). It does not, so Ha(Pa,Pa)==0 is wrong.
>
>
>>
>> This proves that H(P,P)==0 and H1(P,P)==1.
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer

--
Copyright 2022 Pete Olcott

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