Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: No decider is ever allowed to report on the behavior of the
 computation that itself is contained within
Date: Wed, 22 May 2024 16:19:27 -0500
Organization: A noiseless patient Spider
Lines: 127
Message-ID: <v2lnh0$1c0ls$1@dont-email.me>
References: <EOydnaeszcdfHS__nZ2dnUU7_83NnZ2d@giganews.com>
 <PtvsK.300027$5fVf.158200@fx09.iad>
 <CaWdnZEntLawFS__nZ2dnUU7_83NnZ2d@giganews.com>
 <ccb8af3c-e497-4d6e-8040-826a4e87a6e7n@googlegroups.com>
 <g9qdnRjZj9uBlS7_nZ2dnUU7_8zNnZ2d@giganews.com>
 <0f7ed34c-5aaa-4858-885e-66e16777f599n@googlegroups.com>
 <87a6a44s02.fsf@bsb.me.uk>
 <a9adde1d-ad2c-444c-9b14-88841f5e8783n@googlegroups.com>
 <87sfnv2e6e.fsf@bsb.me.uk>
 <3a337f21-4828-46c4-b5be-87c76cff9db4n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 22 May 2024 23:19:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9557ecc38a2c6e613b1947df9dd7fc56";
	logging-data="1442492"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/xx2G1kwZN9PXwGYM2vYJP"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rNTHC8CaTNan9C5uSqp8DBpCH1U=
Content-Language: en-US
In-Reply-To: <3a337f21-4828-46c4-b5be-87c76cff9db4n@googlegroups.com>
Bytes: 7416

On 6/24/2022 2:53 AM, Malcolm McLean wrote:
> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>> ever before.
>>>>>>>>> especially if that is what P calls
>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>
>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>
>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>
>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>
>>>>>> That is an actual immutable verified fact.
>>>>>>
>>>>> That's your conclusion from your observations and reasoning. You've
>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>> explanation is the one you've given but, as I said, that explanation
>>>>> has rather far-reaching consequences.
>>>> There is only one explanation. What you call the "dry-run" is not that
>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>> days. There are two computations -- one that is not stopped and one
>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>> what's going on.
>>>>
>>> I'm a scientists, not a mathematician.
>>> The example I always use is that you are doing an energy budget for tigers.
>>> You work how much they use on running about, lactating, maintaining their
>>> body temperature, and so on.
>>>
>>> Now let's say that you find that all results are within a few percentage points
>>> of a similar budget done for lions. You'd instantly accept this data.
>>>
>>> Now let's say that the results are wildly different from a previous budget done
>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>> understand the reasons tigers spend far less energy on movement than lions.
>>>
>>> Now let's say that the result show that tigers use more energy than they
>>> take in food. Would you instantly conclude that the law of conservation of
>>> energy must be incorrect?
>>>
>>> The third is what PO is doing.
>> I have no idea what parts of this analogy map to the current situation.
>> PO has no contradictory results about anything. There's no conflict
>> with any established facts in anything he is doing.
>>
> He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
> and H reports that it doesn't halt. He's run P(P) and it halts.
> 
> So something odd is going on there that needs an explanation.

*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }

In the above case a simulator is an x86 emulator that correctly emulates
at least one of the x86 instructions of D in the order specified by the
x86 instructions of D.

This may include correctly emulating the x86 instructions of H in the
order specified by the x86 instructions of H thus calling H(D,D) in
recursive simulation.

It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that

D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.

Deciders are only accountable for the behavior of their inputs
and are thus not allowed to report on the behavior of the computation
that they themselves are contained within.

There is no Turing machine that can possibly take its actual
self as an input because actual Turing Machines are not allowed
as inputs to other Turing Machines.

*thus the behavior of D(D) executed from main() has always been moot*
*thus the behavior of D(D) executed from main() has always been moot*
*thus the behavior of D(D) executed from main() has always been moot*


-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer