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: DDD specifies recursive emulation to HHH and halting to HHH1
Date: Mon, 31 Mar 2025 18:42:37 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <8c3723a1d8338265d13cc174f41e9d728165172b@i2pn2.org>
References: <vrfuob$256og$1@dont-email.me> <vs7kvf$3eal$2@dont-email.me>
 <aeb75b411e9f77c974585181c671a47d03b22078@i2pn2.org>
 <vs7qdm$8dae$2@dont-email.me> <vs7r9b$8ajp$1@dont-email.me>
 <vs92l3$1fccq$5@dont-email.me> <vs93ae$1k9u2$1@dont-email.me>
 <vs9g5p$1v2n9$5@dont-email.me> <vs9gcg$20g2j$3@dont-email.me>
 <vs9h9o$23cav$2@dont-email.me> <vs9hh3$20g2j$6@dont-email.me>
 <vs9jie$23cav$4@dont-email.me> <vs9kb1$26cg5$2@dont-email.me>
 <vs9pni$27rl4$9@dont-email.me>
 <3ade9e84224ba9b99c7363e0e9b69181804b7daa@i2pn2.org>
 <vsc2fd$1vihj$2@dont-email.me>
 <e1da7d564873d36f88e119fbbbdafd8c6b0f675e@i2pn2.org>
 <vsc9o7$2bk3d$2@dont-email.me>
 <e8a1a71c83ab391210359dec64ecf493433c813c@i2pn2.org>
 <vsceml$2fv3s$3@dont-email.me> <p9jGP.1145983$nb1.941724@fx01.ams4>
 <vscftc$2fv3s$4@dont-email.me>
 <8130009e4e9d8dffd81a4cb0f5f3338aa21177d3@i2pn2.org>
 <vscv2d$2ub5m$4@dont-email.me>
 <5f207c23d9de993a123307f120bd45af6c474415@i2pn2.org>
 <vseo24$th5g$9@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 31 Mar 2025 22:52:31 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2597814"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vseo24$th5g$9@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 8607
Lines: 165

On 3/31/25 2:48 PM, olcott wrote:
> On 3/31/2025 6:15 AM, Richard Damon wrote:
>> On 3/30/25 10:35 PM, olcott wrote:
>>> On 3/30/2025 7:40 PM, Richard Damon wrote:
>>>> On 3/30/25 6:17 PM, olcott wrote:
>>>>> On 3/30/2025 4:59 PM, Mr Flibble wrote:
>>>>>> On Sun, 30 Mar 2025 16:56:37 -0500, olcott wrote:
>>>>>>
>>>>>>> On 3/30/2025 4:05 PM, Richard Damon wrote:
>>>>>>>> On 3/30/25 4:32 PM, olcott wrote:
>>>>>>>>> On 3/30/2025 1:52 PM, Richard Damon wrote:
>>>>>>>>>> On 3/30/25 2:27 PM, olcott wrote:
>>>>>>>>>>> On 3/30/2025 3:12 AM, joes wrote:
>>>>>>>>>>>> Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
>>>>>>>>>>>>> On 3/29/2025 3:14 PM, dbush wrote:
>>>>>>>>>>>>>> On 3/29/2025 4:01 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can know that when this adapted UTM simulates a finite 
>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>> of steps of its input that this finite number of steps were
>>>>>>>>>>>>>>> simulated correctly.
>>>>>>>>>>>>>> And therefore does not do a correct UTM simulation that 
>>>>>>>>>>>>>> matches
>>>>>>>>>>>>>> the behavior of the direct execution as it is incomplete.
>>>>>>>>>>>>> It is dishonest to expect non-terminating inputs to complete.
>>>>>>>>>>>> A complete simulation of a nonterminating input doesn't halt.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2) changing the input is not allowed
>>>>>>>>>>>>>>> The input is unchanged. There never was any indication 
>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>> input was in any way changed.
>>>>>>>>>>>>>> False, if the starting function calls UTM and UTM changes, 
>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>> changing the input.
>>>>>>>>>>>>> When UTM1 is a UTM that has been adapted to only simulate a 
>>>>>>>>>>>>> finite
>>>>>>>>>>>>> number of steps
>>>>>>>>>>>> So not an UTM.
>>>>>>>>>>>>
>>>>>>>>>>>>> and input D calls UTM1 then the behavior of D simulated by 
>>>>>>>>>>>>> UTM1
>>>>>>>>>>>>> never reaches its final halt state.
>>>>>>>>>>>>> When D is simulated by ordinary UTM2 that D does not call 
>>>>>>>>>>>>> Then D
>>>>>>>>>>>>> reaches its final halt state.
>>>>>>>>>>>> Doesn't matter if it calls it, but if the UTM halts.
>>>>>>>>>>>>
>>>>>>>>>>>>>> Changing the input is not allowed.
>>>>>>>>>>>>> I never changed the input. D always calls UTM1.
>>>>>>>>>>>>> thus is the same input to UTM1 as it is to UTM2.
>>>>>>>>>>>> You changed UTM1, which is part of the input D.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> UTM1 simulates D that calls UTM1 simulated D NEVER reaches final
>>>>>>>>>>> halt state
>>>>>>>>>>>
>>>>>>>>>>> UTM2 simulates D that calls UTM1 simulated D ALWAYS reaches 
>>>>>>>>>>> final
>>>>>>>>>>> halt state
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Only because UTM1 isn't actually a UTM, but a LIE since it 
>>>>>>>>>> only does
>>>>>>>>>> a partial simulation, not a complete as REQURIED by the 
>>>>>>>>>> definition of
>>>>>>>>>> a UTM.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _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]
>>>>>>>>>
>>>>>>>>> DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH 
>>>>>>>>> ITS OWN
>>>>>>>>> FINAL HALT STATE.
>>>>>>>>>
>>>>>>>>> THAT IS WHAT IT SAYS AND ANYONE THAT DISAGREES IS A DAMNED LIAR OR
>>>>>>>>> STUPID.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> How is that DDD correctly emulated beyond the call HHH 
>>>>>>>> instruction by a
>>>>>>>> program that is a pure function, and thus only looks at its input?
>>>>>>>>
>>>>>>>>
>>>>>>> *THE ENTIRE SCOPE IS*
>>>>>>> DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH 
>>>>>>> ITS OWN
>>>>>>> FINAL HALT STATE.
>>>>>>>
>>>>>>> If HHH determines this entirely from a psychotic break from 
>>>>>>> reality the
>>>>>>> above sentence remains immutably true.
>>>>>>
>>>>>> Will this ever stop?  It is kind of depressing to watch.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> I will stop bringing up this point and move
>>>>> on to the next point when the three years of
>>>>> consistent stonewalling on this point stops.
>>>>
>>>> The problem is you are admitting that you are using a strawman, so 
>>>> it is YOU that is stonewalling.
>>>>
>>>>>
>>>>> When HHH computes the mapping from its finite string
>>>>> input to its own reject state it must do this by
>>>>> applying finite string transformations to this input
>>>>> to derive its output.
>>>>
>>>> No, it only CAN do that, but to be correct, it needs to compute the 
>>>> needed function, which has no requirement to be based on that sort 
>>>> of criteria.
>>>>
>>>
>>> At least Rice knows that deciders must recognize semantic
>>> properties encoded as finite strings.
>>>
>>> In computability theory, Rice's theorem states that
>>> all non-trivial semantic properties of programs are
>>> undecidable. A semantic property is one about the
>>> program's behavior
>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>
>>
>> Right, and Rice's definition says it is the behavior of the PROGRAM 
>> described to the decider. Not what the decider can figure out about 
>> it, but the actual behavior of the program.
>>
> 
> The actual behavior as a semantic property of the finite string input.
> int sum (int x, int y) { return x + y; }
> sum(2,3) cannot possibly figure out the sum of 5+3.

The program "sum" can, with the other input.

> 
> It is foolish to require a decider to report on
> anything that it cannot not see.

Why do you say that? Aren't most of our tests about things we can not 
directly see at the moment (unless it is testing our eyes).

> 
> It is ALWAYS CORRECT for any simulating termination
> analyzer to stop simulating and reject any input
> that would otherwise prevent its own termination.
>

And since DDD doesn't, as shown by HHH1, it wasn't correct for HHH to do 
the abort that it did.

Of course, the DIFFERENT input of a DDD built on an HHH that doesn't 
abort would create the opposite case, it would have been correct for HHH 
to have aborted the emulation that it never aborted.
========== REMAINDER OF ARTICLE TRUNCATED ==========