Re: Why do people here insist on denying these verified facts?

On 6/22/24 1:29 PM, olcott wrote:

On 6/22/2024 12:13 PM, Richard Damon wrote:

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

>
void DDD()
{
   HHH0(DDD);
}
>
The input to HHH0(DDD) includes itself.
The input to HHH1(DDD) DOES NOT include itself.
>
It is stipulated that correct emulation is defined by the
semantics of the x86 programming language and nothing else.

>
And thus, your emulation traces show that your "Simulating Halt Deciders" do not do a "Correct Simulation"

 Apparently your ADD preventing you from paying close attention
to ALL of my words.
 *Function names adapted to correspond to my updated paper*
 void DDD()
{
   H0(DDD);
}
 *When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*
 *When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*
 *When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*
 *When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*
 *When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*
 then we see that when DDD is correctly emulated by H0 that
its call to H0(DDD) cannot possibly return.

Since your H0 has never demonstrated that is actually DOES the correct simulation per your stipulation, you have no grounds to make that claim. Maybe you can eventually fix this problem, but until you do, you can't call it a verified claim.
If H0 is assumed to actually do that, then we know that the correct simulation per your stipulation would show the call instruction, and then the instructions of H0, so even though you don't show them below as "part" of the input, they must be considered as part of it by reference (since the "input" to H0 is just an address in memory, and all of the memory is available, the state of all accessed memory is part of the input),
Note, per you stipulation, the ACTUAL behavior of the input, as the actual behavior of a complete correct emulation of the input, will show that DDD calls HHH(DDD) that will try to emulate the input for some time, then give up and return to DDD and halt, thus the correct behavior for a Halting Decider is that the input Halts.
You might be able to prove that there is no possible variant to H0 that could possible emulate its input (when made to refrence THAT NEW varient   of H0) to that final state, which just means that it is impossible for any such decider to prove that this form of input built on its self is halting, But if all of them do abort their emulation and return (so they are a decider) then all those input can be shown to be actually Halting, just unprovable by the decider they are built to fool. That doesn't make them non-haling, just shows that Halting isn't computable by this method.

 _DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]
 When we define H1 as identical to H0 except that DDD does not
call H1 then we see that when DDD is correctly emulated by H1
that its call to H0(DDD) does return. This is the same behavior
as the directly executed DDD().
 

Nope. If we fix your H0 and H1 to actually show the traces simulated, through H0, and actually get H0 to work as described, then we will see the two traces to be IDENTICAL up to the point that H0 decides to stop its simulation and return.
If you disagree, what instruction, correctly emulated by the two of them, creates a differing result to make the traces different, other than H0's trace stops.