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: HHH maps its input to the behavior specified by it --- never
 reaches its halt state ---natural number mapping
Date: Tue, 13 Aug 2024 22:29:39 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <820ac1b87834ce0f7b115bac8bac048e0ed63e5a@i2pn2.org>
References: <v8jh7m$30k55$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> <v99lpd$25ri3$1@dont-email.me>
 <v9a88e$2923f$2@dont-email.me> <v9b4tr$2rdni$1@dont-email.me>
 <v9cvv5$39tbd$1@dont-email.me> <v9f203$3pfoq$1@dont-email.me>
 <v9fl4k$3se8c$2@dont-email.me> <v9fnd9$1ut3$1@news.muc.de>
 <v9fopi$3tfih$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 14 Aug 2024 02:29:39 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2494910"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v9fopi$3tfih$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 7169
Lines: 161

On 8/13/24 9:58 AM, olcott wrote:
> On 8/13/2024 8:34 AM, Alan Mackenzie wrote:
>> olcott <polcott333@gmail.com> wrote:
>>> On 8/13/2024 2:29 AM, Fred. Zwarts wrote:
>>>> Op 12.aug.2024 om 14:42 schreef olcott:
>>>>> On 8/11/2024 2:54 PM, Fred. Zwarts wrote:
>>>>>> Op 11.aug.2024 om 13:45 schreef olcott:
>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>>     HHH(DDD);
>>>>>>>     return;
>>>>>>> }
>>
>>>>>>> None-the-less it is clear that of the above specified infinite
>>>>>>> set DDD correctly emulated by each element of that set never
>>>>>>> reaches its own "return" instruction halt state.
>>
>>>>>> Since no DDD is correctly simulated by HHH, we are talking about the
>>>>>> properties of an empty set.
>>>>>> But, indeed, the simulation of DDD by HHH fails to reach the halt
>>>>>> state. It aborts one cycle before the simulated HHH would reach its
>>>>>> 'return' instruction, after which DDD would reach its halt state.
>>
>>
>>>>>>> My words must be understandable by ordinary C programmers
>>>>>>> and computer scientists. The latter tend to conclude that
>>>>>>> my work is incorrect as soon as they know the subject matter
>>>>>>> before actually seeing what I said.
>>
>> Your words are understandable; they're just wrong.
>>
>>>>>> Every C programmer understands that a simulation fails if it does not
>>>>>> reach the end of a halting program.
>>
>>>>> Four expert C programmers (two with masters degrees in
>>>>> computer science) agree that DDD correctly simulated by
>>>>> HHH does not halt.
>>
>> It's not clear what these "expert programmers" have agreed to.  As Fred
>> has frequently pointed out, your DDD cannot be correctly simulated by
>> HHH, so you have an empty set about which anything is true.
>>
>>>> Many more experts with master degrees tell you that it does halt.
>>>> Show evidence instead of authority.
>>
>>> *Every attempt at rebutting this has been*
>>
>> There's nothing to rebut.  You just keep coming out with blatant
>> falsehoods, as pointed out by the other posters, here.
>>
>>> (a) Denying verified facts
>>
>> That's a lie.  By "verified facts" you just mean "falsehoods PO would
>> like to be true".
>>
>>> (b) Strawman-deception of changing what I said and rebutting that
>>
>> That's a lie, too.  I've not seen anybody else apart from you doing this.
>> Indeed you're doing this as a response to Fred's last post.
>>
>>> (c) Pure ad hominem insults with zero reasoning
>>
>> That's also false.  The insults follow as a result of your falsehoods and
>> lies.  They are entirely justified.  You continually insult other posters
>> by several means, including ignoring what they write.  If you would
>> actually treat them with respect, the insults against you would cease.
>>
>>> Mike is the only one here that seems to have enough technical
>>> skill to understand the verified facts.
>>
>> You mean agree with your falsehoods.  Mike doesn't do this.  You wouldn't
>> know technical skill if it bit you on the nose.
>>
>>> Everyone else denies them entirely on the basis of their own ignorance.
>>
>> You're the ignorant poster here, nobody else.  You've taken a small part
>> of an undergraduate mathematics or computer science course, something the
>> typcial student would master in a few hours at most, spent 20 years on
>> it, and you still don't get it.
>>
>> [ .... ]
>>
>>
>>> -- 
>>> Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
>>> hits a target no one else can see." Arthur Schopenhauer
>>
> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> Through something like mathematical induction we can directly
> see that DDD correctly emulated by any HHH cannot possibly
> reach its "return" instruction final halt state.


Nope,

TRY to form the induction. Remember, changing HHH gives you a DIFFERENT 
DDD, so you can't transfer behaviors between them.


> 
> HHH is only required to predict whether or not an unlimited
> emulation of DDD would ever halt.

Right, but for the DDD that calls THAT HHH, not the unlimited emulator.

> 
> Thus when computing the behavior that this finite string
> specifies DDD never halts.


Nope. You are trying to play a shell game. DDD calls the decider you are 
calling HHH.

HHH must answer about what this DDD that calls THAT HHH when emulated by 
a seperate unlimited emulator will do.

> 
> _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 always has the exact same finite string of machine
> code bytes. This requires each HHH to always be at machine
> address 000015d2.

ERROR ERROR ERROR.

The bytes of HHH are part of the input or the input isn't a program and 
you are committing a category error.

The program DDD can not depend on code that isn't part of it.

Sorry, you just proved you don't know what you are talking ABOUT.

YOU ARE JUST A STUPID SELF-MADE IGNORANT FOOL.


> 
> The computation is always reporting whether or not DDD
> can possibly reach its c3 "ret" instruction at machine
> address [00002183].
> 
> 

Right, and the computation DDD includes the code of the actual HHH that 
it is calling, which is the decider you are claiming to be correct.

The unlimited emulator is given the FULL code of DDD + HHH and that unli 
mited emulator is NOT a 000015d2