Re: DDD correctly emulated by HHH --- Correct Emulation Defined 2 addendum

On 3/22/25 9:43 AM, olcott wrote:

On 3/21/2025 7:50 PM, Richard Damon wrote:

On 3/21/25 8:02 PM, olcott wrote:

>
DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
>
For every HHH at machine address 000015d2 that emulates
a finite number of steps of DDD according to the
semantics of the x86 programming language no DDD
ever reaches its own "ret" instruction halt state.
>

>
So, you demonstrate your utter stupidity and use of incorrect definitions.
>
For EVERY HHH at machine address 000015d2 that emulates just a finite number of steps and return, then the PROGRAM DDD

 https://en.wikipedia.org/wiki/Straw_man

Which is EXACTLY what you example is, since if FAILS to meet the actual requirement of the problem.

 typedef void (*ptr)();
int HHH(ptr P);
 void DDD()
{
   HHH(DDD);
   return;
}
 int main()
{
   HHH(Infinite_Recursion);
}
 There is no program DDD in the above code.

And thus no PROGRAM to ask about for the halting problem or for HHH to correctly emulate, and thus you just admitted that you are using a strawman.

DDD emulated by HHH according to he semantics of the
x86 language is the topic of discussion.

Which can't be done, as the contents of HHH are not provided.

 Since no Turing machine M can ever compute the mapping
from the behavior of any directly executed TM2 referring
to the behavior of the directly executed DDD has always
been incorrect. Halt Deciders always report on the behavior
that their input finite string specifies.

So, you don't understand what a UTM is, or what a decision problem actually is?
There is nothing in the definition of the decision problem that says the mapping that the decider needs to compute needs to be something that it can see for itself.

 In every case that does not involve pathological self-reference
the behavior that the finite string specifies is coincidentally
the same behavior as the direct execution of the corresponding
machine. The actual measure, however, has always been the
behavior that the finite string input specifies.

There is nothing in the definition that gives an exception for this pathological case. The behavior the finite string specifies, is the behavior that the actual UTM will do when given it.
Your problem is that you create a strawman that the behavior that HHH is supposed to report on is the non-existance correct simulation that it does (non-existant, as it doesn't do a correct simulation) instead of the correct objective definition of the behavior of the actual correct emulation done by the UTM.

 typedef void (*ptr)();
int HHH(ptr P);
 int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 int main()
{
   HHH(DD);
}
 Prior to my work on simulating termination analyzers the
behavior of the counter-example input to the conventional
halting problem proofs was unknown. It was unknown because
it was previously assumed the input DD could actually do
the opposite of whatever value that HHH returned.

No, the behavior was known, but dependent on the HHH that it was built on (and every different HHH creates a DIFFERENT DD, as DD includes the code of that HHH to become a program) DD without the code for HHH is not a program, and can't be talked about here.
If HHH(DD) returns 0, then DD will Halt
If HHH(DD) returns 1, then DD will not Halt
If HHH(DD) never returns, then DD will not Halt
If HHH(DD) aborts and doesn't return to its caller but just halts, then DD will Halt.
In no case did HHH return the correct answer for the problem, but there WAS a correct asnwer, so HHH is just not a correct Halt Decider.
Why CAN'T DD do the opposite of whatever value HHH returned?

 When we define the Olcott emulating termination
analyzer's purpose is to report in the behavior that
its x86 machine language input specifies according to
the semantics of the x86 language (thus defining what
a correct emulation is) then we see that DD cannot
possibly reach past its own first instruction in any
finite number of steps of correct emulation.
 

And thus you are admitting to working on a STRAWMAN, as your definition fails to match the problem.
Note, the x86 machine language definition still matches the UTM definition (as the x86 language defines a full and complete emulation), it is just that you don't properly do it or apply the definition.
Sorry, but you are just proving your stupidity and ignorance of what you are talking about and admitting that all your work is just a fraud, becuase you admit to using strawmen.