Re: Who here understands that the last paragraph is Necessarily true?

On 2024-07-19 14:54:07 +0000, olcott said:

On 7/19/2024 1:35 AM, Fred. Zwarts wrote:

Op 18.jul.2024 om 17:37 schreef olcott:

On 7/18/2024 10:27 AM, joes wrote:

Am Thu, 18 Jul 2024 09:14:32 -0500 schrieb olcott:

On 7/18/2024 3:25 AM, joes wrote:

Am Wed, 17 Jul 2024 15:36:24 -0500 schrieb olcott:

On 7/17/2024 3:30 PM, joes wrote:

Am Wed, 17 Jul 2024 12:20:43 -0500 schrieb olcott:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

 

You have already said that a decider is not allowed to answer
anything other than its input. Now you say that the the program
at 15c3 is not a part of the input. Therefore a decider is not
allowed consider it even to the extent to decide whether it
ever returns. But without that knowledge it is not possible to
determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3
to non-halting behavior because this finite string calls
HHH(DDD) in recursive simulation.

That string is meaningless outside of the execution environment of
HHH,
specifically the simulation of DDD it is doing. It does not encode
anything, DDD does not have access to that address. That string
doesn't call anything, the program in HHH's memory space does.
Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a part of
the problem specification.

decider/input pairs <are> a key element of the specification.

 

The finite string does not reveal what is the effect of calling
whatever that address happens to contain.

A simulating termination analyzer proves this.
 

The behaviour of HHH is specified outside of the input. Therefore
your "decider" decides about a non-input, which you said is not
allowed.

HHH is not allowed to report on the behavior of it actual self in
its own directly executed process. HHH is allowed to report on the
effect of the behavior of the simulation of itself simulating DDD.

HHH must report on itself if its input calls it.
HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists in an entirely
different process.

Of course it doesn't make sense to return to a higher stack frame.
And of course a function can recursively call itself.

A separate process is like a different program on a different
computer.

It makes no sense to call a running program. DDD creates a new instance
of the same code with its own memory and code pointer.

It is not that it makes no sense it is that it is impossible.

 

I mean, why are you talking about that?

 All of the halting problem proofs are incorrectly anchored
in the behavior of the direct execution of the input thus
not the behavior that this input specifies to a decider that
this input invokes.

 Exactly the same input is presented to the direct execution and the simulation, namely the x86 code of the program.
The semantics of the x86 language does not change in these two cases, so a correct simulator should interpret the x86 in the same way as the direct execution.

 When you are hungry you remain hungry until you eat.
    Before HHH(DDD) aborts its emulation the directly
    executed DDD() cannot possibly halt.

As lame as your other analogies. Being hungry is a state: one can be
sometimes hungry and other times not whithout becaming another person.
Programs are constant texts. They don't have states. They only have
permanent properties.
--
Mikko