Sujet : Re: Mike Terry Proves --- How the requirements that Professor Sipser agreed to are exactly met
De : polcott333 (at) *nospam* gmail.com (olcott)
Groupes : comp.theoryDate : 18. May 2025, 18:28:05
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <100d5b7$13m1e$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Mozilla Thunderbird
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
> "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
-- Copyright 2025 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer
Overcoming the proof of undecidability of the Halting Problem by a simple example in C
Re: Overcoming the proof of undecidability of the Halting Problem by a simple example in C