Re: The execution trace of HHH1(DDD) shows the divergence

On 6/7/2025 12:29 PM, olcott wrote:

On 6/7/2025 11:20 AM, dbush wrote:

On 6/7/2025 12:17 PM, olcott wrote:

On 6/7/2025 11:14 AM, dbush wrote:

On 6/7/2025 11:33 AM, olcott wrote:

On 6/7/2025 10:17 AM, dbush wrote:

On 6/7/2025 11:12 AM, olcott wrote:

On 6/7/2025 10:08 AM, dbush wrote:

On 6/7/2025 11:06 AM, olcott wrote:

On 6/7/2025 10:01 AM, dbush wrote:

On 6/7/2025 10:58 AM, olcott wrote:

On 6/7/2025 9:56 AM, dbush wrote:

On 6/7/2025 10:54 AM, olcott wrote:

On 6/7/2025 9:51 AM, dbush wrote:

On 6/7/2025 10:32 AM, olcott wrote:

The execution trace of HHH1(DDD) shows the divergence
of DDD emulated by HHH from DDD emulated by HHH1.
>
int main()
{
   HHH1(DDD);
}
>
Shows that DDD emulated by HHH and DDD emulated by
HHH1 diverges as soon as HHH begins emulating itself
emulating DDD.
>
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1              DDD emulated by HHH
[00002183] push ebp               [00002183] push ebp
[00002184] mov ebp,esp            [00002184] mov ebp,esp
[00002186] push 00002183 ; DDD    [00002186] push 00002183 ; DDD
[0000218b] call 000015c3 ; HHH    [0000218b] call 000015c3 ; HHH
*HHH1 emulates DDD once then HHH emulates DDD once, these match*
>
The next instruction of DDD that HHH emulates is at
the machine address of 00002183.
>
The next instruction of DDD that HHH1 emulates is at
the machine address of 00002190.

>
False.
>
The next instruction of DDD that both HHH and HHH1 emulates is at the machine address of 000015c3,

>
*That is not an instruction of DDD*
*That is not an instruction of DDD*
*That is not an instruction of DDD*
*That is not an instruction of DDD*

>
In other words, you're not operating on algorithms.

>
In other words you are not actually paying any attention.
>

>
I'm very much paying to attention to the fact that you stated that the code of the function H is not part of the input and that you're therefore not working on the halting problem.
>

>
You say that I said things that I never said.
>

>
You said that the instruction at address 000015c3 is not part of the input, which means the input to HHH is not an algorithm, and therefore has nothing to do with the halting problem.
>
You really should be honest about not working on the halting problem.

>
I never said that.
>

>
So you're saying that the input to HHH is a description/ specification of algorithm DDD consisting of the fixed code of the function DDD, the fixed code of the function HHH, and the fixed code of everything that HHH calls down to the OS level, and that HHH must therefore report on the behavior of the algorithm described/ specified by its input?

>
The directly executed DDD() would never stop running
unless HHH(DDD) aborts the simulation of its input.
>
The directly executed HHH(DDD) would never stop running
unless HHH(DDD) aborts the simulation of its input.
>
Thus conclusively proving that the input to HHH(DDD)

>
Is not an algorithm, as you have admitted above, and therefore has nothing to do with the halting problem.
>
People might actually take you seriously if you stopped lying about that.

>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     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.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
>

>
>
Irrelevent, as you're not working on the halting problem by your own admission:
>

 I have correctly refuted the conventional proofs of
the Halting Problem

No you haven't, as you're not actually working on the halting problem as you've admitted:
On 5/13/2025 9:54 PM, dbush wrote:
 > On 5/13/2025 9:48 PM, olcott wrote:
 >> On 5/13/2025 8:31 PM, dbush wrote:
 >>> On 5/13/2025 9:27 PM, olcott wrote:
 >>>> On 5/13/2025 8:07 PM, dbush wrote:
 >>>>> On 5/13/2025 5:30 PM, olcott wrote:
 >>>>>> On 5/13/2025 6:43 AM, Richard Damon wrote:
 >>>>>>> On 5/13/25 12:52 AM, olcott wrote:
 >>>>>>>> *simulated D would never stop running unless aborted*
 >>>>>>>> or they themselves could become non-terminating.
 >>>>>>>
 >>>>>>> But you aren't simulating the same PROGRAM D that the original
 >>>>>>> was given.
 >>>>>>>
 >>>>>>
 >>>>>> It is not supposed to be the same program.
 >>>>>
 >>>>> So you *explicitly* admit to changing the input.
 >>>>>
 >>>>
 >>>> The finite string of DD is specific sequence bytes.
 >>>
 >>> Which includes the specific sequence of bytes that is the finite
 >>> string HHH
 >>>
 >>
 >> No it does not. A function calls is not macro inclusion.
 >>
 >
 > Then you admit that your HHH not deciding about algorithms and therefore
 > has nothing to do with the halting problem.
 >
On 6/7/2025 10:56 AM, dbush wrote:
 > On 6/7/2025 10:54 AM, olcott wrote:
 >> On 6/7/2025 9:51 AM, dbush wrote:
 >>> On 6/7/2025 10:32 AM, olcott wrote:
 >>>> The next instruction of DDD that HHH emulates is at
 >>>> the machine address of 00002183.
 >>>>
 >>>> The next instruction of DDD that HHH1 emulates is at
 >>>> the machine address of 00002190.
 >>>
 >>> False.
 >>>
 >>> The next instruction of DDD that both HHH and HHH1 emulates is at the
 >>> machine address of 000015c3,
 >>
 >> *That is not an instruction of DDD*
 >> *That is not an instruction of DDD*
 >> *That is not an instruction of DDD*
 >> *That is not an instruction of DDD*
 >
 > In other words, you're not operating on algorithms.  And since the
 > halting problem is about algorithms, what you're working on has nothing
 > to do with the halting problem.
 >
 > If you would just be honest about the fact that you're not working on
 > the halting problem, people would stop bothering you.