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