On 8/26/2024 7:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/08/2024 22:07, Ben Bacarisse wrote:
joes <noreply@example.org> writes:
Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:We don't really know what context Sipser was given. I got in touch at >>>> the time so do I know he had enough context to know that PO's ideas
Professor Sipser clearly agreed that an H that does a finite
simulation
of D is to predict the behavior of an unlimited simulation of D.
If the simulator *itself* would not abort. The H called by D is,
by construction, the same and *does* abort.
were
"wacky" and that had agreed to what he considered a "minor remark".
Since PO considers his words finely crafted and key to his so-called
work I think it's clear that Sipser did not take the "minor remark" he >>>> agreed to to mean what PO takes it to mean! My own take if that he
(Sipser) read it as a general remark about how to determine some cases, >>>> i.e. that D names an input that H can partially simulate to determine
it's halting or otherwise. We all know or could construct some such
cases.
Exactly my reading. It makes Sipser's agreement natural, because it is >>> both correct [with sensible interpretation of terms], and moreover
describes an obvious strategy that a partial decider might use that can
decide halting for some specific cases. No need for Sipser to be
deceptive
or misleading here, when the truth suffices. (In particular no need to >>> employ "tricksy" vacuous truth get out clauses just to get PO off his
back
as some have suggested.)
Yes, and it fits with his thinking it a "trivial remark". Mind you I
can't help I feeling really annoyed that a respected academic is having
his name repeated dragged into this nonsense by PO.
That aside, it's such an odd way to present an argument: "I managed to
trick X into saying 'yes' to something vague". In any reasonable
collegiate exchange you'd go back and check: "So even when D is
constructed from H, H can return based on what /would/ happen if H did
not stop simulating so that H(D,D) == false is correct even though D(D)
halts?". Just imagine what Sipser would say to that!
Academic exchange thrives on clarity. Cranks thrive on smoke and
mirrors.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
stuff
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
On 8/27/2024 3:58 AM, Fred. Zwarts wrote:
Op 27.aug.2024 om 01:03 schreef olcott:
On 8/26/2024 7:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/08/2024 22:07, Ben Bacarisse wrote:
joes <noreply@example.org> writes:
Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:We don't really know what context Sipser was given. I got in
Professor Sipser clearly agreed that an H that does a finiteIf the simulator *itself* would not abort. The H called by D is, >>>>>>> by construction, the same and *does* abort.
simulation
of D is to predict the behavior of an unlimited simulation of D. >>>>>>>
touch at
the time so do I know he had enough context to know that PO's
ideas were
"wacky" and that had agreed to what he considered a "minor remark". >>>>>> Since PO considers his words finely crafted and key to his so-called >>>>>> work I think it's clear that Sipser did not take the "minor
remark" he
agreed to to mean what PO takes it to mean! My own take if that he >>>>>> (Sipser) read it as a general remark about how to determine some
cases,
i.e. that D names an input that H can partially simulate to determine >>>>>> it's halting or otherwise. We all know or could construct some such >>>>>> cases.
Exactly my reading. It makes Sipser's agreement natural, because
it is
both correct [with sensible interpretation of terms], and moreover
describes an obvious strategy that a partial decider might use that
can
decide halting for some specific cases. No need for Sipser to be
deceptive
or misleading here, when the truth suffices. (In particular no
need to
employ "tricksy" vacuous truth get out clauses just to get PO off
his back
as some have suggested.)
Yes, and it fits with his thinking it a "trivial remark". Mind you I >>>> can't help I feeling really annoyed that a respected academic is having >>>> his name repeated dragged into this nonsense by PO.
That aside, it's such an odd way to present an argument: "I managed to >>>> trick X into saying 'yes' to something vague". In any reasonable
collegiate exchange you'd go back and check: "So even when D is
constructed from H, H can return based on what /would/ happen if H did >>>> not stop simulating so that H(D,D) == false is correct even though D(D) >>>> halts?". Just imagine what Sipser would say to that!
Academic exchange thrives on clarity. Cranks thrive on smoke and
mirrors.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
Only, because the simulation stopped, so that it skipped the halting
part.
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
No, all these years you did not realise that the simulation deviated
from the semantics of the x86 language by skipping the last few
instructions of a halting program.
*The abort code has been disabled*
*The abort code has been disabled*
*The abort code has been disabled*
DDD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 6862210000 push 00002162
[0000216a] e853f4ffff call 000015c2
[0000216f] 83c404 add esp,+04
[00002172] 5d pop ebp
[00002173] c3 ret
Size in bytes:(0018) [00002173]
*Limited to 20,000,000 total instructions*
*Limited to 20,000,000 total instructions*
*Limited to 20,000,000 total instructions*
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== ============= [00002182][00103806][00000000] 55 push ebp ; begin main
[00002183][00103806][00000000] 8bec mov ebp,esp [00002185][00103802][00002162] 6862210000 push 00002162 ; push DDD [0000218a][001037fe][0000218f] e833f4ffff call 000015c2 ; call HHH
New slave_stack at:1038aa
Begin Local Halt Decider Simulation Execution Trace Stored at:1138b2 [00002162][001138a2][001138a6] 55 push ebp [00002163][001138a2][001138a6] 8bec mov ebp,esp [00002165][0011389e][00002162] 6862210000 push 00002162 ; push DDD [0000216a][0011389a][0000216f] e853f4ffff call 000015c2 ; call HHH
New slave_stack at:14e2d2
[00002162][0015e2ca][0015e2ce] 55 push ebp [00002163][0015e2ca][0015e2ce] 8bec mov ebp,esp [00002165][0015e2c6][00002162] 6862210000 push 00002162 ; push DDD [0000216a][0015e2c2][0000216f] e853f4ffff call 000015c2 ; call HHH
New slave_stack at:15e372
[00002162][0016e36a][0016e36e] 55 push ebp [00002163][0016e36a][0016e36e] 8bec mov ebp,esp [00002165][0016e366][00002162] 6862210000 push 00002162 ; push DDD [0000216a][0016e362][0000216f] e853f4ffff call 000015c2 ; call HHH
New slave_stack at:16e412
[00002162][0017e40a][0017e40e] 55 push ebp [00002163][0017e40a][0017e40e] 8bec mov ebp,esp [00002165][0017e406][00002162] 6862210000 push 00002162 ; push DDD [0000216a][0017e402][0000216f] e853f4ffff call 000015c2 ; call HHH
Number of Instructions Executed(20000000) == 298507 Pages
On 8/27/2024 3:58 AM, Fred. Zwarts wrote:So, you changed the subject to another input for the simulator.
Op 27.aug.2024 om 01:03 schreef olcott:
On 8/26/2024 7:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/08/2024 22:07, Ben Bacarisse wrote:
joes <noreply@example.org> writes:
Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:We don't really know what context Sipser was given. I got in
Professor Sipser clearly agreed that an H that does a finiteIf the simulator *itself* would not abort. The H called by D is, >>>>>>> by construction, the same and *does* abort.
simulation
of D is to predict the behavior of an unlimited simulation of D. >>>>>>>
touch at
the time so do I know he had enough context to know that PO's
ideas were
"wacky" and that had agreed to what he considered a "minor remark". >>>>>> Since PO considers his words finely crafted and key to his so-called >>>>>> work I think it's clear that Sipser did not take the "minor
remark" he
agreed to to mean what PO takes it to mean! My own take if that he >>>>>> (Sipser) read it as a general remark about how to determine some
cases,
i.e. that D names an input that H can partially simulate to determine >>>>>> it's halting or otherwise. We all know or could construct some such >>>>>> cases.
Exactly my reading. It makes Sipser's agreement natural, because
it is
both correct [with sensible interpretation of terms], and moreover
describes an obvious strategy that a partial decider might use that
can
decide halting for some specific cases. No need for Sipser to be
deceptive
or misleading here, when the truth suffices. (In particular no
need to
employ "tricksy" vacuous truth get out clauses just to get PO off
his back
as some have suggested.)
Yes, and it fits with his thinking it a "trivial remark". Mind you I >>>> can't help I feeling really annoyed that a respected academic is having >>>> his name repeated dragged into this nonsense by PO.
That aside, it's such an odd way to present an argument: "I managed to >>>> trick X into saying 'yes' to something vague". In any reasonable
collegiate exchange you'd go back and check: "So even when D is
constructed from H, H can return based on what /would/ happen if H did >>>> not stop simulating so that H(D,D) == false is correct even though D(D) >>>> halts?". Just imagine what Sipser would say to that!
Academic exchange thrives on clarity. Cranks thrive on smoke and
mirrors.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
Only, because the simulation stopped, so that it skipped the halting
part.
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
No, all these years you did not realise that the simulation deviated
from the semantics of the x86 language by skipping the last few
instructions of a halting program.
*The abort code has been disabled*
*The abort code has been disabled*
*The abort code has been disabled*
On 8/28/2024 4:06 AM, Fred. Zwarts wrote:
Op 27.aug.2024 om 15:07 schreef olcott:
On 8/27/2024 3:58 AM, Fred. Zwarts wrote:
Op 27.aug.2024 om 01:03 schreef olcott:
On 8/26/2024 7:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/08/2024 22:07, Ben Bacarisse wrote:
joes <noreply@example.org> writes:
Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:We don't really know what context Sipser was given. I got in >>>>>>>> touch at
Professor Sipser clearly agreed that an H that does a finite >>>>>>>>>> simulationIf the simulator *itself* would not abort. The H called by D is, >>>>>>>>> by construction, the same and *does* abort.
of D is to predict the behavior of an unlimited simulation of D. >>>>>>>>>
the time so do I know he had enough context to know that PO's
ideas were
"wacky" and that had agreed to what he considered a "minor remark". >>>>>>>> Since PO considers his words finely crafted and key to his so- >>>>>>>> called
work I think it's clear that Sipser did not take the "minor
remark" he
agreed to to mean what PO takes it to mean! My own take if that he >>>>>>>> (Sipser) read it as a general remark about how to determine some >>>>>>>> cases,
i.e. that D names an input that H can partially simulate to
determine
it's halting or otherwise. We all know or could construct some >>>>>>>> such
cases.
Exactly my reading. It makes Sipser's agreement natural, because >>>>>>> it is
both correct [with sensible interpretation of terms], and moreover >>>>>>> describes an obvious strategy that a partial decider might use
that can
decide halting for some specific cases. No need for Sipser to be >>>>>>> deceptive
or misleading here, when the truth suffices. (In particular no >>>>>>> need to
employ "tricksy" vacuous truth get out clauses just to get PO off >>>>>>> his back
as some have suggested.)
Yes, and it fits with his thinking it a "trivial remark". Mind you I >>>>>> can't help I feeling really annoyed that a respected academic is
having
his name repeated dragged into this nonsense by PO.
That aside, it's such an odd way to present an argument: "I
managed to
trick X into saying 'yes' to something vague". In any reasonable >>>>>> collegiate exchange you'd go back and check: "So even when D is
constructed from H, H can return based on what /would/ happen if H >>>>>> did
not stop simulating so that H(D,D) == false is correct even though >>>>>> D(D)
halts?". Just imagine what Sipser would say to that!
Academic exchange thrives on clarity. Cranks thrive on smoke and >>>>>> mirrors.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
Only, because the simulation stopped, so that it skipped the halting
part.
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
No, all these years you did not realise that the simulation deviated
from the semantics of the x86 language by skipping the last few
instructions of a halting program.
*The abort code has been disabled*
*The abort code has been disabled*
*The abort code has been disabled*
So, you changed the subject to another input for the simulator.
<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
I proved the *simulated DDD would never stop running unless aborted*
I proved the *simulated DDD would never stop running unless aborted*
I proved the *simulated DDD would never stop running unless aborted*
On 8/28/2024 7:39 AM, Fred. Zwarts wrote:
Op 28.aug.2024 om 13:57 schreef olcott:
On 8/28/2024 4:06 AM, Fred. Zwarts wrote:
Op 27.aug.2024 om 15:07 schreef olcott:
On 8/27/2024 3:58 AM, Fred. Zwarts wrote:
Op 27.aug.2024 om 01:03 schreef olcott:
On 8/26/2024 7:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>
On 23/08/2024 22:07, Ben Bacarisse wrote:
joes <noreply@example.org> writes:
Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:We don't really know what context Sipser was given. I got in >>>>>>>>>> touch at
Professor Sipser clearly agreed that an H that does a finite >>>>>>>>>>>> simulation
of D is to predict the behavior of an unlimited simulation >>>>>>>>>>>> of D.
If the simulator *itself* would not abort. The H called by D is, >>>>>>>>>>> by construction, the same and *does* abort.
the time so do I know he had enough context to know that PO's >>>>>>>>>> ideas were
"wacky" and that had agreed to what he considered a "minor >>>>>>>>>> remark".
Since PO considers his words finely crafted and key to his so- >>>>>>>>>> called
work I think it's clear that Sipser did not take the "minor >>>>>>>>>> remark" he
agreed to to mean what PO takes it to mean! My own take if >>>>>>>>>> that he
(Sipser) read it as a general remark about how to determine >>>>>>>>>> some cases,
i.e. that D names an input that H can partially simulate to >>>>>>>>>> determine
it's halting or otherwise. We all know or could construct >>>>>>>>>> some such
cases.
Exactly my reading. It makes Sipser's agreement natural,
because it is
both correct [with sensible interpretation of terms], and moreover >>>>>>>>> describes an obvious strategy that a partial decider might use >>>>>>>>> that can
decide halting for some specific cases. No need for Sipser to >>>>>>>>> be deceptive
or misleading here, when the truth suffices. (In particular no >>>>>>>>> need to
employ "tricksy" vacuous truth get out clauses just to get PO >>>>>>>>> off his back
as some have suggested.)
Yes, and it fits with his thinking it a "trivial remark". Mind >>>>>>>> you I
can't help I feeling really annoyed that a respected academic is >>>>>>>> having
his name repeated dragged into this nonsense by PO.
That aside, it's such an odd way to present an argument: "I
managed to
trick X into saying 'yes' to something vague". In any reasonable >>>>>>>> collegiate exchange you'd go back and check: "So even when D is >>>>>>>> constructed from H, H can return based on what /would/ happen if >>>>>>>> H did
not stop simulating so that H(D,D) == false is correct even
though D(D)
halts?". Just imagine what Sipser would say to that!
Academic exchange thrives on clarity. Cranks thrive on smoke and >>>>>>>> mirrors.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches >>>>>>> its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
Only, because the simulation stopped, so that it skipped the
halting part.
For all the years people said that this simulation is incorrect >>>>>>> never realizing that they were disagreeing with the semantics
of the x86 language.
No, all these years you did not realise that the simulation
deviated from the semantics of the x86 language by skipping the
last few instructions of a halting program.
*The abort code has been disabled*
*The abort code has been disabled*
*The abort code has been disabled*
So, you changed the subject to another input for the simulator.
<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
I proved the *simulated DDD would never stop running unless aborted*
I proved the *simulated DDD would never stop running unless aborted*
I proved the *simulated DDD would never stop running unless aborted*
You keep repeating irrelevant sentences. We know that DDD is aborted,
so the 'unless' always applies. This transforms these sentences into:
I proved the *simulated DDD stopped running because the simulation
aborts*
That is correct.
DDD would never stop running when emulated by a hypothetical
HHH that never aborts. The actual HHH can see this through a
kind of mathematical induction.
All simulating termination analyzers operate under this same
principle otherwise they would always determine that infinite
loops always halt.
This group is for discussions about the theory of computation and related topics. Discussion about people is off-topic.
On 8/28/2024 4:06 AM, Fred. Zwarts wrote:
Op 27.aug.2024 om 15:07 schreef olcott:
On 8/27/2024 3:58 AM, Fred. Zwarts wrote:
Op 27.aug.2024 om 01:03 schreef olcott:
On 8/26/2024 7:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/08/2024 22:07, Ben Bacarisse wrote:
joes <noreply@example.org> writes:
Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:We don't really know what context Sipser was given. I got in >>>>>>>> touch at
Professor Sipser clearly agreed that an H that does a finite >>>>>>>>>> simulationIf the simulator *itself* would not abort. The H called by D is, >>>>>>>>> by construction, the same and *does* abort.
of D is to predict the behavior of an unlimited simulation of D. >>>>>>>>>
the time so do I know he had enough context to know that PO's
ideas were
"wacky" and that had agreed to what he considered a "minor remark". >>>>>>>> Since PO considers his words finely crafted and key to his
so-called
work I think it's clear that Sipser did not take the "minor
remark" he
agreed to to mean what PO takes it to mean! My own take if that he >>>>>>>> (Sipser) read it as a general remark about how to determine some >>>>>>>> cases,
i.e. that D names an input that H can partially simulate to
determine
it's halting or otherwise. We all know or could construct some >>>>>>>> such
cases.
Exactly my reading. It makes Sipser's agreement natural, because >>>>>>> it is
both correct [with sensible interpretation of terms], and moreover >>>>>>> describes an obvious strategy that a partial decider might use
that can
decide halting for some specific cases. No need for Sipser to be >>>>>>> deceptive
or misleading here, when the truth suffices. (In particular no >>>>>>> need to
employ "tricksy" vacuous truth get out clauses just to get PO off >>>>>>> his back
as some have suggested.)
Yes, and it fits with his thinking it a "trivial remark". Mind you I >>>>>> can't help I feeling really annoyed that a respected academic is
having
his name repeated dragged into this nonsense by PO.
That aside, it's such an odd way to present an argument: "I
managed to
trick X into saying 'yes' to something vague". In any reasonable >>>>>> collegiate exchange you'd go back and check: "So even when D is
constructed from H, H can return based on what /would/ happen if H >>>>>> did
not stop simulating so that H(D,D) == false is correct even though >>>>>> D(D)
halts?". Just imagine what Sipser would say to that!
Academic exchange thrives on clarity. Cranks thrive on smoke and >>>>>> mirrors.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
Only, because the simulation stopped, so that it skipped the halting
part.
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
No, all these years you did not realise that the simulation deviated
from the semantics of the x86 language by skipping the last few
instructions of a halting program.
*The abort code has been disabled*
*The abort code has been disabled*
*The abort code has been disabled*
So, you changed the subject to another input for the simulator.
<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
I proved the *simulated DDD would never stop running unless aborted*
I proved the *simulated DDD would never stop running unless aborted*
I proved the *simulated DDD would never stop running unless aborted*
That other input will most probably not halt. And the simulator fails
to produce the correct prediction.
This is completely irrelevant for the different input where the abort
code is enabled.
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>
HHH can abort its simulation of DDD and correctly report that DDD
specifies a non-halting sequence of configurations.
Can we now return to the original input that has the abort code
enabled and which halts and for which the correct prediction must be
that it halts?
On 8/28/2024 2:37 AM, Mikko wrote:
This group is for discussions about the theory of computation and related
topics. Discussion about people is off-topic.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
Now that I point this out all that I get for "rebuttal" is bluster
and double talk.
The same thing applies to this more complex example that
is simply over-the-head of most reviewers:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
On 28/08/24 09:37, Mikko wrote:
This group is for discussions about the theory of computation and related
topics. Discussion about people is off-topic.
there is no moderation, so people are even free to post about cheap
viagra if they want.
On 8/29/2024 2:46 AM, Mikko wrote:
On 2024-08-28 11:51:51 +0000, olcott said:
On 8/28/2024 2:37 AM, Mikko wrote:
This group is for discussions about the theory of computation and
related
topics. Discussion about people is off-topic.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
Now that I point this out all that I get for "rebuttal" is bluster
and double talk.
The same thing applies to this more complex example that
is simply over-the-head of most reviewers:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Nice to see that you don't disagree.
But you should not use subject lines that are off-topic for the group.
When a specific reviewer makes a specific mistake in
reviewing my work related to this group I must refer
to that specific reviewer's mistake to clear my name.
I could generalize it. No one person here besides myself
sufficiently understands the details of how a simulating
halt decider computes the mapping from an input finite
string to the behavior that this finite sting specifies.
I specifically referred to Ben because he got everything
else correctly. Most everyone else cannot even understand
that correct simulation is defined by HHH emulating DDD
according to the semantics of the x86 language.
Fred thinks the when DDD is emulated by HHH according to
the semantics of the x86 language and this causes an
emulated HHH to not halt then the emulation is wrong.
simlation
On 8/29/2024 2:46 AM, Mikko wrote:
On 2024-08-28 11:51:51 +0000, olcott said:
On 8/28/2024 2:37 AM, Mikko wrote:
This group is for discussions about the theory of computation and
related
topics. Discussion about people is off-topic.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
Now that I point this out all that I get for "rebuttal" is bluster
and double talk.
The same thing applies to this more complex example that
is simply over-the-head of most reviewers:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Nice to see that you don't disagree.
But you should not use subject lines that are off-topic for the group.
When a specific reviewer makes a specific mistake in
reviewing my work related to this group I must refer
to that specific reviewer's mistake to clear my name.
I could generalize it. No one person here besides myself
sufficiently understands the details of how a simulating
halt decider computes the mapping from an input finite
string to the behavior that this finite sting specifies.
I specifically referred to Ben because he got everything
else correctly. Most everyone else cannot even understand
that correct simulation is defined by HHH emulating DDD
according to the semantics of the x86 language.
Fred thinks the when DDD is emulated by HHH according to
the semantics of the x86 language and this causes an
emulated HHH to not halt then the emulation is wrong.
simlation
On 8/29/2024 12:39 PM, Fred. Zwarts wrote:
Op 29.aug.2024 om 15:44 schreef olcott:
On 8/29/2024 2:46 AM, Mikko wrote:
On 2024-08-28 11:51:51 +0000, olcott said:
On 8/28/2024 2:37 AM, Mikko wrote:
This group is for discussions about the theory of computation and
related
topics. Discussion about people is off-topic.
Try to point to the tiniest lack of clarity in this fully
specified concrete example.
void DDD()
{
HHH(DDD);
return;
}
_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]
HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.
For all the years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.
Now that I point this out all that I get for "rebuttal" is bluster
and double talk.
The same thing applies to this more complex example that
is simply over-the-head of most reviewers:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Nice to see that you don't disagree.
But you should not use subject lines that are off-topic for the group. >>>>
When a specific reviewer makes a specific mistake in
reviewing my work related to this group I must refer
to that specific reviewer's mistake to clear my name.
I could generalize it. No one person here besides myself
sufficiently understands the details of how a simulating
halt decider computes the mapping from an input finite
string to the behavior that this finite sting specifies.
It looks more that you are the only person that does not understand
these details, but who thinks that his dreams are a nice substitute
for facts.
I specifically referred to Ben because he got everything
else correctly. Most everyone else cannot even understand
that correct simulation is defined by HHH emulating DDD
according to the semantics of the x86 language.
Olcott does not even understand what the semantics of the x86 language
is. He thinks that a finite string can have different behaviours
according to the semantics of the x86 language, depending on whether
it is directly executed, or simulated by different simulators, where
the semantics could be different for each simulator.
One cannot simply ignore the actual behavior of DDD emulated
by HHH according to the semantics of the x86 language because
this actual behavior is not the behavior that one expects or
one would like to have.
An actual world class emulator is correctly emulating this.
One is not free to disagree without being WRONG.
Op 29.aug.2024 om 23:13 schreef olcott:
One cannot simply ignore the actual behavior of DDD emulated
by HHH according to the semantics of the x86 language because
this actual behavior is not the behavior that one expects or
one would like to have.
You cannot deny the semantics of the x86 language simply because you do
not like it, or you prefer another behaviour.
The specification of the semantics of the x86 language does not give
room for a context depending interpretation. It is independent on which processor, or which simulator processes this finite string.
On 8/30/2024 3:32 AM, Fred. Zwarts wrote:
Op 29.aug.2024 om 23:13 schreef olcott:
One cannot simply ignore the actual behavior of DDD emulated
by HHH according to the semantics of the x86 language because
this actual behavior is not the behavior that one expects or
one would like to have.
You cannot deny the semantics of the x86 language simply because you
do not like it, or you prefer another behaviour.
The specification of the semantics of the x86 language does not give
room for a context depending interpretation. It is independent on
which processor, or which simulator processes this finite string.
*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*
The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH
and all four of them are emulated by the world
class x86 emulator libx86emu
It is easy to see that when the executed HHH emulates
DDD that it does this correctly when we look at the
execution trace and see the the first four instructions
of DDD are listed.
_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]
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55 push ebp ; housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Then this emulated DDD calls an emulated HHH(DDD).
It is easy to see that when the executed HHH emulates
itself emulated DDD that it does this correctly when we
look at the execution trace and see the the first four
instructions of DDD are listed again.
On 8/29/2024 2:54 AM, Mikko wrote:
On 2024-08-28 15:49:20 +0000, immibis said:
On 28/08/24 09:37, Mikko wrote:
This group is for discussions about the theory of computation and
related
topics. Discussion about people is off-topic.
there is no moderation, so people are even free to post about cheap
viagra if they want.
Administrators or servers may prevent those that post too musch spam.
Other than that, nobody prevents off-topic posts. We may point out to
posters or adimistrators that if a message is off-topic or harmful to
dicsussion. Adminstrotors hardly care unless there are too many such
posts.
When some specific person makes a key mistake that results
in the incorrect denigration of my life's work I correct this
specific person's specific mistake.
On 8/30/2024 8:46 AM, Fred. Zwarts wrote:
Op 30.aug.2024 om 15:05 schreef olcott:
On 8/30/2024 3:32 AM, Fred. Zwarts wrote:
Op 29.aug.2024 om 23:13 schreef olcott:
One cannot simply ignore the actual behavior of DDD emulated
by HHH according to the semantics of the x86 language because
this actual behavior is not the behavior that one expects or
one would like to have.
You cannot deny the semantics of the x86 language simply because you
do not like it, or you prefer another behaviour.
The specification of the semantics of the x86 language does not give
room for a context depending interpretation. It is independent on
which processor, or which simulator processes this finite string.
*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*
The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH
Not according to the unmodified world calls simulator, which, when
given the same input shows that the DDD based on the aborting HHH, halts.
And after a few recursions HHH sees a 'special condition' after which
and all four of them are emulated by the world
class x86 emulator libx86emu
It is easy to see that when the executed HHH emulates
DDD that it does this correctly when we look at the
execution trace and see the the first four instructions
of DDD are listed.
_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]
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55 push ebp ; housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Then this emulated DDD calls an emulated HHH(DDD).
It is easy to see that when the executed HHH emulates
itself emulated DDD that it does this correctly when we
look at the execution trace and see the the first four
instructions of DDD are listed again.
it aborts and halt.
If you cannot see that this special condition conclusively
proves that HHH must abort its emulation of DDD to prevent
the infinite exection of DDD then you have insufficient
technical competence.
If you can see this then you understand that this criteria has been met:
<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
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Here is is with 100 millions instructions and NO ABORT
_DDD()
[00002137] 55 push ebp
[00002138] 8bec mov ebp,esp
[0000213a] 6837210000 push 00002137
[0000213f] e853f4ffff call 00001597
[00002144] 83c404 add esp,+04
[00002147] 5d pop ebp
[00002148] c3 ret
Size in bytes:(0018) [00002148]
_main()
[00002157] 55 push ebp
[00002158] 8bec mov ebp,esp
[0000215a] e8d8ffffff call 00002137
[0000215f] 33c0 xor eax,eax
[00002161] 5d pop ebp
[00002162] c3 ret
Size in bytes:(0012) [00002162]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00002157][0010379f][00000000] 55 push ebp [00002158][0010379f][00000000] 8bec mov ebp,esp [0000215a][0010379b][0000215f] e8d8ffffff call 00002137 [00002137][00103797][0010379f] 55 push ebp [00002138][00103797][0010379f] 8bec mov ebp,esp [0000213a][00103793][00002137] 6837210000 push 00002137 [0000213f][0010378f][00002144] e853f4ffff call 00001597
New slave_stack at:103843
Begin Local Halt Decider Simulation Execution Trace Stored at:11384b [00002137][0011383b][0011383f] 55 push ebp [00002138][0011383b][0011383f] 8bec mov ebp,esp [0000213a][00113837][00002137] 6837210000 push 00002137 [0000213f][00113833][00002144] e853f4ffff call 00001597
New slave_stack at:14e26b
[00002137][0015e263][0015e267] 55 push ebp [00002138][0015e263][0015e267] 8bec mov ebp,esp [0000213a][0015e25f][00002137] 6837210000 push 00002137 [0000213f][0015e25b][00002144] e853f4ffff call 00001597
New slave_stack at:15e30b
[00002137][0016e303][0016e307] 55 push ebp [00002138][0016e303][0016e307] 8bec mov ebp,esp [0000213a][0016e2ff][00002137] 6837210000 push 00002137 [0000213f][0016e2fb][00002144] e853f4ffff call 00001597
New slave_stack at:16e3ab
[00002137][0017e3a3][0017e3a7] 55 push ebp [00002138][0017e3a3][0017e3a7] 8bec mov ebp,esp [0000213a][0017e39f][00002137] 6837210000 push 00002137 [0000213f][0017e39b][00002144] e853f4ffff call 00001597
New slave_stack at:17e44b
[00002137][0018e443][0018e447] 55 push ebp [00002138][0018e443][0018e447] 8bec mov ebp,esp [0000213a][0018e43f][00002137] 6837210000 push 00002137 [0000213f][0018e43b][00002144] e853f4ffff call 00001597
Number of Instructions Executed(100000000) == 1492537 Pages
On 8/30/2024 8:46 AM, Fred. Zwarts wrote:
Op 30.aug.2024 om 15:05 schreef olcott:
On 8/30/2024 3:32 AM, Fred. Zwarts wrote:
Op 29.aug.2024 om 23:13 schreef olcott:
One cannot simply ignore the actual behavior of DDD emulated
by HHH according to the semantics of the x86 language because
this actual behavior is not the behavior that one expects or
one would like to have.
You cannot deny the semantics of the x86 language simply because you
do not like it, or you prefer another behaviour.
The specification of the semantics of the x86 language does not give
room for a context depending interpretation. It is independent on
which processor, or which simulator processes this finite string.
*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*
The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH
Not according to the unmodified world calls simulator, which, when
given the same input shows that the DDD based on the aborting HHH, halts.
And after a few recursions HHH sees a 'special condition' after which
and all four of them are emulated by the world
class x86 emulator libx86emu
It is easy to see that when the executed HHH emulates
DDD that it does this correctly when we look at the
execution trace and see the the first four instructions
of DDD are listed.
_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]
New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55 push ebp ; housekeeping
[00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Then this emulated DDD calls an emulated HHH(DDD).
It is easy to see that when the executed HHH emulates
itself emulated DDD that it does this correctly when we
look at the execution trace and see the the first four
instructions of DDD are listed again.
it aborts and halt.
If you cannot see that this special condition conclusively
proves that HHH must abort its emulation of DDD to prevent
the infinite exection of DDD then you have insufficient
technical competence.
If you can see this then you understand that this criteria has been met:
<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
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Here is is with 100 millions instructions and NO ABORTIrrelevant.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 04:22:16 |
| Calls: | 10,386 |
| Calls today: | 1 |
| Files: | 14,058 |
| Messages: | 6,416,622 |