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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)