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

On 3/31/2025 9:26 PM, dbush wrote:

On 3/31/2025 10:12 PM, olcott wrote:

On 3/31/2025 8:39 PM, dbush wrote:

On 3/31/2025 9:26 PM, olcott wrote:

On 3/31/2025 8:03 PM, dbush wrote:

On 3/31/2025 8:56 PM, olcott wrote:

On 3/31/2025 7:25 PM, dbush wrote:

On 3/31/2025 7:34 PM, olcott wrote:

On 3/31/2025 5:54 PM, dbush wrote:

On 3/31/2025 6:30 PM, olcott wrote:

On 3/31/2025 5:17 PM, dbush wrote:

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.

>
I have already addressed your misconception that the input is changed.
>

>
No, it is YOUR misconception.  The algorithm DDD consists of the function DDD, the function HHH, and everything that HHH calls down to the OS level.
>

>
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level.

>
So you agree that the input to both is the immutable code of the function DDD, the immutable code of the function HHH, and the immutable code of everything that HHH calls down to the OS level.
>

>
It is the input in terms of the behavior of DDD emulated
by HHH, yet only DDD is the program-under-test.

>
False.  The function DDD by itself is not a program.  The function DDD, the function HHH, and everything that HHH calls down the OS level are *all* under test.
>

>
*Simulating termination analyzer Principle*
It is always correct for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
>

>
>
Repeat of previously refuted point:
>
On 3/31/2025 6:17 PM, dbush wrote:
 > On 3/31/2025 6:12 PM, olcott wrote:
 >> 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.
>
>

>
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
>
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
>
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
>

 Which is also a previously refuted point.
 This means you agree that the input to both is the same, i.e. the algorithm DDD, and therefore must be reported the same as per the requirements:
 

HHH must report on the behavior that its input
actually specifies. This seems way too difficult
for people that can only spout off words that
they learned by rote, with no actual understanding
of the underlying principles involved.
Every actual computation can only transform input
finite strings into outputs. HHH does do this.
The "requirements" that you mindlessly spout off
violate this foundational principle of functions
computed by Turing machines.
int sum(int x, int y)
{
   return 5;
}
sum(2,3) does not compute the sum of 2 + 3.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer