Path: ...!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sun, 11 May 2025 16:36:02 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <f8d15f9ec3c4edd0dbc59f27b4c60c7d759d5a58@i2pn2.org>
References: <vv97ft$3fg66$1@dont-email.me> <vvjotc$28g5i$12@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 11 May 2025 21:03:37 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="4130655"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vvqjnf$gldn$11@dont-email.me>
Content-Language: en-US
Bytes: 7752
Lines: 134

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.

If it isn't a pure function, then my static local hack lets it do the 
emulation.

So, the input DD needs to be defined to include the code of HHH that it 
calls as part of its definition, and for you system, that must be the
same as the decider.

Yes, with tha fix there is also no possible way for a HHH that emulates 
its input by that rule to be a decider and give an answer.

Once you make your HHH give up to answer, it fails to meet your initial 
requrement, and it is looking at a different input then the correctly 
emulating HHH, so we can't use its answer, as it is a different input.

It turns out that the correct simulation of the input DD for a DD built 
on an HHH that answer 0 for HHH(DD) will reach the final state, the fact 
that the only partial emulation by HHH didn't do that is irrelevent, and 
the fact that the DIFFERENT DD