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:That completely depends on who has verified it.
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:And therefore does not do a correct UTM simulation >>>>>>>>>>>>>>>>>> that matches the behavior of the direct execution as >>>>>>>>>>>>>>>>>> it is incomplete.
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 is not impossible to adapt a UTM such that it >>>>>>>>>>>>>>>>>>>>> correctly simulates a finite number of steps of an >>>>>>>>>>>>>>>>>>>>> input.
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.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. >>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>
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.
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:That completely depends on who has verified it.
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:And therefore does not do a correct UTM simulation >>>>>>>>>>>>>>>>>>>> that matches the behavior of the direct execution as >>>>>>>>>>>>>>>>>>>> it is incomplete.
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 is not impossible to adapt a UTM such that it >>>>>>>>>>>>>>>>>>>>>>> correctly simulates a finite number of steps of an >>>>>>>>>>>>>>>>>>>>>>> input.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.It defines that it must compute the mapping >>>>>>>>>>>>>>>>>>>>>>>>>>>>> fromWhich does not require tracing an actual >>>>>>>>>>>>>>>>>>>>>>>>>>>> running TM, only mapping properties of the >>>>>>>>>>>>>>>>>>>>>>>>>>>> TM described.
the direct execution of a Turing Machine >>>>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>
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.
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:No it does not. That is a stupid thing to say.
On 3/29/2025 8:12 PM, Richard Damon wrote:That completely depends on who has verified it. >>>>>>>>>>>>>>>
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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
And therefore does not do a correct UTM simulation >>>>>>>>>>>>>>>>>>>>>> that matches the behavior of the direct execution >>>>>>>>>>>>>>>>>>>>>> as it is incomplete.It is not impossible to adapt a UTM such that it >>>>>>>>>>>>>>>>>>>>>>>>> correctly simulates a finite number of steps of an >>>>>>>>>>>>>>>>>>>>>>>>> input.I deny that a pathological relationship >>>>>>>>>>>>>>>>>>>>>>>>>>> between a UTM andIn 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>It defines that it must compute the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mapping fromWhich does not require tracing an actual >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running TM, only mapping properties of the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM described.
the direct execution of a Turing Machine >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
its input can be correctly ignored. >>>>>>>>>>>>>>>>>>>>>>>>>>>
In such a case, the UTM will not halt, and >>>>>>>>>>>>>>>>>>>>>>>>>> neither will the input when executed directly. >>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>
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.
HHH1 can't possibly emulate itself emulating DDD because
DDD does not call HHH1 in recursive emulation.
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:No it does not. That is a stupid thing to say. >>>>>>>>>>>>>>>>> Every verified fact IS TRUE BY DEFINITION.
On 3/29/2025 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/29/25 6:44 PM, olcott wrote:That completely depends on who has verified it. >>>>>>>>>>>>>>>>>
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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
And therefore does not do a correct UTM >>>>>>>>>>>>>>>>>>>>>>>> simulation that matches the behavior of the >>>>>>>>>>>>>>>>>>>>>>>> direct execution as it is incomplete. >>>>>>>>>>>>>>>>>>>>>>>>We can know that when this adapted UTM simulates a >>>>>>>>>>>>>>>>>>>>>>>>> finite number of steps of its input that this >>>>>>>>>>>>>>>>>>>>>>>>> finiteIt is not impossible to adapt a UTM such that it >>>>>>>>>>>>>>>>>>>>>>>>>>> correctly simulates a finite number of steps >>>>>>>>>>>>>>>>>>>>>>>>>>> of anI deny that a pathological relationship >>>>>>>>>>>>>>>>>>>>>>>>>>>>> between a UTM andIn 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>The key fact that you continue to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dishonestly ignore >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is the concrete counter-example that I >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provided thatIt 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
conclusively proves that the finite >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> string of machine >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> code input is not always a valid proxy >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the behavior >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the underlying virtual machine. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
its input can be correctly ignored. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
In such a case, the UTM will not halt, and >>>>>>>>>>>>>>>>>>>>>>>>>>>> neither will the input when executed directly. >>>>>>>>>>>>>>>>>>>>>>>>>>>
input.
1) then you no longer have a UTM, so >>>>>>>>>>>>>>>>>>>>>>>>>> statements about a UTM don't apply >>>>>>>>>>>>>>>>>>>>>>>>>
number of steps were simulated correctly. >>>>>>>>>>>>>>>>>>>>>>>>
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.
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.
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:No it does not. That is a stupid thing to say. >>>>>>>>>>>>>>>>> Every verified fact IS TRUE BY DEFINITION.
On 3/29/2025 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/29/25 6:44 PM, olcott wrote:That completely depends on who has verified it. >>>>>>>>>>>>>>>>>
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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
And therefore does not do a correct UTM >>>>>>>>>>>>>>>>>>>>>>>> simulation that matches the behavior of the >>>>>>>>>>>>>>>>>>>>>>>> direct execution as it is incomplete. >>>>>>>>>>>>>>>>>>>>>>>>We can know that when this adapted UTM simulates a >>>>>>>>>>>>>>>>>>>>>>>>> finite number of steps of its input that this >>>>>>>>>>>>>>>>>>>>>>>>> finiteIt is not impossible to adapt a UTM such that it >>>>>>>>>>>>>>>>>>>>>>>>>>> correctly simulates a finite number of steps >>>>>>>>>>>>>>>>>>>>>>>>>>> of anI deny that a pathological relationship >>>>>>>>>>>>>>>>>>>>>>>>>>>>> between a UTM andIn 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>The key fact that you continue to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dishonestly ignore >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is the concrete counter-example that I >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provided thatIt 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
conclusively proves that the finite >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> string of machine >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> code input is not always a valid proxy >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the behavior >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the underlying virtual machine. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
its input can be correctly ignored. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
In such a case, the UTM will not halt, and >>>>>>>>>>>>>>>>>>>>>>>>>>>> neither will the input when executed directly. >>>>>>>>>>>>>>>>>>>>>>>>>>>
input.
1) then you no longer have a UTM, so >>>>>>>>>>>>>>>>>>>>>>>>>> statements about a UTM don't apply >>>>>>>>>>>>>>>>>>>>>>>>>
number of steps were simulated correctly. >>>>>>>>>>>>>>>>>>>>>>>>
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.
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.
The only rebuttal to this is rejecting the notion
that deciders must always halt.
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
*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 DDD doesn't prevent its own terminatation, as it calls an HHH that
WILL abort its emulation and return and answer.
You know that DDD stopping running and DDD reaching its
final halt state are not the same thing you damned liar.
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:But for a DDD that halts,
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:The semantics of the x86 language.
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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>No, if the verifiers lies, then his "verification" >>>>>>>>>>>>>>>>>> isn't valid.
No it does not. That is a stupid thing to say. >>>>>>>>>>>>>>>>>>> Every verified fact IS TRUE BY DEFINITION. >>>>>>>>>>>>>>>>>>That completely depends on who has verified it. >>>>>>>>>>>>>>>>>>>And therefore does not do a correct UTM >>>>>>>>>>>>>>>>>>>>>>>>>> simulation that matches the behavior of the >>>>>>>>>>>>>>>>>>>>>>>>>> direct execution as it is incomplete. >>>>>>>>>>>>>>>>>>>>>>>>>>We can know that when this adapted UTM >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates aI deny that a pathological relationship >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> between a UTM and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its input can be correctly ignored. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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 >>>>>>>>>>>>>>>>>>>>>>>>>>>
finite number of steps of its input that this >>>>>>>>>>>>>>>>>>>>>>>>>>> finite
number of steps were simulated correctly. >>>>>>>>>>>>>>>>>>>>>>>>>>
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 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 >>>>>>>>>>>>>>>
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.
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.
On 4/1/2025 5:09 AM, Fred. Zwarts wrote:o, why do you change the subject to a non-halting DDD, when it has been
Op 01.apr.2025 om 04:19 schreef olcott:
On 3/31/2025 8:27 PM, Richard Damon wrote:But for a DDD that halts,
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:The semantics of the x86 language.
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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>No, if the verifiers lies, then his "verification" >>>>>>>>>>>>>>>>>> isn't valid.
No it does not. That is a stupid thing to say. >>>>>>>>>>>>>>>>>>> Every verified fact IS TRUE BY DEFINITION. >>>>>>>>>>>>>>>>>>That completely depends on who has verified it. >>>>>>>>>>>>>>>>>>>And therefore does not do a correct UTM >>>>>>>>>>>>>>>>>>>>>>>>>> simulation that matches the behavior of the >>>>>>>>>>>>>>>>>>>>>>>>>> direct execution as it is incomplete. >>>>>>>>>>>>>>>>>>>>>>>>>>We can know that when this adapted UTM >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates aI deny that a pathological relationship >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> between a UTM and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its input can be correctly ignored. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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 >>>>>>>>>>>>>>>>>>>>>>>>>>>
finite number of steps of its input that this >>>>>>>>>>>>>>>>>>>>>>>>>>> finite
number of steps were simulated correctly. >>>>>>>>>>>>>>>>>>>>>>>>>>
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 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 >>>>>>>>>>>>>>>
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.
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.
On 4/1/2025 8:13 PM, Richard Damon wrote:
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
*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 DDD doesn't prevent its own terminatation, as it calls an HHH
that WILL abort its emulation and return and answer.
You know that DDD stopping running and DDD reaching its
final halt state are not the same thing you damned liar.
Right, the DDD who's simulation is stopped hasn't shown non-halting
behavior, just not-yet-halted.
You already admitted that you are lying about this.
DDD emulated by HHH for an infinite number of steps
never reaches its final halt state.
HHH sees this in one recursive emulation of DDD.
*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. The only rebuttal to this is rejecting the notion that
deciders must always halt.
On 4/1/2025 8:10 PM, Richard Damon wrote:
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:But for a DDD that halts,
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:The semantics of the x86 language.
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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>No, if the verifiers lies, then his "verification" >>>>>>>>>>>>>>>>>>>> isn't valid.
No it does not. That is a stupid thing to say. >>>>>>>>>>>>>>>>>>>>> Every verified fact IS TRUE BY DEFINITION. >>>>>>>>>>>>>>>>>>>>That completely depends on who has verified it. >>>>>>>>>>>>>>>>>>>>>And therefore does not do a correct UTM >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation that matches the behavior of the >>>>>>>>>>>>>>>>>>>>>>>>>>>> direct execution as it is incomplete. >>>>>>>>>>>>>>>>>>>>>>>>>>>>We can know that when this adapted UTM >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates aIn 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.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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
finite number of steps of its input that >>>>>>>>>>>>>>>>>>>>>>>>>>>>> this finite
number of steps were simulated correctly. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
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 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 >>>>>>>>>>>>>>>>>
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.
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,
The execution context differs dipshit.
DDD DOES NOT F-CKING CALL HHH1 IN RECURSIVE EMULATION.
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non-haltingBut DDD doesn't prevent its own terminatation, as it calls an HHHYou know that DDD stopping running and DDD reaching its final halt
that WILL abort its emulation and return and answer.
state are not the same thing you damned liar.
behavior, just not-yet-halted.
DDD emulated by HHH for an infinite number of steps never reaches its
final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion that
deciders must always halt.
On 4/1/2025 8:10 PM, Richard Damon wrote:Then why does it think DDD, which only calls HHH, doesn't halt?
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:
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.The semantics of the x86 language.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 >>>>>>>>>>>>>>>>>
Right, which were defined by INTEL, and requires the data >>>>>>>>>>>>>>>> emulated to be part of the input.
No, your HHH is asking whether it can simulate the input.HHH is asking
does this input specify that it reaches its own final halt >>>>>>>>>>>>>>> state?
DDD doesn't specify anything "to" HHH.So, you admit to your equivocation.The C function DDD specifies non-halting behavior to >>>>>>>>>>>>> termination analyzer HHH because DDD calls HHH in recursive >>>>>>>>>>>>> emulation.
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. >>>>>>>>>>>>>>
That's a tautology, as is that it didn't simulate those it didn't come to.And HHH emulated every instruction is came to including emulating >>>>>>> itself emulating DDD.WHERE?Where "correct" is defined to disagree with the x86 language. >>>>>>>>>But the input WILL halt, when it is correctly emulated.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.
HHH1 correctly emualated EVERY instruction it came to, and
continued to the end.
Then it's not a pure function.But all identical instances of DDD behave the same,But for a DDD that halts,Then how did it return an answer if it did this and never came to*Simulating termination analyzer Principle*
an end?
It is always correct for any simulating termination analyzer to stop >>>>> simulating and reject any input that would otherwise prevent its own >>>>> termination.
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.
The execution context differs dipshit.
DDD DOES NOT F-CKING CALL HHH1 IN RECURSIVE EMULATION.No, it calls HHH whether executed directly or simulated by whatever.
On 3/31/2025 5:32 PM, Richard Damon wrote:How is DDD incorrectly simulated to halt?
On 3/31/25 2:16 PM, olcott wrote:Where "correct" is defined to disagree with the x86 language.
A simulating termination analyzer is always correct to abort theBut the input WILL halt, when it is correctly emulated.
simulation and reject the input as non-halting when-so-ever this input
would otherwise prevent itself from halting.
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're
Op 31.mrt.2025 om 20:16 schreef olcott:
A simulating termination analyzer is always correct to abort theBut the input is halting, as proven by direct execution.
simulation and reject the input as non-halting when-so-ever this input
would otherwise prevent itself from halting.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
On 4/2/2025 9:14 AM, joes wrote:Yes it fails to reach the end of the simulation of a program that
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're
Op 31.mrt.2025 om 20:16 schreef olcott:
A simulating termination analyzer is always correct to abort theBut the input is halting, as proven by direct execution.
simulation and reject the input as non-halting when-so-ever this input >>>>> would otherwise prevent itself from halting.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
doing HHH(HHH(DDD))? What is the difference in what is passed to HHH1?
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
On 4/2/2025 9:14 AM, joes wrote:
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're
Op 31.mrt.2025 om 20:16 schreef olcott:
A simulating termination analyzer is always correct to abort theBut the input is halting, as proven by direct execution.
simulation and reject the input as non-halting when-so-ever this input >>>>> would otherwise prevent itself from halting.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
doing HHH(HHH(DDD))? What is the difference in what is passed to HHH1?
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
Maybe the whole problem is that everyone here
including Mike never had an actual clue about
the x86 language.
On 4/2/2025 1:47 PM, Fred. Zwarts wrote:
Op 02.apr.2025 om 17:55 schreef olcott:
On 4/2/2025 9:14 AM, joes wrote:
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're
Op 31.mrt.2025 om 20:16 schreef olcott:
A simulating termination analyzer is always correct to abort the >>>>>>> simulation and reject the input as non-halting when-so-ever this >>>>>>> inputBut the input is halting, as proven by direct execution.
would otherwise prevent itself from halting.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
doing HHH(HHH(DDD))? What is the difference in what is passed to HHH1? >>>>
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
Yes it fails to reach the end of the simulation of a program that
according to the x86 semantics has an end as proven by direct execution.
In other words you don't hardly know the x86
language at all.
On 4/2/2025 9:00 AM, joes wrote:
Am Tue, 01 Apr 2025 21:33:30 -0500 schrieb olcott:
On 4/1/2025 8:10 PM, Richard Damon wrote:Then it's not a pure function.
On 4/1/25 7:33 PM, olcott wrote:
But all identical instances of DDD behave the same,
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.
The execution context differs dipshit.
DDD is not required to be a pure function.
DDD is allowed to be a simple infinite loop.
DDD DOES NOT F-CKING CALL HHH1 IN RECURSIVE EMULATION.No, it calls HHH whether executed directly or simulated by whatever.
On 4/2/2025 4:18 PM, dbush wrote:
On 4/2/2025 11:55 AM, olcott wrote:
On 4/2/2025 9:14 AM, joes wrote:
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're
Op 31.mrt.2025 om 20:16 schreef olcott:
A simulating termination analyzer is always correct to abort the >>>>>>> simulation and reject the input as non-halting when-so-ever this >>>>>>> inputBut the input is halting, as proven by direct execution.
would otherwise prevent itself from halting.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
doing HHH(HHH(DDD))? What is the difference in what is passed to HHH1? >>>>
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
Category error. The algorithm DDD and the algorithm HHH are fixed and
immutable, so to say that "this DDD cannot possibly reach its own
final state" implies that HHH varies but it does not.
The only valid statements would be that either HHH *does* emulate DDD
to a final state, or HHH *does not* emulate DDD to a final state.
So which is it?
DDD emulated by HHH specifies recursive emulation.
DDD emulated by HHH1 DOES NOT specify recursive emulation.
*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. The only rebuttal to this is rejecting the notion that
deciders must always halt.
On 4/2/2025 8:52 AM, joes wrote:
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non-haltingBut DDD doesn't prevent its own terminatation, as it calls an HHHYou know that DDD stopping running and DDD reaching its final halt
that WILL abort its emulation and return and answer.
state are not the same thing you damned liar.
behavior, just not-yet-halted.
DDD emulated by HHH for an infinite number of steps never reaches its
final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion that
deciders must always halt.
By process of elimination and by the above criteria
we can determine that not stopping the emulation
causes HHH to never halt. This only leaves stopping
the emulation that semantically entails that the
input must be rejected.
On 4/2/2025 6:16 AM, Richard Damon wrote:
On 4/1/25 10:37 PM, olcott wrote:
On 4/1/2025 8:13 PM, Richard Damon wrote:
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
*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 DDD doesn't prevent its own terminatation, as it calls an HHH
that WILL abort its emulation and return and answer.
You know that DDD stopping running and DDD reaching its
final halt state are not the same thing you damned liar.
Right, the DDD who's simulation is stopped hasn't shown non-halting
behavior, just not-yet-halted.
You already admitted that you are lying about this.
DDD emulated by HHH for an infinite number of steps
never reaches its final halt state.
But that isn't something that happens with THIS HHH, since it doesn't
do that.
When DDD emulated by HHH for an infinite number of steps
never halts then as soon as HHH correctly infers this it
has its basis to reject DDD.
https://en.wikipedia.org/wiki/Mathematical_induction
DDD emulated by HHH does not reach its final halt state
with a single emulation of DDD by HHH.
DDD emulated by HHH does not reach its final halt state
with N recursive emulations of HHH emulating itself emulating DDD.
Therefore
DDD emulated by HHH does not reach its final halt state
and can be rejected as non-halting.
On 4/2/2025 9:06 AM, joes wrote:
Am Mon, 31 Mar 2025 18:36:30 -0500 schrieb olcott:
On 3/31/2025 5:32 PM, Richard Damon wrote:How is DDD incorrectly simulated to halt?
On 3/31/25 2:16 PM, olcott wrote:Where "correct" is defined to disagree with the x86 language.
A simulating termination analyzer is always correct to abort theBut the input WILL halt, when it is correctly emulated.
simulation and reject the input as non-halting when-so-ever this input >>>>> would otherwise prevent itself from halting.
You have never shown that you understand recursion
much less recursive emulation.
On 4/2/2025 1:47 PM, Fred. Zwarts wrote:
Op 02.apr.2025 om 17:55 schreef olcott:
On 4/2/2025 9:14 AM, joes wrote:
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're
Op 31.mrt.2025 om 20:16 schreef olcott:
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 is halting, as proven by direct execution.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
doing HHH(HHH(DDD))? What is the difference in what is passed to HHH1? >>>>
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
Yes it fails to reach the end of the simulation of a program that
according to the x86 semantics has an end as proven by direct execution.
In other words you don't hardly know the x86
language at all.
On 4/2/2025 4:18 PM, dbush wrote:
On 4/2/2025 11:55 AM, olcott wrote:
On 4/2/2025 9:14 AM, joes wrote:
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're
Op 31.mrt.2025 om 20:16 schreef olcott:
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 is halting, as proven by direct execution.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
doing HHH(HHH(DDD))? What is the difference in what is passed to HHH1? >>>>
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
Category error. The algorithm DDD and the algorithm HHH are fixed and
immutable, so to say that "this DDD cannot possibly reach its own final
state" implies that HHH varies but it does not.
The only valid statements would be that either HHH *does* emulate DDD
to a final state, or HHH *does not* emulate DDD to a final state.
So which is it?
DDD emulated by HHH specifies recursive emulation.
DDD emulated by HHH1 DOES NOT specify recursive emulation.
*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. The only rebuttal to this is rejecting the notion that
deciders must always halt.
On 4/2/2025 9:00 AM, joes wrote:
Am Tue, 01 Apr 2025 21:33:30 -0500 schrieb olcott:
On 4/1/2025 8:10 PM, Richard Damon wrote:Then it's not a pure function.
On 4/1/25 7:33 PM, olcott wrote:
But all identical instances of DDD behave the same,
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.
The execution context differs dipshit.
DDD is not required to be a pure function.
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
*finiteYou already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non-haltingBut DDD doesn't prevent its own terminatation, as it calls an HHHYou know that DDD stopping running and DDD reaching its final halt
that WILL abort its emulation and return and answer.
state are not the same thing you damned liar.
behavior, just not-yet-halted.
DDD emulated by HHH for an infinite number of steps never reaches its
final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion that
deciders must always halt.
On 4/2/2025 8:52 AM, joes wrote:
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non-haltingBut DDD doesn't prevent its own terminatation, as it calls an HHHYou know that DDD stopping running and DDD reaching its final halt
that WILL abort its emulation and return and answer.
state are not the same thing you damned liar.
behavior, just not-yet-halted.
DDD emulated by HHH for an infinite number of steps never reaches its
final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion that
deciders must always halt.
By process of elimination and by the above criteria
we can determine that not stopping the emulation
causes HHH to never halt. This only leaves stopping
the emulation that semantically entails that the
input must be rejected.
On 4/2/2025 4:18 PM, dbush wrote:
On 4/2/2025 11:55 AM, olcott wrote:
On 4/2/2025 9:14 AM, joes wrote:
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're
Op 31.mrt.2025 om 20:16 schreef olcott:
A simulating termination analyzer is always correct to abort the >>>>>>> simulation and reject the input as non-halting when-so-ever this >>>>>>> inputBut the input is halting, as proven by direct execution.
would otherwise prevent itself from halting.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
doing HHH(HHH(DDD))? What is the difference in what is passed to HHH1? >>>>
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
Category error. The algorithm DDD and the algorithm HHH are fixed and
immutable, so to say that "this DDD cannot possibly reach its own
final state" implies that HHH varies but it does not.
The only valid statements would be that either HHH *does* emulate DDD
to a final state, or HHH *does not* emulate DDD to a final state.
So which is it?
DDD emulated by HHH specifies recursive emulation.
DDD emulated by HHH1 DOES NOT specify recursive emulation.
On 4/2/2025 6:16 AM, Richard Damon wrote:
On 4/1/25 10:37 PM, olcott wrote:
On 4/1/2025 8:13 PM, Richard Damon wrote:
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
*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 DDD doesn't prevent its own terminatation, as it calls an HHH
that WILL abort its emulation and return and answer.
You know that DDD stopping running and DDD reaching its
final halt state are not the same thing you damned liar.
Right, the DDD who's simulation is stopped hasn't shown non-halting
behavior, just not-yet-halted.
You already admitted that you are lying about this.
DDD emulated by HHH for an infinite number of steps
never reaches its final halt state.
But that isn't something that happens with THIS HHH, since it doesn't
do that.
When DDD emulated by HHH for an infinite number of steps
never halts then as soon as HHH correctly infers this it
has its basis to reject DDD.
On 4/2/2025 1:47 PM, Fred. Zwarts wrote:
Op 02.apr.2025 om 17:55 schreef olcott:
On 4/2/2025 9:14 AM, joes wrote:
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're
Op 31.mrt.2025 om 20:16 schreef olcott:
A simulating termination analyzer is always correct to abort the >>>>>>> simulation and reject the input as non-halting when-so-ever this >>>>>>> inputBut the input is halting, as proven by direct execution.
would otherwise prevent itself from halting.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
doing HHH(HHH(DDD))? What is the difference in what is passed to HHH1? >>>>
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
Yes it fails to reach the end of the simulation of a program that
according to the x86 semantics has an end as proven by direct execution.
In other words you don't hardly know the x86
language at all.
On 4/2/2025 8:52 AM, joes wrote:If it didn't abort, it would reach the return at infinity.
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non-haltingBut DDD doesn't prevent its own terminatation, as it calls an HHHYou know that DDD stopping running and DDD reaching its final halt
that WILL abort its emulation and return and answer.
state are not the same thing you damned liar.
behavior, just not-yet-halted.
DDD emulated by HHH for an infinite number of steps never reaches its
final halt state.
How does the inability to simulate entail nontermination?By process of elimination and by the above criteria we can determineHHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion that
deciders must always halt.
that not stopping the emulation causes HHH to never halt. This only
leaves stopping the emulation that semantically entails that the input
must be rejected.
On 4/2/2025 9:00 AM, joes wrote:Yes it is required to have no side effects, no static variables etc.
Am Tue, 01 Apr 2025 21:33:30 -0500 schrieb olcott:DDD is not required to be a pure function. DDD is allowed to be a simple infinite loop.
On 4/1/2025 8:10 PM, Richard Damon wrote:Then it's not a pure function.
On 4/1/25 7:33 PM, olcott wrote:The execution context differs dipshit.
But all identical instances of DDD behave the same,
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.
On 4/2/2025 9:35 PM, Richard Damon wrote:
On 4/2/25 10:15 PM, olcott wrote:
On 4/2/2025 8:52 AM, joes wrote:
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non-halting >>>>>> behavior, just not-yet-halted.But DDD doesn't prevent its own terminatation, as it calls an HHH >>>>>>>> that WILL abort its emulation and return and answer.You know that DDD stopping running and DDD reaching its final halt >>>>>>> state are not the same thing you damned liar.
DDD emulated by HHH for an infinite number of steps never reaches its >>>>> final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion that
deciders must always halt.
By process of elimination and by the above criteria
we can determine that not stopping the emulation
causes HHH to never halt. This only leaves stopping
the emulation that semantically entails that the
input must be rejected.
No, because HHH must do what HHH does.
So I am tong because you claim that HHH
does not do what it does?
On 4/3/2025 5:46 PM, Richard Damon wrote:
On 4/3/25 6:37 PM, olcott wrote:
On 4/2/2025 9:35 PM, Richard Damon wrote:
On 4/2/25 10:15 PM, olcott wrote:
On 4/2/2025 8:52 AM, joes wrote:
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non-halting >>>>>>>> behavior, just not-yet-halted.But DDD doesn't prevent its own terminatation, as it calls an HHH >>>>>>>>>> that WILL abort its emulation and return and answer.You know that DDD stopping running and DDD reaching its final halt >>>>>>>>> state are not the same thing you damned liar.
DDD emulated by HHH for an infinite number of steps never reaches >>>>>>> its
final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion that >>>>>>> deciders must always halt.
By process of elimination and by the above criteria
we can determine that not stopping the emulation
causes HHH to never halt. This only leaves stopping
the emulation that semantically entails that the
input must be rejected.
No, because HHH must do what HHH does.
So I am tong because you claim that HHH
does not do what it does?
The problem is that your logic claims that HHH doesn't do what it
does, which is just emulate its inputpartially and them return.
void DDD()
{
HHH(DDD);
return;
}
Do you really think that anyone knowing the C
programming language is too stupid to see that
DDD simulated by HHH cannot possibly return?
On 4/3/2025 3:53 AM, Fred. Zwarts wrote:
Op 03.apr.2025 om 03:19 schreef olcott:
On 4/2/2025 1:47 PM, Fred. Zwarts wrote:
Op 02.apr.2025 om 17:55 schreef olcott:
On 4/2/2025 9:14 AM, joes wrote:
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're >>>>>> doing HHH(HHH(DDD))? What is the difference in what is passed to
Op 31.mrt.2025 om 20:16 schreef olcott:
A simulating termination analyzer is always correct to abort the >>>>>>>>> simulation and reject the input as non-halting when-so-everBut the input is halting, as proven by direct execution.
this input
would otherwise prevent itself from halting.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
HHH1?
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
Yes it fails to reach the end of the simulation of a program that
according to the x86 semantics has an end as proven by direct
execution.
In other words you don't hardly know the x86
language at all.
I see, you have your own definitions for the x86 language.
Any idiot can be a mindless naysayer.
On 4/3/2025 3:53 AM, Fred. Zwarts wrote:
Op 03.apr.2025 om 03:19 schreef olcott:
On 4/2/2025 1:47 PM, Fred. Zwarts wrote:
Op 02.apr.2025 om 17:55 schreef olcott:In other words you don't hardly know the x86
On 4/2/2025 9:14 AM, joes wrote:
Am Mon, 31 Mar 2025 16:26:58 -0500 schrieb olcott:
On 3/31/2025 2:10 PM, Fred. Zwarts wrote:Why are you not passing DDD as input? Why do you not call what you're >>>>>> doing HHH(HHH(DDD))? What is the difference in what is passed to HHH1? >>>>>>
Op 31.mrt.2025 om 20:16 schreef olcott:
A simulating termination analyzer is always correct to abort the >>>>>>>>> simulation and reject the input as non-halting when-so-ever this inputBut the input is halting, as proven by direct execution.
would otherwise prevent itself from halting.
Something other than the input is halting.
HHH1(DDD) shows the same behavior as the direct execution.
HHH(DDD) shows the behavior of the actual input.
This seems to be above your level of technical competence.
_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]
Anyone understanding the above code where HHH
emulates DDD according to the semantics of the
x86 language knows that this DDD (not some
other different DDD) cannot possibly reach its
own final halt state.
Yes it fails to reach the end of the simulation of a program that
according to the x86 semantics has an end as proven by direct execution. >>>
language at all.
I see, you have your own definitions for the x86 language.
Any idiot can be a mindless naysayer.
On 4/3/2025 5:46 PM, Richard Damon wrote:
On 4/3/25 6:37 PM, olcott wrote:
On 4/2/2025 9:35 PM, Richard Damon wrote:
On 4/2/25 10:15 PM, olcott wrote:
On 4/2/2025 8:52 AM, joes wrote:
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non-halting >>>>>>>> behavior, just not-yet-halted.But DDD doesn't prevent its own terminatation, as it calls an HHH >>>>>>>>>> that WILL abort its emulation and return and answer.You know that DDD stopping running and DDD reaching its final halt >>>>>>>>> state are not the same thing you damned liar.
DDD emulated by HHH for an infinite number of steps never reaches its >>>>>>> final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion that >>>>>>> deciders must always halt.
By process of elimination and by the above criteria
we can determine that not stopping the emulation
causes HHH to never halt. This only leaves stopping
the emulation that semantically entails that the
input must be rejected.
No, because HHH must do what HHH does.
So I am tong because you claim that HHH
does not do what it does?
The problem is that your logic claims that HHH doesn't do what it does,
which is just emulate its inputpartially and them return.
void DDD()
{
HHH(DDD);
return;
}
Do you really think that anyone knowing the C
programming language is too stupid to see that
DDD simulated by HHH cannot possibly return?
On 4/3/2025 6:44 PM, Richard Damon wrote:
On 4/3/25 6:52 PM, olcott wrote:
On 4/3/2025 5:46 PM, Richard Damon wrote:
On 4/3/25 6:37 PM, olcott wrote:
On 4/2/2025 9:35 PM, Richard Damon wrote:
On 4/2/25 10:15 PM, olcott wrote:
On 4/2/2025 8:52 AM, joes wrote:
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non- >>>>>>>>>> haltingBut DDD doesn't prevent its own terminatation, as it calls >>>>>>>>>>>> an HHHYou know that DDD stopping running and DDD reaching its final >>>>>>>>>>> halt
that WILL abort its emulation and return and answer.
state are not the same thing you damned liar.
behavior, just not-yet-halted.
DDD emulated by HHH for an infinite number of steps never
reaches its
final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion >>>>>>>>> that
deciders must always halt.
By process of elimination and by the above criteria
we can determine that not stopping the emulation
causes HHH to never halt. This only leaves stopping
the emulation that semantically entails that the
input must be rejected.
No, because HHH must do what HHH does.
So I am tong because you claim that HHH
does not do what it does?
The problem is that your logic claims that HHH doesn't do what it
does, which is just emulate its inputpartially and them return.
void DDD()
{
HHH(DDD);
return;
}
Do you really think that anyone knowing the C
programming language is too stupid to see that
DDD simulated by HHH cannot possibly return?
WHich is irrelevent, as HHH to be a decider must abort and return some
answer, and thus DDD is halting.
We already know that you are not too stupid to
confuse an aborted simulation with reaching a
final state any halting. Why pretend otherwise?
On 4/4/2025 2:52 AM, Mikko wrote:
On 2025-04-03 22:52:07 +0000, olcott said:
On 4/3/2025 5:46 PM, Richard Damon wrote:
On 4/3/25 6:37 PM, olcott wrote:
On 4/2/2025 9:35 PM, Richard Damon wrote:
On 4/2/25 10:15 PM, olcott wrote:
On 4/2/2025 8:52 AM, joes wrote:
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non- >>>>>>>>>> haltingBut DDD doesn't prevent its own terminatation, as it calls >>>>>>>>>>>> an HHHYou know that DDD stopping running and DDD reaching its final >>>>>>>>>>> halt
that WILL abort its emulation and return and answer.
state are not the same thing you damned liar.
behavior, just not-yet-halted.
DDD emulated by HHH for an infinite number of steps never
reaches its
final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion >>>>>>>>> that
deciders must always halt.
By process of elimination and by the above criteria
we can determine that not stopping the emulation
causes HHH to never halt. This only leaves stopping
the emulation that semantically entails that the
input must be rejected.
No, because HHH must do what HHH does.
So I am tong because you claim that HHH
does not do what it does?
The problem is that your logic claims that HHH doesn't do what it
does, which is just emulate its inputpartially and them return.
void DDD()
{
HHH(DDD);
return;
}
Do you really think that anyone knowing the C
programming language is too stupid to see that
DDD simulated by HHH cannot possibly return?
Anyone knowing the C language can see that if HHH(DDD) returns then
so does DDD(), at least in any conforming implementation.
Changing the subject away from DDD simulated by HHH
is the straw-man deception error of reasoning.
On 4/5/2025 7:47 AM, Richard Damon wrote:
On 4/5/25 2:24 AM, olcott wrote:
On 4/3/2025 6:44 PM, Richard Damon wrote:
On 4/3/25 6:52 PM, olcott wrote:
On 4/3/2025 5:46 PM, Richard Damon wrote:
On 4/3/25 6:37 PM, olcott wrote:
On 4/2/2025 9:35 PM, Richard Damon wrote:
On 4/2/25 10:15 PM, olcott wrote:
On 4/2/2025 8:52 AM, joes wrote:
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non- >>>>>>>>>>>> haltingBut DDD doesn't prevent its own terminatation, as it calls >>>>>>>>>>>>>> an HHHYou know that DDD stopping running and DDD reaching its >>>>>>>>>>>>> final halt
that WILL abort its emulation and return and answer. >>>>>>>>>>>>>>
state are not the same thing you damned liar.
behavior, just not-yet-halted.
DDD emulated by HHH for an infinite number of steps never >>>>>>>>>>> reaches its
final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the
notion that
deciders must always halt.
By process of elimination and by the above criteria
we can determine that not stopping the emulation
causes HHH to never halt. This only leaves stopping
the emulation that semantically entails that the
input must be rejected.
No, because HHH must do what HHH does.
So I am tong because you claim that HHH
does not do what it does?
The problem is that your logic claims that HHH doesn't do what it
does, which is just emulate its inputpartially and them return.
void DDD()
{
HHH(DDD);
return;
}
Do you really think that anyone knowing the C
programming language is too stupid to see that
DDD simulated by HHH cannot possibly return?
WHich is irrelevent, as HHH to be a decider must abort and return
some answer, and thus DDD is halting.
We already know that you are not too stupid to
confuse an aborted simulation with reaching a
final state any halting. Why pretend otherwise?
But it also doesn't show non-halting,
Changing the subject away from DDD simulated by HHH
is the straw-man deception error of reasoning.
On 4/4/2025 2:52 AM, Mikko wrote:
On 2025-04-03 22:52:07 +0000, olcott said:
On 4/3/2025 5:46 PM, Richard Damon wrote:
On 4/3/25 6:37 PM, olcott wrote:
On 4/2/2025 9:35 PM, Richard Damon wrote:
On 4/2/25 10:15 PM, olcott wrote:
On 4/2/2025 8:52 AM, joes wrote:
Am Tue, 01 Apr 2025 21:37:40 -0500 schrieb olcott:
On 4/1/2025 8:13 PM, Richard Damon wrote:*finite
On 4/1/25 7:35 PM, olcott wrote:
On 4/1/2025 5:36 AM, Richard Damon wrote:
On 3/31/25 10:19 PM, olcott wrote:
You already admitted that you are lying about this.Right, the DDD who's simulation is stopped hasn't shown non- halting >>>>>>>>>> behavior, just not-yet-halted.But DDD doesn't prevent its own terminatation, as it calls an HHH >>>>>>>>>>>> that WILL abort its emulation and return and answer.You know that DDD stopping running and DDD reaching its final halt >>>>>>>>>>> state are not the same thing you damned liar.
DDD emulated by HHH for an infinite number of steps never reaches its >>>>>>>>> final halt state.
HHH sees this in one recursive emulation of DDD.It must also return the right value.
*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. The only rebuttal to this is rejecting the notion that >>>>>>>>> deciders must always halt.
By process of elimination and by the above criteria
we can determine that not stopping the emulation
causes HHH to never halt. This only leaves stopping
the emulation that semantically entails that the
input must be rejected.
No, because HHH must do what HHH does.
So I am tong because you claim that HHH
does not do what it does?
The problem is that your logic claims that HHH doesn't do what it does, >>>> which is just emulate its inputpartially and them return.
void DDD()
{
HHH(DDD);
return;
}
Do you really think that anyone knowing the C
programming language is too stupid to see that
DDD simulated by HHH cannot possibly return?
Anyone knowing the C language can see that if HHH(DDD) returns then
so does DDD(), at least in any conforming implementation.
Changing the subject away from DDD simulated by HHH
is the straw-man deception error of reasoning.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 10:43:30 |
| Calls: | 10,387 |
| Calls today: | 2 |
| Files: | 14,060 |
| Messages: | 6,416,691 |