Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sun, 11 May 2025 16:13:50 -0500
Organization: A noiseless patient Spider
Lines: 126
Message-ID: <vvr3uf$ks69$1@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me>
 <vvnh9u$3hd96$1@raubtier-asyl.eternal-september.org>
 <vvno4e$3in62$2@dont-email.me>
 <5b14da4260c0b7e3235ce05f752c092fade4d70e.camel@gmail.com>
 <vvnsae$3in62$9@dont-email.me>
 <11cc09876004107c47467b9481f614f45f450f2c.camel@gmail.com>
 <vvnu9k$3k258$2@dont-email.me>
 <674a661e498281cca55b322cbd5905a1988a6171.camel@gmail.com>
 <vvnvut$3kher$3@dont-email.me>
 <088556c03067d8de7184bf88dd01cc6b8c99ba1b.camel@gmail.com>
 <vvo1ni$3l14p$1@dont-email.me>
 <c09f468e8485c22150cedb12a9010b401f292054.camel@gmail.com>
 <vvo58a$3lnkd$1@dont-email.me>
 <dc76ef3215a83481dfddc40c466bb9ebc0e77341.camel@gmail.com>
 <vvo709$3m1oc$1@dont-email.me>
 <b503e969e23dd1b2a6201ba78c82c9ff7906eaae.camel@gmail.com>
 <vvo9e8$3m1oc$3@dont-email.me>
 <b9cec56c1d257e09fdf8043f02f123a4243de6e1.camel@gmail.com>
 <vvoife$3ofmu$1@dont-email.me>
 <766e4a7e81e5c70c19b646874c52b62f22438811@i2pn2.org>
 <vvqjnf$gldn$11@dont-email.me>
 <f8d15f9ec3c4edd0dbc59f27b4c60c7d759d5a58@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 11 May 2025 23:13:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ef7faca461217fa132b1f53eef89d0be";
	logging-data="684233"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19lknk82hCV3pDPIWDLHURC"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:kNPzXivnzLKHZe2t2IL0/Z6p9vE=
In-Reply-To: <f8d15f9ec3c4edd0dbc59f27b4c60c7d759d5a58@i2pn2.org>
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250511-4, 5/11/2025), Outbound message
Content-Language: en-US
Bytes: 7423

On 5/11/2025 3:36 PM, Richard Damon wrote:
> On 5/11/25 12:37 PM, olcott wrote:
>> On 5/11/2025 6:07 AM, joes wrote:
>>> Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:
>>>> On 5/10/2025 4:44 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 1:37 PM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>>>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>
>>>>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>
>>> ...which makes it halt.
>>>
>>>>>>>>>>>>>>>> The input that has baffled computer scientists for 90 years
>>>>>>>>>>>>>>>> is merely correctly determined to be non-halting when the
>>>>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this
>>>>>>>>>>>>>>>> input according to the rules of the x86 language.
>>>
>>> Nobody is baffled. It halts.
>>>
>>>>>>>>>>>>> I have no problem with that. And, you said HHH merely rejects
>>>>>>>>>>>>> it as non-halting. You had denied HHH can decide the halting
>>>>>>>>>>>>> property of any input, except DDD/DD/D..
>>>>>>>>>>>>>
>>>>>>>>>>>> As long as HHH correctly determines the halt status of a single
>>>>>>>>>>>> input that has no inputs then HHH is a correct termination
>>>>>>>>>>>> analyzer for that input.
>>>>>>>>>>>
>>>>>>>>>>> I have no problem with that, but be noticed that the HHH inside
>>>>>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise, 
>>>>>>>>>>> the
>>>>>>>>>>> 'HHH'
>>>>>>>>>>> will be an infinite recursive which cannot make any decision,
>>>>>>>>>>> which you had agreed)
>>>
>>>>>> The original set theory is now called naive set theory after its
>>>>>> mistake has been corrected. Thus the original halting problem proofs
>>>>>> can now be called the naive halting problem proofs.
>>>>> Traditional logic (or the part mostly used) that won't cause confusion
>>>>> is more reliable.
>>>
>>> The HP doesn't lead to contradictions.
>>>
>>>>>> The halting problem itself remains the same, yet loses its most
>>>>>> important proof.
>>>>>
>>>>> HP is based on TM. Proof of any other kind other than TM have to be
>>>>> cautious.
>>>> Unless this is done as an actual simulating termination analyzer in a
>>>> high level language like C and it operates on a 100% complete 
>>>> exactingly
>>>> precise input specification such as the x86 language too many details
>>>> slip through the cracks of vagueness.
>>>
>>> TMs are concrete. What details, what vagueness?
>>>
>>
>> There isn't even a common TM language.
>> If there was a TM language then examining
>> the details of a termination analyzer would
>> be like reverse engineering all of the details
>> of how an operating system works from its
>> machine code. Humans really need high level
>> abstractions or they get totally lost.
> 
> There is a standardize version of the Turing Machine Language.
> 
> The fact the problem is too big for you to understand just shows that 
> you are just too stupid to understand it.
> 
> Note, Turing Machines CAN be described at a high level, just like the 
> OS. And just like understanding the OS with high level code needs an 
> understanding of the lower level code, understanding the high level 
> descriptions of Turing Machines needs an understanding of the basic 
> operaiton of a Turing Machine.
> 
> Since you couldn't handle a Turing Machine of only a few states, that is 
> about like not being able to understand an assembly function of just a 
> small number of instructions.
> 
>>
>>>> For example no one ever even noticed that it is 100% impossible to
>>>> derive an input that actually does the opposite of whatever value that
>>>> its termination analyzer reports.
>>> Wrong, DDD calls HHH, which returns "non-halting", *and halts*.
>>>
>>
>> int DD()
>> {
>>    int Halt_Status = HHH(DD);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return Halt_Status;
>> }
>>
>> There is no possible way for DD emulated by HHH
>> according to the rules of the x86 language to
>> receive the return value from its call to HHH(DDD).
>> It has been this way for 90 years.
>>
> 
> 
> First, if that is ALL the input, HHH can't emulate past the call 
> instruction and be a pure function.
> 

Sure it can.

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