Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Ben thinks the professor Sipser is wrong
Date: Fri, 5 Jul 2024 07:24:29 -0500
Organization: A noiseless patient Spider
Lines: 120
Message-ID: <v68olt$39dkv$8@dont-email.me>
References: <tic5tr$25uem$6@dont-email.me> <8735bpq5jh.fsf@bsb.me.uk>
 <v66o6i$2rv8q$3@dont-email.me>
 <8bbce1bb519f205ef865a07719bf35f68170ad61@i2pn2.org>
 <v66psp$2scuh$1@dont-email.me>
 <990598b3a90c559f7125530edef9c5a0ef2c7102@i2pn2.org>
 <v677vh$2u7lu$2@dont-email.me>
 <dbebddf487aebc1c848fc07abb0f7800e068f34e@i2pn2.org>
 <v67d2s$2v7vf$1@dont-email.me>
 <852fe13440031ea2d8f54f4243b5329f4e1fbfb7@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 05 Jul 2024 14:24:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f325a973008a37eaa6ec545239278e3d";
	logging-data="3454623"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188aBIZmBorahlzrzx3x+Nv"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/tJJRQaLR8aPldWEhw/ejmZMl4o=
In-Reply-To: <852fe13440031ea2d8f54f4243b5329f4e1fbfb7@i2pn2.org>
Content-Language: en-US
Bytes: 7375

On 7/5/2024 5:11 AM, joes wrote:
> Am Thu, 04 Jul 2024 19:00:28 -0500 schrieb olcott:
>> On 7/4/2024 6:18 PM, Richard Damon wrote:
>>> On 7/4/24 6:33 PM, olcott wrote:
>>>> On 7/4/2024 5:21 PM, Richard Damon wrote:
>>>>> On 7/4/24 2:32 PM, olcott wrote:
>>>>>> On 7/4/2024 1:17 PM, Richard Damon wrote:
>>>>>>> On 7/4/24 2:04 PM, olcott wrote:
> 
>>>>>>>> Ben clearly agrees that the above criteria have been met,
>>>>>>>> yet feels that professor Sipser was tricked into agreeing that
>>>>>>>> this means that:
>>>>>>>>       H can abort its simulation of D and correctly report that
>>>>>>>>       D specifies a non-halting sequence of configurations.
>>>>>>>> I spent two years deriving those words that Professor Sipser
>>>>>>>> agreed with. It seems to me that every software engineer would
>>>>>>>> agree that the second part is logically entailed by the first
>>>>>>>> part.
>>>>>>>
>>>>>>> You mean you WASTED two years and set a trap for your self that you
>>>>>>> fell into.
>>>>>>> The problem is that Ben is adopting your definitions that professor
>>>>>>> Sipser is not using.
>>>>>>>
>>>>>> Ben agrees that my criteria have been met according to their exact
>>>>>> words. If you want to lie about that I won't talk to you again.
>>>>>>
>>>>> Which meant different things, so not the same.
>>>>> The biggest problem is your H/P interlocking program pair is
>>>>> something outside the normal scope of Computation theory.
>>>>> The way you have built your Deicder/Decider combination isn't actualy
>>>>> within the definition of normal Computaiton Theory, as that would
>>>>> have Decider as a totally independent program from the program it is
>>>>> deciding on.
>>>>> Your H and D aren't that sort of thing because they are interwined
>>>>> into a single memory space, and even share code.
>>>>> This makes some things possible to do about the pair that can not be
>>>>> done if they were independent programs, like H being able to detect
>>>>> that D calls itself (but not copies of itself, which is why you don't
>>>>> allow those copies, as that breasks your lie).
>>>>>
>>>> Ever heard of string comparison?
>>>> H can detect that D calls copies of itself.
>>>> That merely makes the details more complex.
>>>
>>> Nope, doesn't work. Particularly for Turing Machines.
>>> The problem is that the seperate compliation and linking with the
>>> resultant different address makes the byte pattern for the code not
>>> necessarily a duplicate.
>>> When you consider that the input is antagonistic, it can also
>>> intentionally make alterations that do not change the outward behavior,
>>> but do change the byte code.
>>> I seem to remember that it has been proven that, in general, the
>>> identification of an equivalent copy of yourself is uncomputable.
>>> We went over this before, and you could never understand it.
>>>
>>>
>>>>> Another of the big effect of thins, is that the way you defined it, D
>>>>> actually does have access to the decider that is going to decide it
>>>>> (if we follow your rule and name the decider H). This can turn what
>>>>> used to be an independent fully defined program P into a dependent
>>>>> program template.
>>>> The key issue is that by my basis structure that applies equally to DD
>>>> correctly simulated by HH as it applies to ⟨Ĥ⟩ correctly simulated by
>>>> embedded_H is that the paradoxical decision point cannot be reached.
>>>> This converts the "impossible" problem into a difficult one.
>>>
>>> Nope. Your basic structure can not be converted back into a pair of
>>> Turing Machihes, showing it isn't based on actual Computations.
>>>
>>>
>>>>> Undet THAT condition, Ben agreed that yoUr H could conclude that no
>>>>> version of H could simulate the version of D that uses it, to its
>>>>> final state. Since P is a template, and not a program, it doesn't
>>>>> have the normal Objective definition of behavior, and thus your
>>>>> subjective one might need to be used, even with its problems.
>>>>>
>>>> The key point that you must acknowledge before continuing is that the
>>>> criteria is met for H/D. I can't tolerate one more reply where you
>>>> deny this.
>>>
>>> But your criteria isn't a legal critieria. The "Behavior" of the input
>>> must be an objective property of just that input, and thus can not be
>>> something that depends on the decider looking at it.
>>>
>> It must depend on the decider looking at it or we are required to ignore
>> the actual fact that DDD does call HHH in recursive simulation.

> It is an accident that we try to decide DDD with the same program it is
> calling (well, it was engineered, but there is nothing special about it).
> HHH came first, and DDD is constructed on it.
> DDD has an independent behaviour when run directly/simulated correctly.
> Of course it calls HHH, but HHH has no power over it; it is bound to
> the behaviour of DDD.
> 

<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>

>>> Thus, the direct execution of the program the input repreesents is what
>>> is consider the "behavior of an input" that represents a program.
>>> And thus, since DDD() Halts, HHH(DDD) saying "non-halting" can not be
>>> correct.
>>> The question of can HHH simulate its input to a final state is just an
>>> incorrect question, and your logic that looks at different inputs to
>>> try to make you claim is just invalid.
> 
> 
> 

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