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

On 4/1/25 7:33 PM, olcott wrote:

On 4/1/2025 5:09 AM, Fred. Zwarts wrote:

Op 01.apr.2025 om 04:19 schreef olcott:

On 3/31/2025 8:27 PM, Richard Damon wrote:

On 3/31/25 8:59 PM, olcott wrote:

On 3/31/2025 7:26 PM, Richard Damon wrote:

On 3/31/25 7:36 PM, olcott wrote:

On 3/31/2025 5:32 PM, Richard Damon wrote:

On 3/31/25 2:16 PM, olcott wrote:

On 3/31/2025 3:24 AM, Fred. Zwarts wrote:

Op 31.mrt.2025 om 05:13 schreef olcott:

On 3/30/2025 9:36 PM, Richard Damon wrote:

On 3/30/25 10:13 PM, olcott wrote:

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:

>
It defines that it must compute the mapping from
the direct execution of a Turing Machine

>
Which does not require tracing an actual running TM, only mapping properties of the TM described.

>
The key fact that you continue to dishonestly ignore
is the concrete counter-example that I provided that
conclusively proves that the finite string of machine
code input is not always a valid proxy for the behavior
of the underlying virtual machine.

>
In other words, you deny the concept of a UTM, which can take a description of any Turing machine and exactly reproduce the behavior of the direct execution.

>
I deny that a pathological relationship between a UTM and
its input can be correctly ignored.
>

>
In such a case, the UTM will not halt, and neither will the input when executed directly.

>
It is not impossible to adapt a UTM such that it
correctly simulates a finite number of steps of an
input.
>

>
1) then you no longer have a UTM, so statements about a UTM don't apply

>
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.

>
An input that halts when executed directly is not non- terminating
>

>

>

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

>
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.
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.
>

>
_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]
>
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.
>

Or, are you admitting you don't understand the meaning of a program?
>

>
It seems that you "just don't believe in" verified facts.
>

That completely depends on who has verified it.

>
No it does not. That is a stupid thing to say.
Every verified fact IS TRUE BY DEFINITION.

>
No, if the verifiers lies, then his "verification" isn't valid.
>

>
That is not the way semantic tautology works.
If the father of lies says that cats are animals
then cats are still animals.
>

Or, do you accept the verification by the election deniers that show that there was the possibility of the fraud,
>

>
There is a possibility that five minutes ago never existed.
Claiming that there was fraud when you know there was no
evidence of fraud might get you eternally incinerated.
>

A guess you have to or you are admitting yourself to be a hypocrite.
>

>

If everyone can see that the way in which Olcott verifies his 'facts' is only a baseless claim, I do not believe in the verification. In particular when he does not fix the errors in the verification that were pointed out to him.

>
My claims are verified as true entirely on the basis
of the  meaning of their words.
>

>
Nope, it is proved incorrect by the ACTUAL meaning of the words you use, but then you LIE to yourself about what those words mean.

>
 >
>
_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 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. HHH is not asking does
itself halt? It was encoded to always halt for such
inputs. HHH is asking does this input specify that it
reaches its own final halt state?

>
So, you admit to your equivocation.
>
DDD is NOT a program, if it doesn't have a DEFINITE HHH as part of it, and thus needs to be part of the input.
>

>
The C function DDD specifies non-halting behavior
to termination analyzer HHH because DDD calls HHH
in recursive emulation.
>

>
But only a finite recursion. DDD calls an HHH that aborts, so there is no infinite recursion.

>
A simulating termination analyzer is always correct to
abort the simulation and reject the input as non-halting
when-so-ever this input would otherwise prevent itself
from halting.
>

>
But the input WILL halt, when it is correctly emulated.
>

>
Where "correct" is defined to disagree with the x86 language.
>
>

>
WHERE?
>
>
HHH1 correctly emualated EVERY instruction it came to, and continued to the end.
>

>
And HHH emulated every instruction is came to including
emulating itself emulating DDD.

>
Then how did it return an answer if it did this and never came to an end?
>

>
*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.
>

But for a DDD that halts,

>
on the basis of dishonestly changing the subject to
a different instance of DDD, then the one proposing
change of subject is committing the straw-man deception.
>
>

 But all identical instances of DDD behave the same,