Re: The philosophy of computation reformulates existing ideas on a new basis

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