Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: key error in all the proofs --- Mike --- basis
Date: Tue, 13 Aug 2024 20:38:45 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <d2309af812f88b94b2a64a422bf8240b54a0caae@i2pn2.org>
References: <v8jh7m$30k55$1@dont-email.me> <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>
	<2f8c1b0943d03743fe9894937092bc2832e0a029@i2pn2.org>
	<v9fn50$3ta4u$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 13 Aug 2024 20:38:45 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2476099"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5559
Lines: 64

Am Tue, 13 Aug 2024 08:30:08 -0500 schrieb olcott:
> 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:

>>>> 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...

>> 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.
It just doesn't halt, that's why HHH can't do it. And if HHH aborts,
it becomes unnecessary. Whether it does can't depend on the simulation
level - all H's abort or none.

> HHH correctly predicts that a correct and unlimited emulation of DDD by
> HHH cannot possibly reach its own "return" instruction final halt state.
If let run, the HHH called by DDD will abort and return.

> H has never ever been required to do an unlimited emulation of a
> non-halting input. H has only ever been required to correctly predict
> what the behavior of a unlimited emulation would be.
Which it doesn't fulfill.

-- 
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.