On 7/12/2024 6:41 PM, Richard Damon wrote:Where does it disagree?!
On 7/12/24 7:19 PM, olcott wrote:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
You try to cut my airtight proof up in little pieces and fail. EveryWhich is just your double-talk to try to redefine what halting means.Thus each HHH element of the above infinite set of HHH/DDD pairs isNope.
necessarily correct to reject its DDD as non-halting.
NONE Of them CORRECTLY rejected itS DDD as non-halting and you are
shown to be ignorant of what you are talking about.
The HHH that did a partial emulation got the wrong answer, because
THEIR DDD will halt. and the HHH that doen't abort never get around
to rejecting its DDD as non-halting.
When no DDD of every HHH/DDD that can possibly exist halts then each
HHH that rejects its DDD as non-halting is necessarily correct.
*No double-talk and weasel words can overcome that*
rebuttal that you make has disagreeing with the semantics of the x86
language as its basis.
On 7/13/2024 3:48 AM, joes wrote:Please actually answer the question instead of derailing.
Am Fri, 12 Jul 2024 22:00:08 -0500 schrieb olcott:
On 7/12/2024 6:41 PM, Richard Damon wrote:
On 7/12/24 7:19 PM, olcott wrote:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
NONE Of them CORRECTLY rejected itS DDD as non-halting and you are >>>>>> shown to be ignorant of what you are talking about.
The HHH that did a partial emulation got the wrong answer, because >>>>>> THEIR DDD will halt. and the HHH that doen't abort never get around >>>>>> to rejecting its DDD as non-halting.
*This proves that every rebuttal is wrong somewhere*You try to cut my airtight proof up in little pieces and fail. EveryWhere does it disagree?!
rebuttal that you make has disagreeing with the semantics of the x86
language as its basis.
No DDD instance of each HHH/DDD pair of the infinite set of every
HHH/DDD pair ever reaches past its own machine address of 0000216b and
halts thus proving that every HHH is correct to reject its input DDD as non-halting.
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:This is the crux. You think that the nested HHH runs forever. But it
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
Which means the only "correct emulation" that tells the behavior of
the program at the input is a non-aborted one.
And thus HHH that do that know only the first N steps of the behavior
of DDD, which continues per the definition of the x86 instruction set
until the COMPLETE emulation (or direct execution) reaches a terminal
instruction.
And thus, the subset that only did a finite number of steps and
aborted its emulation on a non-terminal instrucition only have
partial knowledge of the behavior of their DDD, and by returning to
their caller, they establish that behavior for ALL copies of that
HHH, even the one that DDD calls, which shows that DDD will be
halting, even though HHH stopped its observation of the input before
it gets to that point.
Worth requoting.Wrong. EVERY DDD of an HHH that simulated its input for only a finite
number of steps WILL halt becuase it will reach its final return.
The HHH that simulated it for only a finite number of steps, only
learned that finite number of steps of the behaivor, and in EVERY
case, when we look at the behavior past that point, which DOES occur
per the definition of the x86 instruction set, as we have not reached
a "termial" instruction that stops behavior, will see the HHH(DDD)
that DDD called continuing to simulate its input to the point that
this one was defined to stop, and then returns 0 to DDDD and then DDD
returning and ending the behavior.
You continue to stupidly confuse the PARTIAL observation that HHH
does of the behavior of DDD by its PARTIAL emulation with the ACTUAL
FULL behavior of DDD as defined by the full definition of the x86
insttuction set.
What part of it contradicts which semantics?Your definition of correct contradicts the semantics of the x86 language making it wrong.This is double talk, because no HHH can possibly exist that simulatesNONE Of them CORRECTLY rejected itS DDD as non-halting and you are
shown to be ignorant of what you are talking about.
The HHH that did a partial emulation got the wrong answer, because
THEIR DDD will halt. and the HHH that doen't abort never get around
to rejecting its DDD as non-halting.
When no DDD of every HHH/DDD that can possibly exist halts then each
HHH that rejects its DDD as non-halting is necessarily correct.
itself correctly.
On 7/13/2024 7:20 AM, Fred. Zwarts wrote:Do you understand that a simulator that aborts does not run forever?
Op 13.jul.2024 om 13:39 schreef olcott:
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
You have a wrong understanding of the semantics of the x86 language.
You think that the x86 language specifies that skipping instructions do
not change the behaviour of a program.
As soon as the decider correctly determines that itself would never halt unless is aborts the simulation of its input the decider is required toWhich decider is aborting here, the simulated or the outer one?
abort this simulation.
On 7/13/2024 8:24 AM, joes wrote:Which is definitely not itself. Simulating a decider is guaranteed to
Am Sat, 13 Jul 2024 08:04:01 -0500 schrieb olcott:The executed decider is always correct to abort the simulation of any
On 7/13/2024 7:20 AM, Fred. Zwarts wrote:Do you understand that a simulator that aborts does not run forever?
Op 13.jul.2024 om 13:39 schreef olcott:
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
You have a wrong understanding of the semantics of the x86 language.
You think that the x86 language specifies that skipping instructions
do not change the behaviour of a program.
As soon as the decider correctly determines that itself would neverWhich decider is aborting here, the simulated or the outer one?
halt unless is aborts the simulation of its input the decider is
required to abort this simulation.
A decider always halts, so it cannot find itself non-halting.
damn thing that would cause itself to never halt.
On 7/13/2024 9:21 AM, joes wrote:It certainly is, because the DDD that it simulates calls HHH.
Am Sat, 13 Jul 2024 08:34:55 -0500 schrieb olcott:
On 7/13/2024 8:24 AM, joes wrote:
Am Sat, 13 Jul 2024 08:04:01 -0500 schrieb olcott:
On 7/13/2024 7:20 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 13:39 schreef olcott:
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
It cannot abort the simulation of itself because itself is notWhich is definitely not itself. Simulating a decider is guaranteed toThe executed decider is always correct to abort the simulation of anyAs soon as the decider correctly determines that itself would neverWhich decider is aborting here, the simulated or the outer one?
halt unless is aborts the simulation of its input the decider is
required to abort this simulation.
A decider always halts, so it cannot find itself non-halting.
damn thing that would cause itself to never halt.
halt. Same as a simulator that aborts.
simulated.
On 7/13/2024 5:40 PM, joes wrote:Can you elaborate? All runtime instances share the same static code.
Am Sat, 13 Jul 2024 09:31:33 -0500 schrieb olcott:You are thinking of its twin brother.
On 7/13/2024 9:21 AM, joes wrote:It certainly is, because the DDD that it simulates calls HHH.
Am Sat, 13 Jul 2024 08:34:55 -0500 schrieb olcott:
On 7/13/2024 8:24 AM, joes wrote:
Am Sat, 13 Jul 2024 08:04:01 -0500 schrieb olcott:
On 7/13/2024 7:20 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 13:39 schreef olcott:
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
It cannot abort the simulation of itself because itself is notWhich is definitely not itself. Simulating a decider is guaranteed toThe executed decider is always correct to abort the simulation ofAs soon as the decider correctly determines that itself wouldWhich decider is aborting here, the simulated or the outer one?
never halt unless is aborts the simulation of its input the
decider is required to abort this simulation.
A decider always halts, so it cannot find itself non-halting.
any damn thing that would cause itself to never halt.
halt. Same as a simulator that aborts.
simulated.
On 7/13/2024 6:26 PM, joes wrote:
Am Sat, 13 Jul 2024 17:47:46 -0500 schrieb olcott:
On 7/13/2024 5:40 PM, joes wrote:Can you elaborate? All runtime instances share the same static code.
Am Sat, 13 Jul 2024 09:31:33 -0500 schrieb olcott:You are thinking of its twin brother.
On 7/13/2024 9:21 AM, joes wrote:It certainly is, because the DDD that it simulates calls HHH.
Am Sat, 13 Jul 2024 08:34:55 -0500 schrieb olcott:
On 7/13/2024 8:24 AM, joes wrote:
Am Sat, 13 Jul 2024 08:04:01 -0500 schrieb olcott:
On 7/13/2024 7:20 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 13:39 schreef olcott:
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
It cannot abort the simulation of itself because itself is notWhich is definitely not itself. Simulating a decider is guaranteed to >>>>>> halt. Same as a simulator that aborts.The executed decider is always correct to abort the simulation of >>>>>>> any damn thing that would cause itself to never halt.As soon as the decider correctly determines that itself would >>>>>>>>> never halt unless is aborts the simulation of its input theWhich decider is aborting here, the simulated or the outer one? >>>>>>>> A decider always halts, so it cannot find itself non-halting.
decider is required to abort this simulation.
simulated.
I am talking about the inner HHH which is called by the simulated DDD.
That one is, according to you, aborted. Which is wrong, because by virtue
of running the same code, the inner HHH aborts ITS simulation of DDD
calling another HHH.
If you have a 100% complete understanding infinite recursion
then I can explain it in terms of much more details, otherwise
you can't possibly understand.
On 7/13/2024 6:26 PM, joes wrote:What are the twins and what is their difference?
Am Sat, 13 Jul 2024 17:47:46 -0500 schrieb olcott:If you have a 100% complete understanding infinite recursion then I can explain it in terms of much more details, otherwise you can't possibly understand.
On 7/13/2024 5:40 PM, joes wrote:Can you elaborate? All runtime instances share the same static code.
Am Sat, 13 Jul 2024 09:31:33 -0500 schrieb olcott:You are thinking of its twin brother.
On 7/13/2024 9:21 AM, joes wrote:It certainly is, because the DDD that it simulates calls HHH.
Am Sat, 13 Jul 2024 08:34:55 -0500 schrieb olcott:
On 7/13/2024 8:24 AM, joes wrote:
Am Sat, 13 Jul 2024 08:04:01 -0500 schrieb olcott:
On 7/13/2024 7:20 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 13:39 schreef olcott:
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
It cannot abort the simulation of itself because itself is notWhich is definitely not itself. Simulating a decider is guaranteed >>>>>> to halt. Same as a simulator that aborts.Which decider is aborting here, the simulated or the outer one? >>>>>>>> A decider always halts, so it cannot find itself non-halting.The executed decider is always correct to abort the simulation of >>>>>>> any damn thing that would cause itself to never halt.
simulated.
I am talking about the inner HHH which is called by the simulated DDD.
That one is, according to you, aborted. Which is wrong, because by
virtue of running the same code, the inner HHH aborts ITS simulation of
DDD calling another HHH.
On 7/13/2024 7:20 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 13:39 schreef olcott:
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
We stipulate that the only measure of a correct emulation is the >>>>>>> semantics of the x86 programming language.
Which means the only "correct emulation" that tells the behavior of the >>>>>> program at the input is a non-aborted one.
And thus HHH that do that know only the first N steps of the behavior >>>>>> of DDD, which continues per the definition of the x86 instruction set >>>>>> until the COMPLETE emulation (or direct execution) reaches a terminal >>>>>> instruction.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
When N steps of DDD are emulated by HHH according to the
semantics of the x86 language then N steps are emulated correctly. >>>>>>
When we examine the infinite set of every HHH/DDD pair such that: >>>>>>> HHH₁ one step of DDD is correctly emulated by HHH.
HHH₂ two steps of DDD are correctly emulated by HHH.
HHH₃ three steps of DDD are correctly emulated by HHH.
...
HHH∞ The emulation of DDD by HHH never stops running.
And thus, the subset that only did a finite number of steps and aborted >>>>>> its emulation on a non-terminal instrucition only have partial
knowledge of the behavior of their DDD, and by returning to their
caller, they establish that behavior for ALL copies of that HHH, even >>>>>> the one that DDD calls, which shows that DDD will be halting, even >>>>>> though HHH stopped its observation of the input before it gets to that >>>>>> point.
The above specifies the infinite set of every HHH/DDD pair
where 1 to infinity steps of DDD are correctly emulated by HHH.
No DDD instance of each HHH/DDD pair ever reaches past its
own machine address of 0000216b and halts.
Wrong. EVERY DDD of an HHH that simulated its input for only a finite >>>>>> number of steps WILL halt becuase it will reach its final return.
The HHH that simulated it for only a finite number of steps, only
learned that finite number of steps of the behaivor, and in EVERY case, >>>>>> when we look at the behavior past that point, which DOES occur per the >>>>>> definition of the x86 instruction set, as we have not reached a
"termial" instruction that stops behavior, will see the HHH(DDD) that >>>>>> DDD called continuing to simulate its input to the point that this one >>>>>> was defined to stop, and then returns 0 to DDDD and then DDD returning >>>>>> and ending the behavior.
You continue to stupidly confuse the PARTIAL observation that HHH does >>>>>> of the behavior of DDD by its PARTIAL emulation with the ACTUAL FULL >>>>>> behavior of DDD as defined by the full definition of the x86
insttuction set.
Thus each HHH element of the above infinite set of HHH/DDD
pairs is necessarily correct to reject its DDD as non-halting.
Nope.
NONE Of them CORRECTLY rejected itS DDD as non-halting and you are >>>>>> shown to be ignorant of what you are talking about.
The HHH that did a partial emulation got the wrong answer, because >>>>>> THEIR DDD will halt. and the HHH that doen't abort never get around to >>>>>> rejecting its DDD as non-halting.
*Here is the gist of my proof it is irrefutable*
When no DDD of every HHH/DDD that can possibly exist
halts then each HHH that rejects its DDD as non-halting
is necessarily correct.
*No double-talk and weasel words can overcome that*
This is double talk, because no HHH can possibly exist that simulates
itself correctly.
Your definition of correct contradicts the semantics of
the x86 language making it wrong.
You have a wrong understanding of the semantics of the x86 language.
You think that the x86 language specifies that skipping instructions do
not change the behaviour of a program.
You have the wrong understanding of a decider.
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:
Can you elaborate? All runtime instances share the same static code.
I am talking about the inner HHH which is called by the simulated
DDD. That one is, according to you, aborted. Which is wrong, because
by virtue of running the same code, the inner HHH aborts ITS
simulation of DDD calling another HHH.
What are the twins and what is their difference?
Do you disagree with my tracing?
The directly executed DDD is like the first call of infinite recursion.Not really. Execution does not continue.
The emulated DDD is just like the second call of infinite recursion.
When the second call of infinite recursion is aborted then the first
call halts.
void Infinite_Recursion()That would be incorrect.
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3 causing Infinite_Recursion() to halt.
When DDD calls HHH(DDD) HHH returns.Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as is provenI do not see this below.
below. The executed DDD() has HHH(DDD) skip this call.
HHH(DDD) must skip this call itself by terminating the whole DDDHow is this detected? Is it also triggered when calling a function
process.
Because this HHH does not know its own machine address HHH only sees
that DDD calls a function that causes its first four steps to be
repeated. HHH does not know that this is recursive simulation. To HHH it looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec -- create new process context for 2nd DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
According to the theory of computation the DDD that calls HHH(DDD) isYes it is. Everything that the simulatee calls is in the domain. It
not in the domain of HHH. HHH is not allowed to report on the behavior
of the process that it is contained within. *That breaks the rules of computation theory* HHH cannot even see the steps that were executed
before it was first invoked.
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:
Can you elaborate? All runtime instances share the same static code. >>>>> I am talking about the inner HHH which is called by the simulated
DDD. That one is, according to you, aborted. Which is wrong, because >>>>> by virtue of running the same code, the inner HHH aborts ITS
simulation of DDD calling another HHH.
What are the twins and what is their difference?
Do you disagree with my tracing?
The directly executed DDD is like the first call of infinite recursion.Not really. Execution does not continue.
The emulated DDD is just like the second call of infinite recursion.
When the second call of infinite recursion is aborted then the first
call halts.
void Infinite_Recursion()That would be incorrect.
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3 causing
Infinite_Recursion() to halt.
When DDD calls HHH(DDD) HHH returns.Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as is provenI do not see this below.
below. The executed DDD() has HHH(DDD) skip this call.
HHH(DDD) must skip this call itself by terminating the whole DDD
process.
Because this HHH does not know its own machine address HHH only sees
that DDD calls a function that causes its first four steps to be
repeated. HHH does not know that this is recursive simulation. To HHH it
looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec -- create new process context for 2nd DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)How is this detected?
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Is it also triggered when calling a function
in a loop?
According to the theory of computation the DDD that calls
HHH(DDD) is not in the domain of HHH.
On 7/14/2024 3:58 AM, Mikko wrote:
On 2024-07-13 13:04:01 +0000, olcott said:
On 7/13/2024 7:20 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 13:39 schreef olcott:
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
We stipulate that the only measure of a correct emulation is the >>>>>>>>> semantics of the x86 programming language.
Which means the only "correct emulation" that tells the behavior of the
program at the input is a non-aborted one.
And thus HHH that do that know only the first N steps of the behavior >>>>>>>> of DDD, which continues per the definition of the x86 instruction set >>>>>>>> until the COMPLETE emulation (or direct execution) reaches a terminal >>>>>>>> instruction.
_DDD()
[00002163] 55 push ebp ; housekeeping >>>>>>>>> [00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
When N steps of DDD are emulated by HHH according to the
semantics of the x86 language then N steps are emulated correctly. >>>>>>>>
When we examine the infinite set of every HHH/DDD pair such that: >>>>>>>>> HHH₁ one step of DDD is correctly emulated by HHH.
HHH₂ two steps of DDD are correctly emulated by HHH.
HHH₃ three steps of DDD are correctly emulated by HHH.
...
HHH∞ The emulation of DDD by HHH never stops running.
And thus, the subset that only did a finite number of steps and aborted
its emulation on a non-terminal instrucition only have partial >>>>>>>> knowledge of the behavior of their DDD, and by returning to their >>>>>>>> caller, they establish that behavior for ALL copies of that HHH, even >>>>>>>> the one that DDD calls, which shows that DDD will be halting, even >>>>>>>> though HHH stopped its observation of the input before it gets to that >>>>>>>> point.
The above specifies the infinite set of every HHH/DDD pair
where 1 to infinity steps of DDD are correctly emulated by HHH. >>>>>>>>>
No DDD instance of each HHH/DDD pair ever reaches past its
own machine address of 0000216b and halts.
Wrong. EVERY DDD of an HHH that simulated its input for only a finite >>>>>>>> number of steps WILL halt becuase it will reach its final return. >>>>>>>>
The HHH that simulated it for only a finite number of steps, only >>>>>>>> learned that finite number of steps of the behaivor, and in EVERY case,
when we look at the behavior past that point, which DOES occur per the >>>>>>>> definition of the x86 instruction set, as we have not reached a >>>>>>>> "termial" instruction that stops behavior, will see the HHH(DDD) that >>>>>>>> DDD called continuing to simulate its input to the point that this one >>>>>>>> was defined to stop, and then returns 0 to DDDD and then DDD returning >>>>>>>> and ending the behavior.
You continue to stupidly confuse the PARTIAL observation that HHH does >>>>>>>> of the behavior of DDD by its PARTIAL emulation with the ACTUAL FULL >>>>>>>> behavior of DDD as defined by the full definition of the x86
insttuction set.
Thus each HHH element of the above infinite set of HHH/DDD
pairs is necessarily correct to reject its DDD as non-halting. >>>>>>>>>
Nope.
NONE Of them CORRECTLY rejected itS DDD as non-halting and you are >>>>>>>> shown to be ignorant of what you are talking about.
The HHH that did a partial emulation got the wrong answer, because >>>>>>>> THEIR DDD will halt. and the HHH that doen't abort never get around to >>>>>>>> rejecting its DDD as non-halting.
*Here is the gist of my proof it is irrefutable*
When no DDD of every HHH/DDD that can possibly exist
halts then each HHH that rejects its DDD as non-halting
is necessarily correct.
*No double-talk and weasel words can overcome that*
This is double talk, because no HHH can possibly exist that simulates >>>>>> itself correctly.
Your definition of correct contradicts the semantics of
the x86 language making it wrong.
You have a wrong understanding of the semantics of the x86 language.
You think that the x86 language specifies that skipping instructions do >>>> not change the behaviour of a program.
You have the wrong understanding of a decider.
You seem to have a wrong understanding of a decider.
Calling a program a decider does not make it halt.
Calling a program a decider places a requirement
on its behavior: that it must halt.
On 7/14/2024 10:02 PM, Mike Terry wrote:
On 15/07/2024 01:20, joes wrote:
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:
Can you elaborate? All runtime instances share the same static code. >>>>>>> I am talking about the inner HHH which is called by the simulated >>>>>>> DDD. That one is, according to you, aborted. Which is wrong, because >>>>>>> by virtue of running the same code, the inner HHH aborts ITS
simulation of DDD calling another HHH.
What are the twins and what is their difference?
Do you disagree with my tracing?
The directly executed DDD is like the first call of infinite recursion. >>>> The emulated DDD is just like the second call of infinite recursion.Not really. Execution does not continue.
When the second call of infinite recursion is aborted then the first
call halts.
void Infinite_Recursion()That would be incorrect.
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3 causing
Infinite_Recursion() to halt.
When DDD calls HHH(DDD) HHH returns.Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as is proven >>>> below. The executed DDD() has HHH(DDD) skip this call.I do not see this below.
HHH(DDD) must skip this call itself by terminating the whole DDDHow is this detected?
process.
Because this HHH does not know its own machine address HHH only sees
that DDD calls a function that causes its first four steps to be
repeated. HHH does not know that this is recursive simulation. To
HHH it
looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>>
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>> New slave_stack at:14e2ec -- create new process context for 2nd DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
PO seems not to want to answer you, as I notice you've asked this
question more than once and PO dodges a direct response, so I'll try.
(Alternatively, PO has provided a link to his source code in the past,
so if you can find that link you can just look the answer yourself -
the functions are all in his halt7.c file, which is compiled but not
linked, then the obj file is interpreted within his x86utm.exe (source
also given in the link. The link might not reflect his current code??)
Anyhow, this is what I reckon...
HHH [outer HHH only!] examines a global trace table of simulated
instruction (from all simulation levels merged together). The
particular message "Infinite Recursion Detected Simulation Stopped"
seems to be issued when:
- last instruction is a CALL
- working backwards through the merged trace table, another CALL is
encountered
- ..which is issued at the same address
- ..and is calling to the same address
- ..and no "conditional branch" instructions occur in the trace table
between the two call instructions
KEY TO NOT BEING MISLED BY THE ABOVE:
0. The "Infinite Recursion Detected Simulation Stopped" message is
just a printf.
It does not prove that /actual/ infinite recursion was detected -
on the contrary,
all here but PO realise that the recursion detected is just finite
recursion.
1. The trace table being examined is NOT an x86 processor trace - it is a
"merged simulation trace" containing entries for ALL SIMULATION
LEVELS.
So the two CALL instructions are not referring to one single x86
processor.
When emulated DDD calls HHH(DDD) the outer HHH emulates itself
emulating DDD.
I think that joes does not understand these things.
Typically, the last call instruction is from a deeper nested
simulation
than the earlier detected call instruction. The outer simulations >> are all
still running, but do not appear in the trace table or logs
presented by PO
due to the next note.
2. The searched trace table is filtered to only contain instructions
within the C
function D/DD/DDD/.. !!
YES, YOU READ THAT RIGHT! ALL CODE IN HHH IS TOTALLY IGNORED,
INCLUDING
THE CONDITIONAL BRANCH INSTRUCTIONS THAT ARE TESTING THE VERY
ABORT TESTS
THAT CAUSE OUTER HHH TO ABORT.
3. Inner HHH's do not perform the same tests as above, because they
inspect a global
variable which tells them they are inner HHH's. Yeah, that means
the simulation
is completely broken logically... [but... the outer HHH will abort
first, so
PO might argue the outcome will be the same, even though logically
it is
broken...]
Is it also triggered when calling a function
in a loop?
Not sure what you mean. Calling a function in a loop ends if the loop
ends, right? What loop are you thinking of?
Anyhow, provided the call instructions are physically located in
function D() [i.e. not H() or something called from H] I guess it
would match. But the C function D has only one call instruction,
which isn't in a loop!
Regards,
Mike.
*I have boiled it all down to this simple tautology*
Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.
On 7/14/2024 7:20 PM, joes wrote:As if you would believe me.
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:What are the twins and what is their difference? Do you disagree with
Can you elaborate? All runtime instances share the same static
code.
I am talking about the inner HHH which is called by the simulated
DDD. That one is, according to you, aborted. Which is wrong,
because by virtue of running the same code, the inner HHH aborts
ITS simulation of DDD calling another HHH.
my tracing?
The directly executed DDD is like the first call of infiniteNot really. Execution does not continue.
recursion. The emulated DDD is just like the second call of infinite
recursion. When the second call of infinite recursion is aborted then
the first call halts.
void Infinite_Recursion()That would be incorrect.
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3 causing
Infinite_Recursion() to halt.
When DDD calls HHH(DDD) HHH returns.Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as is provenI do not see this below.
below. The executed DDD() has HHH(DDD) skip this call.
HHH(DDD) must skip this call itself by terminating the whole DDDHow is this detected? Is it also triggered when calling a function in a
process.
Because this HHH does not know its own machine address HHH only sees
that DDD calls a function that causes its first four steps to be
repeated. HHH does not know that this is recursive simulation. To HHH
it looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD) New slave_stack at:14e2ec -- create new process context for
2nd DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD) Local Halt Decider: Infinite Recursion Detected Simulation
Stopped
loop?
You never bothered to answer whether or not you have 100% understanding
of infinite recursion. If you don't then you can never understand what I
am saying. If you do that I already proved my point. Here is the proof
again:
On 7/14/2024 10:02 PM, Mike Terry wrote:to give the abortion criterion.
On 15/07/2024 01:20, joes wrote:
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:
PO seems not to want to answer you, as I notice you've asked this[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; callHow is this detected?
HHH(DDD) Local Halt Decider: Infinite Recursion Detected Simulation
Stopped
question more than once and PO dodges a direct response, so I'll try.
(Alternatively, PO has provided a link to his source code in the past,
so if you can find that link you can just look the answer yourself -
the functions are all in his halt7.c file, which is compiled but not
linked, then the obj file is interpreted within his x86utm.exe (source
also given in the link. The link might not reflect his current code??) Thank you. I didn't bother digging through their code, and they refused
Ah, and here I believed them when they said they had rewritten it.HHH [outer HHH only!] examines a global trace table of simulatedWhen emulated DDD calls HHH(DDD) the outer HHH emulates itself emulating
instruction (from all simulation levels merged together). The
particular message "Infinite Recursion Detected Simulation Stopped"
seems to be issued when:
- last instruction is a CALL - working backwards through the merged
trace table, another CALL is encountered - ..which is issued at the
same address - ..and is calling to the same address - ..and no
"conditional branch" instructions occur in the trace table
between the two call instructions
KEY TO NOT BEING MISLED BY THE ABOVE:
0. The "Infinite Recursion Detected Simulation Stopped" message is just
a printf.
It does not prove that /actual/ infinite recursion was detected -
on the contrary,
all here but PO realise that the recursion detected is just
finite recursion.
1. The trace table being examined is NOT an x86 processor trace - it is
a "merged simulation trace" containing entries for ALL SIMULATION
LEVELS.
So the two CALL instructions are not referring to one single x86
processor.
DDD.
I think that joes does not understand these things.
Typically, the last call instruction is from a deeper nested
simulation than the earlier detected call instruction. The outer
simulations are all
still running, but do not appear in the trace table or logs
presented by PO due to the next note.
2. The searched trace table is filtered to only contain instructions
within the C function D/DD/DDD/.. !!
YES, YOU READ THAT RIGHT! ALL CODE IN HHH IS TOTALLY IGNORED,
INCLUDING
THE CONDITIONAL BRANCH INSTRUCTIONS THAT ARE TESTING THE VERY
ABORT TESTS THAT CAUSE OUTER HHH TO ABORT.
3. Inner HHH's do not perform the same tests as above, because they
inspect a global
variable which tells them they are inner HHH's. Yeah, that means
the simulation
is completely broken logically... [but... the outer HHH will
abort first, so
PO might argue the outcome will be the same, even though
logically it is broken...]
I wondered about just calling the same function repeatedly with the same parameters (on the same simulation level).Is it also triggered when calling a function in a loop?Not sure what you mean. Calling a function in a loop ends if the loop
ends, right? What loop are you thinking of?
Anyhow, provided the call instructions are physically located in
function D() [i.e. not H() or something called from H] I guess it would
match. But the C function D has only one call instruction, which isn't
in a loop!
Any input that must be aborted to prevent the non termination ofIt's just that the input HHH halts and does not need to be aborted.
simulating termination analyzer HHH necessarily specifies non-halting behavior or it would never need to be aborted.
On 7/15/2024 3:59 AM, joes wrote:Because it hadn't halted yet? Why should it have halted, it will do so
Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:
At the point that it is aborted it did need to be abortedAny input that must be aborted to prevent the non termination ofIt's just that the input HHH halts and does not need to be aborted.
simulating termination analyzer HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
On 7/15/2024 3:35 AM, Fred. Zwarts wrote:This here is the key. When a simulator (that doesn't abort) simulates
Op 15.jul.2024 om 05:35 schreef olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:But since HHH aborts,
On 15/07/2024 01:20, joes wrote:
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:Not really. Execution does not continue.
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:
Can you elaborate? All runtime instances share the same static >>>>>>>>> code.
I am talking about the inner HHH which is called by the
simulated DDD. That one is, according to you, aborted. Which is >>>>>>>>> wrong, because by virtue of running the same code, the inner HHH >>>>>>>>> aborts ITS simulation of DDD calling another HHH.
What are the twins and what is their difference? Do you disagree >>>>>>> with my tracing?
The directly executed DDD is like the first call of infinite
recursion.
The emulated DDD is just like the second call of infinite
recursion. When the second call of infinite recursion is aborted
then the first call halts.
void Infinite_Recursion()That would be incorrect.
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3
causing Infinite_Recursion() to halt.
When DDD calls HHH(DDD) HHH returns.Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as isI do not see this below.
proven below. The executed DDD() has HHH(DDD) skip this call.
HHH(DDD) must skip this call itself by terminating the whole DDDHow is this detected?
process.
Because this HHH does not know its own machine address HHH only
sees that DDD calls a function that causes its first four steps to >>>>>> be repeated. HHH does not know that this is recursive simulation.
To HHH it looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD >>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
at:1138cc
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec -- create new process context for 2nd DDD >>>>>
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
PO seems not to want to answer you, as I notice you've asked this
question more than once and PO dodges a direct response, so I'll try.
(Alternatively, PO has provided a link to his source code in the
past, so if you can find that link you can just look the answer
yourself - the functions are all in his halt7.c file, which is
compiled but not linked, then the obj file is interpreted within his
x86utm.exe (source also given in the link. The link might not
reflect his current code??)
HHH [outer HHH only!] examines a global trace table of simulated
instruction (from all simulation levels merged together). The
particular message "Infinite Recursion Detected Simulation Stopped"
seems to be issued when:
- last instruction is a CALL - working backwards through the merged >>>> trace table, another CALL is encountered - ..which is issued at the
same address - ..and is calling to the same address - ..and no
"conditional branch" instructions occur in the trace table
between the two call instructions
KEY TO NOT BEING MISLED BY THE ABOVE:
0. The "Infinite Recursion Detected Simulation Stopped" message is
just a printf.
It does not prove that /actual/ infinite recursion was
detected - on the contrary,
all here but PO realise that the recursion detected is just
finite recursion.
1. The trace table being examined is NOT an x86 processor trace - it
is a "merged simulation trace" containing entries for ALL
SIMULATION LEVELS.
So the two CALL instructions are not referring to one single
x86 processor.
When emulated DDD calls HHH(DDD) the outer HHH emulates itself
emulating DDD.
I think that joes does not understand these things.
Typically, the last call instruction is from a deeper nestedAny input that must be aborted to prevent the non termination of
simulation
than the earlier detected call instruction. The outer
simulations are all
still running, but do not appear in the trace table or logs
presented by PO due to the next note.
2. The searched trace table is filtered to only contain instructions
within the C function D/DD/DDD/.. !!
YES, YOU READ THAT RIGHT! ALL CODE IN HHH IS TOTALLY IGNORED, >>>> INCLUDING
THE CONDITIONAL BRANCH INSTRUCTIONS THAT ARE TESTING THE VERY
ABORT TESTS THAT CAUSE OUTER HHH TO ABORT.
3. Inner HHH's do not perform the same tests as above, because they
inspect a global
variable which tells them they are inner HHH's. Yeah, that
means the simulation
is completely broken logically... [but... the outer HHH will
abort first, so
PO might argue the outcome will be the same, even though
logically it is broken...]
Is it also triggered when calling a function in a loop?
Not sure what you mean. Calling a function in a loop ends if the
loop ends, right? What loop are you thinking of?
Anyhow, provided the call instructions are physically located in
function D() [i.e. not H() or something called from H] I guess it
would match. But the C function D has only one call instruction,
which isn't in a loop!
simulating termination analyzer HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
The above tautology asks about the behavior of DDD correctly emulated by
pure function HHH according to the semantics of the x86 language when
HHH never aborts.
Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:
On 15/07/2024 01:20, joes wrote:
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:
Thank you. I didn't bother digging through their code, and they refusedPO seems not to want to answer you, as I notice you've asked this[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; callHow is this detected?
HHH(DDD) Local Halt Decider: Infinite Recursion Detected Simulation
Stopped
question more than once and PO dodges a direct response, so I'll try.
(Alternatively, PO has provided a link to his source code in the past,
so if you can find that link you can just look the answer yourself -
the functions are all in his halt7.c file, which is compiled but not
linked, then the obj file is interpreted within his x86utm.exe (source
also given in the link. The link might not reflect his current code??)
to give the abortion criterion.
HHH [outer HHH only!] examines a global trace table of simulatedWhen emulated DDD calls HHH(DDD) the outer HHH emulates itself emulating
instruction (from all simulation levels merged together). The
particular message "Infinite Recursion Detected Simulation Stopped"
seems to be issued when:
- last instruction is a CALL - working backwards through the merged
trace table, another CALL is encountered - ..which is issued at the
same address - ..and is calling to the same address - ..and no
"conditional branch" instructions occur in the trace table
between the two call instructions
KEY TO NOT BEING MISLED BY THE ABOVE:
0. The "Infinite Recursion Detected Simulation Stopped" message is just
a printf.
It does not prove that /actual/ infinite recursion was detected -
on the contrary,
all here but PO realise that the recursion detected is just
finite recursion.
1. The trace table being examined is NOT an x86 processor trace - it is
a "merged simulation trace" containing entries for ALL SIMULATION
LEVELS.
So the two CALL instructions are not referring to one single x86
processor.
DDD.
I think that joes does not understand these things.
Ah, and here I believed them when they said they had rewritten it.Typically, the last call instruction is from a deeper nested
simulation than the earlier detected call instruction. The outer
simulations are all
still running, but do not appear in the trace table or logs
presented by PO due to the next note.
2. The searched trace table is filtered to only contain instructions
within the C function D/DD/DDD/.. !!
YES, YOU READ THAT RIGHT! ALL CODE IN HHH IS TOTALLY IGNORED,
INCLUDING
THE CONDITIONAL BRANCH INSTRUCTIONS THAT ARE TESTING THE VERY
ABORT TESTS THAT CAUSE OUTER HHH TO ABORT.
3. Inner HHH's do not perform the same tests as above, because they
inspect a global
variable which tells them they are inner HHH's. Yeah, that means
the simulation
is completely broken logically... [but... the outer HHH will
abort first, so
PO might argue the outcome will be the same, even though
logically it is broken...]
I wondered about just calling the same function repeatedly with the same parameters (on the same simulation level).> Is it also triggered when calling a function in a loop?
Not sure what you mean. Calling a function in a loop ends if the loop
ends, right? What loop are you thinking of?
Anyhow, provided the call instructions are physically located in
function D() [i.e. not H() or something called from H] I guess it would
match. But the C function D has only one call instruction, which isn't
in a loop!
Any input that must be aborted to prevent the non termination ofIt's just that the input HHH halts and does not need to be aborted.
simulating termination analyzer HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
On 7/15/2024 3:49 AM, joes wrote:
Am Sun, 14 Jul 2024 19:30:27 -0500 schrieb olcott:
On 7/14/2024 7:20 PM, joes wrote:As if you would believe me.
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:What are the twins and what is their difference? Do you disagree with >>>>>> my tracing?
Can you elaborate? All runtime instances share the same static >>>>>>>> code.
I am talking about the inner HHH which is called by the simulated >>>>>>>> DDD. That one is, according to you, aborted. Which is wrong,
because by virtue of running the same code, the inner HHH aborts >>>>>>>> ITS simulation of DDD calling another HHH.
The directly executed DDD is like the first call of infiniteNot really. Execution does not continue.
recursion. The emulated DDD is just like the second call of infinite >>>>> recursion. When the second call of infinite recursion is aborted then >>>>> the first call halts.
void Infinite_Recursion()That would be incorrect.
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3 causing >>>>> Infinite_Recursion() to halt.
When DDD calls HHH(DDD) HHH returns.Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as is proven >>>>> below. The executed DDD() has HHH(DDD) skip this call.I do not see this below.
HHH(DDD) must skip this call itself by terminating the whole DDDHow is this detected? Is it also triggered when calling a function in a >>>> loop?
process.
Because this HHH does not know its own machine address HHH only sees >>>>> that DDD calls a function that causes its first four steps to be
repeated. HHH does not know that this is recursive simulation. To HHH >>>>> it looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>>>
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD) New slave_stack at:14e2ec -- create new process context for >>>>> 2nd DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD) Local Halt Decider: Infinite Recursion Detected Simulation
Stopped
You never bothered to answer whether or not you have 100% understanding
of infinite recursion. If you don't then you can never understand what I >>> am saying. If you do that I already proved my point. Here is the proof
again:
You never bothered to answer my questions (see above).
That only proves that HHH and DDD halt.
This *is* an answer too difficult for you to understand.
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55 push ebp ; housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
On 7/15/2024 9:04 AM, joes wrote:
Am Mon, 15 Jul 2024 07:23:57 -0500 schrieb olcott:
On 7/15/2024 3:59 AM, joes wrote:Because it hadn't halted yet?
Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:
At the point that it is aborted it did need to be abortedAny input that must be aborted to prevent the non termination ofIt's just that the input HHH halts and does not need to be aborted.
simulating termination analyzer HHH necessarily specifies non-halting >>>>> behavior or it would never need to be aborted.
Because HHH has seen a repeating state that proves that DDD
correctly emulated by HHH cannot possibly ever stop running
unless aborted.
That you fail to understand a that there is a repeating state
or fail to understand that a repeating state proves this is
less than no rebuttal at all.
Why should it have halted, it will do so
in the future. Do you place arbitrary lifetime limits on all programs?
On 7/15/2024 3:35 AM, Fred. Zwarts wrote:
Op 15.jul.2024 om 05:35 schreef olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:But since HHH aborts,
On 15/07/2024 01:20, joes wrote:
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:
Can you elaborate? All runtime instances share the same static >>>>>>>>> code.
I am talking about the inner HHH which is called by the simulated >>>>>>>>> DDD. That one is, according to you, aborted. Which is wrong, >>>>>>>>> because
by virtue of running the same code, the inner HHH aborts ITS >>>>>>>>> simulation of DDD calling another HHH.
What are the twins and what is their difference?
Do you disagree with my tracing?
The directly executed DDD is like the first call of infiniteNot really. Execution does not continue.
recursion.
The emulated DDD is just like the second call of infinite recursion. >>>>>> When the second call of infinite recursion is aborted then the first >>>>>> call halts.
void Infinite_Recursion()That would be incorrect.
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3 causing >>>>>> Infinite_Recursion() to halt.
When DDD calls HHH(DDD) HHH returns.Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as isI do not see this below.
proven
below. The executed DDD() has HHH(DDD) skip this call.
HHH(DDD) must skip this call itself by terminating the whole DDDHow is this detected?
process.
Because this HHH does not know its own machine address HHH only sees >>>>>> that DDD calls a function that causes its first four steps to be
repeated. HHH does not know that this is recursive simulation. To
HHH it
looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD >>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
at:1138cc
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec -- create new process context for 2nd DDD >>>>>
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
PO seems not to want to answer you, as I notice you've asked this
question more than once and PO dodges a direct response, so I'll
try. (Alternatively, PO has provided a link to his source code in
the past, so if you can find that link you can just look the answer
yourself - the functions are all in his halt7.c file, which is
compiled but not linked, then the obj file is interpreted within his
x86utm.exe (source also given in the link. The link might not
reflect his current code??)
Anyhow, this is what I reckon...
HHH [outer HHH only!] examines a global trace table of simulated
instruction (from all simulation levels merged together). The
particular message "Infinite Recursion Detected Simulation Stopped"
seems to be issued when:
- last instruction is a CALL
- working backwards through the merged trace table, another CALL is
encountered
- ..which is issued at the same address
- ..and is calling to the same address
- ..and no "conditional branch" instructions occur in the trace table >>>> between the two call instructions
KEY TO NOT BEING MISLED BY THE ABOVE:
0. The "Infinite Recursion Detected Simulation Stopped" message is
just a printf.
It does not prove that /actual/ infinite recursion was detected >>>> - on the contrary,
all here but PO realise that the recursion detected is just
finite recursion.
1. The trace table being examined is NOT an x86 processor trace - it
is a
"merged simulation trace" containing entries for ALL SIMULATION >>>> LEVELS.
So the two CALL instructions are not referring to one single x86 >>>> processor.
When emulated DDD calls HHH(DDD) the outer HHH emulates itself
emulating DDD.
I think that joes does not understand these things.
Typically, the last call instruction is from a deeper nested
simulation
than the earlier detected call instruction. The outer
simulations are all
still running, but do not appear in the trace table or logs
presented by PO
due to the next note.
2. The searched trace table is filtered to only contain instructions
within the C
function D/DD/DDD/.. !!
YES, YOU READ THAT RIGHT! ALL CODE IN HHH IS TOTALLY IGNORED, >>>> INCLUDING
THE CONDITIONAL BRANCH INSTRUCTIONS THAT ARE TESTING THE VERY
ABORT TESTS
THAT CAUSE OUTER HHH TO ABORT.
3. Inner HHH's do not perform the same tests as above, because they
inspect a global
variable which tells them they are inner HHH's. Yeah, that
means the simulation
is completely broken logically... [but... the outer HHH will
abort first, so
PO might argue the outcome will be the same, even though
logically it is
broken...]
Is it also triggered when calling a function
in a loop?
Not sure what you mean. Calling a function in a loop ends if the
loop ends, right? What loop are you thinking of?
Anyhow, provided the call instructions are physically located in
function D() [i.e. not H() or something called from H] I guess it
would match. But the C function D has only one call instruction,
which isn't in a loop!
Regards,
Mike.
*I have boiled it all down to this simple tautology*
Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.
The above tautology asks about the behavior of DDD correctly
emulated by pure function HHH according to the semantics
of the x86 language when HHH never aborts.
If when you are very hungry and you eat until you are full
you cannot correctly say that you were never hungry.
On 7/15/2024 9:04 AM, joes wrote:Which state is it that repeats forever? We know that HHH will abort.
Am Mon, 15 Jul 2024 07:23:57 -0500 schrieb olcott:Because HHH has seen a repeating state that proves that DDD correctly emulated by HHH cannot possibly ever stop running unless aborted.
On 7/15/2024 3:59 AM, joes wrote:Because it hadn't halted yet?
Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:
At the point that it is aborted it did need to be abortedAny input that must be aborted to prevent the non termination ofIt's just that the input HHH halts and does not need to be aborted.
simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.
That you fail to understand a that there is a repeating state or fail to understand that a repeating state proves this is less than no rebuttalThe state is in fact different in some internal decision logic that waits
at all.
Why should it have halted, it will do so in the future. Do you place
arbitrary lifetime limits on all programs?
On 7/15/2024 3:49 AM, joes wrote:
Am Sun, 14 Jul 2024 19:30:27 -0500 schrieb olcott:
On 7/14/2024 7:20 PM, joes wrote:As if you would believe me.
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:What are the twins and what is their difference? Do you disagree with >>>>>> my tracing?
Can you elaborate? All runtime instances share the same static >>>>>>>> code.
I am talking about the inner HHH which is called by the simulated >>>>>>>> DDD. That one is, according to you, aborted. Which is wrong,
because by virtue of running the same code, the inner HHH aborts >>>>>>>> ITS simulation of DDD calling another HHH.
The directly executed DDD is like the first call of infiniteNot really. Execution does not continue.
recursion. The emulated DDD is just like the second call of infinite >>>>> recursion. When the second call of infinite recursion is aborted then >>>>> the first call halts.
void Infinite_Recursion()That would be incorrect.
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3 causing >>>>> Infinite_Recursion() to halt.
When DDD calls HHH(DDD) HHH returns.Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as is proven >>>>> below. The executed DDD() has HHH(DDD) skip this call.I do not see this below.
HHH(DDD) must skip this call itself by terminating the whole DDDHow is this detected? Is it also triggered when calling a function in a >>>> loop?
process.
Because this HHH does not know its own machine address HHH only sees >>>>> that DDD calls a function that causes its first four steps to be
repeated. HHH does not know that this is recursive simulation. To HHH >>>>> it looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>>>
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD) New slave_stack at:14e2ec -- create new process context for >>>>> 2nd DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD) Local Halt Decider: Infinite Recursion Detected Simulation
Stopped
You never bothered to answer whether or not you have 100% understanding
of infinite recursion. If you don't then you can never understand what I >>> am saying. If you do that I already proved my point. Here is the proof
again:
You never bothered to answer my questions (see above).
That only proves that HHH and DDD halt.
This *is* an answer too difficult for you to understand.
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55 push ebp ; housekeeping [00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping [00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping [00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
On 7/15/2024 3:09 AM, Mikko wrote:
On 2024-07-14 14:00:55 +0000, olcott said:
According to the theory of computation the DDD that calls
HHH(DDD) is not in the domain of HHH.
The theory of computation does not say what the domain of HHH is.
Sure it does. Where the Hell have you been?
It says that the halting problem is defined in terms
of finite strings that encode Turing machines.
Unless the specificaiton of HHH says otherwise HHH should be able
to handle every input that can be given to it,
No halt decider is allowed to report on the computation
that it is contained within for several different reasons
one of them is that computations are not finite strings.
On 7/15/2024 3:15 AM, Mikko wrote:
On 2024-07-14 14:49:30 +0000, olcott said:
On 7/14/2024 3:58 AM, Mikko wrote:
On 2024-07-13 13:04:01 +0000, olcott said:
On 7/13/2024 7:20 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 13:39 schreef olcott:
On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
Op 13.jul.2024 om 01:19 schreef olcott:
On 7/12/2024 5:56 PM, Richard Damon wrote:
On 7/12/24 10:56 AM, olcott wrote:
We stipulate that the only measure of a correct emulation is the >>>>>>>>>>> semantics of the x86 programming language.
Which means the only "correct emulation" that tells the behavior of the
program at the input is a non-aborted one.
And thus HHH that do that know only the first N steps of the behavior
_DDD()
[00002163] 55 push ebp ; housekeeping >>>>>>>>>>> [00002164] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>> [00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
When N steps of DDD are emulated by HHH according to the >>>>>>>>>>> semantics of the x86 language then N steps are emulated correctly. >>>>>>>>>>
of DDD, which continues per the definition of the x86 instruction set
until the COMPLETE emulation (or direct execution) reaches a terminal
instruction.
When we examine the infinite set of every HHH/DDD pair such that: >>>>>>>>>>> HHH₁ one step of DDD is correctly emulated by HHH.
HHH₂ two steps of DDD are correctly emulated by HHH.
HHH₃ three steps of DDD are correctly emulated by HHH. >>>>>>>>>>> ...
HHH∞ The emulation of DDD by HHH never stops running.
And thus, the subset that only did a finite number of steps and aborted
its emulation on a non-terminal instrucition only have partial >>>>>>>>>> knowledge of the behavior of their DDD, and by returning to their >>>>>>>>>> caller, they establish that behavior for ALL copies of that HHH, even
the one that DDD calls, which shows that DDD will be halting, even >>>>>>>>>> though HHH stopped its observation of the input before it gets to that
point.
The above specifies the infinite set of every HHH/DDD pair >>>>>>>>>>> where 1 to infinity steps of DDD are correctly emulated by HHH. >>>>>>>>>>>
No DDD instance of each HHH/DDD pair ever reaches past its >>>>>>>>>>> own machine address of 0000216b and halts.
Wrong. EVERY DDD of an HHH that simulated its input for only a finite
number of steps WILL halt becuase it will reach its final return. >>>>>>>>>>
The HHH that simulated it for only a finite number of steps, only >>>>>>>>>> learned that finite number of steps of the behaivor, and in EVERY case,
when we look at the behavior past that point, which DOES occur per the
definition of the x86 instruction set, as we have not reached a >>>>>>>>>> "termial" instruction that stops behavior, will see the HHH(DDD) that
DDD called continuing to simulate its input to the point that this one
was defined to stop, and then returns 0 to DDDD and then DDD returning
and ending the behavior.
You continue to stupidly confuse the PARTIAL observation that HHH does
of the behavior of DDD by its PARTIAL emulation with the ACTUAL FULL >>>>>>>>>> behavior of DDD as defined by the full definition of the x86 >>>>>>>>>> insttuction set.
Thus each HHH element of the above infinite set of HHH/DDD >>>>>>>>>>> pairs is necessarily correct to reject its DDD as non-halting. >>>>>>>>>>>
Nope.
NONE Of them CORRECTLY rejected itS DDD as non-halting and you are >>>>>>>>>> shown to be ignorant of what you are talking about.
The HHH that did a partial emulation got the wrong answer, because >>>>>>>>>> THEIR DDD will halt. and the HHH that doen't abort never get around to
rejecting its DDD as non-halting.
*Here is the gist of my proof it is irrefutable*
When no DDD of every HHH/DDD that can possibly exist
halts then each HHH that rejects its DDD as non-halting
is necessarily correct.
*No double-talk and weasel words can overcome that*
This is double talk, because no HHH can possibly exist that simulates >>>>>>>> itself correctly.
Your definition of correct contradicts the semantics of
the x86 language making it wrong.
You have a wrong understanding of the semantics of the x86 language. >>>>>> You think that the x86 language specifies that skipping instructions do >>>>>> not change the behaviour of a program.
You have the wrong understanding of a decider.
You seem to have a wrong understanding of a decider.
Calling a program a decider does not make it halt.
Calling a program a decider places a requirement
on its behavior: that it must halt.
Placing a requirement that the program must halt does not make it halt.
It requires it to halt on inputs in its domain or it does
not meet its own design spec.
On 7/15/2024 3:58 PM, joes wrote:Well then, which state of HHH would repeat forever?
Am Mon, 15 Jul 2024 10:52:34 -0500 schrieb olcott:*It had never been which state DOES repeat forever*
On 7/15/2024 9:04 AM, joes wrote:Which state is it that repeats forever?
Am Mon, 15 Jul 2024 07:23:57 -0500 schrieb olcott:Because HHH has seen a repeating state that proves that DDD correctly
On 7/15/2024 3:59 AM, joes wrote:Because it hadn't halted yet?
Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:
Any input that must be aborted to prevent the non termination of >>>>>>> simulating termination analyzer HHH necessarily specifiesIt's just that the input HHH halts and does not need to be aborted. >>>>> At the point that it is aborted it did need to be aborted
non-halting behavior or it would never need to be aborted.
emulated by HHH cannot possibly ever stop running unless aborted.
*It has always been which state WOULD repeat forever if not aborted*
Infinite_Loop() doesn't even repeat forever because it is aborted.By itself it does.
On 7/16/2024 3:23 AM, joes wrote:Those two are the same, but different to what you said above.
Am Mon, 15 Jul 2024 16:03:30 -0500 schrieb olcott:It is not "which state of HHH would repeat forever?"
On 7/15/2024 3:58 PM, joes wrote:Well then, which state of HHH would repeat forever?
Am Mon, 15 Jul 2024 10:52:34 -0500 schrieb olcott:*It had never been which state DOES repeat forever*
On 7/15/2024 9:04 AM, joes wrote:Which state is it that repeats forever?
Am Mon, 15 Jul 2024 07:23:57 -0500 schrieb olcott:Because HHH has seen a repeating state that proves that DDD
On 7/15/2024 3:59 AM, joes wrote:Because it hadn't halted yet?
Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:
At the point that it is aborted it did need to be abortedAny input that must be aborted to prevent the non termination of >>>>>>>>> simulating termination analyzer HHH necessarily specifiesIt's just that the input HHH halts and does not need to be
non-halting behavior or it would never need to be aborted.
aborted.
correctly emulated by HHH cannot possibly ever stop running unless
aborted.
*It has always been which state WOULD repeat forever if not aborted*
It is: Which state of HHH would repeat forever if not aborted?
Infinite_Loop() doesn't even repeat forever because it is aborted.By itself it does.
On 7/16/2024 3:23 AM, joes wrote:
Am Mon, 15 Jul 2024 16:03:30 -0500 schrieb olcott:
On 7/15/2024 3:58 PM, joes wrote:Well then, which state of HHH would repeat forever?
Am Mon, 15 Jul 2024 10:52:34 -0500 schrieb olcott:*It had never been which state DOES repeat forever*
On 7/15/2024 9:04 AM, joes wrote:Which state is it that repeats forever?
Am Mon, 15 Jul 2024 07:23:57 -0500 schrieb olcott:Because HHH has seen a repeating state that proves that DDD correctly >>>>> emulated by HHH cannot possibly ever stop running unless aborted.
On 7/15/2024 3:59 AM, joes wrote:Because it hadn't halted yet?
Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:
Any input that must be aborted to prevent the non termination of >>>>>>>>> simulating termination analyzer HHH necessarily specifiesIt's just that the input HHH halts and does not need to be aborted. >>>>>>> At the point that it is aborted it did need to be aborted
non-halting behavior or it would never need to be aborted.
*It has always been which state WOULD repeat forever if not aborted*
*You still have it wrong*.
It is not "which state of HHH would repeat forever?"
It is: Which state of HHH would repeat forever if not aborted?
On 7/16/2024 2:47 AM, Mikko wrote:A description of a TM may be given to that same machine as input.
On 2024-07-15 13:39:07 +0000, olcott said:
On 7/15/2024 3:09 AM, Mikko wrote:
On 2024-07-14 14:00:55 +0000, olcott said:It says that the halting problem is defined in terms of finite strings
According to the theory of computation the DDD that calls HHH(DDD)The theory of computation does not say what the domain of HHH is.
is not in the domain of HHH.
that encode Turing machines.
The theory of computation only allows finite string inputs.
It does not allow the currently executing Turing Machine to be its own
input.
On 7/16/2024 2:20 AM, Mikko wrote:
On 2024-07-15 12:22:19 +0000, olcott said:
On 7/15/2024 3:49 AM, joes wrote:
Am Sun, 14 Jul 2024 19:30:27 -0500 schrieb olcott:
On 7/14/2024 7:20 PM, joes wrote:As if you would believe me.
Am Sun, 14 Jul 2024 09:00:55 -0500 schrieb olcott:
On 7/14/2024 3:29 AM, joes wrote:
Am Sat, 13 Jul 2024 18:33:53 -0500 schrieb olcott:
On 7/13/2024 6:26 PM, joes wrote:What are the twins and what is their difference? Do you disagree with >>>>>>>> my tracing?
Can you elaborate? All runtime instances share the same static >>>>>>>>>> code.
I am talking about the inner HHH which is called by the simulated >>>>>>>>>> DDD. That one is, according to you, aborted. Which is wrong, >>>>>>>>>> because by virtue of running the same code, the inner HHH aborts >>>>>>>>>> ITS simulation of DDD calling another HHH.
The directly executed DDD is like the first call of infiniteNot really. Execution does not continue.
recursion. The emulated DDD is just like the second call of infinite >>>>>>> recursion. When the second call of infinite recursion is aborted then >>>>>>> the first call halts.
void Infinite_Recursion()That would be incorrect.
{
Infinite_Recursion();
}
The above *is* infinite recursion.
A program could emulate the above code and simply skip line 3 causing >>>>>>> Infinite_Recursion() to halt.
When DDD calls HHH(DDD) HHH returns.Therefore it does not need to be aborted.
When DDD correctly emulated by HHH the call never returns as is proven >>>>>>> below. The executed DDD() has HHH(DDD) skip this call.I do not see this below.
HHH(DDD) must skip this call itself by terminating the whole DDD >>>>>>> process.How is this detected? Is it also triggered when calling a function in a >>>>>> loop?
Because this HHH does not know its own machine address HHH only sees >>>>>>> that DDD calls a function that causes its first four steps to be >>>>>>> repeated. HHH does not know that this is recursive simulation. To HHH >>>>>>> it looks just like infinite recursion.
New slave_stack at:1038c4 -- create new process context for 1st DDD >>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD) New slave_stack at:14e2ec -- create new process context for >>>>>>> 2nd DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD) Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>> Stopped
You never bothered to answer whether or not you have 100% understanding >>>>> of infinite recursion. If you don't then you can never understand what I >>>>> am saying. If you do that I already proved my point. Here is the proof >>>>> again:
You never bothered to answer my questions (see above).
That only proves that HHH and DDD halt.
This *is* an answer too difficult for you to understand.
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55 push ebp ; housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The trace does not show that HHH returns so there is no basis to
think that HHH is a decider.
The trace shows the data of the executed program of HHH that
does halt.
On 7/17/2024 1:48 AM, Mikko wrote:
On 2024-07-16 15:57:04 +0000, olcott said:
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55 push ebp ; housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The trace does not show that HHH returns so there is no basis to
think that HHH is a decider.
The trace shows the data of the executed program of HHH that
does halt.
It shows some of the data, not all, and in particular, not the halting.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stop running unless aborted.
On 7/17/2024 8:35 AM, Fred. Zwarts wrote:
Op 17.jul.2024 om 15:02 schreef olcott:That is counter-factual
On 7/17/2024 1:48 AM, Mikko wrote:
On 2024-07-16 15:57:04 +0000, olcott said:
The trace does not show that HHH returns so there is no basis to
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored
at:1138cc
[00002172][001138bc][001138c0] 55 push ebp ; >>>>>>> housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; >>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; >>>>>>> housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; >>>>>>> housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>
think that HHH is a decider.
The trace shows the data of the executed program of HHH that
does halt.
It shows some of the data, not all, and in particular, not the halting. >>>>
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stop running unless aborted.
You have shown that you do not understand the semantics of the x86
language.
HHH does abort and halt after N cycles,
When we examine the infinite set of every HHH/DDD pair such that:
HHH1 One step of DDD is correctly emulated by HHH
HHH2 Two steps of DDD are correctly emulated by HHH
HHH3 Three steps of DDD are correctly emulated by HHH
...
HHH∞ The emulation of DDD by HHH never stops
*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.
On 7/17/2024 8:35 AM, Fred. Zwarts wrote:Bla bla.
Op 17.jul.2024 om 15:02 schreef olcott:
On 7/17/2024 1:48 AM, Mikko wrote:
On 2024-07-16 15:57:04 +0000, olcott said:
DDD emulated by HHH according to the semantic meaning of its x86It shows some of the data, not all, and in particular, not theThe trace does not show that HHH returns so there is no basis toThe trace shows the data of the executed program of HHH that does
think that HHH is a decider.
halt.
halting.
instructions never stop running unless aborted.
Then HHH is not a decider.You have shown that you do not understand the semantics of the x86That is counter-factual
language.
HHH does abort and halt after N cycles,
When we examine the infinite set of every HHH/DDD pair such that:DDD only calls HHH, which, being a decider, halts.
HHH1 One step of DDD is correctly emulated by HHH HHH2 Two steps of
DDD are correctly emulated by HHH HHH3 Three steps of DDD are correctly emulated by HHH ...
HHH∞ The emulation of DDD by HHH never stops
DDD emulated by any pure function HHH according to the semantic meaning
of its x86 instructions never stops running unless aborted.
On 7/17/2024 12:18 PM, joes wrote:Only the one that doesn't abort after a finite number of steps doesn't
Am Wed, 17 Jul 2024 08:43:04 -0500 schrieb olcott:I referred to every pure function HHH that can possibly exist.
On 7/17/2024 8:35 AM, Fred. Zwarts wrote:Bla bla.
Op 17.jul.2024 om 15:02 schreef olcott:
On 7/17/2024 1:48 AM, Mikko wrote:
On 2024-07-16 15:57:04 +0000, olcott said:
DDD emulated by HHH according to the semantic meaning of its x86It shows some of the data, not all, and in particular, not theThe trace does not show that HHH returns so there is no basis to >>>>>>>> think that HHH is a decider.The trace shows the data of the executed program of HHH that does >>>>>>> halt.
halting.
instructions never stop running unless aborted.
Then HHH is not a decider.You have shown that you do not understand the semantics of the x86That is counter-factual
language.
HHH does abort and halt after N cycles,
When we examine the infinite set of every HHH/DDD pair such that:DDD only calls HHH, which, being a decider, halts.
HHH1 One step of DDD is correctly emulated by HHH HHH2 Two steps of
DDD are correctly emulated by HHH HHH3 Three steps of DDD are
correctly emulated by HHH ...
HHH∞ The emulation of DDD by HHH never stops
DDD emulated by any pure function HHH according to the semantic
meaning of its x86 instructions never stops running unless aborted.
In each case DDD never makes it past it fourth instruction. This means
that every HHH that halts is correct to reject its DDD as non-halting.
Not every HHH halts.
On 7/17/2024 1:48 AM, Mikko wrote:
On 2024-07-16 15:57:04 +0000, olcott said:
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55 push ebp ; housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>> New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The trace does not show that HHH returns so there is no basis to
think that HHH is a decider.
The trace shows the data of the executed program of HHH that
does halt.
It shows some of the data, not all, and in particular, not the halting.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stop running unless aborted.
On 7/17/2024 8:35 AM, Fred. Zwarts wrote:
Op 17.jul.2024 om 15:02 schreef olcott:That is counter-factual
On 7/17/2024 1:48 AM, Mikko wrote:
On 2024-07-16 15:57:04 +0000, olcott said:
The trace does not show that HHH returns so there is no basis to
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc
[00002172][001138bc][001138c0] 55 push ebp ; housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>> New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>
think that HHH is a decider.
The trace shows the data of the executed program of HHH that
does halt.
It shows some of the data, not all, and in particular, not the halting. >>>>
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stop running unless aborted.
You have shown that you do not understand the semantics of the x86 language. >> HHH does abort and halt after N cycles,
On 7/18/2024 3:00 AM, Mikko wrote:
On 2024-07-17 13:02:31 +0000, olcott said:
On 7/17/2024 1:48 AM, Mikko wrote:
On 2024-07-16 15:57:04 +0000, olcott said:
The trace does not show that HHH returns so there is no basis to
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored
at:1138cc
[00002172][001138bc][001138c0] 55 push ebp ; >>>>>>> housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; >>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; >>>>>>> housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; >>>>>>> housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>
think that HHH is a decider.
The trace shows the data of the executed program of HHH that
does halt.
It shows some of the data, not all, and in particular, not the halting. >>>>
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stop running unless aborted.
The abortion is shown but not any reason to abort.
In other words it is too difficult for you to understand that
the above specifies this execution trace:
*Repeat until aborted*
{
DDD emulated by HHH
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
}
On 7/18/2024 3:00 AM, Mikko wrote:
On 2024-07-17 13:02:31 +0000, olcott said:
On 7/17/2024 1:48 AM, Mikko wrote:
On 2024-07-16 15:57:04 +0000, olcott said:
The trace does not show that HHH returns so there is no basis to
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc
[00002172][001138bc][001138c0] 55 push ebp ; housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>> New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>
think that HHH is a decider.
The trace shows the data of the executed program of HHH that
does halt.
It shows some of the data, not all, and in particular, not the halting. >>>>
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stop running unless aborted.
The abortion is shown but not any reason to abort.
In other words it is too difficult for you to understand that
the above specifies this execution trace:
*Repeat until aborted*
{
DDD emulated by HHH
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
}
On 7/16/2024 1:06 PM, joes wrote:
Am Tue, 16 Jul 2024 08:54:10 -0500 schrieb olcott:
On 7/16/2024 3:23 AM, joes wrote:
Am Mon, 15 Jul 2024 16:03:30 -0500 schrieb olcott:It is not "which state of HHH would repeat forever?"
On 7/15/2024 3:58 PM, joes wrote:Well then, which state of HHH would repeat forever?
Am Mon, 15 Jul 2024 10:52:34 -0500 schrieb olcott:*It had never been which state DOES repeat forever*
On 7/15/2024 9:04 AM, joes wrote:Which state is it that repeats forever?
Am Mon, 15 Jul 2024 07:23:57 -0500 schrieb olcott:Because HHH has seen a repeating state that proves that DDD
On 7/15/2024 3:59 AM, joes wrote:Because it hadn't halted yet?
Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:
At the point that it is aborted it did need to be abortedAny input that must be aborted to prevent the non termination of >>>>>>>>>>> simulating termination analyzer HHH necessarily specifies >>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>> It's just that the input HHH halts and does not need to be >>>>>>>>>> aborted.
correctly emulated by HHH cannot possibly ever stop running unless >>>>>>> aborted.
*It has always been which state WOULD repeat forever if not aborted*
It is: Which state of HHH would repeat forever if not aborted?
Those two are the same, but different to what you said above.
HHH does not repeat forever because it makes sure to stop simulating
anything that does.
I proved that they are not the same in the part that
you skipped.
Infinite_Loop() doesn't even repeat forever because it is aborted.By itself it does.
On 7/19/2024 2:35 AM, Mikko wrote:
On 2024-07-18 14:08:32 +0000, olcott said:
On 7/18/2024 3:00 AM, Mikko wrote:
On 2024-07-17 13:02:31 +0000, olcott said:
On 7/17/2024 1:48 AM, Mikko wrote:
On 2024-07-16 15:57:04 +0000, olcott said:
The trace does not show that HHH returns so there is no basis to >>>>>>>> think that HHH is a decider.
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored >>>>>>>>> at:1138cc
[00002172][001138bc][001138c0] 55 push ebp ;
housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; >>>>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ;
housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; >>>>>>>>> housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>
The trace shows the data of the executed program of HHH that
does halt.
It shows some of the data, not all, and in particular, not the
halting.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stop running unless aborted.
The abortion is shown but not any reason to abort.
In other words it is too difficult for you to understand that
the above specifies this execution trace:
*Repeat until aborted*
{
DDD emulated by HHH
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
}
Your interpretation is wrong, as your interpretations usually are.
Nothing in the trace connects this particular pice of trace to
the abortion. The string "*Repeat untio aborted*" is not a part of
the trace.
*It connects that particular trace to the need to be aborted*
When we examine the infinite set of every HHH/DDD pair such that:
HHH₁ one step of DDD₁ is correctly emulated by HHH₁.
HHH₂ two steps of DDD₂ are correctly emulated by HHH₂.
HHH₃ three steps of DDD₃ are correctly emulated by HHH₃.
...
HHH∞ The emulation of DDD∞ by HHH∞ never stops running.
The above specifies every element of the infinite set of HHH/DDD pairs
where 1 to infinity steps of DDD are correctly emulated by HHH.
On 7/19/2024 2:42 AM, Mikko wrote:
On 2024-07-17 15:02:01 +0000, olcott said:
On 7/16/2024 1:06 PM, joes wrote:
Am Tue, 16 Jul 2024 08:54:10 -0500 schrieb olcott:
On 7/16/2024 3:23 AM, joes wrote:
Am Mon, 15 Jul 2024 16:03:30 -0500 schrieb olcott:It is not "which state of HHH would repeat forever?"
On 7/15/2024 3:58 PM, joes wrote:
Am Mon, 15 Jul 2024 10:52:34 -0500 schrieb olcott:*It had never been which state DOES repeat forever*
On 7/15/2024 9:04 AM, joes wrote:Which state is it that repeats forever?
Am Mon, 15 Jul 2024 07:23:57 -0500 schrieb olcott:Because HHH has seen a repeating state that proves that DDD
On 7/15/2024 3:59 AM, joes wrote:
Am Sun, 14 Jul 2024 22:35:03 -0500 schrieb olcott:
On 7/14/2024 10:02 PM, Mike Terry wrote:
At the point that it is aborted it did need to be aborted >>>>>>>>>> Because it hadn't halted yet?Any input that must be aborted to prevent the non termination of >>>>>>>>>>>>> simulating termination analyzer HHH necessarily specifies >>>>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>>>> It's just that the input HHH halts and does not need to be >>>>>>>>>>>> aborted.
correctly emulated by HHH cannot possibly ever stop running unless >>>>>>>>> aborted.
*It has always been which state WOULD repeat forever if not aborted* >>>>>> Well then, which state of HHH would repeat forever?
It is: Which state of HHH would repeat forever if not aborted?
Those two are the same, but different to what you said above.
HHH does not repeat forever because it makes sure to stop simulating
anything that does.
I proved that they are not the same in the part that
you skipped.
Wat makes you think any part was skipped?
You skipped the part at the bottom.
Infinite_Loop() repeats until aborted.
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about
Infinite_Loop but not about DDD. Possibly because it prefers to
say "no", which is correct about Infinte_loop but not about DDD.
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
On 7/21/2024 4:34 AM, Mikko wrote:Its input just happens to be the same as enclosing computation.
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
If HHH(DDD) abrots its simulation and returns true it is correct as a(b) We know that a decider is not allowed to report on the behavior computation that itself is contained within. Deciders only take finite
halt decider for DDD really halts.
string inputs. They do not take executing processes as inputs. Thus HHH
is not allowed to report on the behavior of this int main() { DDD(); }.
Although embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly correctly report on its ownWhich is the opposite.
behavior because its input does the opposite of whatever it reports embedded_H is only allowed to report on the behavior that its input specifies.
Turing machines never take actual Turing machines as inputs.Trivial.
They only take finite strings as inputs and an actual executing Turing machine is not itself a finite string.
Since we ourselves can directly see that UTM based embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩I see that the input halts.
must abort the simulation of its input otherwise this input would never
stop running we know that the criteria have been met.
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about
Infinite_Loop but not about DDD. Possibly because it prefers to
say "no", which is correct about Infinte_loop but not about DDD.
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior computation that itself is contained within.
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about
Infinite_Loop but not about DDD. Possibly because it prefers to
say "no", which is correct about Infinte_loop but not about DDD.
*Because this is true I don't understand how you are not simply lying* >>>>> int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
Therefore It is not allowed to report on its own behavior.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>
*Because this is true I don't understand how you are not simply lying* >>>>>>> int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct as a >>>>>> halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation,
which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>
*Because this is true I don't understand how you are not simply
lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct as a >>>>>> halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation,
which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
On 7/24/2024 3:52 AM, Fred. Zwarts wrote:
Op 23.jul.2024 om 15:31 schreef olcott:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>
*Because this is true I don't understand how you are not simply >>>>>>>>> lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct >>>>>>>> as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior >>>>>>> computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation, >>>> which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
The x86 code is exactly the same, therefore, the semantics of the x86
does not change, which proves that your claim that HHH works according
to the semantics of the x86 language is not true.
*HHH1(DDD) need not aborted because HHH(DDD) must be aborted*
This is your last chance before I ignore everything you say.
int main()
{
HHH1(DDD);
}
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177
[0000217f] e853f4ffff call 000015d7
[00002184] 83c404 add esp,+04
[00002187] 5d pop ebp
[00002188] c3 ret
Size in bytes:(0018) [00002188]
_main()
[00002197] 55 push ebp
[00002198] 8bec mov ebp,esp
[0000219a] 6877210000 push 00002177
[0000219f] e863f3ffff call 00001507
[000021a4] 83c404 add esp,+04
[000021a7] 33c0 xor eax,eax
[000021a9] 5d pop ebp
[000021aa] c3 ret
Size in bytes:(0020) [000021aa]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00002197][001037fb][00000000] 55 push ebp [00002198][001037fb][00000000] 8bec mov ebp,esp [0000219a][001037f7][00002177] 6877210000 push 00002177 ; push DDD [0000219f][001037f3][000021a4] e863f3ffff call 00001507 ; call HHH1
New slave_stack at:10389f
Begin Local Halt Decider Simulation Execution Trace Stored at:1138a7 [00002177][00113897][0011389b] 55 push ebp [00002178][00113897][0011389b] 8bec mov ebp,esp [0000217a][00113893][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011388f][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:14e2c7
Begin Local Halt Decider Simulation Execution Trace Stored at:15e2cf [00002177][0015e2bf][0015e2c3] 55 push ebp [00002178][0015e2bf][0015e2c3] 8bec mov ebp,esp [0000217a][0015e2bb][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2b7][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:198cef
[00002177][001a8ce7][001a8ceb] 55 push ebp [00002178][001a8ce7][001a8ceb] 8bec mov ebp,esp [0000217a][001a8ce3][00002177] 6877210000 push 00002177 ; push DDD [0000217f][001a8cdf][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002184][00113897][0011389b] 83c404 add esp,+04 [00002187][0011389b][000015bc] 5d pop ebp [00002188][0011389f][0003a980] c3 ret [000021a4][001037fb][00000000] 83c404 add esp,+04 [000021a7][001037fb][00000000] 33c0 xor eax,eax [000021a9][001037ff][00000018] 5d pop ebp [000021aa][00103803][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>
*Because this is true I don't understand how you are not simply lying* >>>>>>> int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct as a >>>>>> halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation,
which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
On 7/24/2024 1:34 PM, Fred. Zwarts wrote:
Op 24.jul.2024 om 15:29 schreef olcott:
On 7/24/2024 3:52 AM, Fred. Zwarts wrote:
Op 23.jul.2024 om 15:31 schreef olcott:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:You are the lying one.
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude >>>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it >>>>>>>>>>>>> only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly >>>>>>>>>>>> about
Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>>>> say "no", which is correct about Infinte_loop but not about >>>>>>>>>>>> DDD.
*Because this is true I don't understand how you are not >>>>>>>>>>> simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input >>>>>>>>>>> or {HHH, emulated DDD and executed DDD} never stop running. >>>>>>>>>>
If HHH(DDD) abrots its simulation and returns true it is
correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the
behavior
computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine >>>>>> is not a finite string. It is an abstract mathematical object without >>>>>> a specification of its exact nature. It could be a set or a finite >>>>>> string. Its exact nature is not relevant to the theory of
computation,
which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not >>>>>> prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
The x86 code is exactly the same, therefore, the semantics of the
x86 does not change, which proves that your claim that HHH works
according to the semantics of the x86 language is not true.
*HHH1(DDD) need not aborted because HHH(DDD) must be aborted*
HHH aborts (whether it must or not is irrelevant, it does).
Therefore there is no need to abort the simulation of HHH.
Good bye liar.
If you care study the code that I just provided
(and don't just ignore this and assume that I must be wrong)
you can see that when DDD is correctly emulated by HHH that
DDD does correctly have different behavior than DDD correctly
emulated by HHH1.
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>
*Because this is true I don't understand how you are not simply >>>>>>>>> lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct >>>>>>>> as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior >>>>>>> computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation, >>>> which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
You say a lot about things that are "empirically proven" and without
exception they are never "proven" at all.
It is empirically proven according to the semantics of the
x86 machine code of DDD that DDD correctly emulated by HHH
has different behavior than DDD correctly emulated by HHH1.
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177
[0000217f] e853f4ffff call 000015d7
[00002184] 83c404 add esp,+04
[00002187] 5d pop ebp
[00002188] c3 ret
Size in bytes:(0018) [00002188]
_main()
[00002197] 55 push ebp
[00002198] 8bec mov ebp,esp
[0000219a] 6877210000 push 00002177
[0000219f] e863f3ffff call 00001507
[000021a4] 83c404 add esp,+04
[000021a7] 33c0 xor eax,eax
[000021a9] 5d pop ebp
[000021aa] c3 ret
Size in bytes:(0020) [000021aa]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00002197][001037fb][00000000] 55 push ebp [00002198][001037fb][00000000] 8bec mov ebp,esp [0000219a][001037f7][00002177] 6877210000 push 00002177 ; push DDD [0000219f][001037f3][000021a4] e863f3ffff call 00001507 ; call HHH1
New slave_stack at:10389f
Begin Local Halt Decider Simulation Execution Trace Stored at:1138a7 [00002177][00113897][0011389b] 55 push ebp [00002178][00113897][0011389b] 8bec mov ebp,esp [0000217a][00113893][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011388f][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:14e2c7
Begin Local Halt Decider Simulation Execution Trace Stored at:15e2cf [00002177][0015e2bf][0015e2c3] 55 push ebp [00002178][0015e2bf][0015e2c3] 8bec mov ebp,esp [0000217a][0015e2bb][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2b7][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:198cef
[00002177][001a8ce7][001a8ceb] 55 push ebp [00002178][001a8ce7][001a8ceb] 8bec mov ebp,esp [0000217a][001a8ce3][00002177] 6877210000 push 00002177 ; push DDD [0000217f][001a8cdf][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002184][00113897][0011389b] 83c404 add esp,+04 [00002187][0011389b][000015bc] 5d pop ebp [00002188][0011389f][0003a980] c3 ret [000021a4][001037fb][00000000] 83c404 add esp,+04 [000021a7][001037fb][00000000] 33c0 xor eax,eax [000021a9][001037ff][00000018] 5d pop ebp [000021aa][00103803][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
Op 25.jul.2024 om 15:56 schreef olcott:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:You are the lying one.
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude >>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it >>>>>>>>>>>> only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>>
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running. >>>>>>>>>
If HHH(DDD) abrots its simulation and returns true it is correct as a >>>>>>>>> halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior >>>>>>>> computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine >>>>> is not a finite string. It is an abstract mathematical object without >>>>> a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation, >>>>> which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not >>>>> prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
You say a lot about things that are "empirically proven" and without exception they are never
"proven" at all.
It is empirically proven according to the semantics of the
x86 machine code of DDD that DDD correctly emulated by HHH
has different behavior than DDD correctly emulated by HHH1.
No, you have proven that the *simulation* is different, not that the behaviour of the simulated
function is different.
The simulations differ, because one is correct and the other one is incorrect.
The one that skips x86 instructions (by aborting) does not follow the semantics of the x86 language.
Its simulation is incomplete and therefore is wrong.
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct as a >>>>>>>> halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior >>>>>>> computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation, >>>> which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
You say a lot about things that are "empirically proven" and without exception they are never
"proven" at all.
It is empirically proven according to the semantics of the
x86 machine code of DDD that DDD correctly emulated by HHH
has different behavior than DDD correctly emulated by HHH1.
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177
[0000217f] e853f4ffff call 000015d7
[00002184] 83c404 add esp,+04
[00002187] 5d pop ebp
[00002188] c3 ret
Size in bytes:(0018) [00002188]
_main()
[00002197] 55 push ebp
[00002198] 8bec mov ebp,esp
[0000219a] 6877210000 push 00002177
[0000219f] e863f3ffff call 00001507
[000021a4] 83c404 add esp,+04
[000021a7] 33c0 xor eax,eax
[000021a9] 5d pop ebp
[000021aa] c3 ret
Size in bytes:(0020) [000021aa]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00002197][001037fb][00000000] 55 push ebp [00002198][001037fb][00000000] 8bec mov ebp,esp [0000219a][001037f7][00002177] 6877210000 push 00002177 ; push DDD [0000219f][001037f3][000021a4] e863f3ffff call 00001507 ; call HHH1
New slave_stack at:10389f
Begin Local Halt Decider Simulation Execution Trace Stored at:1138a7 [00002177][00113897][0011389b] 55 push ebp [00002178][00113897][0011389b] 8bec mov ebp,esp [0000217a][00113893][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011388f][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:14e2c7
Begin Local Halt Decider Simulation Execution Trace Stored at:15e2cf [00002177][0015e2bf][0015e2c3] 55 push ebp [00002178][0015e2bf][0015e2c3] 8bec mov ebp,esp [0000217a][0015e2bb][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2b7][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:198cef
[00002177][001a8ce7][001a8ceb] 55 push ebp [00002178][001a8ce7][001a8ceb] 8bec mov ebp,esp [0000217a][001a8ce3][00002177] 6877210000 push 00002177 ; push DDD [0000217f][001a8cdf][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002184][00113897][0011389b] 83c404 add esp,+04 [00002187][0011389b][000015bc] 5d pop ebp [00002188][0011389f][0003a980] c3 ret
[000021a4][001037fb][00000000] 83c404 add esp,+04 [000021a7][001037fb][00000000] 33c0 xor eax,eax [000021a9][001037ff][00000018] 5d pop ebp [000021aa][00103803][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
You previously claimed that H and H1 behaviours were different as evidence that "copies of
routines" don't necessarily produce the same behaviour as the original routine, due to magical
pathelogical relationships. But if the copies are done properly of course they will produce the
same behaviour, because the x86 language is deterministic. I'm assuming you're not just cheating
and using the mutable global data trick! or similar...
If you care study the code that I just provided
(and don't just ignore this and assume that I must be wrong)
you can see that when DDD is correctly emulated by HHH that
DDD does correctly have different behavior than DDD correctly
emulated by HHH1.
You could have seen this three years ago yet everyone simply
assumes that I must be wrong thus makes sure to ignore the
verified facts that N steps of DDD are correctly emulated by
HHH and M steps of DDD are correctly emulated by HHH1.
They guess that these steps are wrong entirely on the basis
of not bothering to check.
So what had you messed up with H/H1? H and H1 internally both used their /own/ addresses for
comparisons with simulated code addresses. So
They do not do this.
When HHH emulates itself emulating DDD is has no
idea that it is emulating itself. Likewise for when HHH1 emulates DDD
calling HHH(DDD) it does not know that it is not emulating itself.
they are not copies of each other - if they were, H1 would have used H's address (effectively this
address is like a const global variable, and
That is the same as saying the identical twins have the exact same body
not two different bodies in two different locations.
HHH1 and HHH are essentially identical and the only reason why
DDD correctly emulated by HHH has different behavior than DDD
correctly emulated by HHH1 is that DDD does call HHH in recursive
emulation and DDD does not call HHH1 in recursive emulation.
When DDD calls HHH in recursive emulation
(as I have proven that it does**) and DDD does not call HHH1
in recursive simulation (as I have proven that it does not**)
then DDD will have different behavior.
**According to the semantics of the x86 machine code
provided above.
out to be just a case of naff programming on your part - nothing "magical" about pathelogical
relationships between H/D which aren't present for H1/D; just naff coding. [H1 using a different
algorithm meant it never matched H's abort decision, so effectively reverted to UTM behaviour that
simulated (D,D) to completion, including the final return.]
Both HHH and HHH1 use the same algorithm. The input to HHH(DDD)
must be aborted to prevent the non-halting behavior of HHH, and DDD.
The input to HHH1(DDD) need not be aborted because the input to
HHH(DDD) already has been aborted.
The DDD of HHH(DDD) is in the different process state of needing
to be aborted than the DDD of HHH1(DDD) of *not* needing to be
aborted.
DDD needing to be aborted before any DDD has been aborted is
like being hungry before one has eaten.
DDD not needing to be aborted after some DDD has been aborted
is like *not* being hungry after one has eaten.
It's your code so you should be the one to explain anomalies like this at the coding level. Why
/exactly/ does HHH1 produce a different result to HHH?
Why does finite recursion halt and infinite recursion not halt?
HHH does see recursive emulation that will never stop unless aborted.
HHH1 does not see this.
On 7/25/2024 4:03 PM, Mike Terry wrote:
On 25/07/2024 14:56, olcott wrote:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:You are the lying one.
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude >>>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it >>>>>>>>>>>>> only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>>>
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input >>>>>>>>>>> or {HHH, emulated DDD and executed DDD} never stop running. >>>>>>>>>>
If HHH(DDD) abrots its simulation and returns true it is correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior >>>>>>>>> computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine >>>>>> is not a finite string. It is an abstract mathematical object without >>>>>> a specification of its exact nature. It could be a set or a finite >>>>>> string. Its exact nature is not relevant to the theory of computation, >>>>>> which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not >>>>>> prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
You say a lot about things that are "empirically proven" and without exception they are never
"proven" at all.
It is empirically proven according to the semantics of the
x86 machine code of DDD that DDD correctly emulated by HHH
has different behavior than DDD correctly emulated by HHH1.
Perhaps your actual code does behave differently!
OK great, we are making headway.
The questions are:
a) are HHH and HHH1 "identical copies", in the TM machine sense of incorporating
the algorithm of one TM inside another TM? (As Linz incorporates H
inside H^, meaning that the behaviours of H and embedded_H MUST be identical for any
input.)
[You claim HHH and HHH1 /are/ proper copies, and yet give different results for
input (D), which is impossible.]
They are identical in the that have identical x86 machine
code except for the x86 quirk that function calls are to
a relative rather than absolute address. So when HHH calls
the same function that HHH1 calls the machine code is not
the same. The only other case where the machine code of
HHH1 and HHH is not identical is the way for slave instances
of HHH to pass its execution trace up to the master.
Although it seems that I have been correct all along about the
idea that slave instances can pass their execution trace up to
the master without breaking computability this is not the way
it has been actually encoded.
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
b) If the two behaviours HHH/HHH1 are indeed different, WHAT precisely is the coding
difference that accounts for that different behaviour? (Like, with your H/H1 the
difference was that H used H's address as part of its algorithm, while H1 used H1's
address.)
*I have said this about 500 times in the last three years*
DDD calls HHH(DDD) in recursive simulation and does
not call HHH1(DDD) in recursive simulation.
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177
[0000217f] e853f4ffff call 000015d7
[00002184] 83c404 add esp,+04
[00002187] 5d pop ebp
[00002188] c3 ret
Size in bytes:(0018) [00002188]
_main()
[00002197] 55 push ebp
[00002198] 8bec mov ebp,esp
[0000219a] 6877210000 push 00002177
[0000219f] e863f3ffff call 00001507
[000021a4] 83c404 add esp,+04
[000021a7] 33c0 xor eax,eax
[000021a9] 5d pop ebp
[000021aa] c3 ret
Size in bytes:(0020) [000021aa]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00002197][001037fb][00000000] 55 push ebp
[00002198][001037fb][00000000] 8bec mov ebp,esp
[0000219a][001037f7][00002177] 6877210000 push 00002177 ; push DDD
[0000219f][001037f3][000021a4] e863f3ffff call 00001507 ; call HHH1
New slave_stack at:10389f
Begin Local Halt Decider Simulation Execution Trace Stored at:1138a7
[00002177][00113897][0011389b] 55 push ebp
[00002178][00113897][0011389b] 8bec mov ebp,esp
[0000217a][00113893][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][0011388f][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:14e2c7
Begin Local Halt Decider Simulation Execution Trace Stored at:15e2cf
[00002177][0015e2bf][0015e2c3] 55 push ebp
[00002178][0015e2bf][0015e2c3] 8bec mov ebp,esp
[0000217a][0015e2bb][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][0015e2b7][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:198cef
[00002177][001a8ce7][001a8ceb] 55 push ebp
[00002178][001a8ce7][001a8ceb] 8bec mov ebp,esp
[0000217a][001a8ce3][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][001a8cdf][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002184][00113897][0011389b] 83c404 add esp,+04
[00002187][0011389b][000015bc] 5d pop ebp
[00002188][0011389f][0003a980] c3 ret
[000021a4][001037fb][00000000] 83c404 add esp,+04
[000021a7][001037fb][00000000] 33c0 xor eax,eax
[000021a9][001037ff][00000018] 5d pop ebp
[000021aa][00103803][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
that seems to be a (partial) trace of HHH1(D). It's not clear exactly what's happening - for
example, who produces the message "Local Halt Decider: Infinite Recursion Detected Simulation
Stopped"? It might be outer HHH1 or one of the inner HHH's. And what result did HHH1 report?
It is supposed to be the outer most (thus directly executed) HHH.
And more to the point what did HHH(D) do, and what is the difference?
*I have said this about 500 times in the last three years*
DDD calls HHH(DDD) in recursive simulation and does
not call HHH1(DDD) in recursive simulation.
When a function unconditionally calls itself this is infinite
recursion.
When a function unconditionally calls its own simulator this is
infinite recursive simulation. HHH sees this as infinite recursion
because HHH does not know that DDD is calling itself.
On 7/25/2024 11:06 AM, Mike Terry wrote:
On 25/07/2024 15:27, Fred. Zwarts wrote:
Op 25.jul.2024 om 15:56 schreef olcott:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:You are the lying one.
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude >>>>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it >>>>>>>>>>>>>> only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly >>>>>>>>>>>>> about
Infinite_Loop but not about DDD. Possibly because it >>>>>>>>>>>>> prefers to
say "no", which is correct about Infinte_loop but not about >>>>>>>>>>>>> DDD.
*Because this is true I don't understand how you are not >>>>>>>>>>>> simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input >>>>>>>>>>>> or {HHH, emulated DDD and executed DDD} never stop running. >>>>>>>>>>>
If HHH(DDD) abrots its simulation and returns true it is >>>>>>>>>>> correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the >>>>>>>>>> behavior
computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing >>>>>>>> Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing
machine
is not a finite string. It is an abstract mathematical object
without
a specification of its exact nature. It could be a set or a finite >>>>>>> string. Its exact nature is not relevant to the theory of
computation,
which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not >>>>>>> prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
You say a lot about things that are "empirically proven" and
without exception they are never "proven" at all.
It is empirically proven according to the semantics of the
x86 machine code of DDD that DDD correctly emulated by HHH
has different behavior than DDD correctly emulated by HHH1.
No, you have proven that the *simulation* is different, not that the
behaviour of the simulated function is different.
The simulations differ, because one is correct and the other one is
incorrect.
The one that skips x86 instructions (by aborting) does not follow the
semantics of the x86 language. Its simulation is incomplete and
therefore is wrong.
But the point is that PO alleges HHH and HHH1 are identical copies.
If that were the case, why would one abort while the other does not?
I explain that most completely by providing the full execution trace.
I have done that many times over the last three years. You are so
sure that I must be incorrect that you don't bother to examine this
trace that has consistently proven that I am correct for three years.
The answer is obviously that they are NOT proper copies, just like
PO's earlier H/H1. Or PO has cheated with misuse of global variables
or similar. (PO has previously insisted these functions are "pure",
but that is probably his own wishful thinking rather than fact... so
who knows?)
If you understand the semantics of the x86 language then you
can see that N instructions of DDD are correctly emulated by
HHH.
You can also see by the repeating state of DDD correctly
emulated by HHH that HHH must abort it emulation of DDD or
DDD and HHH would never terminate.
From understanding the semantics of the x86 language you can
also see that after HHH(DDD) has aborted the emulation of its
input that the correct emulation of a different process instance
of DDD by HHH1 does terminate normally.
I would like PO to come clean and explain why HHH1 behaves differently
to HHH, in terms of the actual code. Instead he just says stuff like
"HHH1 does not /need/ to abort because [blah blah]", as though he
believes program behaviour is determined by their "needs" rather than
by their coding.
This is a perfectly "concrete" problem - two bits of code behave
differently; why? Even PO should be able to properly understand (and
investigate by himself) the answer to this question. Instead he falls
back on nonsense "magical" explanations based on the programs
"understanding their needs" or "seeing things" they obviously /don't/
"see" [either literally or figuratively], and somehow changing their
behaviour as a result.
Mike.
typedef void (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH1(DDD);
}
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177
[0000217f] e853f4ffff call 000015d7
[00002184] 83c404 add esp,+04
[00002187] 5d pop ebp
[00002188] c3 ret
Size in bytes:(0018) [00002188]
_main()
[00002197] 55 push ebp
[00002198] 8bec mov ebp,esp
[0000219a] 6877210000 push 00002177
[0000219f] e863f3ffff call 00001507
[000021a4] 83c404 add esp,+04
[000021a7] 33c0 xor eax,eax
[000021a9] 5d pop ebp
[000021aa] c3 ret
Size in bytes:(0020) [000021aa]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00002197][001037fb][00000000] 55 push ebp [00002198][001037fb][00000000] 8bec mov ebp,esp [0000219a][001037f7][00002177] 6877210000 push 00002177 ; push DDD [0000219f][001037f3][000021a4] e863f3ffff call 00001507 ; call HHH1
New slave_stack at:10389f
Begin Local Halt Decider Simulation Execution Trace Stored at:1138a7 [00002177][00113897][0011389b] 55 push ebp [00002178][00113897][0011389b] 8bec mov ebp,esp [0000217a][00113893][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011388f][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:14e2c7
Begin Local Halt Decider Simulation Execution Trace Stored at:15e2cf [00002177][0015e2bf][0015e2c3] 55 push ebp [00002178][0015e2bf][0015e2c3] 8bec mov ebp,esp [0000217a][0015e2bb][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2b7][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:198cef
[00002177][001a8ce7][001a8ceb] 55 push ebp [00002178][001a8ce7][001a8ceb] 8bec mov ebp,esp [0000217a][001a8ce3][00002177] 6877210000 push 00002177 ; push DDD [0000217f][001a8cdf][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002184][00113897][0011389b] 83c404 add esp,+04 [00002187][0011389b][000015bc] 5d pop ebp [00002188][0011389f][0003a980] c3 ret [000021a4][001037fb][00000000] 83c404 add esp,+04 [000021a7][001037fb][00000000] 33c0 xor eax,eax [000021a9][001037ff][00000018] 5d pop ebp [000021aa][00103803][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
I just proved that DDD correctly emulated by HHH does
have non-terminating behavior that HHH aborts and DDD
correctly emulated by HHH1 does terminate.
If you "disagree" with this proof on the basis that
(a) You do not know the x86 language well enough
(b) Did not bother to carefully examine the steps
then your "disagreement" would be a reckless disregard of the truth.
2 : a reckless lack of attention to the truth that misleads or deceives another https://dictionary.findlaw.com/definition/reckless-disregard-of-the-truth.html
On 7/25/2024 10:35 PM, Mike Terry wrote:I don't see how the outside use of a function can influence it.
On 26/07/2024 01:53, olcott wrote:
On 7/25/2024 4:03 PM, Mike Terry wrote:
On 25/07/2024 14:56, olcott wrote:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
(b) We know that a decider is not allowed to report on the >>>>>>>>>>> behavior computation that itself is contained within.No, we don't. There is no such prohibition.
Therefore It is not allowed to report on its own behavior.Anyway, that does not follow. The theory of Turing machines does >>>>>>>> not prohibit anything.
In this case we have two x86utm machines that are identical except >>>>>>> that DDD calls HHH and DDD does not call HHH1.
Thanks, Mike, for the detailed analysis.OK great, we are making headway.It is empirically proven according to the semantics of the x86Perhaps your actual code does behave differently!
machine code of DDD that DDD correctly emulated by HHH has different >>>>> behavior than DDD correctly emulated by HHH1.
How is the trace passed?The questions are:
a) are HHH and HHH1 "identical copies", in the TM machine sense of
incorporating
the algorithm of one TM inside another TM? (As Linz
incorporates H inside H^, meaning that the behaviours of H
and embedded_H MUST be identical for any input.)
[You claim HHH and HHH1 /are/ proper copies, and yet give
different results for input (D), which is impossible.]
They are identical in the that have identical x86 machine code except
for the x86 quirk that function calls are to a relative rather than
absolute address. So when HHH calls the same function that HHH1 calls
the machine code is not the same. The only other case where the
machine code of HHH1 and HHH is not identical is the way for slave
instances of HHH to pass its execution trace up to the master.
I bet my nonexistent soul that there are bugs left in libx86. ApartThe relative addressing is to be expected as a difference, and is fineThere never is any actual bug with the simulation.
provided the actual target is the same. [Which it seems to be...]
The whole thing with the slave instances might well be where the bug
lies! That would be slightly funny, as I pointed out that problem on
some completely unrelated post, and this could be a follow-on issue
where it has caused observable misbehavior in the code. (Needs a bit
more investigation...)
How is it coded?Although it seems that I have been correct all along about the idea
that slave instances can pass their execution trace up to the master
without breaking computability this is not the way it has been
actually encoded.
But whyyy?The problem is that the code itself has already answered this questionYou may have said it 500 times, but it doesn't answer my question!b) If the two behaviours HHH/HHH1 are indeed different, WHATDDD calls HHH(DDD) in recursive simulation and does not call HHH1(DDD)
precisely is the coding
difference that accounts for that different behaviour?
(Like, with your H/H1 the
difference was that H used H's address as part of its
algorithm, while H1 used H1's address.)
in recursive simulation.
500 times in three years and people just ignore it.
When DDD emulated by HHH calls HHH(DDD) this call cannot possibly
return. When DDD emulated by HHH1 calls HHH(DDD) this call DOES return.
No, 2+3 = 3+2. You have two copies of the same function that behave differently. How is that possible?Look, here is a rough sketch of the two traces side by side just doneAnd by your same reasoning 2 + 3 shouldn't = 5.
by hand:
So HHH/HHH1 behaviour is different, but shouldn't be if HHH1 is a
correct copy of HHH.
Try to find one x86 instruction that is emulated incorrectly.Can you please point us to where they diverge?
_DDD()I thought HHH aborts?
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177 ; push DDD
[0000217f] e853f4ffff call 000015d7 ; call HHH
[00002184] 83c404 add esp,+04
[00002187] 5d pop ebp
[00002188] c3 ret
Maybe you think that push 00002177 should jmp 00002188?
Well that's correct [lines 6,9,12] - but it's irrelevant, because IT'SIn other words you are totally incompetent with the x86 language or
THE SAME ON BOTH SIDES ABOVE. Both HHH/HHH1 simulate DDD [line 4] and
BOTH of those simulations call HHH in recursive simulation, so BOTH
SIDES MUST HAVE THE SAME BEHAVIOUR.
disagree with this language.
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177 ; push DDD
[0000217f] e853f4ffff call 000015d7 ; call HHH
DDD emulated by HHH endlessly repeats as if it was infinite recursion
such that DDD emulated by HHH cannot possibly reach past 0000217f no
matter what HHH does.
On 7/24/2024 3:57 AM, Mikko wrote:
On 2024-07-23 13:31:35 +0000, olcott said:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct as a >>>>>>>> halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior >>>>>>> computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation, >>>> which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
That DDD calls HHH and DDD does not call HHH1 is not a difference
between two unnamed turing machines.
The same thing happens at the Peter Linz Turing Machine level
I will provide that more difficult example if and only if you
prove that you understand this one.
On 7/25/2024 10:35 PM, Mike Terry wrote:
On 26/07/2024 01:53, olcott wrote:
On 7/25/2024 4:03 PM, Mike Terry wrote:
On 25/07/2024 14:56, olcott wrote:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:You are the lying one.
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude >>>>>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it >>>>>>>>>>>>>>> only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly >>>>>>>>>>>>>> about
Infinite_Loop but not about DDD. Possibly because it >>>>>>>>>>>>>> prefers to
say "no", which is correct about Infinte_loop but not >>>>>>>>>>>>>> about DDD.
*Because this is true I don't understand how you are not >>>>>>>>>>>>> simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input >>>>>>>>>>>>> or {HHH, emulated DDD and executed DDD} never stop running. >>>>>>>>>>>>
If HHH(DDD) abrots its simulation and returns true it is >>>>>>>>>>>> correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the >>>>>>>>>>> behavior
computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs. >>>>>>>>> They only take finite strings as inputs and an actual executing >>>>>>>>> Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing
machine
is not a finite string. It is an abstract mathematical object
without
a specification of its exact nature. It could be a set or a finite >>>>>>>> string. Its exact nature is not relevant to the theory of
computation,
which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does >>>>>>>> not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input >>>>>>>> or as a part of its input it can also take its own description. >>>>>>>> Every Turing machine can be given its own description as input >>>>>>>> but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
You say a lot about things that are "empirically proven" and
without exception they are never "proven" at all.
It is empirically proven according to the semantics of the
x86 machine code of DDD that DDD correctly emulated by HHH
has different behavior than DDD correctly emulated by HHH1.
Perhaps your actual code does behave differently!
OK great, we are making headway.
The questions are:
a) are HHH and HHH1 "identical copies", in the TM machine sense of
incorporating
the algorithm of one TM inside another TM? (As Linz
incorporates H
inside H^, meaning that the behaviours of H and embedded_H MUST >>>> be identical for any
input.)
[You claim HHH and HHH1 /are/ proper copies, and yet give
different results for
input (D), which is impossible.]
They are identical in the that have identical x86 machine
code except for the x86 quirk that function calls are to
a relative rather than absolute address. So when HHH calls
the same function that HHH1 calls the machine code is not
the same. The only other case where the machine code of
HHH1 and HHH is not identical is the way for slave instances
of HHH to pass its execution trace up to the master.
The relative addressing is to be expected as a difference, and is fine
provided the actual target is the same. [Which it seems to be...]
The whole thing with the slave instances might well be where the bug
lies! That would be slightly funny, as I pointed out that problem on
some completely unrelated post, and this could be a follow-on issue
where it has caused observable misbehavior in the code. (Needs a bit
more investigation...)
There never is any actual bug with the simulation.
My system uses libx86emu with decades of development
experience. The current maintainer upgraded the system
to operate in 32-bit mode for me.
Whether or not my implementation of the decider portion is a
computable function is moot as long as some code can see the
repeating state behavior pattern that we can all see where
the first four lines of DDD emulated by HHH repeat.
Although it seems that I have been correct all along about the
idea that slave instances can pass their execution trace up to
the master without breaking computability this is not the way
it has been actually encoded.
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
b) If the two behaviours HHH/HHH1 are indeed different, WHAT
precisely is the coding
difference that accounts for that different behaviour? (Like, >>>> with your H/H1 the
difference was that H used H's address as part of its
algorithm, while H1 used H1's
address.)
*I have said this about 500 times in the last three years*
DDD calls HHH(DDD) in recursive simulation and does
not call HHH1(DDD) in recursive simulation.
You may have said it 500 times, but it doesn't answer my question!
The problem is that the code itself has already answered this
question 500 times in three years and people just ignore it.
Blah, Blah , Blah I know you must be wrong so I will not look
at anything that you say.
When DDD emulated by HHH calls HHH(DDD) this call cannot possibly
return. When DDD emulated by HHH1 calls HHH(DDD) this call DOES return.
I have showed this 500 times with H(D,D) and H1(D,D) or with
H(P,P) and H1(P,P).
Look, here is a rough sketch of the two traces side by side just done
by hand:
[VIEW WITH FIXED FONT!!]
HHH1 (DDD) HHH (DDD) >> -----------------------------------------------------------------
1 main () main ()
2 HHH1 (DDD) HHH (DDD) >> 4 Simulate (DDD) Simulate (DDD)
5 | DDD() | DDD()
6 | HHH (DDD) | HHH (DDD)
7 | Simulate (DDD) | Simulate (DDD)
8 | | DDD() | DDD()
9 | | HHH (DDD) | HHH (DDD)
10 | | Simulate (DDD) Abort
11 | | DDD() ret 0 >> 12 | | HHH (DDD) ret 0
13 | Abort
14 | ret 0
15 | ret
16 ret 1
17 ret 0
So HHH/HHH1 behaviour is different, but shouldn't be if HHH1 is a
correct copy of HHH.
And by your same reasoning 2 + 3 shouldn't = 5.
Try to find one x86 instruction that is emulated incorrectly.
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177 ; push DDD
[0000217f] e853f4ffff call 000015d7 ; call HHH
[00002184] 83c404 add esp,+04
[00002187] 5d pop ebp
[00002188] c3 ret
Maybe you think that push 00002177 should jmp 00002188?
Your explanation makes NO SENSE AT ALL. It's just one of those things
you repeat 500 times, and nobody bothers to call you out.
When people disagree with the semantics of the x86 instructions
that is no actual rebuttal at all and merely proves their own
technical incompetence.
You say DDD calls HHH(DDD) in recursive simulation and does not call
HHH1 in recursive simulation.
Right and 2 + 3 = 5.
Well that's correct [lines 6,9,12] - but it's irrelevant, because IT'S
THE SAME ON BOTH SIDES ABOVE. Both HHH/HHH1 simulate DDD [line 4] and
BOTH of those simulations call HHH in recursive simulation, so BOTH
SIDES MUST HAVE THE SAME BEHAVIOUR.
In other words you are totally incompetent with the x86
language or disagree with this language.
when the instruction says mov eax, 5
and you "interpret" that add edx, 10 YOU ARE WRONG
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177 ; push DDD
[0000217f] e853f4ffff call 000015d7 ; call HHH
DDD emulated by HHH endlessly repeats as if it was infinite
recursion such that DDD emulated by HHH cannot possibly reach
past 0000217f no matter what HHH does.
*This version is better annotated*
Because I have repeated this same point 500 times in the last three
years...
On 7/26/2024 3:50 AM, joes wrote:
Am Thu, 25 Jul 2024 23:25:59 -0500 schrieb olcott:
On 7/25/2024 10:35 PM, Mike Terry wrote:I don't see how the outside use of a function can influence it.
On 26/07/2024 01:53, olcott wrote:
On 7/25/2024 4:03 PM, Mike Terry wrote:
On 25/07/2024 14:56, olcott wrote:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
(b) We know that a decider is not allowed to report on the >>>>>>>>>>>>> behavior computation that itself is contained within. >>>>>>>>>>>> No, we don't. There is no such prohibition.
Therefore It is not allowed to report on its own behavior. >>>>>>>>>> Anyway, that does not follow. The theory of Turing machines does >>>>>>>>>> not prohibit anything.
In this case we have two x86utm machines that are identical except >>>>>>>>> that DDD calls HHH and DDD does not call HHH1.
Thanks, Mike, for the detailed analysis.OK great, we are making headway.It is empirically proven according to the semantics of the x86Perhaps your actual code does behave differently!
machine code of DDD that DDD correctly emulated by HHH has different >>>>>>> behavior than DDD correctly emulated by HHH1.
How is the trace passed?The questions are:
a) are HHH and HHH1 "identical copies", in the TM machine sense of >>>>>> incorporating
the algorithm of one TM inside another TM? (As Linz
incorporates H inside H^, meaning that the behaviours of H >>>>>> and embedded_H MUST be identical for any input.)
[You claim HHH and HHH1 /are/ proper copies, and yet give >>>>>> different results for input (D), which is impossible.]
They are identical in the that have identical x86 machine code except >>>>> for the x86 quirk that function calls are to a relative rather than
absolute address. So when HHH calls the same function that HHH1 calls >>>>> the machine code is not the same. The only other case where the
machine code of HHH1 and HHH is not identical is the way for slave
instances of HHH to pass its execution trace up to the master.
That does not matter. As long as we understand that Mike is correct
about this:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
Then we know that HHH can see the the first four instructions of
DDD have no conditional code that could prevent them from endlessly repeating.
This is the exact same pattern with Infinite_Recursion()
where there are no conditional branch instructions that
would prevent the first three instructions of
Infinite_Recursion() from endlessly repeating.
_Infinite_Recursion()
[0000215a] 55 push ebp
[0000215b] 8bec mov ebp,esp
[0000215d] e8f8ffffff call 0000215a ; recursive call
[00002162] 5d pop ebp
[00002163] c3 ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation Execution Trace Stored at:113934 Decide_Halting_HH:1
[0000215a][00113924][00113928] 55 push ebp [0000215b][00113924][00113928] 8bec mov ebp,esp [0000215d][00113920][00002162] e8f8ffffff call 0000215a [0000215a][0011391c][00113924] 55 push ebp [0000215b][0011391c][00113924] 8bec mov ebp,esp [0000215d][00113918][00002162] e8f8ffffff call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The relative addressing is to be expected as a difference, and is fine >>>> provided the actual target is the same. [Which it seems to be...]There never is any actual bug with the simulation.
The whole thing with the slave instances might well be where the bug
lies! That would be slightly funny, as I pointed out that problem on >>>> some completely unrelated post, and this could be a follow-on issue
where it has caused observable misbehavior in the code. (Needs a bit >>>> more investigation...)
I bet my nonexistent soul that there are bugs left in libx86. Apart
from that, your use of the library may be buggy.
That is irrelevant. We can see by the execution trace of
DDD emulated by HHH that this emulation does precisely
match the semantics of the first four x86 machine language
instructions of DDD.
We can also see that DDD emulated by HHH1 does precisely
match the semantics of the x86 machine language instructions
of DDD.
People have been saying that I am wrong about the for three
years never bothering to notice that I have always proved
that I am correct about this.
On 7/26/2024 3:50 AM, joes wrote:True, but HHH does have a conditional abort. It should be coded to
Am Thu, 25 Jul 2024 23:25:59 -0500 schrieb olcott:
On 7/25/2024 10:35 PM, Mike Terry wrote:
On 26/07/2024 01:53, olcott wrote:
On 7/25/2024 4:03 PM, Mike Terry wrote:
On 25/07/2024 14:56, olcott wrote:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
I don't see how the outside use of a function can influence it.In this case we have two x86utm machines that are identical
except that DDD calls HHH and DDD does not call HHH1.
Then we know that HHH can see the the first four instructions of DDD
have no conditional code that could prevent them from endlessly
repeating.
But not what comes afterwards, and HHH makes the incorrect assumptionThat is irrelevant. We can see by the execution trace of DDD emulated byI bet my nonexistent soul that there are bugs left in libx86. ApartThe relative addressing is to be expected as a difference, and isThere never is any actual bug with the simulation.
fine provided the actual target is the same. [Which it seems to
be...]
The whole thing with the slave instances might well be where the bug
lies! That would be slightly funny, as I pointed out that problem on >>>> some completely unrelated post, and this could be a follow-on issue
where it has caused observable misbehavior in the code. (Needs a bit >>>> more investigation...)
from that, your use of the library may be buggy.
HHH that this emulation does precisely match the semantics of the first
four x86 machine language instructions of DDD.
How can the same code return when called once and not another time?The problem is that the code itself has already answered this questionYou may have said it 500 times, but it doesn't answer my question!b) If the two behaviours HHH/HHH1 are indeed different, WHATDDD calls HHH(DDD) in recursive simulation and does not call
precisely is the coding
difference that accounts for that different behaviour?
(Like, with your H/H1 the difference was that H used H's >>>>>> address as part of its algorithm, while H1 used H1's
address.)
HHH1(DDD)
in recursive simulation.
500 times in three years and people just ignore it.
When DDD emulated by HHH calls HHH(DDD) this call cannot possibly
return. When DDD emulated by HHH1 calls HHH(DDD) this call DOES
return.
No, 2+3 = 3+2. You have two copies of the same function that behaveLook, here is a rough sketch of the two traces side by side just doneAnd by your same reasoning 2 + 3 shouldn't = 5.
by hand:
So HHH/HHH1 behaviour is different, but shouldn't be if HHH1 is a
correct copy of HHH.
differently. How is that possible?
Try to find one x86 instruction that is emulated incorrectly.Can you please point us to where they diverge?
On 7/26/2024 9:02 AM, Fred. Zwarts wrote:
Op 26.jul.2024 om 15:54 schreef olcott:
On 7/26/2024 3:50 AM, joes wrote:
Am Thu, 25 Jul 2024 23:25:59 -0500 schrieb olcott:
On 7/25/2024 10:35 PM, Mike Terry wrote:I don't see how the outside use of a function can influence it.
On 26/07/2024 01:53, olcott wrote:
On 7/25/2024 4:03 PM, Mike Terry wrote:
On 25/07/2024 14:56, olcott wrote:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
(b) We know that a decider is not allowed to report on the >>>>>>>>>>>>>>> behavior computation that itself is contained within. >>>>>>>>>>>>>> No, we don't. There is no such prohibition.
Therefore It is not allowed to report on its own behavior. >>>>>>>>>>>> Anyway, that does not follow. The theory of Turing machines >>>>>>>>>>>> doesnot prohibit anything.
In this case we have two x86utm machines that are identical >>>>>>>>>>> except
that DDD calls HHH and DDD does not call HHH1.
Thanks, Mike, for the detailed analysis.OK great, we are making headway.It is empirically proven according to the semantics of the x86 >>>>>>>>> machine code of DDD that DDD correctly emulated by HHH hasPerhaps your actual code does behave differently!
different
behavior than DDD correctly emulated by HHH1.
How is the trace passed?The questions are:
a) are HHH and HHH1 "identical copies", in the TM machine sense of >>>>>>>> incorporating
the algorithm of one TM inside another TM? (As Linz >>>>>>>> incorporates H inside H^, meaning that the behaviours of H >>>>>>>> and embedded_H MUST be identical for any input.)
[You claim HHH and HHH1 /are/ proper copies, and yet give >>>>>>>> different results for input (D), which is impossible.]
They are identical in the that have identical x86 machine code
except
for the x86 quirk that function calls are to a relative rather than >>>>>>> absolute address. So when HHH calls the same function that HHH1
calls
the machine code is not the same. The only other case where the >>>>>>> machine code of HHH1 and HHH is not identical is the way for slave >>>>>>> instances of HHH to pass its execution trace up to the master.
That does not matter. As long as we understand that Mike is correct
about this:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
Then we know that HHH can see the the first four instructions of
DDD have no conditional code that could prevent them from endlessly
repeating.
This is the exact same pattern with Infinite_Recursion()
where there are no conditional branch instructions that
would prevent the first three instructions of
Infinite_Recursion() from endlessly repeating.
_Infinite_Recursion()
[0000215a] 55 push ebp
[0000215b] 8bec mov ebp,esp
[0000215d] e8f8ffffff call 0000215a ; recursive call
[00002162] 5d pop ebp
[00002163] c3 ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation Execution Trace Stored at:113934 >>> Decide_Halting_HH:1
[0000215a][00113924][00113928] 55 push ebp
[0000215b][00113924][00113928] 8bec mov ebp,esp
[0000215d][00113920][00002162] e8f8ffffff call 0000215a
[0000215a][0011391c][00113924] 55 push ebp
[0000215b][0011391c][00113924] 8bec mov ebp,esp
[0000215d][00113918][00002162] e8f8ffffff call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The relative addressing is to be expected as a difference, and isThere never is any actual bug with the simulation.
fine
provided the actual target is the same. [Which it seems to be...]
The whole thing with the slave instances might well be where the bug >>>>>> lies! That would be slightly funny, as I pointed out that problem on >>>>>> some completely unrelated post, and this could be a follow-on issue >>>>>> where it has caused observable misbehavior in the code. (Needs a bit >>>>>> more investigation...)
I bet my nonexistent soul that there are bugs left in libx86. Apart
from that, your use of the library may be buggy.
That is irrelevant. We can see by the execution trace of
DDD emulated by HHH that this emulation does precisely
match the semantics of the first four x86 machine language
instructions of DDD.
We can also see that DDD emulated by HHH1 does precisely
match the semantics of the x86 machine language instructions
of DDD.
People have been saying that I am wrong about the for three
years never bothering to notice that I have always proved
that I am correct about this.
But you have been told that it is not enough to simulate only four
instructions of a halting program. The simulation is aborted when the
simulated HHH has only one cycle to go.
*This is merely your own software engineering incompetence*
Unless the outermost HHH (having seen the longest execution
trace sequence) aborts its own simulation of DDD then none of
them, ever abort.
On 7/26/2024 10:13 AM, joes wrote:Fuck your insults. I know that. Like you say, if the first one aborts,
Am Fri, 26 Jul 2024 08:54:32 -0500 schrieb olcott:
On 7/26/2024 3:50 AM, joes wrote:
Am Thu, 25 Jul 2024 23:25:59 -0500 schrieb olcott:
On 7/25/2024 10:35 PM, Mike Terry wrote:
On 26/07/2024 01:53, olcott wrote:
On 7/25/2024 4:03 PM, Mike Terry wrote:
On 25/07/2024 14:56, olcott wrote:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
That it is beyond your technical competence to understand that unlessThen we know that HHH can see the the first four instructions of DDDTrue, but HHH does have a conditional abort. It should be coded to
have no conditional code that could prevent them from endlessly
repeating.
recognise that, because one knows that at compile time already.
But not what comes afterwards, and HHH makes the incorrect assumptionThat is irrelevant. We can see by the execution trace of DDD emulatedI bet my nonexistent soul that there are bugs left in libx86. ApartThe whole thing with the slave instances might well be where theThere never is any actual bug with the simulation.
bug lies! That would be slightly funny, as I pointed out that
problem on some completely unrelated post, and this could be a
follow-on issue where it has caused observable misbehavior in the
code. (Needs a bit more investigation...)
from that, your use of the library may be buggy.
by HHH that this emulation does precisely match the semantics of the
first four x86 machine language instructions of DDD.
that another instance of itself wouldn't abort.
the first HHH aborts then none of them do is less than no rebuttal at
all.
On 7/26/2024 3:45 AM, Mikko wrote:
On 2024-07-24 13:33:55 +0000, olcott said:
On 7/24/2024 3:57 AM, Mikko wrote:
On 2024-07-23 13:31:35 +0000, olcott said:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:You are the lying one.
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude >>>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it >>>>>>>>>>>>> only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>>>
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input >>>>>>>>>>> or {HHH, emulated DDD and executed DDD} never stop running. >>>>>>>>>>
If HHH(DDD) abrots its simulation and returns true it is correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior >>>>>>>>> computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine >>>>>> is not a finite string. It is an abstract mathematical object without >>>>>> a specification of its exact nature. It could be a set or a finite >>>>>> string. Its exact nature is not relevant to the theory of computation, >>>>>> which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not >>>>>> prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
That DDD calls HHH and DDD does not call HHH1 is not a difference
between two unnamed turing machines.
The same thing happens at the Peter Linz Turing Machine level
I will provide that more difficult example if and only if you
prove that you understand this one.
However, Peter Linz does not call taht same thing a difference.
We can call everything "late for dinner" with a unique integer
index and the properties that I assert exist still exist.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
Two complete simulations show a pair of identical TMD's are
simulating a pair of identical inputs. We can see this thus
proving recursive simulation.
When embedded_H is accountable for the behavior of its
input and not accountable for the behavior of the
computation that it is contained within then embedded_H
is necessarily correct to transition to its own Ĥ.qn state.
On 7/27/2024 2:21 AM, Mikko wrote:
On 2024-07-26 14:08:11 +0000, olcott said:
On 7/26/2024 3:45 AM, Mikko wrote:
On 2024-07-24 13:33:55 +0000, olcott said:
On 7/24/2024 3:57 AM, Mikko wrote:
On 2024-07-23 13:31:35 +0000, olcott said:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:You are the lying one.
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude >>>>>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it >>>>>>>>>>>>>>> only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>>>>>
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input >>>>>>>>>>>>> or {HHH, emulated DDD and executed DDD} never stop running. >>>>>>>>>>>>
If HHH(DDD) abrots its simulation and returns true it is correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior >>>>>>>>>>> computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs. >>>>>>>>> They only take finite strings as inputs and an actual executing >>>>>>>>> Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine >>>>>>>> is not a finite string. It is an abstract mathematical object without >>>>>>>> a specification of its exact nature. It could be a set or a finite >>>>>>>> string. Its exact nature is not relevant to the theory of computation, >>>>>>>> which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not >>>>>>>> prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input >>>>>>>> or as a part of its input it can also take its own description. >>>>>>>> Every Turing machine can be given its own description as input >>>>>>>> but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
That DDD calls HHH and DDD does not call HHH1 is not a difference
between two unnamed turing machines.
The same thing happens at the Peter Linz Turing Machine level
I will provide that more difficult example if and only if you
prove that you understand this one.
However, Peter Linz does not call taht same thing a difference.
We can call everything "late for dinner" with a unique integer
index and the properties that I assert exist still exist.
That you can say all sorts stupid things does not mean that it be a
good idea to do so.
Some of the properties you assert exsit actually do exist, some don't.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is merely simplified syntax for the top of page 3 https://www.liarparadox.org/Linz_Proof.pdf
The above is the whole original Linz proof.
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
You are supposed to evaluate the above as a contiguous
sequence of moves such that non-halting behavior is
identified.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 44:11:57 |
| Calls: | 9,800 |
| Calls today: | 2 |
| Files: | 13,752 |
| Messages: | 6,189,748 |