| Deutsch English Français Italiano |
|
<46e0e3feda3d1eb14d32fe71c831a58dac491de1@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
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:49:26 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <46e0e3feda3d1eb14d32fe71c831a58dac491de1@i2pn2.org>
References: <vrfuob$256og$1@dont-email.me> <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>
<37611dde484778110d639014703daac38129f076@i2pn2.org>
<vsctva$2ub5m$3@dont-email.me>
<7ec2e83bc35a92bb7c5f7c9c7a9aa333da125931@i2pn2.org>
<vsd1ec$379dn$2@dont-email.me>
<821091edcf00ce1af435e2baf91b3ec94757aa1a@i2pn2.org>
<vseon7$th5g$10@dont-email.me>
<af131d4bcf224fb62a37e80fcce2c9cb18787e4f@i2pn2.org>
<vsf3pp$1crun$1@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:33 -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
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vsf3pp$1crun$1@dont-email.me>
Bytes: 6645
Lines: 105
On 3/31/25 6:08 PM, olcott wrote:
> On 3/31/2025 3:30 PM, joes wrote:
>> Am Mon, 31 Mar 2025 13:59:52 -0500 schrieb olcott:
>>> On 3/31/2025 6:19 AM, Richard Damon wrote:
>>>> On 3/30/25 11:16 PM, olcott wrote:
>>>>> On 3/30/2025 9:40 PM, Richard Damon wrote:
>>>>>> On 3/30/25 10:17 PM, olcott wrote:
>>>>>>> On 3/30/2025 7:35 PM, Richard Damon wrote:
>>>>>>>> On 3/30/25 5:56 PM, 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:
>>
>>
>>>>>>>>>>>>>>> It is dishonest to expect non-terminating inputs to
>>>>>>>>>>>>>>> complete.
>>>>>>>>>>>>>> A complete simulation of a nonterminating input doesn't halt.
>> You missed something here.
>>
>>>>>>>>>>>>>>> When UTM1 is a UTM that has been adapted to only simulate a
>>>>>>>>>>>>>>> finite number of steps
>>>>>>>>>>>>>> So not an UTM.
>> And here.
>>
>>>>>>>>>>>>>>> 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.
>>
>>>>>>>>>>>>>>> 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 EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH
>>>>>>>>>>> ITS OWN FINAL HALT STATE.
>> Only if HHH is not a decider.
>>
>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> From where? Remember, the Halting problem is SPECIFICALLY
>>>>>>>
>>>>>>> OFF F-CKING TOPIC. WE ABOUT ONE F-CKING STEP OF MY PROOF.
>>>>>>> WE HAVE BEEN TALKING ABOUT ONE F-CKING STEP OF MY PROOF FOR THREE
>>>>>>> F-CKING YEARS.
>> You have, only you. We asked your for other steps.
>>
>>>>>>> DDD correctly emulated by HHH DOES NOT F-CKING HALT !!!
>>>>>>>
>>>>>> Your proof is just off topic ranting.
>>>>>> The problem is that DDD is NOT correctly emulated by HHH,
>>>>>
>>>>> You are a damned liar when you try to get away with implying that HHH
>>>>> does not emulate itself emulating DDD in recursive emulation according
>>>>> to the semantics of the x86 language.
>>>>>
>>>> Of course it doesn't CORRECTLY emulate itself emulating DDD (and
>>>> omitting that CORRECTLY is a key point to your fraud), as it stops part
>>>> way, and CORRECT emulation that determines behavior doesn't stop until
>>>> the end is reached.
>>>
>>> It is ALWAYS CORRECT for any simulating termination analyzer to stop
>>> simulating and reject any input that would otherwise prevent its own
>>> termination.
>> Not correct is returning the wrong value. It should just say "I can't
>> simulate it, but it halts". I don't care about a supposed simulator
>> that does not say anything about the direct execution.
>>
>
> int sum(int x, int y) { return x + y; }
> The property of the input sum(3,2) is 5.
> We can incorrectly expect sum(2,3) to return 7.
>
> Halting is a semantic property of an input
> it is never any property of any non-input.
>
And the input is a representation of a program, and the semantic
property of that input is the behavior of the direct execution of that
program.
If you want to call that a "non-input", then you didn't do your
representation correctly, as the behavior of the direct execution should
be fully defined by the representation, since it should fully describe
the full algorithm of the program the decider is supposed to decide on,
and thus that algorithm *IS* an input.