On 1/11/24 12:14, Mike Terry wrote:
> On 10/01/2024 07:16, immibis wrote:
>> On 1/10/24 04:36, Mike Terry wrote:
>>> On 09/01/2024 23:54, immibis wrote:
>>>>
>>>> Your simulator does an incorrect simulation because of the
>>>> undeclared input of execution history into the inner simulation.
>>>>
>>>
>>> I think you may be off base on your exact explanation here.
>>>
>>> It's some time since I looked in any detail at PO's code and traces,
>>> but when I last did that it seemed to me that at the step-by-step x86
>>> instruction level the simulation was ok.  The problem is that H stops
>>> simulating before the simulated computation halts, on the grounds
>>> that it has spotted the "PO infinitely recursive simulation pattern".
>>
>> Yes.
>>
>>> UP TO THAT POINT the simulation faithfully tracks the states of the
>>> actual computation, which continues from that point for a while and
>>> then terminates normally.  [..as seen when running D(D) "directly"]
>>
>> Well, sort of. The simulator refuses to simulate the simulator, and
>> instead does something like incrementing a "simulation level" variable
>> and then simulating the code the inner simulator would have simulated.
>
> I think we diverge here.  Perhaps...  I would say PO's code "simulates
> the simulator" in a reasonable way we could accept for current
> purposes.  (At least for the purposes of discussing where he is going
> wrong - IF he went as far as submitting a formal paper to a journal, all
> sorts of lesser problems would need addressing regarding the validity of
> his approach and his x86utm design (sharing the main code/data across
> all simulation levels, use of complex x86 instruction set etc.), but
> that's never going to happen and meanwhile I don't believe these issues
> are the source of any actual problems in his results.  He has much
> simpler basic misunderstandings.)
>
> The basic limitations of PO's x86utm design:
> -  all simulations share a single address space with shared code and data
> -  the x86-level instruction simulation is housed in x86utm.exe as
> opposed to
>    what I'll call the user (code/data) space, where H,D,H1, code and
> stack space and
>    (perhaps) global data reside
> -  simulation single-stepping etc. is provided as primitives by x86utm
> to user space code.
>    (since address space is shared, and register save space used by
> primitives is in the
>    user address space, simulators can monitor the progress of their
> simulations)
> I think nested simulation works sort of ok given the above architecture
> - but also see my very final comment below...
>
> Also I think there's divergence among posters here re what counts as
> "simulation", so that might be a source of misunderstanding?  I prefer
> "simulation" to mean simply the act of calculating the state changes in
> a computation, with the understanding that a program might simulate just
> (say) 10 steps of a computation, and then stop for whatever reason.  I'd
> say that simulation activity was "correct" if those 10 steps were
> calculated correctly i.e. they track the first 10 actual computation steps.
>
> The program will of course perform many other calculations and make
> other decisions (e.g. the counting to 10 or other tests to decide when
> to stop simulating, deciding on its own return code) - but I don't count
> those  "simulating" or part of the simulator.  I.e. the simulator is
> just a component the program uses.  If the program simulates 10 steps
> correctly then stops simulating, the /simulation/ was correct, and if
> the program proceeds to announce that the computation would never halt,
> when in fact it would, that doesn't change that it correctly simulated
> the 10 steps - the fault lies in the non-simulating code of the
> program.  [Well, that's how I'd express things...]
>
> Perhaps you use "simulate" in a broader sense, e.g. to include ALL the
> code in H including what I'd consider business logic (which for H I'd
> label "termination analysis")?  So when you say "the simulator /refuses/
> to simulate the simulator", maybe you're just saying H is coded to abort
> its simulation too early due to a false positive match with its unsound
> recursion test.  [I agree with that.]  But to me I'm reading it as
> saying x86utm doesn't properly support nested simulation in some way,
> whereas to me it seems it does!
>
> E.g. suppose we run H1(D,D).  [H1 is the copy of H, but with a modified
> abort condition that means in effect it never matches when analysing
> (D,D) input...]
> When H1 simulates D(D), it simulates:
> -  D calling H,
> -  H simulating D(D) - including the simulation primitives within H, and
> all the termination
>    analysis code such as PO's infinite recursion testing code, abort
> decision code and so on.
> -  the simulated simulation being aborted by the simulated H,
> -  H returning to D [telling simulated D that D(D) never halts!],
> -  D reaching its final ret, i.e. halting.
>
> Perfect - no issues I can see with nesting of simulations or invalid
> secret data feeds to inner simulations altering the course of the inner
> simulations or anything like that.
>
> The problem when running H(D,D) is simply that while (correctly)
> simulating D(D), [outer] H spots PO's "infinite recursion" pattern
> [which DOES NOT ACTUALLY TEST FOR INFINITE RECURSION despite PO's name
> for the test] and aborts the simulation, announcing incorrectly that
> D(D) doesn't halt when it does.
>
> That's hardly the fault of the correct (partial) simulation - it's the
> fault of the faulty termination analysis logic in H, namely relience use
> of PO's unsound "infinite recursion" pattern. Er, that's it!
>
>>
>> A true simulation of the simulator would find that the simulator
>> eventually detects the infinite recursion pattern, and then halts.
>
> And it does, e.g. when we run H1(D,D) as above.
>
> In my terminology, when running H(D,D) H "correctly" simulates D(D) for
> a while, but then applies an unsound test that matches its generated
> simulation trace, so it incorrectly concludes its simulation of D(D) "IF
> continued" would never halt.  Actually I'm being sloppy: *H* assumes no
> such thing as it's just code.  The incorrect assumption is PO's, as the
> designer.
>
> The point I'd make is that the /reason/ H1 sees simulated D(D) halt
> while H decides it never halts is nothing to do with incorrect nested
> simulation implementation causing nested simulations to behave
> differently from outer simulations - like due to invalid use of global
> data leaking in, or whatever.  AFAICT regardless of the simulation
> depth, all the simulations behave exactly the same [up to the point the
> simulation is aborted of course].  This is where I suspect you diverge?
>
> I think your "true simulator" = my "full simulator" = "simulates to
> completion"?  PO's H is obviously not a "true simulator" in that sense
> and PO has never claimed that.  PO claims his H "correctly simulates"
> D(D) which fits my usage, although his often repeated "..until H
> correctly decides that its simulation would never end..." bit doesn't
> apply - H actually /incorrectly/ decides blah blah, since it relied on
> his unsound infinite recursion test.
>
>> Olcott's simulator instead behaves as if it knows that the simulator
>> never halts, which is an obviously untrue fact and a self-delusion of
>> Olcott.
>
> Hmm.  I'll read that as "PO's "H" behaves as if it knows...".  But H is
> just code, and doesn't do "as if" or "knowing" (of course).  Those ideas
> may well be in PO's mind, as /designer/ for H, and readers may benefit
> from that insight.
>
> But what actually happens?  H applies an unsound test which matches (a
> false-positive), leading it to incorrectly announce that computation
> D(D) never halts.  That seems a simple account of what's going on.
>
>>
>>>
>>> PO is really really really convinced (despite concrete evidence
>>> showing otherwise) that his infinite recursion pattern gives a sound
>>> non-halting test, but he is just wrong - it does not imply non-halting.
>>
>> Infinite recursion does imply non-halting, but it's detected in a way
>> that is obviously incorrect.
>
> Exactly.  PO's "infinite recursive simulation" test is unsound.  It can
> match both halting and non-halting computations.
>
>>
>> If the simulator simulated the simulator, it would end up in an
>> infinitely nested simulation stack that would obviously never finish.
>> That would be obvious, and a human looking at the program could see
>> that it could never finish (thus acting as a correct halting decider
>> for this particular program).
>>
>> In actuality, the program behaves as if the nested simulation is
>> launched with different parameters from the outer simulation. One way
>> to interpret this is that the nested simulation is launched with some
>> execution history, so that it will behave differently than specified
>> if it detects that a nested simulator is launched inside it (a
>> double-nested simulator).
>
> I don't really follow much of that.  x86utm design seems to me to allow
> correct simulation of the simulating code and surrounding abort code
> etc..  I would say
>
> "In actuality the program "behaves" exactly as it is coded :), with no
> imagined changed parameters, and inner simulations behave just like
> their corresponding computations, except the simulation may be partial
> due to outer code deciding to abort.  The program H gives the wrong
> answer, because it utilises an unsound abort test, and aborts before the
> D(D) final ret."
>
> And the H1(D,D) example shows that "If the simulator simulated the
> simulator, it /wouldn't/ end up in an infinitely nested simulation"
> necessarily.  (Obviously this depends on the remaining non-simulation
> code.)
>
> I could be persuaded to say something like "PO /designed/ H with an
> incorrect understanding that D(D) simulation would continue with
> infinite recursion, just as if H were called with different parameters
> [e.g. as though it was called as H(D_FULL_SIMULATOR,
> D_FULL_SIMULATOR)].  But do we care what PO believed when he designed H;
> it's what actually happens at run time, and why, that matters...
>
> I expect everyone agrees D_FULL_SIMULATOR(D_FULL_SIMULATOR) never halts,
> but we know that's not the D(D) computation.  And FULL_SIMULATOR
> (D_FULL_SIMULATOR, D_FULL_SIMULATOR) never returns, so falls at the
> first hurdle as a HD candidate.  [If this is all you meant, I think your
> wording is confusing to the point of, um, something really confusing
> that doesn't help anybody! :) ]
>
>>
>>    Other tests
>>> coded in his H may (likely) be sound, such as a "tight loop test",
>>> but the one that matches in the D(D) simulation by H is unsound.
>>> Anyway, PO believes it is sound, so for PO there is no debate: once H
>>> detects the pattern in the simulated D(D) trace that is (to PO)
>>> "proof" that D(D) (at least "when correctly simulated by H" whatever
>>> that means) is non-halting.  Since he acknowledges that D(D) run
>>> independently DOES halt, he has to invent further ridiculous
>>> explanations to explain that away
>>
>> Yes, I find that to be the most ridiculous part. It's obvious that
>> H(D,D) says it doesn't halt. It's obvious that D(D) does halt.
>> Therefore it's obvious that H(D,D) is lying. This is an extremely
>> basic and obvious fact which is staring Olcott in the face, but I
>> suppose he can't just give up on 20 years of bullshit in an instant.
>>
>> - all the stuff about "different questions depending on who is
>>> being asked". To repeat my point above - regardless of who is asked,
>>> PO's simulation follows the same correct sequence of steps UP TO THE
>>> POINT where askee stops the simulation.  No difference in the
>>> simulated D(D) steps, only in the surrounding conditional code (e.g.
>>> in H) driving the simulation steps.
>>
>> Actually I don't believe the simulator correctly simulates a nested
>> simulation.
>
> ??  It seems to me that it does ok, and I have no unexplained
> observations.  BUT since PO's current H code aborts before deep nesting
> gets going, perhaps in the end you're right!  At one point in PO's
> development he had all simulation levels accessing the ENTIRE trace
> history, including history for outer processes.  That's a definite show
> stopper, but I understand (maybe incorrectly?) he fixed that so that
> inner traces only saw their own simulation activity trace entries (and
> also those of more deeply nested traces).  Also I doubt current code is
> what I looked at 18 months ago.
>
> Perhaps PO should confirm...
>
> Mike.

On 1/11/24 12:24 AM, olcott wrote:
> On 1/10/2024 10:14 PM, Mike Terry wrote:
>> On 10/01/2024 07:16, immibis wrote:
>>> On 1/10/24 04:36, Mike Terry wrote:
>>>> On 09/01/2024 23:54, immibis wrote:
>>>>>
>>>>> Your simulator does an incorrect simulation because of the
>>>>> undeclared input of execution history into the inner simulation.
>>>>>
>>>>
>>>> I think you may be off base on your exact explanation here.
>>>>
>>>> It's some time since I looked in any detail at PO's code and traces,
>>>> but when I last did that it seemed to me that at the step-by-step
>>>> x86 instruction level the simulation was ok.  The problem is that H
>>>> stops simulating before the simulated computation halts, on the
>>>> grounds that it has spotted the "PO infinitely recursive simulation
>>>> pattern".
>>>
>>> Yes.
>>>
>>>> UP TO THAT POINT the simulation faithfully tracks the states of the
>>>> actual computation, which continues from that point for a while and
>>>> then terminates normally.  [..as seen when running D(D) "directly"]
>>>
>>> Well, sort of. The simulator refuses to simulate the simulator, and
>>> instead does something like incrementing a "simulation level"
>>> variable and then simulating the code the inner simulator would have
>>> simulated.
>>
>
> *Mike has a very thorough not quite perfectly correct analysis*
> (see below)
>
>> I think we diverge here.  Perhaps...  I would say PO's code "simulates
>> the simulator" in a reasonable way we could accept for current
>> purposes.  (At least for the purposes of discussing where he is going
>> wrong - IF he went as far as submitting a formal paper to a journal,
>> all sorts of lesser problems would need addressing regarding the
>> validity of his approach and his x86utm design (sharing the main
>> code/data across all simulation levels, use of complex x86 instruction
>> set etc.), but that's never going to happen and meanwhile I don't
>> believe these issues are the source of any actual problems in his
>> results.  He has much simpler basic misunderstandings.)
>>
>> The basic limitations of PO's x86utm design:
>> -  all simulations share a single address space with shared code and data
>> -  the x86-level instruction simulation is housed in x86utm.exe as
>> opposed to
>>     what I'll call the user (code/data) space, where H,D,H1, code and
>> stack space and
>>     (perhaps) global data reside
>> -  simulation single-stepping etc. is provided as primitives by x86utm
>> to user space code.
>>     (since address space is shared, and register save space used by
>> primitives is in the
>>     user address space, simulators can monitor the progress of their
>> simulations)
>> I think nested simulation works sort of ok given the above
>> architecture - but also see my very final comment below...
>>
>> Also I think there's divergence among posters here re what counts as
>> "simulation", so that might be a source of misunderstanding?  I prefer
>> "simulation" to mean simply the act of calculating the state changes
>> in a computation, with the understanding that a program might simulate
>> just (say) 10 steps of a computation, and then stop for whatever
>> reason.  I'd say that simulation activity was "correct" if those 10
>> steps were calculated correctly i.e. they track the first 10 actual
>> computation steps.
>>
>> The program will of course perform many other calculations and make
>> other decisions (e.g. the counting to 10 or other tests to decide when
>> to stop simulating, deciding on its own return code) - but I don't
>> count those  "simulating" or part of the simulator.  I.e. the
>> simulator is just a component the program uses.  If the program
>> simulates 10 steps correctly then stops simulating, the /simulation/
>> was correct, and if the program proceeds to announce that the
>> computation would never halt, when in fact it would, that doesn't
>> change that it correctly simulated the 10 steps - the fault lies in
>> the non-simulating code of the program.  [Well, that's how I'd express
>> things...]
>>
>> Perhaps you use "simulate" in a broader sense, e.g. to include ALL the
>> code in H including what I'd consider business logic (which for H I'd
>> label "termination analysis")?  So when you say "the simulator
>> /refuses/ to simulate the simulator", maybe you're just saying H is
>> coded to abort its simulation too early due to a false positive match
>> with its unsound recursion test.  [I agree with that.]  But to me I'm
>> reading it as saying x86utm doesn't properly support nested simulation
>> in some way, whereas to me it seems it does!
>>
>> E.g. suppose we run H1(D,D).  [H1 is the copy of H, but with a
>> modified abort condition that means in effect it never matches when
>> analysing (D,D) input...]
>
> H1 is the exact same code as H exact that D does not call H1.

And it checks for calls to H1 instead of calls to H.

Your code model is just incorrect, and you aren't working in a Turing
Equivalent space, because you don't understand what it means.

>
>> When H1 simulates D(D), it simulates:
>> -  D calling H,
>> -  H simulating D(D) - including the simulation primitives within H,
>> and all the termination
>>     analysis code such as PO's infinite recursion testing code, abort
>> decision code and so on.
>> -  the simulated simulation being aborted by the simulated H,
>> -  H returning to D [telling simulated D that D(D) never halts!],
>> -  D reaching its final ret, i.e. halting.
>>
>> Perfect - no issues I can see with nesting of simulations or invalid
>> secret data feeds to inner simulations altering the course of the
>> inner simulations or anything like that.
>>
>> The problem when running H(D,D) is simply that while (correctly)
>> simulating D(D), [outer] H spots PO's "infinite recursion" pattern
>> [which DOES NOT ACTUALLY TEST FOR INFINITE RECURSION despite PO's name
>> for the test] and aborts the simulation, announcing incorrectly that
>> D(D) doesn't halt when it does.
>
> 04 int D(ptr x)
> 05 {
> 06   int Halt_Status = H(x, x);
> 07   if (Halt_Status)
> 08     HERE: goto HERE;
> 09   return Halt_Status;
> 10 }
>
> That no one can possibly provide the exact sequence of
> the execution trace D correctly simulated by H such
> that this simulated D reaches its own line 09 conclusively
> proves that D correctly simulated by H never halts.

Which is exactly the quesiton of "Does the Barber that shaves everyone
that doesn't shave themselves shave himself?"

There is no H possible that "Correctly Simulates" its input AND returns
an answer, so YOUR question is an invalid question, and you logic is
based on unsound reasoning.

You, it seems, are similarly unsound, so can't see this fact.

>
> Every rebuttal to this has always been the pure bluster
> of dogma with zero supporting exact execution trace.

Nope, YOUR statement has been pure bluster of FASLSE dogma.

The fact that you admit that D(D) Halts when its H(D,D) returns 0, that
that H can't have been correct, and you know your claims to be false.

>
>> That's hardly the fault of the correct (partial) simulation - it's the
>> fault of the faulty termination analysis logic in H, namely relience
>> use of PO's unsound "infinite recursion" pattern. Er, that's it!
>>
>>>
>>> A true simulation of the simulator would find that the simulator
>>> eventually detects the infinite recursion pattern, and then halts.
>>
>> And it does, e.g. when we run H1(D,D) as above.
>>
>> In my terminology, when running H(D,D) H "correctly" simulates D(D)
>> for a while, but then applies an unsound test that matches its
>> generated simulation trace, so it incorrectly concludes its simulation
>> of D(D) "IF continued" would never halt.  Actually I'm being sloppy:
>> *H* assumes no such thing as it's just code.  The incorrect assumption
>> is PO's, as the designer.
>>
>> The point I'd make is that the /reason/ H1 sees simulated D(D) halt
>> while H decides it never halts is nothing to do with incorrect nested
>> simulation implementation causing nested simulations to behave
>> differently from outer simulations - like due to invalid use of global
>> data leaking in, or whatever.  AFAICT regardless of the simulation
>> depth, all the simulations behave exactly the same [up to the point
>> the simulation is aborted of course].  This is where I suspect you
>> diverge?
>>
>> I think your "true simulator" = my "full simulator" = "simulates to
>> completion"?  PO's H is obviously not a "true simulator" in that sense
>> and PO has never claimed that.  PO claims his H "correctly simulates"
>> D(D) which fits my usage, although his often repeated "..until H
>> correctly decides that its simulation would never end..." bit doesn't
>> apply - H actually /incorrectly/ decides blah blah, since it relied on
>> his unsound infinite recursion test.
>>
>>> Olcott's simulator instead behaves as if it knows that the simulator
>>> never halts, which is an obviously untrue fact and a self-delusion of
>>> Olcott.
>>
>> Hmm.  I'll read that as "PO's "H" behaves as if it knows...".  But H
>> is just code, and doesn't do "as if" or "knowing" (of course).  Those
>> ideas may well be in PO's mind, as /designer/ for H, and readers may
>> benefit from that insight.
>>
>> But what actually happens?  H applies an unsound test which matches (a
>> false-positive), leading it to incorrectly announce that computation
>> D(D) never halts.  That seems a simple account of what's going on.
>>
>
> I just proved that D correctly simulated by H never reaches its own line
> 09 in N to infinitely steps of correct simulation. Actual C code would
> run out of stack space and still not reach line 09.

On 1/11/2024 3:53 AM, wij wrote:
> On 1/11/24 12:14, Mike Terry wrote:
>> On 10/01/2024 07:16, immibis wrote:
>>> On 1/10/24 04:36, Mike Terry wrote:
>>>> On 09/01/2024 23:54, immibis wrote:
>>>>>
>>>>> Your simulator does an incorrect simulation because of the
>>>>> undeclared input of execution history into the inner simulation.
>>>>>
>>>>
>>>> I think you may be off base on your exact explanation here.
>>>>
>>>> It's some time since I looked in any detail at PO's code and traces,
>>>> but when I last did that it seemed to me that at the step-by-step
>>>> x86 instruction level the simulation was ok.  The problem is that H
>>>> stops simulating before the simulated computation halts, on the
>>>> grounds that it has spotted the "PO infinitely recursive simulation
>>>> pattern".
>>>
>>> Yes.
>>>
>>>> UP TO THAT POINT the simulation faithfully tracks the states of the
>>>> actual computation, which continues from that point for a while and
>>>> then terminates normally.  [..as seen when running D(D) "directly"]
>>>
>>> Well, sort of. The simulator refuses to simulate the simulator, and
>>> instead does something like incrementing a "simulation level"
>>> variable and then simulating the code the inner simulator would have
>>> simulated.
>>
>> I think we diverge here.  Perhaps...  I would say PO's code "simulates
>> the simulator" in a reasonable way we could accept for current
>> purposes.  (At least for the purposes of discussing where he is going
>> wrong - IF he went as far as submitting a formal paper to a journal,
>> all sorts of lesser problems would need addressing regarding the
>> validity of his approach and his x86utm design (sharing the main
>> code/data across all simulation levels, use of complex x86 instruction
>> set etc.), but that's never going to happen and meanwhile I don't
>> believe these issues are the source of any actual problems in his
>> results.  He has much simpler basic misunderstandings.)
>>
>> The basic limitations of PO's x86utm design:
>> -  all simulations share a single address space with shared code and data
>> -  the x86-level instruction simulation is housed in x86utm.exe as
>> opposed to
>>     what I'll call the user (code/data) space, where H,D,H1, code and
>> stack space and
>>     (perhaps) global data reside
>> -  simulation single-stepping etc. is provided as primitives by x86utm
>> to user space code.
>>     (since address space is shared, and register save space used by
>> primitives is in the
>>     user address space, simulators can monitor the progress of their
>> simulations)
>> I think nested simulation works sort of ok given the above
>> architecture - but also see my very final comment below...
>>
>> Also I think there's divergence among posters here re what counts as
>> "simulation", so that might be a source of misunderstanding?  I prefer
>> "simulation" to mean simply the act of calculating the state changes
>> in a computation, with the understanding that a program might simulate
>> just (say) 10 steps of a computation, and then stop for whatever
>> reason.  I'd say that simulation activity was "correct" if those 10
>> steps were calculated correctly i.e. they track the first 10 actual
>> computation steps.
>>
>> The program will of course perform many other calculations and make
>> other decisions (e.g. the counting to 10 or other tests to decide when
>> to stop simulating, deciding on its own return code) - but I don't
>> count those  "simulating" or part of the simulator.  I.e. the
>> simulator is just a component the program uses.  If the program
>> simulates 10 steps correctly then stops simulating, the /simulation/
>> was correct, and if the program proceeds to announce that the
>> computation would never halt, when in fact it would, that doesn't
>> change that it correctly simulated the 10 steps - the fault lies in
>> the non-simulating code of the program.  [Well, that's how I'd express
>> things...]
>>
>> Perhaps you use "simulate" in a broader sense, e.g. to include ALL the
>> code in H including what I'd consider business logic (which for H I'd
>> label "termination analysis")?  So when you say "the simulator
>> /refuses/ to simulate the simulator", maybe you're just saying H is
>> coded to abort its simulation too early due to a false positive match
>> with its unsound recursion test.  [I agree with that.]  But to me I'm
>> reading it as saying x86utm doesn't properly support nested simulation
>> in some way, whereas to me it seems it does!
>>
>> E.g. suppose we run H1(D,D).  [H1 is the copy of H, but with a
>> modified abort condition that means in effect it never matches when
>> analysing (D,D) input...]
>> When H1 simulates D(D), it simulates:
>> -  D calling H,
>> -  H simulating D(D) - including the simulation primitives within H,
>> and all the termination
>>     analysis code such as PO's infinite recursion testing code, abort
>> decision code and so on.
>> -  the simulated simulation being aborted by the simulated H,
>> -  H returning to D [telling simulated D that D(D) never halts!],
>> -  D reaching its final ret, i.e. halting.
>>
>> Perfect - no issues I can see with nesting of simulations or invalid
>> secret data feeds to inner simulations altering the course of the
>> inner simulations or anything like that.
>>
>> The problem when running H(D,D) is simply that while (correctly)
>> simulating D(D), [outer] H spots PO's "infinite recursion" pattern
>> [which DOES NOT ACTUALLY TEST FOR INFINITE RECURSION despite PO's name
>> for the test] and aborts the simulation, announcing incorrectly that
>> D(D) doesn't halt when it does.
>>
>> That's hardly the fault of the correct (partial) simulation - it's the
>> fault of the faulty termination analysis logic in H, namely relience
>> use of PO's unsound "infinite recursion" pattern. Er, that's it!
>>
>>>
>>> A true simulation of the simulator would find that the simulator
>>> eventually detects the infinite recursion pattern, and then halts.
>>
>> And it does, e.g. when we run H1(D,D) as above.
>>
>> In my terminology, when running H(D,D) H "correctly" simulates D(D)
>> for a while, but then applies an unsound test that matches its
>> generated simulation trace, so it incorrectly concludes its simulation
>> of D(D) "IF continued" would never halt.  Actually I'm being sloppy:
>> *H* assumes no such thing as it's just code.  The incorrect assumption
>> is PO's, as the designer.
>>
>> The point I'd make is that the /reason/ H1 sees simulated D(D) halt
>> while H decides it never halts is nothing to do with incorrect nested
>> simulation implementation causing nested simulations to behave
>> differently from outer simulations - like due to invalid use of global
>> data leaking in, or whatever.  AFAICT regardless of the simulation
>> depth, all the simulations behave exactly the same [up to the point
>> the simulation is aborted of course].  This is where I suspect you
>> diverge?
>>
>> I think your "true simulator" = my "full simulator" = "simulates to
>> completion"?  PO's H is obviously not a "true simulator" in that sense
>> and PO has never claimed that.  PO claims his H "correctly simulates"
>> D(D) which fits my usage, although his often repeated "..until H
>> correctly decides that its simulation would never end..." bit doesn't
>> apply - H actually /incorrectly/ decides blah blah, since it relied on
>> his unsound infinite recursion test.
>>
>>> Olcott's simulator instead behaves as if it knows that the simulator
>>> never halts, which is an obviously untrue fact and a self-delusion of
>>> Olcott.
>>
>> Hmm.  I'll read that as "PO's "H" behaves as if it knows...".  But H
>> is just code, and doesn't do "as if" or "knowing" (of course).  Those
>> ideas may well be in PO's mind, as /designer/ for H, and readers may
>> benefit from that insight.
>>
>> But what actually happens?  H applies an unsound test which matches (a
>> false-positive), leading it to incorrectly announce that computation
>> D(D) never halts.  That seems a simple account of what's going on.
>>
>>>
>>>>
>>>> PO is really really really convinced (despite concrete evidence
>>>> showing otherwise) that his infinite recursion pattern gives a sound
>>>> non-halting test, but he is just wrong - it does not imply non-halting.
>>>
>>> Infinite recursion does imply non-halting, but it's detected in a way
>>> that is obviously incorrect.
>>
>> Exactly.  PO's "infinite recursive simulation" test is unsound.  It
>> can match both halting and non-halting computations.
>>
>>>
>>> If the simulator simulated the simulator, it would end up in an
>>> infinitely nested simulation stack that would obviously never finish.
>>> That would be obvious, and a human looking at the program could see
>>> that it could never finish (thus acting as a correct halting decider
>>> for this particular program).
>>>
>>> In actuality, the program behaves as if the nested simulation is
>>> launched with different parameters from the outer simulation. One way
>>> to interpret this is that the nested simulation is launched with some
>>> execution history, so that it will behave differently than specified
>>> if it detects that a nested simulator is launched inside it (a
>>> double-nested simulator).
>>
>> I don't really follow much of that.  x86utm design seems to me to
>> allow correct simulation of the simulating code and surrounding abort
>> code etc..  I would say
>>
>> "In actuality the program "behaves" exactly as it is coded :), with no
>> imagined changed parameters, and inner simulations behave just like
>> their corresponding computations, except the simulation may be partial
>> due to outer code deciding to abort.  The program H gives the wrong
>> answer, because it utilises an unsound abort test, and aborts before
>> the D(D) final ret."
>>
>> And the H1(D,D) example shows that "If the simulator simulated the
>> simulator, it /wouldn't/ end up in an infinitely nested simulation"
>> necessarily.  (Obviously this depends on the remaining non-simulation
>> code.)
>>
>> I could be persuaded to say something like "PO /designed/ H with an
>> incorrect understanding that D(D) simulation would continue with
>> infinite recursion, just as if H were called with different parameters
>> [e.g. as though it was called as H(D_FULL_SIMULATOR,
>> D_FULL_SIMULATOR)].  But do we care what PO believed when he designed
>> H; it's what actually happens at run time, and why, that matters...
>>
>> I expect everyone agrees D_FULL_SIMULATOR(D_FULL_SIMULATOR) never
>> halts, but we know that's not the D(D) computation.  And
>> FULL_SIMULATOR (D_FULL_SIMULATOR, D_FULL_SIMULATOR) never returns, so
>> falls at the first hurdle as a HD candidate.  [If this is all you
>> meant, I think your wording is confusing to the point of, um,
>> something really confusing that doesn't help anybody! :) ]
>>
>>>
>>>    Other tests
>>>> coded in his H may (likely) be sound, such as a "tight loop test",
>>>> but the one that matches in the D(D) simulation by H is unsound.
>>>> Anyway, PO believes it is sound, so for PO there is no debate: once
>>>> H detects the pattern in the simulated D(D) trace that is (to PO)
>>>> "proof" that D(D) (at least "when correctly simulated by H" whatever
>>>> that means) is non-halting.  Since he acknowledges that D(D) run
>>>> independently DOES halt, he has to invent further ridiculous
>>>> explanations to explain that away
>>>
>>> Yes, I find that to be the most ridiculous part. It's obvious that
>>> H(D,D) says it doesn't halt. It's obvious that D(D) does halt.
>>> Therefore it's obvious that H(D,D) is lying. This is an extremely
>>> basic and obvious fact which is staring Olcott in the face, but I
>>> suppose he can't just give up on 20 years of bullshit in an instant.
>>>
>>> - all the stuff about "different questions depending on who is
>>>> being asked". To repeat my point above - regardless of who is asked,
>>>> PO's simulation follows the same correct sequence of steps UP TO THE
>>>> POINT where askee stops the simulation.  No difference in the
>>>> simulated D(D) steps, only in the surrounding conditional code (e.g.
>>>> in H) driving the simulation steps.
>>>
>>> Actually I don't believe the simulator correctly simulates a nested
>>> simulation.
>>
>> ??  It seems to me that it does ok, and I have no unexplained
>> observations.  BUT since PO's current H code aborts before deep
>> nesting gets going, perhaps in the end you're right!  At one point in
>> PO's development he had all simulation levels accessing the ENTIRE
>> trace history, including history for outer processes.  That's a
>> definite show stopper, but I understand (maybe incorrectly?) he fixed
>> that so that inner traces only saw their own simulation activity trace
>> entries (and also those of more deeply nested traces).  Also I doubt
>> current code is what I looked at 18 months ago.
>>
>> Perhaps PO should confirm...
>>
>> Mike.
>
>
>
> He knows everything he was told (but olcott had shown several times he
> don't even understand logic AND and
> IMPLICATION),he just don't like those answers. When he was shown the
> wiki's definition of Halting Problem, he purposefully twists what is
> written... So, all those words from people are just pieces of cake.... a
> long
> story... He can cheat/blind himself.
>
> In all, olcott can't distinguish what is logically right and wrong.
> Every thing is based on oral words or
> hearsay and feeling, the louder the more promising, the many the more
> sound, similar to the 0.999.. mystery
>  to many people :)
>
> This is the picture I imagined: One day, olcott had an idea that he spot
> something no one can see, that he
> can refute the well known HP theorem (exactly because it is so easy to
> understand). And he figured out he
> had a big chance of success for the easy 50% yes/no question, but he
> don't know how to make the brilliant
> idea accepted and also worried about ’plagiarism‘. So, he registered
> patent first and then started by
> halfway-asking, halfway-announcing the rebuttal of HP, hoping that
> someone will 'leak' (not plagiarism)
> something to him.... Anyway, what olcott need is something that can help
> him to fulfill the goal, anything
> else is obstacle he should conquer. He DON'T want to UNDERSTAND the HP.
> He wants the help to successfully
> refute HP.
>
> I did not object olcott's post, because he tried hard to refute the HP,
> it helped people to understand the
> HP more (including me, anyone engaged the discussion).
>
> Note: This reply is also a test post, I just changed to use Thunderbird.

On 1/9/2024 9:02 PM, immibis wrote:
> On 1/10/24 03:58, olcott wrote:
>> On 1/9/2024 8:17 PM, immibis wrote:
>>> On 1/10/24 01:44, olcott wrote:
>>>> On 1/9/2024 5:54 PM, immibis wrote:
>>>>> On 1/9/24 15:01, olcott wrote:
>>>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>>>> Premises:
>>>>>>>
>>>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>>>
>>>>>>> Conclusion:
>>>>>>>
>>>>>>> 3. The halting problem can't be solved.
>>>>>>
>>>>>> When D is intentionally defined to do the opposite of
>>>>>> whatever Boolean value that H returns then input D <is>
>>>>>> absolutely self-contradictory to termination analyzer H
>>>>>> when H is required to report on the behavior of the
>>>>>> directly executed D.
>>>>>>
>>>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>>>> *paragraph is correct*
>>>>>> (a) If simulating halt decider H correctly simulates its input D
>>>>>> until H
>>>>>> correctly determines that its simulated D would never stop running
>>>>>> unless aborted then
>>>>>
>>>>> Your simulator does an incorrect simulation because of the
>>>>> undeclared input of execution history into the inner simulation.
>>>>
>>>> If it was incorrect then you could show the exact sequence that
>>>> should be simulated.
>>>
>>> I could, but why should I do more work when less work is already good
>>> enough? It wouldn't prove anything that wasn't already proved. I'd
>>> have to download your simulator, check it for viruses, figure out how
>>> it works, then change it.
>>>
>>>> You already said that the simulated D should call the simulated H.
>>>>
>>>> You know that when it does this that D correctly simulated by H cannot
>>> possible reach its own line 09 and terminate normally (AKA halt).
>>>>
>>>
>>> That's right.
>>>
>>
>> *That is better than anyone else has ever understood*
>>
> We all understand it, except you.
>
> You refuse to acknowledge this point:
>
> **The correct simulation of a program returns the same result as its
> direct execution.**

04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 H(D,D);
15 }

*Execution Trace*
Line 14: main() invokes H(D,D);

*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 06

*Every rebuttal to this has always been the pure bluster*
*of dogma with zero supporting exact execution trace*

IF A CORRECT EXECUTION TRACE THAT REACHES LINE 09 OF D CANNOT
POSSIBLY BE PROVIDED THAT PROVES THE ABOVE TRACE IS CORRECT.

Internet trolls will try and get away with saying that
they don't need to provide such a trace because they
"just know" that I am wrong. This proves that they are liars.

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

On 11/01/2024 05:24, olcott wrote:
> On 1/10/2024 10:14 PM, Mike Terry wrote:
>> On 10/01/2024 07:16, immibis wrote:
>>> On 1/10/24 04:36, Mike Terry wrote:
>>>> On 09/01/2024 23:54, immibis wrote:
>>>>>
>>>>> Your simulator does an incorrect simulation because of the undeclared input of execution
>>>>> history into the inner simulation.
>>>>>
>>>>
>>>> I think you may be off base on your exact explanation here.
>>>>
>>>> It's some time since I looked in any detail at PO's code and traces, but when I last did that it
>>>> seemed to me that at the step-by-step x86 instruction level the simulation was ok.  The problem
>>>> is that H stops simulating before the simulated computation halts, on the grounds that it has
>>>> spotted the "PO infinitely recursive simulation pattern".
>>>
>>> Yes.
>>>
>>>> UP TO THAT POINT the simulation faithfully tracks the states of the actual computation, which
>>>> continues from that point for a while and then terminates normally.  [..as seen when running
>>>> D(D) "directly"]
>>>
>>> Well, sort of. The simulator refuses to simulate the simulator, and instead does something like
>>> incrementing a "simulation level" variable and then simulating the code the inner simulator would
>>> have simulated.
>>
>
> *Mike has a very thorough not quite perfectly correct analysis*
> (see below)

In many respects my understanding of your code is better than yours, so I've corrected a couple of
your "corrections" below, just for the record...

>
>> I think we diverge here.  Perhaps...  I would say PO's code "simulates the simulator" in a
>> reasonable way we could accept for current purposes.  (At least for the purposes of discussing
>> where he is going wrong - IF he went as far as submitting a formal paper to a journal, all sorts
>> of lesser problems would need addressing regarding the validity of his approach and his x86utm
>> design (sharing the main code/data across all simulation levels, use of complex x86 instruction
>> set etc.), but that's never going to happen and meanwhile I don't believe these issues are the
>> source of any actual problems in his results.  He has much simpler basic misunderstandings.)
>>
>> The basic limitations of PO's x86utm design:
>> -  all simulations share a single address space with shared code and data
>> -  the x86-level instruction simulation is housed in x86utm.exe as opposed to
>>     what I'll call the user (code/data) space, where H,D,H1, code and stack space and
>>     (perhaps) global data reside
>> -  simulation single-stepping etc. is provided as primitives by x86utm to user space code.
>>     (since address space is shared, and register save space used by primitives is in the
>>     user address space, simulators can monitor the progress of their simulations)
>> I think nested simulation works sort of ok given the above architecture - but also see my very
>> final comment below...
>>
>> Also I think there's divergence among posters here re what counts as "simulation", so that might
>> be a source of misunderstanding?  I prefer "simulation" to mean simply the act of calculating the
>> state changes in a computation, with the understanding that a program might simulate just (say) 10
>> steps of a computation, and then stop for whatever reason.  I'd say that simulation activity was
>> "correct" if those 10 steps were calculated correctly i.e. they track the first 10 actual
>> computation steps.
>>
>> The program will of course perform many other calculations and make other decisions (e.g. the
>> counting to 10 or other tests to decide when to stop simulating, deciding on its own return code)
>> - but I don't count those  "simulating" or part of the simulator.  I.e. the simulator is just a
>> component the program uses.  If the program simulates 10 steps correctly then stops simulating,
>> the /simulation/ was correct, and if the program proceeds to announce that the computation would
>> never halt, when in fact it would, that doesn't change that it correctly simulated the 10 steps -
>> the fault lies in the non-simulating code of the program.  [Well, that's how I'd express things...]
>>
>> Perhaps you use "simulate" in a broader sense, e.g. to include ALL the code in H including what
>> I'd consider business logic (which for H I'd label "termination analysis")?  So when you say "the
>> simulator /refuses/ to simulate the simulator", maybe you're just saying H is coded to abort its
>> simulation too early due to a false positive match with its unsound recursion test.  [I agree with
>> that.]  But to me I'm reading it as saying x86utm doesn't properly support nested simulation in
>> some way, whereas to me it seems it does!
>>
>> E.g. suppose we run H1(D,D).  [H1 is the copy of H, but with a modified abort condition that means
>> in effect it never matches when analysing (D,D) input...]
>
> H1 is the exact same code as H exact that D does not call H1.

No it's not. H1 monitors its simulation for occurences of address H1, H monitors for address H -
that even appears explicitly as a code difference - just diff the two routines!

>
>> When H1 simulates D(D), it simulates:
>> -  D calling H,
>> -  H simulating D(D) - including the simulation primitives within H, and all the termination
>>     analysis code such as PO's infinite recursion testing code, abort decision code and so on.
>> -  the simulated simulation being aborted by the simulated H,
>> -  H returning to D [telling simulated D that D(D) never halts!],
>> -  D reaching its final ret, i.e. halting.
>>
>> Perfect - no issues I can see with nesting of simulations or invalid secret data feeds to inner
>> simulations altering the course of the inner simulations or anything like that.
>>
>> The problem when running H(D,D) is simply that while (correctly) simulating D(D), [outer] H spots
>> PO's "infinite recursion" pattern [which DOES NOT ACTUALLY TEST FOR INFINITE RECURSION despite
>> PO's name for the test] and aborts the simulation, announcing incorrectly that D(D) doesn't halt
>> when it does.
>
> 04 int D(ptr x)
> 05 {
> 06   int Halt_Status = H(x, x);
> 07   if (Halt_Status)
> 08     HERE: goto HERE;
> 09   return Halt_Status;
> 10 }
>
> That no one can possibly provide the exact sequence of
> the execution trace D correctly simulated by H such
> that this simulated D reaches its own line 09 conclusively
> proves that D correctly simulated by H never halts.
>
> Every rebuttal to this has always been the pure bluster
> of dogma with zero supporting exact execution trace.
>
>> That's hardly the fault of the correct (partial) simulation - it's the fault of the faulty
>> termination analysis logic in H, namely relience use of PO's unsound "infinite recursion" pattern.
>> Er, that's it!
>>
>>>
>>> A true simulation of the simulator would find that the simulator eventually detects the infinite
>>> recursion pattern, and then halts.
>>
>> And it does, e.g. when we run H1(D,D) as above.
>>
>> In my terminology, when running H(D,D) H "correctly" simulates D(D) for a while, but then applies
>> an unsound test that matches its generated simulation trace, so it incorrectly concludes its
>> simulation of D(D) "IF continued" would never halt.  Actually I'm being sloppy: *H* assumes no
>> such thing as it's just code.  The incorrect assumption is PO's, as the designer.
>>
>> The point I'd make is that the /reason/ H1 sees simulated D(D) halt while H decides it never halts
>> is nothing to do with incorrect nested simulation implementation causing nested simulations to
>> behave differently from outer simulations - like due to invalid use of global data leaking in, or
>> whatever.  AFAICT regardless of the simulation depth, all the simulations behave exactly the same
>> [up to the point the simulation is aborted of course].  This is where I suspect you diverge?
>>
>> I think your "true simulator" = my "full simulator" = "simulates to completion"?  PO's H is
>> obviously not a "true simulator" in that sense and PO has never claimed that.  PO claims his H
>> "correctly simulates" D(D) which fits my usage, although his often repeated "..until H correctly
>> decides that its simulation would never end..." bit doesn't apply - H actually /incorrectly/
>> decides blah blah, since it relied on his unsound infinite recursion test.
>>
>>> Olcott's simulator instead behaves as if it knows that the simulator never halts, which is an
>>> obviously untrue fact and a self-delusion of Olcott.
>>
>> Hmm.  I'll read that as "PO's "H" behaves as if it knows...".  But H is just code, and doesn't do
>> "as if" or "knowing" (of course).  Those ideas may well be in PO's mind, as /designer/ for H, and
>> readers may benefit from that insight.
>>
>> But what actually happens?  H applies an unsound test which matches (a false-positive), leading it
>> to incorrectly announce that computation D(D) never halts.  That seems a simple account of what's
>> going on.
>>
>
> I just proved that D correctly simulated by H never reaches its own line
> 09 in N to infinitely steps of correct simulation. Actual C code would
> run out of stack space and still not reach line 09.
>
> As soon as H sees that D is calling itself with its same input then
> the proves that D never halts.
>
> HH actually simulates D calling its simulated self and sees the
> repeated state up to the point where the simulated HH would
> simulate another HH.
>
>>>
>>>>
>>>> PO is really really really convinced (despite concrete evidence showing otherwise) that his
>>>> infinite recursion pattern gives a sound non-halting test, but he is just wrong - it does not
>>>> imply non-halting.
>>>
>>> Infinite recursion does imply non-halting, but it's detected in a way that is obviously incorrect.
>>
>> Exactly.  PO's "infinite recursive simulation" test is unsound.  It can match both halting and
>> non-halting computations.
>
> That is factually incorrect. No one has been able to report
> any actual error in two years of review.

On 11/01/2024 09:53, wij wrote:
<..snip..>
>
> Note: This reply is also a test post, I just changed to use Thunderbird.

Glad you got it working!

I do wonder how many newbies in future years will come to Usenet.

At the moment, they can find e.g. sci.math in Google Groups with their web browser and post there.
Some like yourself will migrate to direct Usenet when GG breaks the link.

In future, web users will just see GG's read-only copy of sci.math up to the GG disconnect date in a
few weeks. How many will think "hey, I wonder what's been happening in that group since Feb 2024.
Does it even still exist somewhere? Perhaps I could get some old software where I can find out, and
then it would be cool to add new posts!" and then go through all the troubles you've had to
successfully join the Usenet community?

Since those users will have zero previous commitment to the group, I suspect it will (close to)
NONE. So I fear the GG disconnect will spell the end for most Usenet groups in the medium term.
(Groups will not die all at once, of course, and we could say the groups are slowly dying anyway,
but it will be vastly accelerated, I fear...) :(

Mike.

On 1/11/2024 10:14 AM, Mike Terry wrote:
> On 11/01/2024 05:24, olcott wrote:
>> On 1/10/2024 10:14 PM, Mike Terry wrote:
>>> On 10/01/2024 07:16, immibis wrote:
>>>> On 1/10/24 04:36, Mike Terry wrote:
>>>>> On 09/01/2024 23:54, immibis wrote:
>>>>>>
>>>>>> Your simulator does an incorrect simulation because of the
>>>>>> undeclared input of execution history into the inner simulation.
>>>>>>
>>>>>
>>>>> I think you may be off base on your exact explanation here.
>>>>>
>>>>> It's some time since I looked in any detail at PO's code and
>>>>> traces, but when I last did that it seemed to me that at the
>>>>> step-by-step x86 instruction level the simulation was ok.  The
>>>>> problem is that H stops simulating before the simulated computation
>>>>> halts, on the grounds that it has spotted the "PO infinitely
>>>>> recursive simulation pattern".
>>>>
>>>> Yes.
>>>>
>>>>> UP TO THAT POINT the simulation faithfully tracks the states of the
>>>>> actual computation, which continues from that point for a while and
>>>>> then terminates normally.  [..as seen when running D(D) "directly"]
>>>>
>>>> Well, sort of. The simulator refuses to simulate the simulator, and
>>>> instead does something like incrementing a "simulation level"
>>>> variable and then simulating the code the inner simulator would have
>>>> simulated.
>>>
>>
>> *Mike has a very thorough not quite perfectly correct analysis*
>> (see below)
>
> In many respects my understanding of your code is better than yours, so
> I've corrected a couple of your "corrections" below, just for the record...
>
>>
>>> I think we diverge here.  Perhaps...  I would say PO's code
>>> "simulates the simulator" in a reasonable way we could accept for
>>> current purposes.  (At least for the purposes of discussing where he
>>> is going wrong - IF he went as far as submitting a formal paper to a
>>> journal, all sorts of lesser problems would need addressing regarding
>>> the validity of his approach and his x86utm design (sharing the main
>>> code/data across all simulation levels, use of complex x86
>>> instruction set etc.), but that's never going to happen and meanwhile
>>> I don't believe these issues are the source of any actual problems in
>>> his results.  He has much simpler basic misunderstandings.)
>>>
>>> The basic limitations of PO's x86utm design:
>>> -  all simulations share a single address space with shared code and
>>> data
>>> -  the x86-level instruction simulation is housed in x86utm.exe as
>>> opposed to
>>>     what I'll call the user (code/data) space, where H,D,H1, code and
>>> stack space and
>>>     (perhaps) global data reside
>>> -  simulation single-stepping etc. is provided as primitives by
>>> x86utm to user space code.
>>>     (since address space is shared, and register save space used by
>>> primitives is in the
>>>     user address space, simulators can monitor the progress of their
>>> simulations)
>>> I think nested simulation works sort of ok given the above
>>> architecture - but also see my very final comment below...
>>>
>>> Also I think there's divergence among posters here re what counts as
>>> "simulation", so that might be a source of misunderstanding?  I
>>> prefer "simulation" to mean simply the act of calculating the state
>>> changes in a computation, with the understanding that a program might
>>> simulate just (say) 10 steps of a computation, and then stop for
>>> whatever reason.  I'd say that simulation activity was "correct" if
>>> those 10 steps were calculated correctly i.e. they track the first 10
>>> actual computation steps.
>>>
>>> The program will of course perform many other calculations and make
>>> other decisions (e.g. the counting to 10 or other tests to decide
>>> when to stop simulating, deciding on its own return code) - but I
>>> don't count those  "simulating" or part of the simulator.  I.e. the
>>> simulator is just a component the program uses.  If the program
>>> simulates 10 steps correctly then stops simulating, the /simulation/
>>> was correct, and if the program proceeds to announce that the
>>> computation would never halt, when in fact it would, that doesn't
>>> change that it correctly simulated the 10 steps - the fault lies in
>>> the non-simulating code of the program.  [Well, that's how I'd
>>> express things...]
>>>
>>> Perhaps you use "simulate" in a broader sense, e.g. to include ALL
>>> the code in H including what I'd consider business logic (which for H
>>> I'd label "termination analysis")?  So when you say "the simulator
>>> /refuses/ to simulate the simulator", maybe you're just saying H is
>>> coded to abort its simulation too early due to a false positive match
>>> with its unsound recursion test.  [I agree with that.]  But to me I'm
>>> reading it as saying x86utm doesn't properly support nested
>>> simulation in some way, whereas to me it seems it does!
>>>
>>> E.g. suppose we run H1(D,D).  [H1 is the copy of H, but with a
>>> modified abort condition that means in effect it never matches when
>>> analysing (D,D) input...]
>>
>> H1 is the exact same code as H exact that D does not call H1.
>
> No it's not.  H1 monitors its simulation for occurences of address H1, H
> monitors for address H - that even appears explicitly as a code
> difference - just diff the two routines!
>

They used to have identical source-code, and they both
got the address of the function that they were in on
the basis of an offset from the current instruction.
I changed this so it would not be so confusing for novices.

>>
>>> When H1 simulates D(D), it simulates:
>>> -  D calling H,
>>> -  H simulating D(D) - including the simulation primitives within H,
>>> and all the termination
>>>     analysis code such as PO's infinite recursion testing code, abort
>>> decision code and so on.
>>> -  the simulated simulation being aborted by the simulated H,
>>> -  H returning to D [telling simulated D that D(D) never halts!],
>>> -  D reaching its final ret, i.e. halting.
>>>
>>> Perfect - no issues I can see with nesting of simulations or invalid
>>> secret data feeds to inner simulations altering the course of the
>>> inner simulations or anything like that.
>>>
>>> The problem when running H(D,D) is simply that while (correctly)
>>> simulating D(D), [outer] H spots PO's "infinite recursion" pattern
>>> [which DOES NOT ACTUALLY TEST FOR INFINITE RECURSION despite PO's
>>> name for the test] and aborts the simulation, announcing incorrectly
>>> that D(D) doesn't halt when it does.
>>
>> 04 int D(ptr x)
>> 05 {
>> 06   int Halt_Status = H(x, x);
>> 07   if (Halt_Status)
>> 08     HERE: goto HERE;
>> 09   return Halt_Status;
>> 10 }
>>
>> That no one can possibly provide the exact sequence of
>> the execution trace D correctly simulated by H such
>> that this simulated D reaches its own line 09 conclusively
>> proves that D correctly simulated by H never halts.
>>
>> Every rebuttal to this has always been the pure bluster
>> of dogma with zero supporting exact execution trace.
>>
>>> That's hardly the fault of the correct (partial) simulation - it's
>>> the fault of the faulty termination analysis logic in H, namely
>>> relience use of PO's unsound "infinite recursion" pattern. Er, that's
>>> it!
>>>
>>>>
>>>> A true simulation of the simulator would find that the simulator
>>>> eventually detects the infinite recursion pattern, and then halts.
>>>
>>> And it does, e.g. when we run H1(D,D) as above.
>>>
>>> In my terminology, when running H(D,D) H "correctly" simulates D(D)
>>> for a while, but then applies an unsound test that matches its
>>> generated simulation trace, so it incorrectly concludes its
>>> simulation of D(D) "IF continued" would never halt.  Actually I'm
>>> being sloppy: *H* assumes no such thing as it's just code.  The
>>> incorrect assumption is PO's, as the designer.
>>>
>>> The point I'd make is that the /reason/ H1 sees simulated D(D) halt
>>> while H decides it never halts is nothing to do with incorrect nested
>>> simulation implementation causing nested simulations to behave
>>> differently from outer simulations - like due to invalid use of
>>> global data leaking in, or whatever.  AFAICT regardless of the
>>> simulation depth, all the simulations behave exactly the same [up to
>>> the point the simulation is aborted of course].  This is where I
>>> suspect you diverge?
>>>
>>> I think your "true simulator" = my "full simulator" = "simulates to
>>> completion"?  PO's H is obviously not a "true simulator" in that
>>> sense and PO has never claimed that.  PO claims his H "correctly
>>> simulates" D(D) which fits my usage, although his often repeated
>>> "..until H correctly decides that its simulation would never end..."
>>> bit doesn't apply - H actually /incorrectly/ decides blah blah, since
>>> it relied on his unsound infinite recursion test.
>>>
>>>> Olcott's simulator instead behaves as if it knows that the simulator
>>>> never halts, which is an obviously untrue fact and a self-delusion
>>>> of Olcott.
>>>
>>> Hmm.  I'll read that as "PO's "H" behaves as if it knows...".  But H
>>> is just code, and doesn't do "as if" or "knowing" (of course).  Those
>>> ideas may well be in PO's mind, as /designer/ for H, and readers may
>>> benefit from that insight.
>>>
>>> But what actually happens?  H applies an unsound test which matches
>>> (a false-positive), leading it to incorrectly announce that
>>> computation D(D) never halts.  That seems a simple account of what's
>>> going on.
>>>
>>
>> I just proved that D correctly simulated by H never reaches its own line
>> 09 in N to infinitely steps of correct simulation. Actual C code would
>> run out of stack space and still not reach line 09.
>>
>> As soon as H sees that D is calling itself with its same input then
>> the proves that D never halts.
>>
>> HH actually simulates D calling its simulated self and sees the
>> repeated state up to the point where the simulated HH would
>> simulate another HH.
>>
>>>>
>>>>>
>>>>> PO is really really really convinced (despite concrete evidence
>>>>> showing otherwise) that his infinite recursion pattern gives a
>>>>> sound non-halting test, but he is just wrong - it does not imply
>>>>> non-halting.
>>>>
>>>> Infinite recursion does imply non-halting, but it's detected in a
>>>> way that is obviously incorrect.
>>>
>>> Exactly.  PO's "infinite recursive simulation" test is unsound.  It
>>> can match both halting and non-halting computations.
>>
>> That is factually incorrect. No one has been able to report
>> any actual error in two years of review.
>
> It is factually correct.  I know you don't believe that, but just

On 1/12/24 00:36, Mike Terry wrote:
> On 11/01/2024 09:53, wij wrote:
> <..snip..>
>>
>> Note: This reply is also a test post, I just changed to use Thunderbird.
>
> Glad you got it working!
>
> I do wonder how many newbies in future years will come to Usenet.
>
> At the moment, they can find e.g. sci.math in Google Groups with their
> web browser and post there. Some like yourself will migrate to direct
> Usenet when GG breaks the link.
>
> In future, web users will just see GG's read-only copy of sci.math up to
> the GG disconnect date in a few weeks.  How many will think "hey, I
> wonder what's been happening in that group since Feb 2024. Does it even
> still exist somewhere?  Perhaps I could get some old software where I
> can find out, and then it would be cool to add new posts!" and then go
> through all the troubles you've had to successfully join the Usenet
> community?

Several years ago Yahoo Knowledge was very popular here. Latter, it was
closed because Yahoo was losing money, similar with GG. I am not very
optimistic about the chance people will get together discussing
Knowledge like before, this opinion is also based on observation of
quite several number of websites for discussing math., photograhing,
computer things (software,hardware,OS,..,etc.).

> Since those users will have zero previous commitment to the group, I
> suspect it will (close to) NONE.  So I fear the GG disconnect will spell
> the end for most Usenet groups in the medium term. (Groups will not die
> all at once, of course, and we could say the groups are slowly dying
> anyway, but it will be vastly accelerated, I fear...)  :(
>
> Mike.

I have no idea what young would make their choice. Let's see.

On 1/11/24 9:42 AM, olcott wrote:
> On 1/9/2024 9:02 PM, immibis wrote:
>> On 1/10/24 03:58, olcott wrote:
>>> On 1/9/2024 8:17 PM, immibis wrote:
>>>> On 1/10/24 01:44, olcott wrote:
>>>>> On 1/9/2024 5:54 PM, immibis wrote:
>>>>>> On 1/9/24 15:01, olcott wrote:
>>>>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>>>>> Premises:
>>>>>>>>
>>>>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>>>>
>>>>>>>> Conclusion:
>>>>>>>>
>>>>>>>> 3. The halting problem can't be solved.
>>>>>>>
>>>>>>> When D is intentionally defined to do the opposite of
>>>>>>> whatever Boolean value that H returns then input D <is>
>>>>>>> absolutely self-contradictory to termination analyzer H
>>>>>>> when H is required to report on the behavior of the
>>>>>>> directly executed D.
>>>>>>>
>>>>>>> *MIT Professor Michael Sipser has agreed that the following
>>>>>>> verbatim*
>>>>>>> *paragraph is correct*
>>>>>>> (a) If simulating halt decider H correctly simulates its input D
>>>>>>> until H
>>>>>>> correctly determines that its simulated D would never stop running
>>>>>>> unless aborted then
>>>>>>
>>>>>> Your simulator does an incorrect simulation because of the
>>>>>> undeclared input of execution history into the inner simulation.
>>>>>
>>>>> If it was incorrect then you could show the exact sequence that
>>>>> should be simulated.
>>>>
>>>> I could, but why should I do more work when less work is already
>>>> good enough? It wouldn't prove anything that wasn't already proved.
>>>> I'd have to download your simulator, check it for viruses, figure
>>>> out how it works, then change it.
>>>>
>>>>> You already said that the simulated D should call the simulated H.
>>>>>
>>>>> You know that when it does this that D correctly simulated by H cannot
>>>> possible reach its own line 09 and terminate normally (AKA halt).
>>>>>
>>>>
>>>> That's right.
>>>>
>>>
>>> *That is better than anyone else has ever understood*
>>>
>> We all understand it, except you.
>>
>> You refuse to acknowledge this point:
>>
>> **The correct simulation of a program returns the same result as its
>> direct execution.**
>
> 04 int D(ptr x)
> 05 {
> 06   int Halt_Status = H(x, x);
> 07   if (Halt_Status)
> 08     HERE: goto HERE;
> 09   return Halt_Status;
> 10 }
> 11
> 12 void main()
> 13 {
> 14   H(D,D);
> 15 }
>
> *Execution Trace*
> Line 14: main() invokes H(D,D);
>
> *keeps repeating* (unless aborted)
> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
> *Simulation invariant*
> D correctly simulated by H cannot possibly reach past its own line 06
>
> *Every rebuttal to this has always been the pure bluster*
> *of dogma with zero supporting exact execution trace*
>
> IF A CORRECT EXECUTION TRACE THAT REACHES LINE 09 OF D CANNOT
> POSSIBLY BE PROVIDED THAT PROVES THE ABOVE TRACE IS CORRECT.
>
> Internet trolls will try and get away with saying that
> they don't need to provide such a trace because they
> "just know" that I am wrong. This proves that they are liars.
>

Your bluster is just a dishonest straw man,

Note, you have apparently agreed that the correct simulation trace was
posted, since you haven't shown any errors in the trace.

Thus you are admitting that you are just an ignorant pathological lying
idiot.

On 1/11/24 12:29 PM, olcott wrote:
> On 1/11/2024 10:14 AM, Mike Terry wrote:
>> On 11/01/2024 05:24, olcott wrote:
>>> On 1/10/2024 10:14 PM, Mike Terry wrote:
>>>> On 10/01/2024 07:16, immibis wrote:
>>>>> On 1/10/24 04:36, Mike Terry wrote:
>>>>>> On 09/01/2024 23:54, immibis wrote:
>>>>>>>
>>>>>>> Your simulator does an incorrect simulation because of the
>>>>>>> undeclared input of execution history into the inner simulation.
>>>>>>>
>>>>>>
>>>>>> I think you may be off base on your exact explanation here.
>>>>>>
>>>>>> It's some time since I looked in any detail at PO's code and
>>>>>> traces, but when I last did that it seemed to me that at the
>>>>>> step-by-step x86 instruction level the simulation was ok.  The
>>>>>> problem is that H stops simulating before the simulated
>>>>>> computation halts, on the grounds that it has spotted the "PO
>>>>>> infinitely recursive simulation pattern".
>>>>>
>>>>> Yes.
>>>>>
>>>>>> UP TO THAT POINT the simulation faithfully tracks the states of
>>>>>> the actual computation, which continues from that point for a
>>>>>> while and then terminates normally.  [..as seen when running D(D)
>>>>>> "directly"]
>>>>>
>>>>> Well, sort of. The simulator refuses to simulate the simulator, and
>>>>> instead does something like incrementing a "simulation level"
>>>>> variable and then simulating the code the inner simulator would
>>>>> have simulated.
>>>>
>>>
>>> *Mike has a very thorough not quite perfectly correct analysis*
>>> (see below)
>>
>> In many respects my understanding of your code is better than yours,
>> so I've corrected a couple of your "corrections" below, just for the
>> record...
>>
>>>
>>>> I think we diverge here.  Perhaps...  I would say PO's code
>>>> "simulates the simulator" in a reasonable way we could accept for
>>>> current purposes.  (At least for the purposes of discussing where he
>>>> is going wrong - IF he went as far as submitting a formal paper to a
>>>> journal, all sorts of lesser problems would need addressing
>>>> regarding the validity of his approach and his x86utm design
>>>> (sharing the main code/data across all simulation levels, use of
>>>> complex x86 instruction set etc.), but that's never going to happen
>>>> and meanwhile I don't believe these issues are the source of any
>>>> actual problems in his results.  He has much simpler basic
>>>> misunderstandings.)
>>>>
>>>> The basic limitations of PO's x86utm design:
>>>> -  all simulations share a single address space with shared code and
>>>> data
>>>> -  the x86-level instruction simulation is housed in x86utm.exe as
>>>> opposed to
>>>>     what I'll call the user (code/data) space, where H,D,H1, code
>>>> and stack space and
>>>>     (perhaps) global data reside
>>>> -  simulation single-stepping etc. is provided as primitives by
>>>> x86utm to user space code.
>>>>     (since address space is shared, and register save space used by
>>>> primitives is in the
>>>>     user address space, simulators can monitor the progress of their
>>>> simulations)
>>>> I think nested simulation works sort of ok given the above
>>>> architecture - but also see my very final comment below...
>>>>
>>>> Also I think there's divergence among posters here re what counts as
>>>> "simulation", so that might be a source of misunderstanding?  I
>>>> prefer "simulation" to mean simply the act of calculating the state
>>>> changes in a computation, with the understanding that a program
>>>> might simulate just (say) 10 steps of a computation, and then stop
>>>> for whatever reason.  I'd say that simulation activity was "correct"
>>>> if those 10 steps were calculated correctly i.e. they track the
>>>> first 10 actual computation steps.
>>>>
>>>> The program will of course perform many other calculations and make
>>>> other decisions (e.g. the counting to 10 or other tests to decide
>>>> when to stop simulating, deciding on its own return code) - but I
>>>> don't count those  "simulating" or part of the simulator.  I.e. the
>>>> simulator is just a component the program uses.  If the program
>>>> simulates 10 steps correctly then stops simulating, the /simulation/
>>>> was correct, and if the program proceeds to announce that the
>>>> computation would never halt, when in fact it would, that doesn't
>>>> change that it correctly simulated the 10 steps - the fault lies in
>>>> the non-simulating code of the program.  [Well, that's how I'd
>>>> express things...]
>>>>
>>>> Perhaps you use "simulate" in a broader sense, e.g. to include ALL
>>>> the code in H including what I'd consider business logic (which for
>>>> H I'd label "termination analysis")?  So when you say "the simulator
>>>> /refuses/ to simulate the simulator", maybe you're just saying H is
>>>> coded to abort its simulation too early due to a false positive
>>>> match with its unsound recursion test.  [I agree with that.]  But to
>>>> me I'm reading it as saying x86utm doesn't properly support nested
>>>> simulation in some way, whereas to me it seems it does!
>>>>
>>>> E.g. suppose we run H1(D,D).  [H1 is the copy of H, but with a
>>>> modified abort condition that means in effect it never matches when
>>>> analysing (D,D) input...]
>>>
>>> H1 is the exact same code as H exact that D does not call H1.
>>
>> No it's not.  H1 monitors its simulation for occurences of address H1,
>> H monitors for address H - that even appears explicitly as a code
>> difference - just diff the two routines!
>>
>
> They used to have identical source-code, and they both
> got the address of the function that they were in on
> the basis of an offset from the current instruction.
> I changed this so it would not be so confusing for novices.

So, they aren't actually pure functions of just their inputs, as they
use their program location as an additional input.

Thus, you program system is NOT Turing Compatible, and worthless for
this discussion.

Thanks for making that clear.

>
>>>
>>>> When H1 simulates D(D), it simulates:
>>>> -  D calling H,
>>>> -  H simulating D(D) - including the simulation primitives within H,
>>>> and all the termination
>>>>     analysis code such as PO's infinite recursion testing code,
>>>> abort decision code and so on.
>>>> -  the simulated simulation being aborted by the simulated H,
>>>> -  H returning to D [telling simulated D that D(D) never halts!],
>>>> -  D reaching its final ret, i.e. halting.
>>>>
>>>> Perfect - no issues I can see with nesting of simulations or invalid
>>>> secret data feeds to inner simulations altering the course of the
>>>> inner simulations or anything like that.
>>>>
>>>> The problem when running H(D,D) is simply that while (correctly)
>>>> simulating D(D), [outer] H spots PO's "infinite recursion" pattern
>>>> [which DOES NOT ACTUALLY TEST FOR INFINITE RECURSION despite PO's
>>>> name for the test] and aborts the simulation, announcing incorrectly
>>>> that D(D) doesn't halt when it does.
>>>
>>> 04 int D(ptr x)
>>> 05 {
>>> 06   int Halt_Status = H(x, x);
>>> 07   if (Halt_Status)
>>> 08     HERE: goto HERE;
>>> 09   return Halt_Status;
>>> 10 }
>>>
>>> That no one can possibly provide the exact sequence of
>>> the execution trace D correctly simulated by H such
>>> that this simulated D reaches its own line 09 conclusively
>>> proves that D correctly simulated by H never halts.
>>>
>>> Every rebuttal to this has always been the pure bluster
>>> of dogma with zero supporting exact execution trace.
>>>
>>>> That's hardly the fault of the correct (partial) simulation - it's
>>>> the fault of the faulty termination analysis logic in H, namely
>>>> relience use of PO's unsound "infinite recursion" pattern. Er,
>>>> that's it!
>>>>
>>>>>
>>>>> A true simulation of the simulator would find that the simulator
>>>>> eventually detects the infinite recursion pattern, and then halts.
>>>>
>>>> And it does, e.g. when we run H1(D,D) as above.
>>>>
>>>> In my terminology, when running H(D,D) H "correctly" simulates D(D)
>>>> for a while, but then applies an unsound test that matches its
>>>> generated simulation trace, so it incorrectly concludes its
>>>> simulation of D(D) "IF continued" would never halt.  Actually I'm
>>>> being sloppy: *H* assumes no such thing as it's just code.  The
>>>> incorrect assumption is PO's, as the designer.
>>>>
>>>> The point I'd make is that the /reason/ H1 sees simulated D(D) halt
>>>> while H decides it never halts is nothing to do with incorrect
>>>> nested simulation implementation causing nested simulations to
>>>> behave differently from outer simulations - like due to invalid use
>>>> of global data leaking in, or whatever.  AFAICT regardless of the
>>>> simulation depth, all the simulations behave exactly the same [up to
>>>> the point the simulation is aborted of course].  This is where I
>>>> suspect you diverge?
>>>>
>>>> I think your "true simulator" = my "full simulator" = "simulates to
>>>> completion"?  PO's H is obviously not a "true simulator" in that
>>>> sense and PO has never claimed that.  PO claims his H "correctly
>>>> simulates" D(D) which fits my usage, although his often repeated
>>>> "..until H correctly decides that its simulation would never end..."
>>>> bit doesn't apply - H actually /incorrectly/ decides blah blah,
>>>> since it relied on his unsound infinite recursion test.
>>>>
>>>>> Olcott's simulator instead behaves as if it knows that the
>>>>> simulator never halts, which is an obviously untrue fact and a
>>>>> self-delusion of Olcott.
>>>>
>>>> Hmm.  I'll read that as "PO's "H" behaves as if it knows...".  But H
>>>> is just code, and doesn't do "as if" or "knowing" (of course).
>>>> Those ideas may well be in PO's mind, as /designer/ for H, and
>>>> readers may benefit from that insight.
>>>>
>>>> But what actually happens?  H applies an unsound test which matches
>>>> (a false-positive), leading it to incorrectly announce that
>>>> computation D(D) never halts.  That seems a simple account of what's
>>>> going on.
>>>>
>>>
>>> I just proved that D correctly simulated by H never reaches its own line
>>> 09 in N to infinitely steps of correct simulation. Actual C code would
>>> run out of stack space and still not reach line 09.
>>>
>>> As soon as H sees that D is calling itself with its same input then
>>> the proves that D never halts.
>>>
>>> HH actually simulates D calling its simulated self and sees the
>>> repeated state up to the point where the simulated HH would
>>> simulate another HH.
>>>
>>>>>
>>>>>>
>>>>>> PO is really really really convinced (despite concrete evidence
>>>>>> showing otherwise) that his infinite recursion pattern gives a
>>>>>> sound non-halting test, but he is just wrong - it does not imply
>>>>>> non-halting.
>>>>>
>>>>> Infinite recursion does imply non-halting, but it's detected in a
>>>>> way that is obviously incorrect.
>>>>
>>>> Exactly.  PO's "infinite recursive simulation" test is unsound.  It
>>>> can match both halting and non-halting computations.
>>>
>>> That is factually incorrect. No one has been able to report
>>> any actual error in two years of review.
>>
>> It is factually correct.  I know you don't believe that, but just
>
> No one can possibly provide the exact sequence of D correctly
> simulated by H that differs from the one provided below.
>
> *Every rebuttal (including yours) has always been the pure*
> *bluster of dogma with zero supporting exact execution trace*
>
> 04 int D(ptr x)
> 05 {
> 06   int Halt_Status = H(x, x);
> 07   if (Halt_Status)
> 08     HERE: goto HERE;
> 09   return Halt_Status;
> 10 }
> 11
> 12 void main()
> 13 {
> 14   H(D,D);
> 15 }
>
> *Execution Trace*
> Line 14: main() invokes H(D,D);
>
> *keeps repeating* (unless aborted)
> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
> *Simulation invariant*
> *D correctly simulated by H cannot possibly reach past its own line 06*

On 1/11/24 18:29, olcott wrote:
> On 1/11/2024 10:14 AM, Mike Terry wrote:
>> On 11/01/2024 05:24, olcott wrote:
>>> H1 is the exact same code as H exact that D does not call H1.
>>
>> No it's not.  H1 monitors its simulation for occurences of address H1,
>> H monitors for address H - that even appears explicitly as a code
>> difference - just diff the two routines!
>>
>
> They used to have identical source-code, and they both
> got the address of the function that they were in on
> the basis of an offset from the current instruction.
> I changed this so it would not be so confusing for novices.

Changing it creates a different program. *H and H1 are not two copies of
the same program. They are two different programs.*

Using an offset from the current instruction is just another dishonest
way to create two different programs. Turing machines do not know their
own state number. They cannot behave differently just because you
renumber the states.

>>> That is factually incorrect. No one has been able to report
>>> any actual error in two years of review.

we reported it many times, you ignore it and call us stupid

On 1/13/2024 8:00 AM, immibis wrote:
> On 1/11/24 18:29, olcott wrote:
>> On 1/11/2024 10:14 AM, Mike Terry wrote:
>>> On 11/01/2024 05:24, olcott wrote:
>>>> H1 is the exact same code as H exact that D does not call H1.
>>>
>>> No it's not.  H1 monitors its simulation for occurences of address
>>> H1, H monitors for address H - that even appears explicitly as a code
>>> difference - just diff the two routines!
>>>
>>
>> They used to have identical source-code, and they both
>> got the address of the function that they were in on
>> the basis of an offset from the current instruction.
>> I changed this so it would not be so confusing for novices.
>
> Changing it creates a different program. *H and H1 are not two copies of
> the same program. They are two different programs.*
>
> Using an offset from the current instruction is just another dishonest
> way to create two different programs. Turing machines do not know their
> own state number. They cannot behave differently just because you
> renumber the states.
>

Then forget about H1 and simply know that the directly executed D(D)
reaches its final state and terminates normally and D correctly
simulated by H cannot possibly do this.

*All rebuttals to this have been pure bluster* that could not
possibly show any other correct execution trace with the
exact line numbers of D correctly simulated by H.

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

On 1/13/24 12:07 PM, olcott wrote:
> On 1/13/2024 8:00 AM, immibis wrote:
>> On 1/11/24 18:29, olcott wrote:
>>> On 1/11/2024 10:14 AM, Mike Terry wrote:
>>>> On 11/01/2024 05:24, olcott wrote:
>>>>> H1 is the exact same code as H exact that D does not call H1.
>>>>
>>>> No it's not.  H1 monitors its simulation for occurences of address
>>>> H1, H monitors for address H - that even appears explicitly as a
>>>> code difference - just diff the two routines!
>>>>
>>>
>>> They used to have identical source-code, and they both
>>> got the address of the function that they were in on
>>> the basis of an offset from the current instruction.
>>> I changed this so it would not be so confusing for novices.
>>
>> Changing it creates a different program. *H and H1 are not two copies
>> of the same program. They are two different programs.*
>>
>> Using an offset from the current instruction is just another dishonest
>> way to create two different programs. Turing machines do not know
>> their own state number. They cannot behave differently just because
>> you renumber the states.
>>
>
> Then forget about H1 and simply know that the directly executed D(D)
> reaches its final state and terminates normally and D correctly
> simulated by H cannot possibly do this.

Which means H did not correctly simulate its input.

>
> *All rebuttals to this have been pure bluster* that could not
> possibly show any other correct execution trace with the
> exact line numbers of D correctly simulated by H.
>

No, your response has been pure blusted ignoring the actual logic, and
is based on your fantasy world o fUnicorns and Faries, and youi being
God and allowed to watch kiddie porn.

On 1/13/24 18:07, olcott wrote:
> On 1/13/2024 8:00 AM, immibis wrote:
>> On 1/11/24 18:29, olcott wrote:
>>> On 1/11/2024 10:14 AM, Mike Terry wrote:
>>>> On 11/01/2024 05:24, olcott wrote:
>>>>> H1 is the exact same code as H exact that D does not call H1.
>>>>
>>>> No it's not.  H1 monitors its simulation for occurences of address
>>>> H1, H monitors for address H - that even appears explicitly as a
>>>> code difference - just diff the two routines!
>>>>
>>>
>>> They used to have identical source-code, and they both
>>> got the address of the function that they were in on
>>> the basis of an offset from the current instruction.
>>> I changed this so it would not be so confusing for novices.
>>
>> Changing it creates a different program. *H and H1 are not two copies
>> of the same program. They are two different programs.*
>>
>> Using an offset from the current instruction is just another dishonest
>> way to create two different programs. Turing machines do not know
>> their own state number. They cannot behave differently just because
>> you renumber the states.
>>
>
> Then forget about H1 and simply know that the directly executed D(D)
> reaches its final state and terminates normally and D correctly
> simulated by H cannot possibly do this.

D correctly simulated by H must do this because anything correctly
simulated by anything must behave the same as its own direct execution.

On 1/14/2024 12:16 PM, immibis wrote:
> On 1/13/24 18:07, olcott wrote:
>> On 1/13/2024 8:00 AM, immibis wrote:
>>> On 1/11/24 18:29, olcott wrote:
>>>> On 1/11/2024 10:14 AM, Mike Terry wrote:
>>>>> On 11/01/2024 05:24, olcott wrote:
>>>>>> H1 is the exact same code as H exact that D does not call H1.
>>>>>
>>>>> No it's not.  H1 monitors its simulation for occurences of address
>>>>> H1, H monitors for address H - that even appears explicitly as a
>>>>> code difference - just diff the two routines!
>>>>>
>>>>
>>>> They used to have identical source-code, and they both
>>>> got the address of the function that they were in on
>>>> the basis of an offset from the current instruction.
>>>> I changed this so it would not be so confusing for novices.
>>>
>>> Changing it creates a different program. *H and H1 are not two copies
>>> of the same program. They are two different programs.*
>>>
>>> Using an offset from the current instruction is just another
>>> dishonest way to create two different programs. Turing machines do
>>> not know their own state number. They cannot behave differently just
>>> because you renumber the states.
>>>
>>
>> Then forget about H1 and simply know that the directly executed D(D)
>> reaches its final state and terminates normally and D correctly
>> simulated by H cannot possibly do this.
>
> D correctly simulated by H must do this because anything correctly
> simulated by anything must behave the same as its own direct execution.

It is very easy to prove that is false just show me all of
the steps including line numbers of D correctly simulated
by H that differs from this execution trace:

*IF YOU CAN'T DO THAT THEN YOU ARE PROVEN WRONG*
*IF YOU CAN'T DO THAT THEN YOU ARE PROVEN WRONG*
*IF YOU CAN'T DO THAT THEN YOU ARE PROVEN WRONG*

01 int D(ptr x) // ptr is pointer to int function
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
Line 11: main() invokes H(D,D);

*keeps repeating* (unless aborted)
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.

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

On 1/14/24 1:39 PM, olcott wrote:
> On 1/14/2024 12:16 PM, immibis wrote:
>> On 1/13/24 18:07, olcott wrote:
>>> On 1/13/2024 8:00 AM, immibis wrote:
>>>> On 1/11/24 18:29, olcott wrote:
>>>>> On 1/11/2024 10:14 AM, Mike Terry wrote:
>>>>>> On 11/01/2024 05:24, olcott wrote:
>>>>>>> H1 is the exact same code as H exact that D does not call H1.
>>>>>>
>>>>>> No it's not.  H1 monitors its simulation for occurences of address
>>>>>> H1, H monitors for address H - that even appears explicitly as a
>>>>>> code difference - just diff the two routines!
>>>>>>
>>>>>
>>>>> They used to have identical source-code, and they both
>>>>> got the address of the function that they were in on
>>>>> the basis of an offset from the current instruction.
>>>>> I changed this so it would not be so confusing for novices.
>>>>
>>>> Changing it creates a different program. *H and H1 are not two
>>>> copies of the same program. They are two different programs.*
>>>>
>>>> Using an offset from the current instruction is just another
>>>> dishonest way to create two different programs. Turing machines do
>>>> not know their own state number. They cannot behave differently just
>>>> because you renumber the states.
>>>>
>>>
>>> Then forget about H1 and simply know that the directly executed D(D)
>>> reaches its final state and terminates normally and D correctly
>>> simulated by H cannot possibly do this.
>>
>> D correctly simulated by H must do this because anything correctly
>> simulated by anything must behave the same as its own direct execution.
>
> It is very easy to prove that is false just show me all of
> the steps including line numbers of D correctly simulated
> by H that differs from this execution trace:
>
> *IF YOU CAN'T DO THAT THEN YOU ARE PROVEN WRONG*
> *IF YOU CAN'T DO THAT THEN YOU ARE PROVEN WRONG*
> *IF YOU CAN'T DO THAT THEN YOU ARE PROVEN WRONG*

Nope.

To prove yourself right, you need to show the actual trace of an H that
fully simulates the input and gives the right answer.

Since the DEFINITION of "Correct Simulation" in the domain of
Computation Theory is that a correct simulation exactly matches the
direct exectution of it, to claim the DEFINITION is wrong just proves
yourself to be a LIAR.

Remember, DEFINITIONS are part of the fundamental axioms of the system,
so CAN'T be "WRONG". At best you can try to show the system inconsistent.

You are just showing that you are incompetent to talk about logic.

>
> 01 int D(ptr x)  // ptr is pointer to int function
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 void main()
> 10 {
> 11   H(D,D);
> 12 }
>
> *Execution Trace*
> Line 11: main() invokes H(D,D);
>
> *keeps repeating* (unless aborted)
> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
> *Simulation invariant*
> D correctly simulated by H cannot possibly reach past its own line 03.
>
>

On 1/14/24 19:39, olcott wrote:
> On 1/14/2024 12:16 PM, immibis wrote:
>>
>> D correctly simulated by H must do this because anything correctly
>> simulated by anything must behave the same as its own direct execution.
>
> It is very easy to prove that is false

Definition of "correctly simulated": X correctly simulated by Y is
isomorphic to the direct execution of X.

If it's not isomorphic, it's incorrectly simulated.

On 1/14/2024 10:57 PM, immibis wrote:
> On 1/14/24 19:39, olcott wrote:
>> On 1/14/2024 12:16 PM, immibis wrote:
>>>
>>> D correctly simulated by H must do this because anything correctly
>>> simulated by anything must behave the same as its own direct execution.
>>
>> It is very easy to prove that is false
>
> Definition of "correctly simulated": X correctly simulated by Y is
> isomorphic to the direct execution of X.
>
> If it's not isomorphic, it's incorrectly simulated.

The formal proof of the execution trace that D correctly
simulated by H specifies proves that your assumption is
incorrect.

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

On 1/15/24 6:57 PM, olcott wrote:
> On 1/14/2024 10:57 PM, immibis wrote:
>> On 1/14/24 19:39, olcott wrote:
>>> On 1/14/2024 12:16 PM, immibis wrote:
>>>>
>>>> D correctly simulated by H must do this because anything correctly
>>>> simulated by anything must behave the same as its own direct execution.
>>>
>>> It is very easy to prove that is false
>>
>> Definition of "correctly simulated": X correctly simulated by Y is
>> isomorphic to the direct execution of X.
>>
>> If it's not isomorphic, it's incorrectly simulated.
>
> The formal proof of the execution trace that D correctly
> simulated by H specifies proves that your assumption is
> incorrect.
>

Any H that returns and answer did not correctly simulate its input.

Your formal proof show that only ONE "form" of H can exist that meets
your correct simulation requirement, and that one never aborts its
simulation and thus becomes not a decider, so not a correct Halting Decider.

Please try to show the H that answers that also does a correct
simulaiton, and that includes seeing the call to H as a call to THIS H
that does what THIS H does, that is return athe answer it does.

Any other interpretation of the simulation is just an incorrect simulation.

On 1/16/24 00:57, olcott wrote:
> On 1/14/2024 10:57 PM, immibis wrote:
>> On 1/14/24 19:39, olcott wrote:
>>> On 1/14/2024 12:16 PM, immibis wrote:
>>>>
>>>> D correctly simulated by H must do this because anything correctly
>>>> simulated by anything must behave the same as its own direct execution.
>>>
>>> It is very easy to prove that is false
>>
>> Definition of "correctly simulated": X correctly simulated by Y is
>> isomorphic to the direct execution of X.
>>
>> If it's not isomorphic, it's incorrectly simulated.
>
> The formal proof of the execution trace that D correctly
> simulated by H specifies proves that your assumption is
> incorrect.
>

That you can't tell what "correctly simulated" means proves you are
dishonest.

On 2024-01-13 17:07:56 +0000, olcott said:

> Then forget about H1 and simply know that the directly executed D(D)
> reaches its final state and terminates normally and D correctly
> simulated by H cannot possibly do this.

I.e., H1 can simulate D(D) to its termination but H can't.

Mikko

On 1/16/2024 2:00 AM, immibis wrote:
> On 1/16/24 00:57, olcott wrote:
>> On 1/14/2024 10:57 PM, immibis wrote:
>>> On 1/14/24 19:39, olcott wrote:
>>>> On 1/14/2024 12:16 PM, immibis wrote:
>>>>>
>>>>> D correctly simulated by H must do this because anything correctly
>>>>> simulated by anything must behave the same as its own direct
>>>>> execution.
>>>>
>>>> It is very easy to prove that is false
>>>
>>> Definition of "correctly simulated": X correctly simulated by Y is
>>> isomorphic to the direct execution of X.
>>>
>>> If it's not isomorphic, it's incorrectly simulated.
>>
>> The formal proof of the execution trace that D correctly
>> simulated by H specifies proves that your assumption is
>> incorrect.
>>
>
> That you can't tell what "correctly simulated" means proves you are
> dishonest.

I think the real issue here is that you lack sufficient technical
competence to understand these explanations.

_DD()
[00001c42] 55 push ebp
[00001c43] 8bec mov ebp,esp
[00001c45] 51 push ecx
[00001c46] 8b4508 mov eax,[ebp+08] ; DD
[00001c49] 50 push eax ; DD
[00001c4a] 8b4d08 mov ecx,[ebp+08] ; DD
[00001c4d] 51 push ecx ; DD
[00001c4e] e80ff7ffff call 00001362 ; HH
[00001c53] 83c408 add esp,+08
[00001c56] 8945fc mov [ebp-04],eax
[00001c59] 837dfc00 cmp dword [ebp-04],+00
[00001c5d] 7402 jz 00001c61
[00001c5f] ebfe jmp 00001c5f
[00001c61] 8b45fc mov eax,[ebp-04]
[00001c64] 8be5 mov esp,ebp
[00001c66] 5d pop ebp
[00001c67] c3 ret
Size in bytes:(0038) [00001c67]

01 int DD(void (*x)())
02 {
03 int Halt_Status = HH(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 Output("Input_Halts = ", HH(DD,DD));
12 }

The built-in third-party x86 emulator emulates
the x86 instructions of DD as they are specified.

main() invokes HH(DD,DD)
that simulates DD(DD)
that calls a simulated HH(DD,DD)
that simulates DD(DD)
that cannot possibly return to its caller.

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

On 1/16/2024 9:19 AM, Mikko wrote:
> On 2024-01-13 17:07:56 +0000, olcott said:
>
>> Then forget about H1 and simply know that the directly executed D(D)
>> reaches its final state and terminates normally and D correctly
>> simulated by H cannot possibly do this.
>
> I.e., H1 can simulate D(D) to its termination but H can't.
>
> Mikko
>

Do you not understand the idea of infinite recursion?

That D DOES call H(D,D) in recursive simulation and
D does not call H1(D,D) in recursive simulation makes
the behavior of D correctly simulated by H different
than the behavior of D correctly simulated by H1.

If you have no idea what infinite recursion is you
will not be able to understand this.

If you don't know that halting means reaching a final
state and terminating normally then you will not be
able to understand the D correctly simulated by H
DOES NOT HALT.

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

On 2024-01-16 18:18:20 +0000, olcott said:

> On 1/16/2024 9:19 AM, Mikko wrote:
>> On 2024-01-13 17:07:56 +0000, olcott said:
>>
>>> Then forget about H1 and simply know that the directly executed D(D)
>>> reaches its final state and terminates normally and D correctly
>>> simulated by H cannot possibly do this.
>>
>> I.e., H1 can simulate D(D) to its termination but H can't.
>>
>> Mikko
>>
>
> Do you not understand the idea of infinite recursion?
>
> That D DOES call H(D,D) in recursive simulation and
> D does not call H1(D,D) in recursive simulation makes
> the behavior of D correctly simulated by H different
> than the behavior of D correctly simulated by H1.
>
> If you have no idea what infinite recursion is you
> will not be able to understand this.
>
> If you don't know that halting means reaching a final
> state and terminating normally then you will not be
> able to understand the D correctly simulated by H
> DOES NOT HALT.

Nice to see that you don't disagree.

Mikko

On 1/16/24 17:01, olcott wrote:
> On 1/16/2024 2:00 AM, immibis wrote:
>> On 1/16/24 00:57, olcott wrote:
>>> On 1/14/2024 10:57 PM, immibis wrote:
>>>> On 1/14/24 19:39, olcott wrote:
>>>>> On 1/14/2024 12:16 PM, immibis wrote:
>>>>>>
>>>>>> D correctly simulated by H must do this because anything correctly
>>>>>> simulated by anything must behave the same as its own direct
>>>>>> execution.
>>>>>
>>>>> It is very easy to prove that is false
>>>>
>>>> Definition of "correctly simulated": X correctly simulated by Y is
>>>> isomorphic to the direct execution of X.
>>>>
>>>> If it's not isomorphic, it's incorrectly simulated.
>>>
>>> The formal proof of the execution trace that D correctly
>>> simulated by H specifies proves that your assumption is
>>> incorrect.
>>>
>>
>> That you can't tell what "correctly simulated" means proves you are
>> dishonest.
>
>
> I think the real issue here is that you lack sufficient technical
> competence to understand these explanations.
>
> _DD()
> [00001c42] 55         push ebp
> [00001c43] 8bec       mov ebp,esp
> [00001c45] 51         push ecx
> [00001c46] 8b4508     mov eax,[ebp+08] ; DD
> [00001c49] 50         push eax         ; DD
> [00001c4a] 8b4d08     mov ecx,[ebp+08] ; DD
> [00001c4d] 51         push ecx         ; DD
> [00001c4e] e80ff7ffff call 00001362    ; HH
> [00001c53] 83c408     add esp,+08
> [00001c56] 8945fc     mov [ebp-04],eax
> [00001c59] 837dfc00   cmp dword [ebp-04],+00
> [00001c5d] 7402       jz 00001c61
> [00001c5f] ebfe       jmp 00001c5f
> [00001c61] 8b45fc     mov eax,[ebp-04]
> [00001c64] 8be5       mov esp,ebp
> [00001c66] 5d         pop ebp
> [00001c67] c3         ret
> Size in bytes:(0038) [00001c67]
>
> 01 int DD(void (*x)())
> 02 {
> 03   int Halt_Status = HH(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11   Output("Input_Halts = ", HH(DD,DD));
> 12 }
>
> The built-in third-party x86 emulator emulates
> the x86 instructions of DD as they are specified.
>
> main() invokes HH(DD,DD)
> that simulates DD(DD)
> that calls a simulated HH(DD,DD)
> that simulates DD(DD)
> that cannot possibly return to its caller.
>
>
HH cannot possibly return to its caller?