Path: news.eternal-september.org!eternal-september.org!news.eternal-september.org!feeder2.eternal-september.org!news.quux.org!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
Date: Thu, 14 Nov 2024 22:03:35 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <d3533f6f3454f9d0e5ed32f8495c1c4f5898f867@i2pn2.org>
References: <vfli1h$fj8s$1@dont-email.me> <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>
 <vgl0pf$37081$1@dont-email.me> <vgl7qo$37h38$3@dont-email.me>
 <vgnbfc$3uefk$1@paganini.bofh.team> <vgnt6e$3qq7s$4@dont-email.me>
 <vgsog6$uu8r$1@dont-email.me> <vgt71t$11e5a$4@dont-email.me>
 <vgvdp1$1iie3$1@dont-email.me> <vh0lpm$1qfts$1@dont-email.me>
 <vh20gm$25pto$1@dont-email.me> <vh3bho$2e37l$5@dont-email.me>
 <vh4ei3$2o1f0$1@dont-email.me> <vh62da$32617$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 15 Nov 2024 03:03:36 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2514699"; 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: <vh62da$32617$3@dont-email.me>

On 11/14/24 6:51 PM, olcott wrote:
> On 11/14/2024 3:06 AM, Mikko wrote:
>> On 2024-11-13 23:08:40 +0000, olcott said:
>>
>>> On 11/13/2024 4:54 AM, Mikko wrote:
>>>> On 2024-11-12 22:45:10 +0000, olcott said:
>>>>>
>>>>> Since we are only talking about Turing Machines and C functions
>>>>> there is no need to get into other models.
>>>>
>>>> You have also talked about x86, so it is better to include that.
>>>
>>> That is construed as the precise details of the behavior
>>> of the C function.
>>
>> Doing so deviates from the meaning of "C language".
>>
> 
> Not at all. x86 is the Tarski meta-language that
> specifies the precise fully concrete semantics
> of the C code.

Nope, the x86 language is NOT the "meta-language" that Tarski describes.

And the proper x86 implmentation of the C code needs the x86 
instructions that define HHH and everything it calls.

Your omittion of them invaldiates your claims.

> 
>>>>>> For a C program it is more ambiguous as there are situations
>>>>>> where the language standard does not specify whether the execution
>>>>>> should be terminated or continued.
>>>>>
>>>>> Reaching the "return" instruction final halt state <is>
>>>>> the only normal termination for a C function.
>>>>
>>>> You may call it "only normal termitaion" but there are other 
>>>> terminations
>>>> that need not be called "normal".
>>>
>>> When we preserve the mapping to Turing machines then
>>> reaching the return instruction is the only correct
>>> notion of a final halt state.
>>
>> No, it is not. If you want to use the expression "final halt state"
>> about Turing machines you must define it in terms of Turing macnine
>> concepts, either as halting or as someting else.
>>
> 
> We cannot refer to any feature in C++ that Turing Machines
> lack and maintain the mapping to Turing Machines. There
> is no such thing as abnormal termination in TMs.

You seem to confuse METHOD of processing with the RESULTS of processing.



> 
>>>>> If you want to get silly you can say that a C function stuck
>>>>> in an infinite loop "halts" when you yank the computer's power
>>>>> cord out.
>>>>
>>>> That is in the same category as the "aboting" your HHH may do with
>>>> certain inputs. The program does specify a next action but the
>>>> specified action is not performed.
>>>
>>> No it is not. A emulating termination analyzer is
>>> defined to abort as soon as aborting is the only way
>>> to prevent its own non-termination.
>>
>> If for a particular input aborting is the only way to prevent its own
>> non-termination then "as soon as" can only mean before doing anything
> 
> That is a ridiculously stupid way to look at it.
> <As soon as> means the point in the execution
> trace where the non-halt criteria it first met.

But it needs to be a CORRECT non-halting criteria, which yours isn't, as 
it has been shown that the HALTING program DDD seems to match your criteria.

FALSE premises lead to FALSE conclusiongs, an repeating them after being 
shown otherwise just shows you are nothing but a pathological liar.

> 
> For the current algorithm this is immediately after
> HHH emulates itself emulating DDD until its emulated
> HHH is about to emulated itself emulating DDD.

Which isn't correct, as that is based on the FALSE assumption that THIS 
HHH (that DDD calls) will never abort its emulation, but it will just 
like this one does.

So, all you are doing is showing you believe it is ok to LIE.

> 
>> and therefore before finding out that there is no other way.
>>
> 
> 
>