On Sun, 5 Jun 2022 19:27:39 -0500
olcott <NoOne@NoWhere.com> 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

On 6/6/2022 11:49 AM, Mr Flibble wrote:
> On Sun, 5 Jun 2022 19:27:39 -0500
> olcott <NoOne@NoWhere.com> 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
>
> I asserted that it is erroneous to conflate the decider with that which
> is being decided several months ago. No such conflation occurs in the
> HP proofs you are attempting to refute; it is your conflation which is
> erroneous.
>
> /Flibble
>

On 6/6/22 11:28 AM, olcott wrote:
> On 6/5/2022 11:17 PM, Richard Damon wrote:
>>
>> On 6/5/22 11:41 PM, olcott wrote:
>>> On 6/5/2022 10:26 PM, Richard Damon wrote:
>>>> On 6/5/22 11:03 PM, olcott wrote:
>>>>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/5/22 10:37 PM, olcott wrote:
>>>>>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>>>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>>>>>> <..snip..>>>
>>>>>>>>>>>> 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?
>>>>>>>>>>>
>>>>>>>>>>> What would I call it? POOP! It just goes to show the accuracy
>>>>>>>>>>> and flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>>>>>> computation in order to compute certain properties of that
>>>>>>>>>> computation!  It's been around since Turing's days, and is
>>>>>>>>>> very useful.
>>>>>>>>>>
>>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>>> That is true. I am apparently the first one that ever thought
>>>>>>>>> this through well enough so that machine descriptions matching
>>>>>>>>> the following pattern could be correctly determined to be
>>>>>>>>> non-halting:
>>>>>>>>>
>>>>>>>>>       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
>>>>>>>>>
>>>>>>>>> In that a partial simulation does correctly predict the
>>>>>>>>> behavior of a complete simulation it can be used to recognize
>>>>>>>>> infinite behavior patterns.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0,
>>>>>>>> which, by the DEFINITION of the requirements of the Halting
>>>>>>>> Problem, H(P,P) needs to accept (return 1) if P(P) Halts,
>>>>>>> This seems to be brand new computer science that I just discovered.
>>>>>>>
>>>>>>> Previously no one understood that it was possible for the correct
>>>>>>> simulation of the input to H(P,P) to be computationally distinct
>>>>>>> (thus not equivalent) to the direct execution of P(P).
>>>>>>
>>>>>> By what definition of "Correct" are you using?
>>>>>
>>>>>
>>>>> Ordinary software engineering proves that a correct and complete
>>>>> x86 emulation of the input to H(P,P) never reaches its "ret"
>>>>> instruction.
>>>>>
>>>>
>>>> So, I guess this just shows that you don't actually know a
>>>> definition that shows this, so this is just another of your lies.
>>>
>>> Ordinary software engineering proves that a correct and complete x86
>>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>
>> Nope. Not if H(P,P) returns 0, as simple facts show that if H(P,P)
>> returns 0 that P(P) will halt.
>>
>> Good engineering NEVER contradicts actual facts.
>>
>>>
>>> _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.
>>>
>>
>> Maybe to you, but it is wrong (which might be why it is obvious to you).
>>
>
>
> Software engineers competent in C and the x86 language will verify that
> when H(P,P) correctly emulates its input with an x86 emulator that this
> emulation would never stop running. This provides the basis for H(P,P)
> to correctly reject its input as non-halting.

Yes, when H is actually defined to correctly emulate its input, which
means, BY DEFINITON, that it doesn't stop its emulation until it reaches
a final state, then it can be shown that this emulation never stops running.

This can NOT be used to show that any other H is correct to say that the
P built on that other H is non-halting, as it is a different program P,
as the program P includes the H that it is built on.

That you keep missing this fact speaks of your mental ability (or lack
thereof)

>
> > 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
>
> H determines the halt status of its input by watching the behavior of
> this input when it is correctly simulated by H using an x86 emulator.
> When H correctly matches an infinite behavior pattern it aborts the
> emulation of this input and returns 0.

Except that is can't see a full correctly simulation of its input, and
the partial simulation that it sees never shows an actual correctly
defined infinite behavior pattern, as can be proved by the fact that if
you include that in H, then P(P) for the P built on the H that includes
that pattern and returns 0 for H(P,P) will Halt, when the h that it
calls returns that answer.

You can't use the partial simulation that H used, as partial simulation
do not, by themselves, prove non-halting, and for a pattern to be
correctly determined to be non-halting, ALL programs that show that
pattern must be non-halting, but as described above ANY pattern that H
sees in its simulation of its input to H(P,P), if added to its list of
patterns to call non-halting, will produce a Halting P(P), and thus is
proved not to be correct.

>
>     #include <stdint.h>
>     #define u32 uint32_t
>
>     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 repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>

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

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.

> [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!

My unlimited nested simulations could not function properly if I did not
know all of the details of how to do this.

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

--
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/22 9:04 PM, olcott wrote:
> 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.
>>
>
> When a UTM simulates TM description
> that invokes a UTM that simulates a TM description

Nope, it invoke a copy of H that simulates its input and then abort is.

> 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

This appears to be a flaw in your whole system design, you P changes to
call as H whatever you try to use to simulate it.

P needs to call the H that this P is designed to refute, and no others.

Remember, You need to pick *A* H that you are going to claim is a
correct decider, then you make *A* P based on that one, and run the
descion and test on THOSE SPECIIFIC machines.

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

????

The input to the UTM is a description of a P that calls the H that you
claim is correct in aborting its simulation of the P built on it.

That UTM will simulate that input and generate the exact same results as
running that P.

That emulation will show the first 7 instructions of P, then the call to
H, and then H doing its emulations and eventually aborting its emulaton
and returning the 0 to P and P halting.

If the H doesn't do this, then your H never answered H(P,P) as 0, and
your whole premise is false, and shown to be a LIE.

>
>> [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!
>
> My unlimited nested simulations could not function properly if I did not
> know all of the details of how to do this.

Then why do you think the UTM sees another UTM when it should see an H.

Remember, your LIE that the test was to REPLACE H with a UTM has been
discredited, or are you still claiming that is what needs to be done,
even though it doesn't match the test you define?

Or, do you not understand that the representation of P includes
EVERYTHING needed to run it, and thus does include the copy of H that it
calls, so it doesn't change when we give that input to the UTM?

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