Re: Mike Terry Proves --- How the requirements that Professor Sipser agreed to are exactly met

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:
 

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/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
  

 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.

A straw man fallacy is not an error of reasoning. It is a false
attribution of the claim that is refuted.

*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.

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.
--
Mikko