Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: The philosophy of computation reformulates existing ideas on a new basis
Date: Fri, 15 Nov 2024 12:29:13 +0200
Organization: -
Lines: 79
Message-ID: <vh77pp$3c6nu$1@dont-email.me>
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: 8bit
Injection-Date: Fri, 15 Nov 2024 11:29:14 +0100 (CET)
Injection-Info: dont-email.me; posting-host="89169c7db4a6c78cb6d4a91eecf4111f";
	logging-data="3545854"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+uTl6qxZmRrQ5DLjqcsOYg"
User-Agent: Unison/2.2
Cancel-Lock: sha1:KovTowm4DeON6cgn9ND38oHiYyg=
Bytes: 5018

On 2024-11-14 23:51:06 +0000, olcott said:

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

Only with a particular C complier with particular compiler specific
extensions. Another C compiler might compiler different C code.
In particular, C calls HHH which calls functions that cannot be
as strictly conforming C functions.

>>>>>> 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 can do so. And above you excluded C++ from discussion. It is indeed
true that terminations of Turing machines are not usually classified as
"normal" and "abnormal". More often they are classified as "accepting"
and "rejecting". The halting problem does not involve any classification
at all, only whether the program can be continued forever.

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

Not according to Wiktionary. Which dictionary says it does?

-- 
Mikko