Deutsch   English   Français   Italiano  
<04def3c05242c3bfd2b2010509675214e9874696@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!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: The philosophy of computation reformulates existing ideas on a
 new basis --- INFALLIBLY CORRECT REASONING
Date: Fri, 8 Nov 2024 07:25:57 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <04def3c05242c3bfd2b2010509675214e9874696@i2pn2.org>
References: <vfli1h$fj8s$1@dont-email.me> <vfo95k$11qs1$1@dont-email.me>
 <vfp8c0$3tobi$2@i2pn2.org> <vfpcko$1837o$3@dont-email.me>
 <vfpish$3u885$2@i2pn2.org> <vfpjk2$1976k$1@dont-email.me>
 <086fc32f14bcc004466d3128b0fe585b27377399@i2pn2.org>
 <vfqsui$1jg6i$2@dont-email.me> <vft4om$44tc$2@i2pn2.org>
 <vft944$25aio$6@dont-email.me>
 <11408789ed30027f4bc9a743f353dfa9b4712109@i2pn2.org>
 <QU2dnTAfup30Rr_6nZ2dnZfqn_WdnZ2d@brightview.co.uk>
 <vfvnml$2ll12$1@dont-email.me> <vfvujg$2mcse$6@dont-email.me>
 <vg2cqm$37cq6$1@dont-email.me> <vg2kfq$38m0h$1@dont-email.me>
 <vg4va2$3ok87$1@dont-email.me> <vg55lv$3pnvp$1@dont-email.me>
 <vg7sdl$cbfk$1@dont-email.me> <vg83vt$dri5$1@dont-email.me>
 <vgcmu4$1eurt$1@dont-email.me> <vgd5vl$1hqli$1@dont-email.me>
 <vgfv31$25h28$1@dont-email.me> <vgg1qh$26126$1@dont-email.me>
 <vgi2t6$2js8i$1@dont-email.me> <vgiqgt$2nkqv$2@dont-email.me>
 <b9a0d5ce3b7042113a97b55efdc04186959cb401@i2pn2.org>
 <vgk20t$31qrg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 8 Nov 2024 12:25:57 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1516995"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vgk20t$31qrg$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 12745
Lines: 281

On 11/7/24 10:54 PM, olcott wrote:
> On 11/7/2024 9:10 PM, Richard Damon wrote:
>> On 11/7/24 11:39 AM, olcott wrote:
>>> On 11/7/2024 3:56 AM, Mikko wrote:
>>>> On 2024-11-06 15:26:06 +0000, olcott said:
>>>>
>>>>> On 11/6/2024 8:39 AM, Mikko wrote:
>>>>>> On 2024-11-05 13:18:43 +0000, olcott said:
>>>>>>
>>>>>>> On 11/5/2024 3:01 AM, Mikko wrote:
>>>>>>>> On 2024-11-03 15:13:56 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 11/3/2024 7:04 AM, Mikko wrote:
>>>>>>>>>> On 2024-11-02 12:24:29 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> HHH does compute the mapping from its input DDD
>>>>>>>>>>> to the actual behavior that DDD specifies and this
>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD.
>>>>>>>>>>
>>>>>>>>>> Yes but not the particular mapping required by the halting 
>>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> Yes it is the particular mapping required by the halting problem.
>>>>>>>>> The exact same process occurs in the Linz proof.
>>>>>>>>
>>>>>>>> The halting probelm requires that every halt decider terminates.
>>>>>>>> If HHH(DDD) terminates so does DDD. The halting problmen requires
>>>>>>>> that if DDD terminates then HHH(DDD) accepts as halting.
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>>    HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> No that is false.
>>>>>>> The measure is whether a C function can possibly
>>>>>>> reach its "return" instruction final state.
>>>>>>
>>>>>> Not in the original problem but the question whether a particular 
>>>>>> strictly
>>>>>> C function will ever reach its return instruction is equally hard. 
>>>>>> About
>>>>>
>>>>> It has always been about whether or not a finite string input
>>>>> specifies a computation that reaches its final state.
>>>>
>>>> Not really. The original problem was not a halting problem but Turing's
>>>
>>> Exactly. The actual Halting Problem was called that by Davis
>>> in 1952. Not the same as Turing proof.
>>>
>>> *So we are back to The Halting Problem itself*
>>>
>>> has always been about whether or not a finite string input
>>> specifies a computation that reaches its final state.
>>>
>>
>> No, it has always been about trying to make a computation that given a 
>> finite string representation of a program and input, decide if the 
>> program will halt on that input.
>>
> 
> It has never ever been about anything other than the actual
> behavior that this finite string specifies. You are not stupid
> or ignorant about this your knowledge and intelligence has
> seemed pretty good. What you and others are is indoctrinated.

But it always has been. From your favorite source, the Halting problem 
is stated as:

In computability theory, the halting problem is the problem of 
determining, from a description of an arbitrary computer program and an 
input, whether the program will finish running, or continue to run forever.


Note the behavior that is to decided on: "whether the program will 
finish running, or continue to run forever".

The description is just to point to the program.

The "behavior" of that string is what the program it represents does.

> 
>> It should be noted that the problem STARTS with a program, which gets 
>> represented with a finite string, 
> 
> No that it incorrect. It never starts with a program. A TM
> cannot handle another TM as its input. It starts with an
> encoding that has associated semantics.

Right, TM's can't take a TM as in input, but the "Halting Function" can.

Like most problems a TM solves, the "input" of the problem is converted 
and represented with a finite string, but the MEANING (i.e. the 
semantics) of that input is the thing we started with, in this case, is 
the program.

The "associated semantics" of the string given to HHH, is the PROGRAM 
DDD that it is supposed to represent.

Since yours doesn't, since it doesn't fully define the program, you just 
started with an error.

> 
>> and that string might be different for different deciders, as the 
>> problem doesn't define a specific encoding method.
>>
>> Your insistance that the problem starts with a finite-string just 
>> shows your ignorance.
>>
> 
> It is much dumber to think that a TM takes another actual
> TM as input. It is common knowledge that this is not the case.

And it is elementary knowledge (which seems to be beyond you) that the 
string given to it is just a representation of the program that it is 
supposed to try to determine the behavior of,



> 
>> Try to show a reliable source that defines it as the string is the 
>> DEFINITION of what is being asked about, as opposed to being a 
>> representation of the program being asked about.
>>
> 
> It is the semantics that the string specifies that is being
> asked about.

Which is the PROGRAM it represents, and the behavior of that is the 
behavior of the PROGRAM.

> 
>> Go ahead, TRY to do it.
>>
>>> DDD specifies a non-halting computation to HHH because
>>> DDD calls HHH in recursive simulation.
>>
>> No, because the HHH that DDD calls is programmed to break that 
>> recursive simulation, and thus make the results finite.
>>
> 
> Now you are back to stupidly saying that DDD emulated by
> HHH reaches its final halt state because it is aborted.
> You are not stupid (you are smart) and you are not ignorant.

No, it reaches its final halt state because it does. It does because you 
have shown that behavior of the unspecified HHH that it calls is to 
return, and thus

> 
> You know that DDD emulated by HHH cannot possibly reach
> its own final state (whether HHH ever aborts or not) and
> seem to believe that this is irrelevant.

The DDD, that HHH emulates, does reach the end. You are just too stupid 
to understand that.

The emulation of DDD by HHH doesn't make it there, but that doesn't 
demonstrate to property of "cannot posssibly reach ..." for the program 
========== REMAINDER OF ARTICLE TRUNCATED ==========