Re: III correctly emulated by EEE ---

Am Mon, 24 Mar 2025 21:13:51 -0500 schrieb olcott:

On 3/24/2025 8:28 PM, Richard Damon wrote:

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.
>

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.

But there is an N after which III returns.
 

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.

Then it is not pure.
 

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.
>

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,

>
It proves that the input DDD to HHH DOES NOT HALT.
How the f-ck is that irrelevant?

DDD, the input, halts.