On 1/18/24 2:05 PM, olcott wrote:
> On 1/18/2024 11:55 AM, Mike Terry wrote:
>> On 18/01/2024 17:15, olcott wrote:
>>> On 1/18/2024 10:37 AM, Mike Terry wrote:
>>>> On 18/01/2024 14:47, olcott wrote:
>>>>> On 1/18/2024 6:24 AM, Richard Damon wrote:
>>>>>> On 1/17/24 11:35 PM, olcott wrote:
>>>>>>> *This is true on the basis of the meaning of its words*
>>>>>>>
>>>>>>> The ultimate measure [of a correct simulation] is the correct x86
>>>>>>> emulation of the x86 instructions in the order that they are
>>>>>>> specified.
>>>>>>
>>>>>> And continuing until it finishes. (since the question is DOES it
>>>>>> finish).
>>>>>
>>>>> (a) If simulating termination analyzer H correctly determines that D
>>>>> correctly simulated by H cannot possibly reach its own simulated final
>>>>> state and terminate normally then
>>>>>
>>>>> (b) H can abort its simulation of D and correctly report that D
>>>>> specifies a non-halting sequence of configurations.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> The alternative is incorrectly emulating the x86 instructions in
>>>>>>> some
>>>>>>> other order than they are specified.
>>>>>>>
>>>>>>
>>>>>> No, you are neglecting that partial simulation is incorrect.
>>>>>
>>>>> Mike Terry has corrected you on this many times yet your ADD requires
>>>>> the same thing to be repeated hundreds of times be3fore you ever
>>>>> notice
>>>>> that it was said once.
>>>>
>>>> I have not "corrected" anyone on this.  Stop misrepresenting my
>>>> position - that's a form of lying, and I would have thought your
>>>> religious views would dissuade you from behaving like that, even
>>>> inadvertently.  (You must recognise by now that you often
>>>> misunderstand the points people are making - so even if /you/ think
>>>> they are saying one thing, best to avoid telling everyone else what
>>>> you /think/ their position is - just say your own ideas in your own
>>>> words, and you will avoid getting it wrong.
>>>>
>>>> Additionally, even if I had "corrected" Richard many times, SO WHAT?
>>>> If you and Richard have some disagreement over the exact meaning of
>>>> a phrase, discuss and clarify the situation with Richard - no need
>>>> to drag 3rd parties into the matter in some kind of appeal to
>>>> "authority".
>>>>
>>>>
>>>> Mike.
>>>>
>>>
>>> It is not that case that when N steps of DD are correctly simulated
>>> by HH that these N steps are incorrectly simulated on the basis that
>>> N+1 could have been simulated.
>>>
>>> *Although you understand this Richard does not understand this*
>>
>> It is not a question of "correct understanding".  It's just that
>> different people may have slightly different interpretations for the
>> scope of a phrase like "correct simulation".
>>
>> Do you think that Richard thinks the step by step x86 instruction
>> emulation part of your code is faulty?  Maybe he does, but I doubt
>> that... (and if not we are not disagreeing).  More likely he takes
>> "correct simulation" to mean what I'd call "correct full simulation"
>> or something.  Perhaps you should sort out the facts you actually
>> agree on, then you can move on.
>>
>>
>> Mike.
>>
>
> Richard insists that a correct partial simulation is totally incorrect.

No, just incorrect enough to not allow you to make point (a).

of course, incorrect is like "different" and pregnant, just a little bit
make you fully so.

"Almost the same" (aka "the same but ...") means they are DIFFERENT

>
> You insist that either (a) or (b) are incorrect or
> that a correct simulation of D by H must incorrectly
> emulate the x86 instructions of D or emulate them in
> some other order than they are specified.
>
> (a) If simulating termination analyzer H correctly determines that D
> correctly simulated by H cannot possibly reach its own simulated final
> state and terminate normally then
>
> (b) H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
>
> The ultimate measure [of a correct simulation] is the correct x86
> emulation of the x86 instructions in the order that they are specified.
> The alternative is incorrectly emulating the x86 instructions in some
> other order than they are specified.
>
>
>

On 1/18/24 2:00 PM, olcott wrote:
> On 1/18/2024 11:55 AM, Mike Terry wrote:
>> On 18/01/2024 17:15, olcott wrote:
>>> On 1/18/2024 10:37 AM, Mike Terry wrote:
>>>> On 18/01/2024 14:47, olcott wrote:
>>>>> On 1/18/2024 6:24 AM, Richard Damon wrote:
>>>>>> On 1/17/24 11:35 PM, olcott wrote:
>>>>>>> *This is true on the basis of the meaning of its words*
>>>>>>>
>>>>>>> The ultimate measure [of a correct simulation] is the correct x86
>>>>>>> emulation of the x86 instructions in the order that they are
>>>>>>> specified.
>>>>>>
>>>>>> And continuing until it finishes. (since the question is DOES it
>>>>>> finish).
>>>>>
>>>>> (a) If simulating termination analyzer H correctly determines that D
>>>>> correctly simulated by H cannot possibly reach its own simulated final
>>>>> state and terminate normally then
>>>>>
>>>>> (b) H can abort its simulation of D and correctly report that D
>>>>> specifies a non-halting sequence of configurations.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> The alternative is incorrectly emulating the x86 instructions in
>>>>>>> some
>>>>>>> other order than they are specified.
>>>>>>>
>>>>>>
>>>>>> No, you are neglecting that partial simulation is incorrect.
>>>>>
>>>>> Mike Terry has corrected you on this many times yet your ADD requires
>>>>> the same thing to be repeated hundreds of times be3fore you ever
>>>>> notice
>>>>> that it was said once.
>>>>
>>>> I have not "corrected" anyone on this.  Stop misrepresenting my
>>>> position - that's a form of lying, and I would have thought your
>>>> religious views would dissuade you from behaving like that, even
>>>> inadvertently.  (You must recognise by now that you often
>>>> misunderstand the points people are making - so even if /you/ think
>>>> they are saying one thing, best to avoid telling everyone else what
>>>> you /think/ their position is - just say your own ideas in your own
>>>> words, and you will avoid getting it wrong.
>>>>
>>>> Additionally, even if I had "corrected" Richard many times, SO WHAT?
>>>> If you and Richard have some disagreement over the exact meaning of
>>>> a phrase, discuss and clarify the situation with Richard - no need
>>>> to drag 3rd parties into the matter in some kind of appeal to
>>>> "authority".
>>>>
>>>>
>>>> Mike.
>>>>
>>>
>>> It is not that case that when N steps of DD are correctly simulated
>>> by HH that these N steps are incorrectly simulated on the basis that
>>> N+1 could have been simulated.
>>>
>>> *Although you understand this Richard does not understand this*
>>
>> It is not a question of "correct understanding".  It's just that
>> different people may have slightly different interpretations for the
>> scope of a phrase like "correct simulation".
>>
>> Do you think that Richard thinks the step by step x86 instruction
>> emulation part of your code is faulty?  Maybe he does, but I doubt
>> that... (and if not we are not disagreeing).  More likely he takes
>> "correct simulation" to mean what I'd call "correct full simulation"
>> or something.  Perhaps you should sort out the facts you actually
>> agree on, then you can move on.
>>
>>
>> Mike.
>>
>
> Richard insists that a correct partial simulation is totally incorrect.

Which it is if used to substitute for the actual behavior of the machine
actually ran.

That fact that you don't understand this implication of your argument
just proves that you have no understanding of the field you are trying
to talk about.

You have self-imposed ignorance of the field, and thus are unqualified
to make judgements in it.

On 1/18/24 2:13 PM, olcott wrote:
> On 1/18/2024 11:53 AM, immibis wrote:
>> On 1/18/24 18:15, olcott wrote:
>>> On 1/18/2024 10:37 AM, Mike Terry wrote:
>>>> On 18/01/2024 14:47, olcott wrote:
>>>>> On 1/18/2024 6:24 AM, Richard Damon wrote:
>>>>>> On 1/17/24 11:35 PM, olcott wrote:
>>>>>>> *This is true on the basis of the meaning of its words*
>>>>>>>
>>>>>>> The ultimate measure [of a correct simulation] is the correct x86
>>>>>>> emulation of the x86 instructions in the order that they are
>>>>>>> specified.
>>>>>>
>>>>>> And continuing until it finishes. (since the question is DOES it
>>>>>> finish).
>>>>>
>>>>> (a) If simulating termination analyzer H correctly determines that D
>>>>> correctly simulated by H cannot possibly reach its own simulated final
>>>>> state and terminate normally then
>>>>>
>>>>> (b) H can abort its simulation of D and correctly report that D
>>>>> specifies a non-halting sequence of configurations.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> The alternative is incorrectly emulating the x86 instructions in
>>>>>>> some
>>>>>>> other order than they are specified.
>>>>>>>
>>>>>>
>>>>>> No, you are neglecting that partial simulation is incorrect.
>>>>>
>>>>> Mike Terry has corrected you on this many times yet your ADD requires
>>>>> the same thing to be repeated hundreds of times be3fore you ever
>>>>> notice
>>>>> that it was said once.
>>>>
>>>> I have not "corrected" anyone on this.  Stop misrepresenting my
>>>> position - that's a form of lying, and I would have thought your
>>>> religious views would dissuade you from behaving like that, even
>>>> inadvertently.  (You must recognise by now that you often
>>>> misunderstand the points people are making - so even if /you/ think
>>>> they are saying one thing, best to avoid telling everyone else what
>>>> you /think/ their position is - just say your own ideas in your own
>>>> words, and you will avoid getting it wrong.
>>>>
>>>> Additionally, even if I had "corrected" Richard many times, SO WHAT?
>>>> If you and Richard have some disagreement over the exact meaning of
>>>> a phrase, discuss and clarify the situation with Richard - no need
>>>> to drag 3rd parties into the matter in some kind of appeal to
>>>> "authority".
>>>>
>>>>
>>>> Mike.
>>>>
>>>
>>> It is not that case that when N steps of DD are correctly simulated
>>> by HH that these N steps are incorrectly simulated on the basis that
>>> N+1 could have been simulated.
>>>
>>> *Although you understand this Richard does not understand this*
>>>
>>>
>> The first N steps are not incorrect. The non-halting pattern
>> recognition is incorrect.
>
> I have proved that DD correctly simulated by H cannot possibly reach
> its final state. That you don't understand the x86 language well enough
> to understand this IS YOUR MISTAKE NOT MINE.
>

Which doesn't prove that the pattern seen for the first N steps is
always non-halting.

Since the first N steps don't see some of the future code executed, it
is impossible for them to determine the future behavior.

On 1/18/24 12:15 PM, olcott wrote:
> On 1/18/2024 10:37 AM, Mike Terry wrote:
>> On 18/01/2024 14:47, olcott wrote:
>>> On 1/18/2024 6:24 AM, Richard Damon wrote:
>>>> On 1/17/24 11:35 PM, olcott wrote:
>>>>> *This is true on the basis of the meaning of its words*
>>>>>
>>>>> The ultimate measure [of a correct simulation] is the correct x86
>>>>> emulation of the x86 instructions in the order that they are
>>>>> specified.
>>>>
>>>> And continuing until it finishes. (since the question is DOES it
>>>> finish).
>>>
>>> (a) If simulating termination analyzer H correctly determines that D
>>> correctly simulated by H cannot possibly reach its own simulated final
>>> state and terminate normally then
>>>
>>> (b) H can abort its simulation of D and correctly report that D
>>> specifies a non-halting sequence of configurations.
>>>
>>>>
>>>>>
>>>>> The alternative is incorrectly emulating the x86 instructions in some
>>>>> other order than they are specified.
>>>>>
>>>>
>>>> No, you are neglecting that partial simulation is incorrect.
>>>
>>> Mike Terry has corrected you on this many times yet your ADD requires
>>> the same thing to be repeated hundreds of times be3fore you ever notice
>>> that it was said once.
>>
>> I have not "corrected" anyone on this.  Stop misrepresenting my
>> position - that's a form of lying, and I would have thought your
>> religious views would dissuade you from behaving like that, even
>> inadvertently.  (You must recognise by now that you often
>> misunderstand the points people are making - so even if /you/ think
>> they are saying one thing, best to avoid telling everyone else what
>> you /think/ their position is - just say your own ideas in your own
>> words, and you will avoid getting it wrong.
>>
>> Additionally, even if I had "corrected" Richard many times, SO WHAT?
>> If you and Richard have some disagreement over the exact meaning of a
>> phrase, discuss and clarify the situation with Richard - no need to
>> drag 3rd parties into the matter in some kind of appeal to "authority".
>>
>>
>> Mike.
>>
>
> It is not that case that when N steps of DD are correctly simulated
> by HH that these N steps are incorrectly simulated on the basis that
> N+1 could have been simulated.
>
> *Although you understand this Richard does not understand this*
>
>

But a partial simulation is not a "Correct Simulation" for the purpose
of replacing the actual behavior of the program described by the input
with the "correct simulation" of it.

So, you are just admitting that you whole argument is based on
fallacious definitions.

This is the fundamental problem with trying to build your logic system
on "Natural Language", it just is too ambiguous.

By the needed definition, that mere act of aborting a simulation is
INCORRECT, as it does not reflect the actual behavior of the machine,
since the machine continues at that point.

This error is made very obvious when you start to try to argue that the
machine never gets to that latter point, because it was aborted! The
machine was NOT aborted and continues, only the simulation was, and thus
the simulator has no knowledge of what actually happens, especially if
the program gets into sections of code never seen in the simulation.

On 1/18/24 9:47 AM, olcott wrote:
> On 1/18/2024 6:24 AM, Richard Damon wrote:
>> On 1/17/24 11:35 PM, olcott wrote:
>>> *This is true on the basis of the meaning of its words*
>>>
>>> The ultimate measure [of a correct simulation] is the correct x86
>>> emulation of the x86 instructions in the order that they are specified.
>>
>> And continuing until it finishes. (since the question is DOES it finish).
>
> (a) If simulating termination analyzer H correctly determines that D
> correctly simulated by H cannot possibly reach its own simulated final
> state and terminate normally then

Which it doesn't do, and H never did an actual correct simulation.

Since the CORRECT simulation of the input D will see D call H, then H
simulate the input for a while, then abort and return non-halting to D
and then D halting, you neven acheived (a)

>
> (b) H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.

Since (a) wa

>
>>
>>>
>>> The alternative is incorrectly emulating the x86 instructions in some
>>> other order than they are specified.
>>>
>>
>> No, you are neglecting that partial simulation is incorrect.
>
> Mike Terry has corrected you on this many times yet your ADD requires
> the same thing to be repeated hundreds of times be3fore you ever notice
> that it was said once.

Where did he ebver say that a partial simulation was correct by the
definition needed to replace the actual behavior with the simulation?

Just more of your lies and proof of your stupidity.

>>
>> Also, "guessing" what a function call does without actually knowing is
>> incorrect.
>>
>
> That you do not know the x86 language to verify that DD correctly
> simulated by HH does derive a repeated state is not any rebuttal
> what-so-ever.

It is easy to verify that and version of D that calls an H that returns
the non-halting answer will halt.

Yes, a D built on an H that NEVER aborts its simulation will be
correctly simulated by that H and will never halt, but such an H fails
to be a decider.

Only an insane moron would think these two DIFFERENT program/input pairs
are the same.

I guess, that shows what you are.

>
> Why do you insist that your own ignorance is a correct basis for a
> rebuttal?
>
> Begin Local Halt Decider Simulation        Execution Trace Stored at:113027
> [00001c42][00113013][00113017] 55          push ebp
> [00001c43][00113013][00113017] 8bec        mov ebp,esp
> [00001c45][0011300f][00102fe3] 51          push ecx
> [00001c46][0011300f][00102fe3] 8b4508      mov eax,[ebp+08] ; DD
> [00001c49][0011300b][00001c42] 50          push eax         ; DD
> [00001c4a][0011300b][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
> [00001c4d][00113007][00001c42] 51          push ecx         ; DD
> [00001c4e][00113003][00001c53] e80ff7ffff  call 00001362    ; HH
> New slave_stack at:14da47

DANGER!!!
Incorrect simulation!!!!

Call 00001362 needs to be followed by the simulation of the instruction
at 00001362

Obviously YOU are the one that doesn't understand how x86 assembly works,

> [00001c42][0015da3b][0015da3f] 55          push ebp
> [00001c43][0015da3b][0015da3f] 8bec        mov ebp,esp
> [00001c45][0015da37][0014da0b] 51          push ecx
> [00001c46][0015da37][0014da0b] 8b4508      mov eax,[ebp+08] ; DD
> [00001c49][0015da33][00001c42] 50          push eax         ; DD
> [00001c4a][0015da33][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
> [00001c4d][0015da2f][00001c42] 51          push ecx         ; DD
> [00001c4e][0015da2b][00001c53] e80ff7ffff  call 00001362    ; HH
>
> _DD()
> [00001c42] 55         push ebp
> [00001c43] 8bec       mov ebp,esp
> [00001c45] 51         push ecx
> [00001c46] 8b4508     mov eax,[ebp+08] ; DD
> [00001c49] 50         push eax         ; DD
> [00001c4a] 8b4d08     mov ecx,[ebp+08] ; DD
> [00001c4d] 51         push ecx         ; DD
> [00001c4e] e80ff7ffff call 00001362    ; HH

Which isn't a complete program (as you have admitted) and thus is a
category error for asking about Halting.

>
> *As proven above*
> DD correctly simulated by HH cannot possibly
> reach past the above machine address.
>
> The ultimate measure [of a correct simulation] is the correct x86
> emulation of the x86 instructions in the order that they are specified.

which did not happen for the call 00001362 instruction.

>
> The alternative is incorrectly emulating the x86 instructions in some
> other order than they are specified.
>

So, you are just proving you don't understand the meaning of "Correct"

Since it seems your father was the father of lies, I guess that isn't
surprizing.

On 1/18/24 22:05, olcott wrote:
> On 1/18/2024 2:42 PM, immibis wrote:
>> On 1/18/24 21:03, olcott wrote:
>>> On 1/18/2024 1:46 PM, immibis wrote:
>>>> On 1/18/24 20:30, olcott wrote:
>>>>> On 1/18/2024 1:19 PM, immibis wrote:
>>>>>> On 1/18/24 20:05, olcott wrote:
>>>>>>> On 1/18/2024 11:55 AM, Mike Terry wrote:
>>>>>>>> On 18/01/2024 17:15, olcott wrote:
>>>>>>>>> On 1/18/2024 10:37 AM, Mike Terry wrote:
>>>>>>>>>> On 18/01/2024 14:47, olcott wrote:
>>>>>>>>>>> On 1/18/2024 6:24 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/17/24 11:35 PM, olcott wrote:
>>>>>>>>>>>>> *This is true on the basis of the meaning of its words*
>>>>>>>>>>>>>
>>>>>>>>>>>>> The ultimate measure [of a correct simulation] is the
>>>>>>>>>>>>> correct x86
>>>>>>>>>>>>> emulation of the x86 instructions in the order that they
>>>>>>>>>>>>> are specified.
>>>>>>>>>>>>
>>>>>>>>>>>> And continuing until it finishes. (since the question is
>>>>>>>>>>>> DOES it finish).
>>>>>>>>>>>
>>>>>>>>>>> (a) If simulating termination analyzer H correctly determines
>>>>>>>>>>> that D
>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>> simulated final
>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>
>>>>>>>>>>> (b) H can abort its simulation of D and correctly report that
>>>>>>>>>>> D specifies a non-halting sequence of configurations.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The alternative is incorrectly emulating the x86
>>>>>>>>>>>>> instructions in some
>>>>>>>>>>>>> other order than they are specified.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, you are neglecting that partial simulation is incorrect.
>>>>>>>>>>>
>>>>>>>>>>> Mike Terry has corrected you on this many times yet your ADD
>>>>>>>>>>> requires
>>>>>>>>>>> the same thing to be repeated hundreds of times be3fore you
>>>>>>>>>>> ever notice
>>>>>>>>>>> that it was said once.
>>>>>>>>>>
>>>>>>>>>> I have not "corrected" anyone on this.  Stop misrepresenting
>>>>>>>>>> my position - that's a form of lying, and I would have thought
>>>>>>>>>> your religious views would dissuade you from behaving like
>>>>>>>>>> that, even inadvertently.  (You must recognise by now that you
>>>>>>>>>> often misunderstand the points people are making - so even if
>>>>>>>>>> /you/ think they are saying one thing, best to avoid telling
>>>>>>>>>> everyone else what you /think/ their position is - just say
>>>>>>>>>> your own ideas in your own words, and you will avoid getting
>>>>>>>>>> it wrong.
>>>>>>>>>>
>>>>>>>>>> Additionally, even if I had "corrected" Richard many times, SO
>>>>>>>>>> WHAT? If you and Richard have some disagreement over the exact
>>>>>>>>>> meaning of a phrase, discuss and clarify the situation with
>>>>>>>>>> Richard - no need to drag 3rd parties into the matter in some
>>>>>>>>>> kind of appeal to "authority".
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Mike.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is not that case that when N steps of DD are correctly
>>>>>>>>> simulated
>>>>>>>>> by HH that these N steps are incorrectly simulated on the basis
>>>>>>>>> that
>>>>>>>>> N+1 could have been simulated.
>>>>>>>>>
>>>>>>>>> *Although you understand this Richard does not understand this*
>>>>>>>>
>>>>>>>> It is not a question of "correct understanding".  It's just that
>>>>>>>> different people may have slightly different interpretations for
>>>>>>>> the scope of a phrase like "correct simulation".
>>>>>>>>
>>>>>>>> Do you think that Richard thinks the step by step x86
>>>>>>>> instruction emulation part of your code is faulty?  Maybe he
>>>>>>>> does, but I doubt that... (and if not we are not disagreeing).
>>>>>>>> More likely he takes "correct simulation" to mean what I'd call
>>>>>>>> "correct full simulation" or something.  Perhaps you should sort
>>>>>>>> out the facts you actually agree on, then you can move on.
>>>>>>>>
>>>>>>>>
>>>>>>>> Mike.
>>>>>>>>
>>>>>>>
>>>>>>> Richard insists that a correct partial simulation is totally
>>>>>>> incorrect.
>>>>>>>
>>>>>>> You insist that either (a) or (b) are incorrect or
>>>>>>> that a correct simulation of D by H must incorrectly
>>>>>>> emulate the x86 instructions of D or emulate them in
>>>>>>> some other order than they are specified.
>>>>>>
>>>>>> Your simulation skips over the non-halting pattern detection
>>>>>> instructions by aborting the simulation before they execute.
>>>>>>
>>>>>
>>>>> *Not so much*
>>>>>
>>>>> Begin Local Halt Decider Simulation        Execution Trace Stored
>>>>> at:113027
>>>>> [00001c42][00113013][00113017] 55          push ebp
>>>>> [00001c43][00113013][00113017] 8bec        mov ebp,esp
>>>>> [00001c45][0011300f][00102fe3] 51          push ecx
>>>>> [00001c46][0011300f][00102fe3] 8b4508      mov eax,[ebp+08] ; DD
>>>>> [00001c49][0011300b][00001c42] 50          push eax         ; DD
>>>>> [00001c4a][0011300b][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
>>>>> [00001c4d][00113007][00001c42] 51          push ecx         ; DD
>>>>> [00001c4e][00113003][00001c53] e80ff7ffff  call 00001362    ; HH
>>>>> New slave_stack at:14da47
>>>>> [00001c42][0015da3b][0015da3f] 55          push ebp
>>>>> [00001c43][0015da3b][0015da3f] 8bec        mov ebp,esp
>>>>> [00001c45][0015da37][0014da0b] 51          push ecx
>>>>> [00001c46][0015da37][0014da0b] 8b4508      mov eax,[ebp+08] ; DD
>>>>> [00001c49][0015da33][00001c42] 50          push eax         ; DD
>>>>> [00001c4a][0015da33][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
>>>>> [00001c4d][0015da2f][00001c42] 51          push ecx         ; DD
>>>>> [00001c4e][0015da2b][00001c53] e80ff7ffff  call 00001362    ; HH
>>>>>
>>>>> _DD()
>>>>> [00001c42] 55         push ebp
>>>>> [00001c43] 8bec       mov ebp,esp
>>>>> [00001c45] 51         push ecx
>>>>> [00001c46] 8b4508     mov eax,[ebp+08] ; DD
>>>>> [00001c49] 50         push eax         ; DD
>>>>> [00001c4a] 8b4d08     mov ecx,[ebp+08] ; DD
>>>>> [00001c4d] 51         push ecx         ; DD
>>>>> [00001c4e] e80ff7ffff call 00001362    ; HH
>>>>> [00001c53] 83c408     add esp,+08
>>>>> [00001c56] 8945fc     mov [ebp-04],eax
>>>>> [00001c59] 837dfc00   cmp dword [ebp-04],+00
>>>>> [00001c5d] 7402       jz 00001c61
>>>>> [00001c5f] ebfe       jmp 00001c5f
>>>>> [00001c61] 8b45fc     mov eax,[ebp-04]
>>>>> [00001c64] 8be5       mov esp,ebp
>>>>> [00001c66] 5d         pop ebp
>>>>> [00001c67] c3         ret
>>>>> Size in bytes:(0038) [00001c67]
>>>>>
>>>>
>>>> Where is the non-halting pattern detection being simulated?
>>>
>>> repeating instructions [00001c42] to [00001c4e]
>>>
>> Which instruction detects non-halting patterns?
>
> First of all can you see that this sequence repeats?
>

On 1/19/2024 3:39 AM, immibis wrote:
> On 1/18/24 22:05, olcott wrote:
>> On 1/18/2024 2:42 PM, immibis wrote:
>>> On 1/18/24 21:03, olcott wrote:
>>>> On 1/18/2024 1:46 PM, immibis wrote:
>>>>> On 1/18/24 20:30, olcott wrote:
>>>>>> On 1/18/2024 1:19 PM, immibis wrote:
>>>>>>> On 1/18/24 20:05, olcott wrote:
>>>>>>>> On 1/18/2024 11:55 AM, Mike Terry wrote:
>>>>>>>>> On 18/01/2024 17:15, olcott wrote:
>>>>>>>>>> On 1/18/2024 10:37 AM, Mike Terry wrote:
>>>>>>>>>>> On 18/01/2024 14:47, olcott wrote:
>>>>>>>>>>>> On 1/18/2024 6:24 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/17/24 11:35 PM, olcott wrote:
>>>>>>>>>>>>>> *This is true on the basis of the meaning of its words*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The ultimate measure [of a correct simulation] is the
>>>>>>>>>>>>>> correct x86
>>>>>>>>>>>>>> emulation of the x86 instructions in the order that they
>>>>>>>>>>>>>> are specified.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And continuing until it finishes. (since the question is
>>>>>>>>>>>>> DOES it finish).
>>>>>>>>>>>>
>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>> determines that D
>>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>>> simulated final
>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>
>>>>>>>>>>>> (b) H can abort its simulation of D and correctly report
>>>>>>>>>>>> that D specifies a non-halting sequence of configurations.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The alternative is incorrectly emulating the x86
>>>>>>>>>>>>>> instructions in some
>>>>>>>>>>>>>> other order than they are specified.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, you are neglecting that partial simulation is incorrect.
>>>>>>>>>>>>
>>>>>>>>>>>> Mike Terry has corrected you on this many times yet your ADD
>>>>>>>>>>>> requires
>>>>>>>>>>>> the same thing to be repeated hundreds of times be3fore you
>>>>>>>>>>>> ever notice
>>>>>>>>>>>> that it was said once.
>>>>>>>>>>>
>>>>>>>>>>> I have not "corrected" anyone on this.  Stop misrepresenting
>>>>>>>>>>> my position - that's a form of lying, and I would have
>>>>>>>>>>> thought your religious views would dissuade you from behaving
>>>>>>>>>>> like that, even inadvertently.  (You must recognise by now
>>>>>>>>>>> that you often misunderstand the points people are making -
>>>>>>>>>>> so even if /you/ think they are saying one thing, best to
>>>>>>>>>>> avoid telling everyone else what you /think/ their position
>>>>>>>>>>> is - just say your own ideas in your own words, and you will
>>>>>>>>>>> avoid getting it wrong.
>>>>>>>>>>>
>>>>>>>>>>> Additionally, even if I had "corrected" Richard many times,
>>>>>>>>>>> SO WHAT? If you and Richard have some disagreement over the
>>>>>>>>>>> exact meaning of a phrase, discuss and clarify the situation
>>>>>>>>>>> with Richard - no need to drag 3rd parties into the matter in
>>>>>>>>>>> some kind of appeal to "authority".
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Mike.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is not that case that when N steps of DD are correctly
>>>>>>>>>> simulated
>>>>>>>>>> by HH that these N steps are incorrectly simulated on the
>>>>>>>>>> basis that
>>>>>>>>>> N+1 could have been simulated.
>>>>>>>>>>
>>>>>>>>>> *Although you understand this Richard does not understand this*
>>>>>>>>>
>>>>>>>>> It is not a question of "correct understanding".  It's just
>>>>>>>>> that different people may have slightly different
>>>>>>>>> interpretations for the scope of a phrase like "correct
>>>>>>>>> simulation".
>>>>>>>>>
>>>>>>>>> Do you think that Richard thinks the step by step x86
>>>>>>>>> instruction emulation part of your code is faulty?  Maybe he
>>>>>>>>> does, but I doubt that... (and if not we are not disagreeing).
>>>>>>>>> More likely he takes "correct simulation" to mean what I'd call
>>>>>>>>> "correct full simulation" or something.  Perhaps you should
>>>>>>>>> sort out the facts you actually agree on, then you can move on.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Richard insists that a correct partial simulation is totally
>>>>>>>> incorrect.
>>>>>>>>
>>>>>>>> You insist that either (a) or (b) are incorrect or
>>>>>>>> that a correct simulation of D by H must incorrectly
>>>>>>>> emulate the x86 instructions of D or emulate them in
>>>>>>>> some other order than they are specified.
>>>>>>>
>>>>>>> Your simulation skips over the non-halting pattern detection
>>>>>>> instructions by aborting the simulation before they execute.
>>>>>>>
>>>>>>
>>>>>> *Not so much*
>>>>>>
>>>>>> Begin Local Halt Decider Simulation        Execution Trace Stored
>>>>>> at:113027
>>>>>> [00001c42][00113013][00113017] 55          push ebp
>>>>>> [00001c43][00113013][00113017] 8bec        mov ebp,esp
>>>>>> [00001c45][0011300f][00102fe3] 51          push ecx
>>>>>> [00001c46][0011300f][00102fe3] 8b4508      mov eax,[ebp+08] ; DD
>>>>>> [00001c49][0011300b][00001c42] 50          push eax         ; DD
>>>>>> [00001c4a][0011300b][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
>>>>>> [00001c4d][00113007][00001c42] 51          push ecx         ; DD
>>>>>> [00001c4e][00113003][00001c53] e80ff7ffff  call 00001362    ; HH
>>>>>> New slave_stack at:14da47
>>>>>> [00001c42][0015da3b][0015da3f] 55          push ebp
>>>>>> [00001c43][0015da3b][0015da3f] 8bec        mov ebp,esp
>>>>>> [00001c45][0015da37][0014da0b] 51          push ecx
>>>>>> [00001c46][0015da37][0014da0b] 8b4508      mov eax,[ebp+08] ; DD
>>>>>> [00001c49][0015da33][00001c42] 50          push eax         ; DD
>>>>>> [00001c4a][0015da33][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
>>>>>> [00001c4d][0015da2f][00001c42] 51          push ecx         ; DD
>>>>>> [00001c4e][0015da2b][00001c53] e80ff7ffff  call 00001362    ; HH
>>>>>>
>>>>>> _DD()
>>>>>> [00001c42] 55         push ebp
>>>>>> [00001c43] 8bec       mov ebp,esp
>>>>>> [00001c45] 51         push ecx
>>>>>> [00001c46] 8b4508     mov eax,[ebp+08] ; DD
>>>>>> [00001c49] 50         push eax         ; DD
>>>>>> [00001c4a] 8b4d08     mov ecx,[ebp+08] ; DD
>>>>>> [00001c4d] 51         push ecx         ; DD
>>>>>> [00001c4e] e80ff7ffff call 00001362    ; HH
>>>>>> [00001c53] 83c408     add esp,+08
>>>>>> [00001c56] 8945fc     mov [ebp-04],eax
>>>>>> [00001c59] 837dfc00   cmp dword [ebp-04],+00
>>>>>> [00001c5d] 7402       jz 00001c61
>>>>>> [00001c5f] ebfe       jmp 00001c5f
>>>>>> [00001c61] 8b45fc     mov eax,[ebp-04]
>>>>>> [00001c64] 8be5       mov esp,ebp
>>>>>> [00001c66] 5d         pop ebp
>>>>>> [00001c67] c3         ret
>>>>>> Size in bytes:(0038) [00001c67]
>>>>>>
>>>>>
>>>>> Where is the non-halting pattern detection being simulated?
>>>>
>>>> repeating instructions [00001c42] to [00001c4e]
>>>>
>>> Which instruction detects non-halting patterns?
>>
>> First of all can you see that this sequence repeats?
>>
>
> First of all can you see this sequence skips over instructions which are
> present in the program?

On 1/19/24 9:05 AM, olcott wrote:
> On 1/19/2024 3:39 AM, immibis wrote:
>> On 1/18/24 22:05, olcott wrote:
>>> On 1/18/2024 2:42 PM, immibis wrote:
>>>> On 1/18/24 21:03, olcott wrote:
>>>>> On 1/18/2024 1:46 PM, immibis wrote:
>>>>>> On 1/18/24 20:30, olcott wrote:
>>>>>>> On 1/18/2024 1:19 PM, immibis wrote:
>>>>>>>> On 1/18/24 20:05, olcott wrote:
>>>>>>>>> On 1/18/2024 11:55 AM, Mike Terry wrote:
>>>>>>>>>> On 18/01/2024 17:15, olcott wrote:
>>>>>>>>>>> On 1/18/2024 10:37 AM, Mike Terry wrote:
>>>>>>>>>>>> On 18/01/2024 14:47, olcott wrote:
>>>>>>>>>>>>> On 1/18/2024 6:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/17/24 11:35 PM, olcott wrote:
>>>>>>>>>>>>>>> *This is true on the basis of the meaning of its words*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The ultimate measure [of a correct simulation] is the
>>>>>>>>>>>>>>> correct x86
>>>>>>>>>>>>>>> emulation of the x86 instructions in the order that they
>>>>>>>>>>>>>>> are specified.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And continuing until it finishes. (since the question is
>>>>>>>>>>>>>> DOES it finish).
>>>>>>>>>>>>>
>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>>>> simulated final
>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>
>>>>>>>>>>>>> (b) H can abort its simulation of D and correctly report
>>>>>>>>>>>>> that D specifies a non-halting sequence of configurations.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The alternative is incorrectly emulating the x86
>>>>>>>>>>>>>>> instructions in some
>>>>>>>>>>>>>>> other order than they are specified.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, you are neglecting that partial simulation is incorrect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mike Terry has corrected you on this many times yet your
>>>>>>>>>>>>> ADD requires
>>>>>>>>>>>>> the same thing to be repeated hundreds of times be3fore you
>>>>>>>>>>>>> ever notice
>>>>>>>>>>>>> that it was said once.
>>>>>>>>>>>>
>>>>>>>>>>>> I have not "corrected" anyone on this.  Stop misrepresenting
>>>>>>>>>>>> my position - that's a form of lying, and I would have
>>>>>>>>>>>> thought your religious views would dissuade you from
>>>>>>>>>>>> behaving like that, even inadvertently.  (You must recognise
>>>>>>>>>>>> by now that you often misunderstand the points people are
>>>>>>>>>>>> making - so even if /you/ think they are saying one thing,
>>>>>>>>>>>> best to avoid telling everyone else what you /think/ their
>>>>>>>>>>>> position is - just say your own ideas in your own words, and
>>>>>>>>>>>> you will avoid getting it wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> Additionally, even if I had "corrected" Richard many times,
>>>>>>>>>>>> SO WHAT? If you and Richard have some disagreement over the
>>>>>>>>>>>> exact meaning of a phrase, discuss and clarify the situation
>>>>>>>>>>>> with Richard - no need to drag 3rd parties into the matter
>>>>>>>>>>>> in some kind of appeal to "authority".
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Mike.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It is not that case that when N steps of DD are correctly
>>>>>>>>>>> simulated
>>>>>>>>>>> by HH that these N steps are incorrectly simulated on the
>>>>>>>>>>> basis that
>>>>>>>>>>> N+1 could have been simulated.
>>>>>>>>>>>
>>>>>>>>>>> *Although you understand this Richard does not understand this*
>>>>>>>>>>
>>>>>>>>>> It is not a question of "correct understanding".  It's just
>>>>>>>>>> that different people may have slightly different
>>>>>>>>>> interpretations for the scope of a phrase like "correct
>>>>>>>>>> simulation".
>>>>>>>>>>
>>>>>>>>>> Do you think that Richard thinks the step by step x86
>>>>>>>>>> instruction emulation part of your code is faulty?  Maybe he
>>>>>>>>>> does, but I doubt that... (and if not we are not disagreeing).
>>>>>>>>>> More likely he takes "correct simulation" to mean what I'd
>>>>>>>>>> call "correct full simulation" or something.  Perhaps you
>>>>>>>>>> should sort out the facts you actually agree on, then you can
>>>>>>>>>> move on.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Mike.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Richard insists that a correct partial simulation is totally
>>>>>>>>> incorrect.
>>>>>>>>>
>>>>>>>>> You insist that either (a) or (b) are incorrect or
>>>>>>>>> that a correct simulation of D by H must incorrectly
>>>>>>>>> emulate the x86 instructions of D or emulate them in
>>>>>>>>> some other order than they are specified.
>>>>>>>>
>>>>>>>> Your simulation skips over the non-halting pattern detection
>>>>>>>> instructions by aborting the simulation before they execute.
>>>>>>>>
>>>>>>>
>>>>>>> *Not so much*
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation        Execution Trace Stored
>>>>>>> at:113027
>>>>>>> [00001c42][00113013][00113017] 55          push ebp
>>>>>>> [00001c43][00113013][00113017] 8bec        mov ebp,esp
>>>>>>> [00001c45][0011300f][00102fe3] 51          push ecx
>>>>>>> [00001c46][0011300f][00102fe3] 8b4508      mov eax,[ebp+08] ; DD
>>>>>>> [00001c49][0011300b][00001c42] 50          push eax         ; DD
>>>>>>> [00001c4a][0011300b][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
>>>>>>> [00001c4d][00113007][00001c42] 51          push ecx         ; DD
>>>>>>> [00001c4e][00113003][00001c53] e80ff7ffff  call 00001362    ; HH
>>>>>>> New slave_stack at:14da47
>>>>>>> [00001c42][0015da3b][0015da3f] 55          push ebp
>>>>>>> [00001c43][0015da3b][0015da3f] 8bec        mov ebp,esp
>>>>>>> [00001c45][0015da37][0014da0b] 51          push ecx
>>>>>>> [00001c46][0015da37][0014da0b] 8b4508      mov eax,[ebp+08] ; DD
>>>>>>> [00001c49][0015da33][00001c42] 50          push eax         ; DD
>>>>>>> [00001c4a][0015da33][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
>>>>>>> [00001c4d][0015da2f][00001c42] 51          push ecx         ; DD
>>>>>>> [00001c4e][0015da2b][00001c53] e80ff7ffff  call 00001362    ; HH
>>>>>>>
>>>>>>> _DD()
>>>>>>> [00001c42] 55         push ebp
>>>>>>> [00001c43] 8bec       mov ebp,esp
>>>>>>> [00001c45] 51         push ecx
>>>>>>> [00001c46] 8b4508     mov eax,[ebp+08] ; DD
>>>>>>> [00001c49] 50         push eax         ; DD
>>>>>>> [00001c4a] 8b4d08     mov ecx,[ebp+08] ; DD
>>>>>>> [00001c4d] 51         push ecx         ; DD
>>>>>>> [00001c4e] e80ff7ffff call 00001362    ; HH
>>>>>>> [00001c53] 83c408     add esp,+08
>>>>>>> [00001c56] 8945fc     mov [ebp-04],eax
>>>>>>> [00001c59] 837dfc00   cmp dword [ebp-04],+00
>>>>>>> [00001c5d] 7402       jz 00001c61
>>>>>>> [00001c5f] ebfe       jmp 00001c5f
>>>>>>> [00001c61] 8b45fc     mov eax,[ebp-04]
>>>>>>> [00001c64] 8be5       mov esp,ebp
>>>>>>> [00001c66] 5d         pop ebp
>>>>>>> [00001c67] c3         ret
>>>>>>> Size in bytes:(0038) [00001c67]
>>>>>>>
>>>>>>
>>>>>> Where is the non-halting pattern detection being simulated?
>>>>>
>>>>> repeating instructions [00001c42] to [00001c4e]
>>>>>
>>>> Which instruction detects non-halting patterns?
>>>
>>> First of all can you see that this sequence repeats?
>>>
>>
>> First of all can you see this sequence skips over instructions which
>> are present in the program?
>
> The instructions that it skips are unreachable for
> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>

On 1/19/24 15:05, olcott wrote:
> On 1/19/2024 3:39 AM, immibis wrote:
>>
>> First of all can you see this sequence skips over instructions which
>> are present in the program?
>
> The instructions that it skips are unreachable for
> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>

How are they reachable in the directly executed DD and HH?

On 1/19/2024 12:08 PM, immibis wrote:
> On 1/19/24 15:05, olcott wrote:
>> On 1/19/2024 3:39 AM, immibis wrote:
>>>
>>> First of all can you see this sequence skips over instructions which
>>> are present in the program?
>>
>> The instructions that it skips are unreachable for
>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>
>
> How are they reachable in the directly executed DD and HH?

When HH correctly simulates DD and correctly determines
that this simulated DD cannot possibly halt it aborts this
simulation and returns to its caller.

When the directly executed DD(DD) calls the directly
executed HH(DD,DD) it benefits from HH aborting its
simulation that cannot possibly otherwise halt.

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

On 1/19/24 19:47, olcott wrote:
> On 1/19/2024 12:08 PM, immibis wrote:
>> On 1/19/24 15:05, olcott wrote:
>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>
>>>> First of all can you see this sequence skips over instructions which
>>>> are present in the program?
>>>
>>> The instructions that it skips are unreachable for
>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>
>>
>> How are they reachable in the directly executed DD and HH?
>
> When HH correctly simulates DD and correctly determines
> that this simulated DD cannot possibly halt it aborts this
> simulation and returns to its caller.

Which instructions perform this determination?

Why aren't they in the trace?

On 1/19/2024 2:43 PM, immibis wrote:
> On 1/19/24 19:47, olcott wrote:
>> On 1/19/2024 12:08 PM, immibis wrote:
>>> On 1/19/24 15:05, olcott wrote:
>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>
>>>>> First of all can you see this sequence skips over instructions
>>>>> which are present in the program?
>>>>
>>>> The instructions that it skips are unreachable for
>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>
>>>
>>> How are they reachable in the directly executed DD and HH?
>>
>> When HH correctly simulates DD and correctly determines
>> that this simulated DD cannot possibly halt it aborts this
>> simulation and returns to its caller.
>
> Which instructions perform this determination?
>
> Why aren't they in the trace?

Whether or not DD correctly simulated by HH can possibly
reach its own simulated final state has nothing to do with
the other 251 pages of the execution trace of HH.

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

On 1/19/24 1:47 PM, olcott wrote:
> On 1/19/2024 12:08 PM, immibis wrote:
>> On 1/19/24 15:05, olcott wrote:
>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>
>>>> First of all can you see this sequence skips over instructions which
>>>> are present in the program?
>>>
>>> The instructions that it skips are unreachable for
>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>
>>
>> How are they reachable in the directly executed DD and HH?
>
> When HH correctly simulates DD and correctly determines
> that this simulated DD cannot possibly halt it aborts this
> simulation and returns to its caller.
>
> When the directly executed DD(DD) calls the directly
> executed HH(DD,DD) it benefits from HH aborting its
> simulation that cannot possibly otherwise halt.
>

And if HH did correctly simulate its input, it would know that the HH
that it simulating will do that same thing, so HH is just INCORRECT in
its logic that assumes that DD can not possibly halt.

HH can't assume that HH will just correctly simulate until it gets the
correct answer if HH doesn't do that. Of course, since it has been
proven that if HH EVER aborts and returns non-halting, it made an
incorrect decision, any HH that correctly simulates until it can correct
decide ends up never aborting and thus failing to be a decider.

So, any HH that assumes that HH will be correct, is incorrect, and any
HH that understands what is happening will just not answer.

On 1/19/24 4:07 PM, olcott wrote:
> On 1/19/2024 2:43 PM, immibis wrote:
>> On 1/19/24 19:47, olcott wrote:
>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>> On 1/19/24 15:05, olcott wrote:
>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>
>>>>>> First of all can you see this sequence skips over instructions
>>>>>> which are present in the program?
>>>>>
>>>>> The instructions that it skips are unreachable for
>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>
>>>>
>>>> How are they reachable in the directly executed DD and HH?
>>>
>>> When HH correctly simulates DD and correctly determines
>>> that this simulated DD cannot possibly halt it aborts this
>>> simulation and returns to its caller.
>>
>> Which instructions perform this determination?
>>
>> Why aren't they in the trace?
>
> Whether or not DD correctly simulated by HH can possibly
> reach its own simulated final state has nothing to do with
> the other 251 pages of the execution trace of HH.
>

Except that it shows that HH did not actually see the needed condition.

On 1/19/24 22:07, olcott wrote:
> On 1/19/2024 2:43 PM, immibis wrote:
>> On 1/19/24 19:47, olcott wrote:
>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>> On 1/19/24 15:05, olcott wrote:
>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>
>>>>>> First of all can you see this sequence skips over instructions
>>>>>> which are present in the program?
>>>>>
>>>>> The instructions that it skips are unreachable for
>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>
>>>>
>>>> How are they reachable in the directly executed DD and HH?
>>>
>>> When HH correctly simulates DD and correctly determines
>>> that this simulated DD cannot possibly halt it aborts this
>>> simulation and returns to its caller.
>>
>> Which instructions perform this determination?
>>
>> Why aren't they in the trace?
>
> Whether or not DD correctly simulated by HH can possibly
> reach its own simulated final state has nothing to do with
> the other 251 pages of the execution trace of HH.
>

Some of the instructions in H make H reach its final state and terminate
normally.

On 1/19/2024 3:40 PM, immibis wrote:
> On 1/19/24 22:07, olcott wrote:
>> On 1/19/2024 2:43 PM, immibis wrote:
>>> On 1/19/24 19:47, olcott wrote:
>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>
>>>>>>> First of all can you see this sequence skips over instructions
>>>>>>> which are present in the program?
>>>>>>
>>>>>> The instructions that it skips are unreachable for
>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>
>>>>>
>>>>> How are they reachable in the directly executed DD and HH?
>>>>
>>>> When HH correctly simulates DD and correctly determines
>>>> that this simulated DD cannot possibly halt it aborts this
>>>> simulation and returns to its caller.
>>>
>>> Which instructions perform this determination?
>>>
>>> Why aren't they in the trace?
>>
>> Whether or not DD correctly simulated by HH can possibly
>> reach its own simulated final state has nothing to do with
>> the other 251 pages of the execution trace of HH.
>>
>
> Some of the instructions in H make H reach its final state and terminate
> normally.

DD correctly simulated by HH cannot possibly halt because
DD specifies recursive simulation to HH.

What computer language are you an expert in?

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

On 1/19/24 23:20, olcott wrote:
> On 1/19/2024 3:40 PM, immibis wrote:
>> On 1/19/24 22:07, olcott wrote:
>>> On 1/19/2024 2:43 PM, immibis wrote:
>>>> On 1/19/24 19:47, olcott wrote:
>>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>>
>>>>>>>> First of all can you see this sequence skips over instructions
>>>>>>>> which are present in the program?
>>>>>>>
>>>>>>> The instructions that it skips are unreachable for
>>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>>
>>>>>>
>>>>>> How are they reachable in the directly executed DD and HH?
>>>>>
>>>>> When HH correctly simulates DD and correctly determines
>>>>> that this simulated DD cannot possibly halt it aborts this
>>>>> simulation and returns to its caller.
>>>>
>>>> Which instructions perform this determination?
>>>>
>>>> Why aren't they in the trace?
>>>
>>> Whether or not DD correctly simulated by HH can possibly
>>> reach its own simulated final state has nothing to do with
>>> the other 251 pages of the execution trace of HH.
>>>
>>
>> Some of the instructions in H make H reach its final state and
>> terminate normally.
>
> DD correctly simulated by HH cannot possibly halt because
> DD specifies recursive simulation to HH.
>
> What computer language are you an expert in?
>

DD directly executed cannot possibly halt because DD specifies recursive
simulation to the CPU.

On 1/19/2024 4:38 PM, immibis wrote:
> On 1/19/24 23:20, olcott wrote:
>> On 1/19/2024 3:40 PM, immibis wrote:
>>> On 1/19/24 22:07, olcott wrote:
>>>> On 1/19/2024 2:43 PM, immibis wrote:
>>>>> On 1/19/24 19:47, olcott wrote:
>>>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>>>
>>>>>>>>> First of all can you see this sequence skips over instructions
>>>>>>>>> which are present in the program?
>>>>>>>>
>>>>>>>> The instructions that it skips are unreachable for
>>>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>>>
>>>>>>>
>>>>>>> How are they reachable in the directly executed DD and HH?
>>>>>>
>>>>>> When HH correctly simulates DD and correctly determines
>>>>>> that this simulated DD cannot possibly halt it aborts this
>>>>>> simulation and returns to its caller.
>>>>>
>>>>> Which instructions perform this determination?
>>>>>
>>>>> Why aren't they in the trace?
>>>>
>>>> Whether or not DD correctly simulated by HH can possibly
>>>> reach its own simulated final state has nothing to do with
>>>> the other 251 pages of the execution trace of HH.
>>>>
>>>
>>> Some of the instructions in H make H reach its final state and
>>> terminate normally.
>>
>> DD correctly simulated by HH cannot possibly halt because
>> DD specifies recursive simulation to HH.
>>
>> What computer language are you an expert in?
>>
>
> DD directly executed cannot possibly halt because DD specifies recursive
> simulation to the CPU.

What computer language are you an expert in?
What computer language are you an expert in?
What computer language are you an expert in?
What computer language are you an expert in?
My guess is none.

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

On 1/19/24 23:39, olcott wrote:
> On 1/19/2024 4:38 PM, immibis wrote:
>> On 1/19/24 23:20, olcott wrote:
>>> On 1/19/2024 3:40 PM, immibis wrote:
>>>> On 1/19/24 22:07, olcott wrote:
>>>>> On 1/19/2024 2:43 PM, immibis wrote:
>>>>>> On 1/19/24 19:47, olcott wrote:
>>>>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>>>>
>>>>>>>>>> First of all can you see this sequence skips over instructions
>>>>>>>>>> which are present in the program?
>>>>>>>>>
>>>>>>>>> The instructions that it skips are unreachable for
>>>>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>>>>
>>>>>>>>
>>>>>>>> How are they reachable in the directly executed DD and HH?
>>>>>>>
>>>>>>> When HH correctly simulates DD and correctly determines
>>>>>>> that this simulated DD cannot possibly halt it aborts this
>>>>>>> simulation and returns to its caller.
>>>>>>
>>>>>> Which instructions perform this determination?
>>>>>>
>>>>>> Why aren't they in the trace?
>>>>>
>>>>> Whether or not DD correctly simulated by HH can possibly
>>>>> reach its own simulated final state has nothing to do with
>>>>> the other 251 pages of the execution trace of HH.
>>>>>
>>>>
>>>> Some of the instructions in H make H reach its final state and
>>>> terminate normally.
>>>
>>> DD correctly simulated by HH cannot possibly halt because
>>> DD specifies recursive simulation to HH.
>>>
>>> What computer language are you an expert in?
>>>
>>
>> DD directly executed cannot possibly halt because DD specifies
>> recursive simulation to the CPU.
>
>
> What computer language are you an expert in?
> What computer language are you an expert in?
> What computer language are you an expert in?
> What computer language are you an expert in?
> My guess is none.
>

You cannot comment on the point. If DD specifies recursive simulation,
then it specifies recursive simulation to the CPU as well. Aren't there
some instructions in DD that tell it when to abort recursive simulation?

On 1/20/2024 4:01 AM, immibis wrote:
> On 1/19/24 23:39, olcott wrote:
>> On 1/19/2024 4:38 PM, immibis wrote:
>>> On 1/19/24 23:20, olcott wrote:
>>>> On 1/19/2024 3:40 PM, immibis wrote:
>>>>> On 1/19/24 22:07, olcott wrote:
>>>>>> On 1/19/2024 2:43 PM, immibis wrote:
>>>>>>> On 1/19/24 19:47, olcott wrote:
>>>>>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>>>>>
>>>>>>>>>>> First of all can you see this sequence skips over
>>>>>>>>>>> instructions which are present in the program?
>>>>>>>>>>
>>>>>>>>>> The instructions that it skips are unreachable for
>>>>>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How are they reachable in the directly executed DD and HH?
>>>>>>>>
>>>>>>>> When HH correctly simulates DD and correctly determines
>>>>>>>> that this simulated DD cannot possibly halt it aborts this
>>>>>>>> simulation and returns to its caller.
>>>>>>>
>>>>>>> Which instructions perform this determination?
>>>>>>>
>>>>>>> Why aren't they in the trace?
>>>>>>
>>>>>> Whether or not DD correctly simulated by HH can possibly
>>>>>> reach its own simulated final state has nothing to do with
>>>>>> the other 251 pages of the execution trace of HH.
>>>>>>
>>>>>
>>>>> Some of the instructions in H make H reach its final state and
>>>>> terminate normally.
>>>>
>>>> DD correctly simulated by HH cannot possibly halt because
>>>> DD specifies recursive simulation to HH.
>>>>
>>>> What computer language are you an expert in?
>>>>
>>>
>>> DD directly executed cannot possibly halt because DD specifies
>>> recursive simulation to the CPU.
>>
>>
>> What computer language are you an expert in?
>> What computer language are you an expert in?
>> What computer language are you an expert in?
>> What computer language are you an expert in?
>> My guess is none.
>>
>
> You cannot comment on the point.

In others words by refusing to answer you implicitly
acknowledge that you not an expert in any computer languages.

> If DD specifies recursive simulation,
> then it specifies recursive simulation to the CPU as well. Aren't there
> some instructions in DD that tell it when to abort recursive simulation?

If you know the C programming language then you can answer that
yourself. Do you see any "if" statement before the call to HH(x,x) ???

int DD(int (*x)())
{ int Halt_Status = HH(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

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

On 1/20/24 16:19, olcott wrote:
> On 1/20/2024 4:01 AM, immibis wrote:
>> On 1/19/24 23:39, olcott wrote:
>>> On 1/19/2024 4:38 PM, immibis wrote:
>>>> On 1/19/24 23:20, olcott wrote:
>>>>> On 1/19/2024 3:40 PM, immibis wrote:
>>>>>> On 1/19/24 22:07, olcott wrote:
>>>>>>> On 1/19/2024 2:43 PM, immibis wrote:
>>>>>>>> On 1/19/24 19:47, olcott wrote:
>>>>>>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>>>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> First of all can you see this sequence skips over
>>>>>>>>>>>> instructions which are present in the program?
>>>>>>>>>>>
>>>>>>>>>>> The instructions that it skips are unreachable for
>>>>>>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How are they reachable in the directly executed DD and HH?
>>>>>>>>>
>>>>>>>>> When HH correctly simulates DD and correctly determines
>>>>>>>>> that this simulated DD cannot possibly halt it aborts this
>>>>>>>>> simulation and returns to its caller.
>>>>>>>>
>>>>>>>> Which instructions perform this determination?
>>>>>>>>
>>>>>>>> Why aren't they in the trace?
>>>>>>>
>>>>>>> Whether or not DD correctly simulated by HH can possibly
>>>>>>> reach its own simulated final state has nothing to do with
>>>>>>> the other 251 pages of the execution trace of HH.
>>>>>>>
>>>>>>
>>>>>> Some of the instructions in H make H reach its final state and
>>>>>> terminate normally.
>>>>>
>>>>> DD correctly simulated by HH cannot possibly halt because
>>>>> DD specifies recursive simulation to HH.
>>>>>
>>>>> What computer language are you an expert in?
>>>>>
>>>>
>>>> DD directly executed cannot possibly halt because DD specifies
>>>> recursive simulation to the CPU.
>>>
>>>
>>> What computer language are you an expert in?
>>> What computer language are you an expert in?
>>> What computer language are you an expert in?
>>> What computer language are you an expert in?
>>> My guess is none.
>>>
>>
>> You cannot comment on the point.
>
> In others words by refusing to answer you implicitly
> acknowledge that you not an expert in any computer languages.
>
>> If DD specifies recursive simulation, then it specifies recursive
>> simulation to the CPU as well. Aren't there some instructions in DD
>> that tell it when to abort recursive simulation?
>
> If you know the C programming language then you can answer that
> yourself. Do you see any "if" statement before the call to HH(x,x) ???
>
> int DD(int (*x)())
> {
>   int Halt_Status = HH(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return Halt_Status;
> }
>
Doesn't HH also have code *inside* it?

On 1/20/24 10:19 AM, olcott wrote:
> On 1/20/2024 4:01 AM, immibis wrote:
>> On 1/19/24 23:39, olcott wrote:
>>> On 1/19/2024 4:38 PM, immibis wrote:
>>>> On 1/19/24 23:20, olcott wrote:
>>>>> On 1/19/2024 3:40 PM, immibis wrote:
>>>>>> On 1/19/24 22:07, olcott wrote:
>>>>>>> On 1/19/2024 2:43 PM, immibis wrote:
>>>>>>>> On 1/19/24 19:47, olcott wrote:
>>>>>>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>>>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> First of all can you see this sequence skips over
>>>>>>>>>>>> instructions which are present in the program?
>>>>>>>>>>>
>>>>>>>>>>> The instructions that it skips are unreachable for
>>>>>>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How are they reachable in the directly executed DD and HH?
>>>>>>>>>
>>>>>>>>> When HH correctly simulates DD and correctly determines
>>>>>>>>> that this simulated DD cannot possibly halt it aborts this
>>>>>>>>> simulation and returns to its caller.
>>>>>>>>
>>>>>>>> Which instructions perform this determination?
>>>>>>>>
>>>>>>>> Why aren't they in the trace?
>>>>>>>
>>>>>>> Whether or not DD correctly simulated by HH can possibly
>>>>>>> reach its own simulated final state has nothing to do with
>>>>>>> the other 251 pages of the execution trace of HH.
>>>>>>>
>>>>>>
>>>>>> Some of the instructions in H make H reach its final state and
>>>>>> terminate normally.
>>>>>
>>>>> DD correctly simulated by HH cannot possibly halt because
>>>>> DD specifies recursive simulation to HH.
>>>>>
>>>>> What computer language are you an expert in?
>>>>>
>>>>
>>>> DD directly executed cannot possibly halt because DD specifies
>>>> recursive simulation to the CPU.
>>>
>>>
>>> What computer language are you an expert in?
>>> What computer language are you an expert in?
>>> What computer language are you an expert in?
>>> What computer language are you an expert in?
>>> My guess is none.
>>>
>>
>> You cannot comment on the point.
>
> In others words by refusing to answer you implicitly
> acknowledge that you not an expert in any computer languages.
>
>> If DD specifies recursive simulation, then it specifies recursive
>> simulation to the CPU as well. Aren't there some instructions in DD
>> that tell it when to abort recursive simulation?
>
> If you know the C programming language then you can answer that
> yourself. Do you see any "if" statement before the call to HH(x,x) ???
>
> int DD(int (*x)())
> {
>   int Halt_Status = HH(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return Halt_Status;
> }
>

But HH is part of the PROGRAM DD, and there are ifs in HH.

The fact that you don't understand what a simple computer program is,
and think you can have one with undefined function references says that
YOU are the one that doesn't understand programming.

On 1/20/2024 11:09 AM, immibis wrote:
> On 1/20/24 16:19, olcott wrote:
>> On 1/20/2024 4:01 AM, immibis wrote:
>>> On 1/19/24 23:39, olcott wrote:
>>>> On 1/19/2024 4:38 PM, immibis wrote:
>>>>> On 1/19/24 23:20, olcott wrote:
>>>>>> On 1/19/2024 3:40 PM, immibis wrote:
>>>>>>> On 1/19/24 22:07, olcott wrote:
>>>>>>>> On 1/19/2024 2:43 PM, immibis wrote:
>>>>>>>>> On 1/19/24 19:47, olcott wrote:
>>>>>>>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>>>>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>>>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> First of all can you see this sequence skips over
>>>>>>>>>>>>> instructions which are present in the program?
>>>>>>>>>>>>
>>>>>>>>>>>> The instructions that it skips are unreachable for
>>>>>>>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> How are they reachable in the directly executed DD and HH?
>>>>>>>>>>
>>>>>>>>>> When HH correctly simulates DD and correctly determines
>>>>>>>>>> that this simulated DD cannot possibly halt it aborts this
>>>>>>>>>> simulation and returns to its caller.
>>>>>>>>>
>>>>>>>>> Which instructions perform this determination?
>>>>>>>>>
>>>>>>>>> Why aren't they in the trace?
>>>>>>>>
>>>>>>>> Whether or not DD correctly simulated by HH can possibly
>>>>>>>> reach its own simulated final state has nothing to do with
>>>>>>>> the other 251 pages of the execution trace of HH.
>>>>>>>>
>>>>>>>
>>>>>>> Some of the instructions in H make H reach its final state and
>>>>>>> terminate normally.
>>>>>>
>>>>>> DD correctly simulated by HH cannot possibly halt because
>>>>>> DD specifies recursive simulation to HH.
>>>>>>
>>>>>> What computer language are you an expert in?
>>>>>>
>>>>>
>>>>> DD directly executed cannot possibly halt because DD specifies
>>>>> recursive simulation to the CPU.
>>>>
>>>>
>>>> What computer language are you an expert in?
>>>> What computer language are you an expert in?
>>>> What computer language are you an expert in?
>>>> What computer language are you an expert in?
>>>> My guess is none.
>>>>
>>>
>>> You cannot comment on the point.
>>
>> In others words by refusing to answer you implicitly
>> acknowledge that you not an expert in any computer languages.
>>
>>> If DD specifies recursive simulation, then it specifies recursive
>>> simulation to the CPU as well. Aren't there some instructions in DD
>>> that tell it when to abort recursive simulation?
>>
>> If you know the C programming language then you can answer that
>> yourself. Do you see any "if" statement before the call to HH(x,x) ???
>>
>> int DD(int (*x)())
>> {
>>    int Halt_Status = HH(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return Halt_Status;
>> }
>>
> Doesn't HH also have code *inside* it?

There is another 151 pages of the execution trace of
HH correctly simulating itself simulating DD.

What you cannot understand because you have insufficient
technical competence is that nothing that any HH can possibly
do can possibly enable DD correctly simulated by HH
to reach its own simulated final state and halt.

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

On 1/20/24 12:50 PM, olcott wrote:
> On 1/20/2024 11:09 AM, immibis wrote:
>> On 1/20/24 16:19, olcott wrote:
>>> On 1/20/2024 4:01 AM, immibis wrote:
>>>> On 1/19/24 23:39, olcott wrote:
>>>>> On 1/19/2024 4:38 PM, immibis wrote:
>>>>>> On 1/19/24 23:20, olcott wrote:
>>>>>>> On 1/19/2024 3:40 PM, immibis wrote:
>>>>>>>> On 1/19/24 22:07, olcott wrote:
>>>>>>>>> On 1/19/2024 2:43 PM, immibis wrote:
>>>>>>>>>> On 1/19/24 19:47, olcott wrote:
>>>>>>>>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>>>>>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>>>>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> First of all can you see this sequence skips over
>>>>>>>>>>>>>> instructions which are present in the program?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The instructions that it skips are unreachable for
>>>>>>>>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> How are they reachable in the directly executed DD and HH?
>>>>>>>>>>>
>>>>>>>>>>> When HH correctly simulates DD and correctly determines
>>>>>>>>>>> that this simulated DD cannot possibly halt it aborts this
>>>>>>>>>>> simulation and returns to its caller.
>>>>>>>>>>
>>>>>>>>>> Which instructions perform this determination?
>>>>>>>>>>
>>>>>>>>>> Why aren't they in the trace?
>>>>>>>>>
>>>>>>>>> Whether or not DD correctly simulated by HH can possibly
>>>>>>>>> reach its own simulated final state has nothing to do with
>>>>>>>>> the other 251 pages of the execution trace of HH.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Some of the instructions in H make H reach its final state and
>>>>>>>> terminate normally.
>>>>>>>
>>>>>>> DD correctly simulated by HH cannot possibly halt because
>>>>>>> DD specifies recursive simulation to HH.
>>>>>>>
>>>>>>> What computer language are you an expert in?
>>>>>>>
>>>>>>
>>>>>> DD directly executed cannot possibly halt because DD specifies
>>>>>> recursive simulation to the CPU.
>>>>>
>>>>>
>>>>> What computer language are you an expert in?
>>>>> What computer language are you an expert in?
>>>>> What computer language are you an expert in?
>>>>> What computer language are you an expert in?
>>>>> My guess is none.
>>>>>
>>>>
>>>> You cannot comment on the point.
>>>
>>> In others words by refusing to answer you implicitly
>>> acknowledge that you not an expert in any computer languages.
>>>
>>>> If DD specifies recursive simulation, then it specifies recursive
>>>> simulation to the CPU as well. Aren't there some instructions in DD
>>>> that tell it when to abort recursive simulation?
>>>
>>> If you know the C programming language then you can answer that
>>> yourself. Do you see any "if" statement before the call to HH(x,x) ???
>>>
>>> int DD(int (*x)())
>>> {
>>>    int Halt_Status = HH(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return Halt_Status;
>>> }
>>>
>> Doesn't HH also have code *inside* it?
>
> There is another 151 pages of the execution trace of
> HH correctly simulating itself simulating DD.
>
> What you cannot understand because you have insufficient
> technical competence is that nothing that any HH can possibly
> do can possibly enable DD correctly simulated by HH
> to reach its own simulated final state and halt.
>

And you refuse MY request to post the data that you claim to have that
shows where this trace of HH differs from the dirrect execution to allow
it to be correctly different.

Just more of your lies.

On 1/20/24 18:50, olcott wrote:
> On 1/20/2024 11:09 AM, immibis wrote:
>> On 1/20/24 16:19, olcott wrote:
>>> On 1/20/2024 4:01 AM, immibis wrote:
>>>> On 1/19/24 23:39, olcott wrote:
>>>>> On 1/19/2024 4:38 PM, immibis wrote:
>>>>>> On 1/19/24 23:20, olcott wrote:
>>>>>>> On 1/19/2024 3:40 PM, immibis wrote:
>>>>>>>> On 1/19/24 22:07, olcott wrote:
>>>>>>>>> On 1/19/2024 2:43 PM, immibis wrote:
>>>>>>>>>> On 1/19/24 19:47, olcott wrote:
>>>>>>>>>>> On 1/19/2024 12:08 PM, immibis wrote:
>>>>>>>>>>>> On 1/19/24 15:05, olcott wrote:
>>>>>>>>>>>>> On 1/19/2024 3:39 AM, immibis wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> First of all can you see this sequence skips over
>>>>>>>>>>>>>> instructions which are present in the program?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The instructions that it skips are unreachable for
>>>>>>>>>>>>> DD correctly simulated by HH. THIS IS OVER YOUR HEAD.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> How are they reachable in the directly executed DD and HH?
>>>>>>>>>>>
>>>>>>>>>>> When HH correctly simulates DD and correctly determines
>>>>>>>>>>> that this simulated DD cannot possibly halt it aborts this
>>>>>>>>>>> simulation and returns to its caller.
>>>>>>>>>>
>>>>>>>>>> Which instructions perform this determination?
>>>>>>>>>>
>>>>>>>>>> Why aren't they in the trace?
>>>>>>>>>
>>>>>>>>> Whether or not DD correctly simulated by HH can possibly
>>>>>>>>> reach its own simulated final state has nothing to do with
>>>>>>>>> the other 251 pages of the execution trace of HH.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Some of the instructions in H make H reach its final state and
>>>>>>>> terminate normally.
>>>>>>>
>>>>>>> DD correctly simulated by HH cannot possibly halt because
>>>>>>> DD specifies recursive simulation to HH.
>>>>>>>
>>>>>>> What computer language are you an expert in?
>>>>>>>
>>>>>>
>>>>>> DD directly executed cannot possibly halt because DD specifies
>>>>>> recursive simulation to the CPU.
>>>>>
>>>>>
>>>>> What computer language are you an expert in?
>>>>> What computer language are you an expert in?
>>>>> What computer language are you an expert in?
>>>>> What computer language are you an expert in?
>>>>> My guess is none.
>>>>>
>>>>
>>>> You cannot comment on the point.
>>>
>>> In others words by refusing to answer you implicitly
>>> acknowledge that you not an expert in any computer languages.
>>>
>>>> If DD specifies recursive simulation, then it specifies recursive
>>>> simulation to the CPU as well. Aren't there some instructions in DD
>>>> that tell it when to abort recursive simulation?
>>>
>>> If you know the C programming language then you can answer that
>>> yourself. Do you see any "if" statement before the call to HH(x,x) ???
>>>
>>> int DD(int (*x)())
>>> {
>>>    int Halt_Status = HH(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return Halt_Status;
>>> }
>>>
>> Doesn't HH also have code *inside* it?
>
> There is another 151 pages of the execution trace of
> HH correctly simulating itself simulating DD.

That seems to be where the problem is. HH has instructions which detect
non-halting patterns and make HH halt, but your simulator dishonestly
didn't execute those instructions, so HH didn't halt.