Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: The philosophy of computation reformulates existing ideas on a
 new basis ---
Date: Mon, 28 Oct 2024 20:09:44 -0500
Organization: A noiseless patient Spider
Lines: 206
Message-ID: <vfpcko$1837o$3@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Oct 2024 02:09:45 +0100 (CET)
Injection-Info: dont-email.me; posting-host="393123f3287a9aeded778d1158c0bfd1";
	logging-data="1314040"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19SGl6RvHgQx3nc0lu77fVI"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:BXArhWUCEI5BrMGWikAr4PiQIF0=
In-Reply-To: <vfp8c0$3tobi$2@i2pn2.org>
X-Antivirus: Norton (VPS 241028-6, 10/28/2024), Outbound message
X-Antivirus-Status: Clean
Content-Language: en-US
Bytes: 9676

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 ==========