Can D simulated by H terminate normally?

The following code is executed in the x86utm operating system based on
an open source x86 emulator. This system enables one C function to
execute another C function in debug step mode. When H simulates D it
creates a separate process context for D with its own memory, stack and
virtual registers. H is able to simulate D simulating itself, thus the
only limit to recursive simulations is RAM.

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...

Is this clear enough to see that D correctly simulated by H can never
terminate normally ? (because D remains stuck in recursive simulation) ?

For any program H that might determine whether programs halt, a
"pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts D will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

H(D,D) fully operational in x86utm operating system:
https://github.com/plolcott/x86utm

Source-code of several different partial halt deciders and their sample
inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c

This paper shows how that same idea is applied to the Peter Linz Turing
machine based Halting Problem Proofs.

*Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs*
https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs

*At 10/13/2022 11:29 AM in an email*
MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):

If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

It is clear that H does determine the halt status of D precisely
according to that criteria.

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

--
Copyright 2023 Olcott

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

On 5/19/23 10:50 AM, olcott wrote:
> Can D simulated by H terminate normally?

Wrong Question!

You are showing your stupidity by repeatig the Strawman error that has
been pointed out to you many times, showing your Stupidity.

First you have to ask and answer does the ACTUAL H even do a "Correct
Simulation" by the definition that allows you to use the simulation to
determine halting.

Since the answer is NO, your question is mute.

YOU FAIL.

>
> The following code is executed in the x86utm operating system based on
> an open source x86 emulator. This system enables one C function to
> execute another C function in debug step mode. When H simulates D it
> creates a separate process context for D with its own memory, stack and
> virtual registers. H is able to simulate D simulating itself, thus the
> only limit to recursive simulations is RAM.
>
> 01 int D(int (*x)())
> 02 {
> 03  int Halt_Status = H(x, x);
> 04  if (Halt_Status)
> 05    HERE: goto HERE;
> 06  return Halt_Status;
> 07 }
> 08
> 09 void main()
> 10 {
> 11  H(D,D);
> 12 }
>
> *Execution Trace*
> main() calls H(D,D) that simulates D(D) at line 11
>
> *keeps repeating*
> simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...
>
> Is this clear enough to see that D correctly simulated by H can never
> terminate normally ? (because D remains stuck in recursive simulation) ?
>
> For any program H that might determine whether programs halt, a
> "pathological" program D, called with some input, can pass its own
> source and its input to H and then specifically do the opposite of what
> H predicts D will do. *No H can exist that handles this case*
> https://en.wikipedia.org/wiki/Halting_problem
>
> H(D,D) fully operational in x86utm operating system:
> https://github.com/plolcott/x86utm
>
> Source-code of several different partial halt deciders and their sample
> inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c
>
> This paper shows how that same idea is applied to the Peter Linz Turing
> machine based Halting Problem Proofs.
>
> *Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs*
> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>
> *At 10/13/2022 11:29 AM in an email*
> MIT Professor Michael Sipser has agreed that the following verbatim
> paragraph is correct (he has not agreed to anything else):
>
> If simulating halt decider H correctly simulates its input D until H
> correctly determines that its simulated D would never stop running
> unless aborted then H can abort its simulation of D and correctly report
> that D specifies a non-halting sequence of configurations.
>
> It is clear that H does determine the halt status of D precisely
> according to that criteria.
>
>
>

On 5/19/2023 5:54 PM, Richard Damon wrote:
> On 5/19/23 10:50 AM, olcott wrote:
>> Can D simulated by H terminate normally?
>
> Wrong Question!
>

In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.

> You are showing your stupidity by repeatig the Strawman error that has
> been pointed out to you many times, showing your Stupidity.
>
>
> First you have to ask and answer does the ACTUAL H even do a "Correct
> Simulation" by the definition that allows you to use the simulation to
> determine halting.
>
> Since the answer is NO, your question is mute.
>
> YOU FAIL.
>
>>
>> The following code is executed in the x86utm operating system based on
>> an open source x86 emulator. This system enables one C function to
>> execute another C function in debug step mode. When H simulates D it
>> creates a separate process context for D with its own memory, stack and
>> virtual registers. H is able to simulate D simulating itself, thus the
>> only limit to recursive simulations is RAM.
>>
>> 01 int D(int (*x)())
>> 02 {
>> 03  int Halt_Status = H(x, x);
>> 04  if (Halt_Status)
>> 05    HERE: goto HERE;
>> 06  return Halt_Status;
>> 07 }
>> 08
>> 09 void main()
>> 10 {
>> 11  H(D,D);
>> 12 }
>>
>> *Execution Trace*
>> main() calls H(D,D) that simulates D(D) at line 11
>>
>> *keeps repeating*
>> simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...
>>
>> Is this clear enough to see that D correctly simulated by H can never
>> terminate normally ? (because D remains stuck in recursive simulation) ?
>>
>> For any program H that might determine whether programs halt, a
>> "pathological" program D, called with some input, can pass its own
>> source and its input to H and then specifically do the opposite of what
>> H predicts D will do. *No H can exist that handles this case*
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> H(D,D) fully operational in x86utm operating system:
>> https://github.com/plolcott/x86utm
>>
>> Source-code of several different partial halt deciders and their
>> sample inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>
>> This paper shows how that same idea is applied to the Peter Linz Turing
>> machine based Halting Problem Proofs.
>>
>> *Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs*
>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>
>> *At 10/13/2022 11:29 AM in an email*
>> MIT Professor Michael Sipser has agreed that the following verbatim
>> paragraph is correct (he has not agreed to anything else):
>>
>> If simulating halt decider H correctly simulates its input D until H
>> correctly determines that its simulated D would never stop running
>> unless aborted then H can abort its simulation of D and correctly report
>> that D specifies a non-halting sequence of configurations.
>>
>> It is clear that H does determine the halt status of D precisely
>> according to that criteria.
>>
>>
>>
>

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

On 5/19/23 9:47 PM, olcott wrote:
> On 5/19/2023 5:54 PM, Richard Damon wrote:
>> On 5/19/23 10:50 AM, olcott wrote:
>>> Can D simulated by H terminate normally?
>>
>> Wrong Question!
>>
>
> In other words the question is over you head.
> It took me many years to recognize this same dodge by Ben.

No, it is the WRONG question once you try to apply the answer to the
Halting Problem, which you do.

You are just proving your are a stupid ignorant liar by repeating the error.

You have shown a total non-understanding of the principle of
requirements, so none of your work has value to anyone concerned about
doing the right thing when asked.

You keep on giving people the number of dogs when they ask you how many
cats, and insist that must be what they mean.

You TOTALLY don't understand what logic means.

>
>> You are showing your stupidity by repeatig the Strawman error that has
>> been pointed out to you many times, showing your Stupidity.
>>
>>
>> First you have to ask and answer does the ACTUAL H even do a "Correct
>> Simulation" by the definition that allows you to use the simulation to
>> determine halting.
>>
>> Since the answer is NO, your question is mute.
>>
>> YOU FAIL.
>>
>>>
>>> The following code is executed in the x86utm operating system based on
>>> an open source x86 emulator. This system enables one C function to
>>> execute another C function in debug step mode. When H simulates D it
>>> creates a separate process context for D with its own memory, stack and
>>> virtual registers. H is able to simulate D simulating itself, thus the
>>> only limit to recursive simulations is RAM.
>>>
>>> 01 int D(int (*x)())
>>> 02 {
>>> 03  int Halt_Status = H(x, x);
>>> 04  if (Halt_Status)
>>> 05    HERE: goto HERE;
>>> 06  return Halt_Status;
>>> 07 }
>>> 08
>>> 09 void main()
>>> 10 {
>>> 11  H(D,D);
>>> 12 }
>>>
>>> *Execution Trace*
>>> main() calls H(D,D) that simulates D(D) at line 11
>>>
>>> *keeps repeating*
>>> simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...
>>>
>>> Is this clear enough to see that D correctly simulated by H can never
>>> terminate normally ? (because D remains stuck in recursive simulation) ?
>>>
>>> For any program H that might determine whether programs halt, a
>>> "pathological" program D, called with some input, can pass its own
>>> source and its input to H and then specifically do the opposite of what
>>> H predicts D will do. *No H can exist that handles this case*
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> H(D,D) fully operational in x86utm operating system:
>>> https://github.com/plolcott/x86utm
>>>
>>> Source-code of several different partial halt deciders and their
>>> sample inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>
>>> This paper shows how that same idea is applied to the Peter Linz Turing
>>> machine based Halting Problem Proofs.
>>>
>>> *Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs*
>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>
>>> *At 10/13/2022 11:29 AM in an email*
>>> MIT Professor Michael Sipser has agreed that the following verbatim
>>> paragraph is correct (he has not agreed to anything else):
>>>
>>> If simulating halt decider H correctly simulates its input D until H
>>> correctly determines that its simulated D would never stop running
>>> unless aborted then H can abort its simulation of D and correctly report
>>> that D specifies a non-halting sequence of configurations.
>>>
>>> It is clear that H does determine the halt status of D precisely
>>> according to that criteria.
>>>
>>>
>>>
>>
>

On 5/19/2023 8:56 PM, Richard Damon wrote:
> On 5/19/23 9:47 PM, olcott wrote:
>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>> On 5/19/23 10:50 AM, olcott wrote:
>>>> Can D simulated by H terminate normally?
>>>
>>> Wrong Question!
>>>
>>
>> In other words the question is over you head.
>> It took me many years to recognize this same dodge by Ben.
>
> No, it is the WRONG question once you try to apply the answer to the
> Halting Problem, which you do.
>

So the software engineering really is over your head?
I see, so like Ben you have never actually written any code.

Ben kept masking his coding incompetence this way.
It never occurred to me that you have never written any code.

>>>> The following code is executed in the x86utm operating system based on
>>>> an open source x86 emulator. This system enables one C function to
>>>> execute another C function in debug step mode. When H simulates D it
>>>> creates a separate process context for D with its own memory, stack and
>>>> virtual registers. H is able to simulate D simulating itself, thus the
>>>> only limit to recursive simulations is RAM.
>>>>
>>>> 01 int D(int (*x)())
>>>> 02 {
>>>> 03  int Halt_Status = H(x, x);
>>>> 04  if (Halt_Status)
>>>> 05    HERE: goto HERE;
>>>> 06  return Halt_Status;
>>>> 07 }
>>>> 08
>>>> 09 void main()
>>>> 10 {
>>>> 11  H(D,D);
>>>> 12 }
>>>>
>>>> *Execution Trace*
>>>> main() calls H(D,D) that simulates D(D) at line 11
>>>>
>>>> *keeps repeating*
>>>> simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03
>>>> ...
>>>>
>>>> Is this clear enough to see that D correctly simulated by H can never
>>>> terminate normally ? (because D remains stuck in recursive
>>>> simulation) ?
>>>>
>>>> For any program H that might determine whether programs halt, a
>>>> "pathological" program D, called with some input, can pass its own
>>>> source and its input to H and then specifically do the opposite of what
>>>> H predicts D will do. *No H can exist that handles this case*
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> H(D,D) fully operational in x86utm operating system:
>>>> https://github.com/plolcott/x86utm
>>>>
>>>> Source-code of several different partial halt deciders and their
>>>> sample inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>>
>>>> This paper shows how that same idea is applied to the Peter Linz Turing
>>>> machine based Halting Problem Proofs.
>>>>
>>>> *Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs*
>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>
>>>> *At 10/13/2022 11:29 AM in an email*
>>>> MIT Professor Michael Sipser has agreed that the following verbatim
>>>> paragraph is correct (he has not agreed to anything else):
>>>>
>>>> If simulating halt decider H correctly simulates its input D until H
>>>> correctly determines that its simulated D would never stop running
>>>> unless aborted then H can abort its simulation of D and correctly
>>>> report
>>>> that D specifies a non-halting sequence of configurations.
>>>>
>>>> It is clear that H does determine the halt status of D precisely
>>>> according to that criteria.
>>>>
>>>>
>>>>
>>>
>>
>

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

On 5/19/23 10:10 PM, olcott wrote:
> On 5/19/2023 8:56 PM, Richard Damon wrote:
>> On 5/19/23 9:47 PM, olcott wrote:
>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>> Can D simulated by H terminate normally?
>>>>
>>>> Wrong Question!
>>>>
>>>
>>> In other words the question is over you head.
>>> It took me many years to recognize this same dodge by Ben.
>>
>> No, it is the WRONG question once you try to apply the answer to the
>> Halting Problem, which you do.
>>
>
> So the software engineering really is over your head?
> I see, so like Ben you have never actually written any code.

But you aren't talking about Software Engineering unless you are lying
about this applying to the Halting Problem described by Linz, since that
is the Halting Problem of Computability Theory.

Of course, the likely explanation is that you are just ignorant of what
you are talking about, so you don't understand the diference.

>
> Ben kept masking his coding incompetence this way.
> It never occurred to me that you have never written any code.

I have possibly written more WORKING code than you have.

On 5/19/2023 9:51 PM, Richard Damon wrote:
> On 5/19/23 10:10 PM, olcott wrote:
>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>> On 5/19/23 9:47 PM, olcott wrote:
>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>> Can D simulated by H terminate normally?
>>>>>
>>>>> Wrong Question!
>>>>>
>>>>
>>>> In other words the question is over you head.
>>>> It took me many years to recognize this same dodge by Ben.
>>>
>>> No, it is the WRONG question once you try to apply the answer to the
>>> Halting Problem, which you do.
>>>
>>
>> So the software engineering really is over your head?
>> I see, so like Ben you have never actually written any code.
>
> But you aren't talking about Software Engineering unless you are lying
> about this applying to the Halting Problem described by Linz, since that
> is the Halting Problem of Computability Theory.
>
> Of course, the likely explanation is that you are just ignorant of what
> you are talking about, so you don't understand the diference.
>
>>
>> Ben kept masking his coding incompetence this way.
>> It never occurred to me that you have never written any code.
>
> I have possibly written more WORKING code than you have.
>
>

I don't believe you. Your inability to answer an straight forward
software engineering question seems to prove otherwise.

Ben successfully pulled this same crap for nearly two decades.
He may know some things at the abstract textbook level very well.
That seems to be the total extent of his technical knowledge.
Mike had to coach on some relatively simple things.

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

On 5/19/23 11:00 PM, olcott wrote:
> On 5/19/2023 9:51 PM, Richard Damon wrote:
>> On 5/19/23 10:10 PM, olcott wrote:
>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>> Can D simulated by H terminate normally?
>>>>>>
>>>>>> Wrong Question!
>>>>>>
>>>>>
>>>>> In other words the question is over you head.
>>>>> It took me many years to recognize this same dodge by Ben.
>>>>
>>>> No, it is the WRONG question once you try to apply the answer to the
>>>> Halting Problem, which you do.
>>>>
>>>
>>> So the software engineering really is over your head?
>>> I see, so like Ben you have never actually written any code.
>>
>> But you aren't talking about Software Engineering unless you are lying
>> about this applying to the Halting Problem described by Linz, since
>> that is the Halting Problem of Computability Theory.
>>
>> Of course, the likely explanation is that you are just ignorant of
>> what you are talking about, so you don't understand the diference.
>>
>>>
>>> Ben kept masking his coding incompetence this way.
>>> It never occurred to me that you have never written any code.
>>
>> I have possibly written more WORKING code than you have.
>>
>>
>
> I don't believe you. Your inability to answer an straight forward
> software engineering question seems to prove otherwise.

What software engineering question?

SInce you refer to The Halting Problem from Turing as described by Linz,
you are putting out a Strawman.

You don't seem to understand the correct meaning of "Simulate" from the
problem domain.

Maybe with your wrong definition of "Correct Simulation" you can show
that H does what you call a "Correct Simulation", but since it doesn't
match the definition used in talking about a UTM, you can't use that
fact to talk about the Halting of the machine described by the input.

You are just proving you don't understand about logic or anything
related that you have been talking about.

>
> Ben successfully pulled this same crap for nearly two decades.
> He may know some things at the abstract textbook level very well.
> That seems to be the total extent of his technical knowledge.
> Mike had to coach on some relatively simple things.
>

Nope, You have been ignoring the fact that you are just ignorant about
what the question you have been working on actually means, because you
refuese to learn the language it was written in.

YOU are the stupid one trying to pull crap with your POOP problem.

On 5/19/23 10:10 PM, olcott wrote:
> On 5/19/2023 8:56 PM, Richard Damon wrote:
>> On 5/19/23 9:47 PM, olcott wrote:
>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>> Can D simulated by H terminate normally?
>>>>
>>>> Wrong Question!
>>>>
>>>
>>> In other words the question is over you head.
>>> It took me many years to recognize this same dodge by Ben.
>>
>> No, it is the WRONG question once you try to apply the answer to the
>> Halting Problem, which you do.
>>
>
> So the software engineering really is over your head?
> I see, so like Ben you have never actually written any code.

Nope, I have likely written more working code than you.

The problem is the question you are discussing isn't a software
engineering question, in part because it predates the computer you are
thinking about.

This seems to be a common problem with you, you don't seem to understand
about requirements, which is likely why you have so much problem with
getting things rignt.

>
> Ben kept masking his coding incompetence this way.
> It never occurred to me that you have never written any code.
>
>>>>> The following code is executed in the x86utm operating system based on
>>>>> an open source x86 emulator. This system enables one C function to
>>>>> execute another C function in debug step mode. When H simulates D it
>>>>> creates a separate process context for D with its own memory, stack
>>>>> and
>>>>> virtual registers. H is able to simulate D simulating itself, thus the
>>>>> only limit to recursive simulations is RAM.
>>>>>
>>>>> 01 int D(int (*x)())
>>>>> 02 {
>>>>> 03  int Halt_Status = H(x, x);
>>>>> 04  if (Halt_Status)
>>>>> 05    HERE: goto HERE;
>>>>> 06  return Halt_Status;
>>>>> 07 }
>>>>> 08
>>>>> 09 void main()
>>>>> 10 {
>>>>> 11  H(D,D);
>>>>> 12 }
>>>>>
>>>>> *Execution Trace*
>>>>> main() calls H(D,D) that simulates D(D) at line 11
>>>>>
>>>>> *keeps repeating*
>>>>> simulated D(D) calls simulated H(D,D) that simulates D(D) at line
>>>>> 03 ...
>>>>>
>>>>> Is this clear enough to see that D correctly simulated by H can never
>>>>> terminate normally ? (because D remains stuck in recursive
>>>>> simulation) ?
>>>>>
>>>>> For any program H that might determine whether programs halt, a
>>>>> "pathological" program D, called with some input, can pass its own
>>>>> source and its input to H and then specifically do the opposite of
>>>>> what
>>>>> H predicts D will do. *No H can exist that handles this case*
>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> H(D,D) fully operational in x86utm operating system:
>>>>> https://github.com/plolcott/x86utm
>>>>>
>>>>> Source-code of several different partial halt deciders and their
>>>>> sample inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>>>
>>>>> This paper shows how that same idea is applied to the Peter Linz
>>>>> Turing
>>>>> machine based Halting Problem Proofs.
>>>>>
>>>>> *Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs*
>>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
>>>>>
>>>>> *At 10/13/2022 11:29 AM in an email*
>>>>> MIT Professor Michael Sipser has agreed that the following verbatim
>>>>> paragraph is correct (he has not agreed to anything else):
>>>>>
>>>>> If simulating halt decider H correctly simulates its input D until H
>>>>> correctly determines that its simulated D would never stop running
>>>>> unless aborted then H can abort its simulation of D and correctly
>>>>> report
>>>>> that D specifies a non-halting sequence of configurations.
>>>>>
>>>>> It is clear that H does determine the halt status of D precisely
>>>>> according to that criteria.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

On 5/19/2023 10:27 PM, Richard Damon wrote:
> On 5/19/23 11:00 PM, olcott wrote:
>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>> On 5/19/23 10:10 PM, olcott wrote:
>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>
>>>>>>> Wrong Question!
>>>>>>>
>>>>>>
>>>>>> In other words the question is over you head.
>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>
>>>>> No, it is the WRONG question once you try to apply the answer to
>>>>> the Halting Problem, which you do.
>>>>>
>>>>
>>>> So the software engineering really is over your head?
>>>> I see, so like Ben you have never actually written any code.
>>>
>>> But you aren't talking about Software Engineering unless you are
>>> lying about this applying to the Halting Problem described by Linz,
>>> since that is the Halting Problem of Computability Theory.
>>>
>>> Of course, the likely explanation is that you are just ignorant of
>>> what you are talking about, so you don't understand the diference.
>>>
>>>>
>>>> Ben kept masking his coding incompetence this way.
>>>> It never occurred to me that you have never written any code.
>>>
>>> I have possibly written more WORKING code than you have.
>>>
>>>
>>
>> I don't believe you. Your inability to answer an straight forward
>> software engineering question seems to prove otherwise.
>
> What software engineering question?

Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?

The following code is executed in the x86utm operating system based on
an open source x86 emulator. This system enables one C function to
execute another C function in debug step mode. When H simulates D it
creates a separate process context for D with its own memory, stack and
virtual registers. H is able to simulate D simulating itself, thus the
only limit to recursive simulations is RAM.

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...

Is this clear enough to see that D correctly simulated by H can never
terminate normally ? (because D remains stuck in recursive simulation) ?

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

On 5/19/2023 10:27 PM, Richard Damon wrote:
> On 5/19/23 11:00 PM, olcott wrote:
>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>> On 5/19/23 10:10 PM, olcott wrote:
>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>
>>>>>>> Wrong Question!
>>>>>>>
>>>>>>
>>>>>> In other words the question is over you head.
>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>
>>>>> No, it is the WRONG question once you try to apply the answer to
>>>>> the Halting Problem, which you do.
>>>>>
>>>>
>>>> So the software engineering really is over your head?
>>>> I see, so like Ben you have never actually written any code.
>>>
>>> But you aren't talking about Software Engineering unless you are
>>> lying about this applying to the Halting Problem described by Linz,
>>> since that is the Halting Problem of Computability Theory.
>>>
>>> Of course, the likely explanation is that you are just ignorant of
>>> what you are talking about, so you don't understand the diference.
>>>
>>>>
>>>> Ben kept masking his coding incompetence this way.
>>>> It never occurred to me that you have never written any code.
>>>
>>> I have possibly written more WORKING code than you have.
>>>
>>>
>>
>> I don't believe you. Your inability to answer an straight forward
>> software engineering question seems to prove otherwise.
>
> What software engineering question?
>

Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?

The following code is executed in the x86utm operating system based on
an open source x86 emulator. This system enables one C function to
execute another C function in debug step mode. When H simulates D it
creates a separate process context for D with its own memory, stack and
virtual registers. H is able to simulate D simulating itself, thus the
only limit to recursive simulations is RAM.

01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...

Is this clear enough to see that D correctly simulated by H can never
terminate normally ? (because D remains stuck in recursive simulation) ?

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

On 5/20/23 12:00 AM, olcott wrote:
> On 5/19/2023 10:27 PM, Richard Damon wrote:
>> On 5/19/23 11:00 PM, olcott wrote:
>>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>>> On 5/19/23 10:10 PM, olcott wrote:
>>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>
>>>>>>>> Wrong Question!
>>>>>>>>
>>>>>>>
>>>>>>> In other words the question is over you head.
>>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>>
>>>>>> No, it is the WRONG question once you try to apply the answer to
>>>>>> the Halting Problem, which you do.
>>>>>>
>>>>>
>>>>> So the software engineering really is over your head?
>>>>> I see, so like Ben you have never actually written any code.
>>>>
>>>> But you aren't talking about Software Engineering unless you are
>>>> lying about this applying to the Halting Problem described by Linz,
>>>> since that is the Halting Problem of Computability Theory.
>>>>
>>>> Of course, the likely explanation is that you are just ignorant of
>>>> what you are talking about, so you don't understand the diference.
>>>>
>>>>>
>>>>> Ben kept masking his coding incompetence this way.
>>>>> It never occurred to me that you have never written any code.
>>>>
>>>> I have possibly written more WORKING code than you have.
>>>>
>>>>
>>>
>>> I don't believe you. Your inability to answer an straight forward
>>> software engineering question seems to prove otherwise.
>>
>> What software engineering question?
>>
>
>
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
>

The answer to that question is NO, but that is because H doesn't, and
can never do an accurarte simulation per the definition of a UTM.

Thus, it is the WRONG QUESTION for the problem.

It is a STRAWMAN.

The fact that you fixate on it, shows your ignorance.

The fact that D simulated by H doesn't terminate because H aborts its
simulatiom has no bearing on the Halting Problem. By your logic ALL
machines can be correctly decided to be non-halting, as all the decider
needs to do is halt its simulation for an unsound reason and say it
didn't reach a final state.

This has been pointed out to you many times in the past, and the fact
you still haven't learned it makes you STUPID.

> The following code is executed in the x86utm operating system based on
> an open source x86 emulator. This system enables one C function to
> execute another C function in debug step mode. When H simulates D it
> creates a separate process context for D with its own memory, stack and
> virtual registers. H is able to simulate D simulating itself, thus the
> only limit to recursive simulations is RAM.
>
> 01 int D(int (*x)())
> 02 {
> 03  int Halt_Status = H(x, x);
> 04  if (Halt_Status)
> 05    HERE: goto HERE;
> 06  return Halt_Status;
> 07 }
> 08
> 09 void main()
> 10 {
> 11  H(D,D);
> 12 }
>
> *Execution Trace*
> main() calls H(D,D) that simulates D(D) at line 11
>
> *keeps repeating*
> simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...
>
> Is this clear enough to see that D correctly simulated by H can never
> terminate normally ? (because D remains stuck in recursive simulation) ?
>
>

On 5/19/23 11:46 PM, olcott wrote:
> On 5/19/2023 10:27 PM, Richard Damon wrote:
>> On 5/19/23 11:00 PM, olcott wrote:
>>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>>> On 5/19/23 10:10 PM, olcott wrote:
>>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>
>>>>>>>> Wrong Question!
>>>>>>>>
>>>>>>>
>>>>>>> In other words the question is over you head.
>>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>>
>>>>>> No, it is the WRONG question once you try to apply the answer to
>>>>>> the Halting Problem, which you do.
>>>>>>
>>>>>
>>>>> So the software engineering really is over your head?
>>>>> I see, so like Ben you have never actually written any code.
>>>>
>>>> But you aren't talking about Software Engineering unless you are
>>>> lying about this applying to the Halting Problem described by Linz,
>>>> since that is the Halting Problem of Computability Theory.
>>>>
>>>> Of course, the likely explanation is that you are just ignorant of
>>>> what you are talking about, so you don't understand the diference.
>>>>
>>>>>
>>>>> Ben kept masking his coding incompetence this way.
>>>>> It never occurred to me that you have never written any code.
>>>>
>>>> I have possibly written more WORKING code than you have.
>>>>
>>>>
>>>
>>> I don't believe you. Your inability to answer an straight forward
>>> software engineering question seems to prove otherwise.
>>
>> What software engineering question?
>
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?
> Can D simulated by H terminate normally?

The answer to that question is NO, but that is because H doesn't, and
can never do an accurarte simulation per the definition of a UTM.

Thus, it is the WRONG QUESTION for the problem.

It is a STRAWMAN.

The fact that you fixate on it, shows your ignorance.

The fact that D simulated by H doesn't terminate because H aborts its
simulatiom has no bearing on the Halting Problem. By your logic ALL
machines can be correctly decided to be non-halting, as all the decider
needs to do is halt its simulation for an unsound reason and say it
didn't reach a final state.

This has been pointed out to you many times in the past, and the fact
you still haven't learned it makes you STUPID.

>
> The following code is executed in the x86utm operating system based on
> an open source x86 emulator. This system enables one C function to
> execute another C function in debug step mode. When H simulates D it
> creates a separate process context for D with its own memory, stack and
> virtual registers. H is able to simulate D simulating itself, thus the
> only limit to recursive simulations is RAM.
>
> 01 int D(int (*x)())
> 02 {
> 03  int Halt_Status = H(x, x);
> 04  if (Halt_Status)
> 05    HERE: goto HERE;
> 06  return Halt_Status;
> 07 }
> 08
> 09 void main()
> 10 {
> 11  H(D,D);
> 12 }
>
> *Execution Trace*
> main() calls H(D,D) that simulates D(D) at line 11
>
> *keeps repeating*
> simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...
>
> Is this clear enough to see that D correctly simulated by H can never
> terminate normally ? (because D remains stuck in recursive simulation) ?
>

On 5/20/2023 8:49 AM, Richard Damon wrote:
> On 5/20/23 12:00 AM, olcott wrote:
>> On 5/19/2023 10:27 PM, Richard Damon wrote:
>>> On 5/19/23 11:00 PM, olcott wrote:
>>>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>>>> On 5/19/23 10:10 PM, olcott wrote:
>>>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>>
>>>>>>>>> Wrong Question!
>>>>>>>>>
>>>>>>>>
>>>>>>>> In other words the question is over you head.
>>>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>>>
>>>>>>> No, it is the WRONG question once you try to apply the answer to
>>>>>>> the Halting Problem, which you do.
>>>>>>>
>>>>>>
>>>>>> So the software engineering really is over your head?
>>>>>> I see, so like Ben you have never actually written any code.
>>>>>
>>>>> But you aren't talking about Software Engineering unless you are
>>>>> lying about this applying to the Halting Problem described by Linz,
>>>>> since that is the Halting Problem of Computability Theory.
>>>>>
>>>>> Of course, the likely explanation is that you are just ignorant of
>>>>> what you are talking about, so you don't understand the diference.
>>>>>
>>>>>>
>>>>>> Ben kept masking his coding incompetence this way.
>>>>>> It never occurred to me that you have never written any code.
>>>>>
>>>>> I have possibly written more WORKING code than you have.
>>>>>
>>>>>
>>>>
>>>> I don't believe you. Your inability to answer an straight forward
>>>> software engineering question seems to prove otherwise.
>>>
>>> What software engineering question?
>>>
>>
>>
>> Can D simulated by H terminate normally?
>> Can D simulated by H terminate normally?
>> Can D simulated by H terminate normally?
>> Can D simulated by H terminate normally?
>> Can D simulated by H terminate normally?
>> Can D simulated by H terminate normally?
>> Can D simulated by H terminate normally?
>>
>
> The answer to that question is NO,

Finally you admit an easily verified fact.

> but that is because H doesn't, and
> can never do an accurarte simulation per the definition of a UTM.
>
If the simulation by a UTM would be wrong then you would have to be able
to point out the mistake in the simulation of D by H,

because H and D are isomorphic to embedded_H and ⟨Ĥ⟩

yet you already admitted that the simulation by H does prevent the
simulated D from terminating normally. So you have painted yourself in a
corner on this.

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

On 5/20/23 10:54 AM, olcott wrote:
> On 5/20/2023 8:49 AM, Richard Damon wrote:
>> On 5/20/23 12:00 AM, olcott wrote:
>>> On 5/19/2023 10:27 PM, Richard Damon wrote:
>>>> On 5/19/23 11:00 PM, olcott wrote:
>>>>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>>>>> On 5/19/23 10:10 PM, olcott wrote:
>>>>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>>>
>>>>>>>>>> Wrong Question!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In other words the question is over you head.
>>>>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>>>>
>>>>>>>> No, it is the WRONG question once you try to apply the answer to
>>>>>>>> the Halting Problem, which you do.
>>>>>>>>
>>>>>>>
>>>>>>> So the software engineering really is over your head?
>>>>>>> I see, so like Ben you have never actually written any code.
>>>>>>
>>>>>> But you aren't talking about Software Engineering unless you are
>>>>>> lying about this applying to the Halting Problem described by
>>>>>> Linz, since that is the Halting Problem of Computability Theory.
>>>>>>
>>>>>> Of course, the likely explanation is that you are just ignorant of
>>>>>> what you are talking about, so you don't understand the diference.
>>>>>>
>>>>>>>
>>>>>>> Ben kept masking his coding incompetence this way.
>>>>>>> It never occurred to me that you have never written any code.
>>>>>>
>>>>>> I have possibly written more WORKING code than you have.
>>>>>>
>>>>>>
>>>>>
>>>>> I don't believe you. Your inability to answer an straight forward
>>>>> software engineering question seems to prove otherwise.
>>>>
>>>> What software engineering question?
>>>>
>>>
>>>
>>> Can D simulated by H terminate normally?
>>> Can D simulated by H terminate normally?
>>> Can D simulated by H terminate normally?
>>> Can D simulated by H terminate normally?
>>> Can D simulated by H terminate normally?
>>> Can D simulated by H terminate normally?
>>> Can D simulated by H terminate normally?
>>>
>>
>> The answer to that question is NO,
>
> Finally you admit an easily verified fact.
>
>> but that is because H doesn't, and can never do an accurarte
>> simulation per the definition of a UTM.
>>
> If the simulation by a UTM would be wrong then you would have to be able
> to point out the mistake in the simulation of D by H,

No, the simulation by a ACTUAL UTM will reach a final state.

H, which isn't a UTM, can't do that.

>
> because H and D are isomorphic to embedded_H and ⟨Ĥ⟩

No, D is Ĥ, &D is (Ĥ)

>
> yet you already admitted that the simulation by H does prevent the
> simulated D from terminating normally. So you have painted yourself in a
> corner on this.
>
>

Right, because H isn't a UTM. If it was, it would fail to answer, and
thus not be a decider. (By Definition, UTM of a non-halting input never
halts and gives an answer, so if H WAS a UTM, it could never correctly
answer non-halting, doing so makes it NOT a UTM).

YOU have shown yourself to be a LIAR, because this has been explained to
you before, and you refuse to learn it.

UTM(D,D) will Halt, since D(D) will Halt because H(D,D) returns 0.

Thus H(D,D) returning 0 is INCORRECT.

Only because you stupidily think you can just "define" H to be a UTM
"plus" when it fails to meet the requirements of a UTM, can you even
attempt your unsound and invalid arguement.

Basically, we have a case where you are told that Jack knows the answer
to the problem, so you ask Jim for the answer. Even if you ask Jim what
would Jack say, since Jim doesn't know the answer, either he doesn't
answer or he lies, or he just makes up an answer.

The UTM is Jack.

Your H is Jim, it isn't actually a UTM, so it doesn't actually have the
answer in this case, so it needs to either blatantly lie, or just guess,
and due to the structure of D, it will always guess wrong.

On 5/20/2023 10:19 AM, Richard Damon wrote:
> On 5/20/23 10:54 AM, olcott wrote:
>> On 5/20/2023 8:49 AM, Richard Damon wrote:
>>> On 5/20/23 12:00 AM, olcott wrote:
>>>> On 5/19/2023 10:27 PM, Richard Damon wrote:
>>>>> On 5/19/23 11:00 PM, olcott wrote:
>>>>>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>>>>>> On 5/19/23 10:10 PM, olcott wrote:
>>>>>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>>>>
>>>>>>>>>>> Wrong Question!
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In other words the question is over you head.
>>>>>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>>>>>
>>>>>>>>> No, it is the WRONG question once you try to apply the answer
>>>>>>>>> to the Halting Problem, which you do.
>>>>>>>>>
>>>>>>>>
>>>>>>>> So the software engineering really is over your head?
>>>>>>>> I see, so like Ben you have never actually written any code.
>>>>>>>
>>>>>>> But you aren't talking about Software Engineering unless you are
>>>>>>> lying about this applying to the Halting Problem described by
>>>>>>> Linz, since that is the Halting Problem of Computability Theory.
>>>>>>>
>>>>>>> Of course, the likely explanation is that you are just ignorant
>>>>>>> of what you are talking about, so you don't understand the
>>>>>>> diference.
>>>>>>>
>>>>>>>>
>>>>>>>> Ben kept masking his coding incompetence this way.
>>>>>>>> It never occurred to me that you have never written any code.
>>>>>>>
>>>>>>> I have possibly written more WORKING code than you have.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I don't believe you. Your inability to answer an straight forward
>>>>>> software engineering question seems to prove otherwise.
>>>>>
>>>>> What software engineering question?
>>>>>
>>>>
>>>>
>>>> Can D simulated by H terminate normally?
>>>> Can D simulated by H terminate normally?
>>>> Can D simulated by H terminate normally?
>>>> Can D simulated by H terminate normally?
>>>> Can D simulated by H terminate normally?
>>>> Can D simulated by H terminate normally?
>>>> Can D simulated by H terminate normally?
>>>>
>>>
>>> The answer to that question is NO,
>>
>> Finally you admit an easily verified fact.
>>
>>> but that is because H doesn't, and can never do an accurarte
>>> simulation per the definition of a UTM.
>>>
>> If the simulation by a UTM would be wrong then you would have to be able
>> to point out the mistake in the simulation of D by H,
>
> No, the simulation by a ACTUAL UTM will reach a final state.
>
I don't know why you say this when you already know that ⟨Ĥ⟩ correctly
simulated by embedded_H cannot possibly terminate normally.

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

N steps of ⟨Ĥ⟩ correctly simulated by embedded_H are the actual behavior
of this input:
(a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to embedded_H
(b) embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) which simulates
⟨Ĥ⟩ applied to ⟨Ĥ⟩
(c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process

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

On 5/20/23 11:24 AM, olcott wrote:
> On 5/20/2023 10:19 AM, Richard Damon wrote:
>> On 5/20/23 10:54 AM, olcott wrote:
>>> On 5/20/2023 8:49 AM, Richard Damon wrote:
>>>> On 5/20/23 12:00 AM, olcott wrote:
>>>>> On 5/19/2023 10:27 PM, Richard Damon wrote:
>>>>>> On 5/19/23 11:00 PM, olcott wrote:
>>>>>>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>>>>>>> On 5/19/23 10:10 PM, olcott wrote:
>>>>>>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>>>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>>>>>
>>>>>>>>>>>> Wrong Question!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In other words the question is over you head.
>>>>>>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>>>>>>
>>>>>>>>>> No, it is the WRONG question once you try to apply the answer
>>>>>>>>>> to the Halting Problem, which you do.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So the software engineering really is over your head?
>>>>>>>>> I see, so like Ben you have never actually written any code.
>>>>>>>>
>>>>>>>> But you aren't talking about Software Engineering unless you are
>>>>>>>> lying about this applying to the Halting Problem described by
>>>>>>>> Linz, since that is the Halting Problem of Computability Theory.
>>>>>>>>
>>>>>>>> Of course, the likely explanation is that you are just ignorant
>>>>>>>> of what you are talking about, so you don't understand the
>>>>>>>> diference.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ben kept masking his coding incompetence this way.
>>>>>>>>> It never occurred to me that you have never written any code.
>>>>>>>>
>>>>>>>> I have possibly written more WORKING code than you have.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I don't believe you. Your inability to answer an straight forward
>>>>>>> software engineering question seems to prove otherwise.
>>>>>>
>>>>>> What software engineering question?
>>>>>>
>>>>>
>>>>>
>>>>> Can D simulated by H terminate normally?
>>>>> Can D simulated by H terminate normally?
>>>>> Can D simulated by H terminate normally?
>>>>> Can D simulated by H terminate normally?
>>>>> Can D simulated by H terminate normally?
>>>>> Can D simulated by H terminate normally?
>>>>> Can D simulated by H terminate normally?
>>>>>
>>>>
>>>> The answer to that question is NO,
>>>
>>> Finally you admit an easily verified fact.
>>>
>>>> but that is because H doesn't, and can never do an accurarte
>>>> simulation per the definition of a UTM.
>>>>
>>> If the simulation by a UTM would be wrong then you would have to be able
>>> to point out the mistake in the simulation of D by H,
>>
>> No, the simulation by a ACTUAL UTM will reach a final state.
>>
> I don't know why you say this when you already know that ⟨Ĥ⟩ correctly
> simulated by embedded_H cannot possibly terminate normally.

Because embedded_H doesn't actually "Correctly Simulate" its input by
the definintion aquired by your mentioning of a UTM.

Remember, as you have previously pointed out, very word/phrase in a
natural language sentence implicitly has a UUID attached to it to
indicate which of its meanings this use has. When we are talking about a
UTM, the ONLY definition of "Correctly Simulate" that matches, as a
COMPLETE simulation. (Maybe your problem is you don't really understand
what a UTM is). Since the phrase "Correctly Simulates" means completly
simulates, and embedded_H doesn't do that, since it DOES abort its
simulation, your statement of "correctly simulated by embedded_H" is a
statement built on a false premise, and thus unsound.

Thus, your whole arguement fails.

You can't change H / embedded_H to be some other program beside the one
claimed (which does abort) or that means that your Ĥ isn't the Ĥ from
the problem.

You are just showing you are a stupid and ignorant pathological liar.

>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> N steps of ⟨Ĥ⟩ correctly simulated by embedded_H are the actual behavior
> of this input:

Which isn't "Correctly Simulated" per the meaning of the words as
implied by your invoking of the concept of a UTM.

> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to embedded_H
> (b) embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) which simulates
> ⟨Ĥ⟩ applied to ⟨Ĥ⟩
> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process
>
>

And in actuality, (c) doesn't continue the process as the outer
embedded_H aborts its simulation, and returns (incorrectly) non-halting
and the input machine, which then halts.

So a CORRECTLY simulated input will halt, it is just that embedded_H
aborts its simulation, so gets the wrong answer.

On 5/20/2023 11:10 AM, Richard Damon wrote:
> On 5/20/23 11:24 AM, olcott wrote:
>> On 5/20/2023 10:19 AM, Richard Damon wrote:
>>> On 5/20/23 10:54 AM, olcott wrote:
>>>> On 5/20/2023 8:49 AM, Richard Damon wrote:
>>>>> On 5/20/23 12:00 AM, olcott wrote:
>>>>>> On 5/19/2023 10:27 PM, Richard Damon wrote:
>>>>>>> On 5/19/23 11:00 PM, olcott wrote:
>>>>>>>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>>>>>>>> On 5/19/23 10:10 PM, olcott wrote:
>>>>>>>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>>>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wrong Question!
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In other words the question is over you head.
>>>>>>>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>>>>>>>
>>>>>>>>>>> No, it is the WRONG question once you try to apply the answer
>>>>>>>>>>> to the Halting Problem, which you do.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So the software engineering really is over your head?
>>>>>>>>>> I see, so like Ben you have never actually written any code.
>>>>>>>>>
>>>>>>>>> But you aren't talking about Software Engineering unless you
>>>>>>>>> are lying about this applying to the Halting Problem described
>>>>>>>>> by Linz, since that is the Halting Problem of Computability
>>>>>>>>> Theory.
>>>>>>>>>
>>>>>>>>> Of course, the likely explanation is that you are just ignorant
>>>>>>>>> of what you are talking about, so you don't understand the
>>>>>>>>> diference.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ben kept masking his coding incompetence this way.
>>>>>>>>>> It never occurred to me that you have never written any code.
>>>>>>>>>
>>>>>>>>> I have possibly written more WORKING code than you have.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I don't believe you. Your inability to answer an straight forward
>>>>>>>> software engineering question seems to prove otherwise.
>>>>>>>
>>>>>>> What software engineering question?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Can D simulated by H terminate normally?
>>>>>> Can D simulated by H terminate normally?
>>>>>> Can D simulated by H terminate normally?
>>>>>> Can D simulated by H terminate normally?
>>>>>> Can D simulated by H terminate normally?
>>>>>> Can D simulated by H terminate normally?
>>>>>> Can D simulated by H terminate normally?
>>>>>>
>>>>>
>>>>> The answer to that question is NO,
>>>>
>>>> Finally you admit an easily verified fact.
>>>>
>>>>> but that is because H doesn't, and can never do an accurarte
>>>>> simulation per the definition of a UTM.
>>>>>
>>>> If the simulation by a UTM would be wrong then you would have to be
>>>> able
>>>> to point out the mistake in the simulation of D by H,
>>>
>>> No, the simulation by a ACTUAL UTM will reach a final state.
>>>
>> I don't know why you say this when you already know that ⟨Ĥ⟩ correctly
>> simulated by embedded_H cannot possibly terminate normally.
>
>
> Because embedded_H doesn't actually "Correctly Simulate" its input by
> the definintion aquired by your mentioning of a UTM.
>
You have already agreed that it does simulate the first N steps
correctly. It is just as obvious that the behavior pattern of N steps of
⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly terminate normally
even if the value of N is ∞.

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

On 5/20/23 1:09 PM, olcott wrote:
> On 5/20/2023 11:10 AM, Richard Damon wrote:
>> On 5/20/23 11:24 AM, olcott wrote:
>>> On 5/20/2023 10:19 AM, Richard Damon wrote:
>>>> On 5/20/23 10:54 AM, olcott wrote:
>>>>> On 5/20/2023 8:49 AM, Richard Damon wrote:
>>>>>> On 5/20/23 12:00 AM, olcott wrote:
>>>>>>> On 5/19/2023 10:27 PM, Richard Damon wrote:
>>>>>>>> On 5/19/23 11:00 PM, olcott wrote:
>>>>>>>>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>>>>>>>>> On 5/19/23 10:10 PM, olcott wrote:
>>>>>>>>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>>>>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Wrong Question!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> In other words the question is over you head.
>>>>>>>>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it is the WRONG question once you try to apply the
>>>>>>>>>>>> answer to the Halting Problem, which you do.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So the software engineering really is over your head?
>>>>>>>>>>> I see, so like Ben you have never actually written any code.
>>>>>>>>>>
>>>>>>>>>> But you aren't talking about Software Engineering unless you
>>>>>>>>>> are lying about this applying to the Halting Problem described
>>>>>>>>>> by Linz, since that is the Halting Problem of Computability
>>>>>>>>>> Theory.
>>>>>>>>>>
>>>>>>>>>> Of course, the likely explanation is that you are just
>>>>>>>>>> ignorant of what you are talking about, so you don't
>>>>>>>>>> understand the diference.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ben kept masking his coding incompetence this way.
>>>>>>>>>>> It never occurred to me that you have never written any code.
>>>>>>>>>>
>>>>>>>>>> I have possibly written more WORKING code than you have.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't believe you. Your inability to answer an straight forward
>>>>>>>>> software engineering question seems to prove otherwise.
>>>>>>>>
>>>>>>>> What software engineering question?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Can D simulated by H terminate normally?
>>>>>>> Can D simulated by H terminate normally?
>>>>>>> Can D simulated by H terminate normally?
>>>>>>> Can D simulated by H terminate normally?
>>>>>>> Can D simulated by H terminate normally?
>>>>>>> Can D simulated by H terminate normally?
>>>>>>> Can D simulated by H terminate normally?
>>>>>>>
>>>>>>
>>>>>> The answer to that question is NO,
>>>>>
>>>>> Finally you admit an easily verified fact.
>>>>>
>>>>>> but that is because H doesn't, and can never do an accurarte
>>>>>> simulation per the definition of a UTM.
>>>>>>
>>>>> If the simulation by a UTM would be wrong then you would have to be
>>>>> able
>>>>> to point out the mistake in the simulation of D by H,
>>>>
>>>> No, the simulation by a ACTUAL UTM will reach a final state.
>>>>
>>> I don't know why you say this when you already know that ⟨Ĥ⟩ correctly
>>> simulated by embedded_H cannot possibly terminate normally.
>>
>>
>> Because embedded_H doesn't actually "Correctly Simulate" its input by
>> the definintion aquired by your mentioning of a UTM.
>>
> You have already agreed that it does simulate the first N steps
> correctly. It is just as obvious that the behavior pattern of N steps of
> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly terminate normally
> even if the value of N is ∞.
>

But N steps in not ALL steps as required by the actual definition of a UTM.

And, since H DOES abort it simulation, you need to consider that it
does, and thus it doesn't do a correct simulation, so you can't use its
simuation.

You need to decide whcih fact your H implements.

Either it actually does a "Correct Simulation" and thus simulates until
it finds the actual end, which you have shown causes H to never answer, or

it aborts its simulation to give an answer, but then its simulation
doesn't meet the requirements to be "Correct", and when we put the input
that it takes into an ACTUAL UTM, we see that the actual correct
simulation of the input halts, so your H is using incorrect and unsound
logic to make its decision.

You have never answered why you think you answer is correct to say the
input isn't halting, when an actual running of the input is to see it
halts, and the actual correct simulation of the input (by an actual UTM
that doesn't abort) is to show that the correct simulation halts.

You say that the correct simulation by H is different, but you can't
show the step ACTUALLY SIMULATED that shows the actual difference. You
logic confuses the simulation of the simulator with the machine it is
simulating, which are only matchable it the simulator never aborts,
which yours does.

On 5/20/2023 1:15 PM, Richard Damon wrote:
> On 5/20/23 1:09 PM, olcott wrote:
>> On 5/20/2023 11:10 AM, Richard Damon wrote:
>>> On 5/20/23 11:24 AM, olcott wrote:
>>>> On 5/20/2023 10:19 AM, Richard Damon wrote:
>>>>> On 5/20/23 10:54 AM, olcott wrote:
>>>>>> On 5/20/2023 8:49 AM, Richard Damon wrote:
>>>>>>> On 5/20/23 12:00 AM, olcott wrote:
>>>>>>>> On 5/19/2023 10:27 PM, Richard Damon wrote:
>>>>>>>>> On 5/19/23 11:00 PM, olcott wrote:
>>>>>>>>>> On 5/19/2023 9:51 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/19/23 10:10 PM, olcott wrote:
>>>>>>>>>>>> On 5/19/2023 8:56 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/19/23 9:47 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/19/2023 5:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 5/19/23 10:50 AM, olcott wrote:
>>>>>>>>>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Wrong Question!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In other words the question is over you head.
>>>>>>>>>>>>>> It took me many years to recognize this same dodge by Ben.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, it is the WRONG question once you try to apply the
>>>>>>>>>>>>> answer to the Halting Problem, which you do.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So the software engineering really is over your head?
>>>>>>>>>>>> I see, so like Ben you have never actually written any code.
>>>>>>>>>>>
>>>>>>>>>>> But you aren't talking about Software Engineering unless you
>>>>>>>>>>> are lying about this applying to the Halting Problem
>>>>>>>>>>> described by Linz, since that is the Halting Problem of
>>>>>>>>>>> Computability Theory.
>>>>>>>>>>>
>>>>>>>>>>> Of course, the likely explanation is that you are just
>>>>>>>>>>> ignorant of what you are talking about, so you don't
>>>>>>>>>>> understand the diference.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Ben kept masking his coding incompetence this way.
>>>>>>>>>>>> It never occurred to me that you have never written any code.
>>>>>>>>>>>
>>>>>>>>>>> I have possibly written more WORKING code than you have.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't believe you. Your inability to answer an straight forward
>>>>>>>>>> software engineering question seems to prove otherwise.
>>>>>>>>>
>>>>>>>>> What software engineering question?
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>> Can D simulated by H terminate normally?
>>>>>>>>
>>>>>>>
>>>>>>> The answer to that question is NO,
>>>>>>
>>>>>> Finally you admit an easily verified fact.
>>>>>>
>>>>>>> but that is because H doesn't, and can never do an accurarte
>>>>>>> simulation per the definition of a UTM.
>>>>>>>
>>>>>> If the simulation by a UTM would be wrong then you would have to
>>>>>> be able
>>>>>> to point out the mistake in the simulation of D by H,
>>>>>
>>>>> No, the simulation by a ACTUAL UTM will reach a final state.
>>>>>
>>>> I don't know why you say this when you already know that ⟨Ĥ⟩ correctly
>>>> simulated by embedded_H cannot possibly terminate normally.
>>>
>>>
>>> Because embedded_H doesn't actually "Correctly Simulate" its input by
>>> the definintion aquired by your mentioning of a UTM.
>>>
>> You have already agreed that it does simulate the first N steps
>> correctly. It is just as obvious that the behavior pattern of N steps of
>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly terminate normally
>> even if the value of N is ∞.
>>
>
> But N steps in not ALL steps as required by the actual definition of a UTM.
>