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.

--
Copyright 2022 Pete Olcott

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