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 --- key error
 in all the proofs --- Mike --- basis
Date: Tue, 13 Aug 2024 07:23:53 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <2f8c1b0943d03743fe9894937092bc2832e0a029@i2pn2.org>
References: <v8jh7m$30k55$1@dont-email.me> <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>
 <8318f5969aa3074e542747fe6ba2916d7f599bde@i2pn2.org>
 <TyKdnc3hCNvmUyf7nZ2dnZfqn_udnZ2d@brightview.co.uk>
 <v9ekta$3necg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 13 Aug 2024 11:23:53 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2312775"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v9ekta$3necg$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 9722
Lines: 161

On 8/12/24 11:45 PM, olcott wrote:
> On 8/12/2024 10:09 PM, Mike Terry wrote:
>> On 12/08/2024 22:13, Richard Damon wrote:
>>> 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)
>>
>> PO's rule is that there must be no conditional branch instructions 
>> *WITHIN DDD*.  Conditional branch instructions in HHH are simulated, 
>> and with suitable compilation options [I think it is the 
>> TRACE_USER_CODE_ONLY pre-processing symbol that needs to be undefined] 
>> those instructions will also be LOGGED.  Well, you're seeing the 
>> result of that on page 79 of the PDF file.
>>
>> Distinction between what is LOGGED (by x86utm.exe), and what goes into 
>> the global trace table examined by HHH:   The former is an x86utm 
>> ("supervisor?") concept.  The latter is HHH application logic - HHH 
>> implements the tests for "non-halting" patterns, and only needs to 
>> capture trace entries needed to apply its rules.  For example, since 
>> the rules explicitly ignore trace entries from HHH, HHH doesn't need 
>> to capture them.  You can see those trace entries in the x86utm LOG, 
>> which is why the log is the way to go, when working out what's going 
>> on and why.
>>
>> Just to be 100% clear for PO's benefit, when I say HHH "only needs to 
>> capture trace entries needed to apply its rules" I am not suggesting 
>> those rules are correct - just that from a coding perspective, there's 
>> no point in a program capturing data that is irrelevent for it's later 
>> processing.  As an example here, PO adds trace entries to his global 
>> trace table which are of no interest to any of his rules!  Really, he 
>> is only interested in branches, calls, and the likes, but he captures 
>> everything DDD does like "mov ebp,esp" or whatever which his rules all 
>> ignore...  Not an issue in practice because his trace captures [given 
>> other filtering] are tiny.  Might become important for capacity 
>> reasons if PO wanted to include HHH entries, but he doesn't.
>>
>> Now, anyone thinking sensibly at this point is going to ask *WHY* does 
>> PO's rule
>> *exclude conditional branches within HHH* when they are obviously 
>> critical to halting?  PO will never explain that. 
> 
> *I have always explained that and everyone ignores my explanation*
> 
> On 8/2/2024 11:32 PM, Jeff Barnett wrote:
>  > ...In some formulations, there are specific states
>  >    defined as "halting states" and the machine only
>  >    halts if either the start state is a halt state...
> 
>  > ...these and many other definitions all have
>  >    equivalent computing prowess...
> 
> Now I have the same basis that I have repeated many
> times that cannot be so easily rejected out-of-hand.
> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> *DDD correctly emulated by HHH cannot possibly reach its*
> *own "return" instruction final halt state, thus never halts*
> 

Which is only correct if HHH actuallly does a complete and correct 
emulation, or the behavior DDD (but not the emulation of DDD by HHH) 
will reach that return.

Remember, since you put this into the context of "Halting", that 
behavior is ONLY indicated by reference to a COMPLETE execution or 
COMPLETE emulation of the program.

Also remember "DDD" refers to the PROGRAM DDD (since that is what 
Halting talks about), and thus include the code of HHH, and thus 
changing the HHH that DDD calls changes DDD, and it is a different input.

Your statement is NOT true, if you allow "correctly emulated" to include 
partial emulation, and thus by making this assertion, you are 
stipulating that the only meaning you are making of "correct emulation" 
is a complete emulation.

But, we also have the fact that you have admitted that you have defied 
the rules of theory, as you have said that "DDD is only the C function, 
and not a program", at which point your whole argument is based on a 
type error, Halting is about PROGRAMS, complete collections of all the 
instructions used to decide the results, and not the C concept of a 
function that can use other resources outside of itself.

We alos have the confirmed violation of the decider needing to be a 
"pure" function, in that HHH uses accesses to global memory to know it 
if is the outer decier, or is an emulated decider, and changes its 
========== REMAINDER OF ARTICLE TRUNCATED ==========