Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: The philosophy of computation reformulates existing ideas on a
 new basis ---
Date: Mon, 28 Oct 2024 22:56:17 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <vfpish$3u885$2@i2pn2.org>
References: <veoift$29dtl$2@dont-email.me> <veoq3j$2aqp2$1@dont-email.me>
 <vf716u$1607j$1@dont-email.me> <vf7ks8$1d1vt$1@dont-email.me>
 <vf8eu5$1h5mj$2@dont-email.me> <vfdk8g$2lgl1$1@dont-email.me>
 <vfdrb8$2mcdg$1@dont-email.me> <vffk1i$33iat$1@dont-email.me>
 <vfgaev$36im7$5@dont-email.me> <vfi743$3kr1e$1@dont-email.me>
 <vfip3l$3ner2$2@dont-email.me>
 <1bc1ab08ec47bf818ddff1d4f63b542ceadd6985@i2pn2.org>
 <vfjokd$3su2f$1@dont-email.me> <vfk3jl$3kr0c$5@i2pn2.org>
 <vfk4lk$3ukdm$1@dont-email.me> <vfl8o9$3mnmt$5@i2pn2.org>
 <vfli1h$fj8s$1@dont-email.me> <vflue8$3nvp8$2@i2pn2.org>
 <vfmd8m$k2m7$1@dont-email.me>
 <bcd82d9f8a987d3884220c0df7b8f7204cb9de3e@i2pn2.org>
 <vfmueh$mqn9$1@dont-email.me>
 <ff039b922cabbb6d44f90aa71a52d8c2f446b6ab@i2pn2.org>
 <vfo95k$11qs1$1@dont-email.me> <vfp8c0$3tobi$2@i2pn2.org>
 <vfpcko$1837o$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Oct 2024 02:56:17 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="4137221"; mail-complaints-to="usenet@i2pn2.org"
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vfpcko$1837o$3@dont-email.me>
Bytes: 10990
Lines: 233

On 10/28/24 9:09 PM, olcott wrote:
> On 10/28/2024 6:56 PM, Richard Damon wrote:
>> On 10/28/24 11:04 AM, olcott wrote:
>>> On 10/28/2024 6:16 AM, Richard Damon wrote:
>>>> On 10/27/24 10:55 PM, olcott wrote:
> 
>>>>> On 10/27/2024 9:26 PM, Richard Damon wrote:
>>>>>> On 10/27/24 6:01 PM, olcott wrote:
>>>>>>> On 10/27/2024 12:48 PM, Richard Damon wrote:
>>>>>>>> On 10/27/24 10:17 AM, olcott wrote:
>>>>>>>>> I am keeping this post in both sci.logic and comp.theory
>>>>>>>>> because it focuses on a similar idea to the Curry/Howard
>>>>>>>>> correspondence between formal systems and computation.
>>>>>>>>>
>>>>>>>>> Computation and all of the mathematical and logical operations
>>>>>>>>> of mathematical logic can be construed as finite string
>>>>>>>>> transformation rules applied to finite strings.
>>>>>>>>>
>>>>>>>>> The semantics associated with finite string tokens can
>>>>>>>>> be directly accessible to expression in the formal language.
>>>>>>>>> It is basically an enriched type hierarchy called a knowledge
>>>>>>>>> ontology.
>>>>>>>>>
>>>>>>>>> A computation can be construed as the tape input to a
>>>>>>>>> Turing machine and its tape output. All of the cases
>>>>>>>>> where the output was construed as a set of final machine
>>>>>>>>> states can be written to the tape.
>>>>>>>>>
>>>>>>>>> I am not sure but I think that this may broaden the scope
>>>>>>>>> of a computable function, or not.
>>>>>>>>
>>>>>>>> Except that nothing you described related to what a "computabe 
>>>>>>>> function" 
>>>>>>>
>>>>>>> I intend to reply to other aspects of your reply later
>>>>>>> on as long as your reply to this reply is not lame.
>>>>>>>
>>>>>>> When a Turing machine transforms the contents of its
>>>>>>> input tape into the contents of its output tape this
>>>>>>> seems to necessarily always be a computable function
>>>>>>> no matter what the TM does in-between.
>>>>>>>
>>>>>>
>>>>>> Yes, a Turing Machine will always be computing the mapping from 
>>>>>> some computable function.
>>>>>>
>>>>>> It is NOT the "Computable Function" itself, as that is a thing of 
>>>>>> a different ty[pe.
>>>>>>
>>>>>> It just computed the mapping definied by that function.
>>>>>>
>>>>>> Note, the mapping of the function might not be defined in terms of 
>>>>>> "finite-strings", but will be something that can be described by a 
>>>>>> finite string if we want to talk about it being computable.
>>>>>>
>>>>>
>>>>> Yes. We are getting somewhere now.
>>>>>
>>>>>> For instance, the Halting Function, that the Halting problem is 
>>>>>> about, is defined with Turing Machines as its input (not finite 
>>>>>> strings).
>>>>>>
>>>>>
>>>>> Not in the least little bit.
>>>>> It seems totally crazy that you would say this.
>>>>
>>>>
>>>>>
>>>>> It has always been finite string Turing Machine descriptions.
>>>>
>>>> The machine being used to compute the Halting Function has taken a 
>>>> finite string description, the Halting Function itself always took a 
>>>> Turing Machine,
>>>>
>>>
>>> That is incorrect. It has always been the finite string Turing Machine
>>> description of a Turing machine is the input to the halt decider.
>>> There are always been a distinction between the abstraction and the
>>> encoding.
>>
>> Nope, read the problem you have quoted in the past.
>>
>> The FUNCTION is the Halting Function, which is about Turing Machines,
>>
>> The decider is what takes a finite string, and that string is 
>> described as a representation of the Turing Machine the Halting 
>> Function mapped.
>>
>> It CAN'T be about the string, as every decider might take a different 
>> form of encoding.
>>
>> So yes, the TURING MACH(INE DECIDER takes a string, but the HALTING 
>> FUNCTION takes a Turing Machine and its input.
>>
>> Your problem is you don't understand what Computation Theory calls a 
>> "Function", and have guessed wrong.
>>
>>
>>>
>>>>> These finite strings do have a specific semantics associated
>>>>> with them and that is the semantics of Turing Machines.
>>>>
>>>> No, the method of representing the Turing Machine is defined by the 
>>>> decider.
>>>>
>>>> The "Semantics of Turing Machines" does have a finite string 
>>>> representation.
>>>
>>> It may seem that way because there is no currently universal standard
>>> like there is for the x86 language. For these thing to be properly
>>> investigated we must begin with a standard language. The machine
>>> merely conforms to that standard.
>>
>> Nope, doesn't work that way, The is no rule that says the decider 
>> needs to uuse any particular form of encoding, and thus the Function 
>> that defines the mapping can't be based on one.
>>
>> You are just proving your stupidity,
>>
>>>
>>>>
>>>> It defines a Turing Machine as having a "Set of States" (and 
>>>> "States" don't have a defined string representation
>>>>
>>>
>>>   A turing machine program consists of a list of 'quintuples', each 
>>> one of which is a five-symbol turing machine instruction.  For 
>>> example, the quintuple 'SCcsm' is executed by the machine if it is in 
>>> state 'S' and is reading the symbol 'C' on the tape.  In that case, 
>>> the instruction causes the machine to make a transition to state 's' 
>>> and to overwrite the symbol 'C' on the tape with the symbol 'c'.  The 
>>> last operation it performs under this instruction is to move the tape 
>>> reading head one symbol to the left or right according to whether 'm' 
>>> is 'l' or 'r'.
>>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>
>> And none of those have a defined finite-string encoding. Since you 
>> can't even know what the symbol set to encode into, that becomes a lot 
>> harder to define.
>>
>> And, if you did limit it
>>
>>>
>>> SCcsm
>>> current state number,
>>> current symbol,
>>> overwrite current symbol
>>> next state number,
>>> move tape head left or right
>>
>> And how do you encode that into an arbitrary symbol set.
>>
>> And, does it HAVE to be organized that way, NO.
>>
>> If you limited it to that, you would only prove that you can't solve 
>> the problem with that particular encoding, which isn't good enougy to 
>> answer the question about computablility.
>>
>> Which you are just showing you just don't undetstand.
>>
>>>
>>>>>
>>>>>> The key point here is that different implementation of a attempted 
>>>>>> Turing Machines to try to compute this might use different ways of 
========== REMAINDER OF ARTICLE TRUNCATED ==========