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.

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

--
Copyright 2022 Pete Olcott

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