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?

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..

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.

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.
>

--
Copyright 2021 Pete Olcott

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

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?

> 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.

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)

>> 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)

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.

--
Copyright 2021 Pete Olcott

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

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?

> >> 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.

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.

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.

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

> 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.
>

--
Copyright 2021 Pete Olcott

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

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 (Ĥ, Ĥ).

--
Ben.

On 12/4/21 1:24 PM, olcott wrote:
> On 12/4/2021 12:20 PM, Richard Damon wrote:
>> On 12/4/21 1:09 PM, olcott wrote:
>>> On 12/4/2021 11:57 AM, Richard Damon wrote:
>>>> On 12/4/21 11:39 AM, olcott wrote:
>>>>> On 12/4/2021 10:18 AM, Richard Damon wrote:
>>>>>> On 12/4/21 9:52 AM, olcott wrote:
>>>>>>> On 12/4/2021 8:38 AM, Richard Damon wrote:
>>>>>>>> On 12/4/21 8:53 AM, olcott wrote:
>>>>>>>>> On 12/4/2021 5:58 AM, Richard Damon wrote:
>>>>>>>>>> On 12/4/21 12:10 AM, olcott wrote:
>>>>>>>>>>> On 12/3/2021 10:53 PM, Richard Damon wrote:
>>>>>>>>>>>> On 12/3/21 11:43 PM, olcott wrote:
>>>>>>>>>>>>> On 12/3/2021 10:15 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 12/3/21 8:36 PM, olcott wrote:
>>>>>>>>>>>>>>> On 12/3/2021 7:01 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 12/3/21 7: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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>>>> simulation (V2)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Maybe the problem is that YOU don't understand that
>>>>>>>>>>>>>>>> SINCE H does abort its simulation of P(P), that the P
>>>>>>>>>>>>>>>> that calls this H does Halt by itself, and it is the P
>>>>>>>>>>>>>>>> that is actually being run, and not the aborted
>>>>>>>>>>>>>>>> simulation buried in H that actually matters.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main() { P(P) } calls H(P,P) simulates P(P) never
>>>>>>>>>>>>>>> halts even when aborted dumbbell
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then your H(P,P) never returns 0, or you are just a bad liar.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now, if you are going into double-speak, and trying to use
>>>>>>>>>>>>>> the fact that the SIMULATED copy of P(P) that H is doing
>>>>>>>>>>>>>> never got to an end state, then you are just being a
>>>>>>>>>>>>>> cheating liar.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The P(P) that we care about is the one that main calls.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the H that it calls never returns, then H fails to be a
>>>>>>>>>>>>>> decider. PERIOD.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If that H does return the value 0, then this P(P) will
>>>>>>>>>>>>>> halt. PERIOD.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is what I said and you already "forgot" one sentence ago:
>>>>>>>>>>>>>  >>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> returns 0 for not halting.
>>>>>>>>>>>>> returns 0 for not halting.
>>>>>>>>>>>>> returns 0 for not halting.
>>>>>>>>>>>>> returns 0 for not halting.
>>>>>>>>>>>>> returns 0 for not halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> IF H returns 0, then it is BY DEFINITION wrong,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The problem may be that you actually lack the capacity to
>>>>>>>>>>> hold two sentence in your mind at once:
>>>>>>>>>>>
>>>>>>>>>>>  >>>> 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.
>>>>>>>>>>
>>>>>>>>>> I guess you just have a recursive problem then, to actually
>>>>>>>>>> build your halt decider H, someone needs to give you a working
>>>>>>>>>> Halt Decider for it to use.
>>>>>>>>>
>>>>>>>>> I have had a working halt decider since 2021-06-08.
>>>>>>>>
>>>>>>>> You can't have, as it gives the wrong answer to the problem.
>>>>>>> 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.
>>>>>>>  >
>>>>>>>
>>>>>>> H does correctly decide the pure simulation of the input to
>>>>>>> simulating halt decider H(x,y) never stops running unless H
>>>>>>> aborts its simulation.
>>>>>>>
>>>>>>
>>>>>> WRONG.
>>>>>>
>>>>>> Since the direct running of P(P) Halts,
>>>>>
>>>>> #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);
>>>>> }
>>>>>
>>>>> You know that you are a liar.
>>>>> The above is the direct execution of P(P).
>>>>
>>>> Right, and the above H doesn't meet the requirements as it doesn't
>>>> answer H(P,P), thus this H never 'correctly answers'.
>>>>
>>>
>>>
>>> // 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.
>>>
>>> This H(P,P) correctly decides that its input never stops running:
>>> 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.
>>>
>>> On the basis of the infinite_recursion behavior pattern.
>>
>> WRONG, LIE, see other post.
>>
>>
>
>
> THIS STATEMENT IS TRUE BY LOGICAL NECESSITY.
>
> 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
>

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)".
How is it "is very obvious that H could recognize the infinite recursion
behavior pattern of P."?

--
Not even one's god can make the Halting problem decidable (GUR)

On 12/4/21 2:59 PM, 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)
>
>>> 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)
>
> 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.
>

No, that doesn't break the feedback loop, as the copy of P that calls H
still gets its answer and acts contrary, and thus still makes H wrong.

The fact that H has decided without actually proving its answer because
it presumes (incorrectly) the behavior of the H it is simulating, just
makes H wrong, not 'break' the feedback loop.

H can't simulate far enough into the copy of H that it is simulating to
see what it will do, so by the structure of P, when P gets that H's
answer, it will act the opposite of whatever H presumed would happen.

On 12/4/21 5: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)".
> How is it "is very obvious that H could recognize the infinite recursion
> behavior pattern of P."?
>
> --
> Not even one's god can make the Halting problem decidable (GUR)
>

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).

--
Copyright 2021 Pete Olcott

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

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)".
> How is it "is very obvious that H could recognize the infinite recursion
> behavior pattern of P."?
>
> --
> Not even one's god can make the Halting problem decidable (GUR)
>

On Sunday, 5 December 2021 at 07:05:01 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)".
> > How is it "is very obvious that H could recognize the infinite recursion
> > behavior pattern of P."?
> >
> > --
> > Not even one's god can make the Halting problem decidable (GUR)
> >
> [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).

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.

As noted elsewhere, it can't return either 0 or 1 to P for H(P,P)
without being wrong, so an algorithm that actually implements correctly
such a rule will not answer and loop forever on H(P,P).

FAIL.

On 12/4/2021 4:53 PM, Richard Damon wrote:
> On 12/4/21 2:59 PM, 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)
>>
>>>> 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)
>>
>> 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.
>>
>
> No, that doesn't break the feedback loop, as the copy of P that calls H
> still gets its answer and acts contrary, and thus still makes H wrong.
>

If there is no N in the set of positive integers such that H(x,y)
simulates N steps of x(y) and x stops running this proves H(x,y)==0.

> The fact that H has decided without actually proving its answer because
> it presumes (incorrectly) the behavior of the H it is simulating, just
> makes H wrong, not 'break' the feedback loop.
>
> H can't simulate far enough into the copy of H that it is simulating to
> see what it will do, so by the structure of P, when P gets that H's
> answer, it will act the opposite of whatever H presumed would happen.
>

--
Copyright 2021 Pete Olcott

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

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)".

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

> As noted elsewhere, it can't return either 0 or 1 to P for H(P,P)
> without being wrong, so an algorithm that actually implements correctly
> such a rule will not answer and loop forever on H(P,P).
>
> FAIL.

--
Copyright 2021 Pete Olcott

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

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.

The problem is that you claim that there exists an H that does give a
right answer of 0 exists, even for the P that is built from it, but you
can't show it.

The fact that ONE P, one built on an H that never answers, gets in an
infinite recursion says NOTHING about some other P built on an H that
does answer.

You literally seem to be to thick in the head to understand your error here.

You try to claim that an H that never returns an answer is correct in
returning a 0. That is just plai stupid, and shows you total lack of
understanding.

On 12/4/21 8:03 PM, 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.
>
> If there is no N in the set of positive integers such that H(x,y)
> simulates N steps of x(y) and x stops running this proves H(x,y)==0.

On 12/4/21 8:00 PM, olcott wrote:
> On 12/4/2021 4:53 PM, Richard Damon wrote:
>> On 12/4/21 2:59 PM, 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)
>>>
>>>>> 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)
>>>
>>> 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.
>>>
>>
>> No, that doesn't break the feedback loop, as the copy of P that calls
>> H still gets its answer and acts contrary, and thus still makes H wrong.
>>
>
>
> If there is no N in the set of positive integers such that H(x,y)
> simulates N steps of x(y) and x stops running this proves H(x,y)==0.

WRONG.

This fails if x or y depend on 'H'

To do this Right, you need to say it like:

Given an Hn that simulates n steps and decides, there is no n such that
Hn(x,y) will reach the stoping state of x(y), then x(y) is non-halting.

THen when you subsitute in P, you need to choose a FIXED m and build Pm
from Hm, and run Hn(Pm,Pm) and you will find that for every finite value
m, there exists an n (>m) that Hn will see the halting state of Pm, so
Pm(Pm) is a Halting Computation.

It is just a fact that since m < n, Hm doesn't get it right.

FAIL.

This is probably still a first year error.

>
>
>> The fact that H has decided without actually proving its answer
>> because it presumes (incorrectly) the behavior of the H it is
>> simulating, just makes H wrong, not 'break' the feedback loop.
>>
>> H can't simulate far enough into the copy of H that it is simulating
>> to see what it will do, so by the structure of P, when P gets that H's
>> answer, it will act the opposite of whatever H presumed would happen.
>>
>
>

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.
>

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).

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.
>

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.