Mike does not agree that HHH(DD) gets the correct
answer. He does agree that an HHH derived from the
exact meaning of these words is correct:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its
   input D until H correctly determines that its simulated D
   would never stop running unless aborted then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
Mike does not agree that HHH(DD) gets the correct
answer. He does agree that an HHH derived from the
exact meaning of these words is correct:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 5/16/2025 11:08 AM, Mike Terry wrote:
On 16/05/2025 15:33, olcott wrote:
Mike does not agree that HHH(DD) gets the correct
answer. He does agree that an HHH derived from the
exact meaning of these words is correct:
<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>
Please stop telling other people what you think I agree and do not
agree with. It serves no possible purpose other than as some kind of
warped Appeal To Authority.
Just argue whatever point you are making in your own words.
Mike.
The ultimate measure of truth is the correct reasoning
that you provided showing exactly how a correct SHD
can be derived from the exact meaning of the quoted words.
You carefully evaluated the exact meaning of the quoted
words and showed how a correct SHD can be derived from
these words. Everyone else changes the words and then
dishonestly rebuts the changed words.
Everyone else is dishonest with me, yet will not
be dishonest with you.
On 5/16/2025 12:23 PM, Richard Damon wrote:
On 5/16/25 12:16 PM, olcott wrote:
On 5/16/2025 11:08 AM, Mike Terry wrote:
On 16/05/2025 15:33, olcott wrote:
Mike does not agree that HHH(DD) gets the correct
answer. He does agree that an HHH derived from the
exact meaning of these words is correct:
<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> >>>>>
Please stop telling other people what you think I agree and do not
agree with. It serves no possible purpose other than as some kind
of warped Appeal To Authority.
Just argue whatever point you are making in your own words.
Mike.
The ultimate measure of truth is the correct reasoning
that you provided showing exactly how a correct SHD
can be derived from the exact meaning of the quoted words.
You carefully evaluated the exact meaning of the quoted
words and showed how a correct SHD can be derived from
these words. Everyone else changes the words and then
dishonestly rebuts the changed words.
Everyone else is dishonest with me, yet will not
be dishonest with you.
NO, it can't, and that is because you show you don't know the correct
meaning for the words, because you beliave your lies about it.
For 2.5 years the words always said that they
require a partial simulation of non-terminating
inputs and you "interpreted" that as meaning
that non-terminating inputs must be infinitely
simulated.
Then you based your whole rebuttal on these changed words.
On 5/16/2025 10:40 AM, Richard Damon wrote:
On 5/16/25 10:33 AM, olcott wrote:
Mike does not agree that HHH(DD) gets the correct
answer. He does agree that an HHH derived from the
exact meaning of these words is correct:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its
    input D until H correctly determines that its simulated D
    would never stop running unless aborted then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser(Mike says much more about this)
is far more likely (I'd say) to have agreed to.
;
First you should understand the basic idea behind a
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
If he so agrees with you, why are you arguing with him about what he
said?
He made one key big mistake that has nothing to do
with the actual subject matter of this post that
you keep trying to weasel out of.
It is also clear from the quotes that Mike is NOT agreeing with your
stateent, but you just don't understand him.
On 5/16/2025 4:51 PM, Richard Damon wrote:
On 5/16/25 2:26 PM, olcott wrote:
On 5/16/2025 12:23 PM, Richard Damon wrote:
On 5/16/25 12:16 PM, olcott wrote:
On 5/16/2025 11:08 AM, Mike Terry wrote:
On 16/05/2025 15:33, olcott wrote:
Mike does not agree that HHH(DD) gets the correct
answer. He does agree that an HHH derived from the
exact meaning of these words is correct:
<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>
Please stop telling other people what you think I agree and do not >>>>>> agree with. It serves no possible purpose other than as some kind >>>>>> of warped Appeal To Authority.
Just argue whatever point you are making in your own words.
Mike.
The ultimate measure of truth is the correct reasoning
that you provided showing exactly how a correct SHD
can be derived from the exact meaning of the quoted words.
You carefully evaluated the exact meaning of the quoted
words and showed how a correct SHD can be derived from
these words. Everyone else changes the words and then
dishonestly rebuts the changed words.
Everyone else is dishonest with me, yet will not
be dishonest with you.
NO, it can't, and that is because you show you don't know the
correct meaning for the words, because you beliave your lies about it.
For 2.5 years the words always said that they
require a partial simulation of non-terminating
inputs and you "interpreted" that as meaning
that non-terminating inputs must be infinitely
simulated.
Then you based your whole rebuttal on these changed words.
No, the word have NEVER meant that the determination of "non-halting"
is DEFINED by a partial simulation,
Yes you damned liar this is what these words mean:
*would never stop running unless aborted*
On 5/16/2025 4:51 PM, Richard Damon wrote:
On 5/16/25 2:26 PM, olcott wrote:
On 5/16/2025 12:23 PM, Richard Damon wrote:
On 5/16/25 12:16 PM, olcott wrote:
On 5/16/2025 11:08 AM, Mike Terry wrote:
On 16/05/2025 15:33, olcott wrote:
Mike does not agree that HHH(DD) gets the correct
answer. He does agree that an HHH derived from the
exact meaning of these words is correct:
<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>
Please stop telling other people what you think I agree and do not >>>>>> agree with. It serves no possible purpose other than as some kind >>>>>> of warped Appeal To Authority.
Just argue whatever point you are making in your own words.
Mike.
The ultimate measure of truth is the correct reasoning
that you provided showing exactly how a correct SHD
can be derived from the exact meaning of the quoted words.
You carefully evaluated the exact meaning of the quoted
words and showed how a correct SHD can be derived from
these words. Everyone else changes the words and then
dishonestly rebuts the changed words.
Everyone else is dishonest with me, yet will not
be dishonest with you.
NO, it can't, and that is because you show you don't know the
correct meaning for the words, because you beliave your lies about it.
For 2.5 years the words always said that they
require a partial simulation of non-terminating
inputs and you "interpreted" that as meaning
that non-terminating inputs must be infinitely
simulated.
Then you based your whole rebuttal on these changed words.
No, the word have NEVER meant that the determination of "non-halting"
is DEFINED by a partial simulation,
Yes you liar this is what THESE words mean:
*simulates its input D until*
MEANS A PARTIAL SIMULATION OF NON-TERMINATING INPUTS
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing but cheated.
To sincerely agree with you without extreme care is an error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article* https://al.howardknight.net/?STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:One may indeed thik so. Or pehaps he knew what he was doing but
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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> >>>>
cheated.
To sincerely agree with you without extreme care is an error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
On 5/17/2025 2:58 PM, Richard Damon wrote:
On 5/17/25 1:15 PM, olcott wrote:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing but
cheated.
To sincerely agree with you without extreme care is an error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that >>>> Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
  met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
WHich just shows that you don't understand what he is doing,
You must reply to the other post or you bypass
the context that proves you wrong.
On 5/17/2025 2:58 PM, Richard Damon wrote:
On 5/17/25 1:15 PM, olcott wrote:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:One may indeed thik so. Or pehaps he knew what he was doing but cheated. >>>>>> To sincerely agree with you without extreme care is an error.
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>> Â Â Â Â If simulating halt decider H correctly simulates its
    input D until H correctly determines that its simulated D >>>>>>>     would never stop running unless aborted then
    H can abort its simulation of D and correctly report that D >>>>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that >>>> Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
  met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
WHich just shows that you don't understand what he is doing,
You must reply to the other post or you bypass
the context that proves you wrong.
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:One may indeed thik so. Or pehaps he knew what he was doing but cheated. >>>> To sincerely agree with you without extreme care is an error.
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â If simulating halt decider H correctly simulates its
    input D until H correctly determines that its simulated D
    would never stop running unless aborted then
    H can abort its simulation of D and correctly report that D >>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me> https://al.howardknight.net/?STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:One may indeed thik so. Or pehaps he knew what he was doing but cheated. >>>>> To sincerely agree with you without extreme care is an error.
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
That page does not show all of the message.
You say there:
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential.
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's
ability to keep the discussion honest is restricted to ones own contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases
its decision on anything else than what its actual input actually
specifies it does not decide correctly.
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where this hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that he hasHHH(DDD) does not base its decision on the actual behavior of DDD
after it has aborted its simulation of DDD, instead it bases its
decision on a different HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases its
decision on anything else than what its actual input actually
specifies it does not decide correctly.
started using the phrase "..bases its decision on a different *HHH/DDD
pair* ..".
If H always reports on the behavior of its simulated input after itYes, that is why H is wrong.
aborts then every input including infinite_loop would be determined to
be halting.
Instead H must report on the hypothetical H/D input pair where the veryJust no.
same H has been made to not abort its input.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing but
cheated.
To sincerely agree with you without extreme care is an error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that >>>>> Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
That page does not show all of the message.
You say there:
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential.
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's
ability to keep the discussion honest is restricted to ones own
contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases
its decision on anything else than what its actual input actually
specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he has
started using the phrase "..bases its decision on a different *HHH/DDD
pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD does
above. It tells PO that in the tight loop example, H correctly simulates
as far as [A], at which point it correctly determines that "its
simulated input would never stop running unless aborted", so it can
decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where thisRight. It seems to be a recent innovation in PO's wording that he has >>>> started using the phrase "..bases its decision on a different *HHH/DDD >>>> pair* ..".HHH(DDD) does not base its decision on the actual behavior of DDD
after it has aborted its simulation of DDD, instead it bases its
decision on a different HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases its >>>>> decision on anything else than what its actual input actually
specifies it does not decide correctly.
hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated input after itYes, that is why H is wrong.
aborts then every input including infinite_loop would be determined to
be halting.
Instead H must report on the hypothetical H/D input pair where the veryJust no.
same H has been made to not abort its input.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
H is required to report on the behavior of D in the
case where a hypothetical instance of itself never
aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
On 5/18/2025 4:09 AM, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing but
cheated.
To sincerely agree with you without extreme care is an error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that >>>> Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
That page does not show all of the message.
You say there:
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential.
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's
ability to keep the discussion honest is restricted to ones own
contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases
its decision on anything else than what its actual input actually
specifies it does not decide correctly.
Mike's SHD does the exact same thing.
It does not base its decision on the actual SHD/Infinite_Loop
pair that aborts its simulation and stops running. This would
require SHD to report that Infinite_Loop halts.
Mike's SHD bases its decision on a purely hypothetical
SHD/Infinite_Loop pair where SHD never aborts.
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:On 5/14/2025 7:36 PM, Mike Terry wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing but >>>>>>>>> cheated.
To sincerely agree with you without extreme care is an error. >>>>>>>>
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated. >>>>>>>
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements >>>>>>> that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor >>>>>>> Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
That page does not show all of the message.
You say there:
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and >>>>> I havn't noticed any disagreement is the less essential.
Your statement "Mike is one of the few people here that really wants >>>>> an honest dialogue" is far from true. Some peole may have a stronger >>>>> desire to keep the discussion honest but there are not many who have >>>>> any reason to want any dishonest discussion. Of course everyone's
ability to keep the discussion honest is restricted to ones own
contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases
its decision on anything else than what its actual input actually
specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he
has started using the phrase "..bases its decision on a different
*HHH/DDD pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD does
above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so it
can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and NOTHING
(correct) can simulate this DDD past the call the HHH as that code
isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
On 5/18/2025 2:35 PM, Richard Damon wrote:
On 5/18/25 2:36 PM, olcott wrote:
On 5/18/2025 4:09 AM, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing but >>>>>>>> cheated.
To sincerely agree with you without extreme care is an error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated. >>>>>>
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements
that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor >>>>>> Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
That page does not show all of the message.
You say there:
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential.
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's
ability to keep the discussion honest is restricted to ones own
contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases
its decision on anything else than what its actual input actually
specifies it does not decide correctly.
Mike's SHD does the exact same thing.
It does not base its decision on the actual SHD/Infinite_Loop
pair that aborts its simulation and stops running. This would
require SHD to report that Infinite_Loop halts.
Mike's SHD bases its decision on a purely hypothetical
SHD/Infinite_Loop pair where SHD never aborts.
Nope, Mikes SHD bases its decision on the fact that it can prove that
the actual correct simulation of the input will never halt.
That is incorrect. Mike's SHD proves by a correct partial
simulation that a complete simulation cannot possibly exist.
Likewise HHH proves by a correct partial simulation
that a complete simulation of DDD cannot possibly exist.
On 5/18/2025 2:35 PM, Richard Damon wrote:
On 5/18/25 2:36 PM, olcott wrote:
On 5/18/2025 4:09 AM, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing but >>>>>>>> cheated.
To sincerely agree with you without extreme care is an error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated. >>>>>>
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements
that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor >>>>>> Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
That page does not show all of the message.
You say there:
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential.
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's
ability to keep the discussion honest is restricted to ones own
contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases
its decision on anything else than what its actual input actually
specifies it does not decide correctly.
Mike's SHD does the exact same thing.
It does not base its decision on the actual SHD/Infinite_Loop
pair that aborts its simulation and stops running. This would
require SHD to report that Infinite_Loop halts.
Mike's SHD bases its decision on a purely hypothetical
SHD/Infinite_Loop pair where SHD never aborts.
Nope, Mikes SHD bases its decision on the fact that it can prove that
the actual correct simulation of the input will never halt.
*I forgot to allow for your weasel words*
*That is incorrect. Mike's*
SHD proves by a correct partial simulation of
Infinite_Loop by SHD that a complete simulation
of Infinite_Loop by SHD cannot possibly exist.
HHH proves by a correct partial simulation of
DDD by HHH that a complete simulation
of DDD by HHH cannot possibly exist.
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:On 5/14/2025 7:36 PM, Mike Terry wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH.
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing >>>>>>>>>>> but cheated.
To sincerely agree with you without extreme care is an error. >>>>>>>>>>
There is a natural (and correct) statement that Sipser >>>>>>>>>> Â > is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated. >>>>>>>>>
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the
requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor >>>>>>>>> Sipser screwed up when he agreed with these exact words" is not >>>>>>>>> supported by evidence (but that is quite obvious anyway).
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly >>>>>>>> Â met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
That page does not show all of the message.
You say there:
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and >>>>>>> I havn't noticed any disagreement is the less essential.
Your statement "Mike is one of the few people here that really wants >>>>>>> an honest dialogue" is far from true. Some peole may have a stronger >>>>>>> desire to keep the discussion honest but there are not many who have >>>>>>> any reason to want any dishonest discussion. Of course everyone's >>>>>>> ability to keep the discussion honest is restricted to ones own
contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>> simulated D would never stop running unless aborted". If HHH bases >>>>>>> its decision on anything else than what its actual input actually >>>>>>> specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he >>>>>> has started using the phrase "..bases its decision on a different
*HHH/DDD pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines
that "its simulated input would never stop running unless aborted",
so it can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and NOTHING
(correct) can simulate this DDD past the call the HHH as that code
isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a program,
you can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in
memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your setup
is improper and makes it non-turing equivalent to what you claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
The behavior of DDD is exactly the same for any HHH that
simulates DDD. Each DDD of every HHH/DDD pair continues
to call HHH in recursive simulation until its HHH:
(a) Sees this repeating pattern and aborts it.
(b) Simply stops simulating after N steps.
(c) Never aborts it thus never stops.
In none of those cases does the DDD simulated by HHH halt.
When an infinite set of DDD simulated by HHH all have
the same non-halting property then it is proven that
each element of this same set also has this same
non-halting property.
When we know that all cows are animals we can correctly
conclude that some cows are animals and at least one
cow is an animal.
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:On 5/14/2025 7:36 PM, Mike Terry wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing >>>>>>>>>>>>> but cheated.
To sincerely agree with you without extreme care is an error. >>>>>>>>>>>>
There is a natural (and correct) statement that Sipser >>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or >>>>>>>>>>> cheated.
First you should understand the basic idea behind a >>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the
requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that >>>>>>>>>>> professor
Sipser screwed up when he agreed with these exact words" is not >>>>>>>>>>> supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly >>>>>>>>>> Â met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
That page does not show all of the message.
You say there:
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these
discussion, and
I havn't noticed any disagreement is the less essential.
Your statement "Mike is one of the few people here that really >>>>>>>>> wants
an honest dialogue" is far from true. Some peole may have a
stronger
desire to keep the discussion honest but there are not many who >>>>>>>>> have
any reason to want any dishonest discussion. Of course everyone's >>>>>>>>> ability to keep the discussion honest is restricted to ones own >>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>> simulated D would never stop running unless aborted". If HHH bases >>>>>>>>> its decision on anything else than what its actual input actually >>>>>>>>> specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that >>>>>>>> he has started using the phrase "..bases its decision on a
different *HHH/DDD pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD >>>>>>> does above. It tells PO that in the tight loop example, H
correctly simulates as far as [A], at which point it correctly
determines that "its simulated input would never stop running
unless aborted", so it can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and
NOTHING (correct) can simulate this DDD past the call the HHH as
that code isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a program,
you can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in
memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your
setup is improper and makes it non-turing equivalent to what you
claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the
code of the original HHH, and thus the Hypothetical HHH (just like
HHH1) WILL reach a final state.
You keep the strawman fallacy.
This leads me to believe that you may be a liar.
We are not asking DOES THE INPUT to a simulating
halt decider stop running AFTER it has been aborted.
We are asking WOULD THE INPUT to a simulating
halt decider stop running WHEN NEVER ABORTED.
On 5/18/2025 3:27 PM, Richard Damon wrote:
On 5/18/25 4:19 PM, olcott wrote:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or >>>>>>>>>>>>> cheated.
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was >>>>>>>>>>>>>>> doing but cheated.
To sincerely agree with you without extreme care is an >>>>>>>>>>>>>>> error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the >>>>>>>>>>>>> requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that >>>>>>>>>>>>> professor
Sipser screwed up when he agreed with these exact words" is >>>>>>>>>>>>> not
supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are >>>>>>>>>>>> exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>> than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these
discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>
Your statement "Mike is one of the few people here that
really wants
an honest dialogue" is far from true. Some peole may have a >>>>>>>>>>> stronger
desire to keep the discussion honest but there are not many >>>>>>>>>>> who have
any reason to want any dishonest discussion. Of course
everyone's
ability to keep the discussion honest is restricted to ones own >>>>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>>> its
simulated D would never stop running unless aborted". If HHH >>>>>>>>>>> bases
its decision on anything else than what its actual input >>>>>>>>>>> actually
specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording >>>>>>>>>> that he has started using the phrase "..bases its decision on >>>>>>>>>> a different *HHH/DDD pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a >>>>>>>>> SHD does above. It tells PO that in the tight loop example, H >>>>>>>>> correctly simulates as far as [A], at which point it correctly >>>>>>>>> determines that "its simulated input would never stop running >>>>>>>>> unless aborted", so it can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and
NOTHING (correct) can simulate this DDD past the call the HHH as >>>>>>>> that code isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a
program, you can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in >>>>>> memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your
setup is improper and makes it non-turing equivalent to what you
claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the
code of the original HHH, and thus the Hypothetical HHH (just like
HHH1) WILL reach a final state.
You keep the strawman fallacy.
This leads me to believe that you may be a liar.
We are not asking DOES THE INPUT to a simulating
halt decider stop running AFTER it has been aborted.
But "Inputs" don't do anything, just what they represent.
DDD simulated by HHH DOES DO SOMETHING and that
something is remain in recursive simulation until aborted.
On 5/18/2025 6:02 PM, Richard Damon wrote:
On 5/18/25 5:58 PM, olcott wrote:
On 5/18/2025 3:27 PM, Richard Damon wrote:
On 5/18/25 4:19 PM, olcott wrote:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or >>>>>>>>>>>>>>> cheated.
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was >>>>>>>>>>>>>>>>> doing but cheated.
To sincerely agree with you without extreme care is an >>>>>>>>>>>>>>>>> error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the >>>>>>>>>>>>>>> requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that >>>>>>>>>>>>>>> professor
Sipser screwed up when he agreed with these exact words" >>>>>>>>>>>>>>> is not
supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are >>>>>>>>>>>>>> exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>>>> than the next best reviewer. Mike is one of the few >>>>>>>>>>>>>> people here that really wants an honest dialogue. He >>>>>>>>>>>>>> carefully examined my code and has a nearly perfect >>>>>>>>>>>>>> understanding.
Mike and I agree about everything essential in these >>>>>>>>>>>>> discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>>>
Your statement "Mike is one of the few people here that >>>>>>>>>>>>> really wants
an honest dialogue" is far from true. Some peole may have a >>>>>>>>>>>>> stronger
desire to keep the discussion honest but there are not many >>>>>>>>>>>>> who have
any reason to want any dishonest discussion. Of course >>>>>>>>>>>>> everyone's
ability to keep the discussion honest is restricted to ones >>>>>>>>>>>>> own
contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation >>>>>>>>>>>>>> of DDD, instead it bases its decision on a different >>>>>>>>>>>>>> HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines >>>>>>>>>>>>> that its
simulated D would never stop running unless aborted". If >>>>>>>>>>>>> HHH bases
its decision on anything else than what its actual input >>>>>>>>>>>>> actually
specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording >>>>>>>>>>>> that he has started using the phrase "..bases its decision >>>>>>>>>>>> on a different *HHH/DDD pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a >>>>>>>>>>> SHD does above. It tells PO that in the tight loop example, H >>>>>>>>>>> correctly simulates as far as [A], at which point it
correctly determines that "its simulated input would never >>>>>>>>>>> stop running unless aborted", so it can decide "non-halting". >>>>>>>>>>>
Thus SHD must report on a different SHD/Infinite_Loop pair >>>>>>>>>>> where this hypothetical instance of itself never aborts. >>>>>>>>>>>
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and >>>>>>>>>> NOTHING (correct) can simulate this DDD past the call the HHH >>>>>>>>>> as that code isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a
program, you can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else >>>>>>>> in memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your >>>>>>>> setup is improper and makes it non-turing equivalent to what you >>>>>>>> claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the >>>>>> code of the original HHH, and thus the Hypothetical HHH (just like >>>>>> HHH1) WILL reach a final state.
You keep the strawman fallacy.
This leads me to believe that you may be a liar.
We are not asking DOES THE INPUT to a simulating
halt decider stop running AFTER it has been aborted.
But "Inputs" don't do anything, just what they represent.
DDD simulated by HHH DOES DO SOMETHING and that
something is remain in recursive simulation until aborted.
Right, but not necessarily what the meaning of the behavior of the
input specifies.
You just keep flat out lying about this.
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
The meaning of the behavior that DDD emulated by
HHH specifies is to keep calling HHH(DDD) in
recursive emulation never ever reaching its
own "ret" instruction, thus never halting.
On 5/18/2025 9:21 PM, Richard Damon wrote:But the rules of the x86 language are exactly the same for direct
On 5/18/25 8:10 PM, olcott wrote:
On 5/18/2025 6:02 PM, Richard Damon wrote:
Right, but not necessarily what the meaning of the behavior of the
input specifies.
You just keep flat out lying about this.
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
The meaning of the behavior that DDD emulated by
HHH specifies is to keep calling HHH(DDD) in
recursive emulation never ever reaching its
own "ret" instruction, thus never halting.
Where do you get your definition of the behavior of the input.
DDD emulated by HHH according to the rules
of the x86 language JACKASS !!!
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where thisRight. It seems to be a recent innovation in PO's wording that he has >>>> started using the phrase "..bases its decision on a different *HHH/DDD >>>> pair* ..".HHH(DDD) does not base its decision on the actual behavior of DDD
after it has aborted its simulation of DDD, instead it bases its
decision on a different HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases its >>>>> decision on anything else than what its actual input actually
specifies it does not decide correctly.
hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated input after itYes, that is why H is wrong.
aborts then every input including infinite_loop would be determined to
be halting.
Instead H must report on the hypothetical H/D input pair where the veryJust no.
same H has been made to not abort its input.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
H is required to report on the behavior of D in the
case where a hypothetical instance of itself never
aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated D NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:
On 2025-05-15 23:43:27 +0000, olcott said:On 5/14/2025 7:36 PM, Mike Terry wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<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>
One may indeed thik so. Or pehaps he knew what he was doing but cheated.
To sincerely agree with you without extreme care is an error. >>>>>>>>>>>>
There is a natural (and correct) statement that Sipser >>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to.
That is compatible with the idea that Sipser scewed up or cheated. >>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor >>>>>>>>>>> Sipser screwed up when he agreed with these exact words" is not >>>>>>>>>>> supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly >>>>>>>>>> Â met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E
That page does not show all of the message.
You say there:
Mike's reviews of my work are at least ten-fold better
than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and >>>>>>>>> I havn't noticed any disagreement is the less essential.
Your statement "Mike is one of the few people here that really wants >>>>>>>>> an honest dialogue" is far from true. Some peole may have a stronger >>>>>>>>> desire to keep the discussion honest but there are not many who have >>>>>>>>> any reason to want any dishonest discussion. Of course everyone's >>>>>>>>> ability to keep the discussion honest is restricted to ones own >>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>> simulated D would never stop running unless aborted". If HHH bases >>>>>>>>> its decision on anything else than what its actual input actually >>>>>>>>> specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he has
started using the phrase "..bases its decision on a different *HHH/DDD >>>>>>>> pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD does >>>>>>> above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that >>>>>>> "its simulated input would never stop running unless aborted", so it >>>>>>> can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and NOTHING >>>>>> (correct) can simulate this DDD past the call the HHH as that code >>>>>> isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a program, you >>>> can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in
memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your setup >>>> is improper and makes it non-turing equivalent to what you claim it is. >>>>
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the code
of the original HHH, and thus the Hypothetical HHH (just like HHH1)
WILL reach a final state.
You keep the strawman fallacy.
On 5/18/2025 6:02 PM, Richard Damon wrote:
On 5/18/25 5:58 PM, olcott wrote:
On 5/18/2025 3:27 PM, Richard Damon wrote:
On 5/18/25 4:19 PM, olcott wrote:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or cheated.
On 2025-05-15 23:43:27 +0000, olcott said:On 5/14/2025 7:36 PM, Mike Terry wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was doing but cheated.
To sincerely agree with you without extreme care is an error. >>>>>>>>>>>>>>>>
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not >>>>>>>>>>>>>>> supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>>>> than the next best reviewer. Mike is one of the few >>>>>>>>>>>>>> people here that really wants an honest dialogue. He >>>>>>>>>>>>>> carefully examined my code and has a nearly perfect >>>>>>>>>>>>>> understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>>>
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's >>>>>>>>>>>>> ability to keep the discussion honest is restricted to ones own >>>>>>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation >>>>>>>>>>>>>> of DDD, instead it bases its decision on a different >>>>>>>>>>>>>> HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>>>>>> simulated D would never stop running unless aborted". If HHH bases
its decision on anything else than what its actual input actually >>>>>>>>>>>>> specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he has
started using the phrase "..bases its decision on a different *HHH/DDD
pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD does
above. It tells PO that in the tight loop example, H correctly >>>>>>>>>>> simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so it
can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair >>>>>>>>>>> where this hypothetical instance of itself never aborts. >>>>>>>>>>>
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and NOTHING >>>>>>>>>> (correct) can simulate this DDD past the call the HHH as that code >>>>>>>>>> isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a program, you
can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in >>>>>>>> memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your setup >>>>>>>> is improper and makes it non-turing equivalent to what you claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the code >>>>>> of the original HHH, and thus the Hypothetical HHH (just like HHH1) >>>>>> WILL reach a final state.
You keep the strawman fallacy.
This leads me to believe that you may be a liar.
We are not asking DOES THE INPUT to a simulating
halt decider stop running AFTER it has been aborted.
But "Inputs" don't do anything, just what they represent.
DDD simulated by HHH DOES DO SOMETHING and that
something is remain in recursive simulation until aborted.
Right, but not necessarily what the meaning of the behavior of the
input specifies.
You just keep flat out lying about this.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The meaning of the behavior that DDD emulated by
HHH specifies is to keep calling HHH(DDD) in
recursive emulation never ever reaching its
own "ret" instruction, thus never halting.
On 5/18/2025 9:21 PM, Richard Damon wrote:
On 5/18/25 8:10 PM, olcott wrote:
On 5/18/2025 6:02 PM, Richard Damon wrote:
Right, but not necessarily what the meaning of the behavior of the
input specifies.
You just keep flat out lying about this.
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
The meaning of the behavior that DDD emulated by
HHH specifies is to keep calling HHH(DDD) in
recursive emulation never ever reaching its
own "ret" instruction, thus never halting.
Where do you get your definition of the behavior of the input.
DDD emulated by HHH according to the rules
of the x86 language JACKASS !!!
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
You forgot
(e) H does not report
HHH is required to report, that is why it
must always report on the behavior of the
hypothetical H/D pair and not the actual
behavior of the actual H/D pair for every
non-terminating input.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting HHH. >>>>
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where this >>>>> hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that he has >>>>>> started using the phrase "..bases its decision on a different *HHH/DDD >>>>>> pair* ..".HHH(DDD) does not base its decision on the actual behavior of DDD >>>>>>>> after it has aborted its simulation of DDD, instead it bases its >>>>>>>> decision on a different HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>> simulated D would never stop running unless aborted". If HHH bases its >>>>>>> decision on anything else than what its actual input actually
specifies it does not decide correctly.
If H always reports on the behavior of its simulated input after itYes, that is why H is wrong.
aborts then every input including infinite_loop would be determined to >>>>> be halting.
Instead H must report on the hypothetical H/D input pair where the very >>>>> same H has been made to not abort its input.Just no.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it aborts. >>>>
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
H is required to report on the behavior of D in the
case where a hypothetical instance of itself never
aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
You forgot
(e) H does not report
HHH is required to report, that is why it
must always report on the behavior of the
hypothetical H/D pair and not the actual
behavior of the actual H/D pair for every
non-terminating input.
On 5/19/2025 5:30 AM, Mikko wrote:
On 2025-05-19 00:10:15 +0000, olcott said:
On 5/18/2025 6:02 PM, Richard Damon wrote:
On 5/18/25 5:58 PM, olcott wrote:
On 5/18/2025 3:27 PM, Richard Damon wrote:
On 5/18/25 4:19 PM, olcott wrote:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or cheated.
On 2025-05-15 23:43:27 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
On 5/15/2025 6:18 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was doing but cheated.
To sincerely agree with you without extreme care is an error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>>>>>
There he explains an error in your claim to meet the requirements thatFirst you should understand the basic idea behind a >>>>>>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>>>>>> Â > is an input which goes into a tight loop. >>>>>>>>>>>>>>>>>> (Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me> >>>>>>>>>>>>>>>>>
Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not
supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>>>>>> than the next best reviewer. Mike is one of the few >>>>>>>>>>>>>>>> people here that really wants an honest dialogue. He >>>>>>>>>>>>>>>> carefully examined my code and has a nearly perfect >>>>>>>>>>>>>>>> understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>>>>>
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's
ability to keep the discussion honest is restricted to ones own >>>>>>>>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual >>>>>>>>>>>>>>>> behavior of DDD after it has aborted its simulation >>>>>>>>>>>>>>>> of DDD, instead it bases its decision on a different >>>>>>>>>>>>>>>> HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its
simulated D would never stop running unless aborted". If HHH bases
its decision on anything else than what its actual input actually
specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he has
started using the phrase "..bases its decision on a different *HHH/DDD
pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD does
above. It tells PO that in the tight loop example, H correctly >>>>>>>>>>>>> simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so it
can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair >>>>>>>>>>>>> where this hypothetical instance of itself never aborts. >>>>>>>>>>>>>
If H always reports on the behavior of its simulated >>>>>>>>>>>>> input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort >>>>>>>>>>>>> its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts. >>>>>>>>>>>>>
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and NOTHING
(correct) can simulate this DDD past the call the HHH as that code >>>>>>>>>>>> isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a program, you
can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in >>>>>>>>>> memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your setup
is improper and makes it non-turing equivalent to what you claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the code
of the original HHH, and thus the Hypothetical HHH (just like HHH1) >>>>>>>> WILL reach a final state.
You keep the strawman fallacy.
This leads me to believe that you may be a liar.
We are not asking DOES THE INPUT to a simulating
halt decider stop running AFTER it has been aborted.
But "Inputs" don't do anything, just what they represent.
DDD simulated by HHH DOES DO SOMETHING and that
something is remain in recursive simulation until aborted.
Right, but not necessarily what the meaning of the behavior of the
input specifies.
You just keep flat out lying about this.
It's you who kees lying.
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
The meaning of the behavior that DDD emulated by
HHH specifies is to keep calling HHH(DDD) in
recursive emulation never ever reaching its
own "ret" instruction, thus never halting.
The meaning of the behaviour that DDD specifies is irrelevant.
WRONG!
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or cheated.
On 2025-05-15 23:43:27 +0000, olcott said:On 5/14/2025 7:36 PM, Mike Terry wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was doing but cheated.
To sincerely agree with you without extreme care is an error. >>>>>>>>>>>>>>
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not >>>>>>>>>>>>> supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly >>>>>>>>>>>> Â met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>> than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's >>>>>>>>>>> ability to keep the discussion honest is restricted to ones own >>>>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>>>> simulated D would never stop running unless aborted". If HHH bases >>>>>>>>>>> its decision on anything else than what its actual input actually >>>>>>>>>>> specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he has
started using the phrase "..bases its decision on a different *HHH/DDD
pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD does >>>>>>>>> above. It tells PO that in the tight loop example, H correctly >>>>>>>>> simulates as far as [A], at which point it correctly determines that >>>>>>>>> "its simulated input would never stop running unless aborted", so it >>>>>>>>> can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and NOTHING >>>>>>>> (correct) can simulate this DDD past the call the HHH as that code >>>>>>>> isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a program, you >>>>>> can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in >>>>>> memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your setup >>>>>> is improper and makes it non-turing equivalent to what you claim it is. >>>>>>
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the code >>>> of the original HHH, and thus the Hypothetical HHH (just like HHH1)
WILL reach a final state.
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something.
It seems quite stupid to say that an error of reasoning
is correct. You might as well have said all dogs are cows.
*The rules of correct reasoning define it as incorrect*
Description: Substituting a person’s actual
position or argument with a distorted,
exaggerated, or misrepresented version
of the position of the argument.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting HHH. >>>>
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where this >>>>> hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that he >>>>>> hasHHH(DDD) does not base its decision on the actual behavior of DDD >>>>>>>> after it has aborted its simulation of DDD, instead it bases its >>>>>>>> decision on a different HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>> simulated D would never stop running unless aborted". If HHH
bases its
decision on anything else than what its actual input actually
specifies it does not decide correctly.
started using the phrase "..bases its decision on a different
*HHH/DDD
pair* ..".
If H always reports on the behavior of its simulated input after itYes, that is why H is wrong.
aborts then every input including infinite_loop would be determined to >>>>> be halting.
Instead H must report on the hypothetical H/D input pair where theJust no.
very
same H has been made to not abort its input.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it aborts. >>>>
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
H is required to report on the behavior of D in the
case where a hypothetical instance of itself never
aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
You forgot
(e) H does not report
HHH is required to report, that is why it
must always report on the behavior of the
hypothetical H/D pair and not the actual
behavior of the actual H/D pair for every
non-terminating input.
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or >>>>>>>>>>>>> cheated.
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was >>>>>>>>>>>>>>> doing but cheated.
To sincerely agree with you without extreme care is an >>>>>>>>>>>>>>> error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the >>>>>>>>>>>>> requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that >>>>>>>>>>>>> professor
Sipser screwed up when he agreed with these exact words" is >>>>>>>>>>>>> not
supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are >>>>>>>>>>>> exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>> than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these
discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>
Your statement "Mike is one of the few people here that
really wants
an honest dialogue" is far from true. Some peole may have a >>>>>>>>>>> stronger
desire to keep the discussion honest but there are not many >>>>>>>>>>> who have
any reason to want any dishonest discussion. Of course
everyone's
ability to keep the discussion honest is restricted to ones own >>>>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>>> its
simulated D would never stop running unless aborted". If HHH >>>>>>>>>>> bases
its decision on anything else than what its actual input >>>>>>>>>>> actually
specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording >>>>>>>>>> that he has started using the phrase "..bases its decision on >>>>>>>>>> a different *HHH/DDD pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a >>>>>>>>> SHD does above. It tells PO that in the tight loop example, H >>>>>>>>> correctly simulates as far as [A], at which point it correctly >>>>>>>>> determines that "its simulated input would never stop running >>>>>>>>> unless aborted", so it can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and
NOTHING (correct) can simulate this DDD past the call the HHH as >>>>>>>> that code isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a
program, you can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in >>>>>> memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your
setup is improper and makes it non-turing equivalent to what you
claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the
code of the original HHH, and thus the Hypothetical HHH (just like
HHH1) WILL reach a final state.
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something.
It seems quite stupid to say that an error of reasoning
is correct. You might as well have said all dogs are cows.
*The rules of correct reasoning define it as incorrect*
Description: Substituting a person’s actual
position or argument with a distorted,
exaggerated, or misrepresented version
of the position of the argument.
https://www.logicallyfallacious.com/logicalfallacies/Strawman-Fallacy
On 5/19/2025 5:30 AM, Mikko wrote:
On 2025-05-19 00:10:15 +0000, olcott said:
On 5/18/2025 6:02 PM, Richard Damon wrote:
On 5/18/25 5:58 PM, olcott wrote:
On 5/18/2025 3:27 PM, Richard Damon wrote:
On 5/18/25 4:19 PM, olcott wrote:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up >>>>>>>>>>>>>>>>> or cheated.
On 2025-05-15 23:43:27 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
On 5/15/2025 6:18 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH >>>>>>>>>>>>>>>>>>>>>> returns"
becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was >>>>>>>>>>>>>>>>>>> doing but cheated.
To sincerely agree with you without extreme care is >>>>>>>>>>>>>>>>>>> an error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>>>>>
There he explains an error in your claim to meet the >>>>>>>>>>>>>>>>> requirements thatFirst you should understand the basic idea behind a >>>>>>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>>>>>> Â > is an input which goes into a tight loop. >>>>>>>>>>>>>>>>>> (Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- >>>>>>>>>>>>>>>>>> email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me> >>>>>>>>>>>>>>>>>
Professor Sipser agreed.
He also shows that your "In other words you believe >>>>>>>>>>>>>>>>> that professor
Sipser screwed up when he agreed with these exact >>>>>>>>>>>>>>>>> words" is not
supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to >>>>>>>>>>>>>>>> are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>>>>>> than the next best reviewer. Mike is one of the few >>>>>>>>>>>>>>>> people here that really wants an honest dialogue. He >>>>>>>>>>>>>>>> carefully examined my code and has a nearly perfect >>>>>>>>>>>>>>>> understanding.
Mike and I agree about everything essential in these >>>>>>>>>>>>>>> discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>>>>>
Your statement "Mike is one of the few people here that >>>>>>>>>>>>>>> really wants
an honest dialogue" is far from true. Some peole may have >>>>>>>>>>>>>>> a stronger
desire to keep the discussion honest but there are not >>>>>>>>>>>>>>> many who have
any reason to want any dishonest discussion. Of course >>>>>>>>>>>>>>> everyone's
ability to keep the discussion honest is restricted to >>>>>>>>>>>>>>> ones own
contributions.
You also say:
HHH(DDD) does not base its decision on the actual >>>>>>>>>>>>>>>> behavior of DDD after it has aborted its simulation >>>>>>>>>>>>>>>> of DDD, instead it bases its decision on a different >>>>>>>>>>>>>>>> HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines >>>>>>>>>>>>>>> that its
simulated D would never stop running unless aborted". If >>>>>>>>>>>>>>> HHH bases
its decision on anything else than what its actual input >>>>>>>>>>>>>>> actually
specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording >>>>>>>>>>>>>> that he has started using the phrase "..bases its decision >>>>>>>>>>>>>> on a different *HHH/DDD pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said >>>>>>>>>>>>> a SHD does above. It tells PO that in the tight loop >>>>>>>>>>>>> example, H correctly simulates as far as [A], at which >>>>>>>>>>>>> point it correctly determines that "its simulated input >>>>>>>>>>>>> would never stop running unless aborted", so it can decide >>>>>>>>>>>>> "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair >>>>>>>>>>>>> where this hypothetical instance of itself never aborts. >>>>>>>>>>>>>
If H always reports on the behavior of its simulated >>>>>>>>>>>>> input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort >>>>>>>>>>>>> its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts. >>>>>>>>>>>>>
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and >>>>>>>>>>>> NOTHING (correct) can simulate this DDD past the call the >>>>>>>>>>>> HHH as that code isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a >>>>>>>>>> program, you can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere >>>>>>>>>> else in memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that >>>>>>>>>> your setup is improper and makes it non-turing equivalent to >>>>>>>>>> what you claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes >>>>>>>> the code of the original HHH, and thus the Hypothetical HHH
(just like HHH1) WILL reach a final state.
You keep the strawman fallacy.
This leads me to believe that you may be a liar.
We are not asking DOES THE INPUT to a simulating
halt decider stop running AFTER it has been aborted.
But "Inputs" don't do anything, just what they represent.
DDD simulated by HHH DOES DO SOMETHING and that
something is remain in recursive simulation until aborted.
Right, but not necessarily what the meaning of the behavior of the
input specifies.
You just keep flat out lying about this.
It's you who kees lying.
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
The meaning of the behavior that DDD emulated by
HHH specifies is to keep calling HHH(DDD) in
recursive emulation never ever reaching its
own "ret" instruction, thus never halting.
The meaning of the behaviour that DDD specifies is irrelevant.
WRONG!
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
DDD emulated by HHH according to the rules of the
x86 language *would never stop running unless aborted*
This is asking about the behavior of DDD with the
hypothetical HHH/DDD pair where HHH never aborts.
Mike did the same thing with his SHD and Infinite_Loop.
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Only
the behavour itself matters. That behaviour includes a recursive
simulation of DDD by HHH until HHH detects the pattern and aborts
and returns. DDD does not report the value HHH returns and does not
use it any other way, either, but just returns.
I wish that people would pay attention.
People only glance at a couple of words that I say
On 5/20/2025 2:13 AM, Mikko wrote:
On 2025-05-20 04:24:02 +0000, olcott said:
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of
something.
The strawman fallacy is stipulated to be incorrect
that is what the word "fallacy" means.
On 5/20/2025 9:57 AM, Richard Heathfield wrote:
On 20/05/2025 15:22, olcott wrote:
I wish that people would pay attention.
Your wish is in your power to grant.
People only glance at a couple of words that I say
That might be because you're so repetitive, insulting,
dismissive, and obfuscatory.
If you want people to pay attention to what you write, repeat
less. (Don't think up an excuse for repeating more. Repeat less
instead.)
If you want people to pay attention to what you write, insult
less. (Don't think up an excuse for insulting more. Insult less
instead.)
If you want people to pay attention to what you write, don't
dismiss out of hand what people are telling you. (Don't think
up an excuse for dismissing out of hand what people are telling
you. Listen to them instead.)
If you want people to pay attention to what you write, clarify
your argument. (Don't think up an excuse for obfuscating.
Clarify instead.)
Prepare a web page that summarises the logic of your claim. No
code! Just English. Post the URL, and ask people for comments -
not for arguments, but for improvements. What do they find
unclear about your argument? Just for a while, forget trying to
get people to agree with you and see if you can get them to
understand you instead.
Because if you can do that, you have a fighting chance of
turning this farce of a thread farrago into something that
might actually serve a purpose.
It seems to me that reviewers such as you far
too easily dismiss verified facts out-of-hand
with no supporting reasoning. That gets me P-O'd.
No one has actually made any rebuttal of my actual points.
On 5/20/2025 11:44 AM, Richard Heathfield wrote:
On 20/05/2025 17:18, olcott wrote:
No one has actually made any rebuttal of my actual points.
It's far from clear what your actual points are.
But I repeat myself.
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
H sees DDD call the same function with the same
parameter and there are no conditional branch
instructions from the beginning of DDD to calling
HHH(DDD) again. This repeating pattern proves
non-termination.
On 5/20/2025 2:00 AM, Mikko wrote:
On 2025-05-20 04:10:54 +0000, olcott said:
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where >>>>>>> thisRight. It seems to be a recent innovation in PO's wording that >>>>>>>> he hasHHH(DDD) does not base its decision on the actual behavior of DDD >>>>>>>>>> after it has aborted its simulation of DDD, instead it bases its >>>>>>>>>> decision on a different HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>> simulated D would never stop running unless aborted". If HHH >>>>>>>>> bases its
decision on anything else than what its actual input actually >>>>>>>>> specifies it does not decide correctly.
started using the phrase "..bases its decision on a different
*HHH/DDD
pair* ..".
hypothetical instance of itself never aborts.
HHH.
If H always reports on the behavior of its simulated input after it >>>>>>> aborts then every input including infinite_loop would beYes, that is why H is wrong.
determined to
be halting.
Instead H must report on the hypothetical H/D input pair whereJust no.
the very
same H has been made to not abort its input.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
aborts.
H is required to report on the behavior of D in the
case where a hypothetical instance of itself never
aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
You forgot
(e) H does not report
HHH is required to report, that is why it
must always report on the behavior of the
hypothetical H/D pair and not the actual
behavior of the actual H/D pair for every
non-terminating input.
Every decider is required to report. But your (c) above prevents the
hypothetical H from reporting. Therefore the hypothetical H is not a
decider.
I wish that people would pay attention.
People only glance at a couple of words that I say
then artificially contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:We use the same criteria. We see that there is no correct simulation and
On 2025-05-20 04:10:54 +0000, olcott said:I wish that people would pay attention.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:H is required to report on the behavior of D in the case where a
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting >>>>>>> HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where >>>>>>>> this hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that >>>>>>>>> he has started using the phrase "..bases its decision on aHHH(DDD) does not base its decision on the actual behavior of >>>>>>>>>>> DDD after it has aborted its simulation of DDD, instead it >>>>>>>>>>> bases its decision on a different HHH/DDD pair that never >>>>>>>>>>> aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>> its simulated D would never stop running unless aborted". If >>>>>>>>>> HHH bases its decision on anything else than what its actual >>>>>>>>>> input actually specifies it does not decide correctly.
different *HHH/DDD pair* ..".
If H always reports on the behavior of its simulated input after >>>>>>>> it aborts then every input including infinite_loop would beYes, that is why H is wrong.
determined to be halting.
Instead H must report on the hypothetical H/D input pair where >>>>>>>> the very same H has been made to not abort its input.Just no.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
aborts.
hypothetical instance of itself never aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS (b) Executed D() NEVER HALTS (c)
Executed H() NEVER HALTS (d) Everything that H calls NEVER HALTS
You forgot (e) H does not report
HHH is required to report, that is why it must always report on the
behavior of the hypothetical H/D pair and not the actual behavior of
the actual H/D pair for every non-terminating input.
Every decider is required to report. But your (c) above prevents the
hypothetical H from reporting. Therefore the hypothetical H is not a
decider.
People only glance at a couple of words that I say then artificially
contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
that H does not correctly determine that its simulated D would never
stop running. In fact the input specified to H contains code to abort,
so a simulation of this input without abort would lead to a natural
halt.
So, because the criteria are not met, we see that Sipser agreed to a
vacuous statement.
But you do not pay attention to what is said, because you stay in
rebuttal mode and, after seeing just a few words, keep repeating
statements that are proven to be irrelevant, without even touching the
fact that you are proven to be irrelevant.
Op 20.mei.2025 om 16:37 schreef olcott:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
That is a wild guess of HHH, not a correct determination. When it sees the call to HHH and we know
that HHH halts, we know that there is only a finite recursion, so the 'would never stop running'
exists only in your dreams.
The input is a finite string that includes the code of Halt7.c, which specifies that the simulation
will abort. So, HHH is wrong when it assumes that an abort is needed for this input to prevent a
never stop running.
Face the facts, not your dreams. Try a real argument, instead a repetition of your dream. Try to get
out of rebuttal mode.
H sees DDD call the same function with the same
parameter and there are no conditional branch
instructions from the beginning of DDD to calling
HHH(DDD) again. This repeating pattern proves
non-termination.
HHH does not even see a full cycle, so it cannot know that there are no conditional branches in the
cycle. You can view a full cycle in different ways:
1) from the first start of DDD up to the second start of DDD. The second beginning of DDD is reached
after many steps of the simulation, which contains a lot of conditional branching instruction.
2) From the first start of HHH up to the second start of HHH. In this cycle there are also many
conditional branch instructions within HHH.
So, it is misleading to say that there are no conditional branch instruction in the full cycle.
That a small part of the cycle does not have conditional branch instructions does not prove anything.
Face the facts. Stop repeating your dreams. Come out of rebuttal mode and try a serious honest
dialogue.
On 5/20/2025 9:57 AM, Richard Heathfield wrote:
On 20/05/2025 15:22, olcott wrote:
I wish that people would pay attention.
Your wish is in your power to grant.
People only glance at a couple of words that I say
That might be because you're so repetitive, insulting, dismissive, and
obfuscatory.
If you want people to pay attention to what you write, repeat less.
(Don't think up an excuse for repeating more. Repeat less instead.)
If you want people to pay attention to what you write, insult less.
(Don't think up an excuse for insulting more. Insult less instead.)
If you want people to pay attention to what you write, don't dismiss
out of hand what people are telling you. (Don't think up an excuse for
dismissing out of hand what people are telling you. Listen to them
instead.)
If you want people to pay attention to what you write, clarify your
argument. (Don't think up an excuse for obfuscating. Clarify instead.)
Prepare a web page that summarises the logic of your claim. No code!
Just English. Post the URL, and ask people for comments - not for
arguments, but for improvements. What do they find unclear about your
argument? Just for a while, forget trying to get people to agree with
you and see if you can get them to understand you instead.
Because if you can do that, you have a fighting chance of turning this
farce of a thread farrago into something that might actually serve a
purpose.
It seems to me that reviewers such as you far
too easily dismiss verified facts out-of-hand
with no supporting reasoning. That gets me P-O'd.
On 5/20/2025 2:00 AM, Mikko wrote:
On 2025-05-20 04:10:54 +0000, olcott said:
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where >>>>>>> thisRight. It seems to be a recent innovation in PO's wording that >>>>>>>> he hasHHH(DDD) does not base its decision on the actual behavior of DDD >>>>>>>>>> after it has aborted its simulation of DDD, instead it bases its >>>>>>>>>> decision on a different HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>> simulated D would never stop running unless aborted". If HHH >>>>>>>>> bases its
decision on anything else than what its actual input actually >>>>>>>>> specifies it does not decide correctly.
started using the phrase "..bases its decision on a different
*HHH/DDD
pair* ..".
hypothetical instance of itself never aborts.
HHH.
If H always reports on the behavior of its simulated input after it >>>>>>> aborts then every input including infinite_loop would beYes, that is why H is wrong.
determined to
be halting.
Instead H must report on the hypothetical H/D input pair whereJust no.
the very
same H has been made to not abort its input.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
aborts.
H is required to report on the behavior of D in the
case where a hypothetical instance of itself never
aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
You forgot
(e) H does not report
HHH is required to report, that is why it
must always report on the behavior of the
hypothetical H/D pair and not the actual
behavior of the actual H/D pair for every
non-terminating input.
Every decider is required to report. But your (c) above prevents the
hypothetical H from reporting. Therefore the hypothetical H is not a
decider.
I wish that people would pay attention.
People only glance at a couple of words that I say
then artificially contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
HHH is required to abort its input DDD or
(a) (b) (c) (d) never stop running.
This proves that HHH is correct to abort DDD because
*H correctly determines that its simulated D*
*would never stop running unless aborted*
On Tue, 20 May 2025 19:51:59 +0200, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:We use the same criteria. We see that there is no correct simulation and
On 2025-05-20 04:10:54 +0000, olcott said:I wish that people would pay attention.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:H is required to report on the behavior of D in the case where a >>>>>>> hypothetical instance of itself never aborts its simulated D.
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting >>>>>>>> HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where >>>>>>>>> this hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that >>>>>>>>>> he has started using the phrase "..bases its decision on a >>>>>>>>>> different *HHH/DDD pair* ..".HHH(DDD) does not base its decision on the actual behavior of >>>>>>>>>>>> DDD after it has aborted its simulation of DDD, instead it >>>>>>>>>>>> bases its decision on a different HHH/DDD pair that never >>>>>>>>>>>> aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>>> its simulated D would never stop running unless aborted". If >>>>>>>>>>> HHH bases its decision on anything else than what its actual >>>>>>>>>>> input actually specifies it does not decide correctly.
If H always reports on the behavior of its simulated input after >>>>>>>>> it aborts then every input including infinite_loop would beYes, that is why H is wrong.
determined to be halting.
Instead H must report on the hypothetical H/D input pair where >>>>>>>>> the very same H has been made to not abort its input.Just no.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it >>>>>>>> aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS (b) Executed D() NEVER HALTS (c)
Executed H() NEVER HALTS (d) Everything that H calls NEVER HALTS
You forgot (e) H does not report
HHH is required to report, that is why it must always report on the
behavior of the hypothetical H/D pair and not the actual behavior of >>>>> the actual H/D pair for every non-terminating input.
Every decider is required to report. But your (c) above prevents the
hypothetical H from reporting. Therefore the hypothetical H is not a
decider.
People only glance at a couple of words that I say then artificially
contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
that H does not correctly determine that its simulated D would never
stop running. In fact the input specified to H contains code to abort,
so a simulation of this input without abort would lead to a natural
halt.
So, because the criteria are not met, we see that Sipser agreed to a
vacuous statement.
But you do not pay attention to what is said, because you stay in
rebuttal mode and, after seeing just a few words, keep repeating
statements that are proven to be irrelevant, without even touching the
fact that you are proven to be irrelevant.
The halting problem is defined in terms of UTMs with infinite tape so Flibble's law applies and infinite recursion can be detected and assumed
to be equivalent to NON-HALTING.
/Flibble
On 5/20/2025 12:51 PM, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:
On 2025-05-20 04:10:54 +0000, olcott said:
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pairRight. It seems to be a recent innovation in PO's wording >>>>>>>>>> that he hasHHH(DDD) does not base its decision on the actual behavior >>>>>>>>>>>> of DDDThis is why HHH does not satisfy "H correctly determines that >>>>>>>>>>> its
after it has aborted its simulation of DDD, instead it bases >>>>>>>>>>>> its
decision on a different HHH/DDD pair that never aborts. >>>>>>>>>>>
simulated D would never stop running unless aborted". If HHH >>>>>>>>>>> bases its
decision on anything else than what its actual input actually >>>>>>>>>>> specifies it does not decide correctly.
started using the phrase "..bases its decision on a different >>>>>>>>>> *HHH/DDD
pair* ..".
where this
hypothetical instance of itself never aborts.
aborting HHH.
If H always reports on the behavior of its simulated inputYes, that is why H is wrong.
after it
aborts then every input including infinite_loop would be
determined to
be halting.
Instead H must report on the hypothetical H/D input pair where >>>>>>>>> the veryJust no.
same H has been made to not abort its input.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it >>>>>>>> aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
H is required to report on the behavior of D in the
case where a hypothetical instance of itself never
aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
You forgot
(e) H does not report
HHH is required to report, that is why it
must always report on the behavior of the
hypothetical H/D pair and not the actual
behavior of the actual H/D pair for every
non-terminating input.
Every decider is required to report. But your (c) above prevents the
hypothetical H from reporting. Therefore the hypothetical H is not a
decider.
I wish that people would pay attention.
People only glance at a couple of words that I say
then artificially contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
We use the same criteria. We see that there is no correct simulation
and that H does not correctly determine that its simulated D would
never stop running. In fact the input specified to H contains code to
abort, so a simulation of this input without abort would lead to a
natural halt.
That is merely your lack sufficient software skills.
(a) The outermost (directly executed) HHH sees its
abort criteria met one whole execution trace before
the next inner one.
(b) Every instance of HHH is the same machine code at
the same address thus each HHH has the same behavior.
(c) Unless the outer HHH aborts its simulation then
none of them do because they all have the same machine
code.
On 5/20/2025 12:46 PM, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:37 schreef olcott:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
That is a wild guess of HHH,
void DDD()
{
 HHH(DDD);
 return;
}
Sure and people that have no idea what
infinite recursion is would say the same thing.
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
H sees DDD call the same function with the same
parameter and there are no conditional branch
instructions from the beginning of DDD to calling
HHH(DDD) again. This repeating pattern proves
non-termination.
On 5/20/2025 2:13 AM, Mikko wrote:
On 2025-05-20 04:24:02 +0000, olcott said:
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something.
The strawman fallacy is stipulated to be incorrect
that is what the word "fallacy" means.
It seems quite stupid to say that an error of reasoning
is correct. You might as well have said all dogs are cows.
A straw man fallacy is not an error of reasoning. It is a false
attribution of the claim that is refuted.
Any attempt to refute X by changing the subject to Y
is dishonest.
*The rules of correct reasoning define it as incorrect*
If the correctness of an inference depends on who presented the
claim the those "rules of correct reasoning" are unsound.
How many times do I have to repeat this before you
notice ALL of the words that I said?
Any attempt to refute X by changing the subject to Y
is dishonest.
Description: Substituting a person’s actual
position or argument with a distorted,
exaggerated, or misrepresented version
of the position of the argument.
Which is a false attribution of the claim that is not relevant to
the correctness of the proof or refutaion of the presented version.
That quote confirms my claim and contradicts your counter claim.
How many times do I have to repeat this before you
notice ALL of the words that I said?
Any attempt to refute X by changing the subject to Y
is dishonest. Natural born liars may never get this.
On 5/20/2025 11:58 AM, Richard Heathfield wrote:
On 20/05/2025 17:46, olcott wrote:
On 5/20/2025 11:44 AM, Richard Heathfield wrote:
On 20/05/2025 17:18, olcott wrote:
No one has actually made any rebuttal of my actual points.
It's far from clear what your actual points are.
But I repeat myself.
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
The evidence of articles posted in this newsgroup suggests strongly
that what you think Mike Terry 'proves' is very different from what he
thinks he's saying.
*The bullshit and double-talk posted here does no such thing*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
  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. ----------------------------
we can easily interpret that as saying exactly what I said
a SHD does above. It tells PO that in the tight loop example,
H correctly simulates as far as [A], at which point it correctly
determines that "its simulated input would never stop running
unless aborted", so it can decide "non-halting".
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
It also suggests that you are trying to muddy the waters.
Liar!
I think you're being deliberately unclear and trying your utmost not
to be understood.
Why, I know not. But you are not behaving as someone would who has
confidence in his argument. If you truly believed you were right, you
would be doing your utmost to make yourself clear. Every foolish
repetition and every pointless evasion makes it harder and harder for
anyone to take you seriously.
On 5/20/2025 8:06 PM, Mike Terry wrote:
On 20/05/2025 18:46, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:37 schreef olcott:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
That is a wild guess of HHH, not a correct determination. When it
sees the call to HHH and we know that HHH halts, we know that there
is only a finite recursion, so the 'would never stop running' exists
only in your dreams.
The input is a finite string that includes the code of Halt7.c, which
specifies that the simulation will abort. So, HHH is wrong when it
assumes that an abort is needed for this input to prevent a never
stop running.
Face the facts, not your dreams. Try a real argument, instead a
repetition of your dream. Try to get out of rebuttal mode.
H sees DDD call the same function with the same
parameter and there are no conditional branch
instructions from the beginning of DDD to calling
HHH(DDD) again. This repeating pattern proves
non-termination.
HHH does not even see a full cycle, so it cannot know that there are
no conditional branches in the cycle. You can view a full cycle in
different ways:
1) from the first start of DDD up to the second start of DDD. The
second beginning of DDD is reached after many steps of the
simulation, which contains a lot of conditional branching instruction.
2) From the first start of HHH up to the second start of HHH. In this
cycle there are also many conditional branch instructions within HHH.
So, it is misleading to say that there are no conditional branch
instruction in the full cycle.
That a small part of the cycle does not have conditional branch
instructions does not prove anything.
Face the facts. Stop repeating your dreams. Come out of rebuttal mode
and try a serious honest dialogue.
Yes, that all correct. There are loads of conditional branch
instructions performed by HHH as part of DDD. This makes a nonsense
of the implementation of PO's "infinite recursion" test.
But there is a worse nonsense here:Â even if there were indeed no
conditional branches between the matching call statements in the
simulation, THAT STILL WOULD NOT BE ENOUGH TO GUARANTEE INFINITE
RECURSION!
You are assuming details of HHH that are not included
in its specification. A DDD that is only simulated by
HHH *is* infinite recursion.
void DDD()
{
 HHH(DDD);
 return;
}
Any moron can see that DDD simulated by HHH cannot possibly halt.
It does not matter how many steps of DDD are simulated by HHH.
No DDD every reaches its own "return" statement final halt state.
*The same thing goes for Linz*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
So his whole test idea is just nonsense, PLUS it has a nonsense
implementation that ignores the bulk of simulated code for no
justifiable reason. Nonsense^2.
Mike.
*Mike you are not paying close enough attention*
<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
All HHH have the same machine code
*Unless HHH aborts its simulated DDD, then*
a) Simulated DDDÂ Â NEVER STOPS RUNNING
b) Executed DDD() NEVER STOPS RUNNING
c) Simulated HHHÂ Â NEVER STOPS RUNNING
d) Executed HHH() (with all of its conditionals) NEVER STOPS RUNNING
   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>
This PROVES that HHH is correct to abort the simulation of
its DDD and reject DDD as non-halting according to the above
criteria.
On 5/20/2025 2:00 AM, Mikko wrote:
On 2025-05-20 04:10:54 +0000, olcott said:
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting HHH. >>>>>>
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where this >>>>>>> hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that he hasHHH(DDD) does not base its decision on the actual behavior of DDD >>>>>>>>>> after it has aborted its simulation of DDD, instead it bases its >>>>>>>>>> decision on a different HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>> simulated D would never stop running unless aborted". If HHH bases its
decision on anything else than what its actual input actually >>>>>>>>> specifies it does not decide correctly.
started using the phrase "..bases its decision on a different *HHH/DDD >>>>>>>> pair* ..".
If H always reports on the behavior of its simulated input after it >>>>>>> aborts then every input including infinite_loop would be determined to >>>>>>> be halting.Yes, that is why H is wrong.
Instead H must report on the hypothetical H/D input pair where the very >>>>>>> same H has been made to not abort its input.Just no.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it aborts. >>>>>>
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
H is required to report on the behavior of D in the
case where a hypothetical instance of itself never
aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
You forgot
(e) H does not report
HHH is required to report, that is why it
must always report on the behavior of the
hypothetical H/D pair and not the actual
behavior of the actual H/D pair for every
non-terminating input.
Every decider is required to report. But your (c) above prevents the
hypothetical H from reporting. Therefore the hypothetical H is not a
decider.
I wish that people would pay attention.
On Tue, 20 May 2025 19:51:59 +0200, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:We use the same criteria. We see that there is no correct simulation and
On 2025-05-20 04:10:54 +0000, olcott said:I wish that people would pay attention.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:H is required to report on the behavior of D in the case where a >>>>>>> hypothetical instance of itself never aborts its simulated D.
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting >>>>>>>> HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where >>>>>>>>> this hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that >>>>>>>>>> he has started using the phrase "..bases its decision on a >>>>>>>>>> different *HHH/DDD pair* ..".HHH(DDD) does not base its decision on the actual behavior of >>>>>>>>>>>> DDD after it has aborted its simulation of DDD, instead it >>>>>>>>>>>> bases its decision on a different HHH/DDD pair that never >>>>>>>>>>>> aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>>> its simulated D would never stop running unless aborted". If >>>>>>>>>>> HHH bases its decision on anything else than what its actual >>>>>>>>>>> input actually specifies it does not decide correctly.
If H always reports on the behavior of its simulated input after >>>>>>>>> it aborts then every input including infinite_loop would beYes, that is why H is wrong.
determined to be halting.
Instead H must report on the hypothetical H/D input pair where >>>>>>>>> the very same H has been made to not abort its input.Just no.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it >>>>>>>> aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS (b) Executed D() NEVER HALTS (c)
Executed H() NEVER HALTS (d) Everything that H calls NEVER HALTS
You forgot (e) H does not report
HHH is required to report, that is why it must always report on the
behavior of the hypothetical H/D pair and not the actual behavior of >>>>> the actual H/D pair for every non-terminating input.
Every decider is required to report. But your (c) above prevents the
hypothetical H from reporting. Therefore the hypothetical H is not a
decider.
People only glance at a couple of words that I say then artificially
contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
that H does not correctly determine that its simulated D would never
stop running. In fact the input specified to H contains code to abort,
so a simulation of this input without abort would lead to a natural
halt.
So, because the criteria are not met, we see that Sipser agreed to a
vacuous statement.
But you do not pay attention to what is said, because you stay in
rebuttal mode and, after seeing just a few words, keep repeating
statements that are proven to be irrelevant, without even touching the
fact that you are proven to be irrelevant.
The halting problem is defined in terms of UTMs with infinite tape so
On 5/20/2025 12:51 PM, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:
On 2025-05-20 04:10:54 +0000, olcott said:
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting HHH. >>>>>>>>
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where this >>>>>>>>> hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that he hasHHH(DDD) does not base its decision on the actual behavior of DDD >>>>>>>>>>>> after it has aborted its simulation of DDD, instead it bases its >>>>>>>>>>>> decision on a different HHH/DDD pair that never aborts. >>>>>>>>>>>This is why HHH does not satisfy "H correctly determines that its >>>>>>>>>>> simulated D would never stop running unless aborted". If HHH bases its
decision on anything else than what its actual input actually >>>>>>>>>>> specifies it does not decide correctly.
started using the phrase "..bases its decision on a different *HHH/DDD
pair* ..".
If H always reports on the behavior of its simulated input after it >>>>>>>>> aborts then every input including infinite_loop would be determined toYes, that is why H is wrong.
be halting.
Instead H must report on the hypothetical H/D input pair where the veryJust no.
same H has been made to not abort its input.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
H is required to report on the behavior of D in the
case where a hypothetical instance of itself never
aborts its simulated D.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS
(b) Executed D() NEVER HALTS
(c) Executed H() NEVER HALTS
(d) Everything that H calls NEVER HALTS
You forgot
(e) H does not report
HHH is required to report, that is why it
must always report on the behavior of the
hypothetical H/D pair and not the actual
behavior of the actual H/D pair for every
non-terminating input.
Every decider is required to report. But your (c) above prevents the
hypothetical H from reporting. Therefore the hypothetical H is not a
decider.
I wish that people would pay attention.
People only glance at a couple of words that I say
then artificially contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
We use the same criteria. We see that there is no correct simulation
and that H does not correctly determine that its simulated D would
never stop running. In fact the input specified to H contains code to
abort, so a simulation of this input without abort would lead to a
natural halt.
That is merely your lack sufficient software skills.
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
On 5/20/2025 12:46 PM, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:37 schreef olcott:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
That is a wild guess of HHH,
void DDD()
{
HHH(DDD);
return;
}
Sure and people that have no idea what
infinite recursion is would say the same thing.
On 5/20/2025 2:13 AM, Mikko wrote:
On 2025-05-20 04:24:02 +0000, olcott said:
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something.
The strawman fallacy is stipulated to be incorrect
that is what the word "fallacy" means.
It seems quite stupid to say that an error of reasoning
is correct. You might as well have said all dogs are cows.
A straw man fallacy is not an error of reasoning. It is a false
attribution of the claim that is refuted.
Any attempt to refute X by changing the subject to Y
is dishonest.
*The rules of correct reasoning define it as incorrect*
If the correctness of an inference depends on who presented the
claim the those "rules of correct reasoning" are unsound.
How many times do I have to repeat this before you
notice ALL of the words that I said?
On 2025-05-20 14:42:36 +0000, olcott said:
On 5/20/2025 2:13 AM, Mikko wrote:
On 2025-05-20 04:24:02 +0000, olcott said:
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of
something.
The strawman fallacy is stipulated to be incorrect
that is what the word "fallacy" means.
True, but the incorrectness is in the atribution of the claim,
not in the refutation. If there is a fallacy in the refutation
then it is called by some other term, depending on the what is
wrong there.
It seems quite stupid to say that an error of reasoning
is correct. You might as well have said all dogs are cows.
A straw man fallacy is not an error of reasoning. It is a false
attribution of the claim that is refuted.
Any attempt to refute X by changing the subject to Y
is dishonest.
Yes, but that hasn't stopped you.
*The rules of correct reasoning define it as incorrect*
If the correctness of an inference depends on who presented the
claim the those "rules of correct reasoning" are unsound.
How many times do I have to repeat this before you
notice ALL of the words that I said?
You can never find out because you can't determine what I have
noticed
and what not.
On 5/20/2025 9:19 PM, Richard Damon wrote:
On 5/20/25 10:08 PM, olcott wrote:
On 5/20/2025 8:06 PM, Mike Terry wrote:
On 20/05/2025 18:46, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:37 schreef olcott:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
That is a wild guess of HHH, not a correct determination. When it
sees the call to HHH and we know that HHH halts, we know that there
is only a finite recursion, so the 'would never stop running'
exists only in your dreams.
The input is a finite string that includes the code of Halt7.c,
which specifies that the simulation will abort. So, HHH is wrong
when it assumes that an abort is needed for this input to prevent
a never stop running.
Face the facts, not your dreams. Try a real argument, instead a
repetition of your dream. Try to get out of rebuttal mode.
H sees DDD call the same function with the same
parameter and there are no conditional branch
instructions from the beginning of DDD to calling
HHH(DDD) again. This repeating pattern proves
non-termination.
HHH does not even see a full cycle, so it cannot know that there
are no conditional branches in the cycle. You can view a full cycle
in different ways:
1) from the first start of DDD up to the second start of DDD. The
second beginning of DDD is reached after many steps of the
simulation, which contains a lot of conditional branching instruction. >>>>> 2) From the first start of HHH up to the second start of HHH. In
this cycle there are also many conditional branch instructions
within HHH.
So, it is misleading to say that there are no conditional branch
instruction in the full cycle.
That a small part of the cycle does not have conditional branch
instructions does not prove anything.
Face the facts. Stop repeating your dreams. Come out of rebuttal
mode and try a serious honest dialogue.
Yes, that all correct. There are loads of conditional branch
instructions performed by HHH as part of DDD. This makes a nonsense
of the implementation of PO's "infinite recursion" test.
But there is a worse nonsense here:Â even if there were indeed no
conditional branches between the matching call statements in the
simulation, THAT STILL WOULD NOT BE ENOUGH TO GUARANTEE INFINITE
RECURSION!
You are assuming details of HHH that are not included
in its specification. A DDD that is only simulated by
HHH *is* infinite recursion.
But such an HHH isn't the needed decider, so not the DDD that we are
looking at when we have a decider HHH.
Sorry,
void DDD()
{
  HHH(DDD);
  return;
}
Any moron can see that DDD simulated by HHH cannot possibly halt.
It does not matter how many steps of DDD are simulated by HHH.
No DDD every reaches its own "return" statement final halt state.
And any HHH that just simulates its input isn't a decider, and thus
fails.
I have to go one step at a time or people
get completely overwhelmed.
So far everyone here including you right now made
sure to dodge the above point, thus lack the mandatory
prerequisites for moving on the to the next point.
When an HHH emulates N steps of DDD,
(no matter what the value of N is)
DDD never halts and has the exact
same behavior as HHH aborting DDD
after N steps.
On 5/21/2025 4:28 AM, Richard Heathfield wrote:
On 21/05/2025 10:23, Mikko wrote:
On 2025-05-20 14:42:36 +0000, olcott said:
On 5/20/2025 2:13 AM, Mikko wrote:
On 2025-05-20 04:24:02 +0000, olcott said:
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something. >>>>>>
The strawman fallacy is stipulated to be incorrect
that is what the word "fallacy" means.
True, but the incorrectness is in the atribution of the claim,
not in the refutation. If there is a fallacy in the refutation
then it is called by some other term, depending on the what is
wrong there.
It seems quite stupid to say that an error of reasoning
is correct. You might as well have said all dogs are cows.
A straw man fallacy is not an error of reasoning. It is a false
attribution of the claim that is refuted.
Any attempt to refute X by changing the subject to Y
is dishonest.
Yes, but that hasn't stopped you.
*The rules of correct reasoning define it as incorrect*
If the correctness of an inference depends on who presented the
claim the those "rules of correct reasoning" are unsound.
How many times do I have to repeat this before you
notice ALL of the words that I said?
You can never find out because you can't determine what I have noticed
and what not.
I have suggested to him that he puts ALL of the words --- all the
important ones, anyway --- on a Web site so that he doesn't feel
obliged to post reams and reams of copy-paste over and over. It would
be one single place where he can make himself abundantly clear.
But of course he can't afford to be abundantly clear, because if he
nails his point down in stone it will be too easy for his readership
to point out all the holes.
void DDD()
{
 HHH(DDD);
 return;
}
If it too difficult for people to understand
that DDD simulated by HHH cannot possibly halt
then this stuff is simply over-your-head.
On 5/21/2025 3:05 AM, Mikko wrote:
On 2025-05-20 18:31:01 +0000, Mr Flibble said:
On Tue, 20 May 2025 19:51:59 +0200, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:We use the same criteria. We see that there is no correct simulation
On 2025-05-20 04:10:54 +0000, olcott said:I wish that people would pay attention.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:You forgot (e) H does not report
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:H is required to report on the behavior of D in the case where a >>>>>>>>> hypothetical instance of itself never aborts its simulated D. >>>>>>>>>
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting >>>>>>>>>> HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where >>>>>>>>>>> this hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that >>>>>>>>>>>> he has started using the phrase "..bases its decision on a >>>>>>>>>>>> different *HHH/DDD pair* ..".HHH(DDD) does not base its decision on the actual behavior of >>>>>>>>>>>>>> DDD after it has aborted its simulation of DDD, instead it >>>>>>>>>>>>>> bases its decision on a different HHH/DDD pair that never >>>>>>>>>>>>>> aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>>>>> its simulated D would never stop running unless aborted". If >>>>>>>>>>>>> HHH bases its decision on anything else than what its actual >>>>>>>>>>>>> input actually specifies it does not decide correctly. >>>>>>>>>>>>>
If H always reports on the behavior of its simulated input after >>>>>>>>>>> it aborts then every input including infinite_loop would be >>>>>>>>>>> determined to be halting.Yes, that is why H is wrong.
Instead H must report on the hypothetical H/D input pair where >>>>>>>>>>> the very same H has been made to not abort its input.Just no.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it >>>>>>>>>> aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS (b) Executed D() NEVER HALTS (c) >>>>>>>>> Executed H() NEVER HALTS (d) Everything that H calls NEVER HALTS >>>>>>>>
HHH is required to report, that is why it must always report on the >>>>>>> behavior of the hypothetical H/D pair and not the actual behavior of >>>>>>> the actual H/D pair for every non-terminating input.
Every decider is required to report. But your (c) above prevents the >>>>>> hypothetical H from reporting. Therefore the hypothetical H is not a >>>>>> decider.
People only glance at a couple of words that I say then artificially >>>>> contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
and
that H does not correctly determine that its simulated D would never
stop running. In fact the input specified to H contains code to abort, >>>> so a simulation of this input without abort would lead to a natural
halt.
So, because the criteria are not met, we see that Sipser agreed to a
vacuous statement.
But you do not pay attention to what is said, because you stay in
rebuttal mode and, after seeing just a few words, keep repeating
statements that are proven to be irrelevant, without even touching the >>>> fact that you are proven to be irrelevant.
The halting problem is defined in terms of UTMs with infinite tape so
It usually isn't. There are many variants of the problem but if you
have an oracle for one of the you can solve them all. Usually an UTM
is not mentioned in the problem statement. The tape is potentially
infinite but one execution of a decider never uses more than a finite
segment of the tape.
I think that I am the original inventor of
the notion of simulating halt decider as it
pertains to the halting problem proofs.
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and
is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
On 5/20/2025 9:19 PM, Richard Damon wrote:
On 5/20/25 10:08 PM, olcott wrote:
On 5/20/2025 8:06 PM, Mike Terry wrote:
On 20/05/2025 18:46, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:37 schreef olcott:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
That is a wild guess of HHH, not a correct determination. When it
sees the call to HHH and we know that HHH halts, we know that there
is only a finite recursion, so the 'would never stop running'
exists only in your dreams.
The input is a finite string that includes the code of Halt7.c,
which specifies that the simulation will abort. So, HHH is wrong
when it assumes that an abort is needed for this input to prevent
a never stop running.
Face the facts, not your dreams. Try a real argument, instead a
repetition of your dream. Try to get out of rebuttal mode.
H sees DDD call the same function with the same
parameter and there are no conditional branch
instructions from the beginning of DDD to calling
HHH(DDD) again. This repeating pattern proves
non-termination.
HHH does not even see a full cycle, so it cannot know that there
are no conditional branches in the cycle. You can view a full cycle
in different ways:
1) from the first start of DDD up to the second start of DDD. The
second beginning of DDD is reached after many steps of the
simulation, which contains a lot of conditional branching instruction. >>>>> 2) From the first start of HHH up to the second start of HHH. In
this cycle there are also many conditional branch instructions
within HHH.
So, it is misleading to say that there are no conditional branch
instruction in the full cycle.
That a small part of the cycle does not have conditional branch
instructions does not prove anything.
Face the facts. Stop repeating your dreams. Come out of rebuttal
mode and try a serious honest dialogue.
Yes, that all correct. There are loads of conditional branch
instructions performed by HHH as part of DDD. This makes a nonsense
of the implementation of PO's "infinite recursion" test.
But there is a worse nonsense here:Â even if there were indeed no
conditional branches between the matching call statements in the
simulation, THAT STILL WOULD NOT BE ENOUGH TO GUARANTEE INFINITE
RECURSION!
You are assuming details of HHH that are not included
in its specification. A DDD that is only simulated by
HHH *is* infinite recursion.
But such an HHH isn't the needed decider, so not the DDD that we are
looking at when we have a decider HHH.
Sorry,
void DDD()
{
  HHH(DDD);
  return;
}
Any moron can see that DDD simulated by HHH cannot possibly halt.
It does not matter how many steps of DDD are simulated by HHH.
No DDD every reaches its own "return" statement final halt state.
And any HHH that just simulates its input isn't a decider, and thus
fails.
I have to go one step at a time or people
get completely overwhelmed.
So far everyone here including you right now made
sure to dodge the above point, thus lack the mandatory
prerequisites for moving on the to the next point.
When an HHH emulates N steps of DDD,
(no matter what the value of N is)
DDD never halts and has the exact
same behavior as HHH aborting DDD
after N steps.
On 5/21/2025 3:05 AM, Mikko wrote:
On 2025-05-20 18:31:01 +0000, Mr Flibble said:
On Tue, 20 May 2025 19:51:59 +0200, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:We use the same criteria. We see that there is no correct simulation
On 2025-05-20 04:10:54 +0000, olcott said:I wish that people would pay attention.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:You forgot (e) H does not report
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:H is required to report on the behavior of D in the case where a >>>>>>>>> hypothetical instance of itself never aborts its simulated D. >>>>>>>>>
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting >>>>>>>>>> HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where >>>>>>>>>>> this hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that >>>>>>>>>>>> he has started using the phrase "..bases its decision on a >>>>>>>>>>>> different *HHH/DDD pair* ..".HHH(DDD) does not base its decision on the actual behavior of >>>>>>>>>>>>>> DDD after it has aborted its simulation of DDD, instead it >>>>>>>>>>>>>> bases its decision on a different HHH/DDD pair that never >>>>>>>>>>>>>> aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>>>>> its simulated D would never stop running unless aborted". If >>>>>>>>>>>>> HHH bases its decision on anything else than what its actual >>>>>>>>>>>>> input actually specifies it does not decide correctly. >>>>>>>>>>>>>
If H always reports on the behavior of its simulated input after >>>>>>>>>>> it aborts then every input including infinite_loop would be >>>>>>>>>>> determined to be halting.Yes, that is why H is wrong.
Instead H must report on the hypothetical H/D input pair where >>>>>>>>>>> the very same H has been made to not abort its input.Just no.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it >>>>>>>>>> aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS (b) Executed D() NEVER HALTS (c) >>>>>>>>> Executed H() NEVER HALTS (d) Everything that H calls NEVER HALTS >>>>>>>>
HHH is required to report, that is why it must always report on the >>>>>>> behavior of the hypothetical H/D pair and not the actual behavior of >>>>>>> the actual H/D pair for every non-terminating input.
Every decider is required to report. But your (c) above prevents the >>>>>> hypothetical H from reporting. Therefore the hypothetical H is not a >>>>>> decider.
People only glance at a couple of words that I say then artificially >>>>> contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
and
that H does not correctly determine that its simulated D would never
stop running. In fact the input specified to H contains code to abort, >>>> so a simulation of this input without abort would lead to a natural
halt.
So, because the criteria are not met, we see that Sipser agreed to a
vacuous statement.
But you do not pay attention to what is said, because you stay in
rebuttal mode and, after seeing just a few words, keep repeating
statements that are proven to be irrelevant, without even touching the >>>> fact that you are proven to be irrelevant.
The halting problem is defined in terms of UTMs with infinite tape so
It usually isn't. There are many variants of the problem but if you
have an oracle for one of the you can solve them all. Usually an UTM
is not mentioned in the problem statement. The tape is potentially
infinite but one execution of a decider never uses more than a finite
segment of the tape.
I think that I am the original inventor of
the notion of simulating halt decider as it
pertains to the halting problem proofs.
Computer Science professor Eric Hehner PhD
was the first one that noticed this:
*Problems with the Halting Problem*
From a programmer's point of view, if we apply
an interpreter to a program text that includes
a call to that same interpreter with that same
text as argument, then we have an infinite loop. https://www.cs.toronto.edu/~hehner/PHP.pdf
Professor Hehner did not notice that the above
could be used to create a simulating halt decider
that rejects the conventional HP counter-example
input as non-halting.
On 5/21/2025 2:47 PM, Fred. Zwarts wrote:
Op 21.mei.2025 om 05:05 schreef olcott:
On 5/20/2025 9:19 PM, Richard Damon wrote:
On 5/20/25 10:08 PM, olcott wrote:
On 5/20/2025 8:06 PM, Mike Terry wrote:
On 20/05/2025 18:46, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:37 schreef olcott:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>>>>> in the creteria and is therefore irrelevant, an obvious
consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
That is a wild guess of HHH, not a correct determination. When it >>>>>>> sees the call to HHH and we know that HHH halts, we know that
there is only a finite recursion, so the 'would never stop
running' exists only in your dreams.
The input is a finite string that includes the code of Halt7.c,
which specifies that the simulation will abort. So, HHH is wrong >>>>>>> when it assumes that an abort is needed for this input to prevent >>>>>>> a never stop running.
Face the facts, not your dreams. Try a real argument, instead a
repetition of your dream. Try to get out of rebuttal mode.
H sees DDD call the same function with the same
parameter and there are no conditional branch
instructions from the beginning of DDD to calling
HHH(DDD) again. This repeating pattern proves
non-termination.
HHH does not even see a full cycle, so it cannot know that there >>>>>>> are no conditional branches in the cycle. You can view a full
cycle in different ways:
1) from the first start of DDD up to the second start of DDD. The >>>>>>> second beginning of DDD is reached after many steps of the
simulation, which contains a lot of conditional branching
instruction.
2) From the first start of HHH up to the second start of HHH. In >>>>>>> this cycle there are also many conditional branch instructions
within HHH.
So, it is misleading to say that there are no conditional branch >>>>>>> instruction in the full cycle.
That a small part of the cycle does not have conditional branch
instructions does not prove anything.
Face the facts. Stop repeating your dreams. Come out of rebuttal >>>>>>> mode and try a serious honest dialogue.
Yes, that all correct. There are loads of conditional branch
instructions performed by HHH as part of DDD. This makes a
nonsense of the implementation of PO's "infinite recursion" test.
But there is a worse nonsense here:Â even if there were indeed no >>>>>> conditional branches between the matching call statements in the
simulation, THAT STILL WOULD NOT BE ENOUGH TO GUARANTEE INFINITE
RECURSION!
You are assuming details of HHH that are not included
in its specification. A DDD that is only simulated by
HHH *is* infinite recursion.
But such an HHH isn't the needed decider, so not the DDD that we are
looking at when we have a decider HHH.
Sorry,
void DDD()
{
  HHH(DDD);
  return;
}
Any moron can see that DDD simulated by HHH cannot possibly halt.
It does not matter how many steps of DDD are simulated by HHH.
No DDD every reaches its own "return" statement final halt state.
And any HHH that just simulates its input isn't a decider, and thus
fails.
I have to go one step at a time or people
get completely overwhelmed.
So far everyone here including you right now made
sure to dodge the above point, thus lack the mandatory
prerequisites for moving on the to the next point.
When an HHH emulates N steps of DDD,
(no matter what the value of N is)
DDD never halts and has the exact
same behavior as HHH aborting DDD
after N steps.
N has a fixed value,
No dip-shit N is specified to take on an value.
It is like I say 5 > 3 and you say
I doan beeve in nummers.
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and
is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
On 5/21/2025 3:05 AM, Mikko wrote:
On 2025-05-20 18:31:01 +0000, Mr Flibble said:
On Tue, 20 May 2025 19:51:59 +0200, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:We use the same criteria. We see that there is no correct simulation and >>>> that H does not correctly determine that its simulated D would never
On 2025-05-20 04:10:54 +0000, olcott said:I wish that people would pay attention.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:You forgot (e) H does not report
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:H is required to report on the behavior of D in the case where a >>>>>>>>> hypothetical instance of itself never aborts its simulated D. >>>>>>>>>
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting >>>>>>>>>> HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where >>>>>>>>>>> this hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that >>>>>>>>>>>> he has started using the phrase "..bases its decision on a >>>>>>>>>>>> different *HHH/DDD pair* ..".HHH(DDD) does not base its decision on the actual behavior of >>>>>>>>>>>>>> DDD after it has aborted its simulation of DDD, instead it >>>>>>>>>>>>>> bases its decision on a different HHH/DDD pair that never >>>>>>>>>>>>>> aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>>>>> its simulated D would never stop running unless aborted". If >>>>>>>>>>>>> HHH bases its decision on anything else than what its actual >>>>>>>>>>>>> input actually specifies it does not decide correctly. >>>>>>>>>>>>>
If H always reports on the behavior of its simulated input after >>>>>>>>>>> it aborts then every input including infinite_loop would be >>>>>>>>>>> determined to be halting.Yes, that is why H is wrong.
Instead H must report on the hypothetical H/D input pair where >>>>>>>>>>> the very same H has been made to not abort its input.Just no.
*H correctly determines that its simulated D*H does stop running when simulated without aborting, because it >>>>>>>>>> aborts.
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
When the hypothetical H never aborts its simulated D then:
(a) Simulated DÂ NEVER HALTS (b) Executed D() NEVER HALTS (c) >>>>>>>>> Executed H() NEVER HALTS (d) Everything that H calls NEVER HALTS >>>>>>>>
HHH is required to report, that is why it must always report on the >>>>>>> behavior of the hypothetical H/D pair and not the actual behavior of >>>>>>> the actual H/D pair for every non-terminating input.
Every decider is required to report. But your (c) above prevents the >>>>>> hypothetical H from reporting. Therefore the hypothetical H is not a >>>>>> decider.
People only glance at a couple of words that I say then artificially >>>>> contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
stop running. In fact the input specified to H contains code to abort, >>>> so a simulation of this input without abort would lead to a natural
halt.
So, because the criteria are not met, we see that Sipser agreed to a
vacuous statement.
But you do not pay attention to what is said, because you stay in
rebuttal mode and, after seeing just a few words, keep repeating
statements that are proven to be irrelevant, without even touching the >>>> fact that you are proven to be irrelevant.
The halting problem is defined in terms of UTMs with infinite tape so
It usually isn't. There are many variants of the problem but if you
have an oracle for one of the you can solve them all. Usually an UTM
is not mentioned in the problem statement. The tape is potentially
infinite but one execution of a decider never uses more than a finite
segment of the tape.
I think that I am the original inventor of
the notion of simulating halt decider as it
pertains to the halting problem proofs.
Computer Science professor Eric Hehner PhD
was the first one that noticed this:
*Problems with the Halting Problem*
From a programmer's point of view, if we apply
an interpreter to a program text that includes
a call to that same interpreter with that same
text as argument, then we have an infinite loop. https://www.cs.toronto.edu/~hehner/PHP.pdf
Professor Hehner did not notice that the above
could be used to create a simulating halt decider
that rejects the conventional HP counter-example
input as non-halting.
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and
is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
On 5/20/2025 2:13 AM, Mikko wrote:
On 2025-05-20 04:24:02 +0000, olcott said:
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something.
The strawman fallacy is stipulated to be incorrect
that is what the word "fallacy" means.
It seems quite stupid to say that an error of reasoning
is correct. You might as well have said all dogs are cows.
On 5/20/2025 11:44 AM, Richard Heathfield wrote:
On 20/05/2025 17:18, olcott wrote:
No one has actually made any rebuttal of my actual points.
It's far from clear what your actual points are.
But I repeat myself.
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
On 5/20/2025 10:48 AM, Richard Heathfield wrote:
On 20/05/2025 16:30, olcott wrote:
<nothing he hasn't said a thousand times before>
<yawn>
Excessive repetition hinders you. But I repeat myself.
<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
No one has actually made any rebuttal of my actual points.
Even Mike tried to get away with the strawman fallacy of
substituting DDD simulated by HHH1 for my actual claim of
DDD simulated by HHH.
On 21/05/2025 10:23, Mikko wrote:
On 2025-05-20 14:42:36 +0000, olcott said:
On 5/20/2025 2:13 AM, Mikko wrote:
On 2025-05-20 04:24:02 +0000, olcott said:
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something. >>>>>
The strawman fallacy is stipulated to be incorrect
that is what the word "fallacy" means.
True, but the incorrectness is in the atribution of the claim,
not in the refutation. If there is a fallacy in the refutation
then it is called by some other term, depending on the what is
wrong there.
It seems quite stupid to say that an error of reasoning
is correct. You might as well have said all dogs are cows.
A straw man fallacy is not an error of reasoning. It is a false
attribution of the claim that is refuted.
Any attempt to refute X by changing the subject to Y
is dishonest.
Yes, but that hasn't stopped you.
*The rules of correct reasoning define it as incorrect*
If the correctness of an inference depends on who presented the
claim the those "rules of correct reasoning" are unsound.
How many times do I have to repeat this before you
notice ALL of the words that I said?
You can never find out because you can't determine what I have noticed
and what not.
I have suggested to him that he puts ALL of the words --- all the
important ones, anyway --- on a Web site so that he doesn't feel
obliged to post reams and reams of copy-paste over and over. It would
be one single place where he can make himself abundantly clear.
But of course he can't afford to be abundantly clear, because if he
nails his point down in stone it will be too easy for his readership to
point out all the holes.
On 5/20/2025 11:58 AM, Richard Heathfield wrote:
On 20/05/2025 17:46, olcott wrote:
On 5/20/2025 11:44 AM, Richard Heathfield wrote:
On 20/05/2025 17:18, olcott wrote:
No one has actually made any rebuttal of my actual points.
It's far from clear what your actual points are.
But I repeat myself.
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
The evidence of articles posted in this newsgroup suggests strongly
that what you think Mike Terry 'proves' is very different from what he
thinks he's saying.
*The bullshit and double-talk posted here does no such thing*
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or >>>>>>>>>>>>> cheated.
On 2025-05-15 23:43:27 +0000, olcott said:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was >>>>>>>>>>>>>>> doing but cheated.
To sincerely agree with you without extreme care is an >>>>>>>>>>>>>>> error.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the >>>>>>>>>>>>> requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that >>>>>>>>>>>>> professor
Sipser screwed up when he agreed with these exact words" is >>>>>>>>>>>>> not
supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are >>>>>>>>>>>> exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>> than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these
discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>
Your statement "Mike is one of the few people here that
really wants
an honest dialogue" is far from true. Some peole may have a >>>>>>>>>>> stronger
desire to keep the discussion honest but there are not many >>>>>>>>>>> who have
any reason to want any dishonest discussion. Of course
everyone's
ability to keep the discussion honest is restricted to ones own >>>>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>>> its
simulated D would never stop running unless aborted". If HHH >>>>>>>>>>> bases
its decision on anything else than what its actual input >>>>>>>>>>> actually
specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording >>>>>>>>>> that he has started using the phrase "..bases its decision on >>>>>>>>>> a different *HHH/DDD pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a >>>>>>>>> SHD does above. It tells PO that in the tight loop example, H >>>>>>>>> correctly simulates as far as [A], at which point it correctly >>>>>>>>> determines that "its simulated input would never stop running >>>>>>>>> unless aborted", so it can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and
NOTHING (correct) can simulate this DDD past the call the HHH as >>>>>>>> that code isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a
program, you can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in >>>>>> memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your
setup is improper and makes it non-turing equivalent to what you
claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the
code of the original HHH, and thus the Hypothetical HHH (just like
HHH1) WILL reach a final state.
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something.
That is a damned lie and you know it.
On 5/22/2025 3:50 AM, Mikko wrote:
On 2025-05-20 16:46:10 +0000, olcott said:
On 5/20/2025 11:44 AM, Richard Heathfield wrote:
On 20/05/2025 17:18, olcott wrote:
No one has actually made any rebuttal of my actual points.
It's far from clear what your actual points are.
But I repeat myself.
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
That does not clarify what your actual points are.
You should answer all questions about you actual points with a
pointer to the paragraph on your web page where the answer is.
*Here is Mike Terry Proving*
Re: Mike Terry Proves --- *RIGHT HERE RIGHT NOW*
How the requirements that Professor Sipser agreed to are exactly met
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted",
so it can decide "non-halting".
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and
is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific language. That
you may apply his words to a specific language does not mean that
Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D*
What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
None of which contradicts or even attempts to contradict what I said:
I do understand that the meaning of the behaviour is not mentioned
in the creteria and is therefore irrelevant, an obvious consequence
of which is that your "WRONG!" above is false.
If a > b and b > c then a > c is entailed.
*simulating halt decider H correctly simulates its input D*
entails a measure of correct simulation.
On 5/22/2025 3:10 AM, Mikko wrote:
On 2025-05-21 15:41:45 +0000, olcott said:
On 5/21/2025 3:05 AM, Mikko wrote:
On 2025-05-20 18:31:01 +0000, Mr Flibble said:
On Tue, 20 May 2025 19:51:59 +0200, Fred. Zwarts wrote:It usually isn't. There are many variants of the problem but if you
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:We use the same criteria. We see that there is no correct
On 2025-05-20 04:10:54 +0000, olcott said:I wish that people would pay attention.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:You forgot (e) H does not report
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:H is required to report on the behavior of D in the case where a >>>>>>>>>>> hypothetical instance of itself never aborts its simulated D. >>>>>>>>>>>
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real >>>>>>>>>>>> aborting
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair >>>>>>>>>>>>> whereRight. It seems to be a recent innovation in PO's wording >>>>>>>>>>>>>> thatHHH(DDD) does not base its decision on the actual >>>>>>>>>>>>>>>> behavior of
DDD after it has aborted its simulation of DDD, instead it >>>>>>>>>>>>>>>> bases its decision on a different HHH/DDD pair that never >>>>>>>>>>>>>>>> aborts.
This is why HHH does not satisfy "H correctly determines >>>>>>>>>>>>>>> that
its simulated D would never stop running unless aborted". If >>>>>>>>>>>>>>> HHH bases its decision on anything else than what its actual >>>>>>>>>>>>>>> input actually specifies it does not decide correctly. >>>>>>>>>>>>>>>
he has started using the phrase "..bases its decision on a >>>>>>>>>>>>>> different *HHH/DDD pair* ..".
this hypothetical instance of itself never aborts.
HHH.
If H always reports on the behavior of its simulated input >>>>>>>>>>>>> afterYes, that is why H is wrong.
it aborts then every input including infinite_loop would be >>>>>>>>>>>>> determined to be halting.
Instead H must report on the hypothetical H/D input pair where >>>>>>>>>>>>> the very same H has been made to not abort its input. >>>>>>>>>>>> Just no.
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts. >>>>>>>>>>>> H does stop running when simulated without aborting, because it >>>>>>>>>>>> aborts.
When the hypothetical H never aborts its simulated D then: >>>>>>>>>>> (a) Simulated DÂ NEVER HALTS (b) Executed D() NEVER HALTS (c) >>>>>>>>>>> Executed H() NEVER HALTS (d) Everything that H calls NEVER HALTS >>>>>>>>>>
HHH is required to report, that is why it must always report on >>>>>>>>> the
behavior of the hypothetical H/D pair and not the actual
behavior of
the actual H/D pair for every non-terminating input.
Every decider is required to report. But your (c) above prevents >>>>>>>> the
hypothetical H from reporting. Therefore the hypothetical H is >>>>>>>> not a
decider.
People only glance at a couple of words that I say then artificially >>>>>>> contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
simulation and
that H does not correctly determine that its simulated D would never >>>>>> stop running. In fact the input specified to H contains code to
abort,
so a simulation of this input without abort would lead to a natural >>>>>> halt.
So, because the criteria are not met, we see that Sipser agreed to a >>>>>> vacuous statement.
But you do not pay attention to what is said, because you stay in
rebuttal mode and, after seeing just a few words, keep repeating
statements that are proven to be irrelevant, without even touching >>>>>> the
fact that you are proven to be irrelevant.
The halting problem is defined in terms of UTMs with infinite tape so >>>>
have an oracle for one of the you can solve them all. Usually an UTM
is not mentioned in the problem statement. The tape is potentially
infinite but one execution of a decider never uses more than a finite
segment of the tape.
I think that I am the original inventor of
the notion of simulating halt decider as it
pertains to the halting problem proofs.
Computer Science professor Eric Hehner PhD
was the first one that noticed this:
*Problems with the Halting Problem*
 From a programmer's point of view, if we apply
an interpreter to a program text that includes
a call to that same interpreter with that same
text as argument, then we have an infinite loop.
https://www.cs.toronto.edu/~hehner/PHP.pdf
Professor Hehner did not notice that the above
could be used to create a simulating halt decider
that rejects the conventional HP counter-example
input as non-halting.
It can't. A decider, unlike a simulator, cannot be infinitely looping.
void Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
_Infinite_Loop()
[0000212e] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[0000212f] 8bec          mov ebp,esp
[00002131] ebfe          jmp 00002131
[00002133] 5d            pop ebp
[00002134] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0007) [00002134]
In other words (even though Mike proved otherwise)
No one and nothing can possibly know that an infinite
loop will never terminate until they wait until
the end of time and it didn't stop running yet.
Why the Hell are you trying to get away with something
so moronically stupid?
On 5/22/2025 3:10 AM, Mikko wrote:
On 2025-05-21 15:41:45 +0000, olcott said:
On 5/21/2025 3:05 AM, Mikko wrote:
On 2025-05-20 18:31:01 +0000, Mr Flibble said:
On Tue, 20 May 2025 19:51:59 +0200, Fred. Zwarts wrote:It usually isn't. There are many variants of the problem but if you
Op 20.mei.2025 om 16:22 schreef olcott:
On 5/20/2025 2:00 AM, Mikko wrote:We use the same criteria. We see that there is no correct simulation and >>>>>> that H does not correctly determine that its simulated D would never >>>>>> stop running. In fact the input specified to H contains code to abort, >>>>>> so a simulation of this input without abort would lead to a natural >>>>>> halt.
On 2025-05-20 04:10:54 +0000, olcott said:I wish that people would pay attention.
On 5/19/2025 5:12 AM, Mikko wrote:
On 2025-05-18 19:18:21 +0000, olcott said:
On 5/18/2025 2:08 PM, joes wrote:You forgot (e) H does not report
Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:H is required to report on the behavior of D in the case where a >>>>>>>>>>> hypothetical instance of itself never aborts its simulated D. >>>>>>>>>>>
On 5/18/2025 10:21 AM, Mike Terry wrote:This, the simulator. The input still calls the same real aborting >>>>>>>>>>>> HHH.
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
Thus SHD must report on a different SHD/Infinite_Loop pair where >>>>>>>>>>>>> this hypothetical instance of itself never aborts.Right. It seems to be a recent innovation in PO's wording that >>>>>>>>>>>>>> he has started using the phrase "..bases its decision on a >>>>>>>>>>>>>> different *HHH/DDD pair* ..".HHH(DDD) does not base its decision on the actual behavior of >>>>>>>>>>>>>>>> DDD after it has aborted its simulation of DDD, instead it >>>>>>>>>>>>>>>> bases its decision on a different HHH/DDD pair that never >>>>>>>>>>>>>>>> aborts.
This is why HHH does not satisfy "H correctly determines that >>>>>>>>>>>>>>> its simulated D would never stop running unless aborted". If >>>>>>>>>>>>>>> HHH bases its decision on anything else than what its actual >>>>>>>>>>>>>>> input actually specifies it does not decide correctly. >>>>>>>>>>>>>>>
If H always reports on the behavior of its simulated input after >>>>>>>>>>>>> it aborts then every input including infinite_loop would be >>>>>>>>>>>>> determined to be halting.Yes, that is why H is wrong.
Instead H must report on the hypothetical H/D input pair where >>>>>>>>>>>>> the very same H has been made to not abort its input. >>>>>>>>>>>> Just no.
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts. >>>>>>>>>>>> H does stop running when simulated without aborting, because it >>>>>>>>>>>> aborts.
When the hypothetical H never aborts its simulated D then: >>>>>>>>>>> (a) Simulated DÂ NEVER HALTS (b) Executed D() NEVER HALTS (c) >>>>>>>>>>> Executed H() NEVER HALTS (d) Everything that H calls NEVER HALTS >>>>>>>>>>
HHH is required to report, that is why it must always report on the >>>>>>>>> behavior of the hypothetical H/D pair and not the actual behavior of >>>>>>>>> the actual H/D pair for every non-terminating input.
Every decider is required to report. But your (c) above prevents the >>>>>>>> hypothetical H from reporting. Therefore the hypothetical H is not a >>>>>>>> decider.
People only glance at a couple of words that I say then artificially >>>>>>> contrive a fake rebuttal.
*We are ONLY measuring HHH/DDD against this 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
So, because the criteria are not met, we see that Sipser agreed to a >>>>>> vacuous statement.
But you do not pay attention to what is said, because you stay in
rebuttal mode and, after seeing just a few words, keep repeating
statements that are proven to be irrelevant, without even touching the >>>>>> fact that you are proven to be irrelevant.
The halting problem is defined in terms of UTMs with infinite tape so >>>>
have an oracle for one of the you can solve them all. Usually an UTM
is not mentioned in the problem statement. The tape is potentially
infinite but one execution of a decider never uses more than a finite
segment of the tape.
I think that I am the original inventor of
the notion of simulating halt decider as it
pertains to the halting problem proofs.
Computer Science professor Eric Hehner PhD
was the first one that noticed this:
*Problems with the Halting Problem*
 From a programmer's point of view, if we apply
an interpreter to a program text that includes
a call to that same interpreter with that same
text as argument, then we have an infinite loop.
https://www.cs.toronto.edu/~hehner/PHP.pdf
Professor Hehner did not notice that the above
could be used to create a simulating halt decider
that rejects the conventional HP counter-example
input as non-halting.
It can't. A decider, unlike a simulator, cannot be infinitely looping.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
_Infinite_Loop()
[0000212e] 55 push ebp
[0000212f] 8bec mov ebp,esp
[00002131] ebfe jmp 00002131
[00002133] 5d pop ebp
[00002134] c3 ret
Size in bytes:(0007) [00002134]
In other words (even though Mike proved otherwise)
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and
is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific language. That
you may apply his words to a specific language does not mean that
Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D*
What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
On 5/22/2025 3:50 AM, Mikko wrote:
On 2025-05-20 16:46:10 +0000, olcott said:
On 5/20/2025 11:44 AM, Richard Heathfield wrote:
On 20/05/2025 17:18, olcott wrote:
No one has actually made any rebuttal of my actual points.
It's far from clear what your actual points are.
But I repeat myself.
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
That does not clarify what your actual points are.
You should answer all questions about you actual points with a
pointer to the paragraph on your web page where the answer is.
*Here is Mike Terry Proving*
Re: Mike Terry Proves --- *RIGHT HERE RIGHT NOW*
How the requirements that Professor Sipser agreed to are exactly met
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted",
so it can decide "non-halting".
On 5/14/2025 7:36 PM, Mike Terry wrote: https://al.howardknight.net/?STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or cheated.
On 2025-05-15 23:43:27 +0000, olcott said:On 5/14/2025 7:36 PM, Mike Terry wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was doing but cheated.
To sincerely agree with you without extreme care is an error. >>>>>>>>>>>>>>
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not >>>>>>>>>>>>> supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly >>>>>>>>>>>> Â met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>> than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's >>>>>>>>>>> ability to keep the discussion honest is restricted to ones own >>>>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>>>> simulated D would never stop running unless aborted". If HHH bases >>>>>>>>>>> its decision on anything else than what its actual input actually >>>>>>>>>>> specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he has
started using the phrase "..bases its decision on a different *HHH/DDD
pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD does >>>>>>>>> above. It tells PO that in the tight loop example, H correctly >>>>>>>>> simulates as far as [A], at which point it correctly determines that >>>>>>>>> "its simulated input would never stop running unless aborted", so it >>>>>>>>> can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and NOTHING >>>>>>>> (correct) can simulate this DDD past the call the HHH as that code >>>>>>>> isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a program, you >>>>>> can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in >>>>>> memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your setup >>>>>> is improper and makes it non-turing equivalent to what you claim it is. >>>>>>
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the code >>>> of the original HHH, and thus the Hypothetical HHH (just like HHH1)
WILL reach a final state.
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something.
That is a damned lie and you know it.
On 5/21/2025 2:36 PM, Fred. Zwarts wrote:
Op 21.mei.2025 om 17:33 schreef olcott:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and
is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
And that is not the measure of a partial simulation that misses the
part where the input specifies the abort and halts.
Because you are incompetent at software engineering
you are clueless about the idea of unreachable code.
On 5/21/2025 2:47 PM, Fred. Zwarts wrote:
Op 21.mei.2025 om 05:05 schreef olcott:
On 5/20/2025 9:19 PM, Richard Damon wrote:
On 5/20/25 10:08 PM, olcott wrote:
On 5/20/2025 8:06 PM, Mike Terry wrote:
On 20/05/2025 18:46, Fred. Zwarts wrote:
Op 20.mei.2025 om 16:37 schreef olcott:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>>>>> in the creteria and is therefore irrelevant, an obvious
consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The meaning of every step of the behavior is
precisely specified by the x86 language.
_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]
*H correctly simulates its input D*
00002172 00002173 00002175 0000217a
H correctly simulates itself simulating DDD
00002172 00002173 00002175 0000217a
*until H correctly determines that its simulated D*
*would never stop running unless aborted*
That is a wild guess of HHH, not a correct determination. When it >>>>>>> sees the call to HHH and we know that HHH halts, we know that
there is only a finite recursion, so the 'would never stop
running' exists only in your dreams.
The input is a finite string that includes the code of Halt7.c,
which specifies that the simulation will abort. So, HHH is wrong >>>>>>> when it assumes that an abort is needed for this input to prevent >>>>>>> a never stop running.
Face the facts, not your dreams. Try a real argument, instead a
repetition of your dream. Try to get out of rebuttal mode.
H sees DDD call the same function with the same
parameter and there are no conditional branch
instructions from the beginning of DDD to calling
HHH(DDD) again. This repeating pattern proves
non-termination.
HHH does not even see a full cycle, so it cannot know that there >>>>>>> are no conditional branches in the cycle. You can view a full
cycle in different ways:
1) from the first start of DDD up to the second start of DDD. The >>>>>>> second beginning of DDD is reached after many steps of the
simulation, which contains a lot of conditional branching
instruction.
2) From the first start of HHH up to the second start of HHH. In >>>>>>> this cycle there are also many conditional branch instructions
within HHH.
So, it is misleading to say that there are no conditional branch >>>>>>> instruction in the full cycle.
That a small part of the cycle does not have conditional branch
instructions does not prove anything.
Face the facts. Stop repeating your dreams. Come out of rebuttal >>>>>>> mode and try a serious honest dialogue.
Yes, that all correct. There are loads of conditional branch
instructions performed by HHH as part of DDD. This makes a
nonsense of the implementation of PO's "infinite recursion" test.
But there is a worse nonsense here:Â even if there were indeed no >>>>>> conditional branches between the matching call statements in the
simulation, THAT STILL WOULD NOT BE ENOUGH TO GUARANTEE INFINITE
RECURSION!
You are assuming details of HHH that are not included
in its specification. A DDD that is only simulated by
HHH *is* infinite recursion.
But such an HHH isn't the needed decider, so not the DDD that we are
looking at when we have a decider HHH.
Sorry,
void DDD()
{
  HHH(DDD);
  return;
}
Any moron can see that DDD simulated by HHH cannot possibly halt.
It does not matter how many steps of DDD are simulated by HHH.
No DDD every reaches its own "return" statement final halt state.
And any HHH that just simulates its input isn't a decider, and thus
fails.
I have to go one step at a time or people
get completely overwhelmed.
So far everyone here including you right now made
sure to dodge the above point, thus lack the mandatory
prerequisites for moving on the to the next point.
When an HHH emulates N steps of DDD,
(no matter what the value of N is)
DDD never halts and has the exact
same behavior as HHH aborting DDD
after N steps.
N has a fixed value,
No dip-shit N is specified to take on an value.
It is like I say 5 > 3 and you say
I doan beeve in nummers.
On 5/23/2025 1:56 AM, Mikko wrote:
On 2025-05-22 22:35:51 +0000, olcott said:
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and >>>>>> is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific language. That >>>> you may apply his words to a specific language does not mean that
Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D*
What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
A straw man fallcy is a lie, so you are lying.
I am paraphrasing.
They stupidly expect that DDD emulated by HHH must
have the same behavior as DDD emulated by HHH1.
The ONLY way to do that is for HHH to emulate
DDD AGAINST THE RULES OF THE X86 LANGUAGE.
On 5/23/2025 5:50 AM, Fred. Zwarts wrote:
Op 21.mei.2025 om 21:40 schreef olcott:
On 5/21/2025 2:36 PM, Fred. Zwarts wrote:
Op 21.mei.2025 om 17:33 schreef olcott:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and >>>>>> is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
And that is not the measure of a partial simulation that misses the
part where the input specifies the abort and halts.
Because you are incompetent at software engineering
you are clueless about the idea of unreachable code.
Only irrelevant ad hominem attacks.
*unreachable code*
*unreachable code*
*unreachable code*
*unreachable code*
Not rebuttal. So, it seems you understand that that is not the measure
of a partial simulation that misses the part where the input specifies
a halting behaviour.
The halting behavior is *unreachable code*
The halting behavior is *unreachable code*
The halting behavior is *unreachable code*
That HHH has a bug
Your lack of technical competence is not my bug.
Your lack of technical competence is not my bug.
Your lack of technical competence is not my bug.
On 5/23/2025 12:49 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 18:24 schreef olcott:
On 5/23/2025 1:56 AM, Mikko wrote:
On 2025-05-22 22:35:51 +0000, olcott said:
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not
mentioned
in the creteria and is therefore irrelevant, an obvious
consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and >>>>>>>> is irrelevant to the fact that the meaning of the behaviour, if >>>>>>>> there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific language.
That
you may apply his words to a specific language does not mean that
Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D*
What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
A straw man fallcy is a lie, so you are lying.
I am paraphrasing.
They stupidly expect that DDD emulated by HHH must
have the same behavior as DDD emulated by HHH1.
The ONLY way to do that is for HHH to emulate
DDD AGAINST THE RULES OF THE X86 LANGUAGE.
Because it is against the rules of the X86 language it is stupid to
expect that one correct simulation differs from another correct
simulation.
It may seem this way to people lacking
the capacity to pay complete attention.
I dared people to show the exact mistake of
DDD correctly simulated by HHH and the best
that they had was counter-factual statements.
They never show any complete detail because
they already know that this proves they are wrong.
On 5/23/2025 12:54 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 19:23 schreef olcott:
On 5/23/2025 5:50 AM, Fred. Zwarts wrote:
Op 21.mei.2025 om 21:40 schreef olcott:
On 5/21/2025 2:36 PM, Fred. Zwarts wrote:
Op 21.mei.2025 om 17:33 schreef olcott:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not
mentioned
in the creteria and is therefore irrelevant, an obvious
consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and >>>>>>>> is irrelevant to the fact that the meaning of the behaviour, if >>>>>>>> there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
And that is not the measure of a partial simulation that misses
the part where the input specifies the abort and halts.
Because you are incompetent at software engineering
you are clueless about the idea of unreachable code.
Only irrelevant ad hominem attacks.
*unreachable code*
*unreachable code*
*unreachable code*
*unreachable code*
Only in your dream. It is a verifiable fact that the input specifies a
halting program.
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
If you weren't a damned liar you could
show all of the steps of exactly how
DDD correctly simulated by HHH halts.
You don't do this only because you know
that you are a damned liar.
On 5/23/2025 1:30 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 19:54 schreef olcott:
On 5/23/2025 12:49 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 18:24 schreef olcott:
On 5/23/2025 1:56 AM, Mikko wrote:
On 2025-05-22 22:35:51 +0000, olcott said:
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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 >>>>>>>>>>>>>
Do you understand that we are only evaluating whether >>>>>>>>>>>>> or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not >>>>>>>>>>>> mentioned
in the creteria and is therefore irrelevant, an obvious >>>>>>>>>>>> consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, >>>>>>>>>> and
is irrelevant to the fact that the meaning of the behaviour, if >>>>>>>>>> there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific
language. That
you may apply his words to a specific language does not mean that >>>>>>>> Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D*
What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
A straw man fallcy is a lie, so you are lying.
I am paraphrasing.
They stupidly expect that DDD emulated by HHH must
have the same behavior as DDD emulated by HHH1.
The ONLY way to do that is for HHH to emulate
DDD AGAINST THE RULES OF THE X86 LANGUAGE.
Because it is against the rules of the X86 language it is stupid to
expect that one correct simulation differs from another correct
simulation.
It may seem this way to people lacking
the capacity to pay complete attention.
I dared people to show the exact mistake of
DDD correctly simulated by HHH and the best
that they had was counter-factual statements.
But you failed,
*It is not my failure dip-shit*
*I dared you to show a correct simulation*
*of DDD by HHH where the simulated DDD reaches*
*its own "ret" instruction*
On 5/23/2025 1:36 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 20:18 schreef olcott:
On 5/23/2025 12:54 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 19:23 schreef olcott:
On 5/23/2025 5:50 AM, Fred. Zwarts wrote:
Op 21.mei.2025 om 21:40 schreef olcott:
On 5/21/2025 2:36 PM, Fred. Zwarts wrote:
Op 21.mei.2025 om 17:33 schreef olcott:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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 >>>>>>>>>>>>>
Do you understand that we are only evaluating whether >>>>>>>>>>>>> or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not >>>>>>>>>>>> mentioned
in the creteria and is therefore irrelevant, an obvious >>>>>>>>>>>> consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, >>>>>>>>>> and
is irrelevant to the fact that the meaning of the behaviour, if >>>>>>>>>> there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
And that is not the measure of a partial simulation that misses >>>>>>>> the part where the input specifies the abort and halts.
Because you are incompetent at software engineering
you are clueless about the idea of unreachable code.
Only irrelevant ad hominem attacks.
*unreachable code*
*unreachable code*
*unreachable code*
*unreachable code*
Only in your dream. It is a verifiable fact that the input specifies
a halting program.
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
If you weren't a damned liar you could
show all of the steps of exactly how
DDD correctly simulated by HHH halts.
It does not help when you failed to create a square circle to ask for
a correct squared circle.
I am giving up on you because you proved that you are a damned liar.
On 5/23/2025 1:47 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 20:36 schreef olcott:
On 5/23/2025 1:30 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 19:54 schreef olcott:
On 5/23/2025 12:49 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 18:24 schreef olcott:
On 5/23/2025 1:56 AM, Mikko wrote:
On 2025-05-22 22:35:51 +0000, olcott said:
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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 >>>>>>>>>>>>>>>
Do you understand that we are only evaluating whether >>>>>>>>>>>>>>> or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not >>>>>>>>>>>>>> mentioned
in the creteria and is therefore irrelevant, an obvious >>>>>>>>>>>>>> consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that
specification, and
is irrelevant to the fact that the meaning of the behaviour, if >>>>>>>>>>>> there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific
language. That
you may apply his words to a specific language does not mean that >>>>>>>>>> Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D* >>>>>>>>> What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
A straw man fallcy is a lie, so you are lying.
I am paraphrasing.
They stupidly expect that DDD emulated by HHH must
have the same behavior as DDD emulated by HHH1.
The ONLY way to do that is for HHH to emulate
DDD AGAINST THE RULES OF THE X86 LANGUAGE.
Because it is against the rules of the X86 language it is stupid
to expect that one correct simulation differs from another correct >>>>>> simulation.
It may seem this way to people lacking
the capacity to pay complete attention.
I dared people to show the exact mistake of
DDD correctly simulated by HHH and the best
that they had was counter-factual statements.
But you failed,
*It is not my failure dip-shit*
It is.
*I dared you to show a correct simulation*
*of DDD by HHH where the simulated DDD reaches*
*its own "ret" instruction*
And I told you that such a HHH does not exists.
Do you know that when DDD emulated by HHH cannot reach
its own "ret" instruction (final halt state)
that this means that DDD emulated by HHH DOES NOT HALT?
On 5/23/2025 5:50 AM, Fred. Zwarts wrote:
Op 21.mei.2025 om 21:40 schreef olcott:
On 5/21/2025 2:36 PM, Fred. Zwarts wrote:
Op 21.mei.2025 om 17:33 schreef olcott:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and >>>>>> is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
And that is not the measure of a partial simulation that misses the
part where the input specifies the abort and halts.
Because you are incompetent at software engineering
you are clueless about the idea of unreachable code.
Only irrelevant ad hominem attacks.
*unreachable code*
*unreachable code*
*unreachable code*
*unreachable code*
Not rebuttal. So, it seems you understand that that is not the measure
of a partial simulation that misses the part where the input specifies
a halting behaviour.
The halting behavior is *unreachable code*
The halting behavior is *unreachable code*
The halting behavior is *unreachable code*
Your lack of technical competence is not my bug.
Your lack of technical competence is not my bug.
Your lack of technical competence is not my bug.
that makes that it does not show the behaviour specified in the input
(because it aborts before it could reach the verifiable reachable end
of the program), does not change the fact that that behaviour *is*
specified in the input.
On 5/23/2025 1:47 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 20:36 schreef olcott:
On 5/23/2025 1:30 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 19:54 schreef olcott:
On 5/23/2025 12:49 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 18:24 schreef olcott:
On 5/23/2025 1:56 AM, Mikko wrote:
On 2025-05-22 22:35:51 +0000, olcott said:
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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 >>>>>>>>>>>>>>>
Do you understand that we are only evaluating whether >>>>>>>>>>>>>>> or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not >>>>>>>>>>>>>> mentioned
in the creteria and is therefore irrelevant, an obvious >>>>>>>>>>>>>> consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that
specification, and
is irrelevant to the fact that the meaning of the behaviour, if >>>>>>>>>>>> there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific
language. That
you may apply his words to a specific language does not mean that >>>>>>>>>> Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D* >>>>>>>>> What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
A straw man fallcy is a lie, so you are lying.
I am paraphrasing.
They stupidly expect that DDD emulated by HHH must
have the same behavior as DDD emulated by HHH1.
The ONLY way to do that is for HHH to emulate
DDD AGAINST THE RULES OF THE X86 LANGUAGE.
Because it is against the rules of the X86 language it is stupid
to expect that one correct simulation differs from another correct >>>>>> simulation.
It may seem this way to people lacking
the capacity to pay complete attention.
I dared people to show the exact mistake of
DDD correctly simulated by HHH and the best
that they had was counter-factual statements.
But you failed,
*It is not my failure dip-shit*
It is.
*I dared you to show a correct simulation*
*of DDD by HHH where the simulated DDD reaches*
*its own "ret" instruction*
And I told you that such a HHH does not exists.
Do you know that when DDD emulated by HHH cannot reach
its own "ret" instruction (final halt state)
that this means that DDD emulated by HHH DOES NOT HALT?
On 5/23/2025 1:56 AM, Mikko wrote:
On 2025-05-22 22:35:51 +0000, olcott said:
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and >>>>>> is irrelevant to the fact that the meaning of the behaviour, if
there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific language. That >>>> you may apply his words to a specific language does not mean that
Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D*
What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
A straw man fallcy is a lie, so you are lying.
I am paraphrasing.
On 5/23/2025 1:58 AM, Mikko wrote:
On 2025-05-22 22:23:17 +0000, olcott said:
On 5/22/2025 3:50 AM, Mikko wrote:
On 2025-05-20 16:46:10 +0000, olcott said:
On 5/20/2025 11:44 AM, Richard Heathfield wrote:
On 20/05/2025 17:18, olcott wrote:
No one has actually made any rebuttal of my actual points.
It's far from clear what your actual points are.
But I repeat myself.
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met
That does not clarify what your actual points are.
You should answer all questions about you actual points with a
pointer to the paragraph on your web page where the answer is.
*Here is Mike Terry Proving*
Re: Mike Terry Proves --- *RIGHT HERE RIGHT NOW*
How the requirements that Professor Sipser agreed to are exactly met
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser(Mike says much more about this)
is far more likely (I'd say) to have agreed to.
;
First you should understand the basic idea behind a
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted",
so it can decide "non-halting".
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
So one of your actual points is that you are wrong as proven by Mike Terry. >>
Mike Terry was completely correct in exactly how
these words define a simulating termination analyzer
that correctly rejects an infinite loop.
On 5/23/2025 2:01 AM, Mikko wrote:
On 2025-05-22 22:28:00 +0000, olcott said:
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or cheated.
On 2025-05-15 23:43:27 +0000, olcott said:On 5/14/2025 7:36 PM, Mike Terry wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was doing but cheated.
To sincerely agree with you without extreme care is an error. >>>>>>>>>>>>>>>>
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not >>>>>>>>>>>>>>> supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly
 met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>>>> than the next best reviewer. Mike is one of the few >>>>>>>>>>>>>> people here that really wants an honest dialogue. He >>>>>>>>>>>>>> carefully examined my code and has a nearly perfect >>>>>>>>>>>>>> understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>>>
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's >>>>>>>>>>>>> ability to keep the discussion honest is restricted to ones own >>>>>>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation >>>>>>>>>>>>>> of DDD, instead it bases its decision on a different >>>>>>>>>>>>>> HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>>>>>> simulated D would never stop running unless aborted". If HHH bases
its decision on anything else than what its actual input actually >>>>>>>>>>>>> specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he has
started using the phrase "..bases its decision on a different *HHH/DDD
pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD does
above. It tells PO that in the tight loop example, H correctly >>>>>>>>>>> simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so it
can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair >>>>>>>>>>> where this hypothetical instance of itself never aborts. >>>>>>>>>>>
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and NOTHING >>>>>>>>>> (correct) can simulate this DDD past the call the HHH as that code >>>>>>>>>> isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a program, you
can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in >>>>>>>> memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your setup >>>>>>>> is improper and makes it non-turing equivalent to what you claim it is.
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the code >>>>>> of the original HHH, and thus the Hypothetical HHH (just like HHH1) >>>>>> WILL reach a final state.
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something.
That is a damned lie and you know it.
It isn't but it does not matter whether you know it.
AN ERROR OF REASONING IS USUALLY CORRECT ???
Moronically stupid.
On 5/24/2025 2:25 AM, Mikko wrote:
On 2025-05-23 16:24:25 +0000, olcott said:
On 5/23/2025 1:56 AM, Mikko wrote:
On 2025-05-22 22:35:51 +0000, olcott said:
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not
mentioned
in the creteria and is therefore irrelevant, an obvious
consequence
of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and >>>>>>>> is irrelevant to the fact that the meaning of the behaviour, if >>>>>>>> there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific language.
That
you may apply his words to a specific language does not mean that
Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D*
What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
A straw man fallcy is a lie, so you are lying.
I am paraphrasing.
No, a paraphrase preserves the meaning though may focus to a particular
aspect of that meaning. You were trying a straw man deception.
If you don't disagree with their actual statement then you don't
disagree.
People do expect that DDD emulated by HHH according to
the rules of the x86 language will have the same behavior
of the directly executed DDD. They are far too dishonest
to see that this is impossible.
The only way that their goal could be implemented is
the kind of cheats that I provided about.
If you want DDD emulated by HHH to halt then you must
cheat.
On 5/24/2025 2:25 AM, Mikko wrote:
On 2025-05-23 16:24:25 +0000, olcott said:
On 5/23/2025 1:56 AM, Mikko wrote:
On 2025-05-22 22:35:51 +0000, olcott said:
On 5/22/2025 3:18 AM, Mikko wrote:
On 2025-05-21 15:33:23 +0000, olcott said:
On 5/21/2025 3:12 AM, Mikko wrote:
On 2025-05-20 14:37:40 +0000, olcott said:
On 5/20/2025 2:06 AM, Mikko wrote:
On 2025-05-20 04:20:54 +0000, olcott said:
<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
Do you understand that we are only evaluating whether
or not HHH/DDD meets this above criteria?
I do understand that the meaning of the behaviour is not mentioned >>>>>>>>>> in the creteria and is therefore irrelevant, an obvious consequence >>>>>>>>>> of which is that your "WRONG!" above is false.
*H correctly simulates its input D until*
specifies that HHH must simulate DDD according
to the meaning of the rules of the x86 language.
The words Sipser agreed to do not refer to that specification, and >>>>>>>> is irrelevant to the fact that the meaning of the behaviour, if >>>>>>>> there is any, isn't referred there, either.
Sure they do. There is only a single measure of
*H correctly simulates its input D*
When the language of D is the x86 language.
No, they do not. Sipser said nothing about any specific language. That >>>>>> you may apply his words to a specific language does not mean that
Sipser referred to that language.
*If simulating halt decider H correctly simulates its input D*
What is the criterion measure of a correct simulation?
_DDD()
[00002192] 55Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002193] 8bec          mov ebp,esp
[00002195] 6892210000Â Â Â Â push 00002192
[0000219a] e833f4ffff    call 000015d2 // call HHH
[0000219f] 83c404Â Â Â Â Â Â Â Â add esp,+04
[000021a2] 5d            pop ebp
[000021a3] c3Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [000021a3]
The damned liars here are trying to get away with
a correct simulation of DDD interprets: "push ebp"
to mean "jmp 000021a3"
A straw man fallcy is a lie, so you are lying.
I am paraphrasing.
No, a paraphrase preserves the meaning though may focus to a particular
aspect of that meaning. You were trying a straw man deception.
If you don't disagree with their actual statement then you don't disagree.
People do expect that DDD emulated by HHH according to
the rules of the x86 language will have the same behavior
of the directly executed DDD.
On 5/24/2025 2:26 AM, Mikko wrote:
On 2025-05-23 16:37:41 +0000, olcott said:
On 5/23/2025 1:58 AM, Mikko wrote:
On 2025-05-22 22:23:17 +0000, olcott said:
On 5/22/2025 3:50 AM, Mikko wrote:
On 2025-05-20 16:46:10 +0000, olcott said:
On 5/20/2025 11:44 AM, Richard Heathfield wrote:That does not clarify what your actual points are.
On 20/05/2025 17:18, olcott wrote:
No one has actually made any rebuttal of my actual points.
It's far from clear what your actual points are.
But I repeat myself.
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met >>>>>>
You should answer all questions about you actual points with a
pointer to the paragraph on your web page where the answer is.
*Here is Mike Terry Proving*
Re: Mike Terry Proves --- *RIGHT HERE RIGHT NOW*
How the requirements that Professor Sipser agreed to are exactly met >>>>>
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser(Mike says much more about this)
is far more likely (I'd say) to have agreed to.
;
First you should understand the basic idea behind a
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD
does above. It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that >>>>> "its simulated input would never stop running unless aborted",
so it can decide "non-halting".
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
So one of your actual points is that you are wrong as proven by Mike Terry.
Mike Terry was completely correct in exactly how
these words define a simulating termination analyzer
that correctly rejects an infinite loop.
Which means you were wrong when you tried to interprete them otherwise.
I have never interpreted them differently since the day
that I wrote them.
<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
It is a tautology that any input D to a simulating termination
analyzer H that must be aborted to prevent the its infinite
execution is a non-terminating input.
On 5/19/2025 5:20 AM, Mikko wrote:
On 2025-05-18 20:19:19 +0000, olcott said:
On 5/18/2025 3:13 PM, Richard Damon wrote:
On 5/18/25 4:03 PM, olcott wrote:
On 5/18/2025 2:45 PM, Richard Damon wrote:
On 5/18/25 3:32 PM, olcott wrote:
On 5/18/2025 2:25 PM, Richard Damon wrote:
On 5/18/25 1:28 PM, olcott wrote:
On 5/18/2025 10:21 AM, Mike Terry wrote:
On 18/05/2025 10:09, Mikko wrote:
On 2025-05-17 17:15:14 +0000, olcott said:
On 5/17/2025 5:06 AM, Mikko wrote:That page does not show all of the message.
On 2025-05-16 15:07:03 +0000, olcott said:
On 5/16/2025 2:13 AM, Mikko wrote:That is compatible with the idea that Sipser scewed up or cheated.
On 2025-05-15 23:43:27 +0000, olcott said:On 5/14/2025 7:36 PM, Mike Terry wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting >>>>>>>>>>>>>>>>>> Problem in that the code thatNope, only to youtr INCORRECTLY simuated by HHH. >>>>>>>>>>>>>>>>>
"does the opposite of whatever value that HHH returns" >>>>>>>>>>>>>>>>>> becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>>>>>>>>>
In other words you believe that professor Sipser >>>>>>>>>>>>>>>> screwed up when he agreed with these exact words. >>>>>>>>>>>>>>>>
<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>
One may indeed thik so. Or pehaps he knew what he was doing but cheated.
To sincerely agree with you without extreme care is an error. >>>>>>>>>>>>>>
There is a natural (and correct) statement that Sipser >>>>>>>>>>>>>> Â > is far more likely (I'd say) to have agreed to. >>>>>>>>>>>>>
First you should understand the basic idea behind a >>>>>>>>>>>>>> Â > "Simulating Halt Decider" (*SHD*) that /partially/ >>>>>>>>>>>>>> Â > simulates its input, while observing each simulation >>>>>>>>>>>>>> Â > step looking for certain halting/non-halting patterns >>>>>>>>>>>>>> Â > in the simulation. A simple (working) example here >>>>>>>>>>>>>> Â > is an input which goes into a tight loop.(Mike says much more about this)
*Click here to get the whole article*
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E >>>>>>>>>>>>>>
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
There he explains an error in your claim to meet the requirements that
Professor Sipser agreed.
He also shows that your "In other words you believe that professor
Sipser screwed up when he agreed with these exact words" is not >>>>>>>>>>>>> supported by evidence (but that is quite obvious anyway). >>>>>>>>>>>>>
*That is fully addressed in my reply to Mike*
On 5/17/2025 10:31 AM, olcott wrote:
[How the requirements that Professor Sipser agreed to are exactly >>>>>>>>>>>> Â met --- Mike my best reviewer]
Message-ID: <100aa5c$f19u$1@dont-email.me>
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3C100aa5c%24f19u%241%40dont-email.me%3E >>>>>>>>>>>
You say there:
Mike's reviews of my work are at least ten-fold better >>>>>>>>>>>> than the next best reviewer. Mike is one of the few
people here that really wants an honest dialogue. He
carefully examined my code and has a nearly perfect
understanding.
Mike and I agree about everything essential in these discussion, and
I havn't noticed any disagreement is the less essential. >>>>>>>>>>>
Your statement "Mike is one of the few people here that really wants
an honest dialogue" is far from true. Some peole may have a stronger
desire to keep the discussion honest but there are not many who have
any reason to want any dishonest discussion. Of course everyone's >>>>>>>>>>> ability to keep the discussion honest is restricted to ones own >>>>>>>>>>> contributions.
You also say:
HHH(DDD) does not base its decision on the actual
behavior of DDD after it has aborted its simulation
of DDD, instead it bases its decision on a different
HHH/DDD pair that never aborts.
This is why HHH does not satisfy "H correctly determines that its >>>>>>>>>>> simulated D would never stop running unless aborted". If HHH bases >>>>>>>>>>> its decision on anything else than what its actual input actually >>>>>>>>>>> specifies it does not decide correctly.
Right. It seems to be a recent innovation in PO's wording that he has
started using the phrase "..bases its decision on a different *HHH/DDD
pair* ..".
On 5/14/2025 7:36 PM, Mike Terry wrote:
we can easily interpret that as saying exactly what I said a SHD does >>>>>>>>> above. It tells PO that in the tight loop example, H correctly >>>>>>>>> simulates as far as [A], at which point it correctly determines that >>>>>>>>> "its simulated input would never stop running unless aborted", so it >>>>>>>>> can decide "non-halting".
Thus SHD must report on a different SHD/Infinite_Loop pair
where this hypothetical instance of itself never aborts.
If H always reports on the behavior of its simulated
input after it aborts then every input including
infinite_loop would be determined to be halting.
Instead H must report on the hypothetical H/D input
pair where the very same H has been made to not abort
its input.
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]
*H correctly determines that its simulated D*
*would never stop running unless aborted*
by a hypothetical instance of itself that never aborts.
Unless HHH aborts its simulation of DDD then
(a) The simulated DDD
(b) The executed HHH()
(c) The executed DDD()
(d) Every function that HHH calls
NEVER STOP RUNNING
The first problem is your DDD is just a category error, and NOTHING >>>>>>>> (correct) can simulate this DDD past the call the HHH as that code >>>>>>>> isn't in the input.
I have corrected you on this too many times.
HHH and DDD are in the same memory space.
WHich means that since DDD references HHH, for DDD to be a program, you >>>>>> can't change HHH.
Thus, to do you hypothetical, you need to put it somewhere else in >>>>>> memory, or admit you can't chage it.
That you keep "forgetting" this is either dishonesty
or your ADD is much more disabling than I thought.
No, it is following the rules.
All you are doing is showing that you are "forgetting" that your setup >>>>>> is improper and makes it non-turing equivalent to what you claim it is. >>>>>>
*Unless HHH aborts its simulation of DDD*
(a) Simulated DDD NEVER HALTS
(b) Executed DDD() NEVER HALTS
(c) Executed HHH() NEVER HALTS
(d) Everything that HHH calls NEVER HALTS
But "HHH" DOES abort its simulation,
When HHH correctly determines that DDD simulated by a
hypothetical instance of itself that never aborts
*would never stop running* exactly meeting the criteria.
But that doesn't happen, as DDD (to be a valid input) includes the code >>>> of the original HHH, and thus the Hypothetical HHH (just like HHH1)
WILL reach a final state.
You keep the strawman fallacy.
A straw man fallacy is a (usually) correct refutation of something.
How damned dishonest can you get?
You are saying that an error is usually correct.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:44:47 |
| Calls: | 9,798 |
| Files: | 13,751 |
| Messages: | 6,189,098 |