Sujet : Re: DDD specifies recursive emulation to HHH and halting to HHH1
De : dbush.mobile (at) *nospam* gmail.com (dbush)
Groupes : comp.theoryDate : 31. Mar 2025, 23:17:36
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vsf49v$1adee$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
User-Agent : Mozilla Thunderbird
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote:
On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote:
On 3/29/2025 3:14 PM, dbush wrote:
On 3/29/2025 4:01 PM, olcott wrote:
On 3/29/2025 2:26 PM, dbush wrote:
On 3/29/2025 3:22 PM, olcott wrote:
On 3/29/2025 2:06 PM, dbush wrote:
On 3/29/2025 3:03 PM, olcott wrote:
On 3/29/2025 10:23 AM, dbush wrote:
On 3/29/2025 11:12 AM, olcott wrote:
On 3/28/2025 11:00 PM, dbush wrote:
On 3/28/2025 11:45 PM, olcott wrote:
>
An input that halts when executed directly is not non-
terminating
>
When UTM1 is a UTM that has been adapted to only simulate a
finite number of steps
And is therefore no longer a UTM that does a correct and
complete simulation
>
and input D calls UTM1 then the behavior of D simulated by
UTM1
Is not what I asked about. I asked about the behavior of D
when executed directly.
Off topic for this thread.
Yes, HHH is off the topic of deciding halting.
>
UTM1 D DOES NOT HALT UTM2 D HALTS D is the same finite string
in both cases.
No it isn't, not if it is the definition of a PROGRAM.
>
The behavior that these machine code bytes specify:
558bec6872210000e853f4ffff83c4045dc3 as an input to HHH is
different than these same bytes as input to HHH1 as a verified
fact.
What does "specify to" mean? Which behaviour is correct?
>
DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH ITS
OWN FINAL HALT STATE.
How does HHH emulate the call to HHH instruction
The semantics of the x86 language.
Right, which were defined by INTEL, and requires the data emulated to
be part of the input.
It is part of the input in the sense that HHH must emulate itself
emulating DDD. HHH it the test program thus not the program-under-test.
It is part of the program under test, being called by it. That's what
you call a pathological relationship.
>
HHH is not asking does itself halt?
Yes it is saying "I can't simulate this".
>
It was encoded to always halt for
such inputs. HHH is asking does this input specify that it reaches its
own final halt state?
Which it does (except when simulated by HHH).
>
Is it guessing based on your limited input that doesn't contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking outsde the
input to the function (since you say that above is the full input), or
Are you admitting all of Halt7.c/obj as part of the input, and thus you
hae a FIXED definition of HHH, which thus NEVER does a complete
emulation, and thus you can't say that the call to HHH is a complete
emulation.
>
How we we determine that DDD emulated by HHH cannot possibly reach its
final halt state?
Two recursive emulations provide correct inductive proof.
Nope, because if you admit to the first two lies, your HHH never was a
valid decider,
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with HHH and DDD.
Changing the input is not allowed.
DDD correctly emulated by HHH --- Correct Emulation Defined
Re: DDD correctly emulated by HHH --- Correct Emulation Defined 2