Re: III correctly emulated by EEE ---

On 3/25/25 6:57 PM, olcott wrote:

On 3/25/2025 4:32 PM, joes wrote:

Am Tue, 25 Mar 2025 07:00:57 -0500 schrieb olcott:

On 3/25/2025 3:37 AM, joes wrote:

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:

>

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.

>

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.

>
>

DDD, the input, halts.

The DDD that halts IS NOT AN ACTUAL INPUT TO HHH.

 

Then what is? Another program with the same name that doesn't?
>

 An entirely different instance that has different behavior.

YOu mean it has a different set of instructions?

 It is easier to see this as DDD emulated by HHH where DDD
defines a pathological relationship with HHH versus DDD
emulated by HHH1 where there is no such pathological relationship.
 DDD/HHH  Cannot possibly reach its final halt state.

So HHH just gives up before reaching the end, but doesn't show that a FULL emulation of that input won't reach there.

DDD/HHH1 Reaches its final halt state.
 

Because HHH1 didn't give up.
HHH giving up doesn't prove that the correct emulation of its input doesn't reach a halting state, just that HHH didn't emulate long enough.
HHH can't emulate longer, as it would no longer BE that HHH, but some other program, and would have to be at some other address, or you have changed the program DDD as it is already using that memory and fixed its values.
Of course, if you say those locations aren't part of the input representing DDD becuase they are a part of DDD, then DDD CAN'T be correctly emulated, as it is no longer actually a program with behavior, as a program can't use code that isn't part of itself.
Sorry, you are just proving that your logic is based on lies and fraud.