Re: III correctly emulated by EEE ---

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:
>

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

There is also no Infinite_Recursion.
>

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.

>

Please explain what behaviour the description of a TM "specifies",
and which TM the input describes.
>

>
"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

>
And what a UTM does with this input completely specifies its behavior,
>

>

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.

...which is the direct execution. Not much of a coincidence.
>

>
_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
>
When-so-ever any correct emulator EEE correctly emulates
a finite number of steps of an input III that calls this
same emulator to emulate itself the behavior of the direct
execution of III will not be the same as the behavior of
the emulated III.
>

>
Becuase a finite emulation that stop before the end is not a correct emulation

>
In other words you keep dishonestly trying to get away with
disagreeing with the law of identity.
>
When N steps are III are correctly emulated by EEE
then N steps are III are correctly emulated by EEE.

>
Which isn't the same as the CORRECT emulation that shows if the program being emulated will halt/.
>

>
There exists no Natural Number N number of steps of III
correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.
>

>
Because

>
In other words you agree that the recursive emulation
of a single finite string of x86 machine code single
machine address [00002172] cannot possibly reach its
own machine address [00002183]when emulated by emulator
EEE according to the semantics of the x86 language.
>
>

>
But it isn't a single finite string of x86 machince code,

>
As a matter of verified fact it is a single finite
string of machine code at a fixed offset in the
Halt7.obj file.

>
Nope, because DEFINTIONALLY, to correctly emulate it, you need ALL of it (at least all seen by the emulator) and thus you can't change the parts seen and still be talking about the same input.
>
Your claim just shows you are a patholgical liar.
>
You can not "correctly emulate" the code of just the function, you need the rest of the code, which mean you can't do the variations you talk about.
>

>
x86utm operates on a compiled object file that
is stored in a single location of global memory.

>
Right, and thus you must consider *ALL* of that memory as the input, so if you change it, it is a different input.
>

>
You haven't yet noticed that all posts with this title
[III correctly emulated by EEE] are talking about a pure
emulator that emulates a finite number of instructions of III.
>
>

>
Which is just a strawman, and a contradiction, as the definition of "correct emulation" (to be able to use it in the halting problem as a surrogate for the programs behavior) must be complete.
>

 _III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
 You continue to look increasingly foolish when you
try to keep getting away with denying that III
calls EEE(III) in recursive emulation.
 

But I don't deny it, just point out that it is irrelevent, since none of your variations of HHH get that same input, as the input *MUST* include the code of the function that DDD/III calls, and thus they will be different.
Remember, a pure function, which is what a program is, can't access any memory not part of its input. It can only access its own code to execute it.
So sorry that all you are doing is proving the fraud you have been trying to pull over everyone by your lying about what you words actually mean and showing how stupid and ignorant you are.