Halt deciders only compute the mapping from their inputs to an accept or
reject state on the basis of the actual behavior of this input.

The correct simulation of 1 to ∞ steps of a machine description provides
the actual behavior of of 1 to ∞ steps of the underlying machine.

int Hx(ptr x, ptr y);

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

A simulating halt decider (SHD) continues to simulate its input until
the behavior of this input matches a non-halting behavior pattern or the
simulated input halts on its own.

There are zero Px elements of infinite set of Hx/Px pairs such that the
correct simulation (of 1 to ∞ steps) or direct execution of Px by Hx
reaches the final state of Px and halts.

Some of the Hx elements correctly recognize a correct non-halting
behavior pattern proving that its Px never halts. These Hx elements
correctly abort their simulation and correctly return 0 for non-halting.

*This Hx/Px pair is named H/P and is fully operational*

Complete halt deciding system (Visual Studio Project)
(a) x86utm operating system
(b) complete x86 emulator adapted from libx86emu
(c) Several halt deciders and their inputs contained within Halt7.c
https://liarparadox.org/2022_09_07.zip

The recursive simulation non-halting behavior pattern is slightly
adapted from infinite recursion behavior pattern used to determine the
halt status of void Infinite_Recursion(u32 N).

Once the infinite recursion behavior pattern is understood to be correct
then the recursive simulation behavior pattern is also understood to be
correct. Both of these behavior patterns use the exact same non-halting
criteria.

*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
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 Tue, 27 Sep 2022 10:49:02 -0500
olcott <polcott2@gmail.com> wrote:

> Halt deciders only compute the mapping from their inputs to an accept
> or reject state on the basis of the actual behavior of this input.

And your decider doesn't do that so it isn't a halt decider, it is a
recursive simulation decider. Real halt deciders return a decision to
their caller in finite time.

/Flibble

On 9/27/2022 3:36 PM, Mr Flibble wrote:
> On Tue, 27 Sep 2022 10:49:02 -0500
> olcott <polcott2@gmail.com> wrote:
>
>> Halt deciders only compute the mapping from their inputs to an accept
>> or reject state on the basis of the actual behavior of this input.
>
> And your decider doesn't do that so it isn't a halt decider, it is a
> recursive simulation decider. Real halt deciders return a decision to
> their caller in finite time.
>
> /Flibble
>

My code speaks for itself, thus conclusively proves that you don't have
a clue.

Complete halt deciding system (Visual Studio Project)
(a) x86utm operating system
(b) complete x86 emulator adapted from libx86emu
(c) Several halt deciders and their inputs contained within Halt7.c
https://liarparadox.org/2022_09_07.zip

--
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 9/27/22 5:10 PM, olcott wrote:
> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>> On Tue, 27 Sep 2022 10:49:02 -0500
>> olcott <polcott2@gmail.com> wrote:
>>
>>> Halt deciders only compute the mapping from their inputs to an accept
>>> or reject state on the basis of the actual behavior of this input.

And for a Halt Decider, that needs to be the behavior of the program it
represents, or the behavior of an INDEPENDENT running of a UTM on that
input.

>>
>> And your decider doesn't do that so it isn't a halt decider, it is a
>> recursive simulation decider.  Real halt deciders return a decision to
>> their caller in finite time.
>>
>> /Flibble
>>
>
> My code speaks for itself, thus conclusively proves that you don't have
> a clue.
>
> Complete halt deciding system (Visual Studio Project)
> (a) x86utm operating system
> (b) complete x86 emulator adapted from libx86emu
> (c) Several halt deciders and their inputs contained within Halt7.c
> https://liarparadox.org/2022_09_07.zip
>
>

Yes, your code speaks for itself and shows that you don't understand
what you are saying.

Your code have PROVEN that P(P) Halts if H(P,P) returns 0, and thus H is
wrong.

You are just too stupid to understand it.

On Tue, 27 Sep 2022 16:10:01 -0500
olcott <none-ya@beez-waxes.com> wrote:

> On 9/27/2022 3:36 PM, Mr Flibble wrote:
> > On Tue, 27 Sep 2022 10:49:02 -0500
> > olcott <polcott2@gmail.com> wrote:
> >
> >> Halt deciders only compute the mapping from their inputs to an
> >> accept or reject state on the basis of the actual behavior of this
> >> input.
> >
> > And your decider doesn't do that so it isn't a halt decider, it is a
> > recursive simulation decider. Real halt deciders return a decision
> > to their caller in finite time.
> >
> > /Flibble
> >
>
> My code speaks for itself, thus conclusively proves that you don't
> have a clue.

Your code speaks for itself: it doesn't meet the functional
requirements of a halt decider. You don't have a clue.

/Flibble

On 9/28/2022 11:32 AM, Mr Flibble wrote:
> On Tue, 27 Sep 2022 16:10:01 -0500
> olcott <none-ya@beez-waxes.com> wrote:
>
>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>
>>>> Halt deciders only compute the mapping from their inputs to an
>>>> accept or reject state on the basis of the actual behavior of this
>>>> input.
>>>
>>> And your decider doesn't do that so it isn't a halt decider, it is a
>>> recursive simulation decider. Real halt deciders return a decision
>>> to their caller in finite time.
>>>
>>> /Flibble
>>>
>>
>> My code speaks for itself, thus conclusively proves that you don't
>> have a clue.
>
> Your code speaks for itself: it doesn't meet the functional
> requirements of a halt decider. You don't have a clue.
>
> /Flibble
>

You simply don't have the mental discipline to pay enough attention to
understand my rebuttals of your claims.

Halt deciders must compute the mapping from their inputs to a final
accept or reject state on the basis of the actual behavior specified by
these inputs. Every competent reviewer can see that H(P,P) does that.

Complete halt deciding system (Visual Studio Project)
(a) x86utm operating system
(b) complete x86 emulator adapted from libx86emu
(c) Several halt deciders and their inputs contained within Halt7.c
https://liarparadox.org/2022_09_07.zip

--
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 Wed, 28 Sep 2022 11:43:22 -0500
olcott <polcott2@gmail.com> wrote:

> On 9/28/2022 11:32 AM, Mr Flibble wrote:
> > On Tue, 27 Sep 2022 16:10:01 -0500
> > olcott <none-ya@beez-waxes.com> wrote:
> >
> >> On 9/27/2022 3:36 PM, Mr Flibble wrote:
> >>> On Tue, 27 Sep 2022 10:49:02 -0500
> >>> olcott <polcott2@gmail.com> wrote:
> >>>
> >>>> Halt deciders only compute the mapping from their inputs to an
> >>>> accept or reject state on the basis of the actual behavior of
> >>>> this input.
> >>>
> >>> And your decider doesn't do that so it isn't a halt decider, it
> >>> is a recursive simulation decider. Real halt deciders return a
> >>> decision to their caller in finite time.
> >>>
> >>> /Flibble
> >>>
> >>
> >> My code speaks for itself, thus conclusively proves that you don't
> >> have a clue.
> >
> > Your code speaks for itself: it doesn't meet the functional
> > requirements of a halt decider. You don't have a clue.
> >
> > /Flibble
> >
>
> You simply don't have the mental discipline to pay enough attention
> to understand my rebuttals of your claims.

All your rebuttals have been false.

/Flibble

On 9/28/2022 12:29 PM, Mr Flibble wrote:
> On Wed, 28 Sep 2022 11:43:22 -0500
> olcott <polcott2@gmail.com> wrote:
>
>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>> olcott <none-ya@beez-waxes.com> wrote:
>>>
>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>
>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>> accept or reject state on the basis of the actual behavior of
>>>>>> this input.
>>>>>
>>>>> And your decider doesn't do that so it isn't a halt decider, it
>>>>> is a recursive simulation decider. Real halt deciders return a
>>>>> decision to their caller in finite time.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> My code speaks for itself, thus conclusively proves that you don't
>>>> have a clue.
>>>
>>> Your code speaks for itself: it doesn't meet the functional
>>> requirements of a halt decider. You don't have a clue.
>>>
>>> /Flibble
>>>
>>
>> You simply don't have the mental discipline to pay enough attention
>> to understand my rebuttals of your claims.
>
> All your rebuttals have been false.
>
> /Flibble
>

You don't even understand that rebuttals are neither true nor false they
are only correct or incorrect.

--
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 Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
> On 9/28/2022 11:32 AM, Mr Flibble wrote:
> > On Tue, 27 Sep 2022 16:10:01 -0500
> > olcott <non...@beez-waxes.com> wrote:
> >
> >> On 9/27/2022 3:36 PM, Mr Flibble wrote:
> >>> On Tue, 27 Sep 2022 10:49:02 -0500
> >>> olcott <polc...@gmail.com> wrote:
> >>>
> >>>> Halt deciders only compute the mapping from their inputs to an
> >>>> accept or reject state on the basis of the actual behavior of this
> >>>> input.
> >>>
> >>> And your decider doesn't do that so it isn't a halt decider, it is a
> >>> recursive simulation decider. Real halt deciders return a decision
> >>> to their caller in finite time.
> >>>
> >>> /Flibble
> >>>
> >>
> >> My code speaks for itself, thus conclusively proves that you don't
> >> have a clue.
> >
> > Your code speaks for itself: it doesn't meet the functional
> > requirements of a halt decider. You don't have a clue.
> >
> > /Flibble
> >
> You simply don't have the mental discipline to pay enough attention to
> understand my rebuttals of your claims.
>
> Halt deciders must compute the mapping from their inputs to a final
> accept or reject state on the basis of the actual behavior specified by
> these inputs.

Yes. You keep trying to pull a sleight-of-hand by saying that what counts is not the actual behaviour but what a correct simulation would do. This is not actually correct because P cannot be simulated properly. You then say that your simulation is correct, despite it giving the wrong answers. You justify that by claiming that no-one has found a flaw in it, despite several people pointing out the flaws numerous times, which you wave away by claiming, with no proof, that they are all wrong.

> Every competent reviewer can see that H(P,P) does that.

On the contrary, every competent reviewer (and indeed anyone with even a minimal knowledge of C or C++) can see that if H(P, P) is zero, P will halt, and if H(P, P) is non-zero, P will not halt. Thus H always gets it wrong.

> Complete halt deciding system (Visual Studio Project)
> (a) x86utm operating system
> (b) complete x86 emulator adapted from libx86emu
> (c) Several halt deciders and their inputs contained within Halt7.c
> https://liarparadox.org/2022_09_07.zip

On 9/28/2022 3:05 PM, Paul N wrote:
> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>> olcott <non...@beez-waxes.com> wrote:
>>>
>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>> olcott <polc...@gmail.com> wrote:
>>>>>
>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>> input.
>>>>>
>>>>> And your decider doesn't do that so it isn't a halt decider, it is a
>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>> to their caller in finite time.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> My code speaks for itself, thus conclusively proves that you don't
>>>> have a clue.
>>>
>>> Your code speaks for itself: it doesn't meet the functional
>>> requirements of a halt decider. You don't have a clue.
>>>
>>> /Flibble
>>>
>> You simply don't have the mental discipline to pay enough attention to
>> understand my rebuttals of your claims.
>>
>> Halt deciders must compute the mapping from their inputs to a final
>> accept or reject state on the basis of the actual behavior specified by
>> these inputs.
>
> Yes. You keep trying to pull a sleight-of-hand by saying that what counts is not the actual behaviour but what a correct simulation would do. This is not actually correct because P cannot be simulated properly.

Technically competent people can easily verify that P is being simulated
properly, its simulator libx86emu has 26 years of development.

Complete halt deciding system (Visual Studio Project)
(a) x86utm operating system
(b) Complete x86 emulator adapted from libx86emu to compile under Windows
(c) Several halt deciders and their sample inputs contained within Halt7.c
https://liarparadox.org/2022_09_07.zip

--
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 Wed, 28 Sep 2022 12:47:18 -0500
olcott <polcott2@gmail.com> wrote:

> On 9/28/2022 12:29 PM, Mr Flibble wrote:
> > On Wed, 28 Sep 2022 11:43:22 -0500
> > olcott <polcott2@gmail.com> wrote:
> >
> >> On 9/28/2022 11:32 AM, Mr Flibble wrote:
> >>> On Tue, 27 Sep 2022 16:10:01 -0500
> >>> olcott <none-ya@beez-waxes.com> wrote:
> >>>
> >>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
> >>>>> On Tue, 27 Sep 2022 10:49:02 -0500
> >>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>
> >>>>>> Halt deciders only compute the mapping from their inputs to an
> >>>>>> accept or reject state on the basis of the actual behavior of
> >>>>>> this input.
> >>>>>
> >>>>> And your decider doesn't do that so it isn't a halt decider, it
> >>>>> is a recursive simulation decider. Real halt deciders return a
> >>>>> decision to their caller in finite time.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> My code speaks for itself, thus conclusively proves that you
> >>>> don't have a clue.
> >>>
> >>> Your code speaks for itself: it doesn't meet the functional
> >>> requirements of a halt decider. You don't have a clue.
> >>>
> >>> /Flibble
> >>>
> >>
> >> You simply don't have the mental discipline to pay enough attention
> >> to understand my rebuttals of your claims.
> >
> > All your rebuttals have been false.
> >
> > /Flibble
> >
>
> You don't even understand that rebuttals are neither true nor false
> they are only correct or incorrect.

A rebuttal that is false is a rebuttal that is incorrect you obtuse
fucktarded troll.

/Flibble

On 9/28/2022 4:11 PM, Mr Flibble wrote:
> On Wed, 28 Sep 2022 12:47:18 -0500
> olcott <polcott2@gmail.com> wrote:
>
>> On 9/28/2022 12:29 PM, Mr Flibble wrote:
>>> On Wed, 28 Sep 2022 11:43:22 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>
>>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>
>>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>
>>>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>>>> accept or reject state on the basis of the actual behavior of
>>>>>>>> this input.
>>>>>>>
>>>>>>> And your decider doesn't do that so it isn't a halt decider, it
>>>>>>> is a recursive simulation decider. Real halt deciders return a
>>>>>>> decision to their caller in finite time.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> My code speaks for itself, thus conclusively proves that you
>>>>>> don't have a clue.
>>>>>
>>>>> Your code speaks for itself: it doesn't meet the functional
>>>>> requirements of a halt decider. You don't have a clue.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> You simply don't have the mental discipline to pay enough attention
>>>> to understand my rebuttals of your claims.
>>>
>>> All your rebuttals have been false.
>>>
>>> /Flibble
>>>
>>
>> You don't even understand that rebuttals are neither true nor false
>> they are only correct or incorrect.
>
> A rebuttal that is false is a rebuttal that is incorrect you obtuse
> fucktarded troll.
>
> /Flibble

When I claim that "dogs bark" your rebuttal could be that "cats don't
bark" it is true yet incorrect. All of the "rebuttals" of my work take
this same form.

--
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 9/28/22 4:39 PM, olcott wrote:
> On 9/28/2022 3:05 PM, Paul N wrote:
>> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>>> olcott <non...@beez-waxes.com> wrote:
>>>>
>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>>> olcott <polc...@gmail.com> wrote:
>>>>>>
>>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>>> input.
>>>>>>
>>>>>> And your decider doesn't do that so it isn't a halt decider, it is a
>>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>>> to their caller in finite time.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> My code speaks for itself, thus conclusively proves that you don't
>>>>> have a clue.
>>>>
>>>> Your code speaks for itself: it doesn't meet the functional
>>>> requirements of a halt decider. You don't have a clue.
>>>>
>>>> /Flibble
>>>>
>>> You simply don't have the mental discipline to pay enough attention to
>>> understand my rebuttals of your claims.
>>>
>>> Halt deciders must compute the mapping from their inputs to a final
>>> accept or reject state on the basis of the actual behavior specified by
>>> these inputs.
>>
>> Yes. You keep trying to pull a sleight-of-hand by saying that what
>> counts is not the actual behaviour but what a correct simulation would
>> do. This is not actually correct because P cannot be simulated properly.
>
> Technically competent people can easily verify that P is being simulated
> properly, its simulator libx86emu has 26 years of development.
>

No, they can't. The CORRECT simulation of a system is only a COMPLETE
and correct simulation of the system

> Complete halt deciding system (Visual Studio Project)
> (a) x86utm operating system
> (b) Complete x86 emulator adapted from libx86emu to compile under Windows
> (c) Several halt deciders and their sample inputs contained within Halt7.c
> https://liarparadox.org/2022_09_07.zip
>
>

Yes, and that program can generate a COMPLETE simulation of P(P) (you
have posted it) and that shows that P(P) Halts.

So, you FAIL to show your claim and are proved to be a LIAR.

On Wednesday, September 28, 2022 at 9:39:19 PM UTC+1, olcott wrote:
> On 9/28/2022 3:05 PM, Paul N wrote:
> > On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
> >> On 9/28/2022 11:32 AM, Mr Flibble wrote:
> >>> On Tue, 27 Sep 2022 16:10:01 -0500
> >>> olcott <non...@beez-waxes.com> wrote:
> >>>
> >>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
> >>>>> On Tue, 27 Sep 2022 10:49:02 -0500
> >>>>> olcott <polc...@gmail.com> wrote:
> >>>>>
> >>>>>> Halt deciders only compute the mapping from their inputs to an
> >>>>>> accept or reject state on the basis of the actual behavior of this
> >>>>>> input.
> >>>>>
> >>>>> And your decider doesn't do that so it isn't a halt decider, it is a
> >>>>> recursive simulation decider. Real halt deciders return a decision
> >>>>> to their caller in finite time.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> My code speaks for itself, thus conclusively proves that you don't
> >>>> have a clue.
> >>>
> >>> Your code speaks for itself: it doesn't meet the functional
> >>> requirements of a halt decider. You don't have a clue.
> >>>
> >>> /Flibble
> >>>
> >> You simply don't have the mental discipline to pay enough attention to
> >> understand my rebuttals of your claims.
> >>
> >> Halt deciders must compute the mapping from their inputs to a final
> >> accept or reject state on the basis of the actual behavior specified by
> >> these inputs.
> >
> > Yes. You keep trying to pull a sleight-of-hand by saying that what counts is not the actual behaviour but what a correct simulation would do. This is not actually correct because P cannot be simulated properly.
> Technically competent people can easily verify that P is being simulated
> properly, its simulator libx86emu has 26 years of development.

I must remember that for the next time someone tries to assure me of the reliability of something by telling me how long it been in development.

I note you've snipped my simple, one-sentence proof that the simulation is incorrect. That doesn't count as a rebuttal.

> Complete halt deciding system (Visual Studio Project)
> (a) x86utm operating system
> (b) Complete x86 emulator adapted from libx86emu to compile under Windows
> (c) Several halt deciders and their sample inputs contained within Halt7.c
> https://liarparadox.org/2022_09_07.zip

On 9/28/2022 3:05 PM, Paul N wrote:
> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>> olcott <non...@beez-waxes.com> wrote:
>>>
>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>> olcott <polc...@gmail.com> wrote:
>>>>>
>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>> input.
>>>>>
>>>>> And your decider doesn't do that so it isn't a halt decider, it is a
>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>> to their caller in finite time.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> My code speaks for itself, thus conclusively proves that you don't
>>>> have a clue.
>>>
>>> Your code speaks for itself: it doesn't meet the functional
>>> requirements of a halt decider. You don't have a clue.
>>>
>>> /Flibble
>>>
>> You simply don't have the mental discipline to pay enough attention to
>> understand my rebuttals of your claims.
>>
>> Halt deciders must compute the mapping from their inputs to a final
>> accept or reject state on the basis of the actual behavior specified by
>> these inputs.
>
> Yes. You keep trying to pull a sleight-of-hand by saying that what counts is not the actual behaviour but what a correct simulation would do. This is not actually correct because P cannot be simulated properly. You then say that your simulation is correct, despite it giving the wrong answers. You justify that by claiming that no-one has found a flaw in it, despite several people pointing out the flaws numerous times, which you wave away by claiming, with no proof, that they are all wrong.
>

I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
It is easily verified that the simulation is correct in that the
simulated x86 instructions exactly match what their x86 source-code
specifies.

Furthermore:

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

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

There are zero elements of infinite set of Hx/Px pairs such that the
correct *partial or complete* simulation of Px by Hx reaches the final
state of Px and halts. This is also the case when Hx directly executes Px.

My reviewers simply are not bright enough to see this thus mistakenly
believe that I am wrong.

Complete halt deciding system (Visual Studio Project)
(a) x86utm operating system
(b) complete x86 emulator adapted from libx86emu
(c) Several halt deciders and their inputs contained within Halt7.c
https://liarparadox.org/2022_09_07.zip

--
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 Thursday, September 29, 2022 at 2:49:07 PM UTC+1, olcott wrote:
> On 9/28/2022 3:05 PM, Paul N wrote:
> > On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
> >> On 9/28/2022 11:32 AM, Mr Flibble wrote:
> >>> On Tue, 27 Sep 2022 16:10:01 -0500
> >>> olcott <non...@beez-waxes.com> wrote:
> >>>
> >>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
> >>>>> On Tue, 27 Sep 2022 10:49:02 -0500
> >>>>> olcott <polc...@gmail.com> wrote:
> >>>>>
> >>>>>> Halt deciders only compute the mapping from their inputs to an
> >>>>>> accept or reject state on the basis of the actual behavior of this
> >>>>>> input.
> >>>>>
> >>>>> And your decider doesn't do that so it isn't a halt decider, it is a
> >>>>> recursive simulation decider. Real halt deciders return a decision
> >>>>> to their caller in finite time.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> My code speaks for itself, thus conclusively proves that you don't
> >>>> have a clue.
> >>>
> >>> Your code speaks for itself: it doesn't meet the functional
> >>> requirements of a halt decider. You don't have a clue.
> >>>
> >>> /Flibble
> >>>
> >> You simply don't have the mental discipline to pay enough attention to
> >> understand my rebuttals of your claims.
> >>
> >> Halt deciders must compute the mapping from their inputs to a final
> >> accept or reject state on the basis of the actual behavior specified by
> >> these inputs.
> >
> > Yes. You keep trying to pull a sleight-of-hand by saying that what counts is not the actual behaviour but what a correct simulation would do. This is not actually correct because P cannot be simulated properly. You then say that your simulation is correct, despite it giving the wrong answers. You justify that by claiming that no-one has found a flaw in it, despite several people pointing out the flaws numerous times, which you wave away by claiming, with no proof, that they are all wrong.
> >
> I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
> It is easily verified that the simulation is correct in that the
> simulated x86 instructions exactly match what their x86 source-code
> specifies.

On the contrary, you've told us numerous times that Px halts but Hx "correctly" predicts that it doesn't. That is *not* a correct simulation. You are assuming that Hx is correct in assuming that it has got stuck in a loop, when you know full well that Hx has the machinery to get out of the loop, because you wrote it yourself.

> Furthermore:
>
> void Px(ptr x)
> {
> int Halt_Status = Hx(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", Hx(Px, Px));
> }

Yes, it is clear that Px will do the opposite of what Hx "predicts" it will do.

> There are zero elements of infinite set of Hx/Px pairs such that the
> correct *partial or complete* simulation of Px by Hx reaches the final
> state of Px and halts. This is also the case when Hx directly executes Px..

Why do you keep saying this? There are no pairs where Hx correctly simulates Px. It makes no sense to say that zero of these pairs has some extra property. You seem to be implying that if zero of them halt, then at least one of them doesn't, which is not the case.

> My reviewers simply are not bright enough to see this thus mistakenly
> believe that I am wrong.

As far as I can tell, all of your reviewers are bright enough to see that you are wrong. Certainly Richard and Flibble have shown this on numerous occasions.

> Complete halt deciding system (Visual Studio Project)
> (a) x86utm operating system
> (b) complete x86 emulator adapted from libx86emu
> (c) Several halt deciders and their inputs contained within Halt7.c
> https://liarparadox.org/2022_09_07.zip

On 9/29/2022 9:45 AM, Paul N wrote:
> On Thursday, September 29, 2022 at 2:49:07 PM UTC+1, olcott wrote:
>> On 9/28/2022 3:05 PM, Paul N wrote:
>>> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>>>> olcott <non...@beez-waxes.com> wrote:
>>>>>
>>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>>>> olcott <polc...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>>>> input.
>>>>>>>
>>>>>>> And your decider doesn't do that so it isn't a halt decider, it is a
>>>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>>>> to their caller in finite time.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> My code speaks for itself, thus conclusively proves that you don't
>>>>>> have a clue.
>>>>>
>>>>> Your code speaks for itself: it doesn't meet the functional
>>>>> requirements of a halt decider. You don't have a clue.
>>>>>
>>>>> /Flibble
>>>>>
>>>> You simply don't have the mental discipline to pay enough attention to
>>>> understand my rebuttals of your claims.
>>>>
>>>> Halt deciders must compute the mapping from their inputs to a final
>>>> accept or reject state on the basis of the actual behavior specified by
>>>> these inputs.
>>>
>>> Yes. You keep trying to pull a sleight-of-hand by saying that what counts is not the actual behaviour but what a correct simulation would do. This is not actually correct because P cannot be simulated properly. You then say that your simulation is correct, despite it giving the wrong answers. You justify that by claiming that no-one has found a flaw in it, despite several people pointing out the flaws numerous times, which you wave away by claiming, with no proof, that they are all wrong.
>>>
>> I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
>> It is easily verified that the simulation is correct in that the
>> simulated x86 instructions exactly match what their x86 source-code
>> specifies.
>
> On the contrary, you've told us numerous times that Px halts but Hx "correctly" predicts that it doesn't.

Sure and if I am "told" that squares are round I will take it the same
way. The things that clueless wonders tell me carry no weight.

> That is *not* a correct simulation. You are assuming that Hx is correct in assuming that it has got stuck in a loop, when you know full well that Hx has the machinery to get out of the loop, because you wrote it yourself.
>

H and P are C functions that I wrote. Hx/Px is an infinite set of
different definitions of Hx for the following Px.

>> Furthermore:
>>
>> void Px(ptr x)
>> {
>> int Halt_Status = Hx(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", Hx(Px, Px));
>> }
>
> Yes, it is clear that Px will do the opposite of what Hx "predicts" it will do.
>
>> There are zero elements of infinite set of Hx/Px pairs such that the
>> correct *partial or complete* simulation of Px by Hx reaches the final
>> state of Px and halts. This is also the case when Hx directly executes Px.
>
> Why do you keep saying this? There are no pairs where Hx correctly simulates Px.

No sense talking to you anymore because you lack the technical
competence to see that H does correctly emulate P using an x86
emulator. You don't even know C well enough to see that when Hx
correctly simulates 1 to ∞ steps of Px that Px never reaches its
own final state.

// H(Px,Px) directly executes Px that never halts.
//
int Hx(ptr x, ptr y)
{ x(y);
}

Since halt deciders only compute the mapping from their inputs
to an accept or reject state based on the actual behavior
specified by these inputs THE BEHAVIOR OF NON INPUTS IS IRRELEVANT
EVEN IF YOUR GROUP-THINK BUDDIES THINK THAT IT IS.

Groupthink is a phenomenon that occurs when a group of well-intentioned
people makes irrational or non-optimal decisions spurred by the urge to
conform or the belief that dissent is impossible. The problematic or
premature consensus that is characteristic of groupthink may be fueled
by a particular agenda—or it may be due to group members valuing harmony
and coherence above critical thought.
https://www.psychologytoday.com/us/basics/groupthink

--
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 9/29/2022 10:04 AM, olcott wrote:
> On 9/29/2022 9:45 AM, Paul N wrote:
>> On Thursday, September 29, 2022 at 2:49:07 PM UTC+1, olcott wrote:
>>> On 9/28/2022 3:05 PM, Paul N wrote:
>>>> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>>>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>>>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>>>>> olcott <non...@beez-waxes.com> wrote:
>>>>>>
>>>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>>>>> olcott <polc...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>>>>> input.
>>>>>>>>
>>>>>>>> And your decider doesn't do that so it isn't a halt decider, it
>>>>>>>> is a
>>>>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>>>>> to their caller in finite time.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> My code speaks for itself, thus conclusively proves that you don't
>>>>>>> have a clue.
>>>>>>
>>>>>> Your code speaks for itself: it doesn't meet the functional
>>>>>> requirements of a halt decider. You don't have a clue.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>> You simply don't have the mental discipline to pay enough attention to
>>>>> understand my rebuttals of your claims.
>>>>>
>>>>> Halt deciders must compute the mapping from their inputs to a final
>>>>> accept or reject state on the basis of the actual behavior
>>>>> specified by
>>>>> these inputs.
>>>>
>>>> Yes. You keep trying to pull a sleight-of-hand by saying that what
>>>> counts is not the actual behaviour but what a correct simulation
>>>> would do. This is not actually correct because P cannot be simulated
>>>> properly. You then say that your simulation is correct, despite it
>>>> giving the wrong answers. You justify that by claiming that no-one
>>>> has found a flaw in it, despite several people pointing out the
>>>> flaws numerous times, which you wave away by claiming, with no
>>>> proof, that they are all wrong.
>>>>
>>> I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
>>> It is easily verified that the simulation is correct in that the
>>> simulated x86 instructions exactly match what their x86 source-code
>>> specifies.
>>
>> On the contrary, you've told us numerous times that Px halts but Hx
>> "correctly" predicts that it doesn't.
>
> Sure and if I am "told" that squares are round I will take it the same
> way. The things that clueless wonders tell me carry no weight.
>
>
>>  That is *not* a correct simulation. You are assuming that Hx is
>> correct in assuming that it has got stuck in a loop, when you know
>> full well that Hx has the machinery to get out of the loop, because
>> you wrote it yourself.
>>
>
> H and P are C functions that I wrote. Hx/Px is an infinite set of
> different definitions of Hx for the following Px.
>
>>> Furthermore:
>>>
>>> void Px(ptr x)
>>> {
>>>   int Halt_Status = Hx(x, x);
>>>   if (Halt_Status)
>>>     HERE: goto HERE;
>>>   return;
>>> }
>>>
>>> int main()
>>> {
>>>   Output("Input_Halts = ", Hx(Px, Px));
>>> }
>>
>> Yes, it is clear that Px will do the opposite of what Hx "predicts" it
>> will do.
>>
>>> There are zero elements of infinite set of Hx/Px pairs such that the
>>> correct *partial or complete* simulation of Px by Hx reaches the final
>>> state of Px and halts. This is also the case when Hx directly
>>> executes Px.
>>
>> Why do you keep saying this? There are no pairs where Hx correctly
>> simulates Px.
>
> No sense talking to you anymore because you lack the technical
> competence to see that H does correctly emulate P using an x86
> emulator. You don't even know C well enough to see that when Hx
> correctly simulates 1 to ∞ steps of Px that Px never reaches its
> own final state.
>

// Hx(Px,Px) directly executes Px that never halts.
//
int Hx(ptr x, ptr y)
{ x(y);
}

>
> Since halt deciders only compute the mapping from their inputs
> to an accept or reject state based on the actual behavior
> specified by these inputs THE BEHAVIOR OF NON INPUTS IS IRRELEVANT
> EVEN IF YOUR GROUP-THINK BUDDIES THINK THAT IT IS.
>
> Groupthink is a phenomenon that occurs when a group of well-intentioned
> people makes irrational or non-optimal decisions spurred by the urge to
> conform or the belief that dissent is impossible. The problematic or
> premature consensus that is characteristic of groupthink may be fueled
> by a particular agenda—or it may be due to group members valuing harmony
> and coherence above critical thought.
> https://www.psychologytoday.com/us/basics/groupthink
>
>
>

--
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 Thursday, September 29, 2022 at 4:04:26 PM UTC+1, olcott wrote:
> On 9/29/2022 9:45 AM, Paul N wrote:
> > On Thursday, September 29, 2022 at 2:49:07 PM UTC+1, olcott wrote:
> >> On 9/28/2022 3:05 PM, Paul N wrote:
> >>> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
> >>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
> >>>>> On Tue, 27 Sep 2022 16:10:01 -0500
> >>>>> olcott <non...@beez-waxes.com> wrote:
> >>>>>
> >>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
> >>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
> >>>>>>> olcott <polc...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> Halt deciders only compute the mapping from their inputs to an
> >>>>>>>> accept or reject state on the basis of the actual behavior of this
> >>>>>>>> input.
> >>>>>>>
> >>>>>>> And your decider doesn't do that so it isn't a halt decider, it is a
> >>>>>>> recursive simulation decider. Real halt deciders return a decision
> >>>>>>> to their caller in finite time.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> My code speaks for itself, thus conclusively proves that you don't
> >>>>>> have a clue.
> >>>>>
> >>>>> Your code speaks for itself: it doesn't meet the functional
> >>>>> requirements of a halt decider. You don't have a clue.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>> You simply don't have the mental discipline to pay enough attention to
> >>>> understand my rebuttals of your claims.
> >>>>
> >>>> Halt deciders must compute the mapping from their inputs to a final
> >>>> accept or reject state on the basis of the actual behavior specified by
> >>>> these inputs.
> >>>
> >>> Yes. You keep trying to pull a sleight-of-hand by saying that what counts is not the actual behaviour but what a correct simulation would do. This is not actually correct because P cannot be simulated properly. You then say that your simulation is correct, despite it giving the wrong answers. You justify that by claiming that no-one has found a flaw in it, despite several people pointing out the flaws numerous times, which you wave away by claiming, with no proof, that they are all wrong.
> >>>
> >> I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
> >> It is easily verified that the simulation is correct in that the
> >> simulated x86 instructions exactly match what their x86 source-code
> >> specifies.
> >
> > On the contrary, you've told us numerous times that Px halts but Hx "correctly" predicts that it doesn't.
> Sure and if I am "told" that squares are round I will take it the same
> way. The things that clueless wonders tell me carry no weight.

So, all the statements you made before about how Px halts but Hx "correctly" predicts that it doesn't were made by a "clueless wonder" and are statements that carry no weight?

> > That is *not* a correct simulation. You are assuming that Hx is correct in assuming that it has got stuck in a loop, when you know full well that Hx has the machinery to get out of the loop, because you wrote it yourself.
> >
> H and P are C functions that I wrote. Hx/Px is an infinite set of
> different definitions of Hx for the following Px.
> >> Furthermore:
> >>
> >> void Px(ptr x)
> >> {
> >> int Halt_Status = Hx(x, x);
> >> if (Halt_Status)
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", Hx(Px, Px));
> >> }
> >
> > Yes, it is clear that Px will do the opposite of what Hx "predicts" it will do.
> >
> >> There are zero elements of infinite set of Hx/Px pairs such that the
> >> correct *partial or complete* simulation of Px by Hx reaches the final
> >> state of Px and halts. This is also the case when Hx directly executes Px.
> >
> > Why do you keep saying this? There are no pairs where Hx correctly simulates Px.
> No sense talking to you anymore because you lack the technical
> competence to see that H does correctly emulate P using an x86
> emulator. You don't even know C well enough to see that when Hx
> correctly simulates 1 to ∞ steps of Px that Px never reaches its
> own final state.
>
> // H(Px,Px) directly executes Px that never halts.
> //
> int Hx(ptr x, ptr y)
> {
> x(y);
> }
>
> Since halt deciders only compute the mapping from their inputs
> to an accept or reject state based on the actual behavior
> specified by these inputs THE BEHAVIOR OF NON INPUTS IS IRRELEVANT
> EVEN IF YOUR GROUP-THINK BUDDIES THINK THAT IT IS.

If Hx is a halt decider then Hx(X, Y) tells us whether the program X, with input Y, halts. Ie whether X(Y) halts. So Hx(Px,Px) tells us whether PX(Px) halts. You saying that this is a "non-input" is just a total falsehood.

> Groupthink is a phenomenon that occurs when a group of well-intentioned
> people makes irrational or non-optimal decisions spurred by the urge to
> conform or the belief that dissent is impossible. The problematic or
> premature consensus that is characteristic of groupthink may be fueled
> by a particular agenda—or it may be due to group members valuing harmony
> and coherence above critical thought.
> https://www.psychologytoday.com/us/basics/groupthink

Just because everyone can see your errors doesn't make them guilty of group-think.

On 9/29/2022 12:02 PM, Paul N wrote:
> On Thursday, September 29, 2022 at 4:04:26 PM UTC+1, olcott wrote:
>> On 9/29/2022 9:45 AM, Paul N wrote:
>>> On Thursday, September 29, 2022 at 2:49:07 PM UTC+1, olcott wrote:
>>>> On 9/28/2022 3:05 PM, Paul N wrote:
>>>>> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>>>>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>>>>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>>>>>> olcott <non...@beez-waxes.com> wrote:
>>>>>>>
>>>>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>>>>>> olcott <polc...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>>>>>> input.
>>>>>>>>>
>>>>>>>>> And your decider doesn't do that so it isn't a halt decider, it is a
>>>>>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>>>>>> to their caller in finite time.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> My code speaks for itself, thus conclusively proves that you don't
>>>>>>>> have a clue.
>>>>>>>
>>>>>>> Your code speaks for itself: it doesn't meet the functional
>>>>>>> requirements of a halt decider. You don't have a clue.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>> You simply don't have the mental discipline to pay enough attention to
>>>>>> understand my rebuttals of your claims.
>>>>>>
>>>>>> Halt deciders must compute the mapping from their inputs to a final
>>>>>> accept or reject state on the basis of the actual behavior specified by
>>>>>> these inputs.
>>>>>
>>>>> Yes. You keep trying to pull a sleight-of-hand by saying that what counts is not the actual behaviour but what a correct simulation would do. This is not actually correct because P cannot be simulated properly. You then say that your simulation is correct, despite it giving the wrong answers. You justify that by claiming that no-one has found a flaw in it, despite several people pointing out the flaws numerous times, which you wave away by claiming, with no proof, that they are all wrong.
>>>>>
>>>> I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
>>>> It is easily verified that the simulation is correct in that the
>>>> simulated x86 instructions exactly match what their x86 source-code
>>>> specifies.
>>>
>>> On the contrary, you've told us numerous times that Px halts but Hx "correctly" predicts that it doesn't.
>> Sure and if I am "told" that squares are round I will take it the same
>> way. The things that clueless wonders tell me carry no weight.
>
> So, all the statements you made before about how Px halts but Hx "correctly" predicts that it doesn't were made by a "clueless wonder" and are statements that carry no weight?
>

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

// Hx(Px,Px) directly executes Px(Px)
int Px(ptr x, ptr y)
{ x(y);
}

Of the infinite set of Hx/Px pairs where Hx correctly simulates 1 to ∞
steps of Px or Hx directly executes Px, Px never reaches its final state
and halts.

Because halt deciders only compute the mapping from their inputs to an
accept or reject state based on the actual behavior of its inputs THE
BEHAVIOR OF NON-INPUTS IS TOTALLY IRRELEVANT.

I will stop here because my reviewers are so overzealous in finding a
mistake that they cannot pay close enough attention to more than one
point at a time.

--
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 Wed, 28 Sep 2022 17:09:09 -0500
olcott <polcott2@gmail.com> wrote:

> On 9/28/2022 4:11 PM, Mr Flibble wrote:
> > On Wed, 28 Sep 2022 12:47:18 -0500
> > olcott <polcott2@gmail.com> wrote:
> >
> >> On 9/28/2022 12:29 PM, Mr Flibble wrote:
> >>> On Wed, 28 Sep 2022 11:43:22 -0500
> >>> olcott <polcott2@gmail.com> wrote:
> >>>
> >>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
> >>>>> On Tue, 27 Sep 2022 16:10:01 -0500
> >>>>> olcott <none-ya@beez-waxes.com> wrote:
> >>>>>
> >>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
> >>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
> >>>>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> Halt deciders only compute the mapping from their inputs to
> >>>>>>>> an accept or reject state on the basis of the actual
> >>>>>>>> behavior of this input.
> >>>>>>>
> >>>>>>> And your decider doesn't do that so it isn't a halt decider,
> >>>>>>> it is a recursive simulation decider. Real halt deciders
> >>>>>>> return a decision to their caller in finite time.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> My code speaks for itself, thus conclusively proves that you
> >>>>>> don't have a clue.
> >>>>>
> >>>>> Your code speaks for itself: it doesn't meet the functional
> >>>>> requirements of a halt decider. You don't have a clue.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> You simply don't have the mental discipline to pay enough
> >>>> attention to understand my rebuttals of your claims.
> >>>
> >>> All your rebuttals have been false.
> >>>
> >>> /Flibble
> >>>
> >>
> >> You don't even understand that rebuttals are neither true nor false
> >> they are only correct or incorrect.
> >
> > A rebuttal that is false is a rebuttal that is incorrect you obtuse
> > fucktarded troll.
> >
> > /Flibble
>
> When I claim that "dogs bark" your rebuttal could be that "cats don't
> bark" it is true yet incorrect. All of the "rebuttals" of my work
> take this same form.

This is the same reason you fail at the halting problem: your
inability to differentiate between different categories:

"cats don't bark" is a true STATEMENT but a false REBUTTAL to "dogs
bark".

I put the different categories in CAPITAL LETTERS to help you
understand but you seem incapable of understanding anything anyone
tells you and you classify your lack on understanding into an automatic
assumption that what you are trying to understand is wrong.

/Flibble

On 9/29/22 9:49 AM, olcott wrote:
> On 9/28/2022 3:05 PM, Paul N wrote:
>> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>>> olcott <non...@beez-waxes.com> wrote:
>>>>
>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>>> olcott <polc...@gmail.com> wrote:
>>>>>>
>>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>>> input.
>>>>>>
>>>>>> And your decider doesn't do that so it isn't a halt decider, it is a
>>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>>> to their caller in finite time.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> My code speaks for itself, thus conclusively proves that you don't
>>>>> have a clue.
>>>>
>>>> Your code speaks for itself: it doesn't meet the functional
>>>> requirements of a halt decider. You don't have a clue.
>>>>
>>>> /Flibble
>>>>
>>> You simply don't have the mental discipline to pay enough attention to
>>> understand my rebuttals of your claims.
>>>
>>> Halt deciders must compute the mapping from their inputs to a final
>>> accept or reject state on the basis of the actual behavior specified by
>>> these inputs.
>>
>> Yes. You keep trying to pull a sleight-of-hand by saying that what
>> counts is not the actual behaviour but what a correct simulation would
>> do. This is not actually correct because P cannot be simulated
>> properly. You then say that your simulation is correct, despite it
>> giving the wrong answers. You justify that by claiming that no-one has
>> found a flaw in it, despite several people pointing out the flaws
>> numerous times, which you wave away by claiming, with no proof, that
>> they are all wrong.
>>
>
> I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
> It is easily verified that the simulation is correct in that the
> simulated x86 instructions exactly match what their x86 source-code
> specifies.

Except it is only a PARTIAL simulation, so it ony PARTIALLY determines
the behavior of the input.

It shows that P(P) doesn't halt bfore it calls H(P,P) and that is all it
shows.

The fact you claim that this shows P(P) to be non-halting shows that you
are a COMPLETE idiot, as you can't deduce the complete behavior from the
partial simulation, since as you have pointed out, the behavior of the
machine at the input is dependedent on what H(P,P) does, and since H
doesn't figure out the affect of this, it can't be sure t has the right
answer.

>
> Furthermore:
>
> void Px(ptr x)
> {
>   int Halt_Status = Hx(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", Hx(Px, Px));
> }
>
> There are zero elements of infinite set of Hx/Px pairs such that the
> correct *partial or complete* simulation of Px by Hx reaches the final
> state of Px and halts. This is also the case when Hx directly executes Px.
>
> My reviewers simply are not bright enough to see this thus mistakenly
> believe that I am wrong.
>
> Complete halt deciding system (Visual Studio Project)
> (a) x86utm operating system
> (b) complete x86 emulator adapted from libx86emu
> (c) Several halt deciders and their inputs contained within Halt7.c
> https://liarparadox.org/2022_09_07.zip
>

And that system can be used to show that your H(P,P) returns 0, but that
the actual behavior of that input, that is P(P), and the COMPLETE
simulation of that input Simulate(P,P) both halts.

So, your own tools prove you wrong, and to be a liar.

You have wasted the last 18 years of your life pushing a lie.

On 9/29/2022 6:00 PM, Richard Damon wrote:
>
> On 9/29/22 9:49 AM, olcott wrote:
>> On 9/28/2022 3:05 PM, Paul N wrote:
>>> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>>>> olcott <non...@beez-waxes.com> wrote:
>>>>>
>>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>>>> olcott <polc...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>>>> input.
>>>>>>>
>>>>>>> And your decider doesn't do that so it isn't a halt decider, it is a
>>>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>>>> to their caller in finite time.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> My code speaks for itself, thus conclusively proves that you don't
>>>>>> have a clue.
>>>>>
>>>>> Your code speaks for itself: it doesn't meet the functional
>>>>> requirements of a halt decider. You don't have a clue.
>>>>>
>>>>> /Flibble
>>>>>
>>>> You simply don't have the mental discipline to pay enough attention to
>>>> understand my rebuttals of your claims.
>>>>
>>>> Halt deciders must compute the mapping from their inputs to a final
>>>> accept or reject state on the basis of the actual behavior specified by
>>>> these inputs.
>>>
>>> Yes. You keep trying to pull a sleight-of-hand by saying that what
>>> counts is not the actual behaviour but what a correct simulation
>>> would do. This is not actually correct because P cannot be simulated
>>> properly. You then say that your simulation is correct, despite it
>>> giving the wrong answers. You justify that by claiming that no-one
>>> has found a flaw in it, despite several people pointing out the flaws
>>> numerous times, which you wave away by claiming, with no proof, that
>>> they are all wrong.
>>>
>>
>> I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
>> It is easily verified that the simulation is correct in that the
>> simulated x86 instructions exactly match what their x86 source-code
>> specifies.
>
> Except it is only a PARTIAL simulation, so it ony PARTIALLY determines
> the behavior of the input.
>

For Infinite_Loop(), Infinite_Recursion(int N) and P(ptr x), H does
correctly determine that none of these will ever reach their own final
state and halt in 1 to ∞ steps of correct simulation. It does this by
matching a correct non-halting behavior pattern in a finite number of
steps.

You already acknowledged that a halt decider need not simulate an
infinite loop an infinite number of times to detect that this loop is
infinite.

Is it that detecting infinite recursion and recursive simulation is too
difficult for you you understand and in this ignorance you simply assume
that I must be wrong?

--
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 9/29/22 7:12 PM, olcott wrote:
> On 9/29/2022 6:00 PM, Richard Damon wrote:
>>
>> On 9/29/22 9:49 AM, olcott wrote:
>>> On 9/28/2022 3:05 PM, Paul N wrote:
>>>> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>>>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>>>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>>>>> olcott <non...@beez-waxes.com> wrote:
>>>>>>
>>>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>>>>> olcott <polc...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>>>>> input.
>>>>>>>>
>>>>>>>> And your decider doesn't do that so it isn't a halt decider, it
>>>>>>>> is a
>>>>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>>>>> to their caller in finite time.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> My code speaks for itself, thus conclusively proves that you don't
>>>>>>> have a clue.
>>>>>>
>>>>>> Your code speaks for itself: it doesn't meet the functional
>>>>>> requirements of a halt decider. You don't have a clue.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>> You simply don't have the mental discipline to pay enough attention to
>>>>> understand my rebuttals of your claims.
>>>>>
>>>>> Halt deciders must compute the mapping from their inputs to a final
>>>>> accept or reject state on the basis of the actual behavior
>>>>> specified by
>>>>> these inputs.
>>>>
>>>> Yes. You keep trying to pull a sleight-of-hand by saying that what
>>>> counts is not the actual behaviour but what a correct simulation
>>>> would do. This is not actually correct because P cannot be simulated
>>>> properly. You then say that your simulation is correct, despite it
>>>> giving the wrong answers. You justify that by claiming that no-one
>>>> has found a flaw in it, despite several people pointing out the
>>>> flaws numerous times, which you wave away by claiming, with no
>>>> proof, that they are all wrong.
>>>>
>>>
>>> I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
>>> It is easily verified that the simulation is correct in that the
>>> simulated x86 instructions exactly match what their x86 source-code
>>> specifies.
>>
>> Except it is only a PARTIAL simulation, so it ony PARTIALLY determines
>> the behavior of the input.
>>
>
> For Infinite_Loop(), Infinite_Recursion(int N) and P(ptr x), H does
> correctly determine that none of these will ever reach their own final
> state and halt in 1 to ∞ steps of correct simulation. It does this by
> matching a correct non-halting behavior pattern in a finite number of
> steps.

So, it used valid logic from the partial simulation to prove that those
are non-haoting pattern. There is no valid logic that shows that P(P) is
non-halting, since any pattern detected and aborted on makes P(P) Halting.

You are still stuck on the fallacy of proof by example. It doesn't work
for Universal problems.

>
> You already acknowledged that a halt decider need not simulate an
> infinite loop an infinite number of times to detect that this loop is
> infinite.

Right, but the correct answer is what the complete simulation does.
Since P(P) will Halt, as will UTM(P,P) if H(P,P) returns 0, that can not
be the right answer.

>
> Is it that detecting infinite recursion and recursive simulation is too
> difficult for you you understand and in this ignorance you simply assume
> that I must be wrong?
>

No, the apparent infinte simulation in P(P) is too complicated for H to
find, since if it thinks it has found it, it isn't there anymore.

It is a bit like Quantum Mechanics.

On 9/29/2022 6:24 PM, Richard Damon wrote:
> On 9/29/22 7:12 PM, olcott wrote:
>> On 9/29/2022 6:00 PM, Richard Damon wrote:
>>>
>>> On 9/29/22 9:49 AM, olcott wrote:
>>>> On 9/28/2022 3:05 PM, Paul N wrote:
>>>>> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>>>>>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>>>>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>>>>>> olcott <non...@beez-waxes.com> wrote:
>>>>>>>
>>>>>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:
>>>>>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>>>>>> olcott <polc...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>>>>>> accept or reject state on the basis of the actual behavior of
>>>>>>>>>> this
>>>>>>>>>> input.
>>>>>>>>>
>>>>>>>>> And your decider doesn't do that so it isn't a halt decider, it
>>>>>>>>> is a
>>>>>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>>>>>> to their caller in finite time.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> My code speaks for itself, thus conclusively proves that you don't
>>>>>>>> have a clue.
>>>>>>>
>>>>>>> Your code speaks for itself: it doesn't meet the functional
>>>>>>> requirements of a halt decider. You don't have a clue.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>> You simply don't have the mental discipline to pay enough
>>>>>> attention to
>>>>>> understand my rebuttals of your claims.
>>>>>>
>>>>>> Halt deciders must compute the mapping from their inputs to a final
>>>>>> accept or reject state on the basis of the actual behavior
>>>>>> specified by
>>>>>> these inputs.
>>>>>
>>>>> Yes. You keep trying to pull a sleight-of-hand by saying that what
>>>>> counts is not the actual behaviour but what a correct simulation
>>>>> would do. This is not actually correct because P cannot be
>>>>> simulated properly. You then say that your simulation is correct,
>>>>> despite it giving the wrong answers. You justify that by claiming
>>>>> that no-one has found a flaw in it, despite several people pointing
>>>>> out the flaws numerous times, which you wave away by claiming, with
>>>>> no proof, that they are all wrong.
>>>>>
>>>>
>>>> I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
>>>> It is easily verified that the simulation is correct in that the
>>>> simulated x86 instructions exactly match what their x86 source-code
>>>> specifies.
>>>
>>> Except it is only a PARTIAL simulation, so it ony PARTIALLY
>>> determines the behavior of the input.
>>>
>>
>> For Infinite_Loop(), Infinite_Recursion(int N) and P(ptr x), H does
>> correctly determine that none of these will ever reach their own final
>> state and halt in 1 to ∞ steps of correct simulation. It does this by
>> matching a correct non-halting behavior pattern in a finite number of
>> steps.
>
> So, it used valid logic from the partial simulation to prove that those
> are non-haoting pattern. There is no valid logic that shows that P(P) is
> non-halting, since any pattern detected and aborted on makes P(P) Halting.
>

You were the one to come up with a specific term for the idea that an
aborted simulation does not mean that this input halts.

You know that every Px element of the Hx/Px pairs correctly simulated or
directly executed by Hx never halts. That you persist in lying about
this could cause you to end up on Satan's team.

If you can comprehend the infinite recursion non-halting behavior
pattern is correct then you can equally comprehend that the recursive
simulation non-halting behavior pattern is correct it applies the exact
same criteria.

If you CANNOT comprehend the infinite recursion non-halting behavior
pattern is correct then this stuff is simply over your head.

--
Copyright 2022 Pete Olcott

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