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 --- key error
 in all the proofs --- Mike
Date: Mon, 12 Aug 2024 17:13:41 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <8318f5969aa3074e542747fe6ba2916d7f599bde@i2pn2.org>
References: <v8jh7m$30k55$1@dont-email.me>
 <49e9799be11c5e626bc05a421227bb7563982f0d@i2pn2.org>
 <v98uf7$vepo$1@dont-email.me>
 <60f1a533219c1237071f358999228eb48727f5e9@i2pn2.org>
 <v991tu$vepo$2@dont-email.me>
 <895f5e9b934bbfb72925fb109043500d49100a6a@i2pn2.org>
 <v994vs$10cfm$1@dont-email.me>
 <dec62801011bc5bf0b9eb9a62c607cf407198609@i2pn2.org>
 <v99870$14mlk$1@dont-email.me>
 <0f8f134fe961ee00910cce1d7f05b632d7567c6c@i2pn2.org>
 <v9abfu$2nabt$1@dont-email.me>
 <86c21e8a63450bf8b0c32f4f17ba0b503a914fe0@i2pn2.org>
 <v9d01i$39tbd$2@dont-email.me>
 <2c853efb65c3d8e2d4ba1c484f7002c74c68d895@i2pn2.org>
 <v9d1v8$3a9pe$1@dont-email.me>
 <e614d6b981fd5fa6eefc84894a14448d4663e3c7@i2pn2.org>
 <v9da2d$3bth4$1@dont-email.me>
 <64ddeeaa3a55a9e410de599bd8df53d3644ee5a3@i2pn2.org>
 <v9de0o$3cjse$1@dont-email.me> <v9dela$3cjse$2@dont-email.me>
 <b7c45ea22cb83908c31d909b67f4921156be52e3@i2pn2.org>
 <v9dgvl$3d1an$1@dont-email.me>
 <d289636b1d244acaf00108f46df093a9fd5aa27c@i2pn2.org>
 <v9dk2j$3dp9h$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 12 Aug 2024 21:13:41 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2312776"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v9dk2j$3dp9h$1@dont-email.me>
Bytes: 6951
Lines: 122

On 8/12/24 2:25 PM, olcott wrote:
> On 8/12/2024 1:16 PM, Richard Damon wrote:
>> On 8/12/24 1:32 PM, olcott wrote:
>>> On 8/12/2024 12:12 PM, Richard Damon wrote:
>>>> YOU don't understand the rules of the x86 code, or don't care if you 
>>>> are wrong, as NOTHING in the x86 language allows the leaving of the 
>>>> direct exectuion thread and into showing the code the simulator 
>>>> being simulated is simulating. The ONLY correct answer is showing it 
>>>> doing the simulating.
>>>>
>>>
>>> I showed the first four lines of this code
>>> highlighted in red and you ignored it.
>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

First a few comments about this file.

It has clearlly changed over time without notice, you said you added 
highlighting, but it also has had content changes.

It really needs to be date-stamped and version controlled. I can not say 
if the copy I look at today is the same as I looked at the other day.

Second, it is NOT the trace you keep on claiming but is the trace that 
x86UTM makes of running main, with the trace that the levels of HHH do 
inserted (WITHOUT COMMENT) into the listing, making the trace that HHH 
generats hard to find.

The length of the wrong trace starts on page 38, so there are only about 
160 pages of trace (the rest is an assembly listing of the program, 
useful to understand the trace, but not part of the trace itself) and 
there are only 1 to 2 lines from HHH per page, so a trace of just what 
HHH does would be only about 200-300 LINES long, not 200 pages, and not 
beyond what many people can handle, especially when you remove the cruft 
of having to wade through all the other junk that isn't the trace that 
HHH makes.

There are also clearly functions that are not even correctly listed in 
the assembly listings, nor traced, that seem to be hooks to make OS 
calls. That isn't totally unreasonable, but not clearly marked as such.


>>
>> No, you ignored my comments.
>>
>> First, that isn't a trace generated by HHH emulating DDD, but by 
>> x86UTM emulating HHH, so your claim is just a type error.
>>
>> Then when I look at this emulation, we see that HHH *ONLY* emulates 
>> those first 4 instructions of HHH and no more,
> 
> That is counter factual.

Looking closer, I may have gotten confused by the changing file by the 
same name

I do see the simulation continuing into HHH, but ...

One thing I do note is that the trace sees conditional jump instructions 
in the trace, but your "rule" is that there can be no conditional 
instructions see in the full loop, so something is wrong.

One instruction I see is:
Page 79, simulated the JNZ 00001335 at address 000012f8
Why wasn't this counted as a conditional instruction in the trace?
(That means the recursion isn't unconditional)

So, mybe it is a correct partial emulation, but just ignores some of the 
meaning, so that conditional recursion is incorrectly considered to be 
infinite recursion. Perhaps you just failed to test you code to see that 
it correctly detects conditional jump instructions.

Note, examining your code, your code also VIOLATES your requirement to 
be a pure functikon.

First, in Init_Halts_HH you detect if you are the "root" decider by look 
to see it the stack is at the initial prefilled value, and if so make 
yourself the "root" and setup a trace buffer, and record that we are the 
"Root"

Then in Decides_Halting_HH you test that Root flag, and only the "Root" 
decider actually does halt deciding, thus the copy of HHH that DDD calls 
performs a DIFFERENT set of actions to the ones that the one called by 
main does.

Thus, You are proven to be a liar that you code ACTUALLY acts as a pure 
function. The static memory isn't just a way for the lower emulator to 
have its results seen by the higher emulator, but the emulators actually 
change from Halt Deciders to pure emulators when they are nes


> 
>> that it doesn't simulate what happens in HHH after the jmp 000015e7 
>> instruction, and thus you claim is still a LIE.
>>
> 
> That is counter factual.

Maybe it is recording but not looking at those instructions. Why else is 
it ignoring the conditional instructions?

> 
>> It says that you have HHH simulate the first *8* instructions of the 
>> program DDD, and then stop doing a correct x86 emulation, and switches 
>> to an INCORRECT functional emulation, since it doesn't note that this 
>> emulation is CONDITIONAL.
>>
>> Sorry, you are still caught in your lie, and making it clear it is a 
>> DELIBERATE lie.
>>
>> Proofs based on LIES are not proofs but are just lies.
>>
>>>
>>>> I HAVE pointed out the exact point you "correct emulation" deviates 
>>>> from the x86 requirments, > and you only answer seems to be that the 
>>>> x86 model of simulation gets too long. In other words, you logic 
>>>> system allows people to just LIE if they want to.
>>>
>>>
>>
> 
>