On 8/20/2022 8:48 PM, Richard Damon wrote:
> On 8/20/22 9:45 PM, olcott wrote:
>> On 8/20/2022 8:07 PM, Richard Damon wrote:
>>> On 8/20/22 8:14 PM, olcott wrote:
>>>> On 8/20/2022 6:42 PM, Richard Damon wrote:
>>>>> On 8/20/22 7:28 PM, olcott wrote:
>>>>>> On 8/20/2022 5:59 PM, Richard Damon wrote:
>>>>>>> On 8/20/22 6:33 PM, olcott wrote:
>>>>>>>> On 8/20/2022 4:59 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 8/20/22 5:29 PM, olcott wrote:
>>>>>>>>>> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 8/20/22 5:13 PM, olcott wrote:
>>>>>>>>>>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>>>>>>>>>>> Olcott, which of the following do you think is
>>>>>>>>>>>>>>>>>>>>>> more likely?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Which one is more likely hasn't changed for all
>>>>>>>>>>>>>>>>>>>>>> the years you've
>>>>>>>>>>>>>>>>>>>>>> been attempting to shill your simulating halting
>>>>>>>>>>>>>>>>>>>>>> decider. I find
>>>>>>>>>>>>>>>>>>>>>> it amusing that I came up with, in less than 24
>>>>>>>>>>>>>>>>>>>>>> hours, a
>>>>>>>>>>>>>>>>>>>>>> simulating halting decider that doesn't have the
>>>>>>>>>>>>>>>>>>>>>> flaws your SHD
>>>>>>>>>>>>>>>>>>>>>> has.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I have been following these discussions for many
>>>>>>>>>>>>>>>>>>>>> months now. I
>>>>>>>>>>>>>>>>>>>>> have a strong impression that there is little
>>>>>>>>>>>>>>>>>>>>> progress. It seems
>>>>>>>>>>>>>>>>>>>>> that people are running in circles. I am not an
>>>>>>>>>>>>>>>>>>>>> expert in this
>>>>>>>>>>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to
>>>>>>>>>>>>>>>>>>>>> summarize the
>>>>>>>>>>>>>>>>>>>>> discussion. Please, be patient when correcting me
>>>>>>>>>>>>>>>>>>>>> if I make any
>>>>>>>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>>>>>>>>>>> In computation theory we can denote a program with
>>>>>>>>>>>>>>>>>>>>> X and its input
>>>>>>>>>>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may
>>>>>>>>>>>>>>>>>>>>> end (halt) in
>>>>>>>>>>>>>>>>>>>>> a finite number of steps, but another program X
>>>>>>>>>>>>>>>>>>>>> and/or input Y may
>>>>>>>>>>>>>>>>>>>>> not halt in a finite number of steps. The question
>>>>>>>>>>>>>>>>>>>>> is, is it
>>>>>>>>>>>>>>>>>>>>> possible to create a program H that when given any
>>>>>>>>>>>>>>>>>>>>> program X with
>>>>>>>>>>>>>>>>>>>>> its input Y can tell in a finite number of steps
>>>>>>>>>>>>>>>>>>>>> whether X(Y)
>>>>>>>>>>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always
>>>>>>>>>>>>>>>>>>>>> halt after a
>>>>>>>>>>>>>>>>>>>>> finite number of steps with the correct answer for
>>>>>>>>>>>>>>>>>>>>> any X and Y?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I hope that this is a correct formulation of the
>>>>>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The classical proof that it is not possible is the
>>>>>>>>>>>>>>>>>>>>> idea that it is
>>>>>>>>>>>>>>>>>>>>> always possible to create a program P that uses H,
>>>>>>>>>>>>>>>>>>>>> with itself as
>>>>>>>>>>>>>>>>>>>>> input, but behaves opposite to what H returns. In a
>>>>>>>>>>>>>>>>>>>>> C-like
>>>>>>>>>>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If there would be a hypothetical non-simulating
>>>>>>>>>>>>>>>>>>>>> non-aborting H,
>>>>>>>>>>>>>>>>>>>>> which would always halts with the correct answer,
>>>>>>>>>>>>>>>>>>>>> then it is clear
>>>>>>>>>>>>>>>>>>>>> that there would be a contradiction if we ask H
>>>>>>>>>>>>>>>>>>>>> about P with
>>>>>>>>>>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>>>>>>>>>>> 1. If H would return true (halting) in a finite
>>>>>>>>>>>>>>>>>>>>> number of steps,
>>>>>>>>>>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does
>>>>>>>>>>>>>>>>>>>>> not halt in a
>>>>>>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>>>>>>> 2. If H would return false (non-halting) in a
>>>>>>>>>>>>>>>>>>>>> finite number of
>>>>>>>>>>>>>>>>>>>>> steps, then P returns immediately, so H returns a
>>>>>>>>>>>>>>>>>>>>> wrong result.
>>>>>>>>>>>>>>>>>>>>> 3. If H does not return, then it does not return in
>>>>>>>>>>>>>>>>>>>>> a finite
>>>>>>>>>>>>>>>>>>>>> number of steps, so it is not the H where the
>>>>>>>>>>>>>>>>>>>>> problem asked for.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Now Olcott has created a simulating aborting H,
>>>>>>>>>>>>>>>>>>>>> which, when given
>>>>>>>>>>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>>>>>>>>>>>> execution and
>>>>>>>>>>>>>>>>>>>>> at the point where P calls H, it uses the following
>>>>>>>>>>>>>>>>>>>>> logic: If H
>>>>>>>>>>>>>>>>>>>>> were the hypothetical non-aborting H, then an
>>>>>>>>>>>>>>>>>>>>> infinite recursion
>>>>>>>>>>>>>>>>>>>>> would happen at this point. Therefore, Olcott's
>>>>>>>>>>>>>>>>>>>>> simulating H
>>>>>>>>>>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>>>>>>>>>>> Olcott thinks that his H gives the correct answer
>>>>>>>>>>>>>>>>>>>>> that P would not
>>>>>>>>>>>>>>>>>>>>> halt when P would call the hypothetical
>>>>>>>>>>>>>>>>>>>>> non-aborting H, so, it
>>>>>>>>>>>>>>>>>>>>> must also be the correct answer when P actually
>>>>>>>>>>>>>>>>>>>>> calls the actual
>>>>>>>>>>>>>>>>>>>>> aborting H.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>>>>>>>>>>> The key nuance of divergence is that halting means
>>>>>>>>>>>>>>>>>>>> that when H(P,P)
>>>>>>>>>>>>>>>>>>>> correctly simulates its input that this input would
>>>>>>>>>>>>>>>>>>>> reach the
>>>>>>>>>>>>>>>>>>>> "return" instruction (final state) of P. H(P,P)
>>>>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>>>>> determines that its correct simulation of its input
>>>>>>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *computation that halts* … the Turing machine will
>>>>>>>>>>>>>>>>>>>> halt whenever it
>>>>>>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal
>>>>>>>>>>>>>>>>>>>> Languages and Automata.
>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When-so-ever the correct partial simulation of a
>>>>>>>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>>>>>>>> description correctly matches a correct infinite
>>>>>>>>>>>>>>>>>>>> behavior pattern
>>>>>>>>>>>>>>>>>>>> then it is certain that this machine description
>>>>>>>>>>>>>>>>>>>> specifies
>>>>>>>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In other words the SHD decider correctly predicts
>>>>>>>>>>>>>>>>>>>> that its correct
>>>>>>>>>>>>>>>>>>>> and complete simulation of its input would never
>>>>>>>>>>>>>>>>>>>> reach the final
>>>>>>>>>>>>>>>>>>>> state of this input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Px always halts if H returns to Px (and a valid halt
>>>>>>>>>>>>>>>>>>> decider must
>>>>>>>>>>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This one uses my prior version of H named HH where the
>>>>>>>>>>>>>>>>>> infinitely
>>>>>>>>>>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _Px()
>>>>>>>>>>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>>>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>>>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>>>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>>>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>>>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>>>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>>>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>>>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>>>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>>>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>>>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>>>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>>>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>>>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>>>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>>>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>>>>>>>>>>    address   address   data      code       language
>>>>>>>>>>>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>>>>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>>>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>>>>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push
>>>>>>>>>>>>>>>>>> 000010b2
>>>>>>>>>>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push
>>>>>>>>>>>>>>>>>> 000010b2
>>>>>>>>>>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call
>>>>>>>>>>>>>>>>>> 00000ca2
>>>>>>>>>>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>>>>>>> Stored at:111c39
>>>>>>>>>>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>>>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>>>>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov
>>>>>>>>>>>>>>>>>> eax,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax
>>>>>>>>>>>>>>>>>> // push
>>>>>>>>>>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov
>>>>>>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx
>>>>>>>>>>>>>>>>>> // push
>>>>>>>>>>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call
>>>>>>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>>>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>>>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>>>>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov
>>>>>>>>>>>>>>>>>> eax,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax
>>>>>>>>>>>>>>>>>> // push
>>>>>>>>>>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov
>>>>>>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx
>>>>>>>>>>>>>>>>>> // push
>>>>>>>>>>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call
>>>>>>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion
>>>>>>>>>>>>>>>>>> Detected Simulation
>>>>>>>>>>>>>>>>>> Stopped*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>>>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence
>>>>>>>>>>>>>>>>>> from the same
>>>>>>>>>>>>>>>>>> machine address of Px().
>>>>>>>>>>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>>>>>>>>>>> (3) With no control flow instructions between the
>>>>>>>>>>>>>>>>>> invocation of Px()
>>>>>>>>>>>>>>>>>> and its call to HH(Px,Px) that could possibly escape
>>>>>>>>>>>>>>>>>> repeated
>>>>>>>>>>>>>>>>>> simulations.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>>>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push
>>>>>>>>>>>>>>>>>> 00000463
>>>>>>>>>>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call
>>>>>>>>>>>>>>>>>> 00000482
>>>>>>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>>>>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>>>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>>>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> All your trace is doing is confirming that H gets the
>>>>>>>>>>>>>>>>> answer wrong, Px
>>>>>>>>>>>>>>>>> halts. Until you resolve this false positive you do not
>>>>>>>>>>>>>>>>> have a valid
>>>>>>>>>>>>>>>>> SHD.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    (void) HH(x, x);
>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because HH is a simulating halt decider (SHD) it
>>>>>>>>>>>>>>>> continues to perform a pure x86 emulation of its input
>>>>>>>>>>>>>>>> until it correctly matches a non-halting behavior
>>>>>>>>>>>>>>>> pattern proving that the simulated input would never
>>>>>>>>>>>>>>>> reach its own final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated
>>>>>>>>>>>>>>>> HH(Px,Px)
>>>>>>>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>> *Until HH aborts its simulation*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All those having sufficient software engineering
>>>>>>>>>>>>>>>> technical competence can see this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And the correct and complete simulation of the input to
>>>>>>>>>>>>>>> HH(Px,Px) is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>>>>>>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>>>>>>>>>>> (g) which returns, and thus Halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thus, the COMPLETE simulation of the input to HH, which
>>>>>>>>>>>>>>> we agree shows the actual behavior of the input to HH,
>>>>>>>>>>>>>>> comes to a Halt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This sequence of instructions provides the correct and
>>>>>>>>>>>>>> complete simulation of the input to H(P,P):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>     (void) Simulate(x, x);
>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You provide the pure simulation at the wrong point in the
>>>>>>>>>>>>>> execution trace. In any case even in your incorrect
>>>>>>>>>>>>>> execution trace the Px that HH simulates never reaches its
>>>>>>>>>>>>>> own final state, thus never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, because you changed P!
>>>>>>>>>>>>>
>>>>>>>>>>>>> P MUST be
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(void (*x)()) {
>>>>>>>>>>>>>     HH(x,x);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> As that is the P that was defined.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then have main be:
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main() {
>>>>>>>>>>>>>     // The original call to HH
>>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>>
>>>>>>>>>>>>>     // The test
>>>>>>>>>>>>>     Simulate(Px,Px);
>>>>>>>>>>>>>     Output("But Px(Px) Halts");
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> I.E just DO the correct and complete simulation of the
>>>>>>>>>>>>> input to HH.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is the plain meaning of the words.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Youy keep on trying to change the P that is the input to H
>>>>>>>>>>>>> to "prove" your answer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO
>>>>>>>>>>>> ERROR*
>>>>>>>>>>>
>>>>>>>>>>> I just did.
>>>>>>>>>>>
>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) correctly
>>>>>>>>>>>> performs a partial simulation of its input and the behavior
>>>>>>>>>>>> of this partial simulation correctly matches a non-halting
>>>>>>>>>>>> behavior pattern then the SHD halt decider can correctly
>>>>>>>>>>>> report non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>> A non-halting behavior pattern is correct when-so-ever
>>>>>>>>>>>> matching this behavior pattern proves that the correct and
>>>>>>>>>>>> complete simulation of the input by SHD would never reach
>>>>>>>>>>>> the final state of this simulated input.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I just showed you the error which you didn't bother even
>>>>>>>>>>> trying to refute, which is just proof that you don't have a
>>>>>>>>>>> clue how to attempt because you understand you are wrong.
>>>>>>>>>>>
>>>>>>>>>>> You are just proving you are a pathological liar, or totally
>>>>>>>>>>> utterly incompetent and stupid.
>>>>>>>>>>>
>>>>>>>>>>> FAIL.
>>>>>>>>>>
>>>>>>>>>> It is common knowledge that the correct and complete
>>>>>>>>>> simulation of a machine description always provides the actual
>>>>>>>>>> behavior specified by this machine description.
>>>>>>>>>
>>>>>>>>> Right
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Therefore the actual behavior of the actual input is what the
>>>>>>>>>> behavior of the input would be if the SHD performed a correct
>>>>>>>>>> and complete simulation of this input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No. Because the SHD was defined to NOT do a complete
>>>>>>>>> simulation, but to abort it. The "SHD that does a complete
>>>>>>>>> simulation" is a different function than the one deciding, so
>>>>>>>>> it isn't the one that P is calling, so its behavior is irrelvent.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The fact that the simulated input would never reach its own
>>>>>>>>>> final state in the above case conclusively proves that this
>>>>>>>>>> input specifies a non-halting sequence of instructions.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nope. Wrong Machine, The only machine that behaves that way
>>>>>>>>> doesn't answer.
>>>>>>>>>
>>>>>>>>> The fact that Simulate(Px,Px) does Halt for any HH that answers
>>>>>>>>> HH(Px,Px) proves that it is wrong to say non-halting.
>>>>>>>>>
>>>>>>>>> Simulate(Px,Px) is what you just references (if not by name) as
>>>>>>>>> the correct and complete simulation of the machine description
>>>>>>>>> that was given to HH.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You keep on having two different functions that you call H (or
>>>>>>>>> HH) that you conflate in your logic.
>>>>>>>>>
>>>>>>>>> It doesn't matter what H/HH would have done if different, it
>>>>>>>>> matters what the P does that calls the H/HH that you do have.
>>>>>>>>
>>>>>>>> (1) It is common knowledge that the correct and complete
>>>>>>>> simulation of a machine description always provides the actual
>>>>>>>> behavior specified by this machine description.
>>>>>>>>
>>>>>>>> (2) Therefore the actual behavior of the actual input is what
>>>>>>>> the behavior of the input would be if the SHD performed a
>>>>>>>> correct and complete simulation of this input.
>>>>>>>>
>>>>>>>
>>>>>>> Nope. Proves you are an idiot. Because the SHD DOES abort it
>>>>>>> simulation, there is no "If it didn't" case to look at.
>>>>>>>
>>>>>>> What is the results of program X doing operation Y if program X
>>>>>>> never actually does operation Y.
>>>>>>>
>>>>>>> It is an ill defined condition.
>>>>>>>
>>>>>>>> (3) The fact that the simulated input would never reach its own
>>>>>>>> final state in the above case conclusively proves that this
>>>>>>>> input specifies a non-halting sequence of instructions.
>>>>>>>>
>>>>>>>> Because (1) is known to be true and (2) logically follows from
>>>>>>>> (1) it is impossible to correctly accept (1) and deny (2).
>>>>>>>>
>>>>>>>
>>>>>>> If you want to try to express your words in a correct
>>>>>>> formulation, you could do the following.
>>>>>>>
>>>>>>> H is defined to take THREE parameters:
>>>>>>>
>>>>>>> P the program to decide on,
>>>>>>> d the data for that program, and
>>>>>>> s a flag that forces the decider to be a pure simulator and not a
>>>>>>> decider.
>>>>>>>
>>>>>>>
>>>>>>> THen
>>>>>>>
>>>>>>> H(P,d,0) is correct to return 1 if H(P,d,1) Halts, and
>>>>>>> H(P,d,0) is correct to return 0 if H(P,d,1) will never halt but
>>>>>>> run forever.
>>>>>>>
>>>>>>> P(x) is then defined to call H(x,x,0)
>>>>>>
>>>>>> *We could prove my point another way too*
>>>>>>
>>>>>> The simulating halt decider writes a 1 or a 0 to a specific tape
>>>>>> location that is initialized to blank. It does this as soon as it
>>>>>> correctly detects that its complete simulation would never stop
>>>>>> running.
>>>>>>
>>>>>> HERE IS THE KEY DIFFERENCE:
>>>>>> H continues to perform this complete simulation, thus never stops
>>>>>> running. Because it has reported this it is correct.
>>>>>>
>>>>>> The assumption that H must stop to report its decision is refuted.
>>>>>
>>>>>
>>>>> Nope, because H needs to stop to give the answer.
>>>>>
>>>>
>>>> That is needs to stop to give its answer
>>>> IS A FALSE ASSUMPTION.
>>>>
>>>> As soon as H knows the answer it writes a 1 or a 0 to a specific
>>>> tape location and then it keeps on running.
>>>>
>>>>
>>>
>>> Nope.
>>>
>>> Not how Turing Machine work.
>>>
>>
>> So you are saying that it is impossible for a TM to write a binary
>> digit at the first element of its tape?
>>
>
> No, but it doesn't count as an answer until the machine stops.
>

On 8/20/22 9:50 PM, olcott wrote:
> On 8/20/2022 8:10 PM, Richard Damon wrote:
>> On 8/20/22 8:14 PM, olcott wrote:
>>> On 8/20/2022 6:42 PM, Richard Damon wrote:
>>>> On 8/20/22 7:28 PM, olcott wrote:
>>>>> On 8/20/2022 5:59 PM, Richard Damon wrote:
>>>>>> On 8/20/22 6:33 PM, olcott wrote:
>>>>>>> On 8/20/2022 4:59 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 8/20/22 5:29 PM, olcott wrote:
>>>>>>>>> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 8/20/22 5:13 PM, olcott wrote:
>>>>>>>>>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>>>>>>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>>>>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>>>>>>>>>> Olcott, which of the following do you think is more
>>>>>>>>>>>>>>>>>>>>> likely?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Which one is more likely hasn't changed for all the
>>>>>>>>>>>>>>>>>>>>> years you've
>>>>>>>>>>>>>>>>>>>>> been attempting to shill your simulating halting
>>>>>>>>>>>>>>>>>>>>> decider. I find
>>>>>>>>>>>>>>>>>>>>> it amusing that I came up with, in less than 24
>>>>>>>>>>>>>>>>>>>>> hours, a
>>>>>>>>>>>>>>>>>>>>> simulating halting decider that doesn't have the
>>>>>>>>>>>>>>>>>>>>> flaws your SHD
>>>>>>>>>>>>>>>>>>>>> has.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I have been following these discussions for many
>>>>>>>>>>>>>>>>>>>> months now. I
>>>>>>>>>>>>>>>>>>>> have a strong impression that there is little
>>>>>>>>>>>>>>>>>>>> progress. It seems
>>>>>>>>>>>>>>>>>>>> that people are running in circles. I am not an
>>>>>>>>>>>>>>>>>>>> expert in this
>>>>>>>>>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to
>>>>>>>>>>>>>>>>>>>> summarize the
>>>>>>>>>>>>>>>>>>>> discussion. Please, be patient when correcting me if
>>>>>>>>>>>>>>>>>>>> I make any
>>>>>>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>>>>>>>>>> In computation theory we can denote a program with X
>>>>>>>>>>>>>>>>>>>> and its input
>>>>>>>>>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may
>>>>>>>>>>>>>>>>>>>> end (halt) in
>>>>>>>>>>>>>>>>>>>> a finite number of steps, but another program X
>>>>>>>>>>>>>>>>>>>> and/or input Y may
>>>>>>>>>>>>>>>>>>>> not halt in a finite number of steps. The question
>>>>>>>>>>>>>>>>>>>> is, is it
>>>>>>>>>>>>>>>>>>>> possible to create a program H that when given any
>>>>>>>>>>>>>>>>>>>> program X with
>>>>>>>>>>>>>>>>>>>> its input Y can tell in a finite number of steps
>>>>>>>>>>>>>>>>>>>> whether X(Y)
>>>>>>>>>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always
>>>>>>>>>>>>>>>>>>>> halt after a
>>>>>>>>>>>>>>>>>>>> finite number of steps with the correct answer for
>>>>>>>>>>>>>>>>>>>> any X and Y?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I hope that this is a correct formulation of the
>>>>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The classical proof that it is not possible is the
>>>>>>>>>>>>>>>>>>>> idea that it is
>>>>>>>>>>>>>>>>>>>> always possible to create a program P that uses H,
>>>>>>>>>>>>>>>>>>>> with itself as
>>>>>>>>>>>>>>>>>>>> input, but behaves opposite to what H returns. In a
>>>>>>>>>>>>>>>>>>>> C-like
>>>>>>>>>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If there would be a hypothetical non-simulating
>>>>>>>>>>>>>>>>>>>> non-aborting H,
>>>>>>>>>>>>>>>>>>>> which would always halts with the correct answer,
>>>>>>>>>>>>>>>>>>>> then it is clear
>>>>>>>>>>>>>>>>>>>> that there would be a contradiction if we ask H
>>>>>>>>>>>>>>>>>>>> about P with
>>>>>>>>>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>>>>>>>>>> 1. If H would return true (halting) in a finite
>>>>>>>>>>>>>>>>>>>> number of steps,
>>>>>>>>>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does
>>>>>>>>>>>>>>>>>>>> not halt in a
>>>>>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>>>>>> 2. If H would return false (non-halting) in a finite
>>>>>>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>>>>>>> steps, then P returns immediately, so H returns a
>>>>>>>>>>>>>>>>>>>> wrong result.
>>>>>>>>>>>>>>>>>>>> 3. If H does not return, then it does not return in
>>>>>>>>>>>>>>>>>>>> a finite
>>>>>>>>>>>>>>>>>>>> number of steps, so it is not the H where the
>>>>>>>>>>>>>>>>>>>> problem asked for.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Now Olcott has created a simulating aborting H,
>>>>>>>>>>>>>>>>>>>> which, when given
>>>>>>>>>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>>>>>>>>>>> execution and
>>>>>>>>>>>>>>>>>>>> at the point where P calls H, it uses the following
>>>>>>>>>>>>>>>>>>>> logic: If H
>>>>>>>>>>>>>>>>>>>> were the hypothetical non-aborting H, then an
>>>>>>>>>>>>>>>>>>>> infinite recursion
>>>>>>>>>>>>>>>>>>>> would happen at this point. Therefore, Olcott's
>>>>>>>>>>>>>>>>>>>> simulating H
>>>>>>>>>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>>>>>>>>>> Olcott thinks that his H gives the correct answer
>>>>>>>>>>>>>>>>>>>> that P would not
>>>>>>>>>>>>>>>>>>>> halt when P would call the hypothetical non-aborting
>>>>>>>>>>>>>>>>>>>> H, so, it
>>>>>>>>>>>>>>>>>>>> must also be the correct answer when P actually
>>>>>>>>>>>>>>>>>>>> calls the actual
>>>>>>>>>>>>>>>>>>>> aborting H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>>>>>>>>>> The key nuance of divergence is that halting means
>>>>>>>>>>>>>>>>>>> that when H(P,P)
>>>>>>>>>>>>>>>>>>> correctly simulates its input that this input would
>>>>>>>>>>>>>>>>>>> reach the
>>>>>>>>>>>>>>>>>>> "return" instruction (final state) of P. H(P,P)
>>>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>>>> determines that its correct simulation of its input
>>>>>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *computation that halts* … the Turing machine will
>>>>>>>>>>>>>>>>>>> halt whenever it
>>>>>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages
>>>>>>>>>>>>>>>>>>> and Automata.
>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>>>>>>>>>>>> description correctly matches a correct infinite
>>>>>>>>>>>>>>>>>>> behavior pattern
>>>>>>>>>>>>>>>>>>> then it is certain that this machine description
>>>>>>>>>>>>>>>>>>> specifies
>>>>>>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In other words the SHD decider correctly predicts
>>>>>>>>>>>>>>>>>>> that its correct
>>>>>>>>>>>>>>>>>>> and complete simulation of its input would never
>>>>>>>>>>>>>>>>>>> reach the final
>>>>>>>>>>>>>>>>>>> state of this input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Px always halts if H returns to Px (and a valid halt
>>>>>>>>>>>>>>>>>> decider must
>>>>>>>>>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This one uses my prior version of H named HH where the
>>>>>>>>>>>>>>>>> infinitely
>>>>>>>>>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _Px()
>>>>>>>>>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>>>>>>>>>    address   address   data      code       language
>>>>>>>>>>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>>>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>>>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push
>>>>>>>>>>>>>>>>> 000010b2
>>>>>>>>>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push
>>>>>>>>>>>>>>>>> 000010b2
>>>>>>>>>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call
>>>>>>>>>>>>>>>>> 00000ca2
>>>>>>>>>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>>>>>> Stored at:111c39
>>>>>>>>>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>>>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov
>>>>>>>>>>>>>>>>> eax,[ebp+08]
>>>>>>>>>>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax
>>>>>>>>>>>>>>>>> // push
>>>>>>>>>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov
>>>>>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx
>>>>>>>>>>>>>>>>> // push
>>>>>>>>>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call
>>>>>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>>>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov
>>>>>>>>>>>>>>>>> eax,[ebp+08]
>>>>>>>>>>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax
>>>>>>>>>>>>>>>>> // push
>>>>>>>>>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov
>>>>>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx
>>>>>>>>>>>>>>>>> // push
>>>>>>>>>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call
>>>>>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion
>>>>>>>>>>>>>>>>> Detected Simulation
>>>>>>>>>>>>>>>>> Stopped*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from
>>>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>>>> machine address of Px().
>>>>>>>>>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>>>>>>>>>> (3) With no control flow instructions between the
>>>>>>>>>>>>>>>>> invocation of Px()
>>>>>>>>>>>>>>>>> and its call to HH(Px,Px) that could possibly escape
>>>>>>>>>>>>>>>>> repeated
>>>>>>>>>>>>>>>>> simulations.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push
>>>>>>>>>>>>>>>>> 00000463
>>>>>>>>>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call
>>>>>>>>>>>>>>>>> 00000482
>>>>>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>>>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All your trace is doing is confirming that H gets the
>>>>>>>>>>>>>>>> answer wrong, Px
>>>>>>>>>>>>>>>> halts. Until you resolve this false positive you do not
>>>>>>>>>>>>>>>> have a valid
>>>>>>>>>>>>>>>> SHD.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    (void) HH(x, x);
>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because HH is a simulating halt decider (SHD) it
>>>>>>>>>>>>>>> continues to perform a pure x86 emulation of its input
>>>>>>>>>>>>>>> until it correctly matches a non-halting behavior pattern
>>>>>>>>>>>>>>> proving that the simulated input would never reach its
>>>>>>>>>>>>>>> own final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated
>>>>>>>>>>>>>>> HH(Px,Px)
>>>>>>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>> *Until HH aborts its simulation*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All those having sufficient software engineering
>>>>>>>>>>>>>>> technical competence can see this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And the correct and complete simulation of the input to
>>>>>>>>>>>>>> HH(Px,Px) is
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>>>>>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>>>>>>>>>> (g) which returns, and thus Halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus, the COMPLETE simulation of the input to HH, which we
>>>>>>>>>>>>>> agree shows the actual behavior of the input to HH, comes
>>>>>>>>>>>>>> to a Halt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This sequence of instructions provides the correct and
>>>>>>>>>>>>> complete simulation of the input to H(P,P):
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>>     (void) Simulate(x, x);
>>>>>>>>>>>>>     return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> You provide the pure simulation at the wrong point in the
>>>>>>>>>>>>> execution trace. In any case even in your incorrect
>>>>>>>>>>>>> execution trace the Px that HH simulates never reaches its
>>>>>>>>>>>>> own final state, thus never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, because you changed P!
>>>>>>>>>>>>
>>>>>>>>>>>> P MUST be
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> void Px(void (*x)()) {
>>>>>>>>>>>>     HH(x,x);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> As that is the P that was defined.
>>>>>>>>>>>>
>>>>>>>>>>>> Then have main be:
>>>>>>>>>>>>
>>>>>>>>>>>> int main() {
>>>>>>>>>>>>     // The original call to HH
>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>
>>>>>>>>>>>>     // The test
>>>>>>>>>>>>     Simulate(Px,Px);
>>>>>>>>>>>>     Output("But Px(Px) Halts");
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> I.E just DO the correct and complete simulation of the input
>>>>>>>>>>>> to HH.
>>>>>>>>>>>>
>>>>>>>>>>>> That is the plain meaning of the words.
>>>>>>>>>>>>
>>>>>>>>>>>> Youy keep on trying to change the P that is the input to H
>>>>>>>>>>>> to "prove" your answer.
>>>>>>>>>>>>
>>>>>>>>>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO
>>>>>>>>>>> ERROR*
>>>>>>>>>>
>>>>>>>>>> I just did.
>>>>>>>>>>
>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) correctly
>>>>>>>>>>> performs a partial simulation of its input and the behavior
>>>>>>>>>>> of this partial simulation correctly matches a non-halting
>>>>>>>>>>> behavior pattern then the SHD halt decider can correctly
>>>>>>>>>>> report non-halting.
>>>>>>>>>>>
>>>>>>>>>>> A non-halting behavior pattern is correct when-so-ever
>>>>>>>>>>> matching this behavior pattern proves that the correct and
>>>>>>>>>>> complete simulation of the input by SHD would never reach the
>>>>>>>>>>> final state of this simulated input.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I just showed you the error which you didn't bother even
>>>>>>>>>> trying to refute, which is just proof that you don't have a
>>>>>>>>>> clue how to attempt because you understand you are wrong.
>>>>>>>>>>
>>>>>>>>>> You are just proving you are a pathological liar, or totally
>>>>>>>>>> utterly incompetent and stupid.
>>>>>>>>>>
>>>>>>>>>> FAIL.
>>>>>>>>>
>>>>>>>>> It is common knowledge that the correct and complete simulation
>>>>>>>>> of a machine description always provides the actual behavior
>>>>>>>>> specified by this machine description.
>>>>>>>>
>>>>>>>> Right
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Therefore the actual behavior of the actual input is what the
>>>>>>>>> behavior of the input would be if the SHD performed a correct
>>>>>>>>> and complete simulation of this input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No. Because the SHD was defined to NOT do a complete simulation,
>>>>>>>> but to abort it. The "SHD that does a complete simulation" is a
>>>>>>>> different function than the one deciding, so it isn't the one
>>>>>>>> that P is calling, so its behavior is irrelvent.
>>>>>>>>
>>>>>>>>
>>>>>>>>> The fact that the simulated input would never reach its own
>>>>>>>>> final state in the above case conclusively proves that this
>>>>>>>>> input specifies a non-halting sequence of instructions.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope. Wrong Machine, The only machine that behaves that way
>>>>>>>> doesn't answer.
>>>>>>>>
>>>>>>>> The fact that Simulate(Px,Px) does Halt for any HH that answers
>>>>>>>> HH(Px,Px) proves that it is wrong to say non-halting.
>>>>>>>>
>>>>>>>> Simulate(Px,Px) is what you just references (if not by name) as
>>>>>>>> the correct and complete simulation of the machine description
>>>>>>>> that was given to HH.
>>>>>>>>
>>>>>>>>
>>>>>>>> You keep on having two different functions that you call H (or
>>>>>>>> HH) that you conflate in your logic.
>>>>>>>>
>>>>>>>> It doesn't matter what H/HH would have done if different, it
>>>>>>>> matters what the P does that calls the H/HH that you do have.
>>>>>>>
>>>>>>> (1) It is common knowledge that the correct and complete
>>>>>>> simulation of a machine description always provides the actual
>>>>>>> behavior specified by this machine description.
>>>>>>>
>>>>>>> (2) Therefore the actual behavior of the actual input is what the
>>>>>>> behavior of the input would be if the SHD performed a correct and
>>>>>>> complete simulation of this input.
>>>>>>>
>>>>>>
>>>>>> Nope. Proves you are an idiot. Because the SHD DOES abort it
>>>>>> simulation, there is no "If it didn't" case to look at.
>>>>>>
>>>>>> What is the results of program X doing operation Y if program X
>>>>>> never actually does operation Y.
>>>>>>
>>>>>> It is an ill defined condition.
>>>>>>
>>>>>>> (3) The fact that the simulated input would never reach its own
>>>>>>> final state in the above case conclusively proves that this input
>>>>>>> specifies a non-halting sequence of instructions.
>>>>>>>
>>>>>>> Because (1) is known to be true and (2) logically follows from
>>>>>>> (1) it is impossible to correctly accept (1) and deny (2).
>>>>>>>
>>>>>>
>>>>>> If you want to try to express your words in a correct formulation,
>>>>>> you could do the following.
>>>>>>
>>>>>> H is defined to take THREE parameters:
>>>>>>
>>>>>> P the program to decide on,
>>>>>> d the data for that program, and
>>>>>> s a flag that forces the decider to be a pure simulator and not a
>>>>>> decider.
>>>>>>
>>>>>>
>>>>>> THen
>>>>>>
>>>>>> H(P,d,0) is correct to return 1 if H(P,d,1) Halts, and
>>>>>> H(P,d,0) is correct to return 0 if H(P,d,1) will never halt but
>>>>>> run forever.
>>>>>>
>>>>>> P(x) is then defined to call H(x,x,0)
>>>>>
>>>>> *We could prove my point another way too*
>>>>>
>>>>> The simulating halt decider writes a 1 or a 0 to a specific tape
>>>>> location that is initialized to blank. It does this as soon as it
>>>>> correctly detects that its complete simulation would never stop
>>>>> running.
>>>>>
>>>>> HERE IS THE KEY DIFFERENCE:
>>>>> H continues to perform this complete simulation, thus never stops
>>>>> running. Because it has reported this it is correct.
>>>>>
>>>>> The assumption that H must stop to report its decision is refuted.
>>>>
>>>>
>>>> Nope, because H needs to stop to give the answer.
>>>>
>>>
>>> That is needs to stop to give its answer
>>> IS A FALSE ASSUMPTION.
>>>
>>> As soon as H knows the answer it writes a 1 or a 0 to a specific tape
>>> location and then it keeps on running.
>>>
>>>
>>
>> Remember, Linz DEFINED his H to answer by what final state it ended
>> in, and comments that this is without loss of generality.
>>
>
> None-the-less H could write a 1 or a 0 to the first element of its tape
> and keep on running. That the TM must halt to decide is simply not true.
> This is another case where CS simply didn't bother to think things through.

On 8/20/22 10:04 PM, olcott wrote:
> On 8/20/2022 8:48 PM, Richard Damon wrote:
>> On 8/20/22 9:45 PM, olcott wrote:
>>> On 8/20/2022 8:07 PM, Richard Damon wrote:
>>>> On 8/20/22 8:14 PM, olcott wrote:
>>>>> On 8/20/2022 6:42 PM, Richard Damon wrote:
>>>>>> On 8/20/22 7:28 PM, olcott wrote:
>>>>>>> On 8/20/2022 5:59 PM, Richard Damon wrote:
>>>>>>>> On 8/20/22 6:33 PM, olcott wrote:
>>>>>>>>> On 8/20/2022 4:59 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 8/20/22 5:29 PM, olcott wrote:
>>>>>>>>>>> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/20/22 5:13 PM, olcott wrote:
>>>>>>>>>>>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>>>>>>>>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>>>>>>>>>>>> Olcott, which of the following do you think is
>>>>>>>>>>>>>>>>>>>>>>> more likely?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Which one is more likely hasn't changed for all
>>>>>>>>>>>>>>>>>>>>>>> the years you've
>>>>>>>>>>>>>>>>>>>>>>> been attempting to shill your simulating halting
>>>>>>>>>>>>>>>>>>>>>>> decider. I find
>>>>>>>>>>>>>>>>>>>>>>> it amusing that I came up with, in less than 24
>>>>>>>>>>>>>>>>>>>>>>> hours, a
>>>>>>>>>>>>>>>>>>>>>>> simulating halting decider that doesn't have the
>>>>>>>>>>>>>>>>>>>>>>> flaws your SHD
>>>>>>>>>>>>>>>>>>>>>>> has.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I have been following these discussions for many
>>>>>>>>>>>>>>>>>>>>>> months now. I
>>>>>>>>>>>>>>>>>>>>>> have a strong impression that there is little
>>>>>>>>>>>>>>>>>>>>>> progress. It seems
>>>>>>>>>>>>>>>>>>>>>> that people are running in circles. I am not an
>>>>>>>>>>>>>>>>>>>>>> expert in this
>>>>>>>>>>>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to
>>>>>>>>>>>>>>>>>>>>>> summarize the
>>>>>>>>>>>>>>>>>>>>>> discussion. Please, be patient when correcting me
>>>>>>>>>>>>>>>>>>>>>> if I make any
>>>>>>>>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>>>>>>>>>>>> In computation theory we can denote a program with
>>>>>>>>>>>>>>>>>>>>>> X and its input
>>>>>>>>>>>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y)
>>>>>>>>>>>>>>>>>>>>>> may end (halt) in
>>>>>>>>>>>>>>>>>>>>>> a finite number of steps, but another program X
>>>>>>>>>>>>>>>>>>>>>> and/or input Y may
>>>>>>>>>>>>>>>>>>>>>> not halt in a finite number of steps. The question
>>>>>>>>>>>>>>>>>>>>>> is, is it
>>>>>>>>>>>>>>>>>>>>>> possible to create a program H that when given any
>>>>>>>>>>>>>>>>>>>>>> program X with
>>>>>>>>>>>>>>>>>>>>>> its input Y can tell in a finite number of steps
>>>>>>>>>>>>>>>>>>>>>> whether X(Y)
>>>>>>>>>>>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always
>>>>>>>>>>>>>>>>>>>>>> halt after a
>>>>>>>>>>>>>>>>>>>>>> finite number of steps with the correct answer for
>>>>>>>>>>>>>>>>>>>>>> any X and Y?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I hope that this is a correct formulation of the
>>>>>>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The classical proof that it is not possible is the
>>>>>>>>>>>>>>>>>>>>>> idea that it is
>>>>>>>>>>>>>>>>>>>>>> always possible to create a program P that uses H,
>>>>>>>>>>>>>>>>>>>>>> with itself as
>>>>>>>>>>>>>>>>>>>>>> input, but behaves opposite to what H returns. In
>>>>>>>>>>>>>>>>>>>>>> a C-like
>>>>>>>>>>>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If there would be a hypothetical non-simulating
>>>>>>>>>>>>>>>>>>>>>> non-aborting H,
>>>>>>>>>>>>>>>>>>>>>> which would always halts with the correct answer,
>>>>>>>>>>>>>>>>>>>>>> then it is clear
>>>>>>>>>>>>>>>>>>>>>> that there would be a contradiction if we ask H
>>>>>>>>>>>>>>>>>>>>>> about P with
>>>>>>>>>>>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>>>>>>>>>>>> 1. If H would return true (halting) in a finite
>>>>>>>>>>>>>>>>>>>>>> number of steps,
>>>>>>>>>>>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does
>>>>>>>>>>>>>>>>>>>>>> not halt in a
>>>>>>>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>>>>>>>> 2. If H would return false (non-halting) in a
>>>>>>>>>>>>>>>>>>>>>> finite number of
>>>>>>>>>>>>>>>>>>>>>> steps, then P returns immediately, so H returns a
>>>>>>>>>>>>>>>>>>>>>> wrong result.
>>>>>>>>>>>>>>>>>>>>>> 3. If H does not return, then it does not return
>>>>>>>>>>>>>>>>>>>>>> in a finite
>>>>>>>>>>>>>>>>>>>>>> number of steps, so it is not the H where the
>>>>>>>>>>>>>>>>>>>>>> problem asked for.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Now Olcott has created a simulating aborting H,
>>>>>>>>>>>>>>>>>>>>>> which, when given
>>>>>>>>>>>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>>>>>>>>>>>>> execution and
>>>>>>>>>>>>>>>>>>>>>> at the point where P calls H, it uses the
>>>>>>>>>>>>>>>>>>>>>> following logic: If H
>>>>>>>>>>>>>>>>>>>>>> were the hypothetical non-aborting H, then an
>>>>>>>>>>>>>>>>>>>>>> infinite recursion
>>>>>>>>>>>>>>>>>>>>>> would happen at this point. Therefore, Olcott's
>>>>>>>>>>>>>>>>>>>>>> simulating H
>>>>>>>>>>>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>>>>>>>>>>>> Olcott thinks that his H gives the correct answer
>>>>>>>>>>>>>>>>>>>>>> that P would not
>>>>>>>>>>>>>>>>>>>>>> halt when P would call the hypothetical
>>>>>>>>>>>>>>>>>>>>>> non-aborting H, so, it
>>>>>>>>>>>>>>>>>>>>>> must also be the correct answer when P actually
>>>>>>>>>>>>>>>>>>>>>> calls the actual
>>>>>>>>>>>>>>>>>>>>>> aborting H.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>>>>>>>>>>>> The key nuance of divergence is that halting means
>>>>>>>>>>>>>>>>>>>>> that when H(P,P)
>>>>>>>>>>>>>>>>>>>>> correctly simulates its input that this input would
>>>>>>>>>>>>>>>>>>>>> reach the
>>>>>>>>>>>>>>>>>>>>> "return" instruction (final state) of P. H(P,P)
>>>>>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>>>>>> determines that its correct simulation of its input
>>>>>>>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *computation that halts* … the Turing machine will
>>>>>>>>>>>>>>>>>>>>> halt whenever it
>>>>>>>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal
>>>>>>>>>>>>>>>>>>>>> Languages and Automata.
>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When-so-ever the correct partial simulation of a
>>>>>>>>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>>>>>>>>> description correctly matches a correct infinite
>>>>>>>>>>>>>>>>>>>>> behavior pattern
>>>>>>>>>>>>>>>>>>>>> then it is certain that this machine description
>>>>>>>>>>>>>>>>>>>>> specifies
>>>>>>>>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In other words the SHD decider correctly predicts
>>>>>>>>>>>>>>>>>>>>> that its correct
>>>>>>>>>>>>>>>>>>>>> and complete simulation of its input would never
>>>>>>>>>>>>>>>>>>>>> reach the final
>>>>>>>>>>>>>>>>>>>>> state of this input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Px always halts if H returns to Px (and a valid halt
>>>>>>>>>>>>>>>>>>>> decider must
>>>>>>>>>>>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This one uses my prior version of H named HH where
>>>>>>>>>>>>>>>>>>> the infinitely
>>>>>>>>>>>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _Px()
>>>>>>>>>>>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>>>>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>>>>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>>>>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>>>>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>>>>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>>>>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>>>>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>>>>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>>>>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>>>>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>>>>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>>>>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>>>>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>>>>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>>>>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>>>>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>>>>>>>>>>>    address   address   data      code       language
>>>>>>>>>>>>>>>>>>>    ========  ========  ========  =========
>>>>>>>>>>>>>>>>>>> =============
>>>>>>>>>>>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>>>>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov
>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push
>>>>>>>>>>>>>>>>>>> 000010b2
>>>>>>>>>>>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push
>>>>>>>>>>>>>>>>>>> 000010b2
>>>>>>>>>>>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call
>>>>>>>>>>>>>>>>>>> 00000ca2
>>>>>>>>>>>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>>>>>>>> Stored at:111c39
>>>>>>>>>>>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>>>>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov
>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov
>>>>>>>>>>>>>>>>>>> eax,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000010b8][00111c21][000010b2] 50             push
>>>>>>>>>>>>>>>>>>> eax // push
>>>>>>>>>>>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov
>>>>>>>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push
>>>>>>>>>>>>>>>>>>> ecx // push
>>>>>>>>>>>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call
>>>>>>>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>>>>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>>>>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov
>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov
>>>>>>>>>>>>>>>>>>> eax,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000010b8][0015c649][000010b2] 50             push
>>>>>>>>>>>>>>>>>>> eax // push
>>>>>>>>>>>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov
>>>>>>>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000010bc][0015c645][000010b2] 51             push
>>>>>>>>>>>>>>>>>>> ecx // push
>>>>>>>>>>>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call
>>>>>>>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion
>>>>>>>>>>>>>>>>>>> Detected Simulation
>>>>>>>>>>>>>>>>>>> Stopped*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>>>>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence
>>>>>>>>>>>>>>>>>>> from the same
>>>>>>>>>>>>>>>>>>> machine address of Px().
>>>>>>>>>>>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>>>>>>>>>>>> (3) With no control flow instructions between the
>>>>>>>>>>>>>>>>>>> invocation of Px()
>>>>>>>>>>>>>>>>>>> and its call to HH(Px,Px) that could possibly escape
>>>>>>>>>>>>>>>>>>> repeated
>>>>>>>>>>>>>>>>>>> simulations.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add
>>>>>>>>>>>>>>>>>>> esp,+08
>>>>>>>>>>>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>>>>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push
>>>>>>>>>>>>>>>>>>> 00000463
>>>>>>>>>>>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call
>>>>>>>>>>>>>>>>>>> 00000482
>>>>>>>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add
>>>>>>>>>>>>>>>>>>> esp,+08
>>>>>>>>>>>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor
>>>>>>>>>>>>>>>>>>> eax,eax
>>>>>>>>>>>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>>>>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> All your trace is doing is confirming that H gets the
>>>>>>>>>>>>>>>>>> answer wrong, Px
>>>>>>>>>>>>>>>>>> halts. Until you resolve this false positive you do
>>>>>>>>>>>>>>>>>> not have a valid
>>>>>>>>>>>>>>>>>> SHD.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>    (void) HH(x, x);
>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because HH is a simulating halt decider (SHD) it
>>>>>>>>>>>>>>>>> continues to perform a pure x86 emulation of its input
>>>>>>>>>>>>>>>>> until it correctly matches a non-halting behavior
>>>>>>>>>>>>>>>>> pattern proving that the simulated input would never
>>>>>>>>>>>>>>>>> reach its own final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated
>>>>>>>>>>>>>>>>> HH(Px,Px)
>>>>>>>>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>>> *Until HH aborts its simulation*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> All those having sufficient software engineering
>>>>>>>>>>>>>>>>> technical competence can see this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And the correct and complete simulation of the input to
>>>>>>>>>>>>>>>> HH(Px,Px) is
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>>>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>>>>>>>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>>>>>>>>>>>> (g) which returns, and thus Halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thus, the COMPLETE simulation of the input to HH, which
>>>>>>>>>>>>>>>> we agree shows the actual behavior of the input to HH,
>>>>>>>>>>>>>>>> comes to a Halt
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This sequence of instructions provides the correct and
>>>>>>>>>>>>>>> complete simulation of the input to H(P,P):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>     (void) Simulate(x, x);
>>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You provide the pure simulation at the wrong point in the
>>>>>>>>>>>>>>> execution trace. In any case even in your incorrect
>>>>>>>>>>>>>>> execution trace the Px that HH simulates never reaches
>>>>>>>>>>>>>>> its own final state, thus never halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, because you changed P!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> P MUST be
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void Px(void (*x)()) {
>>>>>>>>>>>>>>     HH(x,x);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As that is the P that was defined.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then have main be:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main() {
>>>>>>>>>>>>>>     // The original call to HH
>>>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     // The test
>>>>>>>>>>>>>>     Simulate(Px,Px);
>>>>>>>>>>>>>>     Output("But Px(Px) Halts");
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I.E just DO the correct and complete simulation of the
>>>>>>>>>>>>>> input to HH.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is the plain meaning of the words.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Youy keep on trying to change the P that is the input to H
>>>>>>>>>>>>>> to "prove" your answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS
>>>>>>>>>>>>> NO ERROR*
>>>>>>>>>>>>
>>>>>>>>>>>> I just did.
>>>>>>>>>>>>
>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) correctly
>>>>>>>>>>>>> performs a partial simulation of its input and the behavior
>>>>>>>>>>>>> of this partial simulation correctly matches a non-halting
>>>>>>>>>>>>> behavior pattern then the SHD halt decider can correctly
>>>>>>>>>>>>> report non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A non-halting behavior pattern is correct when-so-ever
>>>>>>>>>>>>> matching this behavior pattern proves that the correct and
>>>>>>>>>>>>> complete simulation of the input by SHD would never reach
>>>>>>>>>>>>> the final state of this simulated input.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I just showed you the error which you didn't bother even
>>>>>>>>>>>> trying to refute, which is just proof that you don't have a
>>>>>>>>>>>> clue how to attempt because you understand you are wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> You are just proving you are a pathological liar, or totally
>>>>>>>>>>>> utterly incompetent and stupid.
>>>>>>>>>>>>
>>>>>>>>>>>> FAIL.
>>>>>>>>>>>
>>>>>>>>>>> It is common knowledge that the correct and complete
>>>>>>>>>>> simulation of a machine description always provides the
>>>>>>>>>>> actual behavior specified by this machine description.
>>>>>>>>>>
>>>>>>>>>> Right
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Therefore the actual behavior of the actual input is what the
>>>>>>>>>>> behavior of the input would be if the SHD performed a correct
>>>>>>>>>>> and complete simulation of this input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No. Because the SHD was defined to NOT do a complete
>>>>>>>>>> simulation, but to abort it. The "SHD that does a complete
>>>>>>>>>> simulation" is a different function than the one deciding, so
>>>>>>>>>> it isn't the one that P is calling, so its behavior is irrelvent.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> The fact that the simulated input would never reach its own
>>>>>>>>>>> final state in the above case conclusively proves that this
>>>>>>>>>>> input specifies a non-halting sequence of instructions.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope. Wrong Machine, The only machine that behaves that way
>>>>>>>>>> doesn't answer.
>>>>>>>>>>
>>>>>>>>>> The fact that Simulate(Px,Px) does Halt for any HH that
>>>>>>>>>> answers HH(Px,Px) proves that it is wrong to say non-halting.
>>>>>>>>>>
>>>>>>>>>> Simulate(Px,Px) is what you just references (if not by name)
>>>>>>>>>> as the correct and complete simulation of the machine
>>>>>>>>>> description that was given to HH.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You keep on having two different functions that you call H (or
>>>>>>>>>> HH) that you conflate in your logic.
>>>>>>>>>>
>>>>>>>>>> It doesn't matter what H/HH would have done if different, it
>>>>>>>>>> matters what the P does that calls the H/HH that you do have.
>>>>>>>>>
>>>>>>>>> (1) It is common knowledge that the correct and complete
>>>>>>>>> simulation of a machine description always provides the actual
>>>>>>>>> behavior specified by this machine description.
>>>>>>>>>
>>>>>>>>> (2) Therefore the actual behavior of the actual input is what
>>>>>>>>> the behavior of the input would be if the SHD performed a
>>>>>>>>> correct and complete simulation of this input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope. Proves you are an idiot. Because the SHD DOES abort it
>>>>>>>> simulation, there is no "If it didn't" case to look at.
>>>>>>>>
>>>>>>>> What is the results of program X doing operation Y if program X
>>>>>>>> never actually does operation Y.
>>>>>>>>
>>>>>>>> It is an ill defined condition.
>>>>>>>>
>>>>>>>>> (3) The fact that the simulated input would never reach its own
>>>>>>>>> final state in the above case conclusively proves that this
>>>>>>>>> input specifies a non-halting sequence of instructions.
>>>>>>>>>
>>>>>>>>> Because (1) is known to be true and (2) logically follows from
>>>>>>>>> (1) it is impossible to correctly accept (1) and deny (2).
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you want to try to express your words in a correct
>>>>>>>> formulation, you could do the following.
>>>>>>>>
>>>>>>>> H is defined to take THREE parameters:
>>>>>>>>
>>>>>>>> P the program to decide on,
>>>>>>>> d the data for that program, and
>>>>>>>> s a flag that forces the decider to be a pure simulator and not
>>>>>>>> a decider.
>>>>>>>>
>>>>>>>>
>>>>>>>> THen
>>>>>>>>
>>>>>>>> H(P,d,0) is correct to return 1 if H(P,d,1) Halts, and
>>>>>>>> H(P,d,0) is correct to return 0 if H(P,d,1) will never halt but
>>>>>>>> run forever.
>>>>>>>>
>>>>>>>> P(x) is then defined to call H(x,x,0)
>>>>>>>
>>>>>>> *We could prove my point another way too*
>>>>>>>
>>>>>>> The simulating halt decider writes a 1 or a 0 to a specific tape
>>>>>>> location that is initialized to blank. It does this as soon as it
>>>>>>> correctly detects that its complete simulation would never stop
>>>>>>> running.
>>>>>>>
>>>>>>> HERE IS THE KEY DIFFERENCE:
>>>>>>> H continues to perform this complete simulation, thus never stops
>>>>>>> running. Because it has reported this it is correct.
>>>>>>>
>>>>>>> The assumption that H must stop to report its decision is refuted.
>>>>>>
>>>>>>
>>>>>> Nope, because H needs to stop to give the answer.
>>>>>>
>>>>>
>>>>> That is needs to stop to give its answer
>>>>> IS A FALSE ASSUMPTION.
>>>>>
>>>>> As soon as H knows the answer it writes a 1 or a 0 to a specific
>>>>> tape location and then it keeps on running.
>>>>>
>>>>>
>>>>
>>>> Nope.
>>>>
>>>> Not how Turing Machine work.
>>>>
>>>
>>> So you are saying that it is impossible for a TM to write a binary
>>> digit at the first element of its tape?
>>>
>>
>> No, but it doesn't count as an answer until the machine stops.
>>
>
> That is only an arbitrary rule that has no actual basis in sound
> reasoning. People that only learn things by rote never notice that some
> rules have no actual basis in reasoning and are thus merely arbitrary
> conventions.

On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:

> So you are saying that it is impossible for a TM to write a binary digit
> at the first element of its tape?
>
The concept "first element of its tape" is ambigious and usually
defined so as to be constantly changing. How something like
H returns anything needs to be carefully defined. Perhaps Linz
does define it elsewhere in his book.

On 8/20/22 10:18 PM, dklei...@gmail.com wrote:
> On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:
>
>> So you are saying that it is impossible for a TM to write a binary digit
>> at the first element of its tape?
>>
> The concept "first element of its tape" is ambigious and usually
> defined so as to be constantly changing. How something like
> H returns anything needs to be carefully defined. Perhaps Linz
> does define it elsewhere in his book.

Some models of Turing Machines have a fixed end that can't be extended,
so there is a first element. This does lead to other issues that need to
be handled.

PO just thinks of the tape as memory locations, so the concept of
element NOT having a address whould be too confusing for him.

On 8/20/2022 9:18 PM, dklei...@gmail.com wrote:
> On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:
>
>> So you are saying that it is impossible for a TM to write a binary digit
>> at the first element of its tape?
>>
> The concept "first element of its tape" is ambigious and usually
> defined so as to be constantly changing. How something like
> H returns anything needs to be carefully defined. Perhaps Linz
> does define it elsewhere in his book.

At least some of the definitions of TM's have only a unidirectional
tapes thus inherently have a first element.

page 10
https://basics.sjtu.edu.cn/~yuxi/teaching/computability2013/slides/4.%20Turing%20Machine.pdf

--
Copyright 2022 Pete Olcott

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

On Saturday, August 20, 2022 at 8:08:04 PM UTC-7, olcott wrote:
> On 8/20/2022 9:18 PM, dklei...@gmail.com wrote:
> > On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:
> >
> >> So you are saying that it is impossible for a TM to write a binary digit
> >> at the first element of its tape?
> >>
> > The concept "first element of its tape" is ambigious and usually
> > defined so as to be constantly changing. How something like
> > H returns anything needs to be carefully defined. Perhaps Linz
> > does define it elsewhere in his book.
> At least some of the definitions of TM's have only a unidirectional
> tapes thus inherently have a first element.
>
> page 10
> https://basics.sjtu.edu.cn/~yuxi/teaching/computability2013/slides/4.%20Turing%20Machine.pdf

That version of Turing Machines is somewhat eccentric. I wonder
what the situation is among the research community. Is there any
kind of consensus today about what a standard Turing Machine
is. Is the machine described in Wikipedia the standard?

On 2022-08-20 15:01:34 +0000, Fred. Zwarts said:

> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>> Olcott, which of the following do you think is more likely?
>>
>> 1) Olcott is correct and everybody else is wrong.
>> 2) Olcott is wrong and everybody else is correct.
>>
>> Which one is more likely hasn't changed for all the years you've been
>> attempting to shill your simulating halting decider. I find it amusing
>> that I came up with, in less than 24 hours, a simulating halting
>> decider that doesn't have the flaws your SHD has.
>>
>> /Flibble
>>
>
> I have been following these discussions for many months now. I have a
> strong impression that there is little progress. It seems that people
> are running in circles. I am not an expert in this field. Maybe it
> helps if a non-expert tries to summarize the discussion. Please, be
> patient when correcting me if I make any mistake.
>
> First the problem this is al about:
> In computation theory we can denote a program with X and its input with
> Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite
> number of steps, but another program X and/or input Y may not halt in a
> finite number of steps. The question is, is it possible to create a
> program H that when given any program X with its input Y can tell in a
> finite number of steps whether X(Y) halts or not? In other words, will
> H(X,Y) always halt after a finite number of steps with the correct
> answer for any X and Y?

In the classical formulation X and H are Turing machines. Y is a finite
string of symbols from some finite set. H(X,Y) denotes a computation where
H is given a finite string that represents X and Y so that each can be
reconstructed.

> I hope that this is a correct formulation of the problem.
>
> The classical proof that it is not possible is the idea that it is
> always possible to create a program P that uses H, with itself as
> input, but behaves opposite to what H returns. In a C-like language it
> would be something like:
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }

Roughly so but both P and H take a single string as argument:

void P(string x)
{ string arg = pair(x, x);
boolean Halt_Status = H(arg);
if (Halt_Status)
HERE: goto HERE;
return;
}

> If there would be a hypothetical non-simulating non-aborting H, which
> would always halts with the correct answer, then it is clear that there
> would be a contradiction if we ask H about P with H(P,P). Because there
> are only three possibilities:
> 1. If H would return true (halting) in a finite number of steps, then P
> would start an endless loop, so H(P,P) does not halt in a finite number
> of steps.
> 2. If H would return false (non-halting) in a finite number of steps,
> then P returns immediately, so H returns a wrong result.
> 3. If H does not return, then it does not return in a finite number of
> steps, so it is not the H where the problem asked for.

With Turing machines the possibilities are:
1. H halts with the answer true.
2. H halts with the answer false.
3. H halts but answers neither true nor false.
4. H does not halt.

If 3 or 4 happens then H is not a halt decider, i.e., not a solution
to the problem. If H(P, P) halts with the answer true then P(P) does
not halt so H is not a halt decider. If H(P, P) halts with the
answer false then P(P) halts so H is not a halt decider.

The restriction to non-simulating non-aborting H is not necessary.
The requirements are the same anyway.

> I think everybody agrees up to this point.
>
> Now Olcott has created a simulating aborting H, which, when given P
> with input P [so H(P,P)], creates a trace of the execution and at the
> point where P calls H, it uses the following logic: If H were the
> hypothetical non-aborting H, then an infinite recursion would happen at
> this point. Therefore, Olcott's simulating H aborts the simulation and
> returns false (0).
>
> Does everybody still agree up to this point?

Yes, and everybody also agrees that P(P) halts.

> Now the opinions diverge.
> Olcott thinks that his H gives the correct answer that P would not halt
> when P would call the hypothetical non-aborting H, so, it must also be
> the correct answer when P actually calls the actual aborting H.
>
> Others have a different opinion and argue that P does not call the
> hypothetical non-aborting H, but the actual aborting H, which does not
> go in infinite recursion, but returns false in a finite number of
> steps. Therefore, H's result is wrong.
>
> Is this a correct summary of the disagreement? If not, please, tell me
> where the summary failed. Maybe we can then find the point of
> divergence of opinions easier.

Basically the disagreement is about the meaning of "correct".

Mikko

On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:

> Op 20.aug..2022 om 17:23 schreef olcott:

>> *You did a very good job summing this up*
>> The key nuance of divergence is that halting means that when H(P,P)
>> correctly simulates its input that this input would reach the "return"
>> instruction (final state) of P. H(P,P) correctly determines that its
>> correct simulation of its input would never reach the "return"
>> instruction of P.
>>
>
> Thanks for the confirmation, because I was not completely sure about my
> last sentence above. But I am glad that I understood you correctly that
> your aborting H answers the question for P calling the hypothetical
> non-aborting H.
>
> You derive the final answer (for P calling the actual aborting H)
> indirectly from the first answer, because it cannot be answered
> directly, as it would not reach the return instruction.

Note that reaching return instruction is not the same as halting as
specified in the original problem. Halting as required to be determined
in the halting problem means that the computation as arrived to a any
situation where the program does not specify the next action. The classical
problem statement is about Turing machines where "return" is not defined.

Mikko

On 2022-08-20 15:23:58 +0000, olcott said:

> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)

Note that an important part of the definition is omitted: the definition
of "final state" is not quoted because that would make much harder to
reject Linz' definition and use a different meaning instead.

Mikko

"dklei...@gmail.com" <dkleinecke@gmail.com> writes:

> On Saturday, August 20, 2022 at 8:08:04 PM UTC-7, olcott wrote:

>> https://basics.sjtu.edu.cn/~yuxi/teaching/computability2013/slides/4.%20Turing%20Machine.pdf
>
> That version of Turing Machines is somewhat eccentric. I wonder
> what the situation is among the research community. Is there any
> kind of consensus today about what a standard Turing Machine
> is. Is the machine described in Wikipedia the standard?

It's a free-for all in teaching: everyone will either give their own
preferred definition or the one in some recommended text. As for the
research community, it's a non-issue as all forms are fundamentally
equivalent.

--
Ben.

On 8/21/22 5:08 AM, Mikko wrote:
> On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
>
>> Op 20.aug..2022 om 17:23 schreef olcott:
>
>>> *You did a very good job summing this up*
>>> The key nuance of divergence is that halting means that when H(P,P)
>>> correctly simulates its input that this input would reach the
>>> "return" instruction (final state) of P. H(P,P) correctly determines
>>> that its correct simulation of its input would never reach the
>>> "return" instruction of P.
>>>
>>
>> Thanks for the confirmation, because I was not completely sure about
>> my last sentence above. But I am glad that I understood you correctly
>> that your aborting H answers the question for P calling the
>> hypothetical non-aborting H.
>>
>> You derive the final answer (for P calling the actual aborting H)
>> indirectly from the first answer, because it cannot be answered
>> directly, as it would not reach the return instruction.
>
> Note that reaching return instruction is not the same as halting as
> specified in the original problem. Halting as required to be determined
> in the halting problem means that the computation as arrived to a any
> situation where the program does not specify the next action. The classical
> problem statement is about Turing machines where "return" is not defined.
>
> Mikko
>

Actually, a "fanal return", where the initial function that performs the
computation returns to "its caller" is not a bad equivalent the the
halting state of a Turing Machine.

The inital call / return become the equivalents of the initial and final
states of the Turing Machine as far as actually building up a larger
computation out of pieces.

It is how a function "yields" its answer to its user.

On 2022-08-21 11:35:09 +0000, Richard Damon said:

> On 8/21/22 5:08 AM, Mikko wrote:
>> On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
>>
>>> Op 20.aug..2022 om 17:23 schreef olcott:
>>
>>>> *You did a very good job summing this up*
>>>> The key nuance of divergence is that halting means that when H(P,P)
>>>> correctly simulates its input that this input would reach the "return"
>>>> instruction (final state) of P. H(P,P) correctly determines that its
>>>> correct simulation of its input would never reach the "return"
>>>> instruction of P.
>>>>
>>>
>>> Thanks for the confirmation, because I was not completely sure about my
>>> last sentence above. But I am glad that I understood you correctly that
>>> your aborting H answers the question for P calling the hypothetical
>>> non-aborting H.
>>>
>>> You derive the final answer (for P calling the actual aborting H)
>>> indirectly from the first answer, because it cannot be answered
>>> directly, as it would not reach the return instruction.
>>
>> Note that reaching return instruction is not the same as halting as
>> specified in the original problem. Halting as required to be determined
>> in the halting problem means that the computation as arrived to a any
>> situation where the program does not specify the next action. The classical
>> problem statement is about Turing machines where "return" is not defined.
>>
>> Mikko
>>
>
> Actually, a "fanal return", where the initial function that performs
> the computation returns to "its caller" is not a bad equivalent the the
> halting state of a Turing Machine.

No, but a program may terminate otherwise, e.g. throw an exception or
call exit. Only if we know that a program does not terminate otherwise
we may equate final return to halt.

Mikko

On 8/21/2022 1:10 AM, dklei...@gmail.com wrote:
> On Saturday, August 20, 2022 at 8:08:04 PM UTC-7, olcott wrote:
>> On 8/20/2022 9:18 PM, dklei...@gmail.com wrote:
>>> On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:
>>>
>>>> So you are saying that it is impossible for a TM to write a binary digit
>>>> at the first element of its tape?
>>>>
>>> The concept "first element of its tape" is ambigious and usually
>>> defined so as to be constantly changing. How something like
>>> H returns anything needs to be carefully defined. Perhaps Linz
>>> does define it elsewhere in his book.
>> At least some of the definitions of TM's have only a unidirectional
>> tapes thus inherently have a first element.
>>
>> page 10
>> https://basics.sjtu.edu.cn/~yuxi/teaching/computability2013/slides/4.%20Turing%20Machine.pdf
>
> That version of Turing Machines is somewhat eccentric. I wonder
> what the situation is among the research community. Is there any
> kind of consensus today about what a standard Turing Machine
> is. Is the machine described in Wikipedia the standard?

There are TM's with a unidirectional tape, thus there *are* TM's with a
first tape element.

--
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 8/21/2022 4:00 AM, Mikko wrote:
> On 2022-08-20 15:01:34 +0000, Fred. Zwarts said:
>
>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>> Olcott, which of the following do you think is more likely?
>>>
>>> 1) Olcott is correct and everybody else is wrong.
>>> 2) Olcott is wrong and everybody else is correct.
>>>
>>> Which one is more likely hasn't changed for all the years you've been
>>> attempting to shill your simulating halting decider.  I find it amusing
>>> that I came up with, in less than 24 hours, a simulating halting
>>> decider that doesn't have the flaws your SHD has.
>>>
>>> /Flibble
>>>
>>
>> I have been following these discussions for many months now. I have a
>> strong impression that there is little progress. It seems that people
>> are running in circles. I am not an expert in this field. Maybe it
>> helps if a non-expert tries to summarize the discussion. Please, be
>> patient when correcting me if I make any mistake.
>>
>> First the problem this is al about:
>> In computation theory we can denote a program with X and its input
>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>> finite number of steps, but another program X and/or input Y may not
>> halt in a finite number of steps. The question is, is it possible to
>> create a program H that when given any program X with its input Y can
>> tell in a finite number of steps whether X(Y) halts or not? In other
>> words, will H(X,Y) always halt after a finite number of steps with the
>> correct answer for any X and Y?
>
> In the classical formulation X and H are Turing machines. Y is a finite
> string of symbols from some finite set. H(X,Y) denotes a computation where
> H is given a finite string that represents X and Y so that each can be
> reconstructed.
>
>> I hope that this is a correct formulation of the problem.
>>
>> The classical proof that it is not possible is the idea that it is
>> always possible to create a program P that uses H, with itself as
>> input, but behaves opposite to what H returns. In a C-like language it
>> would be something like:
>>
>> void P(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>
> Roughly so but both P and H take a single string as argument:
>
> void P(string x)
> {
>  string arg = pair(x, x);
>  boolean Halt_Status = H(arg);
>  if (Halt_Status)
>    HERE: goto HERE;
>  return;
> }
>
>> If there would be a hypothetical non-simulating non-aborting H, which
>> would always halts with the correct answer, then it is clear that
>> there would be a contradiction if we ask H about P with H(P,P).
>> Because there are only three possibilities:
>> 1. If H would return true (halting) in a finite number of steps, then
>> P would start an endless loop, so H(P,P) does not halt in a finite
>> number of steps.
>> 2. If H would return false (non-halting) in a finite number of steps,
>> then P returns immediately, so H returns a wrong result.
>> 3. If H does not return, then it does not return in a finite number of
>> steps, so it is not the H where the problem asked for.
>
> With Turing machines the possibilities are:
> 1. H halts with the answer true.
> 2. H halts with the answer false.
> 3. H halts but answers neither true nor false.
> 4. H does not halt.
>
> If 3 or 4 happens then H is not a halt decider, i.e., not a solution
> to the problem. If H(P, P) halts with the answer true then P(P) does
> not halt so H is not a halt decider. If H(P, P) halts with the
> answer false then P(P) halts so H is not a halt decider.
>
> The restriction to non-simulating non-aborting H is not necessary.
> The requirements are the same anyway.
>
>> I think everybody agrees up to this point.
>>
>> Now Olcott has created a simulating aborting H, which, when given P
>> with input P [so H(P,P)], creates a trace of the execution and at the
>> point where P calls H, it uses the following logic: If H were the
>> hypothetical non-aborting H, then an infinite recursion would happen
>> at this point. Therefore, Olcott's simulating H aborts the simulation
>> and returns false (0).
>>
>> Does everybody still agree up to this point?
>
> Yes, and everybody also agrees that P(P) halts.
>

It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.

The correct and complete simulation by H(P,P) of its input would never
reach its final state and halt, thus the input to H(P,P) specifies a
non-halting sequence of instructions.

>> Now the opinions diverge.
>> Olcott thinks that his H gives the correct answer that P would not
>> halt when P would call the hypothetical non-aborting H, so, it must
>> also be the correct answer when P actually calls the actual aborting H.
>>
>> Others have a different opinion and argue that P does not call the
>> hypothetical non-aborting H, but the actual aborting H, which does not
>> go in infinite recursion, but returns false in a finite number of
>> steps. Therefore, H's result is wrong.
>>
>> Is this a correct summary of the disagreement? If not, please, tell me
>> where the summary failed. Maybe we can then find the point of
>> divergence of opinions easier.
>
> Basically the disagreement is about the meaning of "correct".
>
> Mikko
>

--
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 8/21/2022 4:08 AM, Mikko wrote:
> On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
>
>> Op 20.aug..2022 om 17:23 schreef olcott:
>
>>> *You did a very good job summing this up*
>>> The key nuance of divergence is that halting means that when H(P,P)
>>> correctly simulates its input that this input would reach the
>>> "return" instruction (final state) of P. H(P,P) correctly determines
>>> that its correct simulation of its input would never reach the
>>> "return" instruction of P.
>>>
>>
>> Thanks for the confirmation, because I was not completely sure about
>> my last sentence above. But I am glad that I understood you correctly
>> that your aborting H answers the question for P calling the
>> hypothetical non-aborting H.
>>
>> You derive the final answer (for P calling the actual aborting H)
>> indirectly from the first answer, because it cannot be answered
>> directly, as it would not reach the return instruction.
>
> Note that reaching return instruction is not the same as halting as
> specified in the original problem.

Of course "return" is not defined for Turing Machines, only a final
state is defined for TM's. The final state of a C function is its
"return" instruction.

> Halting as required to be determined
> in the halting problem means that the computation as arrived to a any
> situation where the program does not specify the next action.

AKA a final state.

> The classical
> problem statement is about Turing machines where "return" is not defined.
>
> Mikko
>

--
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 8/21/2022 4:12 AM, Mikko wrote:
> On 2022-08-20 15:23:58 +0000, olcott said:
>
>> *computation that halts* … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>
> Note that an important part of the definition is omitted: the definition
> of "final state" is not quoted because

Everyone here knows what a final state is:
A configuration for which δ is not defined...
we will Assume that no transitions are defined for any final state.

> that would make much harder to
> reject Linz' definition and use a different meaning instead.
>
> Mikko
>

--
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 8/21/2022 4:12 AM, Mikko wrote:
> On 2022-08-20 15:23:58 +0000, olcott said:
>
>> *computation that halts* … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>
> Note that an important part of the definition is omitted: the definition
> of "final state" is not quoted because that would make much harder to
> reject Linz' definition and use a different meaning instead.
>
> Mikko
>

*If you want to get so nit picky about it we can do this*

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
__asm hlt
}

No transitions are defined for __asm hlt.

--
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-08-21 13:33:59 +0000, olcott said:

> On 8/21/2022 4:08 AM, Mikko wrote:

>> Halting as required to be determined
>> in the halting problem means that the computation as arrived to a any
>> situation where the program does not specify the next action.
>
> AKA a final state.

But not necessarily a return statement. For example, an exit call
could be used instead.

Mikko

On Sat, 20 Aug 2022 16:01:31 -0500, in article <crudnRbncP4E1pz-
nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:

[snip]

> It is common knowledge that [...]

Have you noticed that almost every time you use this phrase, you're
wrong?
So also this time.

> [...] the correct and complete simulation of a
> machine description [...]

Machine descriptions are never simulated -- they're just sequences
of symbols.
and don't have any defined behaviour. The machines they *represent*
may be
simulated.

> [...] always provides the actual behavior specified by
> this machine description.

This is almost, but not quite, correct (if you fix it according to
the
previous paragraph). It would have been completely correct, if it
weren't
for the fact that you're using an utterly bizarre meaning for the
phrase
"the actual behavior specified by this machine description".

> That you and others reject this when it is applied to my simulating halt
> decider implicitly rejects the notion of a UTM. Since you and others do
> accept the notion of a UTM, I have just proven that your reasoning is
> incoherent and/or inconsistent.

Let M be a given machine, with machine description [M], and let w
be
a given input tape, with tape description [w]. Then the
"simulation"
UTM([M],[w]) has exactly the same result (i.e. exactly the same
behaviour)
as the direct computation M(w). This is actually the definition of
a UTM.

Another way of expressing this is: M(w) and UTM([M],[w]) compute
the same
partial function.

You have made it abundantly clear that when you say "the actual
behavior
specified by this machine description", you do *not* mean "the
actual
behavior specified by this machine description", because that's
simply
the behaviour of M(w). What you *do* mean is "the behaviour of your
particular, broken and incomplete, quasi-simulation based on [M]
and [w]".

Why is it broken? Because it *doesn't* have the same behaviour as M
(w),
nor as UTM([M],[w]). A correct simulation *means* that it has the
same
behaviour as M(w).

Why is it incomplete? Because it aborts its "simulation" before it
reaches
a halting configuration of the machine represented by its input,
and it
does so on invalidly.

Why is it a quasi-simulation? Because it depends on external input
that is
contained in neither [M] nor [w]. You have said, on numerous
occasions,
that the behaviour of your "H(P,P)" depends on the specific memory
location of "P". Well, then that location is an external input.
Your H is
*not* analogous to Linz' H([M],[w]).

This is the point where you usually barf up your stanza about how
the
behaviour of your "H(P,P)" cannot be expected to be computed "from
the
non-input P(P)". This is obviously idiotic, for the following
reasons:

1) A purported halt decider H([M],[w]) is *not* required to compute
its
result *from* M(w), but to *match* M(w). Computing *from* M(w)
would be
completely pointless, because the decider would already know the
answer.

Since you seem unable to understand anything but arguments from
analogy, let me re-use one that you yourself have employed:
Suppose
we want to construct an addition algorithm add(x,y). If you were
to
complain that add(5,7) cannot be required to compute its result
"from
the non-input 12", you would, quite rightly, be regarded as a
complete
nitwit. Can you now guess why you're universally regarded as a
complete
nitwit?

2) The behaviour of UTM([M],[w]) is *defined* to match the
behaviour of M(w),
and UTMs very evidently do exist. The information contained in
[M] and [w]
is obviously enough to match the behaviour of M(w). The fact
that your
"simulator" fails in this regard, is proof that your
"simulator" is
defective -- *not* that you have discovered a "loop hole", or
that halting
theorem is faulty, or anything of that kind -- only that you're
working
with a broken simulator.

> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*

A lot of people have pointed out many kinds of errors in your
reasoning.
You usually respond with some form "proof by regurgitation". I
expect you
will do so to this post.

> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a non-halting behavior pattern then the SHD
> halt decider can correctly report non-halting.
>
> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.

Yeah, that's just a bunch of equivocations on "correctly", "its
input",
"non-halting behavior", and more. Please learn to write clearly.

Also, could you *please* stop misreading Linz! He *doesn't* say
that a TM
halts, only if it enters a "final state". What he actually says is:

"A Turing machine is said to halt whenever it reaches a
configuration
for which delta is not defined; this is possible because delta
is a
partial function. In fact, we will assume that no transitions
are
defined for any final state, so the Turing machine will halt
whenever
it enters a final state."

So, for a general TM, there may well be configurations for which
the TM
halts in a non-final state. It is, on the other hand, understood
that a TM
*only* stops running if enters a configuration for which the
transition
function is undefined.

"Final states" only concern the *interpretation* of the value of a
computation -- *not* whether the TM halts or not.

This means that "halting" and "stops running" are the exact the
same things.
And obviously, "running" and "being simulated" are two entirely
different
things.

On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
> On Sat, 20 Aug 2022 16:01:31 -0500, in article <crudnRbncP4E1pz-
> nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:
>
> [snip]
>
>> It is common knowledge that [...]
>
> Have you noticed that almost every time you use this phrase, you're
> wrong?
> So also this time.
>
>> [...] the correct and complete simulation of a
>> machine description [...]
>
> Machine descriptions are never simulated -- they're just sequences
> of symbols.
> and don't have any defined behaviour. The machines they *represent*
> may be
> simulated.
>
>> [...] always provides the actual behavior specified by
>> this machine description.
>
> This is almost, but not quite, correct (if you fix it according to
> the
> previous paragraph). It would have been completely correct, if it
> weren't
> for the fact that you're using an utterly bizarre meaning for the
> phrase
> "the actual behavior specified by this machine description".
>
>> That you and others reject this when it is applied to my simulating halt
>> decider implicitly rejects the notion of a UTM. Since you and others do
>> accept the notion of a UTM, I have just proven that your reasoning is
>> incoherent and/or inconsistent.
>
> Let M be a given machine, with machine description [M], and let w
> be
> a given input tape, with tape description [w]. Then the
> "simulation"
> UTM([M],[w]) has exactly the same result (i.e. exactly the same
> behaviour)
> as the direct computation M(w). This is actually the definition of
> a UTM.
>
> Another way of expressing this is: M(w) and UTM([M],[w]) compute
> the same
> partial function.
>
> You have made it abundantly clear that when you say "the actual
> behavior
> specified by this machine description", you do *not* mean "the
> actual
> behavior specified by this machine description", because that's
> simply
> the behaviour of M(w). What you *do* mean is "the behaviour of your
> particular, broken and incomplete, quasi-simulation based on [M]
> and [w]".
>
> Why is it broken? Because it *doesn't* have the same behaviour as M
> (w),
> nor as UTM([M],[w]). A correct simulation *means* that it has the
> same
> behaviour as M(w).
>
> Why is it incomplete? Because it aborts its "simulation" before it
> reaches
> a halting configuration of the machine represented by its input,
> and it
> does so on invalidly.
>
> Why is it a quasi-simulation? Because it depends on external input
> that is
> contained in neither [M] nor [w]. You have said, on numerous
> occasions,
> that the behaviour of your "H(P,P)" depends on the specific memory
> location of "P". Well, then that location is an external input.
> Your H is
> *not* analogous to Linz' H([M],[w]).
>
> This is the point where you usually barf up your stanza about how
> the
> behaviour of your "H(P,P)" cannot be expected to be computed "from
> the
> non-input P(P)". This is obviously idiotic, for the following
> reasons:
>
> 1) A purported halt decider H([M],[w]) is *not* required to compute
> its
> result *from* M(w), but to *match* M(w). Computing *from* M(w)
> would be
> completely pointless, because the decider would already know the
> answer.
>
> Since you seem unable to understand anything but arguments from
> analogy, let me re-use one that you yourself have employed:
> Suppose
> we want to construct an addition algorithm add(x,y). If you were
> to
> complain that add(5,7) cannot be required to compute its result
> "from
> the non-input 12", you would, quite rightly, be regarded as a
> complete
> nitwit. Can you now guess why you're universally regarded as a
> complete
> nitwit?
>
> 2) The behaviour of UTM([M],[w]) is *defined* to match the
> behaviour of M(w),
> and UTMs very evidently do exist. The information contained in
> [M] and [w]
> is obviously enough to match the behaviour of M(w). The fact
> that your
> "simulator" fails in this regard, is proof that your
> "simulator" is
> defective -- *not* that you have discovered a "loop hole", or
> that halting
> theorem is faulty, or anything of that kind -- only that you're
> working
> with a broken simulator.
>
>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>
> A lot of people have pointed out many kinds of errors in your
> reasoning.
> You usually respond with some form "proof by regurgitation". I
> expect you
> will do so to this post.
>
>> When-so-ever a simulating halt decider (SHD) correctly performs a
>> partial simulation of its input and the behavior of this partial
>> simulation correctly matches a non-halting behavior pattern then the SHD
>> halt decider can correctly report non-halting.
>>
>> A non-halting behavior pattern is correct when-so-ever matching this
>> behavior pattern proves that the correct and complete simulation of the
>> input by SHD would never reach the final state of this simulated input.
>
> Yeah, that's just a bunch of equivocations on "correctly", "its
> input",
> "non-halting behavior", and more. Please learn to write clearly.
>
>
> Also, could you *please* stop misreading Linz! He *doesn't* say
> that a TM
> halts, only if it enters a "final state". What he actually says is:
>
> "A Turing machine is said to halt whenever it reaches a
> configuration
> for which delta is not defined; this is possible because delta
> is a
> partial function. In fact, we will assume that no transitions
> are
> defined for any final state, so the Turing machine will halt
> whenever
> it enters a final state."
>
> So, for a general TM, there may well be configurations for which
> the TM
> halts in a non-final state. It is, on the other hand, understood
> that a TM
> *only* stops running if enters a configuration for which the
> transition
> function is undefined.
>
> "Final states" only concern the *interpretation* of the value of a
> computation -- *not* whether the TM halts or not.
>
> This means that "halting" and "stops running" are the exact the
> same things.
> And obviously, "running" and "being simulated" are two entirely
> different
> things.
>
>

void P(ptr x)
{ int Halt_Status = UTM(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

The behavior of the actual input to the simulating halt decider is the
behavior of the above. Since C functions do not actually have UTM's a
more accurate way of sayoing this is:

void P(ptr x)
{ int Halt_Status = Simulate(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

The behavior of UTM(P,P) or Simulate(P,P) is not the behavior of the
actual input to H(P,P) because it is at a different point in the
execution trace than H(P,P).

--
Copyright 2022 Pete Olcott

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

[Re-post: line wrapping went haywire!]

On Sat, 20 Aug 2022 16:01:31 -0500, in article <crudnRbncP4E1pz-
nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:

[snip]

> It is common knowledge that [...]

Have you noticed that almost every time you use this phrase, you're
wrong? So also this time.

> [...] the correct and complete simulation of a
> machine description [...]

Machine descriptions are never simulated -- they're just sequences
of symbols. and don't have any defined behaviour. The machines they
*represent* may be simulated.

> [...] always provides the actual behavior specified by
> this machine description.

This is almost, but not quite, correct (if you fix it according to
the previous paragraph). It would have been completely correct, if
it weren't for the fact that you're using an utterly bizarre meaning
for the phrase "the actual behavior specified by this machine
description".

> That you and others reject this when it is applied to my simulating halt
> decider implicitly rejects the notion of a UTM. Since you and others do
> accept the notion of a UTM, I have just proven that your reasoning is
> incoherent and/or inconsistent.

Let M be a given machine, with machine description [M], and let w be
a given input tape, with tape description [w]. Then the "simulation"
UTM([M],[w]) has exactly the same result (i.e. exactly the same
behaviour) as the direct computation M(w). This is actually the
definition of a UTM.

Another way of expressing this is: M(w) and UTM([M],[w]) compute the
same partial function.

You have made it abundantly clear that when you say "the actual
behavior specified by this machine description", you do *not*
mean "the actual behavior specified by this machine description",
because that's simply the behaviour of M(w). What you *do* mean
is "the behaviour of your particular, broken and incomplete,
quasi-simulation based on [M] and [w]".

Why is it broken? Because it *doesn't* have the same behaviour as
M(w), nor as UTM([M],[w]). A correct simulation *means* that it has
the same behaviour as M(w).

Why is it incomplete? Because it aborts its "simulation" before it
reaches a halting configuration of the machine represented by its
input, and it does so on invalidly.

Why is it a quasi-simulation? Because it depends on external input
that is contained in neither [M] nor [w]. You have said, on numerous
occasions, that the behaviour of your "H(P,P)" depends on the
specific memory location of "P". Well, then that location is an
external input. Your H is *not* analogous to Linz' H([M],[w]).

This is the point where you usually barf up your stanza about how
the behaviour of your "H(P,P)" cannot be expected to be computed
"from the non-input P(P)". This is obviously idiotic, for the
following reasons:

1) A purported halt decider H([M],[w]) is *not* required to compute
its result *from* M(w), but to *match* M(w). Computing *from*
M(w) would be completely pointless, because the decider would
already know the answer.

Since you seem unable to understand anything but arguments from
analogy, let me re-use one that you yourself have employed:
Suppose we want to construct an addition algorithm add(x,y). If
you were to complain that add(5,7) cannot be required to compute
its result "from the non-input 12", you would, quite rightly,
be regarded as a complete nitwit. Can you now guess why you're
universally regarded as a complete nitwit?

2) The behaviour of UTM([M],[w]) is *defined* to match the behaviour
of M(w), and UTMs very evidently do exist. The information
contained in [M] and [w] is obviously enough to match the
behaviour of M(w). The fact that your "simulator" fails in this
regard, is proof that your "simulator" is defective -- *not* that
you have discovered a "loop hole", or that halting theorem is
faulty, or anything of that kind -- only that you're working with
a broken simulator.

> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*

A lot of people have pointed out many kinds of errors in
your reasoning. You usually respond with some form "proof by
regurgitation". I expect you will do so to this post.

> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a non-halting behavior pattern then the SHD
> halt decider can correctly report non-halting.
>
> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.

Yeah, that's just a bunch of equivocations on "correctly", "its
input", "non-halting behavior", and more. Please learn to write
clearly.

Also, could you *please* stop misreading Linz! He *doesn't* say that
a TM halts, only if it enters a "final state". What he actually says
is:

"A Turing machine is said to halt whenever it reaches a
configuration for which delta is not defined; this is possible
because delta is a partial function. In fact, we will assume
that no transitions are defined for any final state, so the
Turing machine will halt whenever it enters a final state."

So, for a general TM, there may well be configurations for which the
TM halts in a non-final state. It is, on the other hand, understood
that a TM *only* stops running if enters a configuration for which
the transition function is undefined.

"Final states" only concern the *interpretation* of the value of a
computation -- *not* whether the TM halts or not.

This means that "halting" and "stops running" are the exact the
same things. And obviously, "running" and "being simulated" are two
entirely different things.

On Sun, 21 Aug 2022 10:36:12 -0500, in article <edqcnTmwUr5IzZ_-
nZ2dnZfqlJ_NnZ2d@giganews.com>, olcott wrote:
>
> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:

[sorry about the strange wrapping -- I have no idea what happened there!]

> > On Sat, 20 Aug 2022 16:01:31 -0500, in article <crudnRbncP4E1pz-
> > nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:
> >
> > [snip]
> >
> >> It is common knowledge that [...]

[snip]

>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*

>>A lot of people have pointed out many kinds of errors in
>>your reasoning. You usually respond with some form [of] "proof by
>>regurgitation". I expect you will do so to this post.

[snip]

>
> void P(ptr x)
> {
<BLARGH!>

Are you actually actively trying to prove my point?

On 8/21/22 9:33 AM, olcott wrote:
> On 8/21/2022 4:08 AM, Mikko wrote:
>> On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
>>
>>> Op 20.aug..2022 om 17:23 schreef olcott:
>>
>>>> *You did a very good job summing this up*
>>>> The key nuance of divergence is that halting means that when H(P,P)
>>>> correctly simulates its input that this input would reach the
>>>> "return" instruction (final state) of P. H(P,P) correctly determines
>>>> that its correct simulation of its input would never reach the
>>>> "return" instruction of P.
>>>>
>>>
>>> Thanks for the confirmation, because I was not completely sure about
>>> my last sentence above. But I am glad that I understood you correctly
>>> that your aborting H answers the question for P calling the
>>> hypothetical non-aborting H.
>>>
>>> You derive the final answer (for P calling the actual aborting H)
>>> indirectly from the first answer, because it cannot be answered
>>> directly, as it would not reach the return instruction.
>>
>> Note that reaching return instruction is not the same as halting as
>> specified in the original problem.
>
>
> Of course "return" is not defined for Turing Machines, only a final
> state is defined for TM's. The final state of a C function is its
> "return" instruction.

So if your H function doesn't reach its return instruction in finite
time, it hasn't given a result.

>
>> Halting as required to be determined
>> in the halting problem means that the computation as arrived to a any
>> situation where the program does not specify the next action.
>
> AKA a final state.
>
>> The classical
>> problem statement is about Turing machines where "return" is not defined.
>>
>> Mikko
>>
>

On 8/21/22 11:36 AM, olcott wrote:
> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
>> On Sat, 20 Aug 2022 16:01:31 -0500, in article <crudnRbncP4E1pz-
>> nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:
>>
>> [snip]
>>
>>> It is common knowledge that [...]
>>
>> Have you noticed that almost every time you use this phrase, you're
>> wrong?
>> So also this time.
>>
>>> [...] the correct and complete simulation of a
>>> machine description [...]
>>
>> Machine descriptions are never simulated -- they're just sequences
>> of symbols.
>> and don't have any defined behaviour. The machines they *represent*
>> may be
>> simulated.
>>
>>> [...] always provides the actual behavior specified by
>>> this machine description.
>>
>> This is almost, but not quite, correct (if you fix it according to
>> the
>> previous paragraph). It would have been completely correct, if it
>> weren't
>> for the fact that you're using an utterly bizarre meaning for the
>> phrase
>> "the actual behavior specified by this machine description".
>>
>>> That you and others reject this when it is applied to my simulating halt
>>> decider implicitly rejects the notion of a UTM. Since you and others do
>>> accept the notion of a UTM, I have just proven that your reasoning is
>>> incoherent and/or inconsistent.
>>
>> Let M be a given machine, with machine description [M], and let w
>> be
>> a given input tape, with tape description [w]. Then the
>> "simulation"
>> UTM([M],[w]) has exactly the same result (i.e. exactly the same
>> behaviour)
>> as the direct computation M(w). This is actually the definition of
>> a UTM.
>>
>> Another way of expressing this is: M(w) and UTM([M],[w]) compute
>> the same
>> partial function.
>>
>> You have made it abundantly clear that when you say "the actual
>> behavior
>> specified by this machine description", you do *not* mean "the
>> actual
>> behavior specified by this machine description", because that's
>> simply
>> the behaviour of M(w). What you *do* mean is "the behaviour of your
>> particular, broken and incomplete, quasi-simulation based on [M]
>> and [w]".
>>
>> Why is it broken? Because it *doesn't* have the same behaviour as M
>> (w),
>> nor as UTM([M],[w]). A correct simulation *means* that it has the
>> same
>> behaviour as M(w).
>>
>> Why is it incomplete? Because it aborts its "simulation" before it
>> reaches
>> a halting configuration of the machine represented by its input,
>> and it
>> does so on invalidly.
>>
>> Why is it a quasi-simulation? Because it depends on external input
>> that is
>> contained in neither [M] nor [w]. You have said, on numerous
>> occasions,
>> that the behaviour of your "H(P,P)" depends on the specific memory
>> location of "P". Well, then that location is an external input.
>> Your H is
>> *not* analogous to Linz' H([M],[w]).
>>
>> This is the point where you usually barf up your stanza about how
>> the
>> behaviour of your "H(P,P)" cannot be expected to be computed "from
>> the
>> non-input P(P)". This is obviously idiotic, for the following
>> reasons:
>>
>> 1) A purported halt decider H([M],[w]) is *not* required to compute
>> its
>>     result *from* M(w), but to *match* M(w). Computing *from* M(w)
>> would be
>>     completely pointless, because the decider would already know the
>> answer.
>>
>>     Since you seem unable to understand anything but arguments from
>>     analogy, let me re-use one that you yourself have employed:
>> Suppose
>>     we want to construct an addition algorithm add(x,y). If you were
>> to
>>     complain that add(5,7) cannot be required to compute its result
>> "from
>>     the non-input 12", you would, quite rightly, be regarded as a
>> complete
>>     nitwit. Can you now guess why you're universally regarded as a
>> complete
>>     nitwit?
>>
>> 2) The behaviour of UTM([M],[w]) is *defined* to match the
>> behaviour of M(w),
>>     and UTMs very evidently do exist. The information contained in
>> [M] and [w]
>>     is obviously enough to match the behaviour of M(w). The fact
>> that your
>>     "simulator" fails in this regard, is proof that your
>> "simulator" is
>>     defective -- *not* that you have discovered a "loop hole", or
>> that halting
>>     theorem is faulty, or anything of that kind -- only that you're
>> working
>>     with a broken simulator.
>>
>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>>
>> A lot of people have pointed out many kinds of errors in your
>> reasoning.
>> You usually respond with some form "proof by regurgitation". I
>> expect you
>> will do so to this post.
>>
>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>> partial simulation of its input and the behavior of this partial
>>> simulation correctly matches a non-halting behavior pattern then the SHD
>>> halt decider can correctly report non-halting.
>>>
>>> A non-halting behavior pattern is correct when-so-ever matching this
>>> behavior pattern proves that the correct and complete simulation of the
>>> input by SHD would never reach the final state of this simulated input.
>>
>> Yeah, that's just a bunch of equivocations on "correctly", "its
>> input",
>> "non-halting behavior", and more.  Please learn to write clearly.
>>
>>
>> Also, could you *please* stop misreading Linz! He *doesn't* say
>> that a TM
>> halts, only if it enters a "final state". What he actually says is:
>>
>>      "A Turing machine is said to halt whenever it reaches a
>> configuration
>>      for which delta is not defined; this is possible because delta
>> is a
>>      partial function. In fact, we will assume that no transitions
>> are
>>      defined for any final state, so the Turing machine will halt
>> whenever
>>      it enters a final state."
>>
>> So, for a general TM, there may well be configurations for which
>> the TM
>> halts in a non-final state. It is, on the other hand, understood
>> that a TM
>> *only* stops running if enters a configuration for which the
>> transition
>> function is undefined.
>>
>> "Final states" only concern the *interpretation* of the value of a
>> computation -- *not* whether the TM halts or not.
>>
>> This means that "halting" and "stops running" are the exact the
>> same things.
>> And obviously, "running" and "being simulated" are two entirely
>> different
>> things.
>>
>>
>
> void P(ptr x)
> {
>   int Halt_Status = UTM(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> The behavior of the actual input to the simulating halt decider is the
> behavior of the above. Since C functions do not actually have UTM's a
> more accurate way of sayoing this is:
>
> void P(ptr x)
> {
>   int Halt_Status = Simulate(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> The behavior of UTM(P,P) or Simulate(P,P) is not the behavior of the
> actual input to H(P,P) because it is at a different point in the
> execution trace than H(P,P).
>

Wrong, at least if H is supposed to be a Halt Decider.

You forget the question that the Halt Decider is being asked to solve,
which is what the machine represented by its input would do.

That starts at that exact point.

You are just confirming that you H isn't actually a Halt Decider, even
though you claim it is, which just proves you are a LIAR.