Deutsch   English   Français   Italiano  
<vgl94s$37h38$6@dont-email.me>

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

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 --- INFALLIBLY CORRECT REASONING
Date: Fri, 8 Nov 2024 09:01:47 -0600
Organization: A noiseless patient Spider
Lines: 155
Message-ID: <vgl94s$37h38$6@dont-email.me>
References: <vfli1h$fj8s$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>
 <1746d80da6dfbe1bfd1bc39811b92bb12be1a81c@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 08 Nov 2024 16:01:48 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c2fa6bf0e4c95fa4383978e96b35b7f1";
	logging-data="3392616"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QSRWnOlrIy7Y1oe5UHyaU"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:v4RNVnvDqUpd7XWwW80RoPHLzOI=
X-Antivirus: Norton (VPS 241108-6, 11/8/2024), Outbound message
X-Antivirus-Status: Clean
Content-Language: en-US
In-Reply-To: <1746d80da6dfbe1bfd1bc39811b92bb12be1a81c@i2pn2.org>
Bytes: 8822

On 11/8/2024 4:54 AM, joes wrote:
> Am Thu, 07 Nov 2024 21:54:05 -0600 schrieb olcott:
>> 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.
>>>>>>>> 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.
>>>>>> 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.
>>>> 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.
>>
>>> 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.

> Silly distinction that buys you nothing.
> 
It has always only been about the behavior that the
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT Specifies.

NON-INPUTS HAVE ALWAYS BEEN OFF THE TABLE.
NON-INPUTS HAVE ALWAYS BEEN OFF THE TABLE.
NON-INPUTS HAVE ALWAYS BEEN OFF THE TABLE.
NON-INPUTS HAVE ALWAYS BEEN OFF THE TABLE.

>>> 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.
> It is common knowledge that nobody is giving actual(?) TMs as input.
> 
>>> 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.
> 
>>>> 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 confusing your simulation levels here.
> Not because itself is aborted, but because the HHH that it calls aborts.
> 

DDD emulated by HHH never reaches its own
final state EVEN IF GOD COMMANDS IT!!!
If God commands it then God is INCORRECT.

>> 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.
> When HHH aborts, it halts and returns.
> 

int main()
{
   HHH(DDD); // When HHH aborts its emulated DDD
             // this emulated DDD does not return

   DDD();    // When DDD calls HHH(DDD)
             // this emulated DDD never returns
}

>>> If you change HHH to not abort, then DDD does become non-halting, but
>> The infinite set of each HHH that emulates DDD (that aborts at some
>> point or not) is not above your educational or intellectual capacity.
> The selfreference of HHH seems to be above your intellectual capacity.
> 
>>> HHH doesn't give the right answer. That is a DIFFERENT HHH, and thus a
>>> DIFFERENT DDD (as DDD to be a program includes ALL the code it uses, so
>>> it includes the code of HHH, which you changed)
>> *We are not even talking about HHH giving the right answer yet*
>> (a) DDD emulated by every HHH that aborts at some point
>>       or not never reaches its final state.
> You mean, if DDD called a fixed simulator that didn’t change along with
> the one simulating DDD.
> 

For N = 0 to  ∞
each instance of HHH that emulate DDD N number of times
DDD fails to reach its final state and halts.

>> (b) This means that the right answer would be that DDD emulated
>>       by HHH does not halt.
> This means that HHH aborts, halts and returns "DDD doesn’t halt". Then
> DDD, which calls HHH, also halts, making HHH wrong.
> 

DDD emulated by HHH never halts as a matter of actual fact.
The directly executed DDD does halt conclusively proves
that it is not the same instance of DDD.

Termination analyzers report on the behavior that their
input specifies. They never have been allowed to report
on anything else.

>> (c) If HHH rejects DDD as non halting then HHH is correct.
>> (d) Can any HHH compute the mapping from its input DDD to
>>       the actual behavior that DDD specifies as a pure function of its
>>       inputs *IS THE ONLY ACTUAL REMAINING UNRESOLVED ISSUE*
> Where’s the problem?
> 


-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer