Re: Hypothetical IMpossibilities -- I reread this again more carefully

On 7/21/24 10:34 AM, olcott wrote:

On 7/21/2024 9:24 AM, joes wrote:

Am Sun, 21 Jul 2024 08:08:53 -0500 schrieb olcott:

On 7/21/2024 6:37 AM, Richard Damon wrote:

On 7/21/24 12:15 AM, olcott wrote:

When the simulation stops running the whole program exits to the
operating system.

Yes. That doesn't mean that DDD itself would terminate.
>

Correct.

Which means you agree that HHH's aborting of its simuliation doesn't stop the behavior of DDD, but it continues until we find what it does.

 

Because (a) We know that it is a logical impossibility for any decider
HHH to report on the halt status of any input that does the opposite of
whatever it reports.
(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within. Deciders only take finite
string inputs. They do not take executing processes as inputs. Thus HHH
is not allowed to report on the behavior of this int main() { DDD(); }.

 

That IS exactly the input.
>

 The behavior of emulated DDD after it has been aborted
changes the behavior of the directly existed DDD.
 

No, it doesn't CHANGE the behavior, but the fact that HHH aborts its simulation of its input and returns ESTABLISHES the behavior of ALL copies of that DDD that call it.

When the second call of what would otherwise be infinite recursion
is required to be aborted to prevent the infinite execution of the
first call this proves that HHH(DDD)==0 is correct even though
the directly executed DDD() halts.

It never WAS "otherwise infinite recursin" because this HHH ALWAYS ABORTED it input. You confuse the different problems in your set of problems with one program "changing" which doesn't actually happen.

 

Therefore we map the finite string input to HHH(DDD) to the behavior
that it species on the basis of DDD correctly emulated by any pure
function HHH that can possibly exist.

The basis is the direct behaviour.
>

 Unless you think the idea of UTMs is wrong-headed nonsense
the behavior of DDD correctly emulated by HHH determines
the actual behavior specified by the input to HHH(DDD).
 

No, because the decider HHH is not a UTM. PERIOD, The only version of HHH that acts like a UTM is the one that never aborts its simulation, and that one you have shown doesn't answer and thus is not a decider.
Thus, you are showing that you don't understand what a UTM actually is, because you have made yourself INTENTIONALLY IGNORANT of the topic.
The ACTUAL UTM processing of the EXACT input to HHH, which means the DDD paired to that HHH, shows what the behavior of that input is.
And that behavior is that DDD calls HHH(DDD) which will emulate its input for awhile and then abort its emulation and return to DDD which will return, showing that DDD halts, and thus this HHH didn't NEED to abort its simulation, but does.
Of course, the different DDD, built on the different HHH that never aborts, does need to be aborted, but that is a different input.
The fact that you try to define DDD to NOT include that code for HHH just shows that you don't understand what a "Program" actually is, and that you figured by excluding it, you could LIE that all the inputs were the same, when they are not. Of course, by defining your input to not include the copy of HHH means your input isn't the representation of a program, and isn't actually emulatable, and thus your HHH isn't actually a halt decider, so everything you have said is shown to be a LIE.