Path: news.eternal-september.org!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: Turing Machine computable functions apply finite string
 transformations to inputs VERIFIED FACT
Date: Tue, 29 Apr 2025 07:45:50 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <7dbf143996623a52d97f71d4e593dd70245e0064@i2pn2.org>
References: <vu6lnf$39fls$2@dont-email.me> <vudkah$1ona3$1@dont-email.me>
 <vufi61$3k099$1@dont-email.me> <vugddv$b21g$2@dont-email.me>
 <0a2eeee6cb4b6a737f6391c963386745a09c8a01@i2pn2.org>
 <vugvr3$pke9$8@dont-email.me>
 <4818688e0354f32267e3a5f3c60846ae7956bed2@i2pn2.org>
 <vuj18i$2lf64$6@dont-email.me>
 <f0d3f2e87d9a4e0b0f445f60a33d529f41a4fcf7@i2pn2.org>
 <vuj55m$2lf64$10@dont-email.me> <vuj8h3$2uahf$3@dont-email.me>
 <vujfuu$35hcg$1@dont-email.me>
 <65dddfad4c862e6593392eaf27876759b1ed0e69@i2pn2.org>
 <vujlj0$3a526$1@dont-email.me> <vujln7$32om9$8@dont-email.me>
 <vujmmm$3a526$2@dont-email.me> <vujmrj$32om9$9@dont-email.me>
 <vujtcb$3gsgr$1@dont-email.me> <vuju44$3hnda$1@dont-email.me>
 <vuk47o$3qkbb$1@dont-email.me> <vuk6b6$3l184$1@dont-email.me>
 <vuls34$1bf1j$4@dont-email.me> <vun87k$2m24h$2@dont-email.me>
 <vunb06$2fjjl$5@dont-email.me> <vuo57j$3h5l9$2@dont-email.me>
 <vuoath$3ljma$1@dont-email.me> <vuohgi$3td7u$1@dont-email.me>
 <vuonh6$2g74$2@dont-email.me> <vupeor$qf60$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 29 Apr 2025 11:55:48 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2388319"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <vupeor$qf60$1@dont-email.me>

On 4/28/25 10:50 PM, olcott wrote:
> On 4/28/2025 3:13 PM, Richard Heathfield wrote:
>> On 28/04/2025 19:30, olcott wrote:
>>> On 4/28/2025 11:38 AM, Richard Heathfield wrote:
>>>> On 28/04/2025 16:01, olcott wrote:
>>>>> On 4/28/2025 2:33 AM, Richard Heathfield wrote:
>>>>>> On 28/04/2025 07:46, Fred. Zwarts wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>> So we agree that no algorithm exists that can determine for all 
>>>>>>> possible inputs whether the input specifies a program that 
>>>>>>> (according to the semantics of the machine language) halts when 
>>>>>>> directly executed.
>>>>>>> Correct?
>>>>>>
>>>>>> Correct. We can, however, construct such an algorithm just as long 
>>>>>> as we can ignore any input we don't like the look of.
>>>>>>
>>>>>
>>>>> The behavior of the direct execution of DD cannot be derived
>>>>> by applying the finite string transformation rules specified
>>>>> by the x86 language to the input to HHH(DD). This proves that
>>>>> this is the wrong behavior to measure.
>>>>>
>>>>> It is the behavior THAT IS derived by applying the finite
>>>>> string transformation rules specified by the x86 language
>>>>> to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
>>>>
>>>> The x86 language is neither here nor there. 
>>>
>>> Computable functions are the formalized analogue
>>> of the intuitive notion of algorithms, in the sense
>>> that a function is computable if there exists an
>>> algorithm that can do the job of the function, i.e.
>>> *given an input of the function domain it*
>>> *can return the corresponding output*
>>> https://en.wikipedia.org/wiki/Computable_function
>>>
>>> *Outputs must correspond to inputs*
>>>
>>> *This stipulates how outputs must be derived*
>>> Every Turing Machine computable function is
>>> only allowed to derive outputs by applying
>>> finite string transformation rules to its inputs.
>>
>> In your reply to my article, you forgot to address what I actually 
>> wrote. I'm not sure you understand what 'reply' means.
>>
>> Still, I'm prepared to give you another crack at it. Here's what I 
>> wrote before:
>>
>> What matters is whether a TM can be constructed that can accept an 
>> arbitrary TM tape P and an arbitrary input tape D and correctly 
>> calculate whether, given D as input, P would halt. Turing proved that 
>> such a TM cannot be constructed.
>>
>> This is what we call the Halting Problem.
>>
> 
> Yet it is H(P,D) and NOT P(D) that must be measured.
> Computer science has been wrong about this all of
> these years. When I provide the 100% concrete example
> of the x86 language there is zero vagueness to slip
> through the cracks of understanding.

No, the question to H is the behavior of P(D).

Your strawman just shows you don't know what you are talking about.

Asking H about H(P,D) is just a stupid subjective question.

> 
> Even calling the Turing Machine language the Turing
> Machine description language make this confusing.

No, the fact you don't understand it shows you are stupid.

> 
> *This is a verified fact*
> When DD is emulated by HHH according to the finite
> string transformation rules of the x86 language
> DD cannot possibly reach its own final state no
> matter what HHH does.

But since HHH DOESN'T correctly emulated DD, it just shows you are a 
stupid liar.

> 
> 
>> Whatever you think you've proved, you haven't solved the Halting 
>> Problem. There are *no* solutions. We know this because there is a 
>> simple well-known proof. So the only way to devise a solution is to 
>> re- define the problem.
>>
> 
> It ultimately is only a confused view because key
> details about how outputs are made to conform to
> inputs:
> 
> Turing machines apply finite string transformations
> to finite string inputs.

Right, that is how they produce there aswers, not how the correct answer 
is determined.

You are just showing you don't understand the meaning of being correct, 
since you never are.

> 
>> And that's fine. If that's what floats your boat, you can re-define it 
>> as much as you like. But any proofs you may devise apply not to the 
>> Halting Problem but to the Olcott problem.
>>
>>
> 
> You aren't paying enough attention because you
> are too sure that I am wrong. I proved my point
> above.
> 
No, YOU are the one that is wrong, and too stupid to understand it.