Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: HHH maps its input to the behavior specified by it --- key error in all the proofs --- Mike --- basis
Date: Wed, 14 Aug 2024 10:30:52 +0300
Organization: -
Lines: 149
Message-ID: <v9hmfc$c71c$1@dont-email.me>
References: <v8jh7m$30k55$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> <2f8c1b0943d03743fe9894937092bc2832e0a029@i2pn2.org> <v9fn50$3ta4u$2@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 09:30:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c3c24c5ffe79752ad72ef4cdb11b642f";
	logging-data="400428"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19IdQPcXa0u6Ozyy4NJAVwg"
User-Agent: Unison/2.2
Cancel-Lock: sha1:j8KkC74uirhwhE/tAw5PRzldOwA=
Bytes: 8767

On 2024-08-13 13:30:08 +0000, olcott said:

> On 8/13/2024 6:23 AM, Richard Damon wrote:
>> 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.
>> 
> 
> A complete emulation of a non-terminating input has always
> been a contradiction in terms.
> 
> HHH correctly predicts that a correct and unlimited emulation
> of DDD by HHH cannot possibly reach its own "return" instruction
> final halt state.

That is not a meaningful prediction because a complete and unlimited
emulation of DDD by HHH never happens.

-- 
Mikko