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: Recursive simulation must be reported and not ignored.
Date: Sat, 10 May 2025 22:04:44 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <28a2e7aa80d2133ab34b11bd30b9073a46a59b13@i2pn2.org>
References: <BPOTP.66191$v0S.4884@fx14.ams4>
 <3bc01824e1d95a30b9784942a8b7ef3bc9ec8ff8@i2pn2.org>
 <UIRTP.228282$_Npd.219273@fx01.ams4> <vvosru$3ql7h$1@dont-email.me>
 <bc5cc7788c2f522f313339d699520118aba2b18c@i2pn2.org>
 <vvovmj$3r1ek$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 11 May 2025 02:06:57 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="4018899"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vvovmj$3r1ek$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5226
Lines: 108

On 5/10/25 9:49 PM, olcott wrote:
> On 5/10/2025 8:07 PM, Richard Damon wrote:
>> On 5/10/25 9:00 PM, olcott wrote:
>>> On 5/10/2025 6:56 PM, Mr Flibble wrote:
>>>> On Sat, 10 May 2025 18:40:53 -0400, Richard Damon wrote:
>>>>
>>>>> On 5/10/25 4:38 PM, Mr Flibble wrote:
>>>>>> How my refutation differs to Peter's:
>>>>>>
>>>>>> * Peter refutes the halting problem based on pathological input
>>>>>> manifesting in a simulating halt decider as infinite recursion, this
>>>>>> being treated as non-halting.
>>>>>> * Flibble refutes the halting problem based on patholgical input
>>>>>> manifesting as decider/input self-referencial conflation, 
>>>>>> resulting in
>>>>>> the contradiction at the heart of the halting problem being a 
>>>>>> category
>>>>>> (type) error, i.e. ill-formed.
>>>>>>
>>>>>> These two refutations are related but not exactly the same.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> And the problem is that you use incorrect categories.
>>>>>
>>>>> The decider needs to be of the category "Program".
>>>>>
>>>>> The input also needs to be of the category "Program", but provided 
>>>>> via a
>>>>> representation. The act of representation lets us convert items of
>>>>> category Program to the category of Finite String which can be an 
>>>>> input.
>>>>
>>>> Those two categories you have identified are different hence the 
>>>> category
>>>> error.
>>>>
>>>
>>> That is correct. A running program and an input finite
>>> string ARE NOT THE SAME.
>>
>> But there is a direct relationship between the two.
>>
> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> _DDD()
> [00002172] 55         push ebp      ; housekeeping
> [00002173] 8bec       mov  ebp,esp  ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404     add  esp,+04
> [00002182] 5d         pop  ebp
> [00002183] c3         ret
> Size in bytes:(0018) [00002183]
> 
> The key thing is that they don't always have the same
> behavior.

Sure they do, at least when defined so it has behavior.

Your DDD above isn't a program and thus can't be run or correctly 
emulated as the HHH isn't part of it. Even if there happens to be an HHH 
at that address, it can't be legally used by the program without 
becoming undefined behavior.

It only HAS behavior when it has been specifically and explicitly paired 
with a specific defintion of HHH and incorporates its full code into the 
algorithm of DDD.

This makes each different pairing a unique input, as they are all different.

> 
> When they do have different behavior the termination
> analyzer is only allowed to report on the recursive
> simulation behavior that its input specifies.

No, it needs to report on the ACTUAL behavior its input specifies, which 
is DEFINED to be the behavior of the direct execution of said program.


> 
> It is not allowed to ignore this on the basis that the
> direct execution or UTM simulation has no recursive
> simulation.
> 

What it isn't allowed to ignore is the ACTUAL DEFINED behavior of the 
ACTUAL INPUT it was given (which include what HHH it calls), the fact 
that various other versions of the input built on different version 
might do something else is irrelevent. Since the version of HHH that you 
claim gets the right answer DOES abort its emulation and returns 0, the 
only version of DDD that needs to be considered is the version paired 
with that exact same input, and the correct mapping of that program, as 
defined by the correct emulation of it, is to halt.

Note call instructions at the x86 level do not change their behavior 
just because at some other level the same call has been made, so yes, it 
MUST "ignore" the fact that the call might be recursive, as that fact 
has no impact at the assembly langugage level.

You seem to not understand the basic meanings of the words you are using.


This *IS* looking at the results of UTM(DD)