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

On 3/30/25 6:17 PM, olcott wrote:

On 3/30/2025 4:59 PM, Mr Flibble wrote:

On Sun, 30 Mar 2025 16:56:37 -0500, olcott wrote:
>

On 3/30/2025 4:05 PM, Richard Damon wrote:

On 3/30/25 4:32 PM, olcott wrote:

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.
>
THAT IS WHAT IT SAYS AND ANYONE THAT DISAGREES IS A DAMNED LIAR OR
STUPID.
>
>

How is that DDD correctly emulated beyond the call HHH instruction by a
program that is a pure function, and thus only looks at its input?
>
>

*THE ENTIRE SCOPE IS*
DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH ITS OWN
FINAL HALT STATE.
>
If HHH determines this entirely from a psychotic break from reality the
above sentence remains immutably true.

>
Will this ever stop?  It is kind of depressing to watch.
>
/Flibble

 I will stop bringing up this point and move
on to the next point when the three years of
consistent stonewalling on this point stops.

The problem is you are admitting that you are using a strawman, so it is YOU that is stonewalling.

 When HHH computes the mapping from its finite string
input to its own reject state it must do this by
applying finite string transformations to this input
to derive its output.

No, it only CAN do that, but to be correct, it needs to compute the needed function, which has no requirement to be based on that sort of criteria.

 Those finite string transformations must be the actual
execution trace of DDD emulated by HHH according to
the semantics of the x86 language.

Nope, nothing in the problem says that.

 DDD emulated by HHH halting is defined by it reaching
its final halt state. Two emulations prove that this
is impossible.
 

Right, but by the direct execution of the program.
Partial Emulation NEVER defines "non-halting". You might be able to use the data collected to show that the complete emulation of this exact input by a real UTM will never reach a final state after an unbound number of steps, by perhaps showing a repeated state, but just not reaching the end isn't enough.
Your problem is you just don't understand the basics of the theory you claim to be making "breakthrough" discoveries in, and your discoveries turn out to be just lies.
Sorry, you are just proving how stupid you are.