On Fri, 17 Jun 2022 14:34:12 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/17/2022 2:17 PM, Mr Flibble wrote:
> > On Fri, 17 Jun 2022 14:15:04 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/17/2022 1:45 PM, Mr Flibble wrote:
> >>> On Fri, 17 Jun 2022 13:42:05 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/17/2022 12:14 PM, Mr Flibble wrote:
> >>>>> On Fri, 17 Jun 2022 12:13:13 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/17/2022 12:04 PM, Mr Flibble wrote:
> >>>>>>> On Fri, 17 Jun 2022 11:59:53 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/17/2022 11:51 AM, Mr Flibble wrote:
> >>>>>>>>> On Fri, 17 Jun 2022 11:38:29 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 6/17/2022 11:36 AM, Mr Flibble wrote:
> >>>>>>>>>>> On Fri, 17 Jun 2022 11:33:22 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 6/17/2022 11:22 AM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Fri, 17 Jun 2022 11:16:15 -0500
> >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 6/17/2022 11:14 AM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Fri, 17 Jun 2022 11:12:31 -0500
> >>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 6/17/2022 10:56 AM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:49:08 -0500
> >>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 6/17/2022 10:37 AM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500
> >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 6/17/2022 9:56 AM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 09:51:07 -0500
> >>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 6/17/2022 9:39 AM, wij wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On Friday, 17 June 2022 at 22:19:09 UTC+8,
> >>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 6/17/2022 8:39 AM, wij wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On Friday, 17 June 2022 at 19:29:37 UTC+8,
> >>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> When a simulating halt decider rejects all
> >>>>>>>>>>>>>>>>>>>>>>>>>> inputs as non-halting whenever it correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>> detects that its correct and complete
> >>>>>>>>>>>>>>>>>>>>>>>>>> simulation of its input would never reach
> >>>>>>>>>>>>>>>>>>>>>>>>>> the final state of this input then all
> >>>>>>>>>>>>>>>>>>>>>>>>>> [these] inputs (including pathological
> >>>>>>>>>>>>>>>>>>>>>>>>>> inputs) are decided correctly.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> *computation that halts* … the Turing
> >>>>>>>>>>>>>>>>>>>>>>>>>> machine will halt whenever it enters a
> >>>>>>>>>>>>>>>>>>>>>>>>>> final state. (Linz:1990:234)
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal
> >>>>>>>>>>>>>>>>>>>>>>>>>> Languages and Automata. Lexington/Toronto:
> >>>>>>>>>>>>>>>>>>>>>>>>>> D. C. Heath and Company. (317-320)
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 //
> >>>>>>>>>>>>>>>>>>>>>>>>>> call H [00001362](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>>>>>>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [0000136c](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> (1) It is an easily verified fact that when
> >>>>>>>>>>>>>>>>>>>>>>>>>> we assume that H is only an x86 emulator
> >>>>>>>>>>>>>>>>>>>>>>>>>> that the correctly emulated P never reaches
> >>>>>>>>>>>>>>>>>>>>>>>>>> its "ret" instruction it remains stuck in
> >>>>>>>>>>>>>>>>>>>>>>>>>> repeated cycles of emulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> (2) It is an easily verified fact that if H
> >>>>>>>>>>>>>>>>>>>>>>>>>> has been adapted to correctly detect (in a
> >>>>>>>>>>>>>>>>>>>>>>>>>> finite number of steps) that the correct
> >>>>>>>>>>>>>>>>>>>>>>>>>> and complete x86 emulation of its input
> >>>>>>>>>>>>>>>>>>>>>>>>>> would never each its "ret" instruction
> >>>>>>>>>>>>>>>>>>>>>>>>>> that H could abort its emulation and
> >>>>>>>>>>>>>>>>>>>>>>>>>> return 0 to report this.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> (3) When the halt status criteria is
> >>>>>>>>>>>>>>>>>>>>>>>>>> defined as correctly determining whether
> >>>>>>>>>>>>>>>>>>>>>>>>>> or not an x86 emulated input would ever
> >>>>>>>>>>>>>>>>>>>>>>>>>> reach its "ret" instruction then it
> >>>>>>>>>>>>>>>>>>>>>>>>>> becomes an easily verified fact H(P,P)
> >>>>>>>>>>>>>>>>>>>>>>>>>> could correctly reject its input as
> >>>>>>>>>>>>>>>>>>>>>>>>>> non-halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Correct deductive inference proves that all
> >>>>>>>>>>>>>>>>>>>>>>>>>> of these things are true without any need
> >>>>>>>>>>>>>>>>>>>>>>>>>> what-so-ever to see either the source-code
> >>>>>>>>>>>>>>>>>>>>>>>>>> or the execution trace of H.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> The one thing that is not proved is whether
> >>>>>>>>>>>>>>>>>>>>>>>>>> or not an actual encoded H(P,P) does indeed
> >>>>>>>>>>>>>>>>>>>>>>>>>> correctly determine that its input would
> >>>>>>>>>>>>>>>>>>>>>>>>>> never reach its "ret" instruction as a pure
> >>>>>>>>>>>>>>>>>>>>>>>>>> function of its inputs. This aspect will be
> >>>>>>>>>>>>>>>>>>>>>>>>>> confirmed by fully operational source-code.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Halting problem undecidability and
> >>>>>>>>>>>>>>>>>>>>>>>>>> infinitely nested simulation (V5)
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>> Copyright 2022 Pete Olcott
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> "Talent hits a target no one else can hit;
> >>>>>>>>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see."
> >>>>>>>>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> GUR already suggested such a halting
> >>>>>>>>>>>>>>>>>>>>>>>>> decider H cannot exist:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==0 means P(P) does not halt.
> >>>>>>>>>>>>>>>>>>>>>>>> That is a misconception.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Halt deciders must compute the mapping from
> >>>>>>>>>>>>>>>>>>>>>>>> their inputs to an accept or reject state on
> >>>>>>>>>>>>>>>>>>>>>>>> the basis of the actual behavior actually
> >>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the
> >>>>>>>>>>>>>>>>>>>>>>>> correct and complete x86 emulation of the
> >>>>>>>>>>>>>>>>>>>>>>>> input to H(P,P) by H would never reach its
> >>>>>>>>>>>>>>>>>>>>>>>> "ret" instruction thus conclusively proving
> >>>>>>>>>>>>>>>>>>>>>>>> that it never halts.
> >>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==1 means P(P) halts.
> >>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==Otherwise means H fails as a decider
> >>>>>>>>>>>>>>>>>>>>>>>>> (undecidable).
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> -----
> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks to PO's years' tireless efforts
> >>>>>>>>>>>>>>>>>>>>>>>>> demonstrated even himself a genius in
> >>>>>>>>>>>>>>>>>>>>>>>>> 10000-years cannot refute my GUR. ...
> >>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>> Copyright 2022 Pete Olcott
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> "Talent hits a target no one else can hit;
> >>>>>>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see."
> >>>>>>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> GUR suggests no halting decider can exist. You
> >>>>>>>>>>>>>>>>>>>>>>> just confirms it by not able to provide POOH
> >>>>>>>>>>>>>>>>>>>>>>> to test/review.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> It took me six months to figure out how to
> >>>>>>>>>>>>>>>>>>>>>> transform H(P,P) into a pure function of its
> >>>>>>>>>>>>>>>>>>>>>> inputs. I did not release the code before
> >>>>>>>>>>>>>>>>>>>>>> because I knew that its use of static local
> >>>>>>>>>>>>>>>>>>>>>> data would have been rejected. With this
> >>>>>>>>>>>>>>>>>>>>>> update to H I will be able to publish the code.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> H recognizes that P is calling itself with its
> >>>>>>>>>>>>>>>>>>>>>> same arguments that it was called with and
> >>>>>>>>>>>>>>>>>>>>>> there are no instructions preceding this call
> >>>>>>>>>>>>>>>>>>>>>> that could possibly escape infinitely recursive
> >>>>>>>>>>>>>>>>>>>>>> emulation so H aborts its emulation of P before
> >>>>>>>>>>>>>>>>>>>>>> P even makes its first call to H.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Without even looking at the code competent
> >>>>>>>>>>>>>>>>>>>>>> software engineers will be able to verify that
> >>>>>>>>>>>>>>>>>>>>>> the above H would correctly determine that that
> >>>>>>>>>>>>>>>>>>>>>> is input is non-halting as a pure function of
> >>>>>>>>>>>>>>>>>>>>>> this input.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> So my other reply for why your H is not a pure
> >>>>>>>>>>>>>>>>>>>>> function for any accepted definition of the
> >>>>>>>>>>>>>>>>>>>>> term.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> In computer programming, a pure function is a
> >>>>>>>>>>>>>>>>>>>> function that has the following properties:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> (1) the function return values are identical for
> >>>>>>>>>>>>>>>>>>>> identical arguments (no variation with local
> >>>>>>>>>>>>>>>>>>>> static variables, non-local variables, mutable
> >>>>>>>>>>>>>>>>>>>> reference arguments or input streams), and
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> (2) the function application has no side effects
> >>>>>>>>>>>>>>>>>>>> (no mutation of local static variables, non-local
> >>>>>>>>>>>>>>>>>>>> variables, mutable reference arguments or
> >>>>>>>>>>>>>>>>>>>> input/output streams).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thus a pure function is a computational analogue
> >>>>>>>>>>>>>>>>>>>> of a mathematical function.
> >>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The revised H has no:
> >>>>>>>>>>>>>>>>>>>> (a) local static variables
> >>>>>>>>>>>>>>>>>>>> (b) non-local variables
> >>>>>>>>>>>>>>>>>>>> (c) mutable reference arguments
> >>>>>>>>>>>>>>>>>>>> (d) input streams
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Aborting the simulation is a side effect; pure
> >>>>>>>>>>>>>>>>>>> functions do not have side effects.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You have a reading comprehension problem.
> >>>>>>>>>>>>>>>>>> If H does not have (a)(b)(c)(d) then
> >>>>>>>>>>>>>>>>>> H has no mutation side effect to (a)(b)(c)(d)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Not at all, but you do seem to have that problem.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Again:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Aborting the simulation is a side effect; pure
> >>>>>>>>>>>>>>>>> functions do not have side effects.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Whether or not it is construed as a side-effect does
> >>>>>>>>>>>>>>>> not matter it must be a mutation side-effect to
> >>>>>>>>>>>>>>>> (a)(b)(c)(d) or it does not count.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It doesn't count according to who?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The above definition of pure functions.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> "In computer science, an operation, function or
> >>>>>>>>>>>>> expression is said to have a side effect if it modifies
> >>>>>>>>>>>>> some state variable value(s) outside its local
> >>>>>>>>>>>>> environment,
> >>>>>>>>>>>>
> >>>>>>>>>>>> The second part is an inaccurate paraphrase of the first
> >>>>>>>>>>>> part.
> >>>>>>>>>>>>> which is to say if it has any observable effect
> >>>>>>>>>>>>> other than its primary effect of returning a value to
> >>>>>>>>>>>>> the invoker of the operation." --
> >>>>>>>>>>>>> https://en.wikipedia.org/wiki/Side_effect_(computer_science)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> "any observable effect"
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Aborting the simulation instead of returning a value to
> >>>>>>>>>>>>> the invoker disqualifies it from being a pure function.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>> return;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> int main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> _P()
> >>>>>>>>>>>> [00001352](01) 55 push ebp
> >>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
> >>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>> [00001358](01) 50 push eax // push P
> >>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
> >>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
> >>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
> >>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
> >>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
> >>>>>>>>>>>> [0000136b](01) 5d pop ebp
> >>>>>>>>>>>> [0000136c](01) c3 ret
> >>>>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>>>>
> >>>>>>>>>>>> H aborts its x86 emulation of P as soon P reaches its
> >>>>>>>>>>>> machine address of [0000135d] the very first time before
> >>>>>>>>>>>> the code at this address is emulated. Then H returns 0 to
> >>>>>>>>>>>> its caller: main().
> >>>>>>>>>>>
> >>>>>>>>>>> Returning to main() is not returning to its invoker, P.
> >>>>>>>>>>>
> >>>>>>>>>>> Again:
> >>>>>>>>>>>
> >>>>>>>>>>> Aborting the simulation is a side effect; pure functions
> >>>>>>>>>>> do not have side effects.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Do you have ADD?
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> If your claim is that H is only called once and the second
> >>>>>>>>> time an *attempt* to call H is prevented than that is
> >>>>>>>>> equivalent to calling H and having H do something different
> >>>>>>>>> with side effects. This is just my opinion though as it
> >>>>>>>>> requires more thought and I am currently getting drunk on
> >>>>>>>>> gin and tonics.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> It is obviously the exact same pattern as infinite recursion
> >>>>>>>> (a) calling the same function a second time with the same
> >>>>>>>> arguments and
> >>>>>>>>
> >>>>>>>> (b) there are no instructions preceding this call that could
> >>>>>>>> possibly escape the infinite recursion / infinitely recursive
> >>>>>>>> emulation.
> >>>>>>>
> >>>>>>> Agree but refusing to analyse what P would have done if H
> >>>>>>> wasn't a simulating decider still makes what you've got
> >>>>>>> worthless as far as the Halting Problem is concerned.
> >>>>>>>
> >>>>>>> /Flibble (getting drunk, possibly not quite at Ballmer's Peak)
> >>>>>>>
> >>>>>>
> >>>>>> It is dead obvious to everyone (even Richard) that what P would
> >>>>>> have done if H was merely an x86 emulator and not a halt
> >>>>>> deciding emulator.
> >>>>>>
> >>>>>> The correct and complete x86 emulation of H(P,P) would never
> >>>>>> reach its "ret" instruction thus making H a correct "not reach
> >>>>>> ret" / halt decider for P.
> >>>>>
> >>>>> You need to think about a P that calls H but is non-pathological
> >>>>> halting (no infinite loop).
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> I have already done that and posted all of the details here about
> >>>> three dozen times.
> >>>>
> >>>> void P(ptr x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H1(P, P));
> >>>> }
> >>>>
> >>>> It remains true that the correct and complete x86 emulation of
> >>>> the input to H(P,P) by H never reaches its "ret" instruction
> >>>> thus never halts.
> >>>
> >>> Try reading what I actually wrote:
> >>>
> >>> void P(ptr x)
> >>> {
> >>> H(x, x); // ignore result
> >>> return; // halt
> >>> }
> >>>
> >>> How does your "decider" handle that P?
> >>>
> >>> /Flibble
> >>>
> >>
> >> Removing the infinite loop does not make it non pathological.
> >> As I have said donzens of times the infinite loop is unreachable.
> >>
> >> void Px(u32 x)
> >> {
> >> H(x, x);
> >> return;
> >> }
> >>
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >> }
> >>
> >> _Px()
> >> [000013b6](01) 55 push ebp
> >> [000013b7](02) 8bec mov ebp,esp
> >> [000013b9](03) 8b4508 mov eax,[ebp+08]
> >> [000013bc](01) 50 push eax
> >> [000013bd](03) 8b4d08 mov ecx,[ebp+08]
> >> [000013c0](01) 51 push ecx
> >> [000013c1](05) e8e0fdffff call 000011a6
> >> [000013c6](03) 83c408 add esp,+08
> >> [000013c9](01) 5d pop ebp
> >> [000013ca](01) c3 ret
> >> Size in bytes:(0021) [000013ca]
> >>
> >> _main()
> >> [000013d6](01) 55 push ebp
> >> [000013d7](02) 8bec mov ebp,esp
> >> [000013d9](05) 68b6130000 push 000013b6
> >> [000013de](05) 68b6130000 push 000013b6
> >> [000013e3](05) e8befdffff call 000011a6
> >> [000013e8](03) 83c408 add esp,+08
> >> [000013eb](01) 50 push eax
> >> [000013ec](05) 6827040000 push 00000427
> >> [000013f1](05) e880f0ffff call 00000476
> >> [000013f6](03) 83c408 add esp,+08
> >> [000013f9](02) 33c0 xor eax,eax
> >> [000013fb](01) 5d pop ebp
> >> [000013fc](01) c3 ret
> >> Size in bytes:(0039) [000013fc]
> >>
> >> machine stack stack machine assembly
> >> address address data code language
> >> ======== ======== ======== ========= ============> >> ...[000013d6][00102357][00000000] 55 push ebp
> >> ...[000013d7][00102357][00000000] 8bec mov ebp,esp
> >> ...[000013d9][00102353][000013b6] 68b6130000 push 000013b6
> >> ...[000013de][0010234f][000013b6] 68b6130000 push 000013b6
> >> ...[000013e3][0010234b][000013e8] e8befdffff call 000011a6
> >>
> >> Begin Local Halt Decider Simulation Execution Trace Stored
> >> at:21240b ...[000013b6][002123f7][002123fb] 55 push
> >> ebp ...[000013b7][002123f7][002123fb] 8bec mov ebp,esp
> >> ...[000013b9][002123f7][002123fb] 8b4508 mov eax,[ebp+08]
> >> ...[000013bc][002123f3][000013b6] 50 push eax
> >> ...[000013bd][002123f3][000013b6] 8b4d08 mov ecx,[ebp+08]
> >> ...[000013c0][002123ef][000013b6] 51 push ecx
> >> ...[000013c1][002123eb][000013c6] e8e0fdffff call 000011a6
> >> ...[000013b6][0025ce1f][0025ce23] 55 push ebp
> >> ...[000013b7][0025ce1f][0025ce23] 8bec mov ebp,esp
> >> ...[000013b9][0025ce1f][0025ce23] 8b4508 mov eax,[ebp+08]
> >> ...[000013bc][0025ce1b][000013b6] 50 push eax
> >> ...[000013bd][0025ce1b][000013b6] 8b4d08 mov ecx,[ebp+08]
> >> ...[000013c0][0025ce17][000013b6] 51 push ecx
> >> ...[000013c1][0025ce13][000013c6] e8e0fdffff call 000011a6
> >> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >>
> >> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >> ...[000013eb][00102353][00000000] 50 push eax
> >> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >> Input_Halts = 0
> >> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >> ...[000013fb][0010235b][00100000] 5d pop ebp
> >> ...[000013fc][0010235f][00000004] c3 ret
> >> Number of Instructions Executed(16120)
> >
> > So it gets the answer wrong. QED.
> >
> > /Flibble
> >
> >
>
> comp.theory:
> [Solution to one instance of the Halting Problem]
> On 3/14/2017 9:05 AM, peteolcott wrote:
>
> This is the culmination of the essence of more than five years worth
> of full time work when I first discovered that a simulating halt
> decider could correctly determine the halt status of the "impossible"
> input:
>
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects that its correct and complete
> simulation of its input would never reach the final state of this
> input that all [these] inputs (including pathological inputs) are
> decided correctly.

It gets the answer wrong. QED.

/Flibble