Re: Sequence of sequence, selection and iteration matters --- Ben agrees (typo corrected)

On 7/9/24 10:44 AM, olcott wrote:

On 7/9/2024 6:29 AM, Richard Damon wrote:

On 7/9/24 12:01 AM, olcott wrote:

>
It correctly determines that it needs to abort,
it aborts then it reports that it needed to abort.

>
But that is the question of POOP, not halting.
>

 *It does meet this criteria*

Nope.

 <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>
 *You disavow sequence of sequence, selection and iteration*
*I have never explained this issue to Ben this clearly before*
Ben seems to believe that HHH must report that it need not
abort its emulation of DDD because AFTER HHH has already
aborted this emulation DDD does not need to be aborted.
 

Nope, YOU don't understand about the deterministic nature of programs or the difference between partial knowledge and actual truth.
The emulation of DDD is not all of the behavior of DDD if it is aborted.
Note, once you define that your HHH will abort under a certain condition that the emulation of the DDD built on that HHH will meet, then the behavior of that DDD is established to be Halting. We don't need to run HHH(DDD) for that to happen, it comes out of determinism.
Note "Sequence, Selection, and Iteration" are concepts that explain how we define how a program runs. But it does NOT establish a causual link bettween different instances of programs.
The define behavior of DDD is established as soon as it is created. The behavior is REVEALED as it is run, and partially as it is simulated partially.
Note that the simulation that HHH is doing is on a different instance of DDD than the DDD that might be calling it. That aborting does NOT actually affect the behavior of the instance it is emulating, that instnce just becomes unobservable. But the behavior of the DDD that is possibly calling that HHH doing the simuation has been established by that definiton and the then behavior of HHH. SInce it WILL return, then the behavior of ALL DDDs is to return.
And because of that, we CAN say that HHH did not NEED to abort its emulation, as a complete emulation of this input (which calls the aborting HHH which is the only HHH in view) will halt.
We can't talk about an HHH that doesn't abort at this point, as the one and only HHH in view did abort. To try to change it at this point is to just LIE.