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

On 6/22/24 3:03 PM, olcott wrote:

On 6/22/2024 1:55 PM, Richard Damon wrote:

On 6/22/24 2:49 PM, olcott wrote:

On 6/22/2024 1:43 PM, Richard Damon wrote:

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,

>
Liar
>

>
Then where is it?
>

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.

But that isn't what H0 should be answering about.
Your definition defines the REPESENTATION of the input, to be x86 code.
The PROPERTY being measured is does the behavior reach a final state when the thing being represented is run, or when correctly simulated to the final state.
By these, DDD is a HALTING input.
So, the question of can H0 correctly simulate its input to the final state is just a strawman.

 _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().
 

Right, because H1 continues past the point that H0 gave up.
Thus showing that the "Correct Simulation" (unconditionally, and thus OBJECTIVELY) of the input shows Halting Behavior.
H0 just INCORRECTLY determined that its input is non-halting due to bad logic.
It might be able to say that its input doesn't POOP correctly, but no one but you seems to care about that, and you really need to figure out how to formally define POOP, as I sort of understand what you are trying to say, but it gets sort of messy since it is talking about subjective measures.