Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Tue, 13 May 2025 13:20:58 +0200
Organization: A noiseless patient Spider
Lines: 99
Message-ID: <vvv9uq$1ov7e$5@dont-email.me>
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: Tue, 13 May 2025 13:20:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f93063a85412bb9b83b70aeb6dff6a7";
	logging-data="1866990"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19NhpH0e4Yfs7M6hN9DA2s7"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:U60jjTf/eh73HSkDftfhQLYIkIs=
In-Reply-To: <vvqjnf$gldn$11@dont-email.me>
Content-Language: nl, en-GB
Bytes: 6244

Op 11.mei.2025 om 18:37 schreef olcott:
> 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.
> 
>>> 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.
> 

And we all expected this failure of HHH. It is a big support for the 
halting theorem.