On 8/27/2022 2:07 PM, Mr Flibble wrote:
> On Sat, 27 Aug 2022 13:30:48 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/27/2022 1:12 PM, Mr Flibble wrote:
>>> On Sat, 27 Aug 2022 13:08:42 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 8/27/2022 12:58 PM, Mr Flibble wrote:
>>>>> On Sat, 27 Aug 2022 12:56:31 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 8/27/2022 12:42 PM, Mr Flibble wrote:
>>>>>>> On Sat, 27 Aug 2022 12:35:44 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 8/27/2022 12:29 PM, Richard Damon wrote:
>>>>>>>>> On 8/27/22 1:15 PM, olcott wrote:
>>>>>>>>>> On 8/27/2022 12:12 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 27 Aug 2022 11:58:13 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 8/27/2022 11:28 AM, Mr Flibble wrote:
>>>>>>>>>>>>> Blocking/ignoring your reviewers means only one thing: you
>>>>>>>>>>>>> do not want an honest review of your work and you are
>>>>>>>>>>>>> yourself dishonest.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>
>>>>>>>> This is the complete system:
>>>>>>>> https://www.liarparadox.org/2022_08_16.zip
>>>>>>>>
>>>>>>>> Microsoft Visual Studio Community 2017
>>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
>>>>>>>
>>>>>>> Ah so you are claiming to be a member of the Terry A. Davis
>>>>>>> (R.I.P) club? It all makes sense now: you are simply a nutter.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> void Px(void (*x)())
>>>>>> {
>>>>>> (void) H(x, x);
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>> }
>>>>>>
>>>>>> Flibble does not understand that
>>>>>>
>>>>>> when simulating halt decider H(Px,Px) correctly simulates its
>>>>>> input the "return" instruction of the simulated Px in
>>>>>> unreachable by this simulated Px.
>>>>>
>>>>> Px should always halt you nutter:
>>>>
>>>> It is a matter of easily verified fact the Px never reaches its
>>>> final state. I have fully operational software that proves this.
>>>> All that you have is misconceptions and empty rhetoric.
>>>
>>> Px halts if H is designed correctly (a valid halt decider always
>>> returns a result to its caller) ergo H is not designed correctly.
>>> Simple undeniable logic, dear.
>>>
>>> /Flibble
>>>
>>
>> That is not the same as you claimed:
>> >>> Px should always halt you nutter:
>
> Now you seem to be unable to comprehend simple English.
>
> /Flibble
>

Px is the program-under-test thus it may be a non-halting input to a
simulating halt decider. Only the SHD itself must halt, if a non-halting
input halts a contradiction is formed, thus non-halting input must never
halt.

--
Copyright 2022 Pete Olcott

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

On 8/27/22 1:35 PM, olcott wrote:
> On 8/27/2022 12:29 PM, Richard Damon wrote:
>> On 8/27/22 1:15 PM, olcott wrote:
>>> On 8/27/2022 12:12 PM, Mr Flibble wrote:
>>>> On Sat, 27 Aug 2022 11:58:13 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 8/27/2022 11:28 AM, Mr Flibble wrote:
>>>>>> Blocking/ignoring your reviewers means only one thing: you do not
>>>>>> want an honest review of your work and you are yourself dishonest.
>>>>>>
>>>>>> /Flibble
>
> *No one would build a complete operating system as a mere ruse*
> *No one would build a complete operating system as a mere ruse*
> *No one would build a complete operating system as a mere ruse*
> *No one would build a complete operating system as a mere ruse*
>
> This is the complete system:
> https://www.liarparadox.org/2022_08_16.zip
>
> Microsoft Visual Studio Community 2017
> https://visualstudio.microsoft.com/vs/older-downloads/
>
>
>

Except you DIDN'T build an "Operating System", maybe you don't
understand what that actually is.

You have written a framework.

Poorly written at that, from what I have seen.

On 8/27/22 3:46 PM, olcott wrote:
> On 8/27/2022 2:07 PM, Mr Flibble wrote:
>> On Sat, 27 Aug 2022 13:30:48 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 8/27/2022 1:12 PM, Mr Flibble wrote:
>>>> On Sat, 27 Aug 2022 13:08:42 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 8/27/2022 12:58 PM, Mr Flibble wrote:
>>>>>> On Sat, 27 Aug 2022 12:56:31 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 8/27/2022 12:42 PM, Mr Flibble wrote:
>>>>>>>> On Sat, 27 Aug 2022 12:35:44 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 8/27/2022 12:29 PM, Richard Damon wrote:
>>>>>>>>>> On 8/27/22 1:15 PM, olcott wrote:
>>>>>>>>>>> On 8/27/2022 12:12 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 27 Aug 2022 11:58:13 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 8/27/2022 11:28 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> Blocking/ignoring your reviewers means only one thing: you
>>>>>>>>>>>>>> do not want an honest review of your work and you are
>>>>>>>>>>>>>> yourself dishonest.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>>
>>>>>>>>> This is the complete system:
>>>>>>>>> https://www.liarparadox.org/2022_08_16.zip
>>>>>>>>>
>>>>>>>>> Microsoft Visual Studio Community 2017
>>>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
>>>>>>>>
>>>>>>>> Ah so you are claiming to be a member of the Terry A. Davis
>>>>>>>> (R.I.P) club?  It all makes sense now: you are simply a nutter.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>>       (void) H(x, x);
>>>>>>>       return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>       Output("Input_Halts = ", H(Px, Px));
>>>>>>> }
>>>>>>>
>>>>>>> Flibble does not understand that
>>>>>>>
>>>>>>> when simulating halt decider H(Px,Px) correctly simulates its
>>>>>>> input the "return" instruction of the simulated Px in
>>>>>>> unreachable by this simulated Px.
>>>>>>
>>>>>> Px should always halt you nutter:
>>>>>
>>>>> It is a matter of easily verified fact the Px never reaches its
>>>>> final state. I have fully operational software that proves this.
>>>>> All that you have is misconceptions and empty rhetoric.
>>>>
>>>> Px halts if H is designed correctly (a valid halt decider always
>>>> returns a result to its caller) ergo H is not designed correctly.
>>>> Simple undeniable logic, dear.
>>>>
>>>> /Flibble
>>>
>>> That is not the same as you claimed:
>>>   >>> Px should always halt you nutter:
>>
>> Now you seem to be unable to comprehend simple English.
>>
>> /Flibble
>>
>
> Px is the program-under-test thus it may be a non-halting input to a
> simulating halt decider. Only the SHD itself must halt, if a non-halting
> input halts a contradiction is formed, thus non-halting input must never
> halt.
>

But Non-Halting per Halt Decider is about the PROGRAM ITSELF, not the
deciders simulation of it.

Since a dirrect Running of Px(Px) will Halt, if H(Px,Px) returns an
answer, the correct answer for H(Px,Px) is 1.

Definition:

H(P,d) return 1 if P(d) halts, and returns 0 of P(d) does not Halt.

Unless you admit that H isn't supposed to be a Halt Decider, then you
have to admit that it gives the wrong answer for one.

If a SHD uses different rules, then you need to admit that they aren't
actually Halt Deciders. (and you are using deceptive naming).

On Sat, 27 Aug 2022 14:26:36 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/27/2022 2:05 PM, Mr Flibble wrote:
> > On Sat, 27 Aug 2022 13:35:12 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 8/27/2022 1:12 PM, Mr Flibble wrote:
> >>> On Sat, 27 Aug 2022 13:08:42 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 8/27/2022 12:58 PM, Mr Flibble wrote:
> >>>>> On Sat, 27 Aug 2022 12:56:31 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 8/27/2022 12:42 PM, Mr Flibble wrote:
> >>>>>>> On Sat, 27 Aug 2022 12:35:44 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 8/27/2022 12:29 PM, Richard Damon wrote:
> >>>>>>>>> On 8/27/22 1:15 PM, olcott wrote:
> >>>>>>>>>> On 8/27/2022 12:12 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Sat, 27 Aug 2022 11:58:13 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 8/27/2022 11:28 AM, Mr Flibble wrote:
> >>>>>>>>>>>>> Blocking/ignoring your reviewers means only one thing:
> >>>>>>>>>>>>> you do not want an honest review of your work and you
> >>>>>>>>>>>>> are yourself dishonest.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>
> >>>>>>>> *No one would build a complete operating system as a mere
> >>>>>>>> ruse* *No one would build a complete operating system as a
> >>>>>>>> mere ruse* *No one would build a complete operating system
> >>>>>>>> as a mere ruse* *No one would build a complete operating
> >>>>>>>> system as a mere ruse*
> >>>>>>>>
> >>>>>>>> This is the complete system:
> >>>>>>>> https://www.liarparadox.org/2022_08_16.zip
> >>>>>>>>
> >>>>>>>> Microsoft Visual Studio Community 2017
> >>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
> >>>>>>>
> >>>>>>> Ah so you are claiming to be a member of the Terry A. Davis
> >>>>>>> (R.I.P) club? It all makes sense now: you are simply a
> >>>>>>> nutter.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> void Px(void (*x)())
> >>>>>> {
> >>>>>> (void) H(x, x);
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H(Px, Px));
> >>>>>> }
> >>>>>>
> >>>>>> Flibble does not understand that
> >>>>>>
> >>>>>> when simulating halt decider H(Px,Px) correctly simulates its
> >>>>>> input the "return" instruction of the simulated Px in
> >>>>>> unreachable by this simulated Px.
> >>>>>
> >>>>> Px should always halt you nutter:
> >>>>
> >>>> It is a matter of easily verified fact the Px never reaches its
> >>>> final state. I have fully operational software that proves this.
> >>>> All that you have is misconceptions and empty rhetoric.
> >>>
> >>> Px halts if H is designed correctly
> >>
> >> INCORRECT
> >>
> >>> (a valid halt decider always
> >>> returns a result to its caller) ergo H is not designed correctly.
> >>>
> >>
> >> CORRECT
> >>
> >>> Simple undeniable logic, dear.
> >>>
> >>> /Flibble
> >>>
> >>
> >> You just said that the non-halting input to a simulating halt
> >> decider must halt, that is a contradiction.
> >
> > No, dear, I am saying that your simulating halt decider is not a
> > valid halt decider as it doesn't return a result to its caller,
>
> In other words you believe that a function called in (what is
> essentially) infinite recursion must return to its caller even though
> it is an axiom to no function called in infinite recursion ever
> returns to its caller?
>
> When any system of axioms has a pair of axioms that contradict each
> other at most one of these axioms is correct.
>
> (a) Deciders must always return to their caller.
> (b) No function called in infinite recursion returns to its caller.
>
> When deciders are called in infinite recursion we have contradictory
> axioms.
>
> *HERE IS WHAT ACTUALLY HAPPENS*
> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...
> *Until H aborts its simulation*
> (e) then H(P,P) returns to main()
>
> (a) P(P) invokes H(P,P)
> (b) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)
> (e) that simulates P(P) that calls a simulated H(P,P)...
> *Until H aborts its simulation*
> (f) then H(P,P) returns to P(P) in main()
>
> (a) Deciders must always return to their caller.
> becomes
> (a) Deciders that are not called in infinite recursion must always
> return to their caller.

Simple enough to refute by counter-example, dear: the Flibble Signaling
Halt Decider (TM) is a simulating halt decider that does return to its
caller, dear. If the Flibble decider was called by Px it would return a
result to Px and Px would then correctly halt. Your simulating halt
decider doesn't do that as it has been designed incorrectly. Your
simulating halt decider is NOT a halt decider so I suggest you rename
it to the Olcott Bullshit Decider.

/Flibble

On 8/27/2022 3:01 PM, Richard Damon wrote:
>
> On 8/27/22 3:46 PM, olcott wrote:
>> On 8/27/2022 2:07 PM, Mr Flibble wrote:
>>> On Sat, 27 Aug 2022 13:30:48 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 8/27/2022 1:12 PM, Mr Flibble wrote:
>>>>> On Sat, 27 Aug 2022 13:08:42 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>> On 8/27/2022 12:58 PM, Mr Flibble wrote:
>>>>>>> On Sat, 27 Aug 2022 12:56:31 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>> On 8/27/2022 12:42 PM, Mr Flibble wrote:
>>>>>>>>> On Sat, 27 Aug 2022 12:35:44 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>> On 8/27/2022 12:29 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/27/22 1:15 PM, olcott wrote:
>>>>>>>>>>>> On 8/27/2022 12:12 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 27 Aug 2022 11:58:13 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>> On 8/27/2022 11:28 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> Blocking/ignoring your reviewers means only one thing: you
>>>>>>>>>>>>>>> do not want an honest review of your work and you are
>>>>>>>>>>>>>>> yourself dishonest.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>>>
>>>>>>>>>> This is the complete system:
>>>>>>>>>> https://www.liarparadox.org/2022_08_16.zip
>>>>>>>>>>
>>>>>>>>>> Microsoft Visual Studio Community 2017
>>>>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
>>>>>>>>>
>>>>>>>>> Ah so you are claiming to be a member of the Terry A. Davis
>>>>>>>>> (R.I.P) club?  It all makes sense now: you are simply a nutter.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> void Px(void (*x)())
>>>>>>>> {
>>>>>>>>       (void) H(x, x);
>>>>>>>>       return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>       Output("Input_Halts = ", H(Px, Px));
>>>>>>>> }
>>>>>>>>
>>>>>>>> Flibble does not understand that
>>>>>>>>
>>>>>>>> when simulating halt decider H(Px,Px) correctly simulates its
>>>>>>>> input the "return" instruction of the simulated Px in
>>>>>>>> unreachable by this simulated Px.
>>>>>>>
>>>>>>> Px should always halt you nutter:
>>>>>>
>>>>>> It is a matter of easily verified fact the Px never reaches its
>>>>>> final state. I have fully operational software that proves this.
>>>>>> All that you have is misconceptions and empty rhetoric.
>>>>>
>>>>> Px halts if H is designed correctly (a valid halt decider always
>>>>> returns a result to its caller) ergo H is not designed correctly.
>>>>> Simple undeniable logic, dear.
>>>>>
>>>>> /Flibble
>>>>
>>>> That is not the same as you claimed:
>>>>   >>> Px should always halt you nutter:
>>>
>>> Now you seem to be unable to comprehend simple English.
>>>
>>> /Flibble
>>>
>>
>> Px is the program-under-test thus it may be a non-halting input to a
>> simulating halt decider. Only the SHD itself must halt, if a
>> non-halting input halts a contradiction is formed, thus non-halting
>> input must never halt.
>>
>
> But Non-Halting per Halt Decider is about the PROGRAM ITSELF, not the
> deciders simulation of it.
That violates the correct definition of a decider:

Every decider must compute the mapping from its input finite string
based on a semantic or syntactic property of this finite string.

int sum(int x, int y)
{ return x + y;
}

sum(3,4) cannot and must not return the sum of 5 + 7.

--
Copyright 2022 Pete Olcott

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

On 8/27/22 5:11 PM, olcott wrote:
> On 8/27/2022 3:01 PM, Richard Damon wrote:
>>
>> On 8/27/22 3:46 PM, olcott wrote:
>>> On 8/27/2022 2:07 PM, Mr Flibble wrote:
>>>> On Sat, 27 Aug 2022 13:30:48 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 8/27/2022 1:12 PM, Mr Flibble wrote:
>>>>>> On Sat, 27 Aug 2022 13:08:42 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 8/27/2022 12:58 PM, Mr Flibble wrote:
>>>>>>>> On Sat, 27 Aug 2022 12:56:31 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 8/27/2022 12:42 PM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 27 Aug 2022 12:35:44 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 8/27/2022 12:29 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/27/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>> On 8/27/2022 12:12 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sat, 27 Aug 2022 11:58:13 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 8/27/2022 11:28 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> Blocking/ignoring your reviewers means only one thing: you
>>>>>>>>>>>>>>>> do not want an honest review of your work and you are
>>>>>>>>>>>>>>>> yourself dishonest.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>>>> *No one would build a complete operating system as a mere ruse*
>>>>>>>>>>>
>>>>>>>>>>> This is the complete system:
>>>>>>>>>>> https://www.liarparadox.org/2022_08_16.zip
>>>>>>>>>>>
>>>>>>>>>>> Microsoft Visual Studio Community 2017
>>>>>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
>>>>>>>>>>
>>>>>>>>>> Ah so you are claiming to be a member of the Terry A. Davis
>>>>>>>>>> (R.I.P) club?  It all makes sense now: you are simply a nutter.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> void Px(void (*x)())
>>>>>>>>> {
>>>>>>>>>       (void) H(x, x);
>>>>>>>>>       return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>       Output("Input_Halts = ", H(Px, Px));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Flibble does not understand that
>>>>>>>>>
>>>>>>>>> when simulating halt decider H(Px,Px) correctly simulates its
>>>>>>>>> input the "return" instruction of the simulated Px in
>>>>>>>>> unreachable by this simulated Px.
>>>>>>>>
>>>>>>>> Px should always halt you nutter:
>>>>>>>
>>>>>>> It is a matter of easily verified fact the Px never reaches its
>>>>>>> final state. I have fully operational software that proves this.
>>>>>>> All that you have is misconceptions and empty rhetoric.
>>>>>>
>>>>>> Px halts if H is designed correctly (a valid halt decider always
>>>>>> returns a result to its caller) ergo H is not designed correctly.
>>>>>> Simple undeniable logic, dear.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> That is not the same as you claimed:
>>>>>   >>> Px should always halt you nutter:
>>>>
>>>> Now you seem to be unable to comprehend simple English.
>>>>
>>>> /Flibble
>>>>
>>>
>>> Px is the program-under-test thus it may be a non-halting input to a
>>> simulating halt decider. Only the SHD itself must halt, if a
>>> non-halting input halts a contradiction is formed, thus non-halting
>>> input must never halt.
>>>
>>
>> But Non-Halting per Halt Decider is about the PROGRAM ITSELF, not the
>> deciders simulation of it.
> That violates the correct definition of a decider:
>
> Every decider must compute the mapping from its input finite string
> based on a semantic or syntactic property of this finite string.

The semantic property of that finite string is does UTM(P,d) Halt.

There is no requirement tha the property be computable to be a valid
requirement, only to actually implement it.

THe Halting Property is properly a semantic property of the input.

It just isn't a computable property, which is why the Halting Function
is not Computable.

>
> int sum(int x, int y)
> {
>   return x + y;
> }
>
> sum(3,4) cannot and must not return the sum of 5 + 7.
>

I never said to do that, that is just you serving up some Red Herring.

I AM asking about the value of Halting(P, d), which IS a mapping of the
representation of P and d to a value of Halting or Non-Halting based on
the deterministic behavior of UTM(P,d).

On 8/27/2022 3:06 PM, Mr Flibble wrote:
> On Sat, 27 Aug 2022 14:26:36 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/27/2022 2:05 PM, Mr Flibble wrote:
>>> On Sat, 27 Aug 2022 13:35:12 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 8/27/2022 1:12 PM, Mr Flibble wrote:
>>>>> On Sat, 27 Aug 2022 13:08:42 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 8/27/2022 12:58 PM, Mr Flibble wrote:
>>>>>>> On Sat, 27 Aug 2022 12:56:31 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 8/27/2022 12:42 PM, Mr Flibble wrote:
>>>>>>>>> On Sat, 27 Aug 2022 12:35:44 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 8/27/2022 12:29 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/27/22 1:15 PM, olcott wrote:
>>>>>>>>>>>> On 8/27/2022 12:12 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 27 Aug 2022 11:58:13 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/27/2022 11:28 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> Blocking/ignoring your reviewers means only one thing:
>>>>>>>>>>>>>>> you do not want an honest review of your work and you
>>>>>>>>>>>>>>> are yourself dishonest.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> *No one would build a complete operating system as a mere
>>>>>>>>>> ruse* *No one would build a complete operating system as a
>>>>>>>>>> mere ruse* *No one would build a complete operating system
>>>>>>>>>> as a mere ruse* *No one would build a complete operating
>>>>>>>>>> system as a mere ruse*
>>>>>>>>>>
>>>>>>>>>> This is the complete system:
>>>>>>>>>> https://www.liarparadox.org/2022_08_16.zip
>>>>>>>>>>
>>>>>>>>>> Microsoft Visual Studio Community 2017
>>>>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
>>>>>>>>>
>>>>>>>>> Ah so you are claiming to be a member of the Terry A. Davis
>>>>>>>>> (R.I.P) club? It all makes sense now: you are simply a
>>>>>>>>> nutter.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> void Px(void (*x)())
>>>>>>>> {
>>>>>>>> (void) H(x, x);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>> }
>>>>>>>>
>>>>>>>> Flibble does not understand that
>>>>>>>>
>>>>>>>> when simulating halt decider H(Px,Px) correctly simulates its
>>>>>>>> input the "return" instruction of the simulated Px in
>>>>>>>> unreachable by this simulated Px.
>>>>>>>
>>>>>>> Px should always halt you nutter:
>>>>>>
>>>>>> It is a matter of easily verified fact the Px never reaches its
>>>>>> final state. I have fully operational software that proves this.
>>>>>> All that you have is misconceptions and empty rhetoric.
>>>>>
>>>>> Px halts if H is designed correctly
>>>>
>>>> INCORRECT
>>>>
>>>>> (a valid halt decider always
>>>>> returns a result to its caller) ergo H is not designed correctly.
>>>>>
>>>>
>>>> CORRECT
>>>>
>>>>> Simple undeniable logic, dear.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> You just said that the non-halting input to a simulating halt
>>>> decider must halt, that is a contradiction.
>>>
>>> No, dear, I am saying that your simulating halt decider is not a
>>> valid halt decider as it doesn't return a result to its caller,
>>
>> In other words you believe that a function called in (what is
>> essentially) infinite recursion must return to its caller even though
>> it is an axiom to no function called in infinite recursion ever
>> returns to its caller?
>>
>> When any system of axioms has a pair of axioms that contradict each
>> other at most one of these axioms is correct.
>>
>> (a) Deciders must always return to their caller.
>> (b) No function called in infinite recursion returns to its caller.
>>
>> When deciders are called in infinite recursion we have contradictory
>> axioms.
>>
>> *HERE IS WHAT ACTUALLY HAPPENS*
>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>> (b) that simulates P(P) that calls a simulated H(P,P)
>> (c) that simulates P(P) that calls a simulated H(P,P)
>> (d) that simulates P(P) that calls a simulated H(P,P)...
>> *Until H aborts its simulation*
>> (e) then H(P,P) returns to main()
>>
>> (a) P(P) invokes H(P,P)
>> (b) H(P,P) simulates P(P) that calls a simulated H(P,P)
>> (c) that simulates P(P) that calls a simulated H(P,P)
>> (d) that simulates P(P) that calls a simulated H(P,P)
>> (e) that simulates P(P) that calls a simulated H(P,P)...
>> *Until H aborts its simulation*
>> (f) then H(P,P) returns to P(P) in main()
>>
>> (a) Deciders must always return to their caller.
>> becomes
>> (a) Deciders that are not called in infinite recursion must always
>> return to their caller.
>
> Simple enough to refute by counter-example, dear: the Flibble Signaling
> Halt Decider (TM) is a simulating halt decider that does return to its
> caller, dear.

It is not doing what the semantics of its inputs specifies that it must do.

void Px(void (*x)())
{ (void) HH(x, x);
return;
}

int main()
{ Output("Input_Halts = ", HH(Px, Px));
}

The correct pure simulation of the input to HH by HH as if HH was only a
simulator and not a simulating halt decider is this:

(a) H(Px,Px) simulates Px(Px) that calls a simulated H(Px,Px)
(b) that simulates Px(Px) that calls a simulated H(Px,Px)
(c) that simulates Px(Px) that calls a simulated H(Px,Px)
(d) that simulates Px(Px) that calls a simulated H(Px,Px)...

_Px()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](03) 8b4508 mov eax,[ebp+08]
[00001108](01) 50 push eax // Push Px
[00001109](03) 8b4d08 mov ecx,[ebp+08]
[0000110c](01) 51 push ecx // Push Px
[0000110d](05) e890fbffff call 00000ca2 // call HH
[00001112](03) 83c408 add esp,+08
[00001115](01) 5d pop ebp
[00001116](01) c3 ret
Size in bytes:(0021) [00001116]

It is not possible for HH to correctly return to a simulated Px.
Every Px that HH(Px,Px) correctly simulates cannot possibly correctly
reach past machine address [0000110d].

--
Copyright 2022 Pete Olcott

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

On Sat, 27 Aug 2022 16:25:44 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/27/2022 3:06 PM, Mr Flibble wrote:
> > On Sat, 27 Aug 2022 14:26:36 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 8/27/2022 2:05 PM, Mr Flibble wrote:
> >>> On Sat, 27 Aug 2022 13:35:12 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 8/27/2022 1:12 PM, Mr Flibble wrote:
> >>>>> On Sat, 27 Aug 2022 13:08:42 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 8/27/2022 12:58 PM, Mr Flibble wrote:
> >>>>>>> On Sat, 27 Aug 2022 12:56:31 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 8/27/2022 12:42 PM, Mr Flibble wrote:
> >>>>>>>>> On Sat, 27 Aug 2022 12:35:44 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 8/27/2022 12:29 PM, Richard Damon wrote:
> >>>>>>>>>>> On 8/27/22 1:15 PM, olcott wrote:
> >>>>>>>>>>>> On 8/27/2022 12:12 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Sat, 27 Aug 2022 11:58:13 -0500
> >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 8/27/2022 11:28 AM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> Blocking/ignoring your reviewers means only one thing:
> >>>>>>>>>>>>>>> you do not want an honest review of your work and you
> >>>>>>>>>>>>>>> are yourself dishonest.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>
> >>>>>>>>>> *No one would build a complete operating system as a mere
> >>>>>>>>>> ruse* *No one would build a complete operating system as a
> >>>>>>>>>> mere ruse* *No one would build a complete operating system
> >>>>>>>>>> as a mere ruse* *No one would build a complete operating
> >>>>>>>>>> system as a mere ruse*
> >>>>>>>>>>
> >>>>>>>>>> This is the complete system:
> >>>>>>>>>> https://www.liarparadox.org/2022_08_16.zip
> >>>>>>>>>>
> >>>>>>>>>> Microsoft Visual Studio Community 2017
> >>>>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
> >>>>>>>>>
> >>>>>>>>> Ah so you are claiming to be a member of the Terry A. Davis
> >>>>>>>>> (R.I.P) club? It all makes sense now: you are simply a
> >>>>>>>>> nutter.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> void Px(void (*x)())
> >>>>>>>> {
> >>>>>>>> (void) H(x, x);
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> Output("Input_Halts = ", H(Px, Px));
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> Flibble does not understand that
> >>>>>>>>
> >>>>>>>> when simulating halt decider H(Px,Px) correctly simulates its
> >>>>>>>> input the "return" instruction of the simulated Px in
> >>>>>>>> unreachable by this simulated Px.
> >>>>>>>
> >>>>>>> Px should always halt you nutter:
> >>>>>>
> >>>>>> It is a matter of easily verified fact the Px never reaches its
> >>>>>> final state. I have fully operational software that proves
> >>>>>> this. All that you have is misconceptions and empty rhetoric.
> >>>>>
> >>>>> Px halts if H is designed correctly
> >>>>
> >>>> INCORRECT
> >>>>
> >>>>> (a valid halt decider always
> >>>>> returns a result to its caller) ergo H is not designed
> >>>>> correctly.
> >>>>
> >>>> CORRECT
> >>>>
> >>>>> Simple undeniable logic, dear.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> You just said that the non-halting input to a simulating halt
> >>>> decider must halt, that is a contradiction.
> >>>
> >>> No, dear, I am saying that your simulating halt decider is not a
> >>> valid halt decider as it doesn't return a result to its caller,
> >>
> >> In other words you believe that a function called in (what is
> >> essentially) infinite recursion must return to its caller even
> >> though it is an axiom to no function called in infinite recursion
> >> ever returns to its caller?
> >>
> >> When any system of axioms has a pair of axioms that contradict each
> >> other at most one of these axioms is correct.
> >>
> >> (a) Deciders must always return to their caller.
> >> (b) No function called in infinite recursion returns to its caller.
> >>
> >> When deciders are called in infinite recursion we have
> >> contradictory axioms.
> >>
> >> *HERE IS WHAT ACTUALLY HAPPENS*
> >> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> >> (b) that simulates P(P) that calls a simulated H(P,P)
> >> (c) that simulates P(P) that calls a simulated H(P,P)
> >> (d) that simulates P(P) that calls a simulated H(P,P)...
> >> *Until H aborts its simulation*
> >> (e) then H(P,P) returns to main()
> >>
> >> (a) P(P) invokes H(P,P)
> >> (b) H(P,P) simulates P(P) that calls a simulated H(P,P)
> >> (c) that simulates P(P) that calls a simulated H(P,P)
> >> (d) that simulates P(P) that calls a simulated H(P,P)
> >> (e) that simulates P(P) that calls a simulated H(P,P)...
> >> *Until H aborts its simulation*
> >> (f) then H(P,P) returns to P(P) in main()
> >>
> >> (a) Deciders must always return to their caller.
> >> becomes
> >> (a) Deciders that are not called in infinite recursion must always
> >> return to their caller.
> >
> > Simple enough to refute by counter-example, dear: the Flibble
> > Signaling Halt Decider (TM) is a simulating halt decider that does
> > return to its caller, dear.
>
> It is not doing what the semantics of its inputs specifies that it
> must do.
>
> void Px(void (*x)())
> {
> (void) HH(x, x);
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", HH(Px, Px));
> }
>
> The correct pure simulation of the input to HH by HH as if HH was
> only a simulator and not a simulating halt decider is this:
>
> (a) H(Px,Px) simulates Px(Px) that calls a simulated H(Px,Px)
> (b) that simulates Px(Px) that calls a simulated H(Px,Px)
> (c) that simulates Px(Px) that calls a simulated H(Px,Px)
> (d) that simulates Px(Px) that calls a simulated H(Px,Px)...
>
> _Px()
> [00001102](01) 55 push ebp
> [00001103](02) 8bec mov ebp,esp
> [00001105](03) 8b4508 mov eax,[ebp+08]
> [00001108](01) 50 push eax // Push Px
> [00001109](03) 8b4d08 mov ecx,[ebp+08]
> [0000110c](01) 51 push ecx // Push Px
> [0000110d](05) e890fbffff call 00000ca2 // call HH
> [00001112](03) 83c408 add esp,+08
> [00001115](01) 5d pop ebp
> [00001116](01) c3 ret
> Size in bytes:(0021) [00001116]
>
> It is not possible for HH to correctly return to a simulated Px.
> Every Px that HH(Px,Px) correctly simulates cannot possibly correctly
> reach past machine address [0000110d].

On 2022-08-27 19:26:36 +0000, olcott said:

> When any system of axioms has a pair of axioms that contradict each
> other at most one of these axioms is correct.
>
> (a) Deciders must always return to their caller.
> (b) No function called in infinite recursion returns to its caller.

Although not formally worng, it is not a good style to have axioms
that can be proven. Above (a) is a consequence of the definition
of "decider" and (b) is a consequence of the definition "infinite
recursion". As both are proven neither one is incorrect.

> When deciders are called in infinite recursion we have contradictory axioms.

No, the "axioms" are not contradictory, as both are proven. But a
provable consequence is that nothing in an infinite recursion is
a decider.

Mikko

On 8/28/22 5:31 AM, Mikko wrote:
> On 2022-08-27 19:26:36 +0000, olcott said:
>
>> When any system of axioms has a pair of axioms that contradict each
>> other at most one of these axioms is correct.
>>
>> (a) Deciders must always return to their caller.
>> (b) No function called in infinite recursion returns to its caller.
>
> Although not formally worng, it is not a good style to have axioms
> that can be proven. Above (a) is a consequence of the definition
> of "decider" and (b) is a consequence of the definition "infinite
> recursion". As both are proven neither one is incorrect.
>
>> When deciders are called in infinite recursion we have contradictory
>> axioms.
>
> No, the "axioms" are not contradictory, as both are proven. But a
> provable consequence is that nothing in an infinite recursion is
> a decider.
>
> Mikko
>

And the key point is that since H(P,P) returns 0 when called by main,
this call doesn't result in infinite recursion, and if H is a "Pure
Function" as it is claimed, NO call to H(P,P) results in infinite
recursion, so the call from P(P) to H(P,P) doesn't result in infinite
recursion.

It doesn't result in Infinite Recursion BECAUSE, H has the "smarts" to
recognize a POTENTIAL infinite recursion and aborts that. Since P calls
H, it gets credit for that smarts. Thus P(P) is not infinitely recursive
either BECAUSE it is smart enough (by using an H that is smart enough)
to break the recursion cycle.

The problem is H is smart enough to break the cycle but not smart enough
to realize that H breaks the cycle, so sees P as infinitely recursive
(when it has been shown not to be) and thus gives the wrong answer.

We shouldn't be too hard on H, because we know this is an impossible
task, as Halting isn't a computable function.

Olcott on the other hand doesn't get the same sympathy, as he should
know the task is impossible, but still attempts it, and then he turns a
blind eye to the actual facts that shows that H is wrong but tries to
justify it as being correct. This shows that he fails to meet the basic
tests of intelligence. Eitehr he is just a pathological liar, or he is
mentally deficient.

On Sun, 28 Aug 2022 07:13:30 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 8/28/22 5:31 AM, Mikko wrote:
> > On 2022-08-27 19:26:36 +0000, olcott said:
> >
> >> When any system of axioms has a pair of axioms that contradict
> >> each other at most one of these axioms is correct.
> >>
> >> (a) Deciders must always return to their caller.
> >> (b) No function called in infinite recursion returns to its
> >> caller.
> >
> > Although not formally worng, it is not a good style to have axioms
> > that can be proven. Above (a) is a consequence of the definition
> > of "decider" and (b) is a consequence of the definition "infinite
> > recursion". As both are proven neither one is incorrect.
> >
> >> When deciders are called in infinite recursion we have
> >> contradictory axioms.
> >
> > No, the "axioms" are not contradictory, as both are proven. But a
> > provable consequence is that nothing in an infinite recursion is
> > a decider.
> >
> > Mikko
> >
>
> And the key point is that since H(P,P) returns 0 when called by main,
> this call doesn't result in infinite recursion, and if H is a "Pure
> Function" as it is claimed, NO call to H(P,P) results in infinite
> recursion, so the call from P(P) to H(P,P) doesn't result in infinite
> recursion.
>
> It doesn't result in Infinite Recursion BECAUSE, H has the "smarts"
> to recognize a POTENTIAL infinite recursion and aborts that. Since P
> calls H, it gets credit for that smarts. Thus P(P) is not infinitely
> recursive either BECAUSE it is smart enough (by using an H that is
> smart enough) to break the recursion cycle.
>
> The problem is H is smart enough to break the cycle but not smart
> enough to realize that H breaks the cycle, so sees P as infinitely
> recursive (when it has been shown not to be) and thus gives the wrong
> answer.
>
> We shouldn't be too hard on H, because we know this is an impossible
> task, as Halting isn't a computable function.

It isn't an impossible task if we fork the simulation returning both 0
and 1 to P and continue simulating P in both forks until we arrive at a
non-contradictory halting decision.

/Flibble

On 8/28/22 7:34 AM, Mr Flibble wrote:
> On Sun, 28 Aug 2022 07:13:30 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 8/28/22 5:31 AM, Mikko wrote:
>>> On 2022-08-27 19:26:36 +0000, olcott said:
>>>
>>>> When any system of axioms has a pair of axioms that contradict
>>>> each other at most one of these axioms is correct.
>>>>
>>>> (a) Deciders must always return to their caller.
>>>> (b) No function called in infinite recursion returns to its
>>>> caller.
>>>
>>> Although not formally worng, it is not a good style to have axioms
>>> that can be proven. Above (a) is a consequence of the definition
>>> of "decider" and (b) is a consequence of the definition "infinite
>>> recursion". As both are proven neither one is incorrect.
>>>
>>>> When deciders are called in infinite recursion we have
>>>> contradictory axioms.
>>>
>>> No, the "axioms" are not contradictory, as both are proven. But a
>>> provable consequence is that nothing in an infinite recursion is
>>> a decider.
>>>
>>> Mikko
>>>
>>
>> And the key point is that since H(P,P) returns 0 when called by main,
>> this call doesn't result in infinite recursion, and if H is a "Pure
>> Function" as it is claimed, NO call to H(P,P) results in infinite
>> recursion, so the call from P(P) to H(P,P) doesn't result in infinite
>> recursion.
>>
>> It doesn't result in Infinite Recursion BECAUSE, H has the "smarts"
>> to recognize a POTENTIAL infinite recursion and aborts that. Since P
>> calls H, it gets credit for that smarts. Thus P(P) is not infinitely
>> recursive either BECAUSE it is smart enough (by using an H that is
>> smart enough) to break the recursion cycle.
>>
>> The problem is H is smart enough to break the cycle but not smart
>> enough to realize that H breaks the cycle, so sees P as infinitely
>> recursive (when it has been shown not to be) and thus gives the wrong
>> answer.
>>
>> We shouldn't be too hard on H, because we know this is an impossible
>> task, as Halting isn't a computable function.
>
> It isn't an impossible task if we fork the simulation returning both 0
> and 1 to P and continue simulating P in both forks until we arrive at a
> non-contradictory halting decision.
>
> /Flibble
>

That works for Px, but not for the original P, since there is no
non-contradictory halting decision that can be given.

Your decider will invent an 'non-answer' of exception.

This answer fails to meet the definition of a Halting Decider, and
depending on how you actually map "exception" into a Turing Machine,
means that there IS a correct answer for P(P), so "exception" isn't
*THE* correct answer, even if it is the best that H can give.

On Sun, 28 Aug 2022 07:51:47 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 8/28/22 7:34 AM, Mr Flibble wrote:
> > On Sun, 28 Aug 2022 07:13:30 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 8/28/22 5:31 AM, Mikko wrote:
> >>> On 2022-08-27 19:26:36 +0000, olcott said:
> >>>
> >>>> When any system of axioms has a pair of axioms that contradict
> >>>> each other at most one of these axioms is correct.
> >>>>
> >>>> (a) Deciders must always return to their caller.
> >>>> (b) No function called in infinite recursion returns to its
> >>>> caller.
> >>>
> >>> Although not formally worng, it is not a good style to have axioms
> >>> that can be proven. Above (a) is a consequence of the definition
> >>> of "decider" and (b) is a consequence of the definition "infinite
> >>> recursion". As both are proven neither one is incorrect.
> >>>
> >>>> When deciders are called in infinite recursion we have
> >>>> contradictory axioms.
> >>>
> >>> No, the "axioms" are not contradictory, as both are proven. But a
> >>> provable consequence is that nothing in an infinite recursion is
> >>> a decider.
> >>>
> >>> Mikko
> >>>
> >>
> >> And the key point is that since H(P,P) returns 0 when called by
> >> main, this call doesn't result in infinite recursion, and if H is
> >> a "Pure Function" as it is claimed, NO call to H(P,P) results in
> >> infinite recursion, so the call from P(P) to H(P,P) doesn't result
> >> in infinite recursion.
> >>
> >> It doesn't result in Infinite Recursion BECAUSE, H has the "smarts"
> >> to recognize a POTENTIAL infinite recursion and aborts that. Since
> >> P calls H, it gets credit for that smarts. Thus P(P) is not
> >> infinitely recursive either BECAUSE it is smart enough (by using
> >> an H that is smart enough) to break the recursion cycle.
> >>
> >> The problem is H is smart enough to break the cycle but not smart
> >> enough to realize that H breaks the cycle, so sees P as infinitely
> >> recursive (when it has been shown not to be) and thus gives the
> >> wrong answer.
> >>
> >> We shouldn't be too hard on H, because we know this is an
> >> impossible task, as Halting isn't a computable function.
> >
> > It isn't an impossible task if we fork the simulation returning
> > both 0 and 1 to P and continue simulating P in both forks until we
> > arrive at a non-contradictory halting decision.
> >
> > /Flibble
> >
>
> That works for Px, but not for the original P, since there is no
> non-contradictory halting decision that can be given.
>
> Your decider will invent an 'non-answer' of exception.
>
> This answer fails to meet the definition of a Halting Decider, and
> depending on how you actually map "exception" into a Turing Machine,
> means that there IS a correct answer for P(P), so "exception" isn't
> *THE* correct answer, even if it is the best that H can give.

Fails to meet YOUR definition of a Halting Decider, I have chosen to
EXTEND the definition of a Halting Decider which is a perfectly valid
approach as far as progressing research in the field is concerned: it
allows us to finally put to bed the "impossible program" bullshit and
instead focus on how we can best design a simulating halting decider for
different classes of non-pathological input. "Impossible program"
pathological input is a massive red herring.

/Flibble

On 8/28/22 7:58 AM, Mr Flibble wrote:
> On Sun, 28 Aug 2022 07:51:47 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 8/28/22 7:34 AM, Mr Flibble wrote:
>>> On Sun, 28 Aug 2022 07:13:30 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 8/28/22 5:31 AM, Mikko wrote:
>>>>> On 2022-08-27 19:26:36 +0000, olcott said:
>>>>>
>>>>>> When any system of axioms has a pair of axioms that contradict
>>>>>> each other at most one of these axioms is correct.
>>>>>>
>>>>>> (a) Deciders must always return to their caller.
>>>>>> (b) No function called in infinite recursion returns to its
>>>>>> caller.
>>>>>
>>>>> Although not formally worng, it is not a good style to have axioms
>>>>> that can be proven. Above (a) is a consequence of the definition
>>>>> of "decider" and (b) is a consequence of the definition "infinite
>>>>> recursion". As both are proven neither one is incorrect.
>>>>>
>>>>>> When deciders are called in infinite recursion we have
>>>>>> contradictory axioms.
>>>>>
>>>>> No, the "axioms" are not contradictory, as both are proven. But a
>>>>> provable consequence is that nothing in an infinite recursion is
>>>>> a decider.
>>>>>
>>>>> Mikko
>>>>>
>>>>
>>>> And the key point is that since H(P,P) returns 0 when called by
>>>> main, this call doesn't result in infinite recursion, and if H is
>>>> a "Pure Function" as it is claimed, NO call to H(P,P) results in
>>>> infinite recursion, so the call from P(P) to H(P,P) doesn't result
>>>> in infinite recursion.
>>>>
>>>> It doesn't result in Infinite Recursion BECAUSE, H has the "smarts"
>>>> to recognize a POTENTIAL infinite recursion and aborts that. Since
>>>> P calls H, it gets credit for that smarts. Thus P(P) is not
>>>> infinitely recursive either BECAUSE it is smart enough (by using
>>>> an H that is smart enough) to break the recursion cycle.
>>>>
>>>> The problem is H is smart enough to break the cycle but not smart
>>>> enough to realize that H breaks the cycle, so sees P as infinitely
>>>> recursive (when it has been shown not to be) and thus gives the
>>>> wrong answer.
>>>>
>>>> We shouldn't be too hard on H, because we know this is an
>>>> impossible task, as Halting isn't a computable function.
>>>
>>> It isn't an impossible task if we fork the simulation returning
>>> both 0 and 1 to P and continue simulating P in both forks until we
>>> arrive at a non-contradictory halting decision.
>>>
>>> /Flibble
>>>
>>
>> That works for Px, but not for the original P, since there is no
>> non-contradictory halting decision that can be given.
>>
>> Your decider will invent an 'non-answer' of exception.
>>
>> This answer fails to meet the definition of a Halting Decider, and
>> depending on how you actually map "exception" into a Turing Machine,
>> means that there IS a correct answer for P(P), so "exception" isn't
>> *THE* correct answer, even if it is the best that H can give.
>
> Fails to meet YOUR definition of a Halting Decider, I have chosen to
> EXTEND the definition of a Halting Decider which is a perfectly valid
> approach as far as progressing research in the field is concerned: it
> allows us to finally put to bed the "impossible program" bullshit and
> instead focus on how we can best design a simulating halting decider for
> different classes of non-pathological input. "Impossible program"
> pathological input is a massive red herring.
>
> /Flibble
>

Which means it doesn't met THE definition from the Classic Theory.

Yes, you can define an alternate problem, and show a solution to that
alternate problem, but it becomes a lie to imply that your solution
applies to the original classical problem.

This isn't "my" definition, it is the classical definition, which is
presumed by people when you just say "The Halting Problem".

You get you choice, chose to be considered a deceitful person by
implying something that isn't true, or be careful enough to make
yourself clear.

Just use better and clearer terminology, like "The extended Halting
Problem", and you won't get complaints of being deceitful.

This is part of the same problem that Olcott has, although in his case I
think he doesn't understand that he HAS tried to extend the definition
to something different, and thus gets stuck in lie loops.

On Sun, 28 Aug 2022 08:10:23 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 8/28/22 7:58 AM, Mr Flibble wrote:
> > On Sun, 28 Aug 2022 07:51:47 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 8/28/22 7:34 AM, Mr Flibble wrote:
> >>> On Sun, 28 Aug 2022 07:13:30 -0400
> >>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>
> >>>> On 8/28/22 5:31 AM, Mikko wrote:
> >>>>> On 2022-08-27 19:26:36 +0000, olcott said:
> >>>>>
> >>>>>> When any system of axioms has a pair of axioms that contradict
> >>>>>> each other at most one of these axioms is correct.
> >>>>>>
> >>>>>> (a) Deciders must always return to their caller.
> >>>>>> (b) No function called in infinite recursion returns to its
> >>>>>> caller.
> >>>>>
> >>>>> Although not formally worng, it is not a good style to have
> >>>>> axioms that can be proven. Above (a) is a consequence of the
> >>>>> definition of "decider" and (b) is a consequence of the
> >>>>> definition "infinite recursion". As both are proven neither one
> >>>>> is incorrect.
> >>>>>> When deciders are called in infinite recursion we have
> >>>>>> contradictory axioms.
> >>>>>
> >>>>> No, the "axioms" are not contradictory, as both are proven. But
> >>>>> a provable consequence is that nothing in an infinite recursion
> >>>>> is a decider.
> >>>>>
> >>>>> Mikko
> >>>>>
> >>>>
> >>>> And the key point is that since H(P,P) returns 0 when called by
> >>>> main, this call doesn't result in infinite recursion, and if H is
> >>>> a "Pure Function" as it is claimed, NO call to H(P,P) results in
> >>>> infinite recursion, so the call from P(P) to H(P,P) doesn't
> >>>> result in infinite recursion.
> >>>>
> >>>> It doesn't result in Infinite Recursion BECAUSE, H has the
> >>>> "smarts" to recognize a POTENTIAL infinite recursion and aborts
> >>>> that. Since P calls H, it gets credit for that smarts. Thus P(P)
> >>>> is not infinitely recursive either BECAUSE it is smart enough
> >>>> (by using an H that is smart enough) to break the recursion
> >>>> cycle.
> >>>>
> >>>> The problem is H is smart enough to break the cycle but not smart
> >>>> enough to realize that H breaks the cycle, so sees P as
> >>>> infinitely recursive (when it has been shown not to be) and thus
> >>>> gives the wrong answer.
> >>>>
> >>>> We shouldn't be too hard on H, because we know this is an
> >>>> impossible task, as Halting isn't a computable function.
> >>>
> >>> It isn't an impossible task if we fork the simulation returning
> >>> both 0 and 1 to P and continue simulating P in both forks until we
> >>> arrive at a non-contradictory halting decision.
> >>>
> >>> /Flibble
> >>>
> >>
> >> That works for Px, but not for the original P, since there is no
> >> non-contradictory halting decision that can be given.
> >>
> >> Your decider will invent an 'non-answer' of exception.
> >>
> >> This answer fails to meet the definition of a Halting Decider, and
> >> depending on how you actually map "exception" into a Turing
> >> Machine, means that there IS a correct answer for P(P), so
> >> "exception" isn't *THE* correct answer, even if it is the best
> >> that H can give.
> >
> > Fails to meet YOUR definition of a Halting Decider, I have chosen to
> > EXTEND the definition of a Halting Decider which is a perfectly
> > valid approach as far as progressing research in the field is
> > concerned: it allows us to finally put to bed the "impossible
> > program" bullshit and instead focus on how we can best design a
> > simulating halting decider for different classes of
> > non-pathological input. "Impossible program" pathological input is
> > a massive red herring.
> >
> > /Flibble
> >
>
> Which means it doesn't met THE definition from the Classic Theory.
>
> Yes, you can define an alternate problem, and show a solution to that
> alternate problem, but it becomes a lie to imply that your solution
> applies to the original classical problem.
>
> This isn't "my" definition, it is the classical definition, which is
> presumed by people when you just say "The Halting Problem".
>
> You get you choice, chose to be considered a deceitful person by
> implying something that isn't true, or be careful enough to make
> yourself clear.
>
> Just use better and clearer terminology, like "The extended Halting
> Problem", and you won't get complaints of being deceitful.
>
> This is part of the same problem that Olcott has, although in his
> case I think he doesn't understand that he HAS tried to extend the
> definition to something different, and thus gets stuck in lie loops.

What is "classic theory" supposed to be? The very idea that definitions
and theories cannot be refined is a nonsense: this certainly isn't how
science is supposed to work. Science deals with moving targets as
unlike with mathematical theories no scientific theory can be proven,
only falsified. So the question ultimately becomes is the Halting
Problem a mathematical problem or a computer science problem? If the
latter then my approach is perfectly valid: scientific theories EVOLVE.

/Flibble

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> On Sun, 28 Aug 2022 07:13:30 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:

>> We shouldn't be too hard on H, because we know this is an impossible
>> task, as Halting isn't a computable function.
>
> It isn't an impossible task if we fork the simulation returning both 0
> and 1 to P and continue simulating P in both forks until we arrive at a
> non-contradictory halting decision.

No. There is no algorithm that can return the correct halts/does not
halt result for all representable computations -- provided the
representation permits the "hat" construct (or something equivalent).
It's the universality of the model that rules out a halt decider.

--
Ben.

On Sun, 28 Aug 2022 13:39:33 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
> > On Sun, 28 Aug 2022 07:13:30 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
>
> >> We shouldn't be too hard on H, because we know this is an
> >> impossible task, as Halting isn't a computable function.
> >
> > It isn't an impossible task if we fork the simulation returning
> > both 0 and 1 to P and continue simulating P in both forks until we
> > arrive at a non-contradictory halting decision.
>
> No. There is no algorithm that can return the correct halts/does not
> halt result for all representable computations -- provided the
> representation permits the "hat" construct (or something equivalent).
> It's the universality of the model that rules out a halt decider.

Your erroneous assertion is a manifestation of your blinkered approach
to the field. The Flibble Signaling Halt Decider (TM) will
work for all inputs.

/Flibble

On 8/28/2022 4:31 AM, Mikko wrote:
> On 2022-08-27 19:26:36 +0000, olcott said:
>
>> When any system of axioms has a pair of axioms that contradict each
>> other at most one of these axioms is correct.
>>
>> (a) Deciders must always return to their caller.
>> (b) No function called in infinite recursion returns to its caller.
>
> Although not formally worng, it is not a good style to have axioms
> that can be proven. Above (a) is a consequence of the definition
> of "decider" and (b) is a consequence of the definition "infinite
> recursion". As both are proven neither one is incorrect.
>
>> When deciders are called in infinite recursion we have contradictory
>> axioms.
>
> No, the "axioms" are not contradictory, as both are proven. But a
> provable consequence is that nothing in an infinite recursion is
> a decider.
>
> Mikko
>

A decider called in infinite recursion can correctly determine that it
was called in infinite recursion and can return to some caller yet this
simply doesn't count because it is against the rules.

It does not matter that when the decider is called in infinite recursion
this recursive call was not even invoked it must still return to its
caller even if it was not invoked because that is what the rule says.

--
Copyright 2022 Pete Olcott

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

On 8/28/2022 7:39 AM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
>> On Sun, 28 Aug 2022 07:13:30 -0400
>> Richard Damon <Richard@Damon-Family.org> wrote:
>
>>> We shouldn't be too hard on H, because we know this is an impossible
>>> task, as Halting isn't a computable function.
>>
>> It isn't an impossible task if we fork the simulation returning both 0
>> and 1 to P and continue simulating P in both forks until we arrive at a
>> non-contradictory halting decision.
>
> No. There is no algorithm that can return the correct halts/does not
> halt result for all representable computations -- provided the
> representation permits the "hat" construct (or something equivalent).
> It's the universality of the model that rules out a halt decider.
>

(a) When a simulating halt decider (SHD) correctly predicts that its
simulated input would never stop running unless it aborts its simulation

(b) It is also predicting the behavior of the UTM simulation of this
same input because the simulation by a SHD that never aborts its
simulation is a UTM simulation of this input

(c) Thus is also predicting the actual behavior of this input because
UTM simulation of a machine description always provides the actual
behavior specified by this machine description.

(a)(b)(c) are merely different ways of saying the same thing.

--
Copyright 2022 Pete Olcott

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

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> On Sun, 28 Aug 2022 13:39:33 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>
>> > On Sun, 28 Aug 2022 07:13:30 -0400
>> > Richard Damon <Richard@Damon-Family.org> wrote:
>>
>> >> We shouldn't be too hard on H, because we know this is an
>> >> impossible task, as Halting isn't a computable function.
>> >
>> > It isn't an impossible task if we fork the simulation returning
>> > both 0 and 1 to P and continue simulating P in both forks until we
>> > arrive at a non-contradictory halting decision.
>>
>> No. There is no algorithm that can return the correct halts/does not
>> halt result for all representable computations -- provided the
>> representation permits the "hat" construct (or something equivalent).
>> It's the universality of the model that rules out a halt decider.
>
> Your erroneous assertion is a manifestation of your blinkered approach
> to the field. The Flibble Signaling Halt Decider (TM) will
> work for all inputs.

So you keep saying. But the theorems don't go away because someone says
otherwise. Everyone who accepts mathematical proofs appears blinkered
to those that deny theorems[1].

Anyway, what is your plan? Just to keep saying it in this insignificant
corner of the 'net for a few more years or even decades? Or do you
intend to let the world know? Of course, if you subscribe to the notion
of a conspiracy preventing truly original thinking from being published
then you might as well give up now.

[1] Truly original mathematical thinking is not "thinking outside the
box", but dreaming up new boxes and looking inside to see what the
new box constraints have brought about.
--
Ben.

On 2022-08-28 12:53:27 +0000, olcott said:

> On 8/28/2022 4:31 AM, Mikko wrote:
>> On 2022-08-27 19:26:36 +0000, olcott said:
>>
>>> When any system of axioms has a pair of axioms that contradict each
>>> other at most one of these axioms is correct.
>>>
>>> (a) Deciders must always return to their caller.
>>> (b) No function called in infinite recursion returns to its caller.
>>
>> Although not formally worng, it is not a good style to have axioms
>> that can be proven. Above (a) is a consequence of the definition
>> of "decider" and (b) is a consequence of the definition "infinite
>> recursion". As both are proven neither one is incorrect.
>>
>>> When deciders are called in infinite recursion we have contradictory axioms.
>>
>> No, the "axioms" are not contradictory, as both are proven. But a
>> provable consequence is that nothing in an infinite recursion is
>> a decider.
>>
>> Mikko
>>
>
> A decider called in infinite recursion can correctly determine that it
> was called in infinite recursion and can return to some caller yet this
> simply doesn't count because it is against the rules.

If a "decider" is called in infinite recursion it does not return
and therefore is not a decider. If it returns it is not in an
infinite recursion and therefore cannot correctly determine that
it is in an infinite recursion.

Mikko

On 8/28/2022 9:54 AM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
>> On Sun, 28 Aug 2022 13:39:33 +0100
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>>
>>>> On Sun, 28 Aug 2022 07:13:30 -0400
>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>>> We shouldn't be too hard on H, because we know this is an
>>>>> impossible task, as Halting isn't a computable function.
>>>>
>>>> It isn't an impossible task if we fork the simulation returning
>>>> both 0 and 1 to P and continue simulating P in both forks until we
>>>> arrive at a non-contradictory halting decision.
>>>
>>> No. There is no algorithm that can return the correct halts/does not
>>> halt result for all representable computations -- provided the
>>> representation permits the "hat" construct (or something equivalent).
>>> It's the universality of the model that rules out a halt decider.
>>
>> Your erroneous assertion is a manifestation of your blinkered approach
>> to the field. The Flibble Signaling Halt Decider (TM) will
>> work for all inputs.
>
> So you keep saying. But the theorems don't go away because someone says
> otherwise. Everyone who accepts mathematical proofs appears blinkered
> to those that deny theorems[1].
>
> Anyway, what is your plan? Just to keep saying it in this insignificant
> corner of the 'net for a few more years or even decades? Or do you
> intend to let the world know? Of course, if you subscribe to the notion
> of a conspiracy preventing truly original thinking from being published
> then you might as well give up now.
>
> [1] Truly original mathematical thinking is not "thinking outside the
> box", but dreaming up new boxes and looking inside to see what the
> new box constraints have brought about.

Truly original mathematical thinking realizes that when symbolic logic
and classical logic discarded the semantics of the categorical
proposition that the syllogism is based on then neither symbolic logic
nor classical logic can be relied upon to derive conclusions that are
true. https://en.wikipedia.org/wiki/Syllogism#Basic_structure

Correct reasoning applies only truth preserving operations to a set of
premises such that any conclusion derived can be relied upon to be a
necessary consequence of the truth of these premises.

When premises are false or contradictory it is impossible to propagate a
truth value of true (because they are untrue) to a true conclusion.

--
Copyright 2022 Pete Olcott

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

On 8/28/2022 10:07 AM, Mikko wrote:
> On 2022-08-28 12:53:27 +0000, olcott said:
>
>> On 8/28/2022 4:31 AM, Mikko wrote:
>>> On 2022-08-27 19:26:36 +0000, olcott said:
>>>
>>>> When any system of axioms has a pair of axioms that contradict each
>>>> other at most one of these axioms is correct.
>>>>
>>>> (a) Deciders must always return to their caller.
>>>> (b) No function called in infinite recursion returns to its caller.
>>>
>>> Although not formally worng, it is not a good style to have axioms
>>> that can be proven. Above (a) is a consequence of the definition
>>> of "decider" and (b) is a consequence of the definition "infinite
>>> recursion". As both are proven neither one is incorrect.
>>>
>>>> When deciders are called in infinite recursion we have contradictory
>>>> axioms.
>>>
>>> No, the "axioms" are not contradictory, as both are proven. But a
>>> provable consequence is that nothing in an infinite recursion is
>>> a decider.
>>>
>>> Mikko
>>>
>>
>> A decider called in infinite recursion can correctly determine that it
>> was called in infinite recursion and can return to some caller yet
>> this simply doesn't count because it is against the rules.
>
> If a "decider" is called in infinite recursion it does not return
> and therefore is not a decider.

That is not true in my case.

In my case the decider does return to main() yet does not return to P()
thus does not always return to every caller. The decider does not return
to P() because it is never invoked in P(), P() is aborted by H() before
H(P,P) is invoked in P().

Because all deciders must always return to every caller even if they are
never invoked by this caller, when my correct decider correctly decides
that it was called in infinite recursion this correct behavior simply
does not count.

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H(P, P));
}

> If it returns it is not in an
> infinite recursion and therefore cannot correctly determine that
> it is in an infinite recursion.
>
> Mikko
>

It is an easily verified fact that it does correctly decide that it was
called in infinite recursion. *Try it for yourself*

This is the complete system:
https://www.liarparadox.org/2022_08_16.zip

Microsoft Visual Studio Community 2017
https://visualstudio.microsoft.com/vs/older-downloads/

--
Copyright 2022 Pete Olcott

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

On 8/28/22 9:02 AM, olcott wrote:
> On 8/28/2022 7:39 AM, Ben Bacarisse wrote:
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>
>>> On Sun, 28 Aug 2022 07:13:30 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>
>>>> We shouldn't be too hard on H, because we know this is an impossible
>>>> task, as Halting isn't a computable function.
>>>
>>> It isn't an impossible task if we fork the simulation returning both 0
>>> and 1 to P and continue simulating P in both forks until we arrive at a
>>> non-contradictory halting decision.
>>
>> No.  There is no algorithm that can return the correct halts/does not
>> halt result for all representable computations -- provided the
>> representation permits the "hat" construct (or something equivalent).
>> It's the universality of the model that rules out a halt decider.
>>
>
> (a) When a simulating halt decider (SHD) correctly predicts that its
> simulated input would never stop running unless it aborts its simulation

Which isn't the definition of Halting.

>
> (b) It is also predicting the behavior of the UTM simulation of this
> same input because the simulation by a SHD that never aborts its
> simulation is a UTM simulation of this input

Which it doesn't actually do, as it is actually replacing ALL copies of
itself with a UTM, thus changing the ACTUAL BEHAVIOR of the ACTUAL INPUT.

>
> (c) Thus is also predicting the actual behavior of this input because
> UTM simulation of a machine description always provides the actual
> behavior specified by this machine description.
>
> (a)(b)(c) are merely different ways of saying the same thing.
>
>

Nope, failed logic, H isn't predicting the ACTUAL behavior of the input,
it is predicting the behavion of the input it H was a UTM, which it
isn't. Thus it is as right as predicting what would happen if a Fairy
Dust Powered Unicord cast a spell with its Majic wand on the machine.

On 8/28/22 11:38 AM, olcott wrote:
> On 8/28/2022 10:07 AM, Mikko wrote:
>> On 2022-08-28 12:53:27 +0000, olcott said:
>>
>>> On 8/28/2022 4:31 AM, Mikko wrote:
>>>> On 2022-08-27 19:26:36 +0000, olcott said:
>>>>
>>>>> When any system of axioms has a pair of axioms that contradict each
>>>>> other at most one of these axioms is correct.
>>>>>
>>>>> (a) Deciders must always return to their caller.
>>>>> (b) No function called in infinite recursion returns to its caller.
>>>>
>>>> Although not formally worng, it is not a good style to have axioms
>>>> that can be proven. Above (a) is a consequence of the definition
>>>> of "decider" and (b) is a consequence of the definition "infinite
>>>> recursion". As both are proven neither one is incorrect.
>>>>
>>>>> When deciders are called in infinite recursion we have
>>>>> contradictory axioms.
>>>>
>>>> No, the "axioms" are not contradictory, as both are proven. But a
>>>> provable consequence is that nothing in an infinite recursion is
>>>> a decider.
>>>>
>>>> Mikko
>>>>
>>>
>>> A decider called in infinite recursion can correctly determine that
>>> it was called in infinite recursion and can return to some caller yet
>>> this simply doesn't count because it is against the rules.
>>
>> If a "decider" is called in infinite recursion it does not return
>> and therefore is not a decider.
>
>
> That is not true in my case.
>
> In my case the decider does return to main() yet does not return to P()
> thus does not always return to every caller. The decider does not return
> to P() because it is never invoked in P(), P() is aborted by H() before
> H(P,P) is invoked in P().
>

Except it DOES return to P, if that P is called by Main and not
simulated by H.

H is just showing that it thinks it is not actually a Computation/Pure
Funcition,

Either it is right about that, and thus disqualifies itself, or it is
wrong and hasn't correctly simulated its input, making itself wrong.

> Because all deciders must always return to every caller even if they are
> never invoked by this caller, when my correct decider correctly decides
> that it was called in infinite recursion this correct behavior simply
> does not count.

What do you mean by return to a caller that never invoked it? That seems
to be nonsense.

The decider needs to return the answer to every "caller" of it. And the
same answer to everyone that asks the same question.

>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
>> If it returns it is not in an
>> infinite recursion and therefore cannot correctly determine that
>> it is in an infinite recursion.
>>
>> Mikko
>>
>
> It is an easily verified fact that it does correctly decide that it was
> called in infinite recursion. *Try it for yourself*

Nope, your program SAYS that, but if you add the statements
P(P);
Output("P(P) Halted");

after the call, then you will see that P(P) actually does NOT result in
"infinte recursion".

Note, you have actually published this results, so you know it to be true.

>
> This is the complete system:
> https://www.liarparadox.org/2022_08_16.zip
>
> Microsoft Visual Studio Community 2017
> https://visualstudio.microsoft.com/vs/older-downloads/
>
>