Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES

On 6/15/24 7:30 PM, olcott wrote:

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

On 6/13/2024 8:24 PM, Richard Damon wrote:
 > On 6/13/24 11:32 AM, olcott wrote:
 >>
 >> It is contingent upon you to show the exact steps of how H computes
 >> the mapping from the x86 machine language finite string input to
 >> H(D,D) using the finite string transformation rules specified by
 >> the semantics of the x86 programming language that reaches the
 >> behavior of the directly executed D(D)
 >>
 >
 > Why? I don't claim it can.
>
The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.
>
After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

>
Nope, the steps of D correctly simulated by H will EXACTLY match the steps of D directly executed, until H just gives up and guesses.
>

>
When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N
recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

>
Nope. Because an aborted simulation doesn't say anything about Halting,
>

 It is the mathematical induction that says this.
 

WHAT "Mathematical Induction"?
You haven't shown the required pieces for an inductive proof.
I doubt you even know what you need to do, let alone be able to do it.