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: DD emulated by HHH cannot possibly terminate normally --- x86
 code
Date: Sat, 1 Mar 2025 20:14:20 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <756b757de18d651eb420e858396adeda8693e73b@i2pn2.org>
References: <vptlfu$3st19$9@dont-email.me> <vpug3h$50td$1@dont-email.me>
 <vq06al$eljf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 2 Mar 2025 01:14:20 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2424304"; 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: <vq06al$eljf$1@dont-email.me>
Bytes: 5411
Lines: 101

On 3/1/25 6:47 PM, olcott wrote:
> On 3/1/2025 2:22 AM, Mikko wrote:
>> On 2025-03-01 00:47:58 +0000, olcott said:
>>
>>> _DD()
>>> [00002133] 55         push ebp      ; housekeeping
>>> [00002134] 8bec       mov ebp,esp   ; housekeeping
>>> [00002136] 51         push ecx      ; make space for local
>>> [00002137] 6833210000 push 00002133 ; push DD
>>> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
>>> [00002141] 83c404     add esp,+04
>>> [00002144] 8945fc     mov [ebp-04],eax
>>> [00002147] 837dfc00   cmp dword [ebp-04],+00
>>> [0000214b] 7402       jz 0000214f
>>> [0000214d] ebfe       jmp 0000214d
>>> [0000214f] 8b45fc     mov eax,[ebp-04]
>>> [00002152] 8be5       mov esp,ebp
>>> [00002154] 5d         pop ebp
>>> [00002155] c3         ret
>>> Size in bytes:(0035) [00002155]
>>>
>>> When we hypothesize that the code at machine address
>>> 0000213c is an x86 emulator then we know that DD
>>> remains stuck in recursive emulation and cannot possibly
>>> reach its own "ret" instruction and terminate normally.
>>
>> The emulator itself is stuck and cannot return normally but it doesn't
>> know it cannot return normally. At some point it runs out of memory
>> and terminates normally or abnormally.
>>
> 
> Yes you are correct about this sub-step of two steps.
> 
>>> When we add the additional complexity that HHH also
>>> aborts this sequence at some point then every level
>>> of recursive emulation immediately stops. This does
>>> not enable any DD to ever reach its "ret" instruction.
>>
>> When we add an additional complexity we must note that there are other
>> additional complexities that could be added instead.
>>
> 
> Sure we could carefully examine every detail about the price
> of tea in China.
> 
> When we are answering the question that seems impossible for
> anyone here to pay attention to even when repeated hundreds of times:
> 
> Can the above DD correctly emulated by HHH possibly
> reach its own "ret" instruction and terminate normally?

The problem is that if HHH correctly emulates DD, then it can not 
answer, and thus YOU are missing that you are making an assumption that 
you are not following.

And, the question you are asking is just a strawman, proving that you 
don't know what a halt decider is, as a halt decider does not determine 
if it can simulate the input to a final state, it determines if the 
program when run or actually completely correctly emulated would halt.

The fact that HHH's aborted emulation doesn't reach a final state means 
nothing, as for this case, the correct emulation of THIS PROGRAM (which 
calls the HHH that aborted its emulation) will reach the final state, 
and the HHH that does a complete emulation (and get stuck) was given a 
DIFFERENT version of DD, since it calls a different version of HHH, 
which means you had to change the code of the input program.

All you are doing is proving you don't understand what a program is, or 
that you don't care about lying about it.

> 
> The answer is dead obviously "no" for everyone that is:
> (a) Technically competent
>    and
> (b) Not deliberately deceptive.

But that HHH can not correctly emulate the input to that point, doesn't 
say that something else can't if HHH doesn't also do that correct emulation.

YOU are showing that it is YOU who is technically incompetent and being 
deliberately deceptive, by your instance of making assumptions that are 
in fact not true, like your HHH is actually doing a correct emulation.

Until you stop doing that, nothing you say has any value, and you are 
just proving that you are just a pathologically lying hypocrite.

> 
> Once we get through this then people will understand
> that my system would eliminate AI hallucinations.
> 
> Until AI has a foundation of basic facts it will always
> view everything as some kind of fiction.
> 

AI, as currently implemented, isn't based on a foundation of facts, as 
the problem of trying to prove answers is just intractable and is too slow.

There are small systems that use that sort of AI, it just is limited to 
small systems. You just don't understand the nature of the problem.

And, it would still be impossible for the AI to answer about things 
whose answer is unprovable.