On 7/27/2024 1:54 AM, Mikko wrote:
On 2024-07-26 13:58:54 +0000, olcott said:
On 7/26/2024 3:05 AM, Mikko wrote:
No, it isn't. Abortion of simulation is a deviation form x86 macine
language semantics. What I ask about does not deviate more.
In other words you are saying that it is absolutely impossible
to make an x86 program that is an x86 emulator that correctly
emulates a finite number of instructions of non-terminating
input x86 machine code.
You are lying again. That is not the same in other words, and I am
not saying what you falsely claim.
I am not lying I am paraphrasing so that we can come to a mutual understanding.
If a simulator correctly simulates a finite number of instructions
where x86 program specifies an execution of an infinite number of
instructions then the simulation deviates from x86 semantics at the
point where the simulation stops but the x86 semantics specify
countinuation.
In other words you believe that instead of recognizing a
non-halting behavior pattern, then aborting the simulation
and rejecting the input as non-halting the termination
analyzer should just get stuck in recursive simulation?
The violates the design requirement that a termination
analyzer must halt so that it wrong.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/27/2024 9:28 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:54 AM, Mikko wrote:
If a simulator correctly simulates a finite number of instructions
where x86 program specifies an execution of an infinite number of
instructions then the simulation deviates from x86 semantics at the
point where the simulation stops but the x86 semantics specify
countinuation.
In other words you believe that instead of recognizing a
non-halting behavior pattern, then aborting the simulation
and rejecting the input as non-halting the termination
analyzer should just get stuck in recursive simulation?
You're doing it again. "In other words" is here a lie; you've just
replaced Mikko's words with something very different.
He just said that the simulation of a non-terminating input
is incorrect unless it is simulated forever.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/27/2024 1:54 AM, Mikko wrote:
On 2024-07-26 13:58:54 +0000, olcott said:
On 7/26/2024 3:05 AM, Mikko wrote:
On 2024-07-24 13:38:08 +0000, olcott said:
On 7/24/2024 4:01 AM, Mikko wrote:
On 2024-07-23 14:41:11 +0000, olcott said:
On 7/23/2024 2:32 AM, Mikko wrote:
On 2024-07-22 15:05:41 +0000, olcott said:
On 7/22/2024 6:05 AM, Mikko wrote:
On 2024-07-20 15:28:31 +0000, olcott said:
void DDD()
{
HHH(DDD);
}
int main()
{
DDD();
}
(a) Termination Analyzers / Partial Halt Deciders must halt >>>>>>>>>>> this is a design requirement.
For a partial analyzer or deciders this is not always required. >>>>>>>>>>
*You can't even get my words correctly*
A termination analyzer must report on the behavior of at least >>>>>>>>> one input for all of the inputs of this one input. This is
met when a termination analyzer analyzes an input having no inputs. >>>>>>>>>
A partial halt decider must correctly determine the halt status >>>>>>>>> of at least one input and its specific input (if any).
HHH is both a partial halt decider and a termination analyzer >>>>>>>>> for DDD and a few other inputs having no input.
(b) Every simulating termination analyzer HHH either
aborts the simulation of its input or not.
This must be interpreted to mean that a simulating termination analyzer
may abort its simulation for some simulated abort and simulate others
to the termination.
I am talking about hypothetical possible ways that HHH could be encoded.
(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.
(c) Within the hypothetical case where HHH does not abort >>>>>>>>>>> the simulation of its input {HHH, emulated DDD and executed DDD} >>>>>>>>>>> never stop running.
The case is not very hypothetical. Given the HHH you already have, >>>>>>>>>> it is fairly easy to construct the "hypothetical" HHH and see what >>>>>>>>>> it actually does.
(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.
Therefore (a) is correct and (b) is incorrect according to the >>>>>>>>> design requirements for HHH that it must halt.This violates the design requirement of (a) therefore HHH must >>>>>>>>>>> abort the simulation of its input.
The violation simply means that the "hypothetical" HHH is not a >>>>>>>>>> termination analyzer of partial halt decider in sense (a). What >>>>>>>>>> it "must" be or do depends on the requirements.
It is also a truism that any input that must be aborted
is a non-halting input.
No, it is not. The "must" and "non-halting" belong to different worlds.
The word "must" blongs to requirements. The word "non-halting" is a >>>>>>>> feature of a program. They are unrelated, so one cannot be inferred >>>>>>>> from the other.
When-so-ever there are two hypothetical possible way to encode
a simulating halt decider for a specific input
(a) one aborts its simulation of DDD
(b) never aborts its simulation of DDD
Does the simulator that simulates the beginning and end of the
simulated computation but skips a part in ghe middle belong to
class (a) or class (b)?
That is off topic. I am only referring to a sequence of
1 to N x86 machine language instructions simulated according
to the x86 semantic meaning of these instructions.
No, it isn't. Abortion of simulation is a deviation form x86 macine
language semantics. What I ask about does not deviate more.
In other words you are saying that it is absolutely impossible
to make an x86 program that is an x86 emulator that correctly
emulates a finite number of instructions of non-terminating
input x86 machine code.
You are lying again. That is not the same in other words, and I am
not saying what you falsely claim.
I am not lying I am paraphrasing so that we can come to a mutual understanding.
On 7/27/2024 9:28 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:54 AM, Mikko wrote:
If a simulator correctly simulates a finite number of instructions
where x86 program specifies an execution of an infinite number of
instructions then the simulation deviates from x86 semantics at the
point where the simulation stops but the x86 semantics specify
countinuation.
In other words you believe that instead of recognizing a
non-halting behavior pattern, then aborting the simulation
and rejecting the input as non-halting the termination
analyzer should just get stuck in recursive simulation?
You're doing it again. "In other words" is here a lie; you've just
replaced Mikko's words with something very different.
He just said that the simulation of a non-terminating input
is incorrect unless it is simulated forever.
On 7/28/2024 3:10 AM, Mikko wrote:That is right.
On 2024-07-27 14:45:21 +0000, olcott said:
On 7/27/2024 9:28 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:He just said that the simulation of a non-terminating input is
On 7/27/2024 1:54 AM, Mikko wrote:
If a simulator correctly simulates a finite number of instructions >>>>>> where x86 program specifies an execution of an infinite number of
instructions then the simulation deviates from x86 semantics at the >>>>>> point where the simulation stops but the x86 semantics specify
countinuation.
In other words you believe that instead of recognizing a non-halting >>>>> behavior pattern, then aborting the simulation and rejecting the
input as non-halting the termination analyzer should just get stuck
in recursive simulation?
You're doing it again. "In other words" is here a lie; you've just
replaced Mikko's words with something very different.
incorrect unless it is simulated forever.
"Until". By which point it does deviate, by not continuing a haltingI said it deviates form the x86 semantics. I didn't say whether it isIt does not freaking deviate from the semantics for DDD to be correctly emulated by HHH
incorrect to deviate from x86 semantics. But it is incorrect to say
"off topic" on the basis of not following x86 semantics when your "on
topic" deviates from the x86 semantics as much as what I ask about in
my "off topic" question.
until HHH correctly determines that its emulated DDD would never
stop running unless aborted...
On 7/28/2024 3:10 AM, Mikko wrote:
On 2024-07-27 14:45:21 +0000, olcott said:
On 7/27/2024 9:28 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:54 AM, Mikko wrote:
If a simulator correctly simulates a finite number of instructions >>>>>> where x86 program specifies an execution of an infinite number of
instructions then the simulation deviates from x86 semantics at the >>>>>> point where the simulation stops but the x86 semantics specify
countinuation.
In other words you believe that instead of recognizing a
non-halting behavior pattern, then aborting the simulation
and rejecting the input as non-halting the termination
analyzer should just get stuck in recursive simulation?
You're doing it again. "In other words" is here a lie; you've just
replaced Mikko's words with something very different.
He just said that the simulation of a non-terminating input
is incorrect unless it is simulated forever.
I said it deviates form the x86 semantics. I didn't say whether it is
incorrect to deviate from x86 semantics. But it is incorrect to say
"off topic" on the basis of not following x86 semantics when your
"on topic" deviates from the x86 semantics as much as what I ask about
in my "off topic" question.
It does not freaking deviate from the semantics for DDD
to be correctly emulated by HHH
until HHH correctly determines that its emulated DDD would never
stop running unless aborted...
until HHH correctly determines that its emulated DDD would never
stop running unless aborted...
until HHH correctly determines that its emulated DDD would never
stop running unless aborted...
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 7/28/2024 3:04 AM, Mikko wrote:
On 2024-07-27 13:55:56 +0000, olcott said:
On 7/27/2024 1:54 AM, Mikko wrote:
On 2024-07-26 13:58:54 +0000, olcott said:
On 7/26/2024 3:05 AM, Mikko wrote:
On 2024-07-24 13:38:08 +0000, olcott said:
On 7/24/2024 4:01 AM, Mikko wrote:
On 2024-07-23 14:41:11 +0000, olcott said:
On 7/23/2024 2:32 AM, Mikko wrote:
On 2024-07-22 15:05:41 +0000, olcott said:
On 7/22/2024 6:05 AM, Mikko wrote:
On 2024-07-20 15:28:31 +0000, olcott said:
void DDD()
{
HHH(DDD);
}
int main()
{
DDD();
}
(a) Termination Analyzers / Partial Halt Deciders must halt >>>>>>>>>>>>> this is a design requirement.
For a partial analyzer or deciders this is not always required. >>>>>>>>>>>>
*You can't even get my words correctly*
A termination analyzer must report on the behavior of at least >>>>>>>>>>> one input for all of the inputs of this one input. This is >>>>>>>>>>> met when a termination analyzer analyzes an input having no inputs. >>>>>>>>>>>
A partial halt decider must correctly determine the halt status >>>>>>>>>>> of at least one input and its specific input (if any).
HHH is both a partial halt decider and a termination analyzer >>>>>>>>>>> for DDD and a few other inputs having no input.
(b) Every simulating termination analyzer HHH either >>>>>>>>>>>>> aborts the simulation of its input or not.
This must be interpreted to mean that a simulating termination analyzer
may abort its simulation for some simulated abort and simulate others
to the termination.
I am talking about hypothetical possible ways that HHH could be encoded.
(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.
(c) Within the hypothetical case where HHH does not abort >>>>>>>>>>>>> the simulation of its input {HHH, emulated DDD and executed DDD} >>>>>>>>>>>>> never stop running.
The case is not very hypothetical. Given the HHH you already have, >>>>>>>>>>>> it is fairly easy to construct the "hypothetical" HHH and see what >>>>>>>>>>>> it actually does.
(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.
Therefore (a) is correct and (b) is incorrect according to the >>>>>>>>>>> design requirements for HHH that it must halt.This violates the design requirement of (a) therefore HHH must >>>>>>>>>>>>> abort the simulation of its input.
The violation simply means that the "hypothetical" HHH is not a >>>>>>>>>>>> termination analyzer of partial halt decider in sense (a). What >>>>>>>>>>>> it "must" be or do depends on the requirements.
It is also a truism that any input that must be aborted
is a non-halting input.
No, it is not. The "must" and "non-halting" belong to different worlds.
The word "must" blongs to requirements. The word "non-halting" is a >>>>>>>>>> feature of a program. They are unrelated, so one cannot be inferred >>>>>>>>>> from the other.
When-so-ever there are two hypothetical possible way to encode >>>>>>>>> a simulating halt decider for a specific input
(a) one aborts its simulation of DDD
(b) never aborts its simulation of DDD
Does the simulator that simulates the beginning and end of the >>>>>>>> simulated computation but skips a part in ghe middle belong to >>>>>>>> class (a) or class (b)?
That is off topic. I am only referring to a sequence of
1 to N x86 machine language instructions simulated according
to the x86 semantic meaning of these instructions.
No, it isn't. Abortion of simulation is a deviation form x86 macine >>>>>> language semantics. What I ask about does not deviate more.
In other words you are saying that it is absolutely impossible
to make an x86 program that is an x86 emulator that correctly
emulates a finite number of instructions of non-terminating
input x86 machine code.
You are lying again. That is not the same in other words, and I am
not saying what you falsely claim.
I am not lying I am paraphrasing so that we can come to a mutual
understanding.
It is lying to paraphrase so that the original meaning is not preserved.
I make my point mere clearly here:
[Any honest person that knows the x86 language can see...]
On 7/28/2024 3:10 AM, Mikko wrote:
On 2024-07-27 14:45:21 +0000, olcott said:
On 7/27/2024 9:28 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:54 AM, Mikko wrote:
If a simulator correctly simulates a finite number of instructions >>>>>> where x86 program specifies an execution of an infinite number of
instructions then the simulation deviates from x86 semantics at the >>>>>> point where the simulation stops but the x86 semantics specify
countinuation.
In other words you believe that instead of recognizing a
non-halting behavior pattern, then aborting the simulation
and rejecting the input as non-halting the termination
analyzer should just get stuck in recursive simulation?
You're doing it again. "In other words" is here a lie; you've just
replaced Mikko's words with something very different.
He just said that the simulation of a non-terminating input
is incorrect unless it is simulated forever.
I said it deviates form the x86 semantics. I didn't say whether it is
incorrect to deviate from x86 semantics.
The measure of DDD correctly emulated by HHH
until HHH correctly determines that its emulated DDD would never
stop running unless aborted...
is that the emulation of DDD by HHH
*DOES NOT DEVIATE FROM THE X86 SEMANTICS*
But it is incorrect to say
"off topic" on the basis of not following x86 semantics when your
"on topic" deviates from the x86 semantics as much as what I ask about
in my "off topic" question.
On 7/28/2024 3:10 AM, Mikko wrote:
On 2024-07-27 14:45:21 +0000, olcott said:
On 7/27/2024 9:28 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:54 AM, Mikko wrote:
If a simulator correctly simulates a finite number of instructions >>>>>> where x86 program specifies an execution of an infinite number of
instructions then the simulation deviates from x86 semantics at the >>>>>> point where the simulation stops but the x86 semantics specify
countinuation.
In other words you believe that instead of recognizing a
non-halting behavior pattern, then aborting the simulation
and rejecting the input as non-halting the termination
analyzer should just get stuck in recursive simulation?
You're doing it again. "In other words" is here a lie; you've just
replaced Mikko's words with something very different.
He just said that the simulation of a non-terminating input
is incorrect unless it is simulated forever.
I said it deviates form the x86 semantics. I didn't say whether it is
incorrect to deviate from x86 semantics.
The measure of DDD correctly emulated by HHH
until HHH correctly determines that its emulated DDD would never
stop running unless aborted...
is that the emulation of DDD by HHH
*DOES NOT DEVIATE FROM THE X86 SEMANTICS*
But it is incorrect to say
"off topic" on the basis of not following x86 semantics when your
"on topic" deviates from the x86 semantics as much as what I ask about
in my "off topic" question.
On 7/30/2024 1:44 AM, Mikko wrote:
On 2024-07-29 16:17:32 +0000, olcott said:
On 7/28/2024 3:04 AM, Mikko wrote:
On 2024-07-27 13:55:56 +0000, olcott said:
On 7/27/2024 1:54 AM, Mikko wrote:
On 2024-07-26 13:58:54 +0000, olcott said:
On 7/26/2024 3:05 AM, Mikko wrote:
On 2024-07-24 13:38:08 +0000, olcott said:
On 7/24/2024 4:01 AM, Mikko wrote:
On 2024-07-23 14:41:11 +0000, olcott said:
On 7/23/2024 2:32 AM, Mikko wrote:
On 2024-07-22 15:05:41 +0000, olcott said:
On 7/22/2024 6:05 AM, Mikko wrote:
On 2024-07-20 15:28:31 +0000, olcott said:
void DDD()
{
HHH(DDD);
}
int main()
{
DDD();
}
(a) Termination Analyzers / Partial Halt Deciders must halt >>>>>>>>>>>>>>> this is a design requirement.
For a partial analyzer or deciders this is not always required. >>>>>>>>>>>>>>
*You can't even get my words correctly*
A termination analyzer must report on the behavior of at least >>>>>>>>>>>>> one input for all of the inputs of this one input. This is >>>>>>>>>>>>> met when a termination analyzer analyzes an input having no inputs.
A partial halt decider must correctly determine the halt status >>>>>>>>>>>>> of at least one input and its specific input (if any). >>>>>>>>>>>>>
HHH is both a partial halt decider and a termination analyzer >>>>>>>>>>>>> for DDD and a few other inputs having no input.
(b) Every simulating termination analyzer HHH either >>>>>>>>>>>>>>> aborts the simulation of its input or not.
This must be interpreted to mean that a simulating termination analyzer
may abort its simulation for some simulated abort and simulate others
to the termination.
I am talking about hypothetical possible ways that HHH could be encoded.
(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation. >>>>>>>>>>>>>
(c) Within the hypothetical case where HHH does not abort >>>>>>>>>>>>>>> the simulation of its input {HHH, emulated DDD and executed DDD}
never stop running.
The case is not very hypothetical. Given the HHH you already have,
it is fairly easy to construct the "hypothetical" HHH and see what
it actually does.
(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation. >>>>>>>>>>>>>
Therefore (a) is correct and (b) is incorrect according to the >>>>>>>>>>>>> design requirements for HHH that it must halt.This violates the design requirement of (a) therefore HHH must >>>>>>>>>>>>>>> abort the simulation of its input.
The violation simply means that the "hypothetical" HHH is not a >>>>>>>>>>>>>> termination analyzer of partial halt decider in sense (a). What >>>>>>>>>>>>>> it "must" be or do depends on the requirements.
It is also a truism that any input that must be aborted >>>>>>>>>>>>> is a non-halting input.
No, it is not. The "must" and "non-halting" belong to different worlds.
The word "must" blongs to requirements. The word "non-halting" is a
feature of a program. They are unrelated, so one cannot be inferred
from the other.
When-so-ever there are two hypothetical possible way to encode >>>>>>>>>>> a simulating halt decider for a specific input
(a) one aborts its simulation of DDD
(b) never aborts its simulation of DDD
Does the simulator that simulates the beginning and end of the >>>>>>>>>> simulated computation but skips a part in ghe middle belong to >>>>>>>>>> class (a) or class (b)?
That is off topic. I am only referring to a sequence of
1 to N x86 machine language instructions simulated according >>>>>>>>> to the x86 semantic meaning of these instructions.
No, it isn't. Abortion of simulation is a deviation form x86 macine >>>>>>>> language semantics. What I ask about does not deviate more.
In other words you are saying that it is absolutely impossible
to make an x86 program that is an x86 emulator that correctly
emulates a finite number of instructions of non-terminating
input x86 machine code.
You are lying again. That is not the same in other words, and I am >>>>>> not saying what you falsely claim.
I am not lying I am paraphrasing so that we can come to a mutual
understanding.
It is lying to paraphrase so that the original meaning is not preserved. >>>>
I make my point mere clearly here:
[Any honest person that knows the x86 language can see...]
That does not alter the fact that you lied above. Therefore the term
"honest person" does not include you. So what is your evidence that
any (or even some) honest person can see...?
*I clarified what I meant responding to your original message here* http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv8bc6j%24159av%241%40dont-email.me%3E
On 8/1/2024 3:02 AM, Mikko wrote:
On 2024-07-30 18:42:27 +0000, olcott said:
On 7/28/2024 3:10 AM, Mikko wrote:
On 2024-07-27 14:45:21 +0000, olcott said:
On 7/27/2024 9:28 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:54 AM, Mikko wrote:
If a simulator correctly simulates a finite number of instructions >>>>>>>> where x86 program specifies an execution of an infinite number of >>>>>>>> instructions then the simulation deviates from x86 semantics at the >>>>>>>> point where the simulation stops but the x86 semantics specify >>>>>>>> countinuation.
In other words you believe that instead of recognizing a
non-halting behavior pattern, then aborting the simulation
and rejecting the input as non-halting the termination
analyzer should just get stuck in recursive simulation?
You're doing it again. "In other words" is here a lie; you've just >>>>>> replaced Mikko's words with something very different.
He just said that the simulation of a non-terminating input
is incorrect unless it is simulated forever.
I said it deviates form the x86 semantics. I didn't say whether it is
incorrect to deviate from x86 semantics.
The measure of DDD correctly emulated by HHH
until HHH correctly determines that its emulated DDD would never
stop running unless aborted...
is that the emulation of DDD by HHH
*DOES NOT DEVIATE FROM THE X86 SEMANTICS*
Whether the determination is correct is not proven.
That you lack sufficient technical competence to
understand that something has been proved is much
less than no actual rebuttal at all.
On 8/1/2024 3:14 AM, Mikko wrote:
On 2024-07-30 21:11:45 +0000, olcott said:
On 7/30/2024 1:44 AM, Mikko wrote:
On 2024-07-29 16:17:32 +0000, olcott said:
On 7/28/2024 3:04 AM, Mikko wrote:
On 2024-07-27 13:55:56 +0000, olcott said:
On 7/27/2024 1:54 AM, Mikko wrote:
On 2024-07-26 13:58:54 +0000, olcott said:
On 7/26/2024 3:05 AM, Mikko wrote:
On 2024-07-24 13:38:08 +0000, olcott said:In other words you are saying that it is absolutely impossible >>>>>>>>> to make an x86 program that is an x86 emulator that correctly >>>>>>>>> emulates a finite number of instructions of non-terminating
On 7/24/2024 4:01 AM, Mikko wrote:
On 2024-07-23 14:41:11 +0000, olcott said:
On 7/23/2024 2:32 AM, Mikko wrote:
On 2024-07-22 15:05:41 +0000, olcott said:
On 7/22/2024 6:05 AM, Mikko wrote:
On 2024-07-20 15:28:31 +0000, olcott said:
void DDD()
{
HHH(DDD);
}
int main()
{
DDD();
}
(a) Termination Analyzers / Partial Halt Deciders must halt >>>>>>>>>>>>>>>>> this is a design requirement.
For a partial analyzer or deciders this is not always required.
*You can't even get my words correctly*
A termination analyzer must report on the behavior of at least >>>>>>>>>>>>>>> one input for all of the inputs of this one input. This is >>>>>>>>>>>>>>> met when a termination analyzer analyzes an input having no inputs.
A partial halt decider must correctly determine the halt status >>>>>>>>>>>>>>> of at least one input and its specific input (if any). >>>>>>>>>>>>>>>
HHH is both a partial halt decider and a termination analyzer >>>>>>>>>>>>>>> for DDD and a few other inputs having no input.
(b) Every simulating termination analyzer HHH either >>>>>>>>>>>>>>>>> aborts the simulation of its input or not.
This must be interpreted to mean that a simulating termination analyzer
may abort its simulation for some simulated abort and simulate others
to the termination.
I am talking about hypothetical possible ways that HHH could be encoded.
(a) HHH(DDD) is encoded to abort its simulation. >>>>>>>>>>>>>>> (b) HHH(DDD) is encoded to never abort its simulation. >>>>>>>>>>>>>>>
(c) Within the hypothetical case where HHH does not abort >>>>>>>>>>>>>>>>> the simulation of its input {HHH, emulated DDD and executed DDD}
never stop running.
The case is not very hypothetical. Given the HHH you already have,
it is fairly easy to construct the "hypothetical" HHH and see what
it actually does.
(a) HHH(DDD) is encoded to abort its simulation. >>>>>>>>>>>>>>> (b) HHH(DDD) is encoded to never abort its simulation. >>>>>>>>>>>>>>>
Therefore (a) is correct and (b) is incorrect according to the >>>>>>>>>>>>>>> design requirements for HHH that it must halt.This violates the design requirement of (a) therefore HHH must
abort the simulation of its input.
The violation simply means that the "hypothetical" HHH is not a
termination analyzer of partial halt decider in sense (a). What
it "must" be or do depends on the requirements. >>>>>>>>>>>>>>>>
It is also a truism that any input that must be aborted >>>>>>>>>>>>>>> is a non-halting input.
No, it is not. The "must" and "non-halting" belong to different worlds.
The word "must" blongs to requirements. The word "non-halting" is a
feature of a program. They are unrelated, so one cannot be inferred
from the other.
When-so-ever there are two hypothetical possible way to encode >>>>>>>>>>>>> a simulating halt decider for a specific input
(a) one aborts its simulation of DDD
(b) never aborts its simulation of DDD
Does the simulator that simulates the beginning and end of the >>>>>>>>>>>> simulated computation but skips a part in ghe middle belong to >>>>>>>>>>>> class (a) or class (b)?
That is off topic. I am only referring to a sequence of >>>>>>>>>>> 1 to N x86 machine language instructions simulated according >>>>>>>>>>> to the x86 semantic meaning of these instructions.
No, it isn't. Abortion of simulation is a deviation form x86 macine >>>>>>>>>> language semantics. What I ask about does not deviate more. >>>>>>>>>
input x86 machine code.
You are lying again. That is not the same in other words, and I am >>>>>>>> not saying what you falsely claim.
I am not lying I am paraphrasing so that we can come to a mutual >>>>>>> understanding.
It is lying to paraphrase so that the original meaning is not preserved. >>>>>>
I make my point mere clearly here:
[Any honest person that knows the x86 language can see...]
That does not alter the fact that you lied above. Therefore the term
"honest person" does not include you. So what is your evidence that
any (or even some) honest person can see...?
*I clarified what I meant responding to your original message here*
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv8bc6j%24159av%241%40dont-email.me%3E
That does not really claify beyond what you said here, and what it
clarifies is irrelevant to the fact that you lied above.
That you persistently make sure to ignore the word "until"
is your brain damage and not my mistake.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 153:58:23 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,842 |