Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: Who here understands that the last paragraph is Necessarily true?
Date: Sat, 20 Jul 2024 12:20:03 +0300
Organization: -
Lines: 86
Message-ID: <v7fvg3$3fmfv$1@dont-email.me>
References: <v6un9t$3nufp$1@dont-email.me> <v7013v$2ccv$1@dont-email.me> <v70nt7$61d8$6@dont-email.me> <58fc6559638120b31e128fe97b5e955248afe218@i2pn2.org> <v71mjh$bp3i$1@dont-email.me> <1173a460ee95e0ca82c08abecdefc80ba86646ac@i2pn2.org> <v71okl$bvm2$1@dont-email.me> <5f6daf68f1b4ffac854d239282bc811b5b806659@i2pn2.org> <v71ttb$crk4$1@dont-email.me> <60e7a93cb8cec0afb68b3e40a0e82e9d63fa8e2a@i2pn2.org> <v721po$h4kr$1@dont-email.me> <v75a0l$16bjt$1@dont-email.me> <v76dth$1cf96$3@dont-email.me> <v77sna$1o83i$1@dont-email.me> <v78grc$1rc43$7@dont-email.me> <159ee197e838dba6c5c6909dca74c8a14e136246@i2pn2.org> <v78uhb$1ud1t$1@dont-email.me> <049a13f967ba3113219beb2223852628643f850e@i2pn2.org> <v79a09$208km$1@dont-email.me> <4a999933a5d46fc107a48bd20c57b351c0bf5e43@i2pn2.org> <v7b808$2e2aq$5@dont-email.me> <71c39e9ce213567b8a958fb5b9fe253d29cf0bcf@i2pn2.org> <v7bcri$2fhfm$1@dont-email.me> <v7d1f7$2s8e2$1@dont-email.me> <v7dumg$30pvh$11@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 20 Jul 2024 11:20:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2909b1ca216a2f11cc9f02747cab45b6";
	logging-data="3660287"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+oSwg2RBwFWb3xy6RTPo08"
User-Agent: Unison/2.2
Cancel-Lock: sha1:JJ9u/zg8osXtifE5Y0WfSQ+HoDY=
Bytes: 6256

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