On Wed, 8 Jun 2022 00:50:11 +0100
Mr Flibble <flibble@reddwarf.jmc> wrote:

> On Tue, 7 Jun 2022 18:42:36 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
> > On 6/7/2022 6:37 PM, Mr Flibble wrote:
> > > On Tue, 7 Jun 2022 18:35:22 -0500
> > > olcott <NoOne@NoWhere.com> wrote:
> > >
> > >> On 6/7/2022 6:31 PM, Mr Flibble wrote:
> > >>> On Tue, 7 Jun 2022 18:28:27 -0500
> > >>> olcott <NoOne@NoWhere.com> wrote:
> > >>>
> > >>>> On 6/7/2022 6:17 PM, Mr Flibble wrote:
> > >>>>> On Tue, 7 Jun 2022 18:14:01 -0500
> > >>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>
> > >>>>>> On 6/7/2022 6:04 PM, Mr Flibble wrote:
> > >>>>>>> On Tue, 7 Jun 2022 18:01:25 -0500
> > >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>
> > >>>>>>>> On 6/7/2022 5:45 PM, Mr Flibble wrote:
> > >>>>>>>>> On Tue, 7 Jun 2022 17:37:44 -0500
> > >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> On 6/7/2022 5:08 PM, Mr Flibble wrote:
> > >>>>>>>>>>> On Tue, 7 Jun 2022 16:28:21 -0500
> > >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On 6/7/2022 4:22 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>> On Tue, 7 Jun 2022 16:01:53 -0500
> > >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 6/7/2022 3:51 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:34:13 -0500
> > >>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On 6/7/2022 3:18 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:14:30 -0500
> > >>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On 6/7/2022 3:06 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:01:13 -0500
> > >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:49 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 14:09:14 -0500
> > >>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:02 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 14:02:08 -0500
> > >>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 1:41 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 13:19:15 -0500
> > >>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 12:50 PM, Mr Flibble wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 11:57:57 -0500
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 11:45 AM, Mr Flibble
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 20:13:01 -0500
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 7:56 PM, Richard Damon
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/22 8:27 PM, olcott wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:59 PM, Mike Terry
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 22:59, Jeff Barnett
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 2:07 PM, Mike Terry
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 16:16, Alan
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mike Terry
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <news.dead.person.stones@darjeeling.plus.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 13:14, Alan
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@nowhere.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:12 AM, Alan
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@nowhere.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 5:14 AM, Mikko
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2022-06-04 19:28:19
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +0000, olcott said:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A Turing machine is said
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to halt whenever it
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches a configuration
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for which δ is not
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined; this is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible because δ is a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> partial function. In
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fact, we will assume
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that no transitions are
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined for any final
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state so the Turing
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine will halt
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whenever it enters a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Introduction to Formal
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Languages and Automata.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Heath and Company.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When translated into
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ordinary software
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineering terms this
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> means terminated
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally. In a C
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function this means
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret"
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The best equivalent to
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "not defined" is not
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "ret". Instead, "not
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined" should include
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at least:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - HLT or any other
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction that means
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'halt'
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any undefined op code
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any return or pop
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction if the stack
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is empty
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - an instruction fetch
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from a location that is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not specifiec by the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program That way the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> analogy to Linz'
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition is much
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> better.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mikko
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reaching a final state is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely the Turing machine
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way of saying terminated
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally. "ret" is the C
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way of saying the same
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sophistry.  What would be
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the turing machine
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> equivalent of an "abnormal
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> termination" in C?
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> An aborted simulation.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's no such thing on a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine. It either
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> runs and halts, or it runs
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> forever.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your aborted simulation is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just one final state of a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine, which has
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thus halted.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A TM "aborting" a simulation
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is just the TM ceasing to
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate computation steps
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for some computation, and
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> going on to calculate
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead. It
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not mean: a) that the TM
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (doing the simulation) has
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted b) that the simulated
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation halts c) that the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation never
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK.  I've a feeling we're
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> talking more about nice shades
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of words than computer science
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here, but ....
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the simulation is the entire
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine, aborting it
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will bring the TM to a halt
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state.  If that simulation is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely part of the TM, then
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the word "halt" has a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different meaning when applied
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that simulation part from
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when applied to the entire TM.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm not even sure what you
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean when you say a part of a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM has halted or not halted.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We are clearly talking at cross
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> purposes
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - I never talked about /part/
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of a TM halting, and like you,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can't work out what that
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would mean!  I used "halt" only
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with respect to a computation,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> meaning that the computation
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts [there is an n such that
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation step n is a TM
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state].
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reading what you say very
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> carefully, I think that by your
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of simulation, the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating TM must be a "pure"
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator that does nothing but
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate computation steps until
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation halts, at which
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point the simulating TM halts
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (like a UTM). I get that with
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that interpretation what you
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >>> Your
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted simulation is just one
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state of a turing
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine, >>> which has thus
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   makes sense and
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is correct. I'd just say I don't
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> think that usage of "simulation"
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is very useful, and is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITELY not what PO is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> talking about (so it would be
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong if applied PO's posts...)
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My use of "simulation" is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> broader: it's simply the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> activity performed by a TM
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which consists of calculating
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps of some given
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation.  As such it's just
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a part of the TM logic. A TM's
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typical use of simulation might
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be something like "..the TM
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates the computation for n
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> steps, and if the simulation
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts during those n steps, the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM [blah blah], /otherwise/ the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM [blah blah blah]...". Just
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about every reference in the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> literature I can recall is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something like that.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So... to be 100% clear on what I
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >> A TM
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "aborting" a simulation is just
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TM ceasing to calculate >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps for some
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation, and going on to
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> E.g. in PO's P, after P aborts
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation of P(P), the TM
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> either halts or enters an
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop. (That logic is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not part of the simulation,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IMO.) >> It does *NOT* mean: >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a)  that the TM (doing the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation) has halted
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously, because now P has
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gone on to something else...
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >> b)  that the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation halts >>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c) that the simulated
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation never halts
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously - in general different
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exacmples of a simulated
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation P(I) might halt or
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never halt, and this is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unaffected by a simulator's
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decision to simulate no further
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps. [The TM may
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have spotted some pattern in the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation which
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implies P(I) never halts - that
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is a separate matter, but for
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sure the mere act of "aborting"
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation doesn't imply
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(I) never halts, or imply that
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it halts...
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Put yet another way, when a TM
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops calculating TM steps (aka
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborts its simulation), NOTHING
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HALTS: not the simulating TM,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not the simulated computation,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and NOT ANY PART OF EITHER OF
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THOSE. (Like you say, what
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would part of a TM halting
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean?)
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think of a TM and an input
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> string as defining a sequence
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (an ordered list). The elements
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the sequence are pairs of a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM state name and a string
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> representing the "tape" contents
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when the state was entered. Note
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that this view has no character
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of animation in it and makes the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of the halt predicate
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (H) trivial:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(TM,STRING) = If length of
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM(STRING) is finite then TRUE
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> else FALSE.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, that's equivalent to what I
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said (or at least meant). Your
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence is my computation steps.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Formally, these would be defined
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inductively via the rule to go
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from step n to step n+1. (Not an
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> animation, but the induction gives
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some /sense/ of step-by-step
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculation, and a simulator will
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> follow this, starting at step 1,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> then calculate step 2 and so on.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Still, I agree the entire sequence
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [the "computation"] exists as one
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> timeless structure.  Too abstract
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for PO...)
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words when we make sure to
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> conflate the program under test
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the test program as a single
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation then the whole idea of
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider becomes less
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> coherent and
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this can be used as an excuse to
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pretend that you don't already know
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0 is correct and the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H/P relationship matches the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halting problem counter example
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> template.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    if (H(x, x))
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      HERE: goto
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE; return;
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    Output("Input_Halts
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H((u32)P, (u32)P)); }
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       For any
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program H that might determine if
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs halt, a "pathological"
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program P, called with some input,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can pass its own source and its
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H and then specifically
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do the opposite of what H predicts
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P will do. No H can exist that
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> handles this case.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A simulator animates the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> production of the sequence and
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that causes some difficulties in
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same way that elaborating an
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sum or sequence does in
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> math classes. An (ultimate)
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value only exists if there is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some notation of convergence or
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit which typically is the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case with examples used in a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> math class. There is no
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of convergence or
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit with the sequence defined
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> by TM(STRING); rather, we simply
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ask about the last pair if the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence is finite.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sure.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The question right now is what you
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would call a TM which evaluates
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the first 10 steps of a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation, and then does
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else. What is it doing
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> while evaluating those 10 steps?
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tl;dr : who cares :)
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My terminology would be that it's
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "simulating" the computation (just
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for 10 steps) - then it stops
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating and does something
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> else. Obviously I wouldn't
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> describe it as "correctly"
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating, because nobody
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> considers incorrect simulations,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> so the word would be redundant!
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is required because my reviewers
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are making their best possible
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> effort to form rebuttals and the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> most persistent of the fake
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rebuttals has been that the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation is incorrect. It is very
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easy to verify the correct x86
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation on the basis of the x86
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Except that it doesn't. By
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION, a correct simulation
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs show the same behavior of the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing it is simulating.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Members of comp.c and comp.c++ this
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> goofy idiot is trying to claim that
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it is utterly impossible to create a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C program that examines the x86
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution trace derived from
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating the input to
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H0(Infinite_Loop) with an x86
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator to correctly determine that
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinite_Loop() infinitely loops.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H0(Infinite_Loop)); }
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342](01) 55 push
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001343](02) 8bec
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001345](02) ebfe
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 [00001347](01) 5d
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pop ebp [00001348](01) c3
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0007) [00001348]
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored at:212343
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342][00212333][00212337] 55
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 Local Halt Decider:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinite Loop Detected Simulation
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stopped
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> But he isn't doing that; the issue is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> not the infinite loop but the logic
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> used to decide to enter the infinite
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop. Post *full* traces.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are unable to tell
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> that _Infinite_Loop() contains an
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Again that isn't the issue; the issue is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> the logic used to decide when to enter
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> the infinite loop;
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> In other words when H0(Infinite_Loop) is
> > >>>>>>>>>>>>>>>>>>>>>>>>>> invoked we have no idea that a correct
> > >>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation of Infinite_Loop would
> > >>>>>>>>>>>>>>>>>>>>>>>>>> reach the instruction at machine address
> > >>>>>>>>>>>>>>>>>>>>>>>>>> [00001345] or not.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> It might be the case that a correct x86
> > >>>>>>>>>>>>>>>>>>>>>>>>>> emulation of Infinite_Loop might instead
> > >>>>>>>>>>>>>>>>>>>>>>>>>> involve emulating an entirely different
> > >>>>>>>>>>>>>>>>>>>>>>>>>> function that plays tic-tac-toe?
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Detecting an infinite loop is indeed
> > >>>>>>>>>>>>>>>>>>>>>>>>> trivial however your program and trace
> > >>>>>>>>>>>>>>>>>>>>>>>>> are not telling the full story as far as
> > >>>>>>>>>>>>>>>>>>>>>>>>> the HP proofs are concerned;
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> The only thing that my program trace
> > >>>>>>>>>>>>>>>>>>>>>>>> conclusively proves is that H(P,P)==0 is
> > >>>>>>>>>>>>>>>>>>>>>>>> the correct return value that does
> > >>>>>>>>>>>>>>>>>>>>>>>> correctly correspond to the actual
> > >>>>>>>>>>>>>>>>>>>>>>>> behavior of the actual input.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> For any program H that
> > >>>>>>>>>>>>>>>>>>>>>>>> might determine if programs halt, a
> > >>>>>>>>>>>>>>>>>>>>>>>> "pathological" program P, called with some
> > >>>>>>>>>>>>>>>>>>>>>>>> input, can pass its own source and its
> > >>>>>>>>>>>>>>>>>>>>>>>> input to H and then specifically do the
> > >>>>>>>>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H
> > >>>>>>>>>>>>>>>>>>>>>>>> can exist that handles
> > >>>>>>>>>>>>>>>>>>>>>>>> this case.
> > >>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> > >>>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> > >>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> > >>>>>>>>>>>>>>>>>>>>>>>> return;
> > >>>>>>>>>>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> int main()
> > >>>>>>>>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ",
> > >>>>>>>>>>>>>>>>>>>>>>>> H((u32)P, (u32)P)); }
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> _P()
> > >>>>>>>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
> > >>>>>>>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> > >>>>>>>>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov
> > >>>>>>>>>>>>>>>>>>>>>>>> eax,[ebp+08] [00001358](01) 50
> > >>>>>>>>>>>>>>>>>>>>>>>> push eax // push P [00001359](03)
> > >>>>>>>>>>>>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08] [0000135c](01) 51
> > >>>>>>>>>>>>>>>>>>>>>>>> push ecx // push P
> > >>>>>>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 //
> > >>>>>>>>>>>>>>>>>>>>>>>> call H [00001362](03) 83c408 add esp,+08
> > >>>>>>>>>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
> > >>>>>>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
> > >>>>>>>>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp
> > >>>>>>>>>>>>>>>>>>>>>>>> 00001369 [0000136b](01) 5d
> > >>>>>>>>>>>>>>>>>>>>>>>> pop ebp [0000136c](01) c3
> > >>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0027) [0000136c]
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P)
> > >>>>>>>>>>>>>>>>>>>>>>>> correctly emulates its input that it must
> > >>>>>>>>>>>>>>>>>>>>>>>> emulate the first seven instructions of P.
> > >>>>>>>>>>>>>>>>>>>>>>>> Because the seventh instruction of P
> > >>>>>>>>>>>>>>>>>>>>>>>> repeats this process we can know with
> > >>>>>>>>>>>>>>>>>>>>>>>> complete certainty that the emulated P
> > >>>>>>>>>>>>>>>>>>>>>>>> never reaches its final “ret” instruction,
> > >>>>>>>>>>>>>>>>>>>>>>>> thus never halts.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> But the halting problem proofs (including
> > >>>>>>>>>>>>>>>>>>>>>>> [Strachey 1965]) that you are trying to
> > >>>>>>>>>>>>>>>>>>>>>>> refute don't do that, they DO NOT make any
> > >>>>>>>>>>>>>>>>>>>>>>> recursive calls
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Because the idea of a simulating halt decider
> > >>>>>>>>>>>>>>>>>>>>>> being applied to the halting problem
> > >>>>>>>>>>>>>>>>>>>>>> counter-example is brand new with me you
> > >>>>>>>>>>>>>>>>>>>>>> won't find other references that refer to
> > >>>>>>>>>>>>>>>>>>>>>> "infinitely nested simulation".
> > >>>>>>>>>>>>>>>>>>>>>>> which is what you are doing with "call H"
> > >>>>>>>>>>>>>>>>>>>>>>> above. Why are you doing something different
> > >>>>>>>>>>>>>>>>>>>>>>> to what the proofs you are trying to refute
> > >>>>>>>>>>>>>>>>>>>>>>> do given doing so is no longer related to
> > >>>>>>>>>>>>>>>>>>>>>>> the Halting Problem?
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> /Flibble
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> The proofs never bothered to examine my idea
> > >>>>>>>>>>>>>>>>>>>>>> because it was unknown by everyone prior to
> > >>>>>>>>>>>>>>>>>>>>>> me creating it in 2016.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> It seems to me that your idea would only be
> > >>>>>>>>>>>>>>>>>>>>> novel because it is a mistake. Your mistake is
> > >>>>>>>>>>>>>>>>>>>>> to have the candidate program call into the
> > >>>>>>>>>>>>>>>>>>>>> SAME INSTANCE of the decider which is deciding
> > >>>>>>>>>>>>>>>>>>>>> the candidate program.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Where the Hell did you ever get this idea from
> > >>>>>>>>>>>>>>>>>>>> ? Whenever H simulates its input it creates a
> > >>>>>>>>>>>>>>>>>>>> whole new process context.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> You cannot make a direct function call into
> > >>>>>>>>>>>>>>>>>>> another process; it has to be the same process.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> As I have said very many hundreds of times I
> > >>>>>>>>>>>>>>>>>> created the x86utm operating system that enables
> > >>>>>>>>>>>>>>>>>> any C function to execute another C function
> > >>>>>>>>>>>>>>>>>> using an x86 emulator.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> In the case of H(P,P) H creates a separate
> > >>>>>>>>>>>>>>>>>> process context to simulate its input every time
> > >>>>>>>>>>>>>>>>>> that it is invoked, thus subsequent invocations
> > >>>>>>>>>>>>>>>>>> of H(P,P) execute in the process context that
> > >>>>>>>>>>>>>>>>>> was previously created.
> > >>>>>>>>>>>>>>>>>>> As far as getting ideas as to what you are
> > >>>>>>>>>>>>>>>>>>> actually doing: publish all your source so we
> > >>>>>>>>>>>>>>>>>>> can see for ourselves so we don't have to guess.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> /Flibble
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> That would be 100,000-fold more complex then
> > >>>>>>>>>>>>>>>>>> simply paying complete attention to what I am
> > >>>>>>>>>>>>>>>>>> saying. Everyone that is not bright enough to
> > >>>>>>>>>>>>>>>>>> understand 14 lines of code keeps saying that
> > >>>>>>>>>>>>>>>>>> they could easily understand 250 pages of code,
> > >>>>>>>>>>>>>>>>>> even though the 14 lines proves to be too much
> > >>>>>>>>>>>>>>>>>> for them.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Your code:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> call 000011a2 // call H
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> is simply a function call into the address space
> > >>>>>>>>>>>>>>>>> of the current process, it doesn't look like code
> > >>>>>>>>>>>>>>>>> to spawn a new process to me.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> How many times do I have to say this before you
> > >>>>>>>>>>>>>>>> notice that I said it at least once? H (in the
> > >>>>>>>>>>>>>>>> current process) always creates a new process
> > >>>>>>>>>>>>>>>> context to emulate its its input with an x86
> > >>>>>>>>>>>>>>>> emulator.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I will have to take your word for it as you refuse
> > >>>>>>>>>>>>>>> to publish source code. Why not just stick your
> > >>>>>>>>>>>>>>> project on GitHub? Open source is de rigueur these
> > >>>>>>>>>>>>>>> days. What are you trying to hide?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> If a new process context is made then how is nested
> > >>>>>>>>>>>>>>> simulation detected? I assume the data segment of
> > >>>>>>>>>>>>>>> each process is private...
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> /Flibble
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> An honest dialogue requires points of mutual
> > >>>>>>>>>>>>>> agreement. The price of moving beyond H(P,P)==0 is
> > >>>>>>>>>>>>>> universal agreement that H(P,P)==0 is correct. The
> > >>>>>>>>>>>>>> next point beyond H(P,P)==0 is computer science thus
> > >>>>>>>>>>>>>> not appropriate for the C/C++ forum.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I agree that H(P,P)==0 for pathological input assuming
> > >>>>>>>>>>>>> your method for detecting pathological input is
> > >>>>>>>>>>>>> sufficiently robust however how is that distinguished
> > >>>>>>>>>>>>> from H(P1,P1)==0 where P1 is normal non-halting (i.e.
> > >>>>>>>>>>>>> non-pathological)?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> When-so-ever the correct and complete emulation of the
> > >>>>>>>>>>>> input to H would never stop running H(x,y)==0 is
> > >>>>>>>>>>>> correct.
> > >>>>>>>>>>>>> If you are pattern matching op codes "EB FE" to detect
> > >>>>>>>>>>>>> the infinite loop then how do you solve the problem of
> > >>>>>>>>>>>>> there being 2^n different patterns equivalent to that
> > >>>>>>>>>>>>> loop so someone could come along and write a
> > >>>>>>>>>>>>> pathological program that defeats your pattern
> > >>>>>>>>>>>>> matcher? This is why we need your source code to
> > >>>>>>>>>>>>> answer these kinds of questions.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> /Flibble
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> To refute all of the HP conventional proofs only
> > >>>>>>>>>>>> requires correctly determining that H(P,P)==0.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Are you using pattern matching to detect the infinite
> > >>>>>>>>>>> loop or not?
> > >>>>>>>>>>>
> > >>>>>>>>>>> /Flibble
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Even if H(P,P) simply makes a wild guess that its input
> > >>>>>>>>>> never halts H(P,P)==0 is correct because the correct and
> > >>>>>>>>>> complete x86 emulation of this input would never stop
> > >>>>>>>>>> running.
> > >>>>>>>>>
> > >>>>>>>>> How do you KNOW it would never stop running? Given
> > >>>>>>>>>
> > >>>>>>>>> void P(u32 x)
> > >>>>>>>>> {
> > >>>>>>>>> if (H(x, x))
> > >>>>>>>>> FUBAR(); // a disguised infinite loop
> > >>>>>>>>> return;
> > >>>>>>>>> }
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> It never gets to FUBAR()
> > >>>>>>>
> > >>>>>>> This is your second reply to my post, your first reply said
> > >>>>>>> it "looks inside" FUBAR so you are contradicting yourself.
> > >>>>>>>
> > >>>>>>> /Flibble
> > >>>>>>
> > >>>>>> Yes I realized that I was incorrect and corrected my
> > >>>>>> mistake.
> > >>>>>
> > >>>>> So you are now saying that it is merely the detection of the
> > >>>>> nested simulation upon which you evaluate H and not what P
> > >>>>> does after it invokes H?
> > >>>>>
> > >>>>
> > >>>> That really should have been obvious hundreds of messages ago.
> > >>>> If a function gets stuck in infinitely nested simulation it
> > >>>> never proceeds to any point after this infinitely nested
> > >>>> simulation.
> > >>>
> > >>> OK, in which case answer my second part which you conveniently
> > >>> ignored:
> > >>
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >> H never gets to the second part. H is stuck in the first part.
> > >>
> > >
> > > Rather than getting angry try reading what I wrote again: P would
> > > have HALTED:
> > >
> > >>
> > >>> Given H doesn't care what P does after P invokes H then, given
> > >>>
> > >>> void P(u32 x)
> > >>> {
> > >>> if (H(x, x))
> > >>> FUBAR2(); // a disguised halting function
> > >>> return;
> > >>> }
> > >>>
> > >>> int main()
> > >>> {
> > >>> Output("Input_Halts = ", H((u32)P, (u32)P));
> > >>> }
> > >>>
> > >>> How do you evaluate H(P,P)=1? FUBAR2 can be any code that halts.
> > >>>
> > >
> > > /Flibble
> > >
> >
> > How do you evaluate H(P,P)=1?
> > How do you evalulate that a dog is a cat?
> > You don't a dog is not a cat.
>
> What the fuck are you talking about? P now halts it only gets
> stuck "in the first part" when using your erroneous simulation-based
> non-decider.

On 07/06/2022 21:51, Mr Flibble wrote:
> On Tue, 7 Jun 2022 15:34:13 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
<..snip..>
>>
>> How many times do I have to say this before you notice that I said it
>> at least once? H (in the current process) always creates a new
>> process context to emulate its its input with an x86 emulator.
>
> I will have to take your word for it as you refuse to publish source
> code. Why not just stick your project on GitHub? Open source is de
> rigueur these days. What are you trying to hide?
>
> If a new process context is made then how is nested simulation
> detected?

The code in x86utm.exe (his emulator) that emulates individual instructions also updates a global
trace table, making it accessible to the emulated code. So every instruction and any (nested,
nested(nested) etc.) simulated instructions ALL get merged together in this one global trace.

I imagine the global trace table to be much like the printed traces that PO posts over and over. If
YOU can recognise some pattern in those printed traces, then logically H can spot that same pattern
in the global trace, as the info in both cases is more or less the same.

[Above is my best guess, based on previous PO answers before you were interested.]

> I assume the data segment of each process is private...

PO said "new process context.." and that would imply each has its own address space, and that is
obviously how simulation is SUPPOSED to work (like a TM would perform) - so your assumption is
totally reasonable! But you've made the basic mistake of assuming PO knows what a "process" is -
PO is not a software engineer or computer scientist, although he does his utmost to give that
impression!

Anyhow, each PO-simulation is like a single-stepped thread within a SINGLE shared address space, so
any globals in his H are shared by all his "independent" simulations.

[Above is based on previous PO answers before you were interested.]

Mike.

On Wed, 8 Jun 2022 01:02:40 +0100
Mr Flibble <flibble@reddwarf.jmc> wrote:

> On Wed, 8 Jun 2022 00:50:11 +0100
> Mr Flibble <flibble@reddwarf.jmc> wrote:
>
> > On Tue, 7 Jun 2022 18:42:36 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> > > On 6/7/2022 6:37 PM, Mr Flibble wrote:
> > > > On Tue, 7 Jun 2022 18:35:22 -0500
> > > > olcott <NoOne@NoWhere.com> wrote:
> > > >
> > > >> On 6/7/2022 6:31 PM, Mr Flibble wrote:
> > > >>> On Tue, 7 Jun 2022 18:28:27 -0500
> > > >>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>
> > > >>>> On 6/7/2022 6:17 PM, Mr Flibble wrote:
> > > >>>>> On Tue, 7 Jun 2022 18:14:01 -0500
> > > >>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>
> > > >>>>>> On 6/7/2022 6:04 PM, Mr Flibble wrote:
> > > >>>>>>> On Tue, 7 Jun 2022 18:01:25 -0500
> > > >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>
> > > >>>>>>>> On 6/7/2022 5:45 PM, Mr Flibble wrote:
> > > >>>>>>>>> On Tue, 7 Jun 2022 17:37:44 -0500
> > > >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> On 6/7/2022 5:08 PM, Mr Flibble wrote:
> > > >>>>>>>>>>> On Tue, 7 Jun 2022 16:28:21 -0500
> > > >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On 6/7/2022 4:22 PM, Mr Flibble wrote:
> > > >>>>>>>>>>>>> On Tue, 7 Jun 2022 16:01:53 -0500
> > > >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On 6/7/2022 3:51 PM, Mr Flibble wrote:
> > > >>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:34:13 -0500
> > > >>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On 6/7/2022 3:18 PM, Mr Flibble wrote:
> > > >>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:14:30 -0500
> > > >>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On 6/7/2022 3:06 PM, Mr Flibble wrote:
> > > >>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:01:13 -0500
> > > >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:49 PM, Mr Flibble wrote:
> > > >>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 14:09:14 -0500
> > > >>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:02 PM, Mr Flibble wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 14:02:08 -0500
> > > >>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 1:41 PM, Mr Flibble wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 13:19:15 -0500
> > > >>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 12:50 PM, Mr Flibble wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 11:57:57 -0500
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 11:45 AM, Mr Flibble
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 20:13:01 -0500
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 7:56 PM, Richard Damon
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/22 8:27 PM, olcott wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:59 PM, Mike Terry
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 22:59, Jeff
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Barnett wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 2:07 PM, Mike Terry
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 16:16, Alan
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mike Terry
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <news.dead.person.stones@darjeeling.plus.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 13:14, Alan
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@nowhere.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:12 AM, Alan
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <NoOne@nowhere.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 5:14 AM,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mikko wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2022-06-04 19:28:19
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +0000, olcott said:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A Turing machine is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said to halt whenever
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it reaches a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configuration for
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which δ is not
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined; this is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible because δ is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial function.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In fact, we will
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assume that no
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> transitions are
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined for any final
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state so the Turing
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine will halt
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whenever it enters a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Introduction to Formal
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Languages and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Automata.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C. Heath and Company.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When translated into
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ordinary software
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineering terms this
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> means terminated
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally. In a C
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function this means
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret"
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The best equivalent to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "not defined" is not
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "ret". Instead, "not
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined" should include
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at least:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - HLT or any other
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction that means
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'halt'
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any undefined op code
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any return or pop
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction if the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stack is empty
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - an instruction fetch
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from a location that is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not specifiec by the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program That way the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> analogy to Linz'
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition is much
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> better.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mikko
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reaching a final state
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is merely the Turing
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine way of saying
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> terminated normally.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "ret" is the C way of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> saying the same thing.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sophistry.  What would be
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the turing machine
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> equivalent of an
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "abnormal termination"
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in C?
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> An aborted simulation.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's no such thing on a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine. It either
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> runs and halts, or it runs
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> forever.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your aborted simulation is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just one final state of a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine, which has
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thus halted.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A TM "aborting" a simulation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is just the TM ceasing to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate computation steps
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for some computation, and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> going on to calculate
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead. It
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not mean: a) that the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM (doing the simulation)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has halted b) that the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation halts
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c) that the simulated
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation never halts
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK.  I've a feeling we're
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> talking more about nice
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> shades of words than
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computer science here, but
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ....
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the simulation is the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entire turing machine,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborting it will bring the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM to a halt state.  If that
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation is merely part of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TM, then the word "halt"
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has a different meaning when
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applied to that simulation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> part from when applied to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the entire TM. I'm not even
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sure what you mean when you
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> say a part of a TM has
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted or not halted.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We are clearly talking at
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cross purposes
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - I never talked about /part/
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of a TM halting, and like you,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can't work out what that
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would mean!  I used "halt"
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only with respect to a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation, meaning that the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation halts [there is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an n such that computation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> step n is a TM final state].
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reading what you say very
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> carefully, I think that by
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your definition of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation, the simulating TM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> must be a "pure" simulator
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that does nothing but
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate computation steps
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> until the simulation halts,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at which point the simulating
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM halts (like a UTM). I get
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that with that interpretation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what you said:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >>> Your
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted simulation is just one
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state of a turing
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine, >>> which has thus
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   makes sense
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and is correct. I'd just say
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think that usage of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "simulation" is very useful,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and is DEFINITELY not what PO
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is talking about (so it would
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be wrong if applied PO's
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> posts...)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My use of "simulation" is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> broader: it's simply the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> activity performed by a TM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which consists of calculating
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps of some
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> given computation.  As such
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it's just a part of the TM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> logic. A TM's typical use of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation might be something
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> like "..the TM simulates the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation for n steps, and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if the simulation halts
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> during those n steps, the TM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [blah blah], /otherwise/ the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM [blah blah blah]...". Just
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about every reference in the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> literature I can recall is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something like that.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So... to be 100% clear on
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what I said:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >> A TM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "aborting" a simulation is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just the TM ceasing to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate >> computation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> steps for some computation,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and going on to calculate
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> E.g. in PO's P, after P aborts
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation of P(P), the TM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> either halts or enters an
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop. (That logic is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not part of the simulation,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IMO.) >> It does *NOT* mean:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> a)  that the TM (doing the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation) has halted
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously, because now P has
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gone on to something else...
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> b)  that the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation halts >>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c) that the simulated
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation never halts
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously - in general
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different exacmples of a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation P(I)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might halt or never halt, and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this is unaffected by a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator's decision to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate no further
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps. [The TM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> may have spotted some pattern
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the simulated computation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which implies P(I) never
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts - that is a separate
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> matter, but for sure the mere
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> act of "aborting" the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation doesn't imply P(I)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never halts, or imply that it
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts...
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Put yet another way, when a TM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops calculating TM steps
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (aka aborts its simulation),
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> NOTHING HALTS: not the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating TM, not the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation, and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> NOT ANY PART OF EITHER OF
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THOSE. (Like you say, what
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would part of a TM halting
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean?)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think of a TM and an input
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> string as defining a sequence
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (an ordered list). The elements
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the sequence are pairs of a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM state name and a string
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> representing the "tape"
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> contents when the state was
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entered. Note that this view
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has no character of animation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in it and makes the definition
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the halt predicate (H)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trivial:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(TM,STRING) = If length of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM(STRING) is finite then TRUE
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> else FALSE.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, that's equivalent to what I
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said (or at least meant). Your
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence is my computation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> steps. Formally, these would be
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined inductively via the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rule to go from step n to step
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> n+1. (Not an animation, but the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> induction gives some /sense/ of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> step-by-step calculation, and a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator will follow this,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> starting at step 1, then
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate step 2 and so on.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Still, I agree the entire
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence [the "computation"]
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exists as one timeless
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> structure.  Too abstract for
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PO...)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words when we make sure
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to conflate the program under
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test with the test program as a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> single computation then the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whole idea of a halt decider
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> becomes less coherent and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this can be used as an excuse to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pretend that you don't already
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> know that H(P,P)==0 is correct
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and the H/P relationship matches
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the halting problem counter
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> example template.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    if (H(x, x))
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      HERE: goto
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE; return;
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    Output("Input_Halts
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H((u32)P, (u32)P)); }
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       For any
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program H that might determine if
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs halt, a "pathological"
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program P, called with some
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input, can pass its own source
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and its input to H and then
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifically do the opposite of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what H predicts P will do. No H
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can exist that handles this case.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A simulator animates the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> production of the sequence and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that causes some difficulties
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the same way that
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> elaborating an infinite sum or
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence does in math classes.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> An (ultimate) value only
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exists if there is some
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> notation of convergence or
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit which typically is the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case with examples used in a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> math class. There is no
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of convergence or
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit with the sequence
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined by TM(STRING); rather,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we simply ask about the last
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pair if the sequence is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> finite.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sure.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The question right now is what
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you would call a TM which
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> evaluates the first 10 steps of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a computation, and then does
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else. What is it doing
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> while evaluating those 10 steps?
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tl;dr : who cares :)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My terminology would be that
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it's "simulating" the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation (just for 10 steps)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - then it stops simulating and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does something else. Obviously
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I wouldn't describe it as
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "correctly" simulating, because
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nobody considers incorrect
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulations, so the word would
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be redundant!
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is required because my
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are making their best
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible effort to form
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rebuttals and the most
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> persistent of the fake rebuttals
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has been that the simulation is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect. It is very easy to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verify the correct x86 emulation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on the basis of the x86
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Except that it doesn't. By
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION, a correct simulation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs show the same behavior of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the thing it is simulating.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Members of comp.c and comp.c++ this
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> goofy idiot is trying to claim that
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it is utterly impossible to create
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a C program that examines the x86
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution trace derived from
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating the input to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H0(Infinite_Loop) with an x86
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator to correctly determine
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that Infinite_Loop() infinitely
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loops.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H0(Infinite_Loop)); }
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342](01) 55
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001343](02) 8bec
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001345](02) ebfe
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 [00001347](01) 5d
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pop ebp [00001348](01) c3
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0007) [00001348]
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored at:212343
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342][00212333][00212337] 55
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 Local Halt Decider:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinite Loop Detected Simulation
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stopped
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> But he isn't doing that; the issue
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not the infinite loop but the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> logic used to decide to enter the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop. Post *full* traces.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are unable to tell
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> that _Infinite_Loop() contains an
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Again that isn't the issue; the issue
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> is the logic used to decide when to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> enter the infinite loop;
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> In other words when H0(Infinite_Loop)
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> is invoked we have no idea that a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> correct x86 emulation of Infinite_Loop
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> would reach the instruction at machine
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> address [00001345] or not.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> It might be the case that a correct x86
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> emulation of Infinite_Loop might
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> instead involve emulating an entirely
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> different function that plays
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> tic-tac-toe?
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> Detecting an infinite loop is indeed
> > > >>>>>>>>>>>>>>>>>>>>>>>>> trivial however your program and trace
> > > >>>>>>>>>>>>>>>>>>>>>>>>> are not telling the full story as far as
> > > >>>>>>>>>>>>>>>>>>>>>>>>> the HP proofs are concerned;
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> The only thing that my program trace
> > > >>>>>>>>>>>>>>>>>>>>>>>> conclusively proves is that H(P,P)==0 is
> > > >>>>>>>>>>>>>>>>>>>>>>>> the correct return value that does
> > > >>>>>>>>>>>>>>>>>>>>>>>> correctly correspond to the actual
> > > >>>>>>>>>>>>>>>>>>>>>>>> behavior of the actual input.
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> For any program H that
> > > >>>>>>>>>>>>>>>>>>>>>>>> might determine if programs halt, a
> > > >>>>>>>>>>>>>>>>>>>>>>>> "pathological" program P, called with
> > > >>>>>>>>>>>>>>>>>>>>>>>> some input, can pass its own source and
> > > >>>>>>>>>>>>>>>>>>>>>>>> its input to H and then specifically do
> > > >>>>>>>>>>>>>>>>>>>>>>>> the opposite of what H predicts P will
> > > >>>>>>>>>>>>>>>>>>>>>>>> do. No H can exist that handles
> > > >>>>>>>>>>>>>>>>>>>>>>>> this case.
> > > >>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> > > >>>>>>>>>>>>>>>>>>>>>>>> {
> > > >>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> > > >>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> > > >>>>>>>>>>>>>>>>>>>>>>>> return;
> > > >>>>>>>>>>>>>>>>>>>>>>>> }
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> int main()
> > > >>>>>>>>>>>>>>>>>>>>>>>> {
> > > >>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ",
> > > >>>>>>>>>>>>>>>>>>>>>>>> H((u32)P, (u32)P)); }
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> _P()
> > > >>>>>>>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
> > > >>>>>>>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov
> > > >>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [00001355](03) 8b4508
> > > >>>>>>>>>>>>>>>>>>>>>>>> mov eax,[ebp+08] [00001358](01) 50
> > > >>>>>>>>>>>>>>>>>>>>>>>> push eax // push P [00001359](03)
> > > >>>>>>>>>>>>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08] [0000135c](01)
> > > >>>>>>>>>>>>>>>>>>>>>>>> 51 push ecx // push P
> > > >>>>>>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2
> > > >>>>>>>>>>>>>>>>>>>>>>>> // call H [00001362](03) 83c408 add
> > > >>>>>>>>>>>>>>>>>>>>>>>> esp,+08 [00001365](02) 85c0 test eax,eax
> > > >>>>>>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz
> > > >>>>>>>>>>>>>>>>>>>>>>>> 0000136b [00001369](02) ebfe
> > > >>>>>>>>>>>>>>>>>>>>>>>> jmp 00001369 [0000136b](01) 5d
> > > >>>>>>>>>>>>>>>>>>>>>>>> pop ebp [0000136c](01) c3
> > > >>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0027) [0000136c]
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P)
> > > >>>>>>>>>>>>>>>>>>>>>>>> correctly emulates its input that it must
> > > >>>>>>>>>>>>>>>>>>>>>>>> emulate the first seven instructions of
> > > >>>>>>>>>>>>>>>>>>>>>>>> P. Because the seventh instruction of P
> > > >>>>>>>>>>>>>>>>>>>>>>>> repeats this process we can know with
> > > >>>>>>>>>>>>>>>>>>>>>>>> complete certainty that the emulated P
> > > >>>>>>>>>>>>>>>>>>>>>>>> never reaches its final “ret”
> > > >>>>>>>>>>>>>>>>>>>>>>>> instruction, thus never halts.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> But the halting problem proofs (including
> > > >>>>>>>>>>>>>>>>>>>>>>> [Strachey 1965]) that you are trying to
> > > >>>>>>>>>>>>>>>>>>>>>>> refute don't do that, they DO NOT make any
> > > >>>>>>>>>>>>>>>>>>>>>>> recursive calls
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> Because the idea of a simulating halt
> > > >>>>>>>>>>>>>>>>>>>>>> decider being applied to the halting
> > > >>>>>>>>>>>>>>>>>>>>>> problem counter-example is brand new with
> > > >>>>>>>>>>>>>>>>>>>>>> me you won't find other references that
> > > >>>>>>>>>>>>>>>>>>>>>> refer to "infinitely nested simulation".
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> which is what you are doing with "call H"
> > > >>>>>>>>>>>>>>>>>>>>>>> above. Why are you doing something
> > > >>>>>>>>>>>>>>>>>>>>>>> different to what the proofs you are
> > > >>>>>>>>>>>>>>>>>>>>>>> trying to refute do given doing so is no
> > > >>>>>>>>>>>>>>>>>>>>>>> longer related to the Halting Problem?
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> /Flibble
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> The proofs never bothered to examine my
> > > >>>>>>>>>>>>>>>>>>>>>> idea because it was unknown by everyone
> > > >>>>>>>>>>>>>>>>>>>>>> prior to me creating it in 2016.
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> It seems to me that your idea would only be
> > > >>>>>>>>>>>>>>>>>>>>> novel because it is a mistake. Your mistake
> > > >>>>>>>>>>>>>>>>>>>>> is to have the candidate program call into
> > > >>>>>>>>>>>>>>>>>>>>> the SAME INSTANCE of the decider which is
> > > >>>>>>>>>>>>>>>>>>>>> deciding the candidate program.
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Where the Hell did you ever get this idea
> > > >>>>>>>>>>>>>>>>>>>> from ? Whenever H simulates its input it
> > > >>>>>>>>>>>>>>>>>>>> creates a whole new process context.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> You cannot make a direct function call into
> > > >>>>>>>>>>>>>>>>>>> another process; it has to be the same
> > > >>>>>>>>>>>>>>>>>>> process.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> As I have said very many hundreds of times I
> > > >>>>>>>>>>>>>>>>>> created the x86utm operating system that
> > > >>>>>>>>>>>>>>>>>> enables any C function to execute another C
> > > >>>>>>>>>>>>>>>>>> function using an x86 emulator.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> In the case of H(P,P) H creates a separate
> > > >>>>>>>>>>>>>>>>>> process context to simulate its input every
> > > >>>>>>>>>>>>>>>>>> time that it is invoked, thus subsequent
> > > >>>>>>>>>>>>>>>>>> invocations of H(P,P) execute in the process
> > > >>>>>>>>>>>>>>>>>> context that was previously created.
> > > >>>>>>>>>>>>>>>>>>> As far as getting ideas as to what you are
> > > >>>>>>>>>>>>>>>>>>> actually doing: publish all your source so we
> > > >>>>>>>>>>>>>>>>>>> can see for ourselves so we don't have to
> > > >>>>>>>>>>>>>>>>>>> guess.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> /Flibble
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> That would be 100,000-fold more complex then
> > > >>>>>>>>>>>>>>>>>> simply paying complete attention to what I am
> > > >>>>>>>>>>>>>>>>>> saying. Everyone that is not bright enough to
> > > >>>>>>>>>>>>>>>>>> understand 14 lines of code keeps saying that
> > > >>>>>>>>>>>>>>>>>> they could easily understand 250 pages of code,
> > > >>>>>>>>>>>>>>>>>> even though the 14 lines proves to be too much
> > > >>>>>>>>>>>>>>>>>> for them.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Your code:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> call 000011a2 // call H
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> is simply a function call into the address space
> > > >>>>>>>>>>>>>>>>> of the current process, it doesn't look like
> > > >>>>>>>>>>>>>>>>> code to spawn a new process to me.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> How many times do I have to say this before you
> > > >>>>>>>>>>>>>>>> notice that I said it at least once? H (in the
> > > >>>>>>>>>>>>>>>> current process) always creates a new process
> > > >>>>>>>>>>>>>>>> context to emulate its its input with an x86
> > > >>>>>>>>>>>>>>>> emulator.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I will have to take your word for it as you refuse
> > > >>>>>>>>>>>>>>> to publish source code. Why not just stick your
> > > >>>>>>>>>>>>>>> project on GitHub? Open source is de rigueur these
> > > >>>>>>>>>>>>>>> days. What are you trying to hide?
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> If a new process context is made then how is
> > > >>>>>>>>>>>>>>> nested simulation detected? I assume the data
> > > >>>>>>>>>>>>>>> segment of each process is private...
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> /Flibble
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> An honest dialogue requires points of mutual
> > > >>>>>>>>>>>>>> agreement. The price of moving beyond H(P,P)==0 is
> > > >>>>>>>>>>>>>> universal agreement that H(P,P)==0 is correct. The
> > > >>>>>>>>>>>>>> next point beyond H(P,P)==0 is computer science
> > > >>>>>>>>>>>>>> thus not appropriate for the C/C++ forum.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I agree that H(P,P)==0 for pathological input
> > > >>>>>>>>>>>>> assuming your method for detecting pathological
> > > >>>>>>>>>>>>> input is sufficiently robust however how is that
> > > >>>>>>>>>>>>> distinguished from H(P1,P1)==0 where P1 is normal
> > > >>>>>>>>>>>>> non-halting (i.e. non-pathological)?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> When-so-ever the correct and complete emulation of
> > > >>>>>>>>>>>> the input to H would never stop running H(x,y)==0 is
> > > >>>>>>>>>>>> correct.
> > > >>>>>>>>>>>>> If you are pattern matching op codes "EB FE" to
> > > >>>>>>>>>>>>> detect the infinite loop then how do you solve the
> > > >>>>>>>>>>>>> problem of there being 2^n different patterns
> > > >>>>>>>>>>>>> equivalent to that loop so someone could come along
> > > >>>>>>>>>>>>> and write a pathological program that defeats your
> > > >>>>>>>>>>>>> pattern matcher? This is why we need your source
> > > >>>>>>>>>>>>> code to answer these kinds of questions.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> /Flibble
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> To refute all of the HP conventional proofs only
> > > >>>>>>>>>>>> requires correctly determining that H(P,P)==0.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Are you using pattern matching to detect the infinite
> > > >>>>>>>>>>> loop or not?
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> /Flibble
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Even if H(P,P) simply makes a wild guess that its input
> > > >>>>>>>>>> never halts H(P,P)==0 is correct because the correct
> > > >>>>>>>>>> and complete x86 emulation of this input would never
> > > >>>>>>>>>> stop running.
> > > >>>>>>>>>
> > > >>>>>>>>> How do you KNOW it would never stop running? Given
> > > >>>>>>>>>
> > > >>>>>>>>> void P(u32 x)
> > > >>>>>>>>> {
> > > >>>>>>>>> if (H(x, x))
> > > >>>>>>>>> FUBAR(); // a disguised infinite loop
> > > >>>>>>>>> return;
> > > >>>>>>>>> }
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> It never gets to FUBAR()
> > > >>>>>>>
> > > >>>>>>> This is your second reply to my post, your first reply
> > > >>>>>>> said it "looks inside" FUBAR so you are contradicting
> > > >>>>>>> yourself.
> > > >>>>>>>
> > > >>>>>>> /Flibble
> > > >>>>>>
> > > >>>>>> Yes I realized that I was incorrect and corrected my
> > > >>>>>> mistake.
> > > >>>>>
> > > >>>>> So you are now saying that it is merely the detection of the
> > > >>>>> nested simulation upon which you evaluate H and not what P
> > > >>>>> does after it invokes H?
> > > >>>>>
> > > >>>>
> > > >>>> That really should have been obvious hundreds of messages
> > > >>>> ago. If a function gets stuck in infinitely nested
> > > >>>> simulation it never proceeds to any point after this
> > > >>>> infinitely nested simulation.
> > > >>>
> > > >>> OK, in which case answer my second part which you conveniently
> > > >>> ignored:
> > > >>
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >> H never gets to the second part. H is stuck in the first part.
> > > >>
> > > >
> > > > Rather than getting angry try reading what I wrote again: P
> > > > would have HALTED:
> > > >
> > > >>
> > > >>> Given H doesn't care what P does after P invokes H then, given
> > > >>>
> > > >>> void P(u32 x)
> > > >>> {
> > > >>> if (H(x, x))
> > > >>> FUBAR2(); // a disguised halting function
> > > >>> return;
> > > >>> }
> > > >>>
> > > >>> int main()
> > > >>> {
> > > >>> Output("Input_Halts = ", H((u32)P, (u32)P));
> > > >>> }
> > > >>>
> > > >>> How do you evaluate H(P,P)=1? FUBAR2 can be any code that
> > > >>> halts.
> > > >
> > > > /Flibble
> > > >
> > >
> > > How do you evaluate H(P,P)=1?
> > > How do you evalulate that a dog is a cat?
> > > You don't a dog is not a cat.
> >
> > What the fuck are you talking about? P now halts it only gets
> > stuck "in the first part" when using your erroneous simulation-based
> > non-decider.
>
> If your brain can't cope with me redefining what P is try this:
>
> Given H doesn't care what P1 does after P1 invokes H then, given
>
> void P1(u32 x)
> {
> if (H(x, x))
> FUBAR2(); // a disguised halting function
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P1, (u32)P1));
> }
>
> How do you evaluate H(P1,P1)=1? FUBAR2 can be any code that halts.

On 6/7/2022 7:02 PM, Mr Flibble wrote:
> On Wed, 8 Jun 2022 00:50:11 +0100
> Mr Flibble <flibble@reddwarf.jmc> wrote:
>
>> On Tue, 7 Jun 2022 18:42:36 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/7/2022 6:37 PM, Mr Flibble wrote:
>>>> On Tue, 7 Jun 2022 18:35:22 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 6/7/2022 6:31 PM, Mr Flibble wrote:
>>>>>> On Tue, 7 Jun 2022 18:28:27 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>
>>>>>>> On 6/7/2022 6:17 PM, Mr Flibble wrote:
>>>>>>>> On Tue, 7 Jun 2022 18:14:01 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> On 6/7/2022 6:04 PM, Mr Flibble wrote:
>>>>>>>>>> On Tue, 7 Jun 2022 18:01:25 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 6/7/2022 5:45 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Tue, 7 Jun 2022 17:37:44 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/7/2022 5:08 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Tue, 7 Jun 2022 16:28:21 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 6/7/2022 4:22 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 16:01:53 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 6/7/2022 3:51 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:34:13 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 6/7/2022 3:18 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:14:30 -0500
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 3:06 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:01:13 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:49 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 14:09:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 14:02:08 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 1:41 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 13:19:15 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 12:50 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 11:57:57 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 11:45 AM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 20:13:01 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 7:56 PM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/22 8:27 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:59 PM, Mike Terry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 22:59, Jeff Barnett
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 2:07 PM, Mike Terry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 16:16, Alan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mike Terry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <news.dead.person.stones@darjeeling.plus.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 13:14, Alan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@nowhere.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:12 AM, Alan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@nowhere.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 5:14 AM, Mikko
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2022-06-04 19:28:19
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A Turing machine is said
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to halt whenever it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches a configuration
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for which δ is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined; this is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible because δ is a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> partial function. In
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fact, we will assume
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that no transitions are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined for any final
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state so the Turing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine will halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whenever it enters a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Introduction to Formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Languages and Automata.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Heath and Company.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When translated into
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ordinary software
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineering terms this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> means terminated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally. In a C
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function this means
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The best equivalent to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "not defined" is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "ret". Instead, "not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined" should include
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at least:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - HLT or any other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction that means
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'halt'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any undefined op code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any return or pop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction if the stack
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is empty
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - an instruction fetch
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from a location that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not specifiec by the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program That way the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> analogy to Linz'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition is much
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> better.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mikko
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reaching a final state is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely the Turing machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way of saying terminated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally. "ret" is the C
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way of saying the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sophistry.  What would be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the turing machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> equivalent of an "abnormal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> termination" in C?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> An aborted simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's no such thing on a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine. It either
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> runs and halts, or it runs
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> forever.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your aborted simulation is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just one final state of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine, which has
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thus halted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A TM "aborting" a simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is just the TM ceasing to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate computation steps
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for some computation, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> going on to calculate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead. It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not mean: a) that the TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (doing the simulation) has
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted b) that the simulated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation halts c) that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK.  I've a feeling we're
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> talking more about nice shades
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of words than computer science
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here, but ....
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the simulation is the entire
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine, aborting it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will bring the TM to a halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state.  If that simulation is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely part of the TM, then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the word "halt" has a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different meaning when applied
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that simulation part from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when applied to the entire TM.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm not even sure what you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean when you say a part of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM has halted or not halted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We are clearly talking at cross
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> purposes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - I never talked about /part/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of a TM halting, and like you,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can't work out what that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would mean!  I used "halt" only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with respect to a computation,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> meaning that the computation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts [there is an n such that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation step n is a TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state].
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reading what you say very
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> carefully, I think that by your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of simulation, the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating TM must be a "pure"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator that does nothing but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate computation steps until
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation halts, at which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point the simulating TM halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (like a UTM). I get that with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that interpretation what you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >>> Your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted simulation is just one
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state of a turing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine, >>> which has thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   makes sense and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is correct. I'd just say I don't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> think that usage of "simulation"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is very useful, and is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITELY not what PO is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> talking about (so it would be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong if applied PO's posts...)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My use of "simulation" is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> broader: it's simply the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> activity performed by a TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which consists of calculating
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps of some given
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation.  As such it's just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a part of the TM logic. A TM's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typical use of simulation might
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be something like "..the TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates the computation for n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> steps, and if the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts during those n steps, the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM [blah blah], /otherwise/ the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM [blah blah blah]...". Just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about every reference in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> literature I can recall is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something like that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So... to be 100% clear on what I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >> A TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "aborting" a simulation is just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TM ceasing to calculate >>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps for some
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation, and going on to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> E.g. in PO's P, after P aborts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation of P(P), the TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> either halts or enters an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop. (That logic is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not part of the simulation,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IMO.) >> It does *NOT* mean: >>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a)  that the TM (doing the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation) has halted
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously, because now P has
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gone on to something else...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >> b)  that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation halts >>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c) that the simulated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation never halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously - in general different
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exacmples of a simulated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation P(I) might halt or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never halt, and this is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unaffected by a simulator's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decision to simulate no further
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps. [The TM may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have spotted some pattern in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implies P(I) never halts - that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is a separate matter, but for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sure the mere act of "aborting"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation doesn't imply
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(I) never halts, or imply that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it halts...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Put yet another way, when a TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops calculating TM steps (aka
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborts its simulation), NOTHING
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HALTS: not the simulating TM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not the simulated computation,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and NOT ANY PART OF EITHER OF
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THOSE. (Like you say, what
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would part of a TM halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean?)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think of a TM and an input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> string as defining a sequence
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (an ordered list). The elements
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the sequence are pairs of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM state name and a string
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> representing the "tape" contents
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when the state was entered. Note
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that this view has no character
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of animation in it and makes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of the halt predicate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (H) trivial:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(TM,STRING) = If length of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM(STRING) is finite then TRUE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> else FALSE.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, that's equivalent to what I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said (or at least meant). Your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence is my computation steps.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Formally, these would be defined
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inductively via the rule to go
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from step n to step n+1. (Not an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> animation, but the induction gives
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some /sense/ of step-by-step
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculation, and a simulator will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> follow this, starting at step 1,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> then calculate step 2 and so on.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Still, I agree the entire sequence
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [the "computation"] exists as one
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> timeless structure.  Too abstract
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for PO...)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words when we make sure to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> conflate the program under test
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the test program as a single
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation then the whole idea of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider becomes less
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> coherent and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this can be used as an excuse to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pretend that you don't already know
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0 is correct and the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H/P relationship matches the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halting problem counter example
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> template.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      HERE: goto
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE; return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    Output("Input_Halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H((u32)P, (u32)P)); }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       For any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program H that might determine if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs halt, a "pathological"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program P, called with some input,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can pass its own source and its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H and then specifically
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do the opposite of what H predicts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P will do. No H can exist that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> handles this case.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A simulator animates the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> production of the sequence and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that causes some difficulties in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same way that elaborating an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sum or sequence does in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> math classes. An (ultimate)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value only exists if there is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some notation of convergence or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit which typically is the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case with examples used in a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> math class. There is no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of convergence or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit with the sequence defined
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> by TM(STRING); rather, we simply
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ask about the last pair if the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence is finite.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sure.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The question right now is what you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would call a TM which evaluates
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the first 10 steps of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation, and then does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else. What is it doing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> while evaluating those 10 steps?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tl;dr : who cares :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My terminology would be that it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "simulating" the computation (just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for 10 steps) - then it stops
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating and does something
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> else. Obviously I wouldn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> describe it as "correctly"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating, because nobody
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> considers incorrect simulations,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> so the word would be redundant!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is required because my reviewers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are making their best possible
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> effort to form rebuttals and the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> most persistent of the fake
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rebuttals has been that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation is incorrect. It is very
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easy to verify the correct x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation on the basis of the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Except that it doesn't. By
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION, a correct simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs show the same behavior of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing it is simulating.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Members of comp.c and comp.c++ this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> goofy idiot is trying to claim that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it is utterly impossible to create a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C program that examines the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution trace derived from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating the input to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H0(Infinite_Loop) with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator to correctly determine that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinite_Loop() infinitely loops.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H0(Infinite_Loop)); }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342](01) 55 push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001343](02) 8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001345](02) ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 [00001347](01) 5d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pop ebp [00001348](01) c3
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0007) [00001348]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored at:212343
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342][00212333][00212337] 55
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 Local Halt Decider:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinite Loop Detected Simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But he isn't doing that; the issue is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not the infinite loop but the logic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used to decide to enter the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop. Post *full* traces.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are unable to tell
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that _Infinite_Loop() contains an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Again that isn't the issue; the issue is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the logic used to decide when to enter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the infinite loop;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words when H0(Infinite_Loop) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invoked we have no idea that a correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation of Infinite_Loop would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach the instruction at machine address
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345] or not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It might be the case that a correct x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of Infinite_Loop might instead
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> involve emulating an entirely different
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function that plays tic-tac-toe?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Detecting an infinite loop is indeed
>>>>>>>>>>>>>>>>>>>>>>>>>>>> trivial however your program and trace
>>>>>>>>>>>>>>>>>>>>>>>>>>>> are not telling the full story as far as
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the HP proofs are concerned;
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The only thing that my program trace
>>>>>>>>>>>>>>>>>>>>>>>>>>> conclusively proves is that H(P,P)==0 is
>>>>>>>>>>>>>>>>>>>>>>>>>>> the correct return value that does
>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly correspond to the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the actual input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> For any program H that
>>>>>>>>>>>>>>>>>>>>>>>>>>> might determine if programs halt, a
>>>>>>>>>>>>>>>>>>>>>>>>>>> "pathological" program P, called with some
>>>>>>>>>>>>>>>>>>>>>>>>>>> input, can pass its own source and its
>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H and then specifically do the
>>>>>>>>>>>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H
>>>>>>>>>>>>>>>>>>>>>>>>>>> can exist that handles
>>>>>>>>>>>>>>>>>>>>>>>>>>> this case.
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ",
>>>>>>>>>>>>>>>>>>>>>>>>>>> H((u32)P, (u32)P)); }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov
>>>>>>>>>>>>>>>>>>>>>>>>>>> eax,[ebp+08] [00001358](01) 50
>>>>>>>>>>>>>>>>>>>>>>>>>>> push eax // push P [00001359](03)
>>>>>>>>>>>>>>>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08] [0000135c](01) 51
>>>>>>>>>>>>>>>>>>>>>>>>>>> push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 //
>>>>>>>>>>>>>>>>>>>>>>>>>>> call H [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp
>>>>>>>>>>>>>>>>>>>>>>>>>>> 00001369 [0000136b](01) 5d
>>>>>>>>>>>>>>>>>>>>>>>>>>> pop ebp [0000136c](01) c3
>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly emulates its input that it must
>>>>>>>>>>>>>>>>>>>>>>>>>>> emulate the first seven instructions of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Because the seventh instruction of P
>>>>>>>>>>>>>>>>>>>>>>>>>>> repeats this process we can know with
>>>>>>>>>>>>>>>>>>>>>>>>>>> complete certainty that the emulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches its final “ret” instruction,
>>>>>>>>>>>>>>>>>>>>>>>>>>> thus never halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But the halting problem proofs (including
>>>>>>>>>>>>>>>>>>>>>>>>>> [Strachey 1965]) that you are trying to
>>>>>>>>>>>>>>>>>>>>>>>>>> refute don't do that, they DO NOT make any
>>>>>>>>>>>>>>>>>>>>>>>>>> recursive calls
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Because the idea of a simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>> being applied to the halting problem
>>>>>>>>>>>>>>>>>>>>>>>>> counter-example is brand new with me you
>>>>>>>>>>>>>>>>>>>>>>>>> won't find other references that refer to
>>>>>>>>>>>>>>>>>>>>>>>>> "infinitely nested simulation".
>>>>>>>>>>>>>>>>>>>>>>>>>> which is what you are doing with "call H"
>>>>>>>>>>>>>>>>>>>>>>>>>> above. Why are you doing something different
>>>>>>>>>>>>>>>>>>>>>>>>>> to what the proofs you are trying to refute
>>>>>>>>>>>>>>>>>>>>>>>>>> do given doing so is no longer related to
>>>>>>>>>>>>>>>>>>>>>>>>>> the Halting Problem?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The proofs never bothered to examine my idea
>>>>>>>>>>>>>>>>>>>>>>>>> because it was unknown by everyone prior to
>>>>>>>>>>>>>>>>>>>>>>>>> me creating it in 2016.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It seems to me that your idea would only be
>>>>>>>>>>>>>>>>>>>>>>>> novel because it is a mistake. Your mistake is
>>>>>>>>>>>>>>>>>>>>>>>> to have the candidate program call into the
>>>>>>>>>>>>>>>>>>>>>>>> SAME INSTANCE of the decider which is deciding
>>>>>>>>>>>>>>>>>>>>>>>> the candidate program.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Where the Hell did you ever get this idea from
>>>>>>>>>>>>>>>>>>>>>>> ? Whenever H simulates its input it creates a
>>>>>>>>>>>>>>>>>>>>>>> whole new process context.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You cannot make a direct function call into
>>>>>>>>>>>>>>>>>>>>>> another process; it has to be the same process.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> As I have said very many hundreds of times I
>>>>>>>>>>>>>>>>>>>>> created the x86utm operating system that enables
>>>>>>>>>>>>>>>>>>>>> any C function to execute another C function
>>>>>>>>>>>>>>>>>>>>> using an x86 emulator.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In the case of H(P,P) H creates a separate
>>>>>>>>>>>>>>>>>>>>> process context to simulate its input every time
>>>>>>>>>>>>>>>>>>>>> that it is invoked, thus subsequent invocations
>>>>>>>>>>>>>>>>>>>>> of H(P,P) execute in the process context that
>>>>>>>>>>>>>>>>>>>>> was previously created.
>>>>>>>>>>>>>>>>>>>>>> As far as getting ideas as to what you are
>>>>>>>>>>>>>>>>>>>>>> actually doing: publish all your source so we
>>>>>>>>>>>>>>>>>>>>>> can see for ourselves so we don't have to guess.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That would be 100,000-fold more complex then
>>>>>>>>>>>>>>>>>>>>> simply paying complete attention to what I am
>>>>>>>>>>>>>>>>>>>>> saying. Everyone that is not bright enough to
>>>>>>>>>>>>>>>>>>>>> understand 14 lines of code keeps saying that
>>>>>>>>>>>>>>>>>>>>> they could easily understand 250 pages of code,
>>>>>>>>>>>>>>>>>>>>> even though the 14 lines proves to be too much
>>>>>>>>>>>>>>>>>>>>> for them.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Your code:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> call 000011a2 // call H
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> is simply a function call into the address space
>>>>>>>>>>>>>>>>>>>> of the current process, it doesn't look like code
>>>>>>>>>>>>>>>>>>>> to spawn a new process to me.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> How many times do I have to say this before you
>>>>>>>>>>>>>>>>>>> notice that I said it at least once? H (in the
>>>>>>>>>>>>>>>>>>> current process) always creates a new process
>>>>>>>>>>>>>>>>>>> context to emulate its its input with an x86
>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I will have to take your word for it as you refuse
>>>>>>>>>>>>>>>>>> to publish source code. Why not just stick your
>>>>>>>>>>>>>>>>>> project on GitHub? Open source is de rigueur these
>>>>>>>>>>>>>>>>>> days. What are you trying to hide?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If a new process context is made then how is nested
>>>>>>>>>>>>>>>>>> simulation detected? I assume the data segment of
>>>>>>>>>>>>>>>>>> each process is private...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> An honest dialogue requires points of mutual
>>>>>>>>>>>>>>>>> agreement. The price of moving beyond H(P,P)==0 is
>>>>>>>>>>>>>>>>> universal agreement that H(P,P)==0 is correct. The
>>>>>>>>>>>>>>>>> next point beyond H(P,P)==0 is computer science thus
>>>>>>>>>>>>>>>>> not appropriate for the C/C++ forum.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I agree that H(P,P)==0 for pathological input assuming
>>>>>>>>>>>>>>>> your method for detecting pathological input is
>>>>>>>>>>>>>>>> sufficiently robust however how is that distinguished
>>>>>>>>>>>>>>>> from H(P1,P1)==0 where P1 is normal non-halting (i.e.
>>>>>>>>>>>>>>>> non-pathological)?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When-so-ever the correct and complete emulation of the
>>>>>>>>>>>>>>> input to H would never stop running H(x,y)==0 is
>>>>>>>>>>>>>>> correct.
>>>>>>>>>>>>>>>> If you are pattern matching op codes "EB FE" to detect
>>>>>>>>>>>>>>>> the infinite loop then how do you solve the problem of
>>>>>>>>>>>>>>>> there being 2^n different patterns equivalent to that
>>>>>>>>>>>>>>>> loop so someone could come along and write a
>>>>>>>>>>>>>>>> pathological program that defeats your pattern
>>>>>>>>>>>>>>>> matcher? This is why we need your source code to
>>>>>>>>>>>>>>>> answer these kinds of questions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To refute all of the HP conventional proofs only
>>>>>>>>>>>>>>> requires correctly determining that H(P,P)==0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you using pattern matching to detect the infinite
>>>>>>>>>>>>>> loop or not?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Even if H(P,P) simply makes a wild guess that its input
>>>>>>>>>>>>> never halts H(P,P)==0 is correct because the correct and
>>>>>>>>>>>>> complete x86 emulation of this input would never stop
>>>>>>>>>>>>> running.
>>>>>>>>>>>>
>>>>>>>>>>>> How do you KNOW it would never stop running? Given
>>>>>>>>>>>>
>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>> FUBAR(); // a disguised infinite loop
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It never gets to FUBAR()
>>>>>>>>>>
>>>>>>>>>> This is your second reply to my post, your first reply said
>>>>>>>>>> it "looks inside" FUBAR so you are contradicting yourself.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Yes I realized that I was incorrect and corrected my
>>>>>>>>> mistake.
>>>>>>>>
>>>>>>>> So you are now saying that it is merely the detection of the
>>>>>>>> nested simulation upon which you evaluate H and not what P
>>>>>>>> does after it invokes H?
>>>>>>>>
>>>>>>>
>>>>>>> That really should have been obvious hundreds of messages ago.
>>>>>>> If a function gets stuck in infinitely nested simulation it
>>>>>>> never proceeds to any point after this infinitely nested
>>>>>>> simulation.
>>>>>>
>>>>>> OK, in which case answer my second part which you conveniently
>>>>>> ignored:
>>>>>
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>
>>>>
>>>> Rather than getting angry try reading what I wrote again: P would
>>>> have HALTED:
>>>>
>>>>>
>>>>>> Given H doesn't care what P does after P invokes H then, given
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> FUBAR2(); // a disguised halting function
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> How do you evaluate H(P,P)=1? FUBAR2 can be any code that halts.
>>>>>>
>>>>
>>>> /Flibble
>>>>
>>>
>>> How do you evaluate H(P,P)=1?
>>> How do you evalulate that a dog is a cat?
>>> You don't a dog is not a cat.
>>
>> What the fuck are you talking about? P now halts it only gets
>> stuck "in the first part" when using your erroneous simulation-based
>> non-decider.
>
> If your brain can't cope with me redefining what P is try this:
>
> Given H doesn't care what P1 does after P1 invokes H then, given
>
> void P1(u32 x)
> {
> if (H(x, x))

On Tue, 7 Jun 2022 19:14:03 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/7/2022 7:02 PM, Mr Flibble wrote:
> > On Wed, 8 Jun 2022 00:50:11 +0100
> > Mr Flibble <flibble@reddwarf.jmc> wrote:
> >
> >> On Tue, 7 Jun 2022 18:42:36 -0500
> >> olcott <NoOne@NoWhere.com> wrote:
> >>
> >>> On 6/7/2022 6:37 PM, Mr Flibble wrote:
> >>>> On Tue, 7 Jun 2022 18:35:22 -0500
> >>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>
> >>>>> On 6/7/2022 6:31 PM, Mr Flibble wrote:
> >>>>>> On Tue, 7 Jun 2022 18:28:27 -0500
> >>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>
> >>>>>>> On 6/7/2022 6:17 PM, Mr Flibble wrote:
> >>>>>>>> On Tue, 7 Jun 2022 18:14:01 -0500
> >>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>
> >>>>>>>>> On 6/7/2022 6:04 PM, Mr Flibble wrote:
> >>>>>>>>>> On Tue, 7 Jun 2022 18:01:25 -0500
> >>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On 6/7/2022 5:45 PM, Mr Flibble wrote:
> >>>>>>>>>>>> On Tue, 7 Jun 2022 17:37:44 -0500
> >>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On 6/7/2022 5:08 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>> On Tue, 7 Jun 2022 16:28:21 -0500
> >>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 6/7/2022 4:22 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 16:01:53 -0500
> >>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 6/7/2022 3:51 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:34:13 -0500
> >>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 6/7/2022 3:18 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:14:30 -0500
> >>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On 6/7/2022 3:06 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:01:13 -0500
> >>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:49 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 14:09:14 -0500
> >>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:02 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 14:02:08 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 1:41 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 13:19:15 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 12:50 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 11:57:57 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 11:45 AM, Mr Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 20:13:01 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 7:56 PM, Richard Damon
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/22 8:27 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:59 PM, Mike Terry
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 22:59, Jeff Barnett
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 2:07 PM, Mike Terry
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 16:16, Alan
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mike Terry
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <news.dead.person.stones@darjeeling.plus.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 13:14, Alan
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@nowhere.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:12 AM, Alan
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@nowhere.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 5:14 AM,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mikko wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2022-06-04 19:28:19
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +0000, olcott said:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A Turing machine is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said to halt whenever
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it reaches a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configuration for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which δ is not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined; this is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible because δ is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial function. In
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fact, we will assume
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that no transitions
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are defined for any
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state so the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Turing machine will
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt whenever it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enters a final state.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Introduction to Formal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Languages and Automata.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C. Heath and Company.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When translated into
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ordinary software
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineering terms this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> means terminated
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally. In a C
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function this means
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The best equivalent to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "not defined" is not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "ret". Instead, "not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined" should include
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at least:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - HLT or any other
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction that means
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'halt'
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any undefined op code
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any return or pop
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction if the stack
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is empty
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - an instruction fetch
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from a location that is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not specifiec by the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program That way the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> analogy to Linz'
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition is much
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> better.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mikko
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reaching a final state is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely the Turing machine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way of saying terminated
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally. "ret" is the C
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way of saying the same
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sophistry.  What would be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the turing machine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> equivalent of an "abnormal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> termination" in C?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> An aborted simulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's no such thing on a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine. It either
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> runs and halts, or it runs
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> forever.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your aborted simulation is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just one final state of a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine, which has
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thus halted.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A TM "aborting" a simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is just the TM ceasing to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate computation steps
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for some computation, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> going on to calculate
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead. It
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not mean: a) that the TM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (doing the simulation) has
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted b) that the simulated
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation halts c) that the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation never
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK.  I've a feeling we're
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> talking more about nice shades
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of words than computer science
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here, but ....
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the simulation is the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entire turing machine,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborting it will bring the TM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to a halt state.  If that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation is merely part of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TM, then the word "halt"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has a different meaning when
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applied to that simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> part from when applied to the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entire TM. I'm not even sure
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what you mean when you say a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> part of a TM has halted or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not halted.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We are clearly talking at cross
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> purposes
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - I never talked about /part/
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of a TM halting, and like you,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can't work out what that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would mean!  I used "halt" only
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with respect to a computation,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> meaning that the computation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts [there is an n such that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation step n is a TM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state].
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reading what you say very
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> carefully, I think that by your
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of simulation, the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating TM must be a "pure"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator that does nothing but
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate computation steps
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> until the simulation halts, at
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which point the simulating TM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts (like a UTM). I get that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with that interpretation what
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you said:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >>> Your
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted simulation is just one
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state of a turing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine, >>> which has thus
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   makes sense
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and is correct. I'd just say I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> don't think that usage of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "simulation" is very useful,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and is DEFINITELY not what PO
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is talking about (so it would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be wrong if applied PO's
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> posts...)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My use of "simulation" is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> broader: it's simply the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> activity performed by a TM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which consists of calculating
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps of some given
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation.  As such it's just
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a part of the TM logic. A TM's
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typical use of simulation might
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be something like "..the TM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates the computation for n
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> steps, and if the simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts during those n steps, the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM [blah blah], /otherwise/ the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM [blah blah blah]...". Just
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about every reference in the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> literature I can recall is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something like that.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So... to be 100% clear on what
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I said:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >> A TM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "aborting" a simulation is just
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TM ceasing to calculate >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps for some
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation, and going on to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> E.g. in PO's P, after P aborts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation of P(P), the TM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> either halts or enters an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop. (That logic is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not part of the simulation,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IMO.) >> It does *NOT* mean: >>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a)  that the TM (doing the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation) has halted
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously, because now P has
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gone on to something else...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >> b)  that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated computation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts >> c) that the simulated
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation never halts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously - in general
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different exacmples of a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation P(I)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might halt or never halt, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this is unaffected by a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator's decision to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate no further
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps. [The TM may
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have spotted some pattern in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated computation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which implies P(I) never halts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - that is a separate matter,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but for sure the mere act of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "aborting" the simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't imply P(I) never
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts, or imply that it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Put yet another way, when a TM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops calculating TM steps (aka
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborts its simulation), NOTHING
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HALTS: not the simulating TM,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not the simulated computation,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and NOT ANY PART OF EITHER OF
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THOSE. (Like you say, what
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would part of a TM halting
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean?)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think of a TM and an input
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> string as defining a sequence
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (an ordered list). The elements
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the sequence are pairs of a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM state name and a string
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> representing the "tape" contents
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when the state was entered. Note
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that this view has no character
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of animation in it and makes the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of the halt predicate
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (H) trivial:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(TM,STRING) = If length of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM(STRING) is finite then TRUE
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> else FALSE.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, that's equivalent to what I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said (or at least meant). Your
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence is my computation steps.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Formally, these would be defined
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inductively via the rule to go
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from step n to step n+1. (Not an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> animation, but the induction
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gives some /sense/ of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> step-by-step calculation, and a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator will follow this,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> starting at step 1, then
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate step 2 and so on.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Still, I agree the entire
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence [the "computation"]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exists as one timeless
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> structure.  Too abstract for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PO...)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words when we make sure
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to conflate the program under test
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the test program as a single
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation then the whole idea of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider becomes less
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> coherent and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this can be used as an excuse to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pretend that you don't already
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> know that H(P,P)==0 is correct
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and the H/P relationship matches
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the halting problem counter
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> example template.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    if (H(x, x))
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      HERE: goto
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE; return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    Output("Input_Halts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H((u32)P, (u32)P)); }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       For any
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program H that might determine if
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs halt, a "pathological"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program P, called with some input,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can pass its own source and its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H and then specifically
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do the opposite of what H predicts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P will do. No H can exist that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> handles this case.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A simulator animates the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> production of the sequence and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that causes some difficulties in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same way that elaborating an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sum or sequence does in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> math classes. An (ultimate)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value only exists if there is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some notation of convergence or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit which typically is the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case with examples used in a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> math class. There is no
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of convergence or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit with the sequence defined
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> by TM(STRING); rather, we simply
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ask about the last pair if the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence is finite.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sure.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The question right now is what
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you would call a TM which
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> evaluates the first 10 steps of a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation, and then does
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else. What is it doing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> while evaluating those 10 steps?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tl;dr : who cares :)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My terminology would be that it's
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "simulating" the computation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (just for 10 steps) - then it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops simulating and does
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else. Obviously I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wouldn't describe it as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "correctly" simulating, because
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nobody considers incorrect
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulations, so the word would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be redundant!
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is required because my
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are making their best
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible effort to form rebuttals
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and the most persistent of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fake rebuttals has been that the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation is incorrect. It is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> very easy to verify the correct
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation on the basis of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86 language.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Except that it doesn't. By
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION, a correct simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs show the same behavior of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing it is simulating.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Members of comp.c and comp.c++ this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> goofy idiot is trying to claim that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it is utterly impossible to create a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C program that examines the x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution trace derived from
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating the input to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H0(Infinite_Loop) with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator to correctly determine that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinite_Loop() infinitely loops.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H0(Infinite_Loop)); }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342](01) 55 push
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001343](02) 8bec
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001345](02) ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 [00001347](01) 5d
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pop ebp [00001348](01) c3
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0007) [00001348]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored at:212343
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342][00212333][00212337] 55
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 Local Halt Decider:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinite Loop Detected Simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stopped
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But he isn't doing that; the issue is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not the infinite loop but the logic
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used to decide to enter the infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop. Post *full* traces.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are unable to tell
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that _Infinite_Loop() contains an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Again that isn't the issue; the issue
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is the logic used to decide when to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enter the infinite loop;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words when H0(Infinite_Loop) is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> invoked we have no idea that a correct
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation of Infinite_Loop would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach the instruction at machine address
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345] or not.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It might be the case that a correct x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of Infinite_Loop might instead
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> involve emulating an entirely different
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> function that plays tic-tac-toe?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Detecting an infinite loop is indeed
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> trivial however your program and trace
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> are not telling the full story as far as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the HP proofs are concerned;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> The only thing that my program trace
> >>>>>>>>>>>>>>>>>>>>>>>>>>> conclusively proves is that H(P,P)==0 is
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the correct return value that does
> >>>>>>>>>>>>>>>>>>>>>>>>>>> correctly correspond to the actual
> >>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the actual input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> For any program H that
> >>>>>>>>>>>>>>>>>>>>>>>>>>> might determine if programs halt, a
> >>>>>>>>>>>>>>>>>>>>>>>>>>> "pathological" program P, called with some
> >>>>>>>>>>>>>>>>>>>>>>>>>>> input, can pass its own source and its
> >>>>>>>>>>>>>>>>>>>>>>>>>>> input to H and then specifically do the
> >>>>>>>>>>>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No
> >>>>>>>>>>>>>>>>>>>>>>>>>>> H can exist that handles
> >>>>>>>>>>>>>>>>>>>>>>>>>>> this case.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ",
> >>>>>>>>>>>>>>>>>>>>>>>>>>> H((u32)P, (u32)P)); }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov
> >>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [00001355](03) 8b4508
> >>>>>>>>>>>>>>>>>>>>>>>>>>> mov eax,[ebp+08] [00001358](01) 50
> >>>>>>>>>>>>>>>>>>>>>>>>>>> push eax // push P [00001359](03)
> >>>>>>>>>>>>>>>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08] [0000135c](01) 51
> >>>>>>>>>>>>>>>>>>>>>>>>>>> push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2
> >>>>>>>>>>>>>>>>>>>>>>>>>>> // call H [00001362](03) 83c408 add
> >>>>>>>>>>>>>>>>>>>>>>>>>>> esp,+08 [00001365](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz
> >>>>>>>>>>>>>>>>>>>>>>>>>>> 0000136b [00001369](02) ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001369 [0000136b](01) 5d
> >>>>>>>>>>>>>>>>>>>>>>>>>>> pop ebp [0000136c](01) c3
> >>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0027) [0000136c]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P)
> >>>>>>>>>>>>>>>>>>>>>>>>>>> correctly emulates its input that it must
> >>>>>>>>>>>>>>>>>>>>>>>>>>> emulate the first seven instructions of P.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Because the seventh instruction of P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> repeats this process we can know with
> >>>>>>>>>>>>>>>>>>>>>>>>>>> complete certainty that the emulated P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches its final “ret” instruction,
> >>>>>>>>>>>>>>>>>>>>>>>>>>> thus never halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> But the halting problem proofs (including
> >>>>>>>>>>>>>>>>>>>>>>>>>> [Strachey 1965]) that you are trying to
> >>>>>>>>>>>>>>>>>>>>>>>>>> refute don't do that, they DO NOT make any
> >>>>>>>>>>>>>>>>>>>>>>>>>> recursive calls
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Because the idea of a simulating halt
> >>>>>>>>>>>>>>>>>>>>>>>>> decider being applied to the halting problem
> >>>>>>>>>>>>>>>>>>>>>>>>> counter-example is brand new with me you
> >>>>>>>>>>>>>>>>>>>>>>>>> won't find other references that refer to
> >>>>>>>>>>>>>>>>>>>>>>>>> "infinitely nested simulation".
> >>>>>>>>>>>>>>>>>>>>>>>>>> which is what you are doing with "call H"
> >>>>>>>>>>>>>>>>>>>>>>>>>> above. Why are you doing something
> >>>>>>>>>>>>>>>>>>>>>>>>>> different to what the proofs you are
> >>>>>>>>>>>>>>>>>>>>>>>>>> trying to refute do given doing so is no
> >>>>>>>>>>>>>>>>>>>>>>>>>> longer related to the Halting Problem?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The proofs never bothered to examine my idea
> >>>>>>>>>>>>>>>>>>>>>>>>> because it was unknown by everyone prior to
> >>>>>>>>>>>>>>>>>>>>>>>>> me creating it in 2016.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> It seems to me that your idea would only be
> >>>>>>>>>>>>>>>>>>>>>>>> novel because it is a mistake. Your mistake
> >>>>>>>>>>>>>>>>>>>>>>>> is to have the candidate program call into
> >>>>>>>>>>>>>>>>>>>>>>>> the SAME INSTANCE of the decider which is
> >>>>>>>>>>>>>>>>>>>>>>>> deciding the candidate program.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Where the Hell did you ever get this idea from
> >>>>>>>>>>>>>>>>>>>>>>> ? Whenever H simulates its input it creates a
> >>>>>>>>>>>>>>>>>>>>>>> whole new process context.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> You cannot make a direct function call into
> >>>>>>>>>>>>>>>>>>>>>> another process; it has to be the same process.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> As I have said very many hundreds of times I
> >>>>>>>>>>>>>>>>>>>>> created the x86utm operating system that enables
> >>>>>>>>>>>>>>>>>>>>> any C function to execute another C function
> >>>>>>>>>>>>>>>>>>>>> using an x86 emulator.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> In the case of H(P,P) H creates a separate
> >>>>>>>>>>>>>>>>>>>>> process context to simulate its input every time
> >>>>>>>>>>>>>>>>>>>>> that it is invoked, thus subsequent invocations
> >>>>>>>>>>>>>>>>>>>>> of H(P,P) execute in the process context that
> >>>>>>>>>>>>>>>>>>>>> was previously created.
> >>>>>>>>>>>>>>>>>>>>>> As far as getting ideas as to what you are
> >>>>>>>>>>>>>>>>>>>>>> actually doing: publish all your source so we
> >>>>>>>>>>>>>>>>>>>>>> can see for ourselves so we don't have to
> >>>>>>>>>>>>>>>>>>>>>> guess.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> That would be 100,000-fold more complex then
> >>>>>>>>>>>>>>>>>>>>> simply paying complete attention to what I am
> >>>>>>>>>>>>>>>>>>>>> saying. Everyone that is not bright enough to
> >>>>>>>>>>>>>>>>>>>>> understand 14 lines of code keeps saying that
> >>>>>>>>>>>>>>>>>>>>> they could easily understand 250 pages of code,
> >>>>>>>>>>>>>>>>>>>>> even though the 14 lines proves to be too much
> >>>>>>>>>>>>>>>>>>>>> for them.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Your code:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> call 000011a2 // call H
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> is simply a function call into the address space
> >>>>>>>>>>>>>>>>>>>> of the current process, it doesn't look like code
> >>>>>>>>>>>>>>>>>>>> to spawn a new process to me.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> How many times do I have to say this before you
> >>>>>>>>>>>>>>>>>>> notice that I said it at least once? H (in the
> >>>>>>>>>>>>>>>>>>> current process) always creates a new process
> >>>>>>>>>>>>>>>>>>> context to emulate its its input with an x86
> >>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I will have to take your word for it as you refuse
> >>>>>>>>>>>>>>>>>> to publish source code. Why not just stick your
> >>>>>>>>>>>>>>>>>> project on GitHub? Open source is de rigueur these
> >>>>>>>>>>>>>>>>>> days. What are you trying to hide?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> If a new process context is made then how is nested
> >>>>>>>>>>>>>>>>>> simulation detected? I assume the data segment of
> >>>>>>>>>>>>>>>>>> each process is private...
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> An honest dialogue requires points of mutual
> >>>>>>>>>>>>>>>>> agreement. The price of moving beyond H(P,P)==0 is
> >>>>>>>>>>>>>>>>> universal agreement that H(P,P)==0 is correct. The
> >>>>>>>>>>>>>>>>> next point beyond H(P,P)==0 is computer science thus
> >>>>>>>>>>>>>>>>> not appropriate for the C/C++ forum.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I agree that H(P,P)==0 for pathological input
> >>>>>>>>>>>>>>>> assuming your method for detecting pathological
> >>>>>>>>>>>>>>>> input is sufficiently robust however how is that
> >>>>>>>>>>>>>>>> distinguished from H(P1,P1)==0 where P1 is normal
> >>>>>>>>>>>>>>>> non-halting (i.e. non-pathological)?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> When-so-ever the correct and complete emulation of the
> >>>>>>>>>>>>>>> input to H would never stop running H(x,y)==0 is
> >>>>>>>>>>>>>>> correct.
> >>>>>>>>>>>>>>>> If you are pattern matching op codes "EB FE" to
> >>>>>>>>>>>>>>>> detect the infinite loop then how do you solve the
> >>>>>>>>>>>>>>>> problem of there being 2^n different patterns
> >>>>>>>>>>>>>>>> equivalent to that loop so someone could come along
> >>>>>>>>>>>>>>>> and write a pathological program that defeats your
> >>>>>>>>>>>>>>>> pattern matcher? This is why we need your source
> >>>>>>>>>>>>>>>> code to answer these kinds of questions.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> To refute all of the HP conventional proofs only
> >>>>>>>>>>>>>>> requires correctly determining that H(P,P)==0.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Are you using pattern matching to detect the infinite
> >>>>>>>>>>>>>> loop or not?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Even if H(P,P) simply makes a wild guess that its input
> >>>>>>>>>>>>> never halts H(P,P)==0 is correct because the correct and
> >>>>>>>>>>>>> complete x86 emulation of this input would never stop
> >>>>>>>>>>>>> running.
> >>>>>>>>>>>>
> >>>>>>>>>>>> How do you KNOW it would never stop running? Given
> >>>>>>>>>>>>
> >>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>> FUBAR(); // a disguised infinite loop
> >>>>>>>>>>>> return;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> It never gets to FUBAR()
> >>>>>>>>>>
> >>>>>>>>>> This is your second reply to my post, your first reply said
> >>>>>>>>>> it "looks inside" FUBAR so you are contradicting yourself.
> >>>>>>>>>>
> >>>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>> Yes I realized that I was incorrect and corrected my
> >>>>>>>>> mistake.
> >>>>>>>>
> >>>>>>>> So you are now saying that it is merely the detection of the
> >>>>>>>> nested simulation upon which you evaluate H and not what P
> >>>>>>>> does after it invokes H?
> >>>>>>>>
> >>>>>>>
> >>>>>>> That really should have been obvious hundreds of messages ago.
> >>>>>>> If a function gets stuck in infinitely nested simulation it
> >>>>>>> never proceeds to any point after this infinitely nested
> >>>>>>> simulation.
> >>>>>>
> >>>>>> OK, in which case answer my second part which you conveniently
> >>>>>> ignored:
> >>>>>
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>> H never gets to the second part. H is stuck in the first part.
> >>>>>
> >>>>
> >>>> Rather than getting angry try reading what I wrote again: P would
> >>>> have HALTED:
> >>>>
> >>>>>
> >>>>>> Given H doesn't care what P does after P invokes H then, given
> >>>>>>
> >>>>>> void P(u32 x)
> >>>>>> {
> >>>>>> if (H(x, x))
> >>>>>> FUBAR2(); // a disguised halting function
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>> }
> >>>>>>
> >>>>>> How do you evaluate H(P,P)=1? FUBAR2 can be any code that
> >>>>>> halts.
> >>>>
> >>>> /Flibble
> >>>>
> >>>
> >>> How do you evaluate H(P,P)=1?
> >>> How do you evalulate that a dog is a cat?
> >>> You don't a dog is not a cat.
> >>
> >> What the fuck are you talking about? P now halts it only gets
> >> stuck "in the first part" when using your erroneous
> >> simulation-based non-decider.
> >
> > If your brain can't cope with me redefining what P is try this:
> >
> > Given H doesn't care what P1 does after P1 invokes H then, given
> >
> > void P1(u32 x)
> > {
> > if (H(x, x))
>
>
> Because P never gets past this point H(P,P)==1 is false.
> IS FALSE IS THE ONLY CORRECT WAY TO EVALUATE H(P,P)==1.

On 6/7/2022 7:05 PM, Mike Terry wrote:
> On 07/06/2022 21:51, Mr Flibble wrote:
>> On Tue, 7 Jun 2022 15:34:13 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
> <..snip..>
>>>
>>> How many times do I have to say this before you notice that I said it
>>> at least once? H (in the current process) always creates a new
>>> process context to emulate its its input with an x86 emulator.
>>
>> I will have to take your word for it as you refuse to publish source
>> code. Why not just stick your project on GitHub? Open source is de
>> rigueur these days. What are you trying to hide?
>>
>> If a new process context is made then how is nested simulation
>> detected?
>
> The code in x86utm.exe (his emulator) that emulates individual
> instructions also updates a global trace table, making it accessible to
> the emulated code.  So every instruction and any (nested, nested(nested)
> etc.) simulated instructions ALL get merged together in this one global
> trace.
>
> I imagine the global trace table to be much like the printed traces that
> PO posts over and over.  If YOU can recognise some pattern in those
> printed traces, then logically H can spot that same pattern in the
> global trace, as the info in both cases is more or less the same.
>
> [Above is my best guess, based on previous PO answers before you were
> interested.]
>

When a UTM simulates TM description
that invokes a UTM that simulates a TM description
that invokes a UTM that simulates a TM description
that invokes a UTM that simulates a TM description
that invokes a UTM that simulates a TM description

All of this whole process is data belongs to the first UTM, thus global
data is not needed and the whole process is a computable function of the
original inputs to the outermost UTM.

>> I assume the data segment of each process is private...
>
> PO said "new process context.." and that would imply each has its own
> address space, and that is obviously how simulation is SUPPOSED to work
> (like a TM would perform) - so your assumption is totally reasonable!
> But you've made the basic mistake of assuming PO knows what a "process"
> is - PO is not a software engineer or computer scientist, although he
> does his utmost to give that impression!
>
> Anyhow, each PO-simulation is like a single-stepped thread within a
> SINGLE shared address space, so any globals in his H are shared by all
> his "independent" simulations.
>
> [Above is based on previous PO answers before you were interested.]
>
> Mike.

The most difficult part of creating x86utm was to providing the means
for unlimited nested emulations.

Perhaps my credibility will increase when I get back to my TM
interpreter and complete it. I have had numerous issues that had higher
priorities.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/7/2022 7:18 PM, Mr Flibble wrote:
> On Tue, 7 Jun 2022 19:14:03 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/7/2022 7:02 PM, Mr Flibble wrote:
>>> On Wed, 8 Jun 2022 00:50:11 +0100
>>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>>
>>>> On Tue, 7 Jun 2022 18:42:36 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 6/7/2022 6:37 PM, Mr Flibble wrote:
>>>>>> On Tue, 7 Jun 2022 18:35:22 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>
>>>>>>> On 6/7/2022 6:31 PM, Mr Flibble wrote:
>>>>>>>> On Tue, 7 Jun 2022 18:28:27 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> On 6/7/2022 6:17 PM, Mr Flibble wrote:
>>>>>>>>>> On Tue, 7 Jun 2022 18:14:01 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 6/7/2022 6:04 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Tue, 7 Jun 2022 18:01:25 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/7/2022 5:45 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Tue, 7 Jun 2022 17:37:44 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 6/7/2022 5:08 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 16:28:21 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 6/7/2022 4:22 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 16:01:53 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 6/7/2022 3:51 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:34:13 -0500
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 3:18 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:14:30 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 3:06 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 15:01:13 -0500
>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:49 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 7 Jun 2022 14:09:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/7/2022 2:02 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 14:02:08 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 1:41 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 13:19:15 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 12:50 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 6 Jun 2022 11:57:57 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/6/2022 11:45 AM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 20:13:01 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 7:56 PM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/22 8:27 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:59 PM, Mike Terry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 22:59, Jeff Barnett
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 2:07 PM, Mike Terry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 16:16, Alan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mike Terry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <news.dead.person.stones@darjeeling.plus.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2022 13:14, Alan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@nowhere.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 6:12 AM, Alan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mackenzie wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@nowhere.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/5/2022 5:14 AM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2022-06-04 19:28:19
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A Turing machine is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said to halt whenever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it reaches a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configuration for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which δ is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined; this is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible because δ is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial function. In
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fact, we will assume
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that no transitions
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are defined for any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state so the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Turing machine will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt whenever it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enters a final state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Introduction to Formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Languages and Automata.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C. Heath and Company.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When translated into
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ordinary software
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineering terms this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> means terminated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally. In a C
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function this means
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The best equivalent to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "not defined" is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "ret". Instead, "not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined" should include
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at least:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - HLT or any other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction that means
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'halt'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any undefined op code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - any return or pop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction if the stack
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is empty
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - an instruction fetch
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from a location that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not specifiec by the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program That way the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> analogy to Linz'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition is much
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> better.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mikko
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reaching a final state is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely the Turing machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way of saying terminated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally. "ret" is the C
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way of saying the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sophistry.  What would be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the turing machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> equivalent of an "abnormal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> termination" in C?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> An aborted simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's no such thing on a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine. It either
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> runs and halts, or it runs
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> forever.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your aborted simulation is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just one final state of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> turing machine, which has
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thus halted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A TM "aborting" a simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is just the TM ceasing to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate computation steps
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for some computation, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> going on to calculate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead. It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not mean: a) that the TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (doing the simulation) has
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted b) that the simulated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation halts c) that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK.  I've a feeling we're
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> talking more about nice shades
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of words than computer science
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here, but ....
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the simulation is the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entire turing machine,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborting it will bring the TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to a halt state.  If that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation is merely part of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TM, then the word "halt"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has a different meaning when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applied to that simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> part from when applied to the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entire TM. I'm not even sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what you mean when you say a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> part of a TM has halted or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not halted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We are clearly talking at cross
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> purposes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - I never talked about /part/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of a TM halting, and like you,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can't work out what that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would mean!  I used "halt" only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with respect to a computation,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> meaning that the computation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts [there is an n such that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation step n is a TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state].
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reading what you say very
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> carefully, I think that by your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of simulation, the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating TM must be a "pure"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator that does nothing but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate computation steps
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> until the simulation halts, at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which point the simulating TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts (like a UTM). I get that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with that interpretation what
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >>> Your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted simulation is just one
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state of a turing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine, >>> which has thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   makes sense
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and is correct. I'd just say I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> don't think that usage of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "simulation" is very useful,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and is DEFINITELY not what PO
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is talking about (so it would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be wrong if applied PO's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> posts...)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My use of "simulation" is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> broader: it's simply the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> activity performed by a TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which consists of calculating
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps of some given
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation.  As such it's just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a part of the TM logic. A TM's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typical use of simulation might
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be something like "..the TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates the computation for n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> steps, and if the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts during those n steps, the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM [blah blah], /otherwise/ the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM [blah blah blah]...". Just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about every reference in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> literature I can recall is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something like that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So... to be 100% clear on what
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <copied from above>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >> A TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "aborting" a simulation is just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TM ceasing to calculate >>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps for some
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation, and going on to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else instead.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> E.g. in PO's P, after P aborts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation of P(P), the TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> either halts or enters an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop. (That logic is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not part of the simulation,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IMO.) >> It does *NOT* mean: >>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a)  that the TM (doing the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation) has halted
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously, because now P has
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gone on to something else...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  >> b)  that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated computation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts >> c) that the simulated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation never halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously - in general
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different exacmples of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated computation P(I)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might halt or never halt, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this is unaffected by a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator's decision to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate no further
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation steps. [The TM may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have spotted some pattern in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated computation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which implies P(I) never halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - that is a separate matter,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but for sure the mere act of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "aborting" the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't imply P(I) never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts, or imply that it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Put yet another way, when a TM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops calculating TM steps (aka
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborts its simulation), NOTHING
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HALTS: not the simulating TM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not the simulated computation,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and NOT ANY PART OF EITHER OF
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THOSE. (Like you say, what
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would part of a TM halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean?)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think of a TM and an input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> string as defining a sequence
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (an ordered list). The elements
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the sequence are pairs of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM state name and a string
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> representing the "tape" contents
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when the state was entered. Note
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that this view has no character
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of animation in it and makes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of the halt predicate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (H) trivial:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(TM,STRING) = If length of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM(STRING) is finite then TRUE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> else FALSE.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, that's equivalent to what I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said (or at least meant). Your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence is my computation steps.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Formally, these would be defined
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inductively via the rule to go
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from step n to step n+1. (Not an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> animation, but the induction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gives some /sense/ of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> step-by-step calculation, and a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator will follow this,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> starting at step 1, then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculate step 2 and so on.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Still, I agree the entire
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence [the "computation"]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exists as one timeless
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> structure.  Too abstract for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PO...)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words when we make sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to conflate the program under test
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the test program as a single
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation then the whole idea of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider becomes less
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> coherent and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this can be used as an excuse to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pretend that you don't already
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> know that H(P,P)==0 is correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and the H/P relationship matches
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the halting problem counter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> example template.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      HERE: goto
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE; return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    Output("Input_Halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H((u32)P, (u32)P)); }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       For any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program H that might determine if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs halt, a "pathological"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> program P, called with some input,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can pass its own source and its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H and then specifically
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do the opposite of what H predicts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P will do. No H can exist that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> handles this case.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A simulator animates the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> production of the sequence and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that causes some difficulties in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same way that elaborating an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite sum or sequence does in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> math classes. An (ultimate)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value only exists if there is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some notation of convergence or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit which typically is the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case with examples used in a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> math class. There is no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of convergence or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit with the sequence defined
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> by TM(STRING); rather, we simply
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ask about the last pair if the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence is finite.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sure.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The question right now is what
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you would call a TM which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> evaluates the first 10 steps of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation, and then does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else. What is it doing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> while evaluating those 10 steps?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tl;dr : who cares :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My terminology would be that it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "simulating" the computation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (just for 10 steps) - then it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops simulating and does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something else. Obviously I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wouldn't describe it as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "correctly" simulating, because
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nobody considers incorrect
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulations, so the word would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be redundant!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is required because my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are making their best
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible effort to form rebuttals
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and the most persistent of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fake rebuttals has been that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation is incorrect. It is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> very easy to verify the correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation on the basis of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Except that it doesn't. By
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION, a correct simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs show the same behavior of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing it is simulating.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Members of comp.c and comp.c++ this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> goofy idiot is trying to claim that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it is utterly impossible to create a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C program that examines the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution trace derived from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating the input to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H0(Infinite_Loop) with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator to correctly determine that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinite_Loop() infinitely loops.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = ", H0(Infinite_Loop)); }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342](01) 55 push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001343](02) 8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001345](02) ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 [00001347](01) 5d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pop ebp [00001348](01) c3
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0007) [00001348]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored at:212343
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001342][00212333][00212337] 55
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345 Local Halt Decider:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinite Loop Detected Simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But he isn't doing that; the issue is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not the infinite loop but the logic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used to decide to enter the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop. Post *full* traces.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are unable to tell
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that _Infinite_Loop() contains an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Again that isn't the issue; the issue
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is the logic used to decide when to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enter the infinite loop;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words when H0(Infinite_Loop) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invoked we have no idea that a correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation of Infinite_Loop would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach the instruction at machine address
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345] or not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It might be the case that a correct x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of Infinite_Loop might instead
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> involve emulating an entirely different
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function that plays tic-tac-toe?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Detecting an infinite loop is indeed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trivial however your program and trace
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are not telling the full story as far as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the HP proofs are concerned;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The only thing that my program trace
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> conclusively proves is that H(P,P)==0 is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the correct return value that does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly correspond to the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the actual input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For any program H that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might determine if programs halt, a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "pathological" program P, called with some
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input, can pass its own source and its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H and then specifically do the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H can exist that handles
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this case.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ",
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H((u32)P, (u32)P)); }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [00001355](03) 8b4508
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov eax,[ebp+08] [00001358](01) 50
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push eax // push P [00001359](03)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08] [0000135c](01) 51
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // call H [00001362](03) 83c408 add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> esp,+08 [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0000136b [00001369](02) ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001369 [0000136b](01) 5d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pop ebp [0000136c](01) c3
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly emulates its input that it must
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulate the first seven instructions of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because the seventh instruction of P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> repeats this process we can know with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> complete certainty that the emulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches its final “ret” instruction,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thus never halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> But the halting problem proofs (including
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [Strachey 1965]) that you are trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> refute don't do that, they DO NOT make any
>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive calls
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Because the idea of a simulating halt
>>>>>>>>>>>>>>>>>>>>>>>>>>> decider being applied to the halting problem
>>>>>>>>>>>>>>>>>>>>>>>>>>> counter-example is brand new with me you
>>>>>>>>>>>>>>>>>>>>>>>>>>> won't find other references that refer to
>>>>>>>>>>>>>>>>>>>>>>>>>>> "infinitely nested simulation".
>>>>>>>>>>>>>>>>>>>>>>>>>>>> which is what you are doing with "call H"
>>>>>>>>>>>>>>>>>>>>>>>>>>>> above. Why are you doing something
>>>>>>>>>>>>>>>>>>>>>>>>>>>> different to what the proofs you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> trying to refute do given doing so is no
>>>>>>>>>>>>>>>>>>>>>>>>>>>> longer related to the Halting Problem?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The proofs never bothered to examine my idea
>>>>>>>>>>>>>>>>>>>>>>>>>>> because it was unknown by everyone prior to
>>>>>>>>>>>>>>>>>>>>>>>>>>> me creating it in 2016.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> It seems to me that your idea would only be
>>>>>>>>>>>>>>>>>>>>>>>>>> novel because it is a mistake. Your mistake
>>>>>>>>>>>>>>>>>>>>>>>>>> is to have the candidate program call into
>>>>>>>>>>>>>>>>>>>>>>>>>> the SAME INSTANCE of the decider which is
>>>>>>>>>>>>>>>>>>>>>>>>>> deciding the candidate program.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Where the Hell did you ever get this idea from
>>>>>>>>>>>>>>>>>>>>>>>>> ? Whenever H simulates its input it creates a
>>>>>>>>>>>>>>>>>>>>>>>>> whole new process context.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You cannot make a direct function call into
>>>>>>>>>>>>>>>>>>>>>>>> another process; it has to be the same process.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> As I have said very many hundreds of times I
>>>>>>>>>>>>>>>>>>>>>>> created the x86utm operating system that enables
>>>>>>>>>>>>>>>>>>>>>>> any C function to execute another C function
>>>>>>>>>>>>>>>>>>>>>>> using an x86 emulator.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> In the case of H(P,P) H creates a separate
>>>>>>>>>>>>>>>>>>>>>>> process context to simulate its input every time
>>>>>>>>>>>>>>>>>>>>>>> that it is invoked, thus subsequent invocations
>>>>>>>>>>>>>>>>>>>>>>> of H(P,P) execute in the process context that
>>>>>>>>>>>>>>>>>>>>>>> was previously created.
>>>>>>>>>>>>>>>>>>>>>>>> As far as getting ideas as to what you are
>>>>>>>>>>>>>>>>>>>>>>>> actually doing: publish all your source so we
>>>>>>>>>>>>>>>>>>>>>>>> can see for ourselves so we don't have to
>>>>>>>>>>>>>>>>>>>>>>>> guess.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> That would be 100,000-fold more complex then
>>>>>>>>>>>>>>>>>>>>>>> simply paying complete attention to what I am
>>>>>>>>>>>>>>>>>>>>>>> saying. Everyone that is not bright enough to
>>>>>>>>>>>>>>>>>>>>>>> understand 14 lines of code keeps saying that
>>>>>>>>>>>>>>>>>>>>>>> they could easily understand 250 pages of code,
>>>>>>>>>>>>>>>>>>>>>>> even though the 14 lines proves to be too much
>>>>>>>>>>>>>>>>>>>>>>> for them.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Your code:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> call 000011a2 // call H
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> is simply a function call into the address space
>>>>>>>>>>>>>>>>>>>>>> of the current process, it doesn't look like code
>>>>>>>>>>>>>>>>>>>>>> to spawn a new process to me.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> How many times do I have to say this before you
>>>>>>>>>>>>>>>>>>>>> notice that I said it at least once? H (in the
>>>>>>>>>>>>>>>>>>>>> current process) always creates a new process
>>>>>>>>>>>>>>>>>>>>> context to emulate its its input with an x86
>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I will have to take your word for it as you refuse
>>>>>>>>>>>>>>>>>>>> to publish source code. Why not just stick your
>>>>>>>>>>>>>>>>>>>> project on GitHub? Open source is de rigueur these
>>>>>>>>>>>>>>>>>>>> days. What are you trying to hide?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If a new process context is made then how is nested
>>>>>>>>>>>>>>>>>>>> simulation detected? I assume the data segment of
>>>>>>>>>>>>>>>>>>>> each process is private...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> An honest dialogue requires points of mutual
>>>>>>>>>>>>>>>>>>> agreement. The price of moving beyond H(P,P)==0 is
>>>>>>>>>>>>>>>>>>> universal agreement that H(P,P)==0 is correct. The
>>>>>>>>>>>>>>>>>>> next point beyond H(P,P)==0 is computer science thus
>>>>>>>>>>>>>>>>>>> not appropriate for the C/C++ forum.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I agree that H(P,P)==0 for pathological input
>>>>>>>>>>>>>>>>>> assuming your method for detecting pathological
>>>>>>>>>>>>>>>>>> input is sufficiently robust however how is that
>>>>>>>>>>>>>>>>>> distinguished from H(P1,P1)==0 where P1 is normal
>>>>>>>>>>>>>>>>>> non-halting (i.e. non-pathological)?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When-so-ever the correct and complete emulation of the
>>>>>>>>>>>>>>>>> input to H would never stop running H(x,y)==0 is
>>>>>>>>>>>>>>>>> correct.
>>>>>>>>>>>>>>>>>> If you are pattern matching op codes "EB FE" to
>>>>>>>>>>>>>>>>>> detect the infinite loop then how do you solve the
>>>>>>>>>>>>>>>>>> problem of there being 2^n different patterns
>>>>>>>>>>>>>>>>>> equivalent to that loop so someone could come along
>>>>>>>>>>>>>>>>>> and write a pathological program that defeats your
>>>>>>>>>>>>>>>>>> pattern matcher? This is why we need your source
>>>>>>>>>>>>>>>>>> code to answer these kinds of questions.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To refute all of the HP conventional proofs only
>>>>>>>>>>>>>>>>> requires correctly determining that H(P,P)==0.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Are you using pattern matching to detect the infinite
>>>>>>>>>>>>>>>> loop or not?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Even if H(P,P) simply makes a wild guess that its input
>>>>>>>>>>>>>>> never halts H(P,P)==0 is correct because the correct and
>>>>>>>>>>>>>>> complete x86 emulation of this input would never stop
>>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How do you KNOW it would never stop running? Given
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>> FUBAR(); // a disguised infinite loop
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It never gets to FUBAR()
>>>>>>>>>>>>
>>>>>>>>>>>> This is your second reply to my post, your first reply said
>>>>>>>>>>>> it "looks inside" FUBAR so you are contradicting yourself.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Yes I realized that I was incorrect and corrected my
>>>>>>>>>>> mistake.
>>>>>>>>>>
>>>>>>>>>> So you are now saying that it is merely the detection of the
>>>>>>>>>> nested simulation upon which you evaluate H and not what P
>>>>>>>>>> does after it invokes H?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That really should have been obvious hundreds of messages ago.
>>>>>>>>> If a function gets stuck in infinitely nested simulation it
>>>>>>>>> never proceeds to any point after this infinitely nested
>>>>>>>>> simulation.
>>>>>>>>
>>>>>>>> OK, in which case answer my second part which you conveniently
>>>>>>>> ignored:
>>>>>>>
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>> H never gets to the second part. H is stuck in the first part.
>>>>>>>
>>>>>>
>>>>>> Rather than getting angry try reading what I wrote again: P would
>>>>>> have HALTED:
>>>>>>
>>>>>>>
>>>>>>>> Given H doesn't care what P does after P invokes H then, given
>>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> FUBAR2(); // a disguised halting function
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> How do you evaluate H(P,P)=1? FUBAR2 can be any code that
>>>>>>>> halts.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> How do you evaluate H(P,P)=1?
>>>>> How do you evalulate that a dog is a cat?
>>>>> You don't a dog is not a cat.
>>>>
>>>> What the fuck are you talking about? P now halts it only gets
>>>> stuck "in the first part" when using your erroneous
>>>> simulation-based non-decider.
>>>
>>> If your brain can't cope with me redefining what P is try this:
>>>
>>> Given H doesn't care what P1 does after P1 invokes H then, given
>>>
>>> void P1(u32 x)
>>> {
>>> if (H(x, x))
>>
>>
>> Because P never gets past this point H(P,P)==1 is false.
>> IS FALSE IS THE ONLY CORRECT WAY TO EVALUATE H(P,P)==1.
>
> At this point I give up as you are either being deliberately obtuse or
> do not read/comprehend properly what people are telling you. I will not
> waste any more time with you on this except to say everybody else is
> correct and you are incorrect, as is to be expected.
>
> Good luck with the cancer, I mean that.
>
> /Flibble
>

On 04/06/2022 01:12, olcott wrote:
>
> I yes, I have. They make sure to erase anything that has not been
> properly peer reviewed.
>
>
Perhaps you can contact Gamo to peer review your work:

<http://gamo.sdf-eu.org/turing>

On 6/11/2022 12:40 PM, Manu Raju wrote:
> On 04/06/2022 01:12, olcott wrote:
>>
>> I yes, I have. They make sure to erase anything that has not been
>> properly peer reviewed.
>>
>>
> Perhaps you can contact Gamo to peer review your work:
>
> <http://gamo.sdf-eu.org/turing>
>
>

Ideally I need a PhD computer scientists that are also expert software
engineers in C/x86.

The reason that I post to this forum is that expert software engineers
that know nothing about computer science can confirm that H(P,P) does
correctly determine that its complete and correct x86 emulation of its
input would never stop running.

Once this single point is validated we leave the scope of pure software
engineering and must examine the computer science aspects. I can do that
in other groups and quit posting here.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 11/06/2022 19:09, olcott wrote:
>
>
> Ideally I need a PhD computer scientists that are also expert software
> engineers in C/x86.

That's what Gamo is.

>
> The reason that I post to this forum is that expert software engineers
> that know nothing about computer science can confirm that H(P,P) does
> correctly determine that its complete and correct x86 emulation of its
> input would never stop running.

Mr Flibble, our resident expert in Halt systems has looked at your work
and he is NOT impressed at all. Your options are pretty limited on these
newsgroups because no one is interested in your work. They are
interested to waist your time here by arguing with everything you do,
knowing that you are just another disillusional troll here.

>
> Once this single point is validated we leave the scope of pure
> software engineering and must examine the computer science aspects. I
> can do that in other groups and quit posting here.
>
This will not happen and assuming you were telling us truth about your
cancer, you will not be able to make a name for yourself because you
have just given up going to the right people about your work. I am
assuming that you honestly believe that you have found something that
nobody from MIT, Harvard, Stanford, Oxford, Cambridge or some other top
universities have managed to find.

Good luck and continue trolling on these newsgroups. People have given
up on you and now I am joining them.

Bye bye.

On 6/11/2022 5:30 PM, Manu Raju wrote:
> On 11/06/2022 19:09, olcott wrote:
>>
>>
>> Ideally I need a PhD computer scientists that are also expert software
>> engineers in C/x86.
>
> That's what Gamo is.
>

It sure does not look like that from the link.

>
>>
>> The reason that I post to this forum is that expert software engineers
>> that know nothing about computer science can confirm that H(P,P) does
>> correctly determine that its complete and correct x86 emulation of its
>> input would never stop running.
>
> Mr Flibble, our resident expert in Halt systems has looked at your work
> and he is NOT impressed at all. Your options are pretty limited on these
> newsgroups

Flibble has proven that he does not even understand the concept of
unreachable code.

> because no one is interested in your work. They are
> interested to waist your time here by arguing with everything you do,
> knowing that you are just another disillusional troll here.
>

>
>>
>> Once this single point is validated we leave the scope of pure
>> software engineering and must examine the computer science aspects. I
>> can do that in other groups and quit posting here.
>>
> This will not happen and assuming you were telling us truth about your
> cancer, you will not be able to make a name for yourself because you
> have just given up going to the right people about your work. I am

The problem is that almost everyone assumes that I must be incorrect
before ever even looking at what I said.

> assuming that you honestly believe that you have found something that
> nobody from MIT, Harvard, Stanford, Oxford, Cambridge or some other top
> universities have managed to find.
>

The problem is that people never previously thought the idea of a
simulating halt decider applied to the halting problem proof
counter-examples ALL-THE-WAY-THROUGH.

No one that rejects my work out-of-hand without review ever noticed this
key fact.

> Good luck and continue trolling on these newsgroups. People have given
> up on you and now I am joining them.
>
> Bye bye.
>
>
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Sat, 11 Jun 2022 18:10:44 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/11/2022 5:30 PM, Manu Raju wrote:
> > On 11/06/2022 19:09, olcott wrote:
> >>
> >> The reason that I post to this forum is that expert software
> >> engineers that know nothing about computer science can confirm
> >> that H(P,P) does correctly determine that its complete and correct
> >> x86 emulation of its input would never stop running.
> >
> > Mr Flibble, our resident expert in Halt systems has looked at your
> > work and he is NOT impressed at all. Your options are pretty
> > limited on these newsgroups
>
>
> Flibble has proven that he does not even understand the concept of
> unreachable code.

LIE. You are just a lying troll with nothing of interest to present.

/Flibble

On 6/11/2022 6:24 PM, Mr Flibble wrote:
> On Sat, 11 Jun 2022 18:10:44 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/11/2022 5:30 PM, Manu Raju wrote:
>>> On 11/06/2022 19:09, olcott wrote:
>>>>
>>>> The reason that I post to this forum is that expert software
>>>> engineers that know nothing about computer science can confirm
>>>> that H(P,P) does correctly determine that its complete and correct
>>>> x86 emulation of its input would never stop running.
>>>
>>> Mr Flibble, our resident expert in Halt systems has looked at your
>>> work and he is NOT impressed at all. Your options are pretty
>>> limited on these newsgroups
>>
>>
>> Flibble has proven that he does not even understand the concept of
>> unreachable code.
>
> LIE. You are just a lying troll with nothing of interest to present.
>
> /Flibble
>

It is an easily verified fact that you made several replies that you
thought changing the opcodes in the unreachable part of P after machine
address [0000135d] might make a difference.

You never did understand that this code is unreachable.

from comp.theory
On 6/9/2022 12:46 PM, Mr Flibble wrote:
> On Thu, 9 Jun 2022 12:39:32 -0500
> olcott <NoOne@NoWhere.com> wrote:
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax // push P
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx // push P
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> It is completely obvious that when H(P,P) correctly emulates its
>> input that it must emulate the first seven instructions of P. Because
>> the seventh instruction of P repeats this process we know with
>> complete certainty that the correct and complete emulation of P by H
>> would never reach its final “ret” instruction, thus never halts.
>
> We are going around and around and around in circles. I will try again:
>
> If you replace the opcodes "EB FE" at 00001369 with the opcodes "90 90"
> then your H gets the answer wrong: P should have halted.
>
> /Flibble
>

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

00001369 is unreachable code for the correctly emulated input to H(P,P)
You still don't get this.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer