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: HHH maps its input to the behavior specified by it --- key error
 in all the proofs
Date: Sat, 10 Aug 2024 19:51:10 -0500
Organization: A noiseless patient Spider
Lines: 191
Message-ID: <v991tu$vepo$2@dont-email.me>
References: <v8jh7m$30k55$1@dont-email.me> <v97rq3$l4f4$4@dont-email.me>
 <v97t7g$m8l6$1@dont-email.me>
 <332fdac834dd53dbe6a8650e170f08fac33ca2cf@i2pn2.org>
 <v988fu$r9k6$1@dont-email.me>
 <614b136972063ab2c9d5e3d91e4289858ef24f55@i2pn2.org>
 <v98ag9$rj63$1@dont-email.me>
 <9721b1bcc4a6849dabc5d7956754292823381840@i2pn2.org>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 11 Aug 2024 02:51:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2823e9f63915b861ed765b8be41520b0";
	logging-data="1030968"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18uPIBDENGVQdKp45Qgas+s"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Nak8ZPb41efNQx9/k3ehkLC9Ijk=
Content-Language: en-US
In-Reply-To: <60f1a533219c1237071f358999228eb48727f5e9@i2pn2.org>
Bytes: 9772

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.

>>
>> You might not be open-minded or smart enough to understand
>> this. Mike may be smart enough if he can manage to be
>> open-minded enough to pay attention to every single detail
>> of what I said without leaping to the conclusion that I must be
>> wrong. Ben understood this more deeply than anyone else.
>>
>>
> 
> Nope, you are just showing you don't understand what you are talking about.
> 

That no one "believes" the mapping that the finite string
specifies because they never had a slight clue about the
semantics that the x86 language specifies or they do know
this semantics yet don't bother to check the actual trace
because believe that I must be incorrect
DOES NOT MATTER, I AM PROVEN CORRECT EITHER WAY.

> If you want to make any of your claims, PROVE THEM by showing an ACTUAL 
> PROOF starting from the actual definitions and established truths of the 
> field, and then with accepted truth preserving operations show how to 
> combine them to get to your answer.
> 

I did hundreds of times for three years and people are
either clueless or don't want to bother checking that
I am correct.

*I am proven correct in that the execution trace of DDD*
*derived by HHH and the simulated HHH exactly matches the*
*x86 source code of DDD*

> Your problem is you just don't know any of those basics, so you can't do 
> it, which just makes you into a liar that makes unsubstantiated claims, 
> proving your ignorance.
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========