On 7/4/2024 3:04 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:45 schreef olcott:
On 7/4/2024 2:40 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:30 schreef olcott:
On 7/4/2024 2:26 PM, Fred. Zwarts wrote:
I showed that HHH cannot possibly correctly simulate itself.
I proved otherwise, Liar.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, this trace supports my claim. When we look at this trace we see
that
HHH is simulating itself simulating DDD until it sees
that DDD is calling HHH in recursive simulation such
that neither the simulated DDD nor the simulated HHH
can possibly stop running unless HHH aborts its DDD.
The 'unless HHH aborts ...' is irrelevant and misleading,
Not at all. Not in the least little bit.
A halt decider must PREDICT what its input would do.
Professor Sipser recognized this as inherently correct.
Introduction to the Theory of Computation, by Michael Sipser https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
He is the #1 best selling author of textbooks on computation
theory. Ben did contact him to verify that he did say this.
<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>
Ben also agreed that D correctly simulated by H DOES MEET THIS CRITERIA.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's...
trivial to do for this one case) that correctly determines that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were not halted. That much is a truism.
On 7/4/2024 3:04 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:45 schreef olcott:
On 7/4/2024 2:40 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:30 schreef olcott:HHH is simulating itself simulating DDD until it sees
On 7/4/2024 2:26 PM, Fred. Zwarts wrote:
I showed that HHH cannot possibly correctly simulate itself.
I proved otherwise, Liar.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, this trace supports my claim. When we look at this trace we see that >>>
that DDD is calling HHH in recursive simulation such
that neither the simulated DDD nor the simulated HHH
can possibly stop running unless HHH aborts its DDD.
The 'unless HHH aborts ...' is irrelevant and misleading,
Not at all. Not in the least little bit.
A halt decider must PREDICT what its input would do.
Professor Sipser recognized this as inherently correct.
On 7/4/2024 3:04 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:45 schreef olcott:
On 7/4/2024 2:40 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:30 schreef olcott:
On 7/4/2024 2:26 PM, Fred. Zwarts wrote:
I showed that HHH cannot possibly correctly simulate itself.
I proved otherwise, Liar.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, this trace supports my claim. When we look at this trace we see
that
HHH is simulating itself simulating DDD until it sees
that DDD is calling HHH in recursive simulation such
that neither the simulated DDD nor the simulated HHH
can possibly stop running unless HHH aborts its DDD.
The 'unless HHH aborts ...' is irrelevant and misleading,
Not at all. Not in the least little bit.
A halt decider must PREDICT what its input would do.
Professor Sipser recognized this as inherently correct.
Introduction to the Theory of Computation, by Michael Sipser https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
He is the #1 best selling author of textbooks on computation
theory. Ben did contact him to verify that he did say this.
<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>
Ben also agreed that D correctly simulated by H DOES MEET THIS CRITERIA.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's...
trivial to do for this one case) that correctly determines that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were not halted. That much is a truism.
On 7/4/2024 3:04 PM, Fred. Zwarts wrote:because in fact HHH DOES abort.
Op 04.jul.2024 om 21:45 schreef olcott:
On 7/4/2024 2:40 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:30 schreef olcott:
On 7/4/2024 2:26 PM, Fred. Zwarts wrote:
The 'unless HHH aborts ...' is irrelevant and misleading,No, this trace supports my claim. When we look at this trace we seeHHH is simulating itself simulating DDD until it sees that DDD is
that
calling HHH in recursive simulation such that neither the simulated
DDD nor the simulated HHH can possibly stop running unless HHH aborts
its DDD.
Not at all. Not in the least little bit.Which is that HHH aborts and does not run forever.
A halt decider must PREDICT what its input would do.
Professor Sipser recognized this as inherently correct.It is not the huge deal you make it out to be.
Ben also agreed that D correctly simulated by H DOES MEET THIS CRITERIA.Where does he say that? D IS aborted, so the condition doesn’t match.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's
trivial to do for this one case) that correctly determines that P(P) *would* never stop running *unless* aborted.
On 7/5/2024 3:32 AM, Fred. Zwarts wrote:
Op 04.jul.2024 om 22:18 schreef olcott:
On 7/4/2024 3:04 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:45 schreef olcott:
On 7/4/2024 2:40 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:30 schreef olcott:
On 7/4/2024 2:26 PM, Fred. Zwarts wrote:
I showed that HHH cannot possibly correctly simulate itself.
I proved otherwise, Liar.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, this trace supports my claim. When we look at this trace we
see that
HHH is simulating itself simulating DDD until it sees
that DDD is calling HHH in recursive simulation such
that neither the simulated DDD nor the simulated HHH
can possibly stop running unless HHH aborts its DDD.
The 'unless HHH aborts ...' is irrelevant and misleading,
Not at all. Not in the least little bit.
A halt decider must PREDICT what its input would do.
Yes and when it must predict what a simulator that is programmed to
abort would do, it should predict that the it will abort and halt. If
it predicts something different, then it is incorrect.
If it aborts and ignore that last part of the input, it is incorrect.
When a bear is running at you to kill you it is not
enough that you only predict that you will shoot the
bear. You must actually shoot the bear or you will be killed.
Professor Sipser recognized this as inherently correct.
But that did not apply, because its context was a *correct*
simulation. His agreement does not include *incorrect* simulations.
Sipser would agree that HHH, when aborting a simulation of itself and
missing the last part of the input is incorrect.
Introduction to the Theory of Computation, by Michael Sipser
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
He is the #1 best selling author of textbooks on computation
theory. Ben did contact him to verify that he did say this.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
Note the word 'correctly'. So, it does not apply to the simulation of
HHH by itself, which cannot possibly correctly simulate itself.
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>
Ben also agreed that D correctly simulated by H DOES MEET THIS CRITERIA. >>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's...
trivial to do for this one case) that correctly determines that P(P) >>> > *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were not
halted. That much is a truism.
On 7/5/2024 7:38 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 14:19 schreef olcott:
On 7/5/2024 3:32 AM, Fred. Zwarts wrote:
Op 04.jul.2024 om 22:18 schreef olcott:
On 7/4/2024 3:04 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:45 schreef olcott:
On 7/4/2024 2:40 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:30 schreef olcott:
On 7/4/2024 2:26 PM, Fred. Zwarts wrote:
I proved otherwise, Liar.
I showed that HHH cannot possibly correctly simulate itself. >>>>>>>>>
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, this trace supports my claim. When we look at this trace we >>>>>>>> see that
HHH is simulating itself simulating DDD until it sees
that DDD is calling HHH in recursive simulation such
that neither the simulated DDD nor the simulated HHH
can possibly stop running unless HHH aborts its DDD.
The 'unless HHH aborts ...' is irrelevant and misleading,
Not at all. Not in the least little bit.
A halt decider must PREDICT what its input would do.
Yes and when it must predict what a simulator that is programmed to
abort would do, it should predict that the it will abort and halt.
If it predicts something different, then it is incorrect.
If it aborts and ignore that last part of the input, it is incorrect.
When a bear is running at you to kill you it is not
enough that you only predict that you will shoot the
bear. You must actually shoot the bear or you will be killed.
Exactly! Similarly, if a program is programmed to halt, the simulation
of it should not only predict that it will halt, but the simulation
must actually let it halt, as the simulated program is programmed to
do. HHH fails at both. Its prediction is incorrect and its action is
incorrect.
You are either a liar or incompetent
when correctly emulated by HHH there
is no "letting" these functions halt.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(Infinite_Loop);
HHH(Infinite_Recursion);
HHH(DDD);
}
On 7/5/2024 2:56 AM, Mikko wrote:
On 2024-07-04 20:18:16 +0000, olcott said:
On 7/4/2024 3:04 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:45 schreef olcott:
On 7/4/2024 2:40 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:30 schreef olcott:
On 7/4/2024 2:26 PM, Fred. Zwarts wrote:
I showed that HHH cannot possibly correctly simulate itself.
I proved otherwise, Liar.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, this trace supports my claim. When we look at this trace we
see that
HHH is simulating itself simulating DDD until it sees
that DDD is calling HHH in recursive simulation such
that neither the simulated DDD nor the simulated HHH
can possibly stop running unless HHH aborts its DDD.
The 'unless HHH aborts ...' is irrelevant and misleading,
Not at all. Not in the least little bit.
A halt decider must PREDICT what its input would do.
Professor Sipser recognized this as inherently correct.
"When a prophet speaketh in the name of the LORD, if the thing follow
not,
nor come to pass, that is the thing which the LORD hath not spoken,
but the
prophet hath spoken it presumptuously: thou shalt not be afraid of him."
Deuteronomy 18:22
That is, preditions and predictors must be tested and not taken serioulsy
unless the pass the test.
In case of halt deciders, that means that when we know what the halt
decider
has predicted we run the computation described by the input to the halt
decider and see whether it halts and complare what we see to the
prediction.
It is not the job of a simulating termination analyzer
to get stuck in recursive simulation. It is the job
of a simulating termination analyzer to correctly
predict this and take action to prevent it.
On 7/5/2024 3:32 AM, Fred. Zwarts wrote:
Op 04.jul.2024 om 22:18 schreef olcott:
On 7/4/2024 3:04 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:45 schreef olcott:
On 7/4/2024 2:40 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:30 schreef olcott:
On 7/4/2024 2:26 PM, Fred. Zwarts wrote:
I showed that HHH cannot possibly correctly simulate itself.
I proved otherwise, Liar.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, this trace supports my claim. When we look at this trace we
see that
HHH is simulating itself simulating DDD until it sees
that DDD is calling HHH in recursive simulation such
that neither the simulated DDD nor the simulated HHH
can possibly stop running unless HHH aborts its DDD.
The 'unless HHH aborts ...' is irrelevant and misleading,
Not at all. Not in the least little bit.
A halt decider must PREDICT what its input would do.
Yes and when it must predict what a simulator that is programmed to
abort would do, it should predict that the it will abort and halt. If
it predicts something different, then it is incorrect.
If it aborts and ignore that last part of the input, it is incorrect.
When a bear is running at you to kill you it is not
enough that you only predict that you will shoot the
bear. You must actually shoot the bear or you will be killed.
Professor Sipser recognized this as inherently correct.
But that did not apply, because its context was a *correct*
simulation. His agreement does not include *incorrect* simulations.
Sipser would agree that HHH, when aborting a simulation of itself and
missing the last part of the input is incorrect.
Introduction to the Theory of Computation, by Michael Sipser
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
He is the #1 best selling author of textbooks on computation
theory. Ben did contact him to verify that he did say this.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
Note the word 'correctly'. So, it does not apply to the simulation of
HHH by itself, which cannot possibly correctly simulate itself.
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>
Ben also agreed that D correctly simulated by H DOES MEET THIS CRITERIA. >>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's...
trivial to do for this one case) that correctly determines that P(P) >>> > *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were not
halted. That much is a truism.
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 15:16 schreef olcott:LIAR! I give up on you.
On 7/5/2024 7:38 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 14:19 schreef olcott:
On 7/5/2024 3:32 AM, Fred. Zwarts wrote:
Op 04.jul.2024 om 22:18 schreef olcott:
On 7/4/2024 3:04 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:45 schreef olcott:
On 7/4/2024 2:40 PM, Fred. Zwarts wrote:
Op 04.jul.2024 om 21:30 schreef olcott:
On 7/4/2024 2:26 PM, Fred. Zwarts wrote:
I proved otherwise, Liar.
I showed that HHH cannot possibly correctly simulate itself. >>>>>>>>>>>
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, this trace supports my claim. When we look at this trace >>>>>>>>>> we see that
HHH is simulating itself simulating DDD until it sees
that DDD is calling HHH in recursive simulation such
that neither the simulated DDD nor the simulated HHH
can possibly stop running unless HHH aborts its DDD.
The 'unless HHH aborts ...' is irrelevant and misleading,
Not at all. Not in the least little bit.
A halt decider must PREDICT what its input would do.
Yes and when it must predict what a simulator that is programmed
to abort would do, it should predict that the it will abort and
halt. If it predicts something different, then it is incorrect.
If it aborts and ignore that last part of the input, it is incorrect. >>>>>>
When a bear is running at you to kill you it is not
enough that you only predict that you will shoot the
bear. You must actually shoot the bear or you will be killed.
Exactly! Similarly, if a program is programmed to halt, the
simulation of it should not only predict that it will halt, but the
simulation must actually let it halt, as the simulated program is
programmed to do. HHH fails at both. Its prediction is incorrect and
its action is incorrect.
You are either a liar or incompetent
I know you have problems recognizing the truth.
when correctly emulated by HHH there
HHH cannot possibly correctly simulate itself.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
is no "letting" these functions halt.
That is indeed the failure of HHH. It cannot do what it must do.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(Infinite_Loop);
HHH(Infinite_Recursion);
HHH(DDD);
}
It seems you do not understand that a finite recursion will end.
void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}
In the same way, DDD, when correctly simulated, will end, as you have
shown. Only HHH cannot possibly correctly simulate itself up to its
end. That is why HHH cannot simulate DDD. That is not a property of
DDD, but a failure of HHH, which is unable to process the full input
and aborts before DDD reaches its end.
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
LIAR! I give up on you.
HHH cannot possibly correctly simulate itself.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No need to come back, because you are unable to point to any error in
my reasoning.
I conclusively proved that HHH is correctly simulating itself
simulating DDD and you simply freaking lie about it.
Your replies are only irrelevant, or supporting my reasoning. I showed
that HHH cannot possibly simulate itself correctly and your full trace
supports this, as it shows that the simulating HHH is unable to reach
the 'ret' of the simulated HHH.
*Unable to reach ret IS A FREAKING CORRECT FREAKING SIMULATION*
The machine code specifies that DDD simulated by HHH according
to the semantics of the x86 language cannot possibly reach the
ret instruction of DDD or its correctly simulated self.
_DDD()
[00002172] 55 push ebp ; housekeeping [00002173] 8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
LIAR! I give up on you.
HHH cannot possibly correctly simulate itself.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No need to come back, because you are unable to point to any error in
my reasoning.
I conclusively proved that HHH is correctly simulating itself
simulating DDD and you simply freaking lie about it.
Your replies are only irrelevant, or supporting my reasoning. I showed
that HHH cannot possibly simulate itself correctly and your full trace
supports this, as it shows that the simulating HHH is unable to reach
the 'ret' of the simulated HHH.
*Unable to reach ret IS A FREAKING CORRECT FREAKING SIMULATION*
The machine code specifies that DDD simulated by HHH according
to the semantics of the x86 language cannot possibly reach the
ret instruction of DDD or its correctly simulated self.
_DDD()
[00002172] 55 push ebp ; housekeeping [00002173] 8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
On 7/6/2024 4:09 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 17:54 schreef olcott:
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
LIAR! I give up on you.
HHH cannot possibly correctly simulate itself.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No need to come back, because you are unable to point to any error
in my reasoning.
I conclusively proved that HHH is correctly simulating itself
simulating DDD and you simply freaking lie about it.
Your replies are only irrelevant, or supporting my reasoning. I
showed that HHH cannot possibly simulate itself correctly and your
full trace supports this, as it shows that the simulating HHH is
unable to reach the 'ret' of the simulated HHH.
*Unable to reach ret IS A FREAKING CORRECT FREAKING SIMULATION*
Unable to reach ret *is a freaking demonstration* of an incorrect
simulation.
If it was incorrect you would have to show which
x86 instruction was simulated incorrectly. You
can't do that because it is a matter of verified
fact that none of them were simulated incorrectly.
The machine code specifies that DDD simulated by HHH according
to the semantics of the x86 language cannot possibly reach the
ret instruction of DDD or its correctly simulated self.
_DDD()
[00002172] 55 push ebp ; housekeeping >>> [00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Your traces shows that HHH aborts the simulation at a point there the
simulated HHH has only one cycle to go before it would abort and halt.
All of the HHH have the same code. The outer HHH
meets its abort criteria first. It is a verified
fact that unless the outer HHH aborts then none
of them do. This violates this correct criteria
<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>
So, the only reason why this simulation does not reach the 'ret' of
the simulated HHH, is that it is aborted prematurely.
A correct simulation by another simulator shows that this is indeed
the case.
HHH1 can wait for HHH to abort because DDD does not call HHH1.
HHH cannot wait because DDD calls HHH.
HHH cannot possible simulate *itself* correctly. This code and your
trace demonstrates this. The fact that the simulation does not reach
the 'ret', where other simulator can do that, demonstrates that HHH's
simulation of itself is incorrect.
The only thing you brought in against it, is a baseless repetition
that you still belief that the simulation is correct.
HHH that aborts and halts can be compared to a bear running at you to
kill you:
All other simulators will tell you that HHH aborts and halts.
All people will warn you that the bear is running at you and will kill
you.
Only when HHH simulates itself, it says: not aborting and non-halting.
The bear says about itself: I am not running and I will not kill you.
What do you trust?
I only trust correct reasoning.
On 7/6/2024 10:00 AM, Fred. Zwarts wrote:
Op 06.jul.2024 om 15:01 schreef olcott:
On 7/6/2024 4:09 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 17:54 schreef olcott:
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
LIAR! I give up on you.
HHH cannot possibly correctly simulate itself.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No need to come back, because you are unable to point to any error >>>>>> in my reasoning.
I conclusively proved that HHH is correctly simulating itself
simulating DDD and you simply freaking lie about it.
Your replies are only irrelevant, or supporting my reasoning. I
showed that HHH cannot possibly simulate itself correctly and your >>>>>> full trace supports this, as it shows that the simulating HHH is
unable to reach the 'ret' of the simulated HHH.
*Unable to reach ret IS A FREAKING CORRECT FREAKING SIMULATION*
Unable to reach ret *is a freaking demonstration* of an incorrect
simulation.
If it was incorrect you would have to show which
x86 instruction was simulated incorrectly. You
can't do that because it is a matter of verified
fact that none of them were simulated incorrectly.
Incorrect reasoning. Is it really over your head? The simulated
instructions are correct, but the instructions that are not simulated
make the simulation incorrect. The simulation is aborted too soon. One
cycle later the simulated HHH would abort and halt. That part of the
input is neglected by your simulation, which makes it incorrect,
because it should process the whole input, not only the first part.
The machine code specifies that DDD simulated by HHH according
to the semantics of the x86 language cannot possibly reach the
ret instruction of DDD or its correctly simulated self.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping >>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Your traces shows that HHH aborts the simulation at a point there
the simulated HHH has only one cycle to go before it would abort and
halt.
All of the HHH have the same code. The outer HHH
meets its abort criteria first. It is a verified
fact that unless the outer HHH aborts then none
of them do. This violates this correct criteria
Incorrect reasoning.
Dreaming of an HHH that does not abort is irrelevant. This HHH *does*
abort. The outer one does, so all of them do. Therefore, the HHH
simulated by the outer one is aborted one cycle before it would abort
and halt, as well. That makes the abort premature.
HHH cannot possibly simulate itself correctly.
<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>
Incorrect reasoning.
That is a stupid lie.
You forget pretty soon you have been told many times that Sipser does
not apply here. You keep repeating this irrelevant text. It is
irrelevant, because it is about a correct simulation, not about an
incorrect simulation.
So, the only reason why this simulation does not reach the 'ret' of
the simulated HHH, is that it is aborted prematurely.
A correct simulation by another simulator shows that this is indeed
the case.
HHH1 can wait for HHH to abort because DDD does not call HHH1.
HHH cannot wait because DDD calls HHH.
HHH cannot possible simulate *itself* correctly. This code and your
trace demonstrates this. The fact that the simulation does not reach
the 'ret', where other simulator can do that, demonstrates that
HHH's simulation of itself is incorrect.
The only thing you brought in against it, is a baseless repetition
that you still belief that the simulation is correct.
HHH that aborts and halts can be compared to a bear running at you
to kill you:
All other simulators will tell you that HHH aborts and halts.
All people will warn you that the bear is running at you and will
kill you.
Only when HHH simulates itself, it says: not aborting and non-halting. >>>> The bear says about itself: I am not running and I will not kill you.
What do you trust?
I only trust correct reasoning.
So, trust my correct reasoning. Not your own incorrect reasoning.
On 7/6/2024 10:00 AM, Fred. Zwarts wrote:You have previously agreed that the direct execution halts. How can
Op 06.jul.2024 om 15:01 schreef olcott:
On 7/6/2024 4:09 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 17:54 schreef olcott:
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
HHH cannot possibly correctly simulate itself.
If it was incorrect you would have to show which x86 instruction wasUnable to reach ret *is a freaking demonstration* of an incorrectYour replies are only irrelevant, or supporting my reasoning. I
showed that HHH cannot possibly simulate itself correctly and your >>>>>> full trace supports this, as it shows that the simulating HHH is
unable to reach the 'ret' of the simulated HHH.
simulation.
simulated incorrectly. You can't do that because it is a matter of
verified fact that none of them were simulated incorrectly.
The semantics of the x86 language are the only criterion measure ofWhich semantics say that you are allowed to abort a simulation that
correct emulation. Only stupid liars would disagree.
Smart liars would not disagree because they would know how stupid thisPeople that know their way around notice obvious mistakes.
makes them look. Smart liars would disagree on much more subtle things.
This is the right place to respond.Is it really over your head? The simulated instructions are correct,
but the instructions that are not simulated make the simulation
incorrect. The simulation is aborted too soon. One cycle later the
simulated HHH would abort and halt. That part of the input is neglected
by your simulation, which makes it incorrect, because it should process
the whole input, not only the first part.
And HHH halts, by definition.Your traces shows that HHH aborts the simulation at a point there the
simulated HHH has only one cycle to go before it would abort and
halt.
All of the HHH have the same code. The outer HHH meets its abort
criteria first. It is a verified fact that unless the outer HHH aborts
then none of them do. This violates this correct criteria
Incorrect reasoning.
Dreaming of an HHH that does not abort is irrelevant. This HHH *does*
abort. The outer one does, so all of them do. Therefore, the HHH
simulated by the outer one is aborted one cycle before it would abort
and halt, as well. That makes the abort premature.
HHH cannot possibly simulate itself correctly.
So, the only reason why this simulation does not reach the 'ret' of
the simulated HHH, is that it is aborted prematurely.
A correct simulation by another simulator shows that this is indeed
the case.
HHH1 can wait for HHH to abort because DDD does not call HHH1.
HHH cannot wait because DDD calls HHH.
On 7/6/2024 10:00 AM, Fred. Zwarts wrote:
Op 06.jul.2024 om 15:01 schreef olcott:
On 7/6/2024 4:09 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 17:54 schreef olcott:
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
LIAR! I give up on you.
HHH cannot possibly correctly simulate itself.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No need to come back, because you are unable to point to any error >>>>>> in my reasoning.
I conclusively proved that HHH is correctly simulating itself
simulating DDD and you simply freaking lie about it.
Your replies are only irrelevant, or supporting my reasoning. I
showed that HHH cannot possibly simulate itself correctly and your >>>>>> full trace supports this, as it shows that the simulating HHH is
unable to reach the 'ret' of the simulated HHH.
*Unable to reach ret IS A FREAKING CORRECT FREAKING SIMULATION*
Unable to reach ret *is a freaking demonstration* of an incorrect
simulation.
If it was incorrect you would have to show which
x86 instruction was simulated incorrectly. You
can't do that because it is a matter of verified
fact that none of them were simulated incorrectly.
Incorrect reasoning. Is it really over your head? The simulated
instructions are correct, but the instructions that are not simulated
make the simulation incorrect. The simulation is aborted too soon. One
cycle later the simulated HHH would abort and halt. That part of the
input is neglected by your simulation, which makes it incorrect,
because it should process the whole input, not only the first part.
The machine code specifies that DDD simulated by HHH according
to the semantics of the x86 language cannot possibly reach the
ret instruction of DDD or its correctly simulated self.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping >>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Your traces shows that HHH aborts the simulation at a point there
the simulated HHH has only one cycle to go before it would abort and
halt.
All of the HHH have the same code. The outer HHH
meets its abort criteria first. It is a verified
fact that unless the outer HHH aborts then none
of them do. This violates this correct criteria
Incorrect reasoning.
Dreaming of an HHH that does not abort is irrelevant. This HHH *does*
abort. The outer one does, so all of them do. Therefore, the HHH
simulated by the outer one is aborted one cycle before it would abort
and halt, as well. That makes the abort premature.
HHH cannot possibly simulate itself correctly.
<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>
Incorrect reasoning.
That is a stupid lie.
You forget pretty soon you have been told many times that Sipser does
not apply here. You keep repeating this irrelevant text. It is
irrelevant, because it is about a correct simulation, not about an
incorrect simulation.
So, the only reason why this simulation does not reach the 'ret' of
the simulated HHH, is that it is aborted prematurely.
A correct simulation by another simulator shows that this is indeed
the case.
HHH1 can wait for HHH to abort because DDD does not call HHH1.
HHH cannot wait because DDD calls HHH.
HHH cannot possible simulate *itself* correctly. This code and your
trace demonstrates this. The fact that the simulation does not reach
the 'ret', where other simulator can do that, demonstrates that
HHH's simulation of itself is incorrect.
The only thing you brought in against it, is a baseless repetition
that you still belief that the simulation is correct.
HHH that aborts and halts can be compared to a bear running at you
to kill you:
All other simulators will tell you that HHH aborts and halts.
All people will warn you that the bear is running at you and will
kill you.
Only when HHH simulates itself, it says: not aborting and non-halting. >>>> The bear says about itself: I am not running and I will not kill you.
What do you trust?
I only trust correct reasoning.
So, trust my correct reasoning. Not your own incorrect reasoning.
On 7/6/2024 10:00 AM, Fred. Zwarts wrote:
Op 06.jul.2024 om 15:01 schreef olcott:
On 7/6/2024 4:09 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 17:54 schreef olcott:
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
LIAR! I give up on you.
HHH cannot possibly correctly simulate itself.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No need to come back, because you are unable to point to any error >>>>>> in my reasoning.
I conclusively proved that HHH is correctly simulating itself
simulating DDD and you simply freaking lie about it.
Your replies are only irrelevant, or supporting my reasoning. I
showed that HHH cannot possibly simulate itself correctly and your >>>>>> full trace supports this, as it shows that the simulating HHH is
unable to reach the 'ret' of the simulated HHH.
*Unable to reach ret IS A FREAKING CORRECT FREAKING SIMULATION*
Unable to reach ret *is a freaking demonstration* of an incorrect
simulation.
If it was incorrect you would have to show which
x86 instruction was simulated incorrectly. You
can't do that because it is a matter of verified
fact that none of them were simulated incorrectly.
Incorrect reasoning.
I commented at the wrong place.
The semantics of the x86 language are the only criterion
measure of correct emulation. Only stupid liars would disagree.
Smart liars would not disagree because they would know how
stupid this makes them look. Smart liars would disagree on
much more subtle things.
Is it really over your head? The simulated instructions are correct,
but the instructions that are not simulated make the simulation
incorrect. The simulation is aborted too soon. One cycle later the
simulated HHH would abort and halt. That part of the input is
neglected by your simulation, which makes it incorrect, because it
should process the whole input, not only the first part.
The machine code specifies that DDD simulated by HHH according
to the semantics of the x86 language cannot possibly reach the
ret instruction of DDD or its correctly simulated self.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping >>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Your traces shows that HHH aborts the simulation at a point there
the simulated HHH has only one cycle to go before it would abort and
halt.
All of the HHH have the same code. The outer HHH
meets its abort criteria first. It is a verified
fact that unless the outer HHH aborts then none
of them do. This violates this correct criteria
Incorrect reasoning.
Dreaming of an HHH that does not abort is irrelevant. This HHH *does*
abort. The outer one does, so all of them do. Therefore, the HHH
simulated by the outer one is aborted one cycle before it would abort
and halt, as well. That makes the abort premature.
HHH cannot possibly simulate itself correctly.
<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>
Incorrect reasoning.
You forget pretty soon you have been told many times that Sipser does
not apply here. You keep repeating this irrelevant text. It is
irrelevant, because it is about a correct simulation, not about an
incorrect simulation.
So, the only reason why this simulation does not reach the 'ret' of
the simulated HHH, is that it is aborted prematurely.
A correct simulation by another simulator shows that this is indeed
the case.
HHH1 can wait for HHH to abort because DDD does not call HHH1.
HHH cannot wait because DDD calls HHH.
HHH cannot possible simulate *itself* correctly. This code and your
trace demonstrates this. The fact that the simulation does not reach
the 'ret', where other simulator can do that, demonstrates that
HHH's simulation of itself is incorrect.
The only thing you brought in against it, is a baseless repetition
that you still belief that the simulation is correct.
HHH that aborts and halts can be compared to a bear running at you
to kill you:
All other simulators will tell you that HHH aborts and halts.
All people will warn you that the bear is running at you and will
kill you.
Only when HHH simulates itself, it says: not aborting and non-halting. >>>> The bear says about itself: I am not running and I will not kill you.
What do you trust?
I only trust correct reasoning.
So, trust my correct reasoning. Not your own incorrect reasoning.
On 7/6/2024 10:00 AM, Fred. Zwarts wrote:
Op 06.jul.2024 om 15:01 schreef olcott:
On 7/6/2024 4:09 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 17:54 schreef olcott:
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
LIAR! I give up on you.
HHH cannot possibly correctly simulate itself.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No need to come back, because you are unable to point to any error >>>>>> in my reasoning.
I conclusively proved that HHH is correctly simulating itself
simulating DDD and you simply freaking lie about it.
Your replies are only irrelevant, or supporting my reasoning. I
showed that HHH cannot possibly simulate itself correctly and your >>>>>> full trace supports this, as it shows that the simulating HHH is
unable to reach the 'ret' of the simulated HHH.
*Unable to reach ret IS A FREAKING CORRECT FREAKING SIMULATION*
Unable to reach ret *is a freaking demonstration* of an incorrect
simulation.
If it was incorrect you would have to show which
x86 instruction was simulated incorrectly. You
can't do that because it is a matter of verified
fact that none of them were simulated incorrectly.
Incorrect reasoning.
I commented at the wrong place.
The semantics of the x86 language are the only criterion
measure of correct emulation. Only stupid liars would disagree.
Smart liars would not disagree because they would know how
stupid this makes them look. Smart liars would disagree on
much more subtle things.
Is it really over your head? The simulated instructions are correct,
but the instructions that are not simulated make the simulation
incorrect. The simulation is aborted too soon. One cycle later the
simulated HHH would abort and halt. That part of the input is
neglected by your simulation, which makes it incorrect, because it
should process the whole input, not only the first part.
The machine code specifies that DDD simulated by HHH according
to the semantics of the x86 language cannot possibly reach the
ret instruction of DDD or its correctly simulated self.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping >>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Your traces shows that HHH aborts the simulation at a point there
the simulated HHH has only one cycle to go before it would abort and
halt.
All of the HHH have the same code. The outer HHH
meets its abort criteria first. It is a verified
fact that unless the outer HHH aborts then none
of them do. This violates this correct criteria
Incorrect reasoning.
Dreaming of an HHH that does not abort is irrelevant. This HHH *does*
abort. The outer one does, so all of them do. Therefore, the HHH
simulated by the outer one is aborted one cycle before it would abort
and halt, as well. That makes the abort premature.
HHH cannot possibly simulate itself correctly.
<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>
Incorrect reasoning.
You forget pretty soon you have been told many times that Sipser does
not apply here. You keep repeating this irrelevant text. It is
irrelevant, because it is about a correct simulation, not about an
incorrect simulation.
So, the only reason why this simulation does not reach the 'ret' of
the simulated HHH, is that it is aborted prematurely.
A correct simulation by another simulator shows that this is indeed
the case.
HHH1 can wait for HHH to abort because DDD does not call HHH1.
HHH cannot wait because DDD calls HHH.
HHH cannot possible simulate *itself* correctly. This code and your
trace demonstrates this. The fact that the simulation does not reach
the 'ret', where other simulator can do that, demonstrates that
HHH's simulation of itself is incorrect.
The only thing you brought in against it, is a baseless repetition
that you still belief that the simulation is correct.
HHH that aborts and halts can be compared to a bear running at you
to kill you:
All other simulators will tell you that HHH aborts and halts.
All people will warn you that the bear is running at you and will
kill you.
Only when HHH simulates itself, it says: not aborting and non-halting. >>>> The bear says about itself: I am not running and I will not kill you.
What do you trust?
I only trust correct reasoning.
So, trust my correct reasoning. Not your own incorrect reasoning.
On 7/6/2024 10:26 AM, joes wrote:
Am Sat, 06 Jul 2024 10:10:06 -0500 schrieb olcott:
On 7/6/2024 10:00 AM, Fred. Zwarts wrote:
Op 06.jul.2024 om 15:01 schreef olcott:
On 7/6/2024 4:09 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 17:54 schreef olcott:
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
HHH cannot possibly correctly simulate itself.
If it was incorrect you would have to show which x86 instruction was >>>>> simulated incorrectly. You can't do that because it is a matter ofUnable to reach ret *is a freaking demonstration* of an incorrectYour replies are only irrelevant, or supporting my reasoning. I >>>>>>>> showed that HHH cannot possibly simulate itself correctly and your >>>>>>>> full trace supports this, as it shows that the simulating HHH is >>>>>>>> unable to reach the 'ret' of the simulated HHH.
simulation.
verified fact that none of them were simulated incorrectly.
You have previously agreed that the direct execution halts. How can
a simulation deviate and be correct?
If you sufficiently understand the semantics of the x86
language then you can see that the call to HHH(DDD) from
DDD simulated according to the semantics of the x86 language
cannot possibly return.
If you fail to sufficiently understand the semantics of the
x86 language then seeing this is impossible for you.
_DDD()
[00002172] 55 push ebp ; housekeeping [00002173] 8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
On 7/6/2024 10:29 AM, Fred. Zwarts wrote:
Op 06.jul.2024 om 17:10 schreef olcott:
On 7/6/2024 10:00 AM, Fred. Zwarts wrote:
Op 06.jul.2024 om 15:01 schreef olcott:
On 7/6/2024 4:09 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 17:54 schreef olcott:
On 7/5/2024 10:48 AM, Fred. Zwarts wrote:
Op 05.jul.2024 om 16:05 schreef olcott:
On 7/5/2024 8:54 AM, Fred. Zwarts wrote:
LIAR! I give up on you.
HHH cannot possibly correctly simulate itself.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No need to come back, because you are unable to point to any
error in my reasoning.
I conclusively proved that HHH is correctly simulating itself
simulating DDD and you simply freaking lie about it.
Your replies are only irrelevant, or supporting my reasoning. I >>>>>>>> showed that HHH cannot possibly simulate itself correctly and
your full trace supports this, as it shows that the simulating >>>>>>>> HHH is unable to reach the 'ret' of the simulated HHH.
*Unable to reach ret IS A FREAKING CORRECT FREAKING SIMULATION*
Unable to reach ret *is a freaking demonstration* of an incorrect
simulation.
If it was incorrect you would have to show which
x86 instruction was simulated incorrectly. You
can't do that because it is a matter of verified
fact that none of them were simulated incorrectly.
Incorrect reasoning.
I commented at the wrong place.
The semantics of the x86 language are the only criterion
measure of correct emulation. Only stupid liars would disagree.
So, why do you disagree that the x86 code specifies an HHH that aborts
and halts?
Dishonest dodge of changing the subject. This is called
the strawman deception and is a favorite tactic of liars.
If you sufficiently understand the semantics of the x86
language then you can see that the call to HHH(DDD) from
DDD simulated according to the semantics of the x86 language
cannot possibly return.
If you fail to sufficiently understand the semantics of the
x86 language then seeing this is impossible for you.
_DDD()
[00002172] 55 push ebp ; housekeeping [00002173] 8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
On 7/6/2024 1:55 PM, Fred. Zwarts wrote:
Op 06.jul.2024 om 18:30 schreef olcott:
On 7/6/2024 10:29 AM, Fred. Zwarts wrote:
So, why do you disagree that the x86 code specifies an HHH that
aborts and halts?
Dishonest dodge of changing the subject. This is called
the strawman deception and is a favorite tactic of liars.
Irrelevant text ignored. You talked about x86, therefore continuing to
talk about x86 is not a change of subject.
I know you have difficulties to recognize the truth, so I do not feel
offended, because: 'Don't assume somebody is wilfully wrong, if
incompetence could be an explanation, as well.'
If you sufficiently understand the semantics of the x86
language then you can see that the call to HHH(DDD) from
DDD simulated according to the semantics of the x86 language
cannot possibly return.
I understand enough of it to see that it cannot possibly return,
because HHH cannot possibly simulate itself correctly.
According to the semantics of the x86 language IS IS IMPOSSIBLE
FOR DDD SIMULATED BY HHH TO RETURN AND IT IS EQUALLY IMPOSSIBLE
FOR THE HHH(DDD) CALLED BY DDD SIMULATED BY HHH TO RETURN.
I can't tell that you are ignorant or a liar and it is reaching
the point where I don't care which it is.
On 7/6/2024 1:55 PM, Fred. Zwarts wrote:
Op 06.jul.2024 om 18:30 schreef olcott:
On 7/6/2024 10:29 AM, Fred. Zwarts wrote:
So, why do you disagree that the x86 code specifies an HHH that
aborts and halts?
Dishonest dodge of changing the subject. This is called
the strawman deception and is a favorite tactic of liars.
Irrelevant text ignored. You talked about x86, therefore continuing to
talk about x86 is not a change of subject.
I know you have difficulties to recognize the truth, so I do not feel
offended, because: 'Don't assume somebody is wilfully wrong, if
incompetence could be an explanation, as well.'
If you sufficiently understand the semantics of the x86
language then you can see that the call to HHH(DDD) from
DDD simulated according to the semantics of the x86 language
cannot possibly return.
I understand enough of it to see that it cannot possibly return,
because HHH cannot possibly simulate itself correctly.
According to the semantics of the x86 language IS IS IMPOSSIBLE
FOR DDD SIMULATED BY HHH TO RETURN AND IT IS EQUALLY IMPOSSIBLE
FOR THE HHH(DDD) CALLED BY DDD SIMULATED BY HHH TO RETURN.
I can't tell that you are ignorant or a liar and it is reaching
the point where I don't care which it is.
On 7/8/2024 9:25 AM, Fred. Zwarts wrote:An aborted simulation is not correct.
Op 07.jul.2024 om 15:46 schreef olcott:
Yes. This shows that the simulation is incorrect.
Correctly is measured by the semantics of the x86 language.
This specifies that when DDD is correctly simulated by HHH calls
emulated HHH(DDD) that this call cannot return.
Similarly, HHH cannot possibly simulate itself correctly, no matter howWhere correct is understood to be what-ever-the-Hell that the machine
much you want it to be correct,
code of DDD specifies within the semantics of the x86 language then:
When DDD is correctly simulated by any pure function x86 emulator HHH
that aborts its emulation at some point calls HHH(DDD) then it is
correctly understood that this call cannot possibly return.
Correct is certainly not screwball misconceptions that contradict the
above.
On 7/7/2024 1:41 AM, Fred. Zwarts wrote:
Op 06.jul.2024 om 21:14 schreef olcott:
On 7/6/2024 1:55 PM, Fred. Zwarts wrote:
Op 06.jul.2024 om 18:30 schreef olcott:
On 7/6/2024 10:29 AM, Fred. Zwarts wrote:
So, why do you disagree that the x86 code specifies an HHH that
aborts and halts?
Dishonest dodge of changing the subject. This is called
the strawman deception and is a favorite tactic of liars.
Irrelevant text ignored. You talked about x86, therefore continuing
to talk about x86 is not a change of subject.
I know you have difficulties to recognize the truth, so I do not
feel offended, because: 'Don't assume somebody is wilfully wrong, if
incompetence could be an explanation, as well.'
If you sufficiently understand the semantics of the x86
language then you can see that the call to HHH(DDD) from
DDD simulated according to the semantics of the x86 language
cannot possibly return.
I understand enough of it to see that it cannot possibly return,
because HHH cannot possibly simulate itself correctly.
According to the semantics of the x86 language IS IS IMPOSSIBLE
FOR DDD SIMULATED BY HHH TO RETURN AND IT IS EQUALLY IMPOSSIBLE
FOR THE HHH(DDD) CALLED BY DDD SIMULATED BY HHH TO RETURN.
Therefore, you should agree that HHH cannot possibly simulate itself
correctly.
Correctly is measured by the semantics of the x86 language.
This specifies that when DDD is correctly simulated by HHH
calls emulated HHH(DDD) that this call cannot return.
You smash a bottle on the ground. No matter how much you
want the bottle to hold water it will not hold water.
That is what the semantics of the x86 teach you.A correct simulation is what-so-ever-the Hell that the x86
There is no disagreement about the semantics of the x86, if you see
that it means that HHH cannot possibly reach its own 'ret'
instruction, therefore, the simulation cannot possibly be correct.
machine code of HHH/DDD specifies even if this code starts
WW III. Correct is not measured by what you would like to
see or what you expect to happen. Correct is only measured
by the behavior that the code specifies.
When I say that 2 + 3 = 5 you are not free to dislike this
result and prefer or expect 2 + 3 = 7.
On 7/8/2024 10:08 AM, joes wrote:He is not, but you assume the condition has been met.
Am Mon, 08 Jul 2024 10:04:37 -0500 schrieb olcott:
On 7/8/2024 9:25 AM, Fred. Zwarts wrote:
Op 07.jul.2024 om 15:46 schreef olcott:
It turns out the the #1 best selling author of theory of computation textbooks is not wrong when he agreed with my verbatim words.When DDD is correctly simulated by any pure function x86 emulator HHHAn aborted simulation is not correct.
that aborts its emulation at some point calls HHH(DDD) then it is
correctly understood that this call cannot possibly return.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:No. P(P) IS in fact aborted, so DOES stop running.
I don't think that is the shell game. PO really /has/ an H (it's...
trivial to do for this one case) that correctly determines that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were not*Proves that Ben agreed that the criteria has been met*
halted. That much is a truism.
Ben thought that H must report on the behavior of D after H aborts its simulation before it aborts this simulation.Of course it does. If it would not run forever, it would be wrong to
On 7/8/2024 9:25 AM, Fred. Zwarts wrote:
Op 07.jul.2024 om 15:46 schreef olcott:
Correctly is measured by the semantics of the x86 language.
This specifies that when DDD is correctly simulated by HHH
calls emulated HHH(DDD) that this call cannot return.
Yes. This shows that the simulation is incorrect.
You smash a bottle on the ground. No matter how much you
want the bottle to hold water it will not hold water.
Similarly, HHH cannot possibly simulate itself correctly, no matter
how much you want it to be correct,
Where correct is understood to be what-ever-the-Hell that the
machine code of DDD specifies within the semantics of the x86
language then:
When DDD is correctly simulated by any pure function x86 emulator
HHH that aborts its emulation at some point calls HHH(DDD) then
it is correctly understood that this call cannot possibly return.
The proof of this is something like mathematical induction.
When DDD is correctly emulated by any HHH that aborts
its emulation after N repetitions:
(1) DDD is correctly emulated by HHH
(2) that calls an emulated HHH(DDD) that
(3) emulates another DDD... goto (2) or abort
Correct is certainly not screwball misconceptions that contradict
the above.
On 7/8/2024 11:04 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 17:04 schreef olcott:
On 7/8/2024 9:25 AM, Fred. Zwarts wrote:
Op 07.jul.2024 om 15:46 schreef olcott:
Correctly is measured by the semantics of the x86 language.
This specifies that when DDD is correctly simulated by HHH
calls emulated HHH(DDD) that this call cannot return.
Yes. This shows that the simulation is incorrect.
You smash a bottle on the ground. No matter how much you
want the bottle to hold water it will not hold water.
Similarly, HHH cannot possibly simulate itself correctly, no matter
how much you want it to be correct,
Where correct is understood to be what-ever-the-Hell that the
machine code of DDD specifies within the semantics of the x86
language then:
When DDD is correctly simulated by any pure function x86 emulator
HHH that aborts its emulation at some point calls HHH(DDD) then
it is correctly understood that this call cannot possibly return.
The proof of this is something like mathematical induction.
When DDD is correctly emulated by any HHH that aborts
its emulation after N repetitions:
(1) DDD is correctly emulated by HHH
But only the first part is simulated, not the full input. The
simulation must simulate the full input. It will will only become
correct if also the other behaviour of HHH is simulated. But HHH is
unable to simulate itself up to that point.
That is what the x86 code specifies.
(2) that calls an emulated HHH(DDD) that
(3) emulates another DDD... goto (2) or abort
And when it aborts, it is one cycle to soon.
Try to show how infinity is one cycle too soon.
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
On 7/8/2024 11:04 AM, Fred. Zwarts wrote:You believe that two equals infinity.
Op 08.jul.2024 om 17:04 schreef olcott:
On 7/8/2024 9:25 AM, Fred. Zwarts wrote:
Op 07.jul.2024 om 15:46 schreef olcott:
Correctly is measured by the semantics of the x86 language.
This specifies that when DDD is correctly simulated by HHH
calls emulated HHH(DDD) that this call cannot return.
Yes. This shows that the simulation is incorrect.
You smash a bottle on the ground. No matter how much you
want the bottle to hold water it will not hold water.
Similarly, HHH cannot possibly simulate itself correctly, no matter how >>>>>> much you want it to be correct,
Where correct is understood to be what-ever-the-Hell that the
machine code of DDD specifies within the semantics of the x86
language then:
When DDD is correctly simulated by any pure function x86 emulator
HHH that aborts its emulation at some point calls HHH(DDD) then
it is correctly understood that this call cannot possibly return.
The proof of this is something like mathematical induction.
When DDD is correctly emulated by any HHH that aborts
its emulation after N repetitions:
(1) DDD is correctly emulated by HHH
But only the first part is simulated, not the full input. The
simulation must simulate the full input. It will will only become
correct if also the other behaviour of HHH is simulated. But HHH is
unable to simulate itself up to that point.
That is what the x86 code specifies.
(2) that calls an emulated HHH(DDD) that
(3) emulates another DDD... goto (2) or abort
And when it aborts, it is one cycle to soon.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
On 7/8/2024 11:04 AM, Fred. Zwarts wrote:You believe that two equals infinity.
Op 08.jul.2024 om 17:04 schreef olcott:
On 7/8/2024 9:25 AM, Fred. Zwarts wrote:
Op 07.jul.2024 om 15:46 schreef olcott:
Correctly is measured by the semantics of the x86 language.
This specifies that when DDD is correctly simulated by HHH
calls emulated HHH(DDD) that this call cannot return.
Yes. This shows that the simulation is incorrect.
You smash a bottle on the ground. No matter how much you
want the bottle to hold water it will not hold water.
Similarly, HHH cannot possibly simulate itself correctly, no
matter how much you want it to be correct,
Where correct is understood to be what-ever-the-Hell that the
machine code of DDD specifies within the semantics of the x86
language then:
When DDD is correctly simulated by any pure function x86 emulator
HHH that aborts its emulation at some point calls HHH(DDD) then
it is correctly understood that this call cannot possibly return.
The proof of this is something like mathematical induction.
When DDD is correctly emulated by any HHH that aborts
its emulation after N repetitions:
(1) DDD is correctly emulated by HHH
But only the first part is simulated, not the full input. The
simulation must simulate the full input. It will will only become
correct if also the other behaviour of HHH is simulated. But HHH is
unable to simulate itself up to that point.
That is what the x86 code specifies.
(2) that calls an emulated HHH(DDD) that
(3) emulates another DDD... goto (2) or abort
And when it aborts, it is one cycle to soon.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite
execution can be inferred. That is best illustrated by the following
examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates no more >> }
The important difference is that in my examples there is a conditional
instruction that can (and does) prevent infinite exectuion.
When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return?
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite
execution can be inferred. That is best illustrated by the following
examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates
no more
}
The important difference is that in my examples there is a conditional >>>> instruction that can (and does) prevent infinite exectuion.
When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is
what one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
A correct emulator can correctly any correct x86 instructions.
When it emulates non-halting code then itself does not halt.
On 7/10/2024 9:11 AM, Fred. Zwarts wrote:
Op 10.jul.2024 om 15:37 schreef olcott:
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite
execution can be inferred. That is best illustrated by the following >>>>>> examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates >>>>>> no more
}
The important difference is that in my examples there is a
conditional
instruction that can (and does) prevent infinite exectuion.
When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is
what one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
A correct emulator can correctly any correct x86 instructions.
When it emulates non-halting code then itself does not halt.
But when simulating a halting code, it is incorrect to abort the
simulation halfway, even when you dream of another non-halting code.
Such dreams are irrelevant.
As soon as it is certain that not aborting results in
its own non-termination a simulating termination must
abort.
On 7/10/2024 2:18 AM, Mikko wrote:Oh? Maybe you should give your simulator and decider different names
On 2024-07-09 14:14:16 +0000, olcott said:A correct emulator can correctly any correct x86 instructions.
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:When we ask:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none of the above
functions correctly emulated by HHH can possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite
execution can be inferred. That is best illustrated by the following
examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates
no more }
The important difference is that in my examples there is a
conditional instruction that can (and does) prevent infinite
exectuion.
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is what
one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
When it emulates non-halting code then itself does not halt.
On 7/10/2024 9:11 AM, Fred. Zwarts wrote:You said previously that it could be a correct simulation to abort that.
Op 10.jul.2024 om 15:37 schreef olcott:
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
A correct emulator can correctly any correct x86 instructions.There is an important detail that determines whether an infiniteWhen we ask:
execution can be inferred. That is best illustrated by the
following examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates >>>>>> no more }
The important difference is that in my examples there is a
conditional instruction that can (and does) prevent infinite
exectuion.
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is
what one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
When it emulates non-halting code then itself does not halt.
It is certain that the simulation will terminate of its own accord.But when simulating a halting code, it is incorrect to abort the
simulation halfway, even when you dream of another non-halting code.
Such dreams are irrelevant.
As soon as it is certain that not aborting results in its own
non-termination a simulating termination must abort.
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite
execution can be inferred. That is best illustrated by the following
examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates no more
}
The important difference is that in my examples there is a conditional >>>> instruction that can (and does) prevent infinite exectuion.
When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is
what one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
A correct emulator can correctly any correct x86 instructions.
When it emulates non-halting code then itself does not halt.
Am Wed, 10 Jul 2024 08:37:30 -0500 schrieb olcott:
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:A correct emulator can correctly any correct x86 instructions.
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:When we ask:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none of the above >>>>>> functions correctly emulated by HHH can possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite
execution can be inferred. That is best illustrated by the following >>>>> examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates
no more }
The important difference is that in my examples there is a
conditional instruction that can (and does) prevent infinite
exectuion.
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is what
one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
When it emulates non-halting code then itself does not halt.
Oh? Maybe you should give your simulator and decider different names
so they don't get confused.
On 7/11/2024 1:50 AM, Mikko wrote:
On 2024-07-10 13:37:30 +0000, olcott said:
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite
execution can be inferred. That is best illustrated by the following >>>>>> examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates >>>>>> no more
}
The important difference is that in my examples there is a
conditional
instruction that can (and does) prevent infinite exectuion.
When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is
what one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
A correct emulator can correctly any correct x86 instructions.
When it emulates non-halting code then itself does not halt.
Not quite right but should be easy to fix. There should be a verb
before "any",
for example "execute". Of course there still is a probelm with the
meaning
"any correct x86 instructions". Intel may publish a new x86 processor
that has
instructios that the emulator cannot know but are nevertheless correct
x86
instructions because Intel says so. In the second sentence "it" should
be used
istead of "itself".
Intel has already done this and they call this x64.
A 1907 Model-T Ford cannot have upgrades and still
be a 1907 model-T Ford. Likewise for the x86 language.
On 7/11/2024 1:56 AM, Mikko wrote:
On 2024-07-10 18:27:27 +0000, joes said:
Am Wed, 10 Jul 2024 08:37:30 -0500 schrieb olcott:
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:A correct emulator can correctly any correct x86 instructions.
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:When we ask:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none of the above >>>>>>>> functions correctly emulated by HHH can possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite >>>>>>> execution can be inferred. That is best illustrated by the following >>>>>>> examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates >>>>>>> no more }
The important difference is that in my examples there is a
conditional instruction that can (and does) prevent infinite
exectuion.
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is what >>>>> one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
When it emulates non-halting code then itself does not halt.
Oh? Maybe you should give your simulator and decider different names
so they don't get confused.
A charlatan doesn't want clarity but confusion. A good charlatan just
dont what them so much that they would be noticed for that might expose
the charlatan.
It is a hierarchy of prerequisites of knowledge.
Before anyone can understand a simulating termination
analyzer based on an x86 emulator they must understand
(1) x86 emulation
(2) Termination Analysis.
So far no-one besides Ben Bacarisse has sufficiently
understood (1) "x86 emulation" well enough so that we can
move on to the
On 7/11/2024 1:50 AM, Mikko wrote:
On 2024-07-10 13:37:30 +0000, olcott said:
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite
execution can be inferred. That is best illustrated by the following >>>>>> examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates no more
}
The important difference is that in my examples there is a conditional >>>>>> instruction that can (and does) prevent infinite exectuion.
When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is
what one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
A correct emulator can correctly any correct x86 instructions.
When it emulates non-halting code then itself does not halt.
Not quite right but should be easy to fix. There should be a verb before "any",
for example "execute". Of course there still is a probelm with the meaning >> "any correct x86 instructions". Intel may publish a new x86 processor that has
instructios that the emulator cannot know but are nevertheless correct x86 >> instructions because Intel says so. In the second sentence "it" should be used
istead of "itself".
Intel has already done this and they call this x64.
A 1907 Model-T Ford cannot have upgrades and still
be a 1907 model-T Ford. Likewise for the x86 language.
On 7/12/2024 2:49 AM, Mikko wrote:
On 2024-07-11 14:40:50 +0000, olcott said:
It is a hierarchy of prerequisites of knowledge.
Before anyone can understand a simulating termination
analyzer based on an x86 emulator they must understand
(1) x86 emulation
(2) Termination Analysis.
The order should be:
(1) termination analysis and termination analyzer,
(2) simulating termination analyzer,
(3) x86,
(4) x86 emulation,
(5) simulating termination analyzer based on an x86 emulator.
*That order has proven to not work*
People are getting stuck on x86 emulation.
On 7/12/2024 2:55 AM, Mikko wrote:
On 2024-07-11 14:16:34 +0000, olcott said:
On 7/11/2024 1:50 AM, Mikko wrote:
On 2024-07-10 13:37:30 +0000, olcott said:
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite >>>>>>>> execution can be inferred. That is best illustrated by the following >>>>>>>> examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates no more
}
The important difference is that in my examples there is a conditional >>>>>>>> instruction that can (and does) prevent infinite exectuion.
When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic. >>>>>> Instead one could ask whether HHH can fully emulate DDD if that is >>>>>> what one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.
A correct emulator can correctly any correct x86 instructions.
When it emulates non-halting code then itself does not halt.
Not quite right but should be easy to fix. There should be a verb before "any",
for example "execute". Of course there still is a probelm with the meaning >>>> "any correct x86 instructions". Intel may publish a new x86 processor that has
instructios that the emulator cannot know but are nevertheless correct x86 >>>> instructions because Intel says so. In the second sentence "it" should be used
istead of "itself".
Intel has already done this and they call this x64.
A 1907 Model-T Ford cannot have upgrades and still
be a 1907 model-T Ford. Likewise for the x86 language.
A new version of a 1907 Model-T Ford is possible and can have the same name >> except that the "1907" must be replaced as it refers to the year. That the >> "Model-T" is also replaced is a free chioce of Ford.
Likewise Intel is free to call a new processor whatever they want to call it.
The x86 language is a fixed constant.
On 7/13/2024 2:48 AM, Mikko wrote:
On 2024-07-12 13:07:13 +0000, olcott said:
On 7/12/2024 2:49 AM, Mikko wrote:
On 2024-07-11 14:40:50 +0000, olcott said:
It is a hierarchy of prerequisites of knowledge.
Before anyone can understand a simulating termination
analyzer based on an x86 emulator they must understand
(1) x86 emulation
(2) Termination Analysis.
The order should be:
(1) termination analysis and termination analyzer,
(2) simulating termination analyzer,
(3) x86,
(4) x86 emulation,
(5) simulating termination analyzer based on an x86 emulator.
*That order has proven to not work*
People are getting stuck on x86 emulation.
In that case it is likely that no order that contains x86 emulation at
any point will not work.
The issue with this is that people believe that they
can disagree with the x86 language. That is the same
as disagreeing with arithmetic, not allowed.
Op 13.jul.2024 om 14:15 schreef olcott:
On 7/13/2024 2:48 AM, Mikko wrote:
On 2024-07-12 13:07:13 +0000, olcott said:
On 7/12/2024 2:49 AM, Mikko wrote:
On 2024-07-11 14:40:50 +0000, olcott said:
It is a hierarchy of prerequisites of knowledge.
Before anyone can understand a simulating termination
analyzer based on an x86 emulator they must understand
(1) x86 emulation
(2) Termination Analysis.
The order should be:
(1) termination analysis and termination analyzer,
(2) simulating termination analyzer,
(3) x86,
(4) x86 emulation,
(5) simulating termination analyzer based on an x86 emulator.
*That order has proven to not work*
People are getting stuck on x86 emulation.
In that case it is likely that no order that contains x86 emulation at
any point will not work.
The issue with this is that people believe that they
can disagree with the x86 language. That is the same
as disagreeing with arithmetic, not allowed.
The real issue is that olcott thinks he can change the semantics of the
x86 language at will. He thinks that the behaviour of a program does not change if it is halted halfway its execution. Therefore, he does not understand that when the simulation of a halting program is aborted
before it reaches its end, it is still a correct simulation according to
the semantics of the x86 language.
On 7/13/2024 2:48 AM, Mikko wrote:Doing the simulation at the level of C is sufficient.
On 2024-07-12 13:07:13 +0000, olcott said:
On 7/12/2024 2:49 AM, Mikko wrote:
On 2024-07-11 14:40:50 +0000, olcott said:
I explained x86 emulation in terms of a C language interpreter and the*That order has proven to not work* People are getting stuck on x86In that case it is likely that no order that contains x86 emulation at
emulation.
any point will work.
one detail of the x86 language that must be understood (the function
calling convention) so that C programmers can understand the first half
of my paper.
All of the rebuttals of my work remain anchored in disagreeing with theI have not seen reference to the assembly. What is the disagreement?
x86 language, they have no other basis.
On 7/13/2024 2:46 AM, Mikko wrote:
On 2024-07-12 13:07:59 +0000, olcott said:
On 7/12/2024 2:55 AM, Mikko wrote:
On 2024-07-11 14:16:34 +0000, olcott said:
On 7/11/2024 1:50 AM, Mikko wrote:
On 2024-07-10 13:37:30 +0000, olcott said:
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:A correct emulator can correctly any correct x86 instructions.
On 7/9/2024 1:14 AM, Mikko wrote:
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite >>>>>>>>>> execution can be inferred. That is best illustrated by the following >>>>>>>>>> examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates no more
}
The important difference is that in my examples there is a conditional
instruction that can (and does) prevent infinite exectuion. >>>>>>>>>>
When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return?
Why would anyone ask that? A question should make clear its topic. >>>>>>>> Instead one could ask whether HHH can fully emulate DDD if that is >>>>>>>> what one wants to know. Or one may think that HHH and DDD are so >>>>>>>> unimteresting that there is no point to ask anyting about them. >>>>>>>
When it emulates non-halting code then itself does not halt.
Not quite right but should be easy to fix. There should be a verb before "any",
for example "execute". Of course there still is a probelm with the meaning
"any correct x86 instructions". Intel may publish a new x86 processor that has
instructios that the emulator cannot know but are nevertheless correct x86
instructions because Intel says so. In the second sentence "it" should be used
istead of "itself".
Intel has already done this and they call this x64.
A 1907 Model-T Ford cannot have upgrades and still
be a 1907 model-T Ford. Likewise for the x86 language.
A new version of a 1907 Model-T Ford is possible and can have the same name
except that the "1907" must be replaced as it refers to the year. That the >>>> "Model-T" is also replaced is a free chioce of Ford.
Likewise Intel is free to call a new processor whatever they want to call it.
The x86 language is a fixed constant.
Where has Intel promised so?
Backward compatibility requires it. https://en.wikipedia.org/wiki/X86_assembly_language#:~:text=x86%20assembly%20language%20is%20the,was%20launched%20in%20April%201972.
On 7/13/2024 2:48 AM, Mikko wrote:
On 2024-07-12 13:07:13 +0000, olcott said:
On 7/12/2024 2:49 AM, Mikko wrote:
On 2024-07-11 14:40:50 +0000, olcott said:
It is a hierarchy of prerequisites of knowledge.
Before anyone can understand a simulating termination
analyzer based on an x86 emulator they must understand
(1) x86 emulation
(2) Termination Analysis.
The order should be:
(1) termination analysis and termination analyzer,
(2) simulating termination analyzer,
(3) x86,
(4) x86 emulation,
(5) simulating termination analyzer based on an x86 emulator.
*That order has proven to not work*
People are getting stuck on x86 emulation.
In that case it is likely that no order that contains x86 emulation at
any point will not work.
I explained x86 emulation in terms of a C language interpreter
and the one detail of the x86 language that must be understood
(the function calling convention) so that C programmers can
understand the first half of my paper.
Simulating Termination Analyzer H is Not Fooled by Pathological Input D https://www.researchgate.net/publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
All of the rebuttals of my work remain anchored in disagreeing
with the x86 language, they have no other basis.
On 7/14/2024 2:43 AM, Mikko wrote:
On 2024-07-13 12:07:18 +0000, olcott said:
On 7/13/2024 2:48 AM, Mikko wrote:
On 2024-07-12 13:07:13 +0000, olcott said:
On 7/12/2024 2:49 AM, Mikko wrote:
On 2024-07-11 14:40:50 +0000, olcott said:
It is a hierarchy of prerequisites of knowledge.
Before anyone can understand a simulating termination
analyzer based on an x86 emulator they must understand
(1) x86 emulation
(2) Termination Analysis.
The order should be:
(1) termination analysis and termination analyzer,
(2) simulating termination analyzer,
(3) x86,
(4) x86 emulation,
(5) simulating termination analyzer based on an x86 emulator.
*That order has proven to not work*
People are getting stuck on x86 emulation.
In that case it is likely that no order that contains x86 emulation at >>>> any point will not work.
I explained x86 emulation in terms of a C language interpreter
and the one detail of the x86 language that must be understood
(the function calling convention) so that C programmers can
understand the first half of my paper.
Simulating Termination Analyzer H is Not Fooled by Pathological Input D
https://www.researchgate.net/publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
All of the rebuttals of my work remain anchored in disagreeing
with the x86 language, they have no other basis.
The main error in your atricle is lack of proofs (i.e., sequences of
sentences that are either presented as assumtions or derived from
earlier sentences in the proof with truth preserving transformations).
In addtion, many of the defects already pointed out are still there.
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
On 7/14/2024 2:56 AM, Mikko wrote:
On 2024-07-13 11:57:59 +0000, olcott said:
On 7/13/2024 2:46 AM, Mikko wrote:
On 2024-07-12 13:07:59 +0000, olcott said:
On 7/12/2024 2:55 AM, Mikko wrote:
On 2024-07-11 14:16:34 +0000, olcott said:
On 7/11/2024 1:50 AM, Mikko wrote:
On 2024-07-10 13:37:30 +0000, olcott said:
On 7/10/2024 2:18 AM, Mikko wrote:
On 2024-07-09 14:14:16 +0000, olcott said:A correct emulator can correctly any correct x86 instructions. >>>>>>>>> When it emulates non-halting code then itself does not halt.
On 7/9/2024 1:14 AM, Mikko wrote:Why would anyone ask that? A question should make clear its topic. >>>>>>>>>> Instead one could ask whether HHH can fully emulate DDD if that is >>>>>>>>>> what one wants to know. Or one may think that HHH and DDD are so >>>>>>>>>> unimteresting that there is no point to ask anyting about them. >>>>>>>>>
On 2024-07-08 17:36:58 +0000, olcott said:
On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
Op 08.jul.2024 om 18:07 schreef olcott:
You believe that two equals infinity.
Try to show how infinity is one cycle too soon.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
Two cycles is enough to correctly determine that none >>>>>>>>>>>>> of the above functions correctly emulated by HHH can >>>>>>>>>>>>> possibly halt.
That you don't see this is ignorance or deception.
There is an important detail that determines whether an infinite >>>>>>>>>>>> execution can be inferred. That is best illustrated by the following
examples:
void Finite_Loop()
{
int x = 10000;
HERE:
if (x > 0) {
x--;
goto HERE;
}
}
void Finite_Recursion(int n)
{
if (n > 0) {
Finite_Recursion(n + 1);
}
}
void DDD()
{
HHH(DDD); // HHH detects recursive simulation and then simulates no more
}
The important difference is that in my examples there is a conditional
instruction that can (and does) prevent infinite exectuion. >>>>>>>>>>>>
When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return? >>>>>>>>>>
Not quite right but should be easy to fix. There should be a verb before "any",
for example "execute". Of course there still is a probelm with the meaning
"any correct x86 instructions". Intel may publish a new x86 processor that has
instructios that the emulator cannot know but are nevertheless correct x86
instructions because Intel says so. In the second sentence "it" should be used
istead of "itself".
Intel has already done this and they call this x64.
A 1907 Model-T Ford cannot have upgrades and still
be a 1907 model-T Ford. Likewise for the x86 language.
A new version of a 1907 Model-T Ford is possible and can have the same name
except that the "1907" must be replaced as it refers to the year. That the
"Model-T" is also replaced is a free chioce of Ford.
Likewise Intel is free to call a new processor whatever they want to call it.
The x86 language is a fixed constant.
Where has Intel promised so?
Backward compatibility requires it.
https://en.wikipedia.org/wiki/X86_assembly_language#:~:text=x86%20assembly%20language%20is%20the,was%20launched%20in%20April%201972.
That is about the assembly language, not about the machine instruction set. >> It does not say much about backwards compatibitlity and does not say that
Intel has promised anything about that.
Policy of backwards compatibilty does not mean that every x86 proscessor
has exactly the same machine language as 8086. Later version have introduced >> new instructions and new processor modes and Intel is not prohibited from
adding still more in future models. It only means that the meanings of the >> existing instructions are not changed when executed in existing modes.
When I refer to the x86 language I am referring to the minimal
subset that runs the same way on compatible Intel 32-bit processors.
On 7/15/2024 2:15 AM, Mikko wrote:
On 2024-07-14 14:15:45 +0000, olcott said:
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
No, it is false. What the input specifies is a property of the input alone. >> Whether some HHH is able to process it without looping forever is not a
property of the input and not relevant to the meaning of the input.
In other words you believe that you can correctly
ignore the verified fact that DDD correctly emulated
by HHH does call HHH(DDD) in recursive emulation.
On 7/15/2024 2:19 AM, Mikko wrote:
On 2024-07-14 14:26:21 +0000, olcott said:
When I refer to the x86 language I am referring to the minimal
subset that runs the same way on compatible Intel 32-bit processors.
Then you should specify a specific instruction set, preferably the one
that your compiler uses.
All this is a moot deflation away from the point.
You can see the actual code you can look up what
its instructions mean.
_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]
On 7/16/2024 1:58 AM, Mikko wrote:
On 2024-07-15 12:55:21 +0000, olcott said:
On 7/15/2024 2:15 AM, Mikko wrote:
On 2024-07-14 14:15:45 +0000, olcott said:
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
No, it is false. What the input specifies is a property of the input
alone.
Whether some HHH is able to process it without looping forever is not a >>>> property of the input and not relevant to the meaning of the input.
In other words you believe that you can correctly
ignore the verified fact that DDD correctly emulated
by HHH does call HHH(DDD) in recursive emulation.
It is not a fact and not verified but otherwise, yes, that is not
relevant.
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
On 7/16/2024 1:58 AM, Mikko wrote:
On 2024-07-15 12:55:21 +0000, olcott said:
On 7/15/2024 2:15 AM, Mikko wrote:
On 2024-07-14 14:15:45 +0000, olcott said:
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
No, it is false. What the input specifies is a property of the input alone.
Whether some HHH is able to process it without looping forever is not a >>>> property of the input and not relevant to the meaning of the input.
In other words you believe that you can correctly
ignore the verified fact that DDD correctly emulated
by HHH does call HHH(DDD) in recursive emulation.
It is not a fact and not verified but otherwise, yes, that is not relevant. >>
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
On 7/17/2024 1:43 AM, Mikko wrote:
On 2024-07-16 14:21:28 +0000, olcott said:
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
DDD does not stop runnig unless it is completely exeuted.
_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:32 AM, Fred. Zwarts wrote:
Op 17.jul.2024 om 15:00 schreef olcott:*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
On 7/17/2024 1:43 AM, Mikko wrote:
On 2024-07-16 14:21:28 +0000, olcott said:
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
DDD does not stop runnig unless it is completely exeuted.
_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 'unless aborted' is misleading, since we know that HHH *does* abort.
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 9:08 AM, Fred. Zwarts wrote:
Op 17.jul.2024 om 15:39 schreef olcott:
On 7/17/2024 8:32 AM, Fred. Zwarts wrote:
Op 17.jul.2024 om 15:00 schreef olcott:*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
On 7/17/2024 1:43 AM, Mikko wrote:
On 2024-07-16 14:21:28 +0000, olcott said:
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
DDD does not stop runnig unless it is completely exeuted.
_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 'unless aborted' is misleading, since we know that HHH *does*
abort.
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.
But HHH is programmed to abort after N cycles,
_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 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
No DDD of the infinite set of every HHH/DDD pair reaches
past its machine address 0000216b thus never halts. Every
HHH either aborts its simulation or DDD never stops running.
On 7/17/2024 1:43 AM, Mikko wrote:
On 2024-07-16 14:21:28 +0000, olcott said:
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
DDD does not stop runnig unless it is completely exeuted.
_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/18/2024 2:40 AM, Mikko wrote:
On 2024-07-17 13:00:55 +0000, olcott said:
On 7/17/2024 1:43 AM, Mikko wrote:
On 2024-07-16 14:21:28 +0000, olcott said:
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
DDD does not stop runnig unless it is completely exeuted.
_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 mean HHH's simulation of DDD may not termite before HHH aborts it?
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.
When each DDD of the HHH/DDD pairs above is correctly emulated
by its corresponding HHH according to the semantic meaning of its
x86 instructions it CANNOT POSSIBLY reach past its own machine
address 0000216b, not even by an act of God.
The behaviour specified by DDD, both by C semantics and by x86 semantics,
is halting if HHH returns. Otherwise HHH is not a decider.
When HHH is required to be a pure function then only one element
of the above infinite set of every possible HHH/DDD is not a decider.
On 7/18/2024 9:13 AM, Fred. Zwarts wrote:
Op 18.jul.2024 om 15:17 schreef olcott:
On 7/18/2024 2:40 AM, Mikko wrote:
On 2024-07-17 13:00:55 +0000, olcott said:
On 7/17/2024 1:43 AM, Mikko wrote:
On 2024-07-16 14:21:28 +0000, olcott said:
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
DDD does not stop runnig unless it is completely exeuted.
_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 mean HHH's simulation of DDD may not termite before HHH aborts it?
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 we have proved that each of these infinite set of simulations is
incorrect.
When each DDD of the HHH/DDD pairs above is correctly emulated
by its corresponding HHH according to the semantic meaning of its
x86 instructions it CANNOT POSSIBLY reach past its own machine
address 0000216b, not even by an act of God.
Which proves that the simulation is incorrect.
As long as each instruction is simulated according to its
semantic meaning then even of God himself disagrees that it
is correct then God himself is wrong.
On 7/18/2024 2:40 AM, Mikko wrote:
On 2024-07-17 13:00:55 +0000, olcott said:
On 7/17/2024 1:43 AM, Mikko wrote:
On 2024-07-16 14:21:28 +0000, olcott said:
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
DDD does not stop runnig unless it is completely exeuted.
_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 mean HHH's simulation of DDD may not termite before HHH aborts it?
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.
When each DDD of the HHH/DDD pairs above is correctly emulated
by its corresponding HHH according to the semantic meaning of its
x86 instructions it CANNOT POSSIBLY reach past its own machine
address 0000216b, not even by an act of God.
The behaviour specified by DDD, both by C semantics and by x86 semantics,
is halting if HHH returns. Otherwise HHH is not a decider.
When HHH is required to be a pure function then only one element
of the above infinite set of every possible HHH/DDD is not a decider.
On 7/19/2024 3:51 AM, Mikko wrote:That would be HHH_oo, which is arguably not a member of that set.
On 2024-07-18 13:17:22 +0000, olcott said:No I don't mean that at all that incorrectly allocates the error to the emulator.
On 7/18/2024 2:40 AM, Mikko wrote:
On 2024-07-17 13:00:55 +0000, olcott said:
On 7/17/2024 1:43 AM, Mikko wrote:
On 2024-07-16 14:21:28 +0000, olcott said:
When simulated input DDD stops running {if and only if} the
simulation of this input DDD has been aborted this necessitates
that input DDD specifies non-halting behavior
DDD does not stop runnig unless it is completely exeuted.
_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 mean HHH's simulation of DDD may not termite before HHH aborts
it?
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.
When each DDD of the HHH/DDD pairs above is correctly emulated by its
corresponding HHH according to the semantic meaning of its x86
instructions it CANNOT POSSIBLY reach past its own machine address
0000216b, not even by an act of God.
You apparently mean that no HHHᵢ can simulate the corresponding DDDᵢ to >> its termination?
No DDDᵢ correctly emulated by its corresponding HHHᵢ can possibly reach past it own machine address 0000216b because each DDDᵢ calls its corresponding HHHᵢ in recursive emulation.
For every finite i the behaviour specified by DDDᵢ is halting.Unless DDDᵢ correctly emulated by its corresponding HHHᵢ can reach its own machine address 00002174 it cannot halt.
One HHH element of the above set of pairs never halts and thus is not a decider. Every other HHH is a decider.The behavour of DDDᵢ depends on what HHHᵢ does. Wheter HHHᵢ is requiredThe behaviour specified by DDD, both by C semantics and by x86When HHH is required to be a pure function then only one element of
semantics,
is halting if HHH returns. Otherwise HHH is not a decider.
the above infinite set of every possible HHH/DDD is not a decider.
to what it does has no evvect on the behaviour of DDDᵢ.
A pair is never a decider.
Not one DDD element of the infinite set of every possible HHH/DDD halts,Of course they do. They all do nothing but call a halting HHH.
thus every HHH that halts is correct to reject its input as non-halting.
On 7/19/2024 3:51 AM, Mikko wrote:
On 2024-07-18 13:17:22 +0000, olcott said:
On 7/18/2024 2:40 AM, Mikko wrote:
On 2024-07-17 13:00:55 +0000, olcott said:
On 7/17/2024 1:43 AM, Mikko wrote:
On 2024-07-16 14:21:28 +0000, olcott said:
When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior
DDD does not stop runnig unless it is completely exeuted.
_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 mean HHH's simulation of DDD may not termite before HHH aborts it?
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.
When each DDD of the HHH/DDD pairs above is correctly emulated
by its corresponding HHH according to the semantic meaning of its
x86 instructions it CANNOT POSSIBLY reach past its own machine
address 0000216b, not even by an act of God.
You apparently mean that no HHHᵢ can simulate the corresponding DDDᵢ to >> its termination?
No I don't mean that at all that incorrectly allocates the error
to the emulator.
No DDDᵢ correctly emulated by its corresponding HHHᵢ can
possibly reach past it own machine address 0000216b because
each DDDᵢ calls its corresponding HHHᵢ in recursive emulation.
For every finite i the behaviour specified by DDDᵢ is
halting.
Unless DDDᵢ correctly emulated by its corresponding HHHᵢ
can reach its own machine address 00002174 it cannot halt.
The behaviour specified by DDD, both by C semantics and by x86 semantics, >>>> is halting if HHH returns. Otherwise HHH is not a decider.
When HHH is required to be a pure function then only one element
of the above infinite set of every possible HHH/DDD is not a decider.
The behavour of DDDᵢ depends on what HHHᵢ does. Wheter HHHᵢ is required
to what it does has no evvect on the behaviour of DDDᵢ.
A pair is never a decider.
One HHH element of the above set of pairs never halts
and thus is not a decider. Every other HHH is a decider.
Not one DDD element of the infinite set of every possible
HHH/DDD halts, thus every HHH that halts is correct to
reject its input as non-halting.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 148:14:34 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,740 |