Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: HHH maps its input to the behavior specified by it ---
Date: Sat, 10 Aug 2024 14:58:32 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <9721b1bcc4a6849dabc5d7956754292823381840@i2pn2.org>
References: <v8jh7m$30k55$1@dont-email.me> <v8pvke$ih0a$1@dont-email.me>
 <4-qdnbdw1JzlRS37nZ2dnZfqlJydnZ2d@giganews.com>
 <v8v7p3$29r2r$1@dont-email.me> <v8vub1$32fso$14@dont-email.me>
 <1e1fa9bc4bbc00aa65c1a7974bd1bda87687c92b@i2pn2.org>
 <v90di8$38oni$1@dont-email.me>
 <47a76378d634bf0db4017f879d0160793b57125e@i2pn2.org>
 <v9161o$3gaju$1@dont-email.me>
 <b84374e766c199e1ba38ef1dc3bc8f6ab2c39dfc@i2pn2.org>
 <v91i97$3n4m0$1@dont-email.me> <v91unh$3rbor$1@dont-email.me>
 <v92gja$p1$3@dont-email.me> <v94m0l$ljf4$1@dont-email.me>
 <v95ae9$p5rb$1@dont-email.me> <v978dv$h1ib$1@dont-email.me>
 <v97j0q$ilah$2@dont-email.me>
 <ccc5dafb53acf66239baac0183a6291687794963@i2pn2.org>
 <v97l3j$kof0$2@dont-email.me> <v97pgq$l4f4$2@dont-email.me>
 <v97qf0$lise$2@dont-email.me> <v97rq3$l4f4$4@dont-email.me>
 <v97t7g$m8l6$1@dont-email.me>
 <332fdac834dd53dbe6a8650e170f08fac33ca2cf@i2pn2.org>
 <v988fu$r9k6$1@dont-email.me>
 <614b136972063ab2c9d5e3d91e4289858ef24f55@i2pn2.org>
 <v98ag9$rj63$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 10 Aug 2024 18:58:32 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2111484"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v98ag9$rj63$1@dont-email.me>
Content-Language: en-US
Bytes: 6629
Lines: 109

On 8/10/24 2:11 PM, olcott wrote:
> On 8/10/2024 12:51 PM, Richard Damon wrote:
>> On 8/10/24 1:37 PM, olcott wrote:
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>      If simulating halt decider H correctly simulates its input D
>>>      until H correctly determines that its simulated D would never
>>>      stop running unless aborted then
>>>
>>>      H can abort its simulation of D and correctly report that D
>>>      specifies a non-halting sequence of configurations.
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>> That is true in every case except when an input calls its
>>> own simulating halt decider.
>>
>>
>> Nope. No exeptions. That is just another of your "I made it up but 
>> can't prove it but it must be true" lies.
>>
>>
>>>
>>> void DDD()
>>> {
>>>    HHH(DDD);
>>>    return;
>>> }
>>>
>>> *The set of HHH x86 emulators are defined such that*
>>> Each element of this set corresponds to one element of the set
>>> of positive integers indicating the number of  x86 instructions
>>> of DDD that it emulates.
>>
>> But every one that emulates for a finite number of steps, and then 
>> returns create a halting DDD, so you claim is just disproven.
>>
> 
> Changing the title indicates a reply that I can ignore.
> I am only replying to a single thread of communication
> with you.

I just sometimes correct your title, because it is wrong.

For instance, if HHH is defined to be a Halt Decider, it MUST map the 
input to the behavior of the direct execution of the machine represented 
by the input, which if HHH(DDD) returns to main, in returns to DDD, so 
the mapping it is REQUIRED to compute (to be correct) is Halting.

If HHH computes a mapping based on its aborted simulation of its input, 
then it is NOT a "Halt Decider", but something else. Since the mapping 
it is computing differs based on the decider, it isn't even a fixed 
property of the input, so isn't even a valid "property" for a decider 
unless you define the property for THAT PARTICUAL HHHs simulaiton, and 
thus you infinite set of "deciders" is looking at an infinite set of 
"properties", which isn't something that is normally considered valid.

Sorry, you are just showing you don't know what you are talking about.

> 
> *Maybe your ADD has always been much worse than I ever expected*
> We have been over all of these same points hundreds of times.

Right, you have made the same LIES  over and over, and I keep on 
correcting you, but you seem too stupid to be able to learn. I pity the 
angel that has been assigned to keep your behavior books in heaven and 
has to keep track of all your lies.

> 
> When each element of the outer-most directly executed SHH
> corresponds to one element of the set of positive integers
> indicating the number of x86 instructions of DDD that it
> emulates none of the emulated instances of HHH ever returns.

And EVERY ONE Of them doesn't get the right answer.

The ones that do a finite number of instructions, and then return create 
a HALTING DDD, because the DDD they are looking at calls THEM, so if 
they return to their caller of main, they return to their caller of DDD, 
and thus DDD is halting.

The fact that their simulation didn't get to that point, just shows that 
it was just a PARTIAL simulation which doesn't actually show the full 
behavior fo the input, and then the programmer (YOU) gave them faulty 
logic to try to compute the behavior.

Your problem is you conflate the behavior of the program emulated, with 
the partial emulation of that program. Once you talk about "halting", 
partial emulations are no longer determinative of that property, only 
direct exectution or complete emulations.


> 
> THAT IS WHAT THE C SOURCE CODE MEANS
> THAT IS WHAT THE X86 CODE MEANS
> 

Well, the x86 instruction of DDD says that it will do exactly what its 
direct execution does, and says that the code of HHH is PARRT of the 
code of DDD, as that comes out of the semantics of the x86 langugage.

It also comes out of the C programming language, which says that a 
program consists of ALL the translation units that define the program, 
and DDD isn't a valid program if we don't have the translation unit with 
HHH.

This also means that changing the translation unit with HHH, changes the 
program DDD, whether you want to consdier that or not, and thus the 
correct interpreation of the program DDD if dependent on the behavior of 
HHH, and thus you can't look at the behavior of one DDD while assuming a 
different HHH then the one that DDD actually was calling.