Re: key error in all the proofs --- Mike --- basis

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.