Re: DDD specifies recursive emulation to HHH and halting to HHH1

On 4/3/2025 1:32 AM, Mikko wrote:

On 2025-04-03 02:08:22 +0000, olcott said:
 

On 4/2/2025 4:09 AM, Mikko wrote:

On 2025-04-01 23:31:23 +0000, olcott said:
 

On 4/1/2025 1:25 AM, Mikko wrote:

On 2025-03-31 18:06:35 +0000, olcott said:
 

On 3/31/2025 3:47 AM, Mikko wrote:

On 2025-03-30 20:32:07 +0000, olcott said:
 

On 3/30/2025 1:52 PM, Richard Damon wrote:

On 3/30/25 2:27 PM, olcott wrote:

On 3/30/2025 3:12 AM, joes wrote:

Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:

On 3/29/2025 3:14 PM, dbush wrote:

On 3/29/2025 4:01 PM, olcott wrote:

 

We can know that when this adapted UTM simulates a finite number of
steps of its input that this finite number of steps were simulated
correctly.

And therefore does not do a correct UTM simulation that matches the
behavior of the direct execution as it is incomplete.

It is dishonest to expect non-terminating inputs to complete.

A complete simulation of a nonterminating input doesn't halt.
 

2) changing the input is not allowed

The input is unchanged. There never was any indication that the input
was in any way changed.

False, if the starting function calls UTM and UTM changes, you're
changing the input.

When UTM1 is a UTM that has been adapted to only simulate a finite
number of steps

So not an UTM.
 

and input D calls UTM1 then the behavior of D simulated
by UTM1 never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call Then D reaches
its final halt state.

Doesn't matter if it calls it, but if the UTM halts.
 

Changing the input is not allowed.

I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.

You changed UTM1, which is part of the input D.
 

 UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
 UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
 

 Only because UTM1 isn't actually a UTM, but a LIE since it only does a partial simulation, not a complete as REQURIED by the definition of a UTM.
 

 _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]
 DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.

 No, it does not. HHH misintepretes, contrary to the semantics of x86,
the specification to mean that.

 It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.

 Irrelevant. You didn't say anything about a correct emulator or emulation.

 Sure all trolls would agree that when-so-ever a statement
is made many dozens of time this proves that this statement
was never said.

 Trolls don't care what was said. But I do. My comment was about your words
I quoted. Your response was not about my or your quoted words. Instead you
talked obout something else as trolls typically do.

 I always reply to the immediate context.
What you said was irrelevant was a key essence
of my reasoning that proves my point.
 When someone totally proves their point a Troll
that is only interested in naysaying would see
that the point is irrefutable so they say some
other nonsense such that the point was irrelevant.

 As can be seen above, you had said said:
 

_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]
 DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.

 That, and especially the last pair of lines, is the immediate context
to my comment:

 THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS
NOT RELEVANT TO A CORRECT DECISION BY A HALT DECIDER?
HHH does correctly compute the mapping from its input
finite string on this basis: