Path: ...!news.mixmin.net!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: HHH maps its input to the behavior specified by it --- key error
 in all the proofs
Date: Sun, 11 Aug 2024 07:40:28 -0500
Organization: A noiseless patient Spider
Lines: 316
Message-ID: <v9abfu$2nabt$1@dont-email.me>
References: <v8jh7m$30k55$1@dont-email.me> <v98e8s$sddi$2@dont-email.me>
 <f7a568982428ce74da1635a0537c47580063d45b@i2pn2.org>
 <v98g9c$sres$1@dont-email.me>
 <5586bed1ae799730f4f5cda602007aa0a67a5b71@i2pn2.org>
 <v98hpa$t1hv$1@dont-email.me>
 <2fee2a47a11178b8ec9089878a51aa7ccb410fc2@i2pn2.org>
 <v98j19$taas$1@dont-email.me>
 <e594b5b47303846026e79ab95d1ba6b528ba6267@i2pn2.org>
 <v98leq$tna8$1@dont-email.me>
 <f2715e52691fec808c2ae5953e65fb42f4e19fa9@i2pn2.org>
 <v98mj9$tunr$1@dont-email.me>
 <86cbe5924d3495f56986483f79567af3e6efde8a@i2pn2.org>
 <v98qbj$ul50$1@dont-email.me>
 <49e9799be11c5e626bc05a421227bb7563982f0d@i2pn2.org>
 <v98uf7$vepo$1@dont-email.me>
 <60f1a533219c1237071f358999228eb48727f5e9@i2pn2.org>
 <v991tu$vepo$2@dont-email.me>
 <895f5e9b934bbfb72925fb109043500d49100a6a@i2pn2.org>
 <v994vs$10cfm$1@dont-email.me>
 <dec62801011bc5bf0b9eb9a62c607cf407198609@i2pn2.org>
 <v99870$14mlk$1@dont-email.me>
 <0f8f134fe961ee00910cce1d7f05b632d7567c6c@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 11 Aug 2024 14:40:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2823e9f63915b861ed765b8be41520b0";
	logging-data="2861437"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/mvsukX8qHaggeh/bwzsd5"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:zgVnb6AlLCQ6tWDvkPT1aMmARFA=
In-Reply-To: <0f8f134fe961ee00910cce1d7f05b632d7567c6c@i2pn2.org>
Content-Language: en-US
Bytes: 15720

On 8/11/2024 6:08 AM, Richard Damon wrote:
> On 8/10/24 10:38 PM, olcott wrote:
>> On 8/10/2024 9:21 PM, Richard Damon wrote:
>>> On 8/10/24 9:43 PM, olcott wrote:
>>>> On 8/10/2024 8:13 PM, Richard Damon wrote:
>>>>> On 8/10/24 8:51 PM, olcott wrote:
>>>>>> On 8/10/2024 7:20 PM, Richard Damon wrote:
>>>>>>> On 8/10/24 7:52 PM, olcott wrote:
>>>>>>>> On 8/10/2024 5:47 PM, Richard Damon wrote:
>>>>>>>>> On 8/10/24 6:41 PM, olcott wrote:
>>>>>>>>>> On 8/10/2024 4:53 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/10/24 5:37 PM, olcott wrote:
>>>>>>>>>>>> On 8/10/2024 4:33 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 8/10/24 5:18 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/10/2024 3:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 8/10/24 4:36 PM, olcott wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As I have countlessly proven it only requires enough 
>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>> emulated steps to correctly infer that the input would 
>>>>>>>>>>>>>>>> never
>>>>>>>>>>>>>>>> reach is "return" instruction halt state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except that HHH does't do that, since if HHH decides to 
>>>>>>>>>>>>>>> abort and return, then the DDD that it is emulating WILL 
>>>>>>>>>>>>>>> return, just after HHH has stopped its emulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You just confuse the behavior of DDD with the PARTIAL 
>>>>>>>>>>>>>>> emulation that HHH does, because you lie about your false 
>>>>>>>>>>>>>>> "tautology".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Denying a tautology seems to make you a liar. I only
>>>>>>>>>>>>>>>> say "seems to" because I know that I am fallible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Claiming a false statement is a tautology only make you a 
>>>>>>>>>>>>>>> liar.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In this case, you lie is that the HHH that you are 
>>>>>>>>>>>>>>> talking about do the "correct emulation" you base you 
>>>>>>>>>>>>>>> claim on.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That is just a deception like the devil uses, has just a 
>>>>>>>>>>>>>>> hint of truth, but the core is a lie.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What I say is provably correct on the basis of the
>>>>>>>>>>>>>> semantics of the x86 language.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The x86 language says DDD will Halt if HHH(DDD) returns a 
>>>>>>>>>>>>> value.
>>>>>>>>>>>>
>>>>>>>>>>>> HHH is called by main() there is no directly executed DDD()
>>>>>>>>>>>> any where in the whole computation.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Except in your requirements, and we can see what it does by 
>>>>>>>>>>> adding a call to DDD from main, since nothing in your system 
>>>>>>>>>>> calls main.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> All that you need to know is that there is not any
>>>>>>>>>> directly executed DDD() anywhere in the computation.
>>>>>>>>>
>>>>>>>>> But there ccould be, and the behavior of it is what matters.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The key error of the halting problem proofs all of these
>>>>>>>> years has been the false assumption that a halt decider
>>>>>>>> must report on the behavior of the computation that itself
>>>>>>>> is contained within.
>>>>>>>
>>>>>>> But it isn't a false assemption, but an actual requirement.
>>>>>>>
>>>>>>> A Halt Decider must be able to correctly answer for ANY Turing 
>>>>>>> Machine represented as its input.
>>>>>>>
>>>>>>> ANY includes those that are built from a copy of itself.
>>>>>>>
>>>>>>> So, a Halt Decider needs to be able to correctly answer about 
>>>>>>> programs that include copies of itself, even with contrary 
>>>>>>> behavior, which is what makes it impossible to compute.
>>>>>>>
>>>>>>> You seem to confuse non-computable with invalid, it seems in part 
>>>>>>> because you don't understand the difference between knowledge and 
>>>>>>> truth.
>>>>>>>
>>>>>>>>
>>>>>>>> Everyone has simply assumed that the behavior of the
>>>>>>>> input to a decider must exactly match the direct execution
>>>>>>>> of this input. They only did this because everyone rejected
>>>>>>>> simulation out-of-hand without review.
>>>>>>>
>>>>>>> Because that is the DEFINITION of what it is to decide on.
>>>>>>>
>>>>>>> You just don't understand what a requirement is.
>>>>>>>
>>>>>>> Since the DEFINITION of "Correct Simulation" that you are trying 
>>>>>>> to use (from a UTM) means a machine the EXACTLY reproduces the 
>>>>>>> behavior of the direct exectution of the machine described by the 
>>>>>>> input, the correct simulation must exactly match the behavior of 
>>>>>>> the direct execution.
>>>>>>>
>>>>>>> You can't get out of it by trying to lie about it being different.
>>>>>>>
>>>>>>>>
>>>>>>>> This caused them to never notice that the input simulated
>>>>>>>> according to its correct semantics does call its own decider
>>>>>>>> in recursive simulation thus cannot possibly return to its
>>>>>>>> caller. The Linz proof is sufficiently isomorphic so this equally
>>>>>>>> applies to the Linz TM proof.
>>>>>>>
>>>>>>> Nope, just shows you don't know what "Correct" means.
>>>>>>>
>>>>>>> Your proof is NOT "sufficiently isomorphic" since by your own 
>>>>>>> claims it is clearly not even Turing Complete, so no where near 
>>>>>>> isomorphic.
>>>>>>>
>>>>>>>>
>>>>>>>> If HHH were to report on the direct execution of DDD it would
>>>>>>>> be breaking the definition of a halt decider that only computes
>>>>>>>> the mapping from its input...
>>>>>>>
>>>>>>> Nope. Since the mapping that it is supposed to compute is DEFINED 
>>>>>>> as based on the direct exectut
>>>>>>>
>>>>>>
>>>>>> No it never has been this. I has always been a mapping
>>>>>> from the behavior that the finite string specifies. It
>>>>>> has never been the behavior of the actual computation
>>>>>> that the decider is contained within.
>>>>>
>>>>>
>>>>> And thatg behavior is specified to be the behavior of the program 
>>>>> the input represents. PERIOD.
>>>>>
>>>>
>>>> That has never been true. It is always the case that every
>>>> decider of any kind only computes the mapping from its input
>>>> finite string and never gives a rat's ass about anything else
>>>> anywhere else.
>>>
>>> No, you are confusing capability with requirements.
>>>
>>> A "Foo Decider" has ALWAYS been required to compute the "Foo" 
>>> mapping, as that mapping is defined.
>>>
>>> The "Halting" mapping is defined as the behavior of the machine/input 
>>> represented by the input, so the input needs to be a representation 
>>> of the program and input and the decider tries to compute the mapping 
>>> of that representation to the behavior that program represents.
>>>
>>> How that isn't the "mapping" of the input to a Halt Decider seems to 
>>> put a big hole in your argument.
========== REMAINDER OF ARTICLE TRUNCATED ==========