Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!panix!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Turing Computations <are> finite string transformations of inputs
Date: Sat, 26 Apr 2025 07:07:43 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <d1fe682cde3076734b8fcf5a97b281a4c2c14ae0@i2pn2.org>
References: <vu6lnf$39fls$2@dont-email.me> <vua9oi$2lub6$1@dont-email.me>
 <vudkah$1ona3$1@dont-email.me> <vufi61$3k099$1@dont-email.me>
 <vugddv$b21g$2@dont-email.me> <vuh2a3$tkor$1@dont-email.me>
 <vuhjsk$1h0ma$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 26 Apr 2025 11:12:16 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1960198"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vuhjsk$1h0ma$1@dont-email.me>

On 4/25/25 11:28 PM, olcott wrote:
> On 4/25/2025 5:28 PM, André G. Isaak wrote:
>> On 2025-04-25 10:31, olcott wrote:
>>
>>> Once we understand that Turing computable functions are only
>>> allowed to derived their outputs by applying finite string
>>> operations to their inputs then my claim about the behavior
>>> of DD that HHH must report on is completely proven.
>>
>> You're very confused here.
>>
>> Computable functions are *functions*. That is, they are mappings from 
>> a domain to a codomain, neither of which are required to be strings. 
>> Functions don't involve finite string operations at all.
>>
> 
> All Turing Machine based computation applies the
> finite string transformations specified by the TM
> language to the input finite string.

But you are missing that not all Functions are Turing Machine 
Compuations, and don't need to be mappings of "Finite Strings" to 
"Finite Strings". And we often ask Turing Machines to try to compute the 
mapping of such a function, with the added concept of a representation.

For instance, math "functions" are not based on Finite Strings, because 
Numbers themselves are not a Finite String, but can be represented by them.

> 
>> What distinguishes a computable function from other functions is that 
>> it is possible to implement an algorithm which computes that function. 
>> That algorithm might involve string operations, but the algorithm is 
>> not the function anymore than the function is the algorithm.
>>
>> The halting *function* is a mapping from the set of computations (not 
>> strings) to the set of boolean values (also not strings). A given 
>> computation maps to true if and only if it is finite.
>>
> 
> Ultimately every semantic meaning that can be expressed in
> language can be encoded as some type of relation between
> finite strings.
> 
>  From a set of basic facts all knowledge that can be expressed
> in language can be derived. It is derived through semantic
> logical entailment as the ONLY rule of inference.

Illrelevent to the point in question, and a claim you need to prove. IT 
would seem that trying to limit your logical operator when to just 
semantic logical entailment, when the field you are trying to represent 
uses more operators

> 
>> A halt *decider* (were such a thing possible) would be an algorithm 
>> which computes the halting function. Such an algorithm (assuming we're 
>> talking in terms of Turing Machines) would have to encode the elements 
>> of the halting function's domain as strings, but the mapping it computes 
> 
> 
>> would still be from the computations which those strings represent to 
>> their associated boolean values.
>>
>> André
>>
> 
> It is an easily verified fact that when HHH applies
> the finite string transformations specified by the
> x86 language to its input DD that for each HHH/DD
> pair no emulated DD can possibly reach its final
> halt state.
> 

But the fact that HHH's transformation doesn't reach the end doesn't 
mean that the correct and complete set of transformations defined by 
processor won't get there.

>   _DD()
> [00002133] 55         push ebp      ; housekeeping
> [00002134] 8bec       mov ebp,esp   ; housekeeping
> [00002136] 51         push ecx      ; make space for local
> [00002137] 6833210000 push 00002133 ; push DD
> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
> [00002141] 83c404     add esp,+04
> [00002144] 8945fc     mov [ebp-04],eax
> [00002147] 837dfc00   cmp dword [ebp-04],+00
> [0000214b] 7402       jz 0000214f
> [0000214d] ebfe       jmp 0000214d
> [0000214f] 8b45fc     mov eax,[ebp-04]
> [00002152] 8be5       mov esp,ebp
> [00002154] 5d         pop ebp
> [00002155] c3         ret
> Size in bytes:(0035) [00002155]
>

And the above is not a "program" as it uses and undefined term, HHH, so 
it doesn't have behavior.

When you add your Halt7 as you stipulate, then you claim about "No 
HHH/DD pair" is somewhat meaningless, as there is only one possible 
HHH/DD pair, as HHH has be fully defined by your stipulations,

IF you try to make Halt7 now a variable, included implicitly as part of 
the input, the  each pair becomes a totally new input, and all you have 
done is proven that all your possible machines fail to get to the end of 
their particular input, but we can still corrcctly and complete emulate 
every input from an HHH/DD pair that returns the answer 0 to see that 
its DD does halt, and thus it was just wrong.

All you are doing is proving that you have fundamental misunderstandings 
of the topics you are talking about, and are too stupid and ignorant to 
see those errors.