On 12/4/21 11:52 PM, olcott wrote:
> On 12/4/2021 7:54 PM, Richard Damon wrote:
>> On 12/4/21 8:31 PM, olcott wrote:
>>> On 12/4/2021 7:18 PM, Richard Damon wrote:
>>>> On 12/4/21 8:04 PM, olcott wrote:
>>>>> On 12/4/2021 6:28 PM, Richard Damon wrote:
>>>>>> On 12/4/21 6:04 PM, olcott wrote:
>>>>>>> On 12/4/2021 4:41 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> I spent two years creating the UTM operating system to that H
>>>>>>>>> correctly decide the halt status of its input automatically.
>>>>>>>>
>>>>>>>> And yet *three* years ago (give or take 10 days) you said:
>>>>>>>>
>>>>>>>>    "I now have an actual H that decides actual halting for an
>>>>>>>> actual (Ĥ,
>>>>>>>>    Ĥ) input pair.  I have to write the UTM to execute this code,
>>>>>>>> that
>>>>>>>>    should not take very long."
>>>>>>>>
>>>>>>>> and
>>>>>>>>
>>>>>>>>    "I am waiting to encode the UTM in C++ so that I can actually
>>>>>>>> execute
>>>>>>>>    H on the input pair: (Ĥ, Ĥ). This should take a week or two.
>>>>>>>> It is not
>>>>>>>>    a universal halt decider, yet it is exactly and precisely the
>>>>>>>> Peter
>>>>>>>>    Linz H and Ĥ, with H actually deciding input pair: (Ĥ, Ĥ) on
>>>>>>>> the basis
>>>>>>>>    of Ĥ actually deciding itself."
>>>>>>>>
>>>>>>>> Where did it all go wrong?  The only significant new information
>>>>>>>> to seep
>>>>>>>> out in the last three years is that H gives the wrong answer for
>>>>>>>> the
>>>>>>>> input pair (Ĥ, Ĥ).
>>>>>>>>
>>>>>>>
>>>>>>> Yet another dishonest dodge (strawman error) away from the point:
>>>>>>>
>>>>>>> [Olcott 2021 generic halt deciding principle] Whenever the pure
>>>>>>> simulation of the input to simulating halt decider H(x,y) never
>>>>>>> stops running unless H aborts its simulation H correctly aborts
>>>>>>> this simulation and returns 0 for not halting. is true by logical
>>>>>>> necessity (The same way that we know all black cats are cats).
>>>>>>>
>>>>>>
>>>>>> But you haven't shown that you CAN make such a decider.
>>>>>>
>>>>>
>>>>> X86 machine code and execution trace of {main, H, and P}
>>>>>
>>>>> _H()
>>>>> [00001a6e](01)  55              push ebp
>>>>> [00001a6f](02)  8bec            mov ebp,esp
>>>>> [00001a71](03)  8b450c          mov eax,[ebp+0c]
>>>>> [00001a74](01)  50              push eax            // push 2nd param
>>>>> [00001a75](03)  ff5508          call dword [ebp+08] // call 1st
>>>>> param with 2nd param
>>>>> [00001a78](03)  83c404          add esp,+04
>>>>> [00001a7b](05)  b801000000      mov eax,00000001
>>>>> [00001a80](01)  5d              pop ebp
>>>>> [00001a81](01)  c3              ret
>>>>> Size in bytes:(0020) [00001a81]
>>>>>
>>>>> _P()
>>>>> [00001a8e](01)  55              push ebp
>>>>> [00001a8f](02)  8bec            mov ebp,esp
>>>>> [00001a91](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001a94](01)  50              push eax         // push 2nd param
>>>>> [00001a95](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [00001a98](01)  51              push ecx         // push 1st param
>>>>> [00001a99](05)  e8d0ffffff      call 00001a6e    // call H
>>>>> [00001a9e](03)  83c408          add esp,+08
>>>>> [00001aa1](02)  85c0            test eax,eax
>>>>> [00001aa3](02)  7402            jz 00001aa7
>>>>> [00001aa5](02)  ebfe            jmp 00001aa5
>>>>> [00001aa7](01)  5d              pop ebp
>>>>> [00001aa8](01)  c3              ret
>>>>> Size in bytes:(0027) [00001aa8]
>>>>>
>>>>> _main()
>>>>> [00001aae](01)  55              push ebp
>>>>> [00001aaf](02)  8bec            mov ebp,esp
>>>>> [00001ab1](05)  688e1a0000      push 00001a8e   // push P
>>>>> [00001ab6](05)  e8d3ffffff      call 00001a8e   // call P
>>>>> [00001abb](03)  83c404          add esp,+04
>>>>> [00001abe](02)  33c0            xor eax,eax
>>>>> [00001ac0](01)  5d              pop ebp
>>>>> [00001ac1](01)  c3              ret
>>>>> Size in bytes:(0020) [00001ac1]
>>>>>
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [00001aae][00102ec9][00000000] 55         push ebp
>>>>> [00001aaf][00102ec9][00000000] 8bec       mov ebp,esp
>>>>> [00001ab1][00102ec5][00001a8e] 688e1a0000 push 00001a8e       //
>>>>> push P
>>>>> [00001ab6][00102ec1][00001abb] e8d3ffffff call 00001a8e       //
>>>>> call P
>>>>> [00001a8e][00102ebd][00102ec9] 55         push ebp
>>>>> [00001a8f][00102ebd][00102ec9] 8bec       mov ebp,esp
>>>>> [00001a91][00102ebd][00102ec9] 8b4508     mov eax,[ebp+08]
>>>>> [00001a94][00102eb9][00001a8e] 50         push eax            //
>>>>> push P
>>>>> [00001a95][00102eb9][00001a8e] 8b4d08     mov ecx,[ebp+08]
>>>>> [00001a98][00102eb5][00001a8e] 51         push ecx            //
>>>>> push P
>>>>> [00001a99][00102eb1][00001a9e] e8d0ffffff call 00001a6e       //
>>>>> call H
>>>>> [00001a6e][00102ead][00102ebd] 55         push ebp
>>>>> [00001a6f][00102ead][00102ebd] 8bec       mov ebp,esp
>>>>> [00001a71][00102ead][00102ebd] 8b450c     mov eax,[ebp+0c]
>>>>> [00001a74][00102ea9][00001a8e] 50         push eax            //
>>>>> push P
>>>>> [00001a75][00102ea5][00001a78] ff5508     call dword [ebp+08] //
>>>>> call P
>>>>> [00001a8e][00102ea1][00102ead] 55         push ebp
>>>>> [00001a8f][00102ea1][00102ead] 8bec       mov ebp,esp
>>>>> [00001a91][00102ea1][00102ead] 8b4508     mov eax,[ebp+08]
>>>>> [00001a94][00102e9d][00001a8e] 50         push eax
>>>>> [00001a95][00102e9d][00001a8e] 8b4d08     mov ecx,[ebp+08]
>>>>> [00001a98][00102e99][00001a8e] 51         push ecx
>>>>> [00001a99][00102e95][00001a9e] e8d0ffffff call 00001a6e       //
>>>>> call H
>>>>> [00001a6e][00102e91][00102ea1] 55         push ebp            //
>>>>> push P
>>>>> [00001a6f][00102e91][00102ea1] 8bec       mov ebp,esp
>>>>> [00001a71][00102e91][00102ea1] 8b450c     mov eax,[ebp+0c]
>>>>> [00001a74][00102e8d][00001a8e] 50         push eax            //
>>>>> push P
>>>>> [00001a75][00102e89][00001a78] ff5508     call dword [ebp+08] //
>>>>> call P
>>>>> [00001a8e][00102e85][00102e91] 55         push ebp
>>>>> [00001a8f][00102e85][00102e91] 8bec       mov ebp,esp
>>>>> [00001a91][00102e85][00102e91] 8b4508     mov eax,[ebp+08]
>>>>> [00001a94][00102e81][00001a8e] 50         push eax
>>>>> [00001a95][00102e81][00001a8e] 8b4d08     mov ecx,[ebp+08]
>>>>> [00001a98][00102e7d][00001a8e] 51         push ecx
>>>>> [00001a99][00102e79][00001a9e] e8d0ffffff call 00001a6e       //
>>>>> call H
>>>>> [00001a6e][00102e75][00102e85] 55         push ebp
>>>>> [00001a6f][00102e75][00102e85] 8bec       mov ebp,esp
>>>>> [00001a71][00102e75][00102e85] 8b450c     mov eax,[ebp+0c]
>>>>> [00001a74][00102e71][00001a8e] 50         push eax            //
>>>>> push P
>>>>> [00001a75][00102e6d][00001a78] ff5508     call dword [ebp+08] //
>>>>> call P
>>>>> [00001a8e][00102e69][00102e75] 55         push ebp            //
>>>>> push P
>>>>> [00001a8f][00102e69][00102e75] 8bec       mov ebp,esp
>>>>> [00001a91][00102e69][00102e75] 8b4508     mov eax,[ebp+08]
>>>>> [00001a94][00102e65][00001a8e] 50         push eax            //
>>>>> push P
>>>>> [00001a95][00102e65][00001a8e] 8b4d08     mov ecx,[ebp+08]
>>>>> [00001a98][00102e61][00001a8e] 51         push ecx            //
>>>>> push P
>>>>> [00001a99][00102e5d][00001a9e] e8d0ffffff call 00001a6e       //
>>>>> call H
>>>>> [00001a6e][00102e59][00102e69] 55         push ebp
>>>>> [00001a6f][00102e59][00102e69] 8bec       mov ebp,esp
>>>>> [00001a71][00102e59][00102e69] 8b450c     mov eax,[ebp+0c]
>>>>> [00001a74][00102e55][00001a8e] 50         push eax            //
>>>>> push P
>>>>> [00001a75][00102e51][00001a78] ff5508     call dword [ebp+08] //
>>>>> call P
>>>>> [00001a8e][00102e4d][00102e59] 55         push ebp            //
>>>>> push P
>>>>
>>>>
>>>> So, you have just showed that THIS H fails by never answering.
>>>>
>>>
>>> No I showed all of the details of exactly how any technically
>>> competent person that knows the x86 language could write a simple C
>>> program that turns H into a correct halt decider for input (P,P).
>>
>> No, you haven't. Only how a technically INcompetent person can think
>> they did it.
>>
>> You 'details' basically said 'solve the halting problem', not how to
>> do it.
>>
>
> The above details are very simple for any competent C programmer that
> knows the x86 language, obviously not you.
>

On 12/4/2021 11:47 PM, wij wrote:
> On Sunday, 5 December 2021 at 09:03:40 UTC+8, olcott wrote:
>> On 12/4/2021 4:44 PM, wij wrote:
>>> On Sunday, 5 December 2021 at 05:30:26 UTC+8, olcott wrote:
>>>> On 12/4/2021 2:32 PM, wij wrote:
>>>>> On Sunday, 5 December 2021 at 03:59:44 UTC+8, olcott wrote:
>>>>>> On 12/4/2021 1:45 PM, wij wrote:
>>>>>>> On Sunday, 5 December 2021 at 03:24:33 UTC+8, olcott wrote:
>>>>>>>> On 12/4/2021 12:59 PM, wij wrote:
>>>>>>>>> On Sunday, 5 December 2021 at 02:47:14 UTC+8, olcott wrote:
>>>>>>>>>> On 12/4/2021 12:45 PM, olcott wrote:
>>>>>>>>>>> On 12/4/2021 12:37 PM, wij wrote:
>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:07:53 UTC+8, olcott wrote:
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> x(y);
>>>>>>>>>>>>>> return 1;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H can only return 1 or never returns. Do you agree?
>>>>>>>>>>>>>> I had asked the same question, you did not answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> // Simplified Linz(1990) Ĥ
>>>>>>>>>>>>> // and Strachey(1965) P
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>> }
>>>>>>>>>>>>> When that H has (P,P) as input it can only never return.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>
>>>>>>>>>>>> Halting decider H has to return {0,1} (or reject, accept) for the
>>>>>>>>>>>> given inputs.
>>>>>>>>>>>> Your H clearly can only return 1, not a halting decider.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ARE YOU BRAIN-DEAD ???
>>>>>>>>>>>
>>>>>>>>>>> Whenever the pure simulation of the input to simulating halt decider
>>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
>>>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>>>>>
>>>>>>>>>> THIS IS A GENERAL PRINCIPLE:
>>>>>>>>>> Whenever the pure simulation of [ANY] input to [ANY] simulating halt
>>>>>>>>>> decider H(x,y) never stops running unless H aborts its simulation H
>>>>>>>>>> correctly aborts this simulation and returns 0 for not halting.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> One problem is that H contains no 'abort' instruction, or you abort it manually
>>>>>>>>> and claim that you have built a H successfully?
>>>>>>>>>
>>>>>>>> I spent two years creating the x86utm operating system based on an x86
>>>>>>>> emulator so that an actual H recognizes the infinitely recursive
>>>>>>>> behavior pattern of P. H is a pure function, thus a computation.
>>>>>>>>
>>>>>>>> Page 7-8 show a complete trace.
>>>>>>>>
>>>>>>>
>>>>>>> IIRC, x86 has no 'abort' instruction.
>>>>>>> There is no 'abort' function call in Page 7-8 neither.
>>>>>>> Do you manually abort the program execution?
>>>>>> The x86utm operating system has this operating system function call:
>>>>>>
>>>>>> u32 DebugStep(Registers* master_state,
>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>
>>>>> So what?
>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>
>>>> I spent two years creating the UTM operating system to that H correctly
>>>> decide the halt status of its input automatically.
>>>
>>> All we have is what you say.
>>> So far, no one can confirm what you did, even remotely, imaginary.
>>>
>>>>>>>> int main() { P(P); } calls H(P,P) simulates and aborts P(P)
>>>>>>>> Halting problem undecidability and infinitely nested simulation (V2)
>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>>> Where is the "return 0" is H?
>>>>>>>>> Where is the 'abort' instruction in H?
>>>>>>>>>
>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>>
>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>> No function f can decide the property of another function g that g can defy.
>>>>>>>>>
>>>>>>>
>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>> Actually, it is OK, if you decide manually to 'abort' to return whatever value.
>>>>>>> Since it does not change the conclusion, what GUR says remains holds.
>>>>>>>
>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>> No function f can decide the property of another function g that g can defy.
>>>>>>>
>>>>>>> Even anyone's god cannot solve the Halting problem.
>>>>>>>
>>>>>> Now we construct a new Turing machine D with H as a subroutine.
>>>>>> This new TM calls H to determine what M does when the input to M
>>>>>> is its own description ⟨M⟩. Once D has determined this information,
>>>>>> it does the opposite. (Sipser:1997:165)
>>>>>
>>>>> .Decision problems –
>>>>> A decision problem has only two possible outputs (yes or no) on any input. In computability theory and computational complexity theory, a decision problem is a problem that can be posed as a yes-no question of the input values. Like is there any solution to a particular problem? The answer would be either a yes or no. A decision problem is any arbitrary yes/no question on an infinite set of inputs.
>>>>> Turing machine –
>>>>> A Turing machine is a mathematical model of computation. A Turing machine is a general example of a CPU that controls all data manipulation done by a computer. Turing machine can be halting as well as non halting and it depends on algorithm and input associated with the algorithm.
>>>>>
>>>>> Now, lets discuss Halting problem:
>>>>> ... More in
>>>>> https://www.geeksforgeeks.org/halting-problem-in-theory-of-computation/
>>>>>
>>>>>> On 12/3/2021 6:18 PM, olcott wrote:
>>>>>>> Whenever the pure simulation of the input to simulating halt decider
>>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>> Since H never returns any value until after it has already made its halt
>>>>>> status decision there is no (conventional HP) feedback loop between the
>>>>>> halt decider and its input. This makes the conventional HP inputs
>>>>>> decidable.
>>>>>
>>>>> I don't see any corresponding codes in your H matches what you said.
>>>>>
>>>> My actual H is hundreds of pages long. If you look at pages 3 and 4 is
>>>> is very obvious that H could recognize the infinite recursion behavior
>>>> pattern of P.
>>>> Halting problem undecidability and infinitely nested simulation (V2)
>>>>
>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>
>>> "hundreds of pages long" means nothing to 'software engineer'.
>>>
>>> --- file t.c (from page 3)
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>> int H(ptr x, ptr y)
>>> {
>>> x(y);
>>> return 1;
>>> }
>>> // Simplified Linz(1990) Ĥ
>>> // and Strachey(1965) P
>>> void P(ptr x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>>> int main(void)
>>> {
>>> P(P);
>>> }
>>>
>>> []$ gcc t.c
>>> []$ ./a.out
>>> Segmentation fault (core dumped)
>>> ---
>>>
>>> I don's see H could recognize the infinite recursion behavior pattern of P,
>>> because of "Segmentation fault (core dumped)".
>> H simulates P(P) is debug step mode and stops as soon as P calls H(P,P)
>> with the same input that H(P,P) was called with.
>
> This saying means you conduct how H should stop/continue/abort... *manually*.
>
> ...[snipet from previous post]
>>>> u32 DebugStep(Registers* master_state,
>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>
>>> So what?
>>> Did you input any manual inputs? And thus make your conclusion?
>>>
>> I spent two years creating the UTM operating system to that H correctly
>> decide the halt status of its input automatically.
>
> The previous saying is that "H correctly decide the halt status of its input automatically."
> So, your 'automatically' means the same as 'manually'?
>

On Sunday, 5 December 2021 at 22:44:38 UTC+8, olcott wrote:
> On 12/4/2021 11:47 PM, wij wrote:
> > On Sunday, 5 December 2021 at 09:03:40 UTC+8, olcott wrote:
> >> On 12/4/2021 4:44 PM, wij wrote:
> >>> On Sunday, 5 December 2021 at 05:30:26 UTC+8, olcott wrote:
> >>>> On 12/4/2021 2:32 PM, wij wrote:
> >>>>> On Sunday, 5 December 2021 at 03:59:44 UTC+8, olcott wrote:
> >>>>>> On 12/4/2021 1:45 PM, wij wrote:
> >>>>>>> On Sunday, 5 December 2021 at 03:24:33 UTC+8, olcott wrote:
> >>>>>>>> On 12/4/2021 12:59 PM, wij wrote:
> >>>>>>>>> On Sunday, 5 December 2021 at 02:47:14 UTC+8, olcott wrote:
> >>>>>>>>>> On 12/4/2021 12:45 PM, olcott wrote:
> >>>>>>>>>>> On 12/4/2021 12:37 PM, wij wrote:
> >>>>>>>>>>>> On Sunday, 5 December 2021 at 02:07:53 UTC+8, olcott wrote:
> >>>>>>>>>>>>> ...
> >>>>>>>>>>>>>> int H(ptr x, ptr y)
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> x(y);
> >>>>>>>>>>>>>> return 1;
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> H can only return 1 or never returns. Do you agree?
> >>>>>>>>>>>>>> I had asked the same question, you did not answer.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> // Simplified Linz(1990) Ĥ
> >>>>>>>>>>>>> // and Strachey(1965) P
> >>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>> When that H has (P,P) as input it can only never return.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>
> >>>>>>>>>>>> Halting decider H has to return {0,1} (or reject, accept) for the
> >>>>>>>>>>>> given inputs.
> >>>>>>>>>>>> Your H clearly can only return 1, not a halting decider.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> ARE YOU BRAIN-DEAD ???
> >>>>>>>>>>>
> >>>>>>>>>>> Whenever the pure simulation of the input to simulating halt decider
> >>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
> >>>>>>>>>>> aborts this simulation and returns 0 for not halting.
> >>>>>>>>>>>
> >>>>>>>>>> THIS IS A GENERAL PRINCIPLE:
> >>>>>>>>>> Whenever the pure simulation of [ANY] input to [ANY] simulating halt
> >>>>>>>>>> decider H(x,y) never stops running unless H aborts its simulation H
> >>>>>>>>>> correctly aborts this simulation and returns 0 for not halting..
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> One problem is that H contains no 'abort' instruction, or you abort it manually
> >>>>>>>>> and claim that you have built a H successfully?
> >>>>>>>>>
> >>>>>>>> I spent two years creating the x86utm operating system based on an x86
> >>>>>>>> emulator so that an actual H recognizes the infinitely recursive
> >>>>>>>> behavior pattern of P. H is a pure function, thus a computation.
> >>>>>>>>
> >>>>>>>> Page 7-8 show a complete trace.
> >>>>>>>>
> >>>>>>>
> >>>>>>> IIRC, x86 has no 'abort' instruction.
> >>>>>>> There is no 'abort' function call in Page 7-8 neither.
> >>>>>>> Do you manually abort the program execution?
> >>>>>> The x86utm operating system has this operating system function call:
> >>>>>>
> >>>>>> u32 DebugStep(Registers* master_state,
> >>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
> >>>>>
> >>>>> So what?
> >>>>> Did you input any manual inputs? And thus make your conclusion?
> >>>>>
> >>>> I spent two years creating the UTM operating system to that H correctly
> >>>> decide the halt status of its input automatically.
> >>>
> >>> All we have is what you say.
> >>> So far, no one can confirm what you did, even remotely, imaginary.
> >>>
> >>>>>>>> int main() { P(P); } calls H(P,P) simulates and aborts P(P)
> >>>>>>>> Halting problem undecidability and infinitely nested simulation (V2)
> >>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
> >>>>>>>>> Where is the "return 0" is H?
> >>>>>>>>> Where is the 'abort' instruction in H?
> >>>>>>>>>
> >>>>>>>>> Note: We do not actually need to know how H is implemented.
> >>>>>>>>>
> >>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
> >>>>>>>>> No function f can decide the property of another function g that g can defy.
> >>>>>>>>>
> >>>>>>>
> >>>>>>> Note: We do not actually need to know how H is implemented.
> >>>>>>> Actually, it is OK, if you decide manually to 'abort' to return whatever value.
> >>>>>>> Since it does not change the conclusion, what GUR says remains holds.
> >>>>>>>
> >>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
> >>>>>>> No function f can decide the property of another function g that g can defy.
> >>>>>>>
> >>>>>>> Even anyone's god cannot solve the Halting problem.
> >>>>>>>
> >>>>>> Now we construct a new Turing machine D with H as a subroutine.
> >>>>>> This new TM calls H to determine what M does when the input to M
> >>>>>> is its own description ⟨M⟩. Once D has determined this information,
> >>>>>> it does the opposite. (Sipser:1997:165)
> >>>>>
> >>>>> .Decision problems –
> >>>>> A decision problem has only two possible outputs (yes or no) on any input. In computability theory and computational complexity theory, a decision problem is a problem that can be posed as a yes-no question of the input values. Like is there any solution to a particular problem? The answer would be either a yes or no. A decision problem is any arbitrary yes/no question on an infinite set of inputs.
> >>>>> Turing machine –
> >>>>> A Turing machine is a mathematical model of computation. A Turing machine is a general example of a CPU that controls all data manipulation done by a computer. Turing machine can be halting as well as non halting and it depends on algorithm and input associated with the algorithm.
> >>>>>
> >>>>> Now, lets discuss Halting problem:
> >>>>> ... More in
> >>>>> https://www.geeksforgeeks.org/halting-problem-in-theory-of-computation/
> >>>>>
> >>>>>> On 12/3/2021 6:18 PM, olcott wrote:
> >>>>>>> Whenever the pure simulation of the input to simulating halt decider
> >>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
> >>>>>>> aborts this simulation and returns 0 for not halting.
> >>>>>> Since H never returns any value until after it has already made its halt
> >>>>>> status decision there is no (conventional HP) feedback loop between the
> >>>>>> halt decider and its input. This makes the conventional HP inputs
> >>>>>> decidable.
> >>>>>
> >>>>> I don't see any corresponding codes in your H matches what you said..
> >>>>>
> >>>> My actual H is hundreds of pages long. If you look at pages 3 and 4 is
> >>>> is very obvious that H could recognize the infinite recursion behavior
> >>>> pattern of P.
> >>>> Halting problem undecidability and infinitely nested simulation (V2)
> >>>>
> >>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
> >>>
> >>> "hundreds of pages long" means nothing to 'software engineer'.
> >>>
> >>> --- file t.c (from page 3)
> >>> #include <stdint.h>
> >>> typedef void (*ptr)();
> >>> int H(ptr x, ptr y)
> >>> {
> >>> x(y);
> >>> return 1;
> >>> }
> >>> // Simplified Linz(1990) Ĥ
> >>> // and Strachey(1965) P
> >>> void P(ptr x)
> >>> {
> >>> if (H(x, x))
> >>> HERE: goto HERE;
> >>> }
> >>> int main(void)
> >>> {
> >>> P(P);
> >>> }
> >>>
> >>> []$ gcc t.c
> >>> []$ ./a.out
> >>> Segmentation fault (core dumped)
> >>> ---
> >>>
> >>> I don's see H could recognize the infinite recursion behavior pattern of P,
> >>> because of "Segmentation fault (core dumped)".
> >> H simulates P(P) is debug step mode and stops as soon as P calls H(P,P)
> >> with the same input that H(P,P) was called with.
> >
> > This saying means you conduct how H should stop/continue/abort... *manually*.
> >
> > ...[snipet from previous post]
> >>>> u32 DebugStep(Registers* master_state,
> >>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
> >>>
> >>> So what?
> >>> Did you input any manual inputs? And thus make your conclusion?
> >>>
> >> I spent two years creating the UTM operating system to that H correctly
> >> decide the halt status of its input automatically.
> >
> > The previous saying is that "H correctly decide the halt status of its input automatically."
> > So, your 'automatically' means the same as 'manually'?
> >
> If it is obvious to every competent C/C++ programmer that knows the x86
> language how to write the code for H to recognize this very obvious
> infinite recursion pattern then it can be known that such a decider can
> exist:

On 12/5/2021 9:52 AM, wij wrote:
> On Sunday, 5 December 2021 at 22:44:38 UTC+8, olcott wrote:
>> On 12/4/2021 11:47 PM, wij wrote:
>>> On Sunday, 5 December 2021 at 09:03:40 UTC+8, olcott wrote:
>>>> On 12/4/2021 4:44 PM, wij wrote:
>>>>> On Sunday, 5 December 2021 at 05:30:26 UTC+8, olcott wrote:
>>>>>> On 12/4/2021 2:32 PM, wij wrote:
>>>>>>> On Sunday, 5 December 2021 at 03:59:44 UTC+8, olcott wrote:
>>>>>>>> On 12/4/2021 1:45 PM, wij wrote:
>>>>>>>>> On Sunday, 5 December 2021 at 03:24:33 UTC+8, olcott wrote:
>>>>>>>>>> On 12/4/2021 12:59 PM, wij wrote:
>>>>>>>>>>> On Sunday, 5 December 2021 at 02:47:14 UTC+8, olcott wrote:
>>>>>>>>>>>> On 12/4/2021 12:45 PM, olcott wrote:
>>>>>>>>>>>>> On 12/4/2021 12:37 PM, wij wrote:
>>>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:07:53 UTC+8, olcott wrote:
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> x(y);
>>>>>>>>>>>>>>>> return 1;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H can only return 1 or never returns. Do you agree?
>>>>>>>>>>>>>>>> I had asked the same question, you did not answer.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> // Simplified Linz(1990) Ĥ
>>>>>>>>>>>>>>> // and Strachey(1965) P
>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> When that H has (P,P) as input it can only never return.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Halting decider H has to return {0,1} (or reject, accept) for the
>>>>>>>>>>>>>> given inputs.
>>>>>>>>>>>>>> Your H clearly can only return 1, not a halting decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ARE YOU BRAIN-DEAD ???
>>>>>>>>>>>>>
>>>>>>>>>>>>> Whenever the pure simulation of the input to simulating halt decider
>>>>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
>>>>>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>>>>>>>
>>>>>>>>>>>> THIS IS A GENERAL PRINCIPLE:
>>>>>>>>>>>> Whenever the pure simulation of [ANY] input to [ANY] simulating halt
>>>>>>>>>>>> decider H(x,y) never stops running unless H aborts its simulation H
>>>>>>>>>>>> correctly aborts this simulation and returns 0 for not halting.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> One problem is that H contains no 'abort' instruction, or you abort it manually
>>>>>>>>>>> and claim that you have built a H successfully?
>>>>>>>>>>>
>>>>>>>>>> I spent two years creating the x86utm operating system based on an x86
>>>>>>>>>> emulator so that an actual H recognizes the infinitely recursive
>>>>>>>>>> behavior pattern of P. H is a pure function, thus a computation.
>>>>>>>>>>
>>>>>>>>>> Page 7-8 show a complete trace.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> IIRC, x86 has no 'abort' instruction.
>>>>>>>>> There is no 'abort' function call in Page 7-8 neither.
>>>>>>>>> Do you manually abort the program execution?
>>>>>>>> The x86utm operating system has this operating system function call:
>>>>>>>>
>>>>>>>> u32 DebugStep(Registers* master_state,
>>>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>>>
>>>>>>> So what?
>>>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>>>
>>>>>> I spent two years creating the UTM operating system to that H correctly
>>>>>> decide the halt status of its input automatically.
>>>>>
>>>>> All we have is what you say.
>>>>> So far, no one can confirm what you did, even remotely, imaginary.
>>>>>
>>>>>>>>>> int main() { P(P); } calls H(P,P) simulates and aborts P(P)
>>>>>>>>>> Halting problem undecidability and infinitely nested simulation (V2)
>>>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>>>>> Where is the "return 0" is H?
>>>>>>>>>>> Where is the 'abort' instruction in H?
>>>>>>>>>>>
>>>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>>>>
>>>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>>>> No function f can decide the property of another function g that g can defy.
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>> Actually, it is OK, if you decide manually to 'abort' to return whatever value.
>>>>>>>>> Since it does not change the conclusion, what GUR says remains holds.
>>>>>>>>>
>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>> No function f can decide the property of another function g that g can defy.
>>>>>>>>>
>>>>>>>>> Even anyone's god cannot solve the Halting problem.
>>>>>>>>>
>>>>>>>> Now we construct a new Turing machine D with H as a subroutine.
>>>>>>>> This new TM calls H to determine what M does when the input to M
>>>>>>>> is its own description ⟨M⟩. Once D has determined this information,
>>>>>>>> it does the opposite. (Sipser:1997:165)
>>>>>>>
>>>>>>> .Decision problems –
>>>>>>> A decision problem has only two possible outputs (yes or no) on any input. In computability theory and computational complexity theory, a decision problem is a problem that can be posed as a yes-no question of the input values. Like is there any solution to a particular problem? The answer would be either a yes or no. A decision problem is any arbitrary yes/no question on an infinite set of inputs.
>>>>>>> Turing machine –
>>>>>>> A Turing machine is a mathematical model of computation. A Turing machine is a general example of a CPU that controls all data manipulation done by a computer. Turing machine can be halting as well as non halting and it depends on algorithm and input associated with the algorithm.
>>>>>>>
>>>>>>> Now, lets discuss Halting problem:
>>>>>>> ... More in
>>>>>>> https://www.geeksforgeeks.org/halting-problem-in-theory-of-computation/
>>>>>>>
>>>>>>>> On 12/3/2021 6:18 PM, olcott wrote:
>>>>>>>>> Whenever the pure simulation of the input to simulating halt decider
>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>> Since H never returns any value until after it has already made its halt
>>>>>>>> status decision there is no (conventional HP) feedback loop between the
>>>>>>>> halt decider and its input. This makes the conventional HP inputs
>>>>>>>> decidable.
>>>>>>>
>>>>>>> I don't see any corresponding codes in your H matches what you said.
>>>>>>>
>>>>>> My actual H is hundreds of pages long. If you look at pages 3 and 4 is
>>>>>> is very obvious that H could recognize the infinite recursion behavior
>>>>>> pattern of P.
>>>>>> Halting problem undecidability and infinitely nested simulation (V2)
>>>>>>
>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>
>>>>> "hundreds of pages long" means nothing to 'software engineer'.
>>>>>
>>>>> --- file t.c (from page 3)
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>> x(y);
>>>>> return 1;
>>>>> }
>>>>> // Simplified Linz(1990) Ĥ
>>>>> // and Strachey(1965) P
>>>>> void P(ptr x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>> int main(void)
>>>>> {
>>>>> P(P);
>>>>> }
>>>>>
>>>>> []$ gcc t.c
>>>>> []$ ./a.out
>>>>> Segmentation fault (core dumped)
>>>>> ---
>>>>>
>>>>> I don's see H could recognize the infinite recursion behavior pattern of P,
>>>>> because of "Segmentation fault (core dumped)".
>>>> H simulates P(P) is debug step mode and stops as soon as P calls H(P,P)
>>>> with the same input that H(P,P) was called with.
>>>
>>> This saying means you conduct how H should stop/continue/abort... *manually*.
>>>
>>> ...[snipet from previous post]
>>>>>> u32 DebugStep(Registers* master_state,
>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>
>>>>> So what?
>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>
>>>> I spent two years creating the UTM operating system to that H correctly
>>>> decide the halt status of its input automatically.
>>>
>>> The previous saying is that "H correctly decide the halt status of its input automatically."
>>> So, your 'automatically' means the same as 'manually'?
>>>
>> If it is obvious to every competent C/C++ programmer that knows the x86
>> language how to write the code for H to recognize this very obvious
>> infinite recursion pattern then it can be known that such a decider can
>> exist:
>
> I would say you don't have the real functioning H but claims.
>
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> int H(ptr x, ptr y)
>> {
>> x(y);
>> return 1;
>> }
>>
>> // Simplified Linz(1990) Ĥ
>> // and Strachey(1965) P
>> void P(ptr x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> int main(void)
>> {
>> P(P);
>> }
>
> If you are honest about your H, it is very obvious that H can only return 1 or
> never return. Therefore, this H is not a decider.
>

On Monday, 6 December 2021 at 00:08:01 UTC+8, olcott wrote:
> On 12/5/2021 9:52 AM, wij wrote:
> > On Sunday, 5 December 2021 at 22:44:38 UTC+8, olcott wrote:
> >> On 12/4/2021 11:47 PM, wij wrote:
> >>> On Sunday, 5 December 2021 at 09:03:40 UTC+8, olcott wrote:
> >>>> On 12/4/2021 4:44 PM, wij wrote:
> >>>>> On Sunday, 5 December 2021 at 05:30:26 UTC+8, olcott wrote:
> >>>>>> On 12/4/2021 2:32 PM, wij wrote:
> >>>>>>> On Sunday, 5 December 2021 at 03:59:44 UTC+8, olcott wrote:
> >>>>>>>> On 12/4/2021 1:45 PM, wij wrote:
> >>>>>>>>> On Sunday, 5 December 2021 at 03:24:33 UTC+8, olcott wrote:
> >>>>>>>>>> On 12/4/2021 12:59 PM, wij wrote:
> >>>>>>>>>>> On Sunday, 5 December 2021 at 02:47:14 UTC+8, olcott wrote:
> >>>>>>>>>>>> On 12/4/2021 12:45 PM, olcott wrote:
> >>>>>>>>>>>>> On 12/4/2021 12:37 PM, wij wrote:
> >>>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:07:53 UTC+8, olcott wrote:
> >>>>>>>>>>>>>>> ...
> >>>>>>>>>>>>>>>> int H(ptr x, ptr y)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> x(y);
> >>>>>>>>>>>>>>>> return 1;
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H can only return 1 or never returns. Do you agree?
> >>>>>>>>>>>>>>>> I had asked the same question, you did not answer.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> // Simplified Linz(1990) Ĥ
> >>>>>>>>>>>>>>> // and Strachey(1965) P
> >>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>> When that H has (P,P) as input it can only never return.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Halting decider H has to return {0,1} (or reject, accept) for the
> >>>>>>>>>>>>>> given inputs.
> >>>>>>>>>>>>>> Your H clearly can only return 1, not a halting decider.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ARE YOU BRAIN-DEAD ???
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Whenever the pure simulation of the input to simulating halt decider
> >>>>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
> >>>>>>>>>>>>> aborts this simulation and returns 0 for not halting.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> THIS IS A GENERAL PRINCIPLE:
> >>>>>>>>>>>> Whenever the pure simulation of [ANY] input to [ANY] simulating halt
> >>>>>>>>>>>> decider H(x,y) never stops running unless H aborts its simulation H
> >>>>>>>>>>>> correctly aborts this simulation and returns 0 for not halting.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> One problem is that H contains no 'abort' instruction, or you abort it manually
> >>>>>>>>>>> and claim that you have built a H successfully?
> >>>>>>>>>>>
> >>>>>>>>>> I spent two years creating the x86utm operating system based on an x86
> >>>>>>>>>> emulator so that an actual H recognizes the infinitely recursive
> >>>>>>>>>> behavior pattern of P. H is a pure function, thus a computation.
> >>>>>>>>>>
> >>>>>>>>>> Page 7-8 show a complete trace.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> IIRC, x86 has no 'abort' instruction.
> >>>>>>>>> There is no 'abort' function call in Page 7-8 neither.
> >>>>>>>>> Do you manually abort the program execution?
> >>>>>>>> The x86utm operating system has this operating system function call:
> >>>>>>>>
> >>>>>>>> u32 DebugStep(Registers* master_state,
> >>>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
> >>>>>>>
> >>>>>>> So what?
> >>>>>>> Did you input any manual inputs? And thus make your conclusion?
> >>>>>>>
> >>>>>> I spent two years creating the UTM operating system to that H correctly
> >>>>>> decide the halt status of its input automatically.
> >>>>>
> >>>>> All we have is what you say.
> >>>>> So far, no one can confirm what you did, even remotely, imaginary.
> >>>>>
> >>>>>>>>>> int main() { P(P); } calls H(P,P) simulates and aborts P(P)
> >>>>>>>>>> Halting problem undecidability and infinitely nested simulation (V2)
> >>>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
> >>>>>>>>>>> Where is the "return 0" is H?
> >>>>>>>>>>> Where is the 'abort' instruction in H?
> >>>>>>>>>>>
> >>>>>>>>>>> Note: We do not actually need to know how H is implemented.
> >>>>>>>>>>>
> >>>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
> >>>>>>>>>>> No function f can decide the property of another function g that g can defy.
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Note: We do not actually need to know how H is implemented.
> >>>>>>>>> Actually, it is OK, if you decide manually to 'abort' to return whatever value.
> >>>>>>>>> Since it does not change the conclusion, what GUR says remains holds.
> >>>>>>>>>
> >>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
> >>>>>>>>> No function f can decide the property of another function g that g can defy.
> >>>>>>>>>
> >>>>>>>>> Even anyone's god cannot solve the Halting problem.
> >>>>>>>>>
> >>>>>>>> Now we construct a new Turing machine D with H as a subroutine.
> >>>>>>>> This new TM calls H to determine what M does when the input to M
> >>>>>>>> is its own description ⟨M⟩. Once D has determined this information,
> >>>>>>>> it does the opposite. (Sipser:1997:165)
> >>>>>>>
> >>>>>>> .Decision problems –
> >>>>>>> A decision problem has only two possible outputs (yes or no) on any input. In computability theory and computational complexity theory, a decision problem is a problem that can be posed as a yes-no question of the input values. Like is there any solution to a particular problem? The answer would be either a yes or no. A decision problem is any arbitrary yes/no question on an infinite set of inputs.
> >>>>>>> Turing machine –
> >>>>>>> A Turing machine is a mathematical model of computation. A Turing machine is a general example of a CPU that controls all data manipulation done by a computer. Turing machine can be halting as well as non halting and it depends on algorithm and input associated with the algorithm.
> >>>>>>>
> >>>>>>> Now, lets discuss Halting problem:
> >>>>>>> ... More in
> >>>>>>> https://www.geeksforgeeks.org/halting-problem-in-theory-of-computation/
> >>>>>>>
> >>>>>>>> On 12/3/2021 6:18 PM, olcott wrote:
> >>>>>>>>> Whenever the pure simulation of the input to simulating halt decider
> >>>>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
> >>>>>>>>> aborts this simulation and returns 0 for not halting.
> >>>>>>>> Since H never returns any value until after it has already made its halt
> >>>>>>>> status decision there is no (conventional HP) feedback loop between the
> >>>>>>>> halt decider and its input. This makes the conventional HP inputs
> >>>>>>>> decidable.
> >>>>>>>
> >>>>>>> I don't see any corresponding codes in your H matches what you said.
> >>>>>>>
> >>>>>> My actual H is hundreds of pages long. If you look at pages 3 and 4 is
> >>>>>> is very obvious that H could recognize the infinite recursion behavior
> >>>>>> pattern of P.
> >>>>>> Halting problem undecidability and infinitely nested simulation (V2)
> >>>>>>
> >>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
> >>>>>
> >>>>> "hundreds of pages long" means nothing to 'software engineer'.
> >>>>>
> >>>>> --- file t.c (from page 3)
> >>>>> #include <stdint.h>
> >>>>> typedef void (*ptr)();
> >>>>> int H(ptr x, ptr y)
> >>>>> {
> >>>>> x(y);
> >>>>> return 1;
> >>>>> }
> >>>>> // Simplified Linz(1990) Ĥ
> >>>>> // and Strachey(1965) P
> >>>>> void P(ptr x)
> >>>>> {
> >>>>> if (H(x, x))
> >>>>> HERE: goto HERE;
> >>>>> }
> >>>>> int main(void)
> >>>>> {
> >>>>> P(P);
> >>>>> }
> >>>>>
> >>>>> []$ gcc t.c
> >>>>> []$ ./a.out
> >>>>> Segmentation fault (core dumped)
> >>>>> ---
> >>>>>
> >>>>> I don's see H could recognize the infinite recursion behavior pattern of P,
> >>>>> because of "Segmentation fault (core dumped)".
> >>>> H simulates P(P) is debug step mode and stops as soon as P calls H(P,P)
> >>>> with the same input that H(P,P) was called with.
> >>>
> >>> This saying means you conduct how H should stop/continue/abort... *manually*.
> >>>
> >>> ...[snipet from previous post]
> >>>>>> u32 DebugStep(Registers* master_state,
> >>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
> >>>>>
> >>>>> So what?
> >>>>> Did you input any manual inputs? And thus make your conclusion?
> >>>>>
> >>>> I spent two years creating the UTM operating system to that H correctly
> >>>> decide the halt status of its input automatically.
> >>>
> >>> The previous saying is that "H correctly decide the halt status of its input automatically."
> >>> So, your 'automatically' means the same as 'manually'?
> >>>
> >> If it is obvious to every competent C/C++ programmer that knows the x86
> >> language how to write the code for H to recognize this very obvious
> >> infinite recursion pattern then it can be known that such a decider can
> >> exist:
> >
> > I would say you don't have the real functioning H but claims.
> >
> >> #include <stdint.h>
> >> typedef void (*ptr)();
> >>
> >> int H(ptr x, ptr y)
> >> {
> >> x(y);
> >> return 1;
> >> }
> >>
> >> // Simplified Linz(1990) Ĥ
> >> // and Strachey(1965) P
> >> void P(ptr x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> }
> >>
> >> int main(void)
> >> {
> >> P(P);
> >> }
> >
> > If you are honest about your H, it is very obvious that H can only return 1 or
> > never return. Therefore, this H is not a decider.
> >
> I have not finished transforming my original H that requires static
> memory to decide the halt status of P into my pure function H that does
> not require static memory to decide the full Linz H ⟨Ĥ⟩⟨Ĥ⟩.
> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>
> It is the case that anyone competent with C that knows the x86 language
> could easily see exactly how halt decider H recognizes the infinite
> recursion behavior pattern from its simulated lines 12-23.
> X86 machine code and execution trace of {main, H, and P}
> _H()
> [00001a6e](01) 55 push ebp
> [00001a6f](02) 8bec mov ebp,esp
> [00001a71](03) 8b450c mov eax,[ebp+0c]
> [00001a74](01) 50 push eax // push 2nd param
> [00001a75](03) ff5508 call dword [ebp+08] // call 1st param
> with 2nd param
> [00001a78](03) 83c404 add esp,+04
> [00001a7b](05) b801000000 mov eax,00000001
> [00001a80](01) 5d pop ebp
> [00001a81](01) c3 ret
> Size in bytes:(0020) [00001a81]
>
>
> _P()
> [00001a8e](01) 55 push ebp
> [00001a8f](02) 8bec mov ebp,esp
> [00001a91](03) 8b4508 mov eax,[ebp+08]
> [00001a94](01) 50 push eax // push 2nd param
> [00001a95](03) 8b4d08 mov ecx,[ebp+08]
> [00001a98](01) 51 push ecx // push 1st param
> [00001a99](05) e8d0ffffff call 00001a6e // call H
> [00001a9e](03) 83c408 add esp,+08
> [00001aa1](02) 85c0 test eax,eax
> [00001aa3](02) 7402 jz 00001aa7
> [00001aa5](02) ebfe jmp 00001aa5
> [00001aa7](01) 5d pop ebp
> [00001aa8](01) c3 ret
> Size in bytes:(0027) [00001aa8]
>
> _main()
> [00001aae](01) 55 push ebp
> [00001aaf](02) 8bec mov ebp,esp
> [00001ab1](05) 688e1a0000 push 00001a8e // push P
> [00001ab6](05) e8d3ffffff call 00001a8e // call P
> [00001abb](03) 83c404 add esp,+04
> [00001abe](02) 33c0 xor eax,eax
> [00001ac0](01) 5d pop ebp
> [00001ac1](01) c3 ret
> Size in bytes:(0020) [00001ac1]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= ============> (01)[00001aae][00102ec9][00000000] 55 push ebp
> (02)[00001aaf][00102ec9][00000000] 8bec mov ebp,esp
> (03)[00001ab1][00102ec5][00001a8e] 688e1a0000 push 00001a8e // push P
> (04)[00001ab6][00102ec1][00001abb] e8d3ffffff call 00001a8e // call P
> (05)[00001a8e][00102ebd][00102ec9] 55 push ebp
> (06)[00001a8f][00102ebd][00102ec9] 8bec mov ebp,esp
> (07)[00001a91][00102ebd][00102ec9] 8b4508 mov eax,[ebp+08]
> (08)[00001a94][00102eb9][00001a8e] 50 push eax // push P
> (09)[00001a95][00102eb9][00001a8e] 8b4d08 mov ecx,[ebp+08]
> (10)[00001a98][00102eb5][00001a8e] 51 push ecx // push P
> (11)[00001a99][00102eb1][00001a9e] e8d0ffffff call 00001a6e // call H
> (12)[00001a6e][00102ead][00102ebd] 55 push ebp
> (13)[00001a6f][00102ead][00102ebd] 8bec mov ebp,esp
> (14)[00001a71][00102ead][00102ebd] 8b450c mov eax,[ebp+0c]
> (15)[00001a74][00102ea9][00001a8e] 50 push eax // push P
> (16)[00001a75][00102ea5][00001a78] ff5508 call dword [ebp+08] // call P
> (17)[00001a8e][00102ea1][00102ead] 55 push ebp
> (18)[00001a8f][00102ea1][00102ead] 8bec mov ebp,esp
> (19)[00001a91][00102ea1][00102ead] 8b4508 mov eax,[ebp+08]
> (20)[00001a94][00102e9d][00001a8e] 50 push eax
> (21)[00001a95][00102e9d][00001a8e] 8b4d08 mov ecx,[ebp+08]
> (22)[00001a98][00102e99][00001a8e] 51 push ecx
> (23)[00001a99][00102e95][00001a9e] e8d0ffffff call 00001a6e // call H

On 12/5/2021 10:36 AM, wij wrote:
> On Monday, 6 December 2021 at 00:08:01 UTC+8, olcott wrote:
>> On 12/5/2021 9:52 AM, wij wrote:
>>> On Sunday, 5 December 2021 at 22:44:38 UTC+8, olcott wrote:
>>>> On 12/4/2021 11:47 PM, wij wrote:
>>>>> On Sunday, 5 December 2021 at 09:03:40 UTC+8, olcott wrote:
>>>>>> On 12/4/2021 4:44 PM, wij wrote:
>>>>>>> On Sunday, 5 December 2021 at 05:30:26 UTC+8, olcott wrote:
>>>>>>>> On 12/4/2021 2:32 PM, wij wrote:
>>>>>>>>> On Sunday, 5 December 2021 at 03:59:44 UTC+8, olcott wrote:
>>>>>>>>>> On 12/4/2021 1:45 PM, wij wrote:
>>>>>>>>>>> On Sunday, 5 December 2021 at 03:24:33 UTC+8, olcott wrote:
>>>>>>>>>>>> On 12/4/2021 12:59 PM, wij wrote:
>>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:47:14 UTC+8, olcott wrote:
>>>>>>>>>>>>>> On 12/4/2021 12:45 PM, olcott wrote:
>>>>>>>>>>>>>>> On 12/4/2021 12:37 PM, wij wrote:
>>>>>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:07:53 UTC+8, olcott wrote:
>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> x(y);
>>>>>>>>>>>>>>>>>> return 1;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H can only return 1 or never returns. Do you agree?
>>>>>>>>>>>>>>>>>> I had asked the same question, you did not answer.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> // Simplified Linz(1990) Ĥ
>>>>>>>>>>>>>>>>> // and Strachey(1965) P
>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>> When that H has (P,P) as input it can only never return.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Halting decider H has to return {0,1} (or reject, accept) for the
>>>>>>>>>>>>>>>> given inputs.
>>>>>>>>>>>>>>>> Your H clearly can only return 1, not a halting decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ARE YOU BRAIN-DEAD ???
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Whenever the pure simulation of the input to simulating halt decider
>>>>>>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
>>>>>>>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> THIS IS A GENERAL PRINCIPLE:
>>>>>>>>>>>>>> Whenever the pure simulation of [ANY] input to [ANY] simulating halt
>>>>>>>>>>>>>> decider H(x,y) never stops running unless H aborts its simulation H
>>>>>>>>>>>>>> correctly aborts this simulation and returns 0 for not halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> One problem is that H contains no 'abort' instruction, or you abort it manually
>>>>>>>>>>>>> and claim that you have built a H successfully?
>>>>>>>>>>>>>
>>>>>>>>>>>> I spent two years creating the x86utm operating system based on an x86
>>>>>>>>>>>> emulator so that an actual H recognizes the infinitely recursive
>>>>>>>>>>>> behavior pattern of P. H is a pure function, thus a computation.
>>>>>>>>>>>>
>>>>>>>>>>>> Page 7-8 show a complete trace.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> IIRC, x86 has no 'abort' instruction.
>>>>>>>>>>> There is no 'abort' function call in Page 7-8 neither.
>>>>>>>>>>> Do you manually abort the program execution?
>>>>>>>>>> The x86utm operating system has this operating system function call:
>>>>>>>>>>
>>>>>>>>>> u32 DebugStep(Registers* master_state,
>>>>>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>>>>>
>>>>>>>>> So what?
>>>>>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>>>>>
>>>>>>>> I spent two years creating the UTM operating system to that H correctly
>>>>>>>> decide the halt status of its input automatically.
>>>>>>>
>>>>>>> All we have is what you say.
>>>>>>> So far, no one can confirm what you did, even remotely, imaginary.
>>>>>>>
>>>>>>>>>>>> int main() { P(P); } calls H(P,P) simulates and aborts P(P)
>>>>>>>>>>>> Halting problem undecidability and infinitely nested simulation (V2)
>>>>>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>>>>>>> Where is the "return 0" is H?
>>>>>>>>>>>>> Where is the 'abort' instruction in H?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>>>>>>
>>>>>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>>>>>> No function f can decide the property of another function g that g can defy.
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>>>> Actually, it is OK, if you decide manually to 'abort' to return whatever value.
>>>>>>>>>>> Since it does not change the conclusion, what GUR says remains holds.
>>>>>>>>>>>
>>>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>>>> No function f can decide the property of another function g that g can defy.
>>>>>>>>>>>
>>>>>>>>>>> Even anyone's god cannot solve the Halting problem.
>>>>>>>>>>>
>>>>>>>>>> Now we construct a new Turing machine D with H as a subroutine.
>>>>>>>>>> This new TM calls H to determine what M does when the input to M
>>>>>>>>>> is its own description ⟨M⟩. Once D has determined this information,
>>>>>>>>>> it does the opposite. (Sipser:1997:165)
>>>>>>>>>
>>>>>>>>> .Decision problems –
>>>>>>>>> A decision problem has only two possible outputs (yes or no) on any input. In computability theory and computational complexity theory, a decision problem is a problem that can be posed as a yes-no question of the input values. Like is there any solution to a particular problem? The answer would be either a yes or no. A decision problem is any arbitrary yes/no question on an infinite set of inputs.
>>>>>>>>> Turing machine –
>>>>>>>>> A Turing machine is a mathematical model of computation. A Turing machine is a general example of a CPU that controls all data manipulation done by a computer. Turing machine can be halting as well as non halting and it depends on algorithm and input associated with the algorithm.
>>>>>>>>>
>>>>>>>>> Now, lets discuss Halting problem:
>>>>>>>>> ... More in
>>>>>>>>> https://www.geeksforgeeks.org/halting-problem-in-theory-of-computation/
>>>>>>>>>
>>>>>>>>>> On 12/3/2021 6:18 PM, olcott wrote:
>>>>>>>>>>> Whenever the pure simulation of the input to simulating halt decider
>>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H correctly
>>>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>>>> Since H never returns any value until after it has already made its halt
>>>>>>>>>> status decision there is no (conventional HP) feedback loop between the
>>>>>>>>>> halt decider and its input. This makes the conventional HP inputs
>>>>>>>>>> decidable.
>>>>>>>>>
>>>>>>>>> I don't see any corresponding codes in your H matches what you said.
>>>>>>>>>
>>>>>>>> My actual H is hundreds of pages long. If you look at pages 3 and 4 is
>>>>>>>> is very obvious that H could recognize the infinite recursion behavior
>>>>>>>> pattern of P.
>>>>>>>> Halting problem undecidability and infinitely nested simulation (V2)
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>
>>>>>>> "hundreds of pages long" means nothing to 'software engineer'.
>>>>>>>
>>>>>>> --- file t.c (from page 3)
>>>>>>> #include <stdint.h>
>>>>>>> typedef void (*ptr)();
>>>>>>> int H(ptr x, ptr y)
>>>>>>> {
>>>>>>> x(y);
>>>>>>> return 1;
>>>>>>> }
>>>>>>> // Simplified Linz(1990) Ĥ
>>>>>>> // and Strachey(1965) P
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>>> int main(void)
>>>>>>> {
>>>>>>> P(P);
>>>>>>> }
>>>>>>>
>>>>>>> []$ gcc t.c
>>>>>>> []$ ./a.out
>>>>>>> Segmentation fault (core dumped)
>>>>>>> ---
>>>>>>>
>>>>>>> I don's see H could recognize the infinite recursion behavior pattern of P,
>>>>>>> because of "Segmentation fault (core dumped)".
>>>>>> H simulates P(P) is debug step mode and stops as soon as P calls H(P,P)
>>>>>> with the same input that H(P,P) was called with.
>>>>>
>>>>> This saying means you conduct how H should stop/continue/abort... *manually*.
>>>>>
>>>>> ...[snipet from previous post]
>>>>>>>> u32 DebugStep(Registers* master_state,
>>>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>>>
>>>>>>> So what?
>>>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>>>
>>>>>> I spent two years creating the UTM operating system to that H correctly
>>>>>> decide the halt status of its input automatically.
>>>>>
>>>>> The previous saying is that "H correctly decide the halt status of its input automatically."
>>>>> So, your 'automatically' means the same as 'manually'?
>>>>>
>>>> If it is obvious to every competent C/C++ programmer that knows the x86
>>>> language how to write the code for H to recognize this very obvious
>>>> infinite recursion pattern then it can be known that such a decider can
>>>> exist:
>>>
>>> I would say you don't have the real functioning H but claims.
>>>
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>> x(y);
>>>> return 1;
>>>> }
>>>>
>>>> // Simplified Linz(1990) Ĥ
>>>> // and Strachey(1965) P
>>>> void P(ptr x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main(void)
>>>> {
>>>> P(P);
>>>> }
>>>
>>> If you are honest about your H, it is very obvious that H can only return 1 or
>>> never return. Therefore, this H is not a decider.
>>>
>> I have not finished transforming my original H that requires static
>> memory to decide the halt status of P into my pure function H that does
>> not require static memory to decide the full Linz H ⟨Ĥ⟩⟨Ĥ⟩.
>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>
>> It is the case that anyone competent with C that knows the x86 language
>> could easily see exactly how halt decider H recognizes the infinite
>> recursion behavior pattern from its simulated lines 12-23.
>> X86 machine code and execution trace of {main, H, and P}
>> _H()
>> [00001a6e](01) 55 push ebp
>> [00001a6f](02) 8bec mov ebp,esp
>> [00001a71](03) 8b450c mov eax,[ebp+0c]
>> [00001a74](01) 50 push eax // push 2nd param
>> [00001a75](03) ff5508 call dword [ebp+08] // call 1st param
>> with 2nd param
>> [00001a78](03) 83c404 add esp,+04
>> [00001a7b](05) b801000000 mov eax,00000001
>> [00001a80](01) 5d pop ebp
>> [00001a81](01) c3 ret
>> Size in bytes:(0020) [00001a81]
>>
>>
>> _P()
>> [00001a8e](01) 55 push ebp
>> [00001a8f](02) 8bec mov ebp,esp
>> [00001a91](03) 8b4508 mov eax,[ebp+08]
>> [00001a94](01) 50 push eax // push 2nd param
>> [00001a95](03) 8b4d08 mov ecx,[ebp+08]
>> [00001a98](01) 51 push ecx // push 1st param
>> [00001a99](05) e8d0ffffff call 00001a6e // call H
>> [00001a9e](03) 83c408 add esp,+08
>> [00001aa1](02) 85c0 test eax,eax
>> [00001aa3](02) 7402 jz 00001aa7
>> [00001aa5](02) ebfe jmp 00001aa5
>> [00001aa7](01) 5d pop ebp
>> [00001aa8](01) c3 ret
>> Size in bytes:(0027) [00001aa8]
>>
>> _main()
>> [00001aae](01) 55 push ebp
>> [00001aaf](02) 8bec mov ebp,esp
>> [00001ab1](05) 688e1a0000 push 00001a8e // push P
>> [00001ab6](05) e8d3ffffff call 00001a8e // call P
>> [00001abb](03) 83c404 add esp,+04
>> [00001abe](02) 33c0 xor eax,eax
>> [00001ac0](01) 5d pop ebp
>> [00001ac1](01) c3 ret
>> Size in bytes:(0020) [00001ac1]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> (01)[00001aae][00102ec9][00000000] 55 push ebp
>> (02)[00001aaf][00102ec9][00000000] 8bec mov ebp,esp
>> (03)[00001ab1][00102ec5][00001a8e] 688e1a0000 push 00001a8e // push P
>> (04)[00001ab6][00102ec1][00001abb] e8d3ffffff call 00001a8e // call P
>> (05)[00001a8e][00102ebd][00102ec9] 55 push ebp
>> (06)[00001a8f][00102ebd][00102ec9] 8bec mov ebp,esp
>> (07)[00001a91][00102ebd][00102ec9] 8b4508 mov eax,[ebp+08]
>> (08)[00001a94][00102eb9][00001a8e] 50 push eax // push P
>> (09)[00001a95][00102eb9][00001a8e] 8b4d08 mov ecx,[ebp+08]
>> (10)[00001a98][00102eb5][00001a8e] 51 push ecx // push P
>> (11)[00001a99][00102eb1][00001a9e] e8d0ffffff call 00001a6e // call H
>> (12)[00001a6e][00102ead][00102ebd] 55 push ebp
>> (13)[00001a6f][00102ead][00102ebd] 8bec mov ebp,esp
>> (14)[00001a71][00102ead][00102ebd] 8b450c mov eax,[ebp+0c]
>> (15)[00001a74][00102ea9][00001a8e] 50 push eax // push P
>> (16)[00001a75][00102ea5][00001a78] ff5508 call dword [ebp+08] // call P
>> (17)[00001a8e][00102ea1][00102ead] 55 push ebp
>> (18)[00001a8f][00102ea1][00102ead] 8bec mov ebp,esp
>> (19)[00001a91][00102ea1][00102ead] 8b4508 mov eax,[ebp+08]
>> (20)[00001a94][00102e9d][00001a8e] 50 push eax
>> (21)[00001a95][00102e9d][00001a8e] 8b4d08 mov ecx,[ebp+08]
>> (22)[00001a98][00102e99][00001a8e] 51 push ecx
>> (23)[00001a99][00102e95][00001a9e] e8d0ffffff call 00001a6e // call H
>
> Same result: Segmentation fault (core dumped)
> Is segmentation fault the correct behavior?
>

On 12/5/21 11:58 AM, olcott wrote:
> On 12/5/2021 10:36 AM, wij wrote:
>> On Monday, 6 December 2021 at 00:08:01 UTC+8, olcott wrote:
>>> On 12/5/2021 9:52 AM, wij wrote:
>>>> On Sunday, 5 December 2021 at 22:44:38 UTC+8, olcott wrote:
>>>>> On 12/4/2021 11:47 PM, wij wrote:
>>>>>> On Sunday, 5 December 2021 at 09:03:40 UTC+8, olcott wrote:
>>>>>>> On 12/4/2021 4:44 PM, wij wrote:
>>>>>>>> On Sunday, 5 December 2021 at 05:30:26 UTC+8, olcott wrote:
>>>>>>>>> On 12/4/2021 2:32 PM, wij wrote:
>>>>>>>>>> On Sunday, 5 December 2021 at 03:59:44 UTC+8, olcott wrote:
>>>>>>>>>>> On 12/4/2021 1:45 PM, wij wrote:
>>>>>>>>>>>> On Sunday, 5 December 2021 at 03:24:33 UTC+8, olcott wrote:
>>>>>>>>>>>>> On 12/4/2021 12:59 PM, wij wrote:
>>>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:47:14 UTC+8, olcott wrote:
>>>>>>>>>>>>>>> On 12/4/2021 12:45 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 12/4/2021 12:37 PM, wij wrote:
>>>>>>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:07:53 UTC+8, olcott
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> x(y);
>>>>>>>>>>>>>>>>>>> return 1;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H can only return 1 or never returns. Do you agree?
>>>>>>>>>>>>>>>>>>> I had asked the same question, you did not answer.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> // Simplified Linz(1990) Ĥ
>>>>>>>>>>>>>>>>>> // and Strachey(1965) P
>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>> When that H has (P,P) as input it can only never return.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Halting decider H has to return {0,1} (or reject,
>>>>>>>>>>>>>>>>> accept) for the
>>>>>>>>>>>>>>>>> given inputs.
>>>>>>>>>>>>>>>>> Your H clearly can only return 1, not a halting decider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ARE YOU BRAIN-DEAD ???
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Whenever the pure simulation of the input to simulating
>>>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>>>> H(x,y) never stops running unless H aborts its
>>>>>>>>>>>>>>>> simulation H correctly
>>>>>>>>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> THIS IS A GENERAL PRINCIPLE:
>>>>>>>>>>>>>>> Whenever the pure simulation of [ANY] input to [ANY]
>>>>>>>>>>>>>>> simulating halt
>>>>>>>>>>>>>>> decider H(x,y) never stops running unless H aborts its
>>>>>>>>>>>>>>> simulation H
>>>>>>>>>>>>>>> correctly aborts this simulation and returns 0 for not
>>>>>>>>>>>>>>> halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One problem is that H contains no 'abort' instruction, or
>>>>>>>>>>>>>> you abort it manually
>>>>>>>>>>>>>> and claim that you have built a H successfully?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I spent two years creating the x86utm operating system
>>>>>>>>>>>>> based on an x86
>>>>>>>>>>>>> emulator so that an actual H recognizes the infinitely
>>>>>>>>>>>>> recursive
>>>>>>>>>>>>> behavior pattern of P. H is a pure function, thus a
>>>>>>>>>>>>> computation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Page 7-8 show a complete trace.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> IIRC, x86 has no 'abort' instruction.
>>>>>>>>>>>> There is no 'abort' function call in Page 7-8 neither.
>>>>>>>>>>>> Do you manually abort the program execution?
>>>>>>>>>>> The x86utm operating system has this operating system
>>>>>>>>>>> function call:
>>>>>>>>>>>
>>>>>>>>>>> u32 DebugStep(Registers* master_state,
>>>>>>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>>>>>>
>>>>>>>>>> So what?
>>>>>>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>>>>>>
>>>>>>>>> I spent two years creating the UTM operating system to that H
>>>>>>>>> correctly
>>>>>>>>> decide the halt status of its input automatically.
>>>>>>>>
>>>>>>>> All we have is what you say.
>>>>>>>> So far, no one can confirm what you did, even remotely, imaginary.
>>>>>>>>
>>>>>>>>>>>>> int main() { P(P); } calls H(P,P) simulates and aborts P(P)
>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>> simulation (V2)
>>>>>>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Where is the "return 0" is H?
>>>>>>>>>>>>>> Where is the 'abort' instruction in H?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>>>>>>> No function f can decide the property of another function
>>>>>>>>>>>>>> g that g can defy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>>>>> Actually, it is OK, if you decide manually to 'abort' to
>>>>>>>>>>>> return whatever value.
>>>>>>>>>>>> Since it does not change the conclusion, what GUR says
>>>>>>>>>>>> remains holds.
>>>>>>>>>>>>
>>>>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>>>>> No function f can decide the property of another function g
>>>>>>>>>>>> that g can defy.
>>>>>>>>>>>>
>>>>>>>>>>>> Even anyone's god cannot solve the Halting problem.
>>>>>>>>>>>>
>>>>>>>>>>> Now we construct a new Turing machine D with H as a subroutine.
>>>>>>>>>>> This new TM calls H to determine what M does when the input to M
>>>>>>>>>>> is its own description ⟨M⟩. Once D has determined this
>>>>>>>>>>> information,
>>>>>>>>>>> it does the opposite. (Sipser:1997:165)
>>>>>>>>>>
>>>>>>>>>> .Decision problems –
>>>>>>>>>> A decision problem has only two possible outputs (yes or no)
>>>>>>>>>> on any input. In computability theory and computational
>>>>>>>>>> complexity theory, a decision problem is a problem that can be
>>>>>>>>>> posed as a yes-no question of the input values. Like is there
>>>>>>>>>> any solution to a particular problem? The answer would be
>>>>>>>>>> either a yes or no. A decision problem is any arbitrary yes/no
>>>>>>>>>> question on an infinite set of inputs.
>>>>>>>>>> Turing machine –
>>>>>>>>>> A Turing machine is a mathematical model of computation. A
>>>>>>>>>> Turing machine is a general example of a CPU that controls all
>>>>>>>>>> data manipulation done by a computer. Turing machine can be
>>>>>>>>>> halting as well as non halting and it depends on algorithm and
>>>>>>>>>> input associated with the algorithm.
>>>>>>>>>>
>>>>>>>>>> Now, lets discuss Halting problem:
>>>>>>>>>> ... More in
>>>>>>>>>> https://www.geeksforgeeks.org/halting-problem-in-theory-of-computation/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 12/3/2021 6:18 PM, olcott wrote:
>>>>>>>>>>>> Whenever the pure simulation of the input to simulating halt
>>>>>>>>>>>> decider
>>>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H
>>>>>>>>>>>> correctly
>>>>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>>>>> Since H never returns any value until after it has already
>>>>>>>>>>> made its halt
>>>>>>>>>>> status decision there is no (conventional HP) feedback loop
>>>>>>>>>>> between the
>>>>>>>>>>> halt decider and its input. This makes the conventional HP
>>>>>>>>>>> inputs
>>>>>>>>>>> decidable.
>>>>>>>>>>
>>>>>>>>>> I don't see any corresponding codes in your H matches what you
>>>>>>>>>> said.
>>>>>>>>>>
>>>>>>>>> My actual H is hundreds of pages long. If you look at pages 3
>>>>>>>>> and 4 is
>>>>>>>>> is very obvious that H could recognize the infinite recursion
>>>>>>>>> behavior
>>>>>>>>> pattern of P.
>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>> (V2)
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>>>
>>>>>>>>
>>>>>>>> "hundreds of pages long" means nothing to 'software engineer'.
>>>>>>>>
>>>>>>>> --- file t.c (from page 3)
>>>>>>>> #include <stdint.h>
>>>>>>>> typedef void (*ptr)();
>>>>>>>> int H(ptr x, ptr y)
>>>>>>>> {
>>>>>>>> x(y);
>>>>>>>> return 1;
>>>>>>>> }
>>>>>>>> // Simplified Linz(1990) Ĥ
>>>>>>>> // and Strachey(1965) P
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> }
>>>>>>>> int main(void)
>>>>>>>> {
>>>>>>>> P(P);
>>>>>>>> }
>>>>>>>>
>>>>>>>> []$ gcc t.c
>>>>>>>> []$ ./a.out
>>>>>>>> Segmentation fault (core dumped)
>>>>>>>> ---
>>>>>>>>
>>>>>>>> I don's see H could recognize the infinite recursion behavior
>>>>>>>> pattern of P,
>>>>>>>> because of "Segmentation fault (core dumped)".
>>>>>>> H simulates P(P) is debug step mode and stops as soon as P calls
>>>>>>> H(P,P)
>>>>>>> with the same input that H(P,P) was called with.
>>>>>>
>>>>>> This saying means you conduct how H should stop/continue/abort...
>>>>>> *manually*.
>>>>>>
>>>>>> ...[snipet from previous post]
>>>>>>>>> u32 DebugStep(Registers* master_state,
>>>>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>>>>
>>>>>>>> So what?
>>>>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>>>>
>>>>>>> I spent two years creating the UTM operating system to that H
>>>>>>> correctly
>>>>>>> decide the halt status of its input automatically.
>>>>>>
>>>>>> The previous saying is that "H correctly decide the halt status of
>>>>>> its input automatically."
>>>>>> So, your 'automatically' means the same as 'manually'?
>>>>>>
>>>>> If it is obvious to every competent C/C++ programmer that knows the
>>>>> x86
>>>>> language how to write the code for H to recognize this very obvious
>>>>> infinite recursion pattern then it can be known that such a decider
>>>>> can
>>>>> exist:
>>>>
>>>> I would say you don't have the real functioning H but claims.
>>>>
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>>
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>> x(y);
>>>>> return 1;
>>>>> }
>>>>>
>>>>> // Simplified Linz(1990) Ĥ
>>>>> // and Strachey(1965) P
>>>>> void P(ptr x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main(void)
>>>>> {
>>>>> P(P);
>>>>> }
>>>>
>>>> If you are honest about your H, it is very obvious that H can only
>>>> return 1 or
>>>> never return. Therefore, this H is not a decider.
>>>>
>>> I have not finished transforming my original H that requires static
>>> memory to decide the halt status of P into my pure function H that does
>>> not require static memory to decide the full Linz H ⟨Ĥ⟩⟨Ĥ⟩.
>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>
>>> It is the case that anyone competent with C that knows the x86 language
>>> could easily see exactly how halt decider H recognizes the infinite
>>> recursion behavior pattern from its simulated lines 12-23.
>>> X86 machine code and execution trace of {main, H, and P}
>>> _H()
>>> [00001a6e](01) 55 push ebp
>>> [00001a6f](02) 8bec mov ebp,esp
>>> [00001a71](03) 8b450c mov eax,[ebp+0c]
>>> [00001a74](01) 50 push eax // push 2nd param
>>> [00001a75](03) ff5508 call dword [ebp+08] // call 1st param
>>> with 2nd param
>>> [00001a78](03) 83c404 add esp,+04
>>> [00001a7b](05) b801000000 mov eax,00000001
>>> [00001a80](01) 5d pop ebp
>>> [00001a81](01) c3 ret
>>> Size in bytes:(0020) [00001a81]
>>>
>>>
>>> _P()
>>> [00001a8e](01) 55 push ebp
>>> [00001a8f](02) 8bec mov ebp,esp
>>> [00001a91](03) 8b4508 mov eax,[ebp+08]
>>> [00001a94](01) 50 push eax // push 2nd param
>>> [00001a95](03) 8b4d08 mov ecx,[ebp+08]
>>> [00001a98](01) 51 push ecx // push 1st param
>>> [00001a99](05) e8d0ffffff call 00001a6e // call H
>>> [00001a9e](03) 83c408 add esp,+08
>>> [00001aa1](02) 85c0 test eax,eax
>>> [00001aa3](02) 7402 jz 00001aa7
>>> [00001aa5](02) ebfe jmp 00001aa5
>>> [00001aa7](01) 5d pop ebp
>>> [00001aa8](01) c3 ret
>>> Size in bytes:(0027) [00001aa8]
>>>
>>> _main()
>>> [00001aae](01) 55 push ebp
>>> [00001aaf](02) 8bec mov ebp,esp
>>> [00001ab1](05) 688e1a0000 push 00001a8e // push P
>>> [00001ab6](05) e8d3ffffff call 00001a8e // call P
>>> [00001abb](03) 83c404 add esp,+04
>>> [00001abe](02) 33c0 xor eax,eax
>>> [00001ac0](01) 5d pop ebp
>>> [00001ac1](01) c3 ret
>>> Size in bytes:(0020) [00001ac1]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> (01)[00001aae][00102ec9][00000000] 55 push ebp
>>> (02)[00001aaf][00102ec9][00000000] 8bec mov ebp,esp
>>> (03)[00001ab1][00102ec5][00001a8e] 688e1a0000 push 00001a8e // push P
>>> (04)[00001ab6][00102ec1][00001abb] e8d3ffffff call 00001a8e // call P
>>> (05)[00001a8e][00102ebd][00102ec9] 55 push ebp
>>> (06)[00001a8f][00102ebd][00102ec9] 8bec mov ebp,esp
>>> (07)[00001a91][00102ebd][00102ec9] 8b4508 mov eax,[ebp+08]
>>> (08)[00001a94][00102eb9][00001a8e] 50 push eax // push P
>>> (09)[00001a95][00102eb9][00001a8e] 8b4d08 mov ecx,[ebp+08]
>>> (10)[00001a98][00102eb5][00001a8e] 51 push ecx // push P
>>> (11)[00001a99][00102eb1][00001a9e] e8d0ffffff call 00001a6e // call H
>>> (12)[00001a6e][00102ead][00102ebd] 55 push ebp
>>> (13)[00001a6f][00102ead][00102ebd] 8bec mov ebp,esp
>>> (14)[00001a71][00102ead][00102ebd] 8b450c mov eax,[ebp+0c]
>>> (15)[00001a74][00102ea9][00001a8e] 50 push eax // push P
>>> (16)[00001a75][00102ea5][00001a78] ff5508 call dword [ebp+08] // call P
>>> (17)[00001a8e][00102ea1][00102ead] 55 push ebp
>>> (18)[00001a8f][00102ea1][00102ead] 8bec mov ebp,esp
>>> (19)[00001a91][00102ea1][00102ead] 8b4508 mov eax,[ebp+08]
>>> (20)[00001a94][00102e9d][00001a8e] 50 push eax
>>> (21)[00001a95][00102e9d][00001a8e] 8b4d08 mov ecx,[ebp+08]
>>> (22)[00001a98][00102e99][00001a8e] 51 push ecx
>>> (23)[00001a99][00102e95][00001a9e] e8d0ffffff call 00001a6e // call H
>>
>> Same result: Segmentation fault (core dumped)
>> Is segmentation fault the correct behavior?
>>
>
> It is the case that anyone competent with C that knows the x86 language
> could easily see exactly how
>
> the above code could be adapted so that it becomes
>
> halt decider H recognizes the infinite recursion behavior pattern from
> its simulated lines 12-23.

On 12/5/21 9:44 AM, olcott wrote:
> On 12/4/2021 11:47 PM, wij wrote:
>> On Sunday, 5 December 2021 at 09:03:40 UTC+8, olcott wrote:
>>> On 12/4/2021 4:44 PM, wij wrote:
>>>> On Sunday, 5 December 2021 at 05:30:26 UTC+8, olcott wrote:
>>>>> On 12/4/2021 2:32 PM, wij wrote:
>>>>>> On Sunday, 5 December 2021 at 03:59:44 UTC+8, olcott wrote:
>>>>>>> On 12/4/2021 1:45 PM, wij wrote:
>>>>>>>> On Sunday, 5 December 2021 at 03:24:33 UTC+8, olcott wrote:
>>>>>>>>> On 12/4/2021 12:59 PM, wij wrote:
>>>>>>>>>> On Sunday, 5 December 2021 at 02:47:14 UTC+8, olcott wrote:
>>>>>>>>>>> On 12/4/2021 12:45 PM, olcott wrote:
>>>>>>>>>>>> On 12/4/2021 12:37 PM, wij wrote:
>>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:07:53 UTC+8, olcott wrote:
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> x(y);
>>>>>>>>>>>>>>> return 1;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H can only return 1 or never returns. Do you agree?
>>>>>>>>>>>>>>> I had asked the same question, you did not answer.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> // Simplified Linz(1990) Ĥ
>>>>>>>>>>>>>> // and Strachey(1965) P
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> When that H has (P,P) as input it can only never return.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>
>>>>>>>>>>>>> Halting decider H has to return {0,1} (or reject, accept)
>>>>>>>>>>>>> for the
>>>>>>>>>>>>> given inputs.
>>>>>>>>>>>>> Your H clearly can only return 1, not a halting decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ARE YOU BRAIN-DEAD ???
>>>>>>>>>>>>
>>>>>>>>>>>> Whenever the pure simulation of the input to simulating halt
>>>>>>>>>>>> decider
>>>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H
>>>>>>>>>>>> correctly
>>>>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>>>>>>
>>>>>>>>>>> THIS IS A GENERAL PRINCIPLE:
>>>>>>>>>>> Whenever the pure simulation of [ANY] input to [ANY]
>>>>>>>>>>> simulating halt
>>>>>>>>>>> decider H(x,y) never stops running unless H aborts its
>>>>>>>>>>> simulation H
>>>>>>>>>>> correctly aborts this simulation and returns 0 for not halting.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> One problem is that H contains no 'abort' instruction, or you
>>>>>>>>>> abort it manually
>>>>>>>>>> and claim that you have built a H successfully?
>>>>>>>>>>
>>>>>>>>> I spent two years creating the x86utm operating system based on
>>>>>>>>> an x86
>>>>>>>>> emulator so that an actual H recognizes the infinitely recursive
>>>>>>>>> behavior pattern of P. H is a pure function, thus a computation.
>>>>>>>>>
>>>>>>>>> Page 7-8 show a complete trace.
>>>>>>>>>
>>>>>>>>
>>>>>>>> IIRC, x86 has no 'abort' instruction.
>>>>>>>> There is no 'abort' function call in Page 7-8 neither.
>>>>>>>> Do you manually abort the program execution?
>>>>>>> The x86utm operating system has this operating system function call:
>>>>>>>
>>>>>>> u32 DebugStep(Registers* master_state,
>>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>>
>>>>>> So what?
>>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>>
>>>>> I spent two years creating the UTM operating system to that H
>>>>> correctly
>>>>> decide the halt status of its input automatically.
>>>>
>>>> All we have is what you say.
>>>> So far, no one can confirm what you did, even remotely, imaginary.
>>>>
>>>>>>>>> int main() { P(P); } calls H(P,P) simulates and aborts P(P)
>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>> (V2)
>>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>>>
>>>>>>>>>> Where is the "return 0" is H?
>>>>>>>>>> Where is the 'abort' instruction in H?
>>>>>>>>>>
>>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>>>
>>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>>> No function f can decide the property of another function g
>>>>>>>>>> that g can defy.
>>>>>>>>>>
>>>>>>>>
>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>> Actually, it is OK, if you decide manually to 'abort' to return
>>>>>>>> whatever value.
>>>>>>>> Since it does not change the conclusion, what GUR says remains
>>>>>>>> holds.
>>>>>>>>
>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>> No function f can decide the property of another function g that
>>>>>>>> g can defy.
>>>>>>>>
>>>>>>>> Even anyone's god cannot solve the Halting problem.
>>>>>>>>
>>>>>>> Now we construct a new Turing machine D with H as a subroutine.
>>>>>>> This new TM calls H to determine what M does when the input to M
>>>>>>> is its own description ⟨M⟩. Once D has determined this information,
>>>>>>> it does the opposite. (Sipser:1997:165)
>>>>>>
>>>>>> .Decision problems –
>>>>>> A decision problem has only two possible outputs (yes or no) on
>>>>>> any input. In computability theory and computational complexity
>>>>>> theory, a decision problem is a problem that can be posed as a
>>>>>> yes-no question of the input values. Like is there any solution to
>>>>>> a particular problem? The answer would be either a yes or no. A
>>>>>> decision problem is any arbitrary yes/no question on an infinite
>>>>>> set of inputs.
>>>>>> Turing machine –
>>>>>> A Turing machine is a mathematical model of computation. A Turing
>>>>>> machine is a general example of a CPU that controls all data
>>>>>> manipulation done by a computer. Turing machine can be halting as
>>>>>> well as non halting and it depends on algorithm and input
>>>>>> associated with the algorithm.
>>>>>>
>>>>>> Now, lets discuss Halting problem:
>>>>>> ... More in
>>>>>> https://www.geeksforgeeks.org/halting-problem-in-theory-of-computation/
>>>>>>
>>>>>>
>>>>>>> On 12/3/2021 6:18 PM, olcott wrote:
>>>>>>>> Whenever the pure simulation of the input to simulating halt
>>>>>>>> decider
>>>>>>>> H(x,y) never stops running unless H aborts its simulation H
>>>>>>>> correctly
>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>> Since H never returns any value until after it has already made
>>>>>>> its halt
>>>>>>> status decision there is no (conventional HP) feedback loop
>>>>>>> between the
>>>>>>> halt decider and its input. This makes the conventional HP inputs
>>>>>>> decidable.
>>>>>>
>>>>>> I don't see any corresponding codes in your H matches what you said.
>>>>>>
>>>>> My actual H is hundreds of pages long. If you look at pages 3 and 4 is
>>>>> is very obvious that H could recognize the infinite recursion behavior
>>>>> pattern of P.
>>>>> Halting problem undecidability and infinitely nested simulation (V2)
>>>>>
>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>
>>>>
>>>> "hundreds of pages long" means nothing to 'software engineer'.
>>>>
>>>> --- file t.c (from page 3)
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>> int H(ptr x, ptr y)
>>>> {
>>>> x(y);
>>>> return 1;
>>>> }
>>>> // Simplified Linz(1990) Ĥ
>>>> // and Strachey(1965) P
>>>> void P(ptr x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>> int main(void)
>>>> {
>>>> P(P);
>>>> }
>>>>
>>>> []$ gcc t.c
>>>> []$ ./a.out
>>>> Segmentation fault (core dumped)
>>>> ---
>>>>
>>>> I don's see H could recognize the infinite recursion behavior
>>>> pattern of P,
>>>> because of "Segmentation fault (core dumped)".
>>> H simulates P(P) is debug step mode and stops as soon as P calls H(P,P)
>>> with the same input that H(P,P) was called with.
>>
>> This saying means you conduct how H should stop/continue/abort...
>> *manually*.
>>
>> ...[snipet from previous post]
>>>>> u32 DebugStep(Registers* master_state,
>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>
>>>> So what?
>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>
>>> I spent two years creating the UTM operating system to that H correctly
>>> decide the halt status of its input automatically.
>>
>> The previous saying is that "H correctly decide the halt status of its
>> input automatically."
>> So,  your 'automatically' means the same as 'manually'?
>>
>
> If it is obvious to every competent C/C++ programmer that knows the x86
> language how to write the code for H to recognize this very obvious
> infinite recursion pattern then it can be known that such a decider can
> exist:

On 12/5/21 11:07 AM, olcott wrote:
> On 12/5/2021 9:52 AM, wij wrote:
>> On Sunday, 5 December 2021 at 22:44:38 UTC+8, olcott wrote:
>>> On 12/4/2021 11:47 PM, wij wrote:
>>>> On Sunday, 5 December 2021 at 09:03:40 UTC+8, olcott wrote:
>>>>> On 12/4/2021 4:44 PM, wij wrote:
>>>>>> On Sunday, 5 December 2021 at 05:30:26 UTC+8, olcott wrote:
>>>>>>> On 12/4/2021 2:32 PM, wij wrote:
>>>>>>>> On Sunday, 5 December 2021 at 03:59:44 UTC+8, olcott wrote:
>>>>>>>>> On 12/4/2021 1:45 PM, wij wrote:
>>>>>>>>>> On Sunday, 5 December 2021 at 03:24:33 UTC+8, olcott wrote:
>>>>>>>>>>> On 12/4/2021 12:59 PM, wij wrote:
>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:47:14 UTC+8, olcott wrote:
>>>>>>>>>>>>> On 12/4/2021 12:45 PM, olcott wrote:
>>>>>>>>>>>>>> On 12/4/2021 12:37 PM, wij wrote:
>>>>>>>>>>>>>>> On Sunday, 5 December 2021 at 02:07:53 UTC+8, olcott wrote:
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> x(y);
>>>>>>>>>>>>>>>>> return 1;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H can only return 1 or never returns. Do you agree?
>>>>>>>>>>>>>>>>> I had asked the same question, you did not answer.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> // Simplified Linz(1990) Ĥ
>>>>>>>>>>>>>>>> // and Strachey(1965) P
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> When that H has (P,P) as input it can only never return.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Halting decider H has to return {0,1} (or reject, accept)
>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>> given inputs.
>>>>>>>>>>>>>>> Your H clearly can only return 1, not a halting decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ARE YOU BRAIN-DEAD ???
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Whenever the pure simulation of the input to simulating
>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation
>>>>>>>>>>>>>> H correctly
>>>>>>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> THIS IS A GENERAL PRINCIPLE:
>>>>>>>>>>>>> Whenever the pure simulation of [ANY] input to [ANY]
>>>>>>>>>>>>> simulating halt
>>>>>>>>>>>>> decider H(x,y) never stops running unless H aborts its
>>>>>>>>>>>>> simulation H
>>>>>>>>>>>>> correctly aborts this simulation and returns 0 for not
>>>>>>>>>>>>> halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> One problem is that H contains no 'abort' instruction, or
>>>>>>>>>>>> you abort it manually
>>>>>>>>>>>> and claim that you have built a H successfully?
>>>>>>>>>>>>
>>>>>>>>>>> I spent two years creating the x86utm operating system based
>>>>>>>>>>> on an x86
>>>>>>>>>>> emulator so that an actual H recognizes the infinitely recursive
>>>>>>>>>>> behavior pattern of P. H is a pure function, thus a computation.
>>>>>>>>>>>
>>>>>>>>>>> Page 7-8 show a complete trace.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> IIRC, x86 has no 'abort' instruction.
>>>>>>>>>> There is no 'abort' function call in Page 7-8 neither.
>>>>>>>>>> Do you manually abort the program execution?
>>>>>>>>> The x86utm operating system has this operating system function
>>>>>>>>> call:
>>>>>>>>>
>>>>>>>>> u32 DebugStep(Registers* master_state,
>>>>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>>>>
>>>>>>>> So what?
>>>>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>>>>
>>>>>>> I spent two years creating the UTM operating system to that H
>>>>>>> correctly
>>>>>>> decide the halt status of its input automatically.
>>>>>>
>>>>>> All we have is what you say.
>>>>>> So far, no one can confirm what you did, even remotely, imaginary.
>>>>>>
>>>>>>>>>>> int main() { P(P); } calls H(P,P) simulates and aborts P(P)
>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>> simulation (V2)
>>>>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>>>>>
>>>>>>>>>>>> Where is the "return 0" is H?
>>>>>>>>>>>> Where is the 'abort' instruction in H?
>>>>>>>>>>>>
>>>>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>>>>>
>>>>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>>>>> No function f can decide the property of another function g
>>>>>>>>>>>> that g can defy.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Note: We do not actually need to know how H is implemented.
>>>>>>>>>> Actually, it is OK, if you decide manually to 'abort' to
>>>>>>>>>> return whatever value.
>>>>>>>>>> Since it does not change the conclusion, what GUR says remains
>>>>>>>>>> holds.
>>>>>>>>>>
>>>>>>>>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>>>>>>>>> No function f can decide the property of another function g
>>>>>>>>>> that g can defy.
>>>>>>>>>>
>>>>>>>>>> Even anyone's god cannot solve the Halting problem.
>>>>>>>>>>
>>>>>>>>> Now we construct a new Turing machine D with H as a subroutine.
>>>>>>>>> This new TM calls H to determine what M does when the input to M
>>>>>>>>> is its own description ⟨M⟩. Once D has determined this
>>>>>>>>> information,
>>>>>>>>> it does the opposite. (Sipser:1997:165)
>>>>>>>>
>>>>>>>> .Decision problems –
>>>>>>>> A decision problem has only two possible outputs (yes or no) on
>>>>>>>> any input. In computability theory and computational complexity
>>>>>>>> theory, a decision problem is a problem that can be posed as a
>>>>>>>> yes-no question of the input values. Like is there any solution
>>>>>>>> to a particular problem? The answer would be either a yes or no.
>>>>>>>> A decision problem is any arbitrary yes/no question on an
>>>>>>>> infinite set of inputs.
>>>>>>>> Turing machine –
>>>>>>>> A Turing machine is a mathematical model of computation. A
>>>>>>>> Turing machine is a general example of a CPU that controls all
>>>>>>>> data manipulation done by a computer. Turing machine can be
>>>>>>>> halting as well as non halting and it depends on algorithm and
>>>>>>>> input associated with the algorithm.
>>>>>>>>
>>>>>>>> Now, lets discuss Halting problem:
>>>>>>>> ... More in
>>>>>>>> https://www.geeksforgeeks.org/halting-problem-in-theory-of-computation/
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 12/3/2021 6:18 PM, olcott wrote:
>>>>>>>>>> Whenever the pure simulation of the input to simulating halt
>>>>>>>>>> decider
>>>>>>>>>> H(x,y) never stops running unless H aborts its simulation H
>>>>>>>>>> correctly
>>>>>>>>>> aborts this simulation and returns 0 for not halting.
>>>>>>>>> Since H never returns any value until after it has already made
>>>>>>>>> its halt
>>>>>>>>> status decision there is no (conventional HP) feedback loop
>>>>>>>>> between the
>>>>>>>>> halt decider and its input. This makes the conventional HP inputs
>>>>>>>>> decidable.
>>>>>>>>
>>>>>>>> I don't see any corresponding codes in your H matches what you
>>>>>>>> said.
>>>>>>>>
>>>>>>> My actual H is hundreds of pages long. If you look at pages 3 and
>>>>>>> 4 is
>>>>>>> is very obvious that H could recognize the infinite recursion
>>>>>>> behavior
>>>>>>> pattern of P.
>>>>>>> Halting problem undecidability and infinitely nested simulation (V2)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>
>>>>>>
>>>>>> "hundreds of pages long" means nothing to 'software engineer'.
>>>>>>
>>>>>> --- file t.c (from page 3)
>>>>>> #include <stdint.h>
>>>>>> typedef void (*ptr)();
>>>>>> int H(ptr x, ptr y)
>>>>>> {
>>>>>> x(y);
>>>>>> return 1;
>>>>>> }
>>>>>> // Simplified Linz(1990) Ĥ
>>>>>> // and Strachey(1965) P
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>> int main(void)
>>>>>> {
>>>>>> P(P);
>>>>>> }
>>>>>>
>>>>>> []$ gcc t.c
>>>>>> []$ ./a.out
>>>>>> Segmentation fault (core dumped)
>>>>>> ---
>>>>>>
>>>>>> I don's see H could recognize the infinite recursion behavior
>>>>>> pattern of P,
>>>>>> because of "Segmentation fault (core dumped)".
>>>>> H simulates P(P) is debug step mode and stops as soon as P calls
>>>>> H(P,P)
>>>>> with the same input that H(P,P) was called with.
>>>>
>>>> This saying means you conduct how H should stop/continue/abort...
>>>> *manually*.
>>>>
>>>> ...[snipet from previous post]
>>>>>>> u32 DebugStep(Registers* master_state,
>>>>>>> Registers* slave_state, Decoded_Line_Of_Code* decoded)
>>>>>>
>>>>>> So what?
>>>>>> Did you input any manual inputs? And thus make your conclusion?
>>>>>>
>>>>> I spent two years creating the UTM operating system to that H
>>>>> correctly
>>>>> decide the halt status of its input automatically.
>>>>
>>>> The previous saying is that "H correctly decide the halt status of
>>>> its input automatically."
>>>> So, your 'automatically' means the same as 'manually'?
>>>>
>>> If it is obvious to every competent C/C++ programmer that knows the x86
>>> language how to write the code for H to recognize this very obvious
>>> infinite recursion pattern then it can be known that such a decider can
>>> exist:
>>
>> I would say you don't have the real functioning H but claims.
>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>> x(y);
>>> return 1;
>>> }
>>>
>>> // Simplified Linz(1990) Ĥ
>>> // and Strachey(1965) P
>>> void P(ptr x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>>>
>>> int main(void)
>>> {
>>> P(P);
>>> }
>>
>> If you are honest about your H, it is very obvious that H can only
>> return 1 or
>> never return. Therefore, this H is not a decider.
>>
>
> I have not finished transforming my original H that requires static
> memory to decide the halt status of P into my pure function H that does
> not require static memory to decide the full Linz H ⟨Ĥ⟩⟨Ĥ⟩.
> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>
> It is the case that anyone competent with C that knows the x86 language
> could easily see exactly how halt decider H recognizes the infinite
> recursion behavior pattern from its simulated lines 12-23.
>