Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: DDD specifies recursive emulation to HHH and halting to HHH1
Date: Sun, 30 Mar 2025 21:35:57 -0500
Organization: A noiseless patient Spider
Lines: 132
Message-ID: <vscv2d$2ub5m$4@dont-email.me>
References: <vrfuob$256og$1@dont-email.me> <vs76m9$3m3q0$1@dont-email.me>
 <vs77th$2p360$11@dont-email.me> <vs78cu$3ms9k$1@dont-email.me>
 <c2b91231b9052e07b6705250938fb9095e711327@i2pn2.org>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 31 Mar 2025 04:35:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7c3e41e7cd06e5848bcc8c57c53d2c68";
	logging-data="3091638"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/zibcaObyQz2nuDWig/5Lx"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:w/A1hV/vJufhpaoNwgmwGo7qryg=
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250330-6, 3/30/2025), Outbound message
Content-Language: en-US
In-Reply-To: <8130009e4e9d8dffd81a4cb0f5f3338aa21177d3@i2pn2.org>
Bytes: 7270

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

>>
>> Those finite string transformations must be the actual
>> execution trace of DDD emulated by HHH according to
>> the semantics of the x86 language.
> 
> Nope, nothing in the problem says that.
> 

How else would it obtain a semantic property encoded
as a finite string?

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer