On 9/13/2022 5:54 PM, Richard Damon wrote:
> On 9/13/22 11:06 AM, olcott wrote:
>>>
>>
>> Every time that a simulating halt decider must abort the simulation of
>> its input to prevent the infinite simulation of this input
>> conclusively proves that this correctly simulated input cannot
>> possibly reach its own final state and halt.
>
> Not if it is programmed to do that abort, as P(P) shows.

Of the the infinite set of Hx/Px pairs where Hx performs a correct
(partial or complete) simulation of Px none of them reach the final
state of Px.

You change the subject using the strawman deception because you are
fundamentally deceitful.

*straw man*
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

--
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/13/22 7:22 PM, olcott wrote:
> On 9/13/2022 5:54 PM, Richard Damon wrote:
>> On 9/13/22 11:06 AM, olcott wrote:
>>>>
>>>
>>> Every time that a simulating halt decider must abort the simulation
>>> of its input to prevent the infinite simulation of this input
>>> conclusively proves that this correctly simulated input cannot
>>> possibly reach its own final state and halt.
>>
>> Not if it is programmed to do that abort, as P(P) shows.
>
> Of the the infinite set of Hx/Px pairs where Hx performs a correct
> (partial or complete) simulation of Px none of them reach the final
> state of Px.

So? that isn't what the Halting Problem is about. P(P) Halt whenever the
H(P,P) it is built on returns 0, so that answer is NEVER the right one
for that P. At least if H is supposed to be a Halting Decider.

>
> You change the subject using the strawman deception because you are
> fundamentally deceitful.

No, YOU have changed the topic, you claim to be talking about "The
Halting Problem", but don't use its requirements.

>
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
>

Right, like your "Simulation by H", when the ACTUAL defintion is the
behavior of the ACTUAL MACHINE, or equivalently, but a REAL UTM, not
your H's that only play one on TV (at least the ones tha give an answer).

FAIL.

You repeated pointing out of this argument is just showing what you
yourself are doing. You clearly do not understand what ANY of this
means, and are just lying to try to make your dishonest point.

You are just proving your ignorance of the topic, your inability to
learn, and your utter disreguard for the truth.

This is your legacy unless you do something drastic soon to change the
impression you are leaving on the worlds.

On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
> On 9/13/2022 9:43 AM, Paul N wrote:
> > On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
> >> On 9/13/2022 6:34 AM, Paul N wrote:
> >>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
> >>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>> Simulating halt deciders always predict what the behavior of their input
> >>>> would be if they never aborted their simulation of this input.
> >>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
> >>>> simulated by Hx ever reaches its final state.
> >>>>
> >>>> All of your "rebuttals" depend oon the strawman deception and never
> >>>> axcually refutes either of the above two precise wordings.
> >>>
> >>> You're not even correct when you say that the wording above is precise.
> >>>
> >>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
> >>>
> >> *So you accept this as true*
> >> Simulating halt deciders always predict what the behavior of their input
> >> would be if they never aborted their simulation of this input.
> >> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
> >> that is correctly simulated by any Hx ever reaches its final state.
> >
> > Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
> >
> You said that the wording of the second one was imprecise and did not
> seem to comment on the first one.
> >>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
> >> As I have told you many times "correctly simulated" means that each line
> >> of 1 to N lines of the execution trace derived by the simulation of Px
> >> precisely corresponds to the sequence of lines specified by the x86
> >> source-code of Px.
> >
> > There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
> When I say something hundreds of times you forget that I ever said it?
> I did not bother to post the x86 version because I have said many
> hundreds of times that the simulating halt decider bases its halt status
> decision on the execution trace of its correct simulation of the x86
> source-code.
> >
> > Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
> Every time that a simulating halt decider must abort the simulation of
> its input to prevent the infinite simulation of this input conclusively
> proves that this correctly simulated input cannot possibly reach its own
> final state and halt.

This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it. It's a bit like saying that if you need a dog licence for your pet, this proves conclusively that the pet is a dog.

But anyhow, you have shown numerous times that you are getting the simulation wrong. Suppose we have two functions, Hn which does not abort and will go on simulating until the code it is simulating reaches a halt, and Ha which can detect whether it is stuck in some sort of infinite loop.

If Px calls Hn, then a simulation of Px by Hn will indeed run forever. Hn won't spot this.

If Px calls Hn, then it is possible that a simulation of Px by Ha will be able to spot this and correctly report that Px will run forever.

If Px calls Ha, then your deduction that Px will run forever is no longer valid, because we have replaced Hn which does not abort with Ha which does.

You gloss over this point each time, insisting that it makes no difference, Px runs forever, Hx correctly reports this, and yet admit Px when directly executed actually halts. You've said this tons of times, but it is still not correct.

> >>> You however have insisted that when you use the term "actual behavior" you mean the result of a correct simulation,
> >> It is understood in computer science that the correct and complete
> >> simulation of a machine description does provide the actual behavior
> >> specified by this machine description.
> >>
> >> The current discussion is limited to Hx/Px pairs where Hx correctly
> >> simulates 1 to ∞ lines of Px. It is known that none of the Px instances
> >> ever reach their final state.
> >> which may differ from what actually happens. In this case presumably a
> >> "correct simulation" means something that produces the same results as a
> >> correct simulation, which is of course an entirely circular definition..
> >>>
> >>> I think the confusion in what you write is related to the confusion in how you understand things.
> >>>
> >>> Px is a very simple function and it is clear that it must do the opposite of what Hx predicts it will do.
> >> *WHY DO I HAVE TO CORRECT YOU AGAIN AND AGAIN ON THIS POINT*
> >> If and only if it ever get to the point in its execution trace where it
> >> receives a return value from H. Every Px correctly simulated by any Hx
> >> never gets to this point.
> >
> > Just look at the code for Px:
> >
> > void Px(ptr x)
> > {
> > int Halt_Status = Hx(x, x);
> > if (Halt_Status)
> > HERE: goto HERE;
> > return;
> > }
> >
> > If we run this, it will call Hx.
> The scope of the investigation is every Hx/Px pair where Hx correctly
> simulates 1 to ∞ instructions of Px. If we want to examine the direct
> execution of Px this is what we must examine:
> int Hx(ptr x, ptr y)
> {
> x(y);
> }
> > If Hx is indeed a SHD it will produce a value within finite time.
> >
> That is why is must correctly predict that a correctly simulated input
> cannot possibly reach the final state of this input.
> > If we do a *correct* simulation of Px, the simulation will get to the same point.
> >
> If we do a correct simulate of 1 step of Px it will not get to the same
> point as a correct simulation of 2 steps of Px. No correct simulation of
> 1 to ∞ instructions of Px ever reaches the final state of Px.
> > I assume you know that the code of Px which you keep posting contradicts what you are saying about it, because when I asked you simple questions about the operation of Px you simply snipped them. Twice.
> Questions based on false assumptions have no correct answer. The only
> thing that can be done with questions based on false assumptions is to
> correct the false assumption.

Please state the wrong assumptions made when I asked you about the operation of Px.

> >
> >>> Thus it is impossible to write an Hx which is always right, no matter how clever you are.
> >> It is impossible for you to understand what I am saying when you make
> >> sure to ignore what I am saying.
> >
> > That's not true. I have addressed your "A simulation can be correct even if it gives the wrong answers" nonsense several times now.
> >
> Every Hx that returns 0 correctly predicts that every simulation of 1 to
> ∞ instructions of Px never reaches the final state of Px.
>
> When you dishonestly change the words that I said and then form a
> rebuttal based on these changed words this is known as the strawman
> deception.
> >> I have had to constantly correct you on the same points over and over as
> >> if you don't give a rat's ass for truth.
> >
> >>> You fail to accept this simple point. You also fail to accept the more complicated details about why your actual Hx is wrong.
> Even if Hx was only predicting that its own partial simulation of Px
> never reaches the final state of Px it would still be correct for this
> Hx to return 0.
>
> Every Hx that returns 0 correctly predicts that every simulation of 1 to
> ∞ instructions of Px never reaches the final state of Px.

On 9/14/2022 5:58 AM, Paul N wrote:
> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
>> On 9/13/2022 9:43 AM, Paul N wrote:
>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
>>>> On 9/13/2022 6:34 AM, Paul N wrote:
>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>> would be if they never aborted their simulation of this input.
>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
>>>>>> simulated by Hx ever reaches its final state.
>>>>>>
>>>>>> All of your "rebuttals" depend oon the strawman deception and never
>>>>>> axcually refutes either of the above two precise wordings.
>>>>>
>>>>> You're not even correct when you say that the wording above is precise.
>>>>>
>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
>>>>>
>>>> *So you accept this as true*
>>>> Simulating halt deciders always predict what the behavior of their input
>>>> would be if they never aborted their simulation of this input.
>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
>>>> that is correctly simulated by any Hx ever reaches its final state.
>>>
>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
>>>
>> You said that the wording of the second one was imprecise and did not
>> seem to comment on the first one.
>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
>>>> As I have told you many times "correctly simulated" means that each line
>>>> of 1 to N lines of the execution trace derived by the simulation of Px
>>>> precisely corresponds to the sequence of lines specified by the x86
>>>> source-code of Px.
>>>
>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
>> When I say something hundreds of times you forget that I ever said it?
>> I did not bother to post the x86 version because I have said many
>> hundreds of times that the simulating halt decider bases its halt status
>> decision on the execution trace of its correct simulation of the x86
>> source-code.
>>>
>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
>> Every time that a simulating halt decider must abort the simulation of
>> its input to prevent the infinite simulation of this input conclusively
>> proves that this correctly simulated input cannot possibly reach its own
>> final state and halt.
>
> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.

No not at all. I have proven that no Px of the infinite set of Hx/Px
pairs ever reaches its final state when 1 to ∞ steps of of Px have been
correctly simulated by Hx.

I am going to stop here and go over this point again and again until you
get it, before moving on to any other points.

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));
}

*When we examine the infinite set of Hx/Px pairs*

*EXISTENTIAL QUANTIFICATION PROVES MY POINT*
No function Hx can be defined such that its correct simulation of its
input Px would reach the final state of this simulated Px in any finite
number of steps.

--
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 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
> On 9/14/2022 5:58 AM, Paul N wrote:
> > On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
> >> On 9/13/2022 9:43 AM, Paul N wrote:
> >>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
> >>>> On 9/13/2022 6:34 AM, Paul N wrote:
> >>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
> >>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>> Simulating halt deciders always predict what the behavior of their input
> >>>>>> would be if they never aborted their simulation of this input.
> >>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
> >>>>>> simulated by Hx ever reaches its final state.
> >>>>>>
> >>>>>> All of your "rebuttals" depend oon the strawman deception and never
> >>>>>> axcually refutes either of the above two precise wordings.
> >>>>>
> >>>>> You're not even correct when you say that the wording above is precise.
> >>>>>
> >>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
> >>>>>
> >>>> *So you accept this as true*
> >>>> Simulating halt deciders always predict what the behavior of their input
> >>>> would be if they never aborted their simulation of this input.
> >>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
> >>>> that is correctly simulated by any Hx ever reaches its final state.
> >>>
> >>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
> >>>
> >> You said that the wording of the second one was imprecise and did not
> >> seem to comment on the first one.
> >>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
> >>>> As I have told you many times "correctly simulated" means that each line
> >>>> of 1 to N lines of the execution trace derived by the simulation of Px
> >>>> precisely corresponds to the sequence of lines specified by the x86
> >>>> source-code of Px.
> >>>
> >>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
> >> When I say something hundreds of times you forget that I ever said it?
> >> I did not bother to post the x86 version because I have said many
> >> hundreds of times that the simulating halt decider bases its halt status
> >> decision on the execution trace of its correct simulation of the x86
> >> source-code.
> >>>
> >>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
> >> Every time that a simulating halt decider must abort the simulation of
> >> its input to prevent the infinite simulation of this input conclusively
> >> proves that this correctly simulated input cannot possibly reach its own
> >> final state and halt.
> >
> > This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
> No not at all. I have proven that no Px of the infinite set of Hx/Px
> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
> correctly simulated by Hx.
>
> I am going to stop here and go over this point again and again until you
> get it, before moving on to any other points.

OK, we'll go through it again. You said that:

[ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]

conclusively proves that

[ this correctly simulated input cannot possibly reach its own final state and halt. ]

(brackets and emphasis added)

So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".

> 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));
> }
> *When we examine the infinite set of Hx/Px pairs*
>
> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*

What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".

> No function Hx can be defined such that its correct simulation of its
> input Px would reach the final state of this simulated Px in any finite
> number of steps.

Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.

On 9/14/2022 10:31 AM, Paul N wrote:
> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
>> On 9/14/2022 5:58 AM, Paul N wrote:
>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
>>>> On 9/13/2022 9:43 AM, Paul N wrote:
>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
>>>>>>>> simulated by Hx ever reaches its final state.
>>>>>>>>
>>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
>>>>>>>> axcually refutes either of the above two precise wordings.
>>>>>>>
>>>>>>> You're not even correct when you say that the wording above is precise.
>>>>>>>
>>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
>>>>>>>
>>>>>> *So you accept this as true*
>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>> would be if they never aborted their simulation of this input.
>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
>>>>>> that is correctly simulated by any Hx ever reaches its final state.
>>>>>
>>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
>>>>>
>>>> You said that the wording of the second one was imprecise and did not
>>>> seem to comment on the first one.
>>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
>>>>>> As I have told you many times "correctly simulated" means that each line
>>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
>>>>>> precisely corresponds to the sequence of lines specified by the x86
>>>>>> source-code of Px.
>>>>>
>>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
>>>> When I say something hundreds of times you forget that I ever said it?
>>>> I did not bother to post the x86 version because I have said many
>>>> hundreds of times that the simulating halt decider bases its halt status
>>>> decision on the execution trace of its correct simulation of the x86
>>>> source-code.
>>>>>
>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
>>>> Every time that a simulating halt decider must abort the simulation of
>>>> its input to prevent the infinite simulation of this input conclusively
>>>> proves that this correctly simulated input cannot possibly reach its own
>>>> final state and halt.
>>>
>>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
>> No not at all. I have proven that no Px of the infinite set of Hx/Px
>> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
>> correctly simulated by Hx.
>>
>> I am going to stop here and go over this point again and again until you
>> get it, before moving on to any other points.
>
> OK, we'll go through it again. You said that:
>
> [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
>
> conclusively proves that
>
> [ this correctly simulated input cannot possibly reach its own final state and halt. ]
>
> (brackets and emphasis added)
>
> So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
>
>> 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));
>> }
>> *When we examine the infinite set of Hx/Px pairs*
>>
>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>
> What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
>
>> No function Hx can be defined such that its correct simulation of its
>> input Px would reach the final state of this simulated Px in any finite
>> number of steps.
>
> Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.

That is not true, I have such a function. Perhaps I greatly
overestimated your software engineering skills.

*Function HH performs a correct recursive simulation of PP*
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 Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
> On 9/14/2022 10:31 AM, Paul N wrote:
> > On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
> >> On 9/14/2022 5:58 AM, Paul N wrote:
> >>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
> >>>> On 9/13/2022 9:43 AM, Paul N wrote:
> >>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
> >>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
> >>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
> >>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>>>> Simulating halt deciders always predict what the behavior of their input
> >>>>>>>> would be if they never aborted their simulation of this input.
> >>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
> >>>>>>>> simulated by Hx ever reaches its final state.
> >>>>>>>>
> >>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
> >>>>>>>> axcually refutes either of the above two precise wordings.
> >>>>>>>
> >>>>>>> You're not even correct when you say that the wording above is precise.
> >>>>>>>
> >>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
> >>>>>>>
> >>>>>> *So you accept this as true*
> >>>>>> Simulating halt deciders always predict what the behavior of their input
> >>>>>> would be if they never aborted their simulation of this input.
> >>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
> >>>>>> that is correctly simulated by any Hx ever reaches its final state..
> >>>>>
> >>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
> >>>>>
> >>>> You said that the wording of the second one was imprecise and did not
> >>>> seem to comment on the first one.
> >>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
> >>>>>> As I have told you many times "correctly simulated" means that each line
> >>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
> >>>>>> precisely corresponds to the sequence of lines specified by the x86
> >>>>>> source-code of Px.
> >>>>>
> >>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
> >>>> When I say something hundreds of times you forget that I ever said it?
> >>>> I did not bother to post the x86 version because I have said many
> >>>> hundreds of times that the simulating halt decider bases its halt status
> >>>> decision on the execution trace of its correct simulation of the x86
> >>>> source-code.
> >>>>>
> >>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
> >>>> Every time that a simulating halt decider must abort the simulation of
> >>>> its input to prevent the infinite simulation of this input conclusively
> >>>> proves that this correctly simulated input cannot possibly reach its own
> >>>> final state and halt.
> >>>
> >>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
> >> No not at all. I have proven that no Px of the infinite set of Hx/Px
> >> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
> >> correctly simulated by Hx.
> >>
> >> I am going to stop here and go over this point again and again until you
> >> get it, before moving on to any other points.
> >
> > OK, we'll go through it again. You said that:
> >
> > [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
> >
> > conclusively proves that
> >
> > [ this correctly simulated input cannot possibly reach its own final state and halt. ]
> >
> > (brackets and emphasis added)
> >
> > So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
> >
> >> 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));
> >> }
> >> *When we examine the infinite set of Hx/Px pairs*
> >>
> >> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
> >
> > What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
> >
> >> No function Hx can be defined such that its correct simulation of its
> >> input Px would reach the final state of this simulated Px in any finite
> >> number of steps.
> >
> > Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.
> That is not true, I have such a function. Perhaps I greatly
> overestimated your software engineering skills.

My software engineering skills are in doubt because you claim to have produced something that has been proved impossible?

> *Function HH performs a correct recursive simulation of PP*
> https://liarparadox.org/2022_09_07.zip

Come on then. Does PP halt when you run it? Does HH(PP, PP) give a result in finite time and, if so, is it zero or not?

On 9/14/2022 2:47 PM, Paul N wrote:
> On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
>> On 9/14/2022 10:31 AM, Paul N wrote:
>>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
>>>> On 9/14/2022 5:58 AM, Paul N wrote:
>>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
>>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
>>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
>>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
>>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
>>>>>>>>>> simulated by Hx ever reaches its final state.
>>>>>>>>>>
>>>>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
>>>>>>>>>> axcually refutes either of the above two precise wordings.
>>>>>>>>>
>>>>>>>>> You're not even correct when you say that the wording above is precise.
>>>>>>>>>
>>>>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
>>>>>>>>>
>>>>>>>> *So you accept this as true*
>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
>>>>>>>> that is correctly simulated by any Hx ever reaches its final state.
>>>>>>>
>>>>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
>>>>>>>
>>>>>> You said that the wording of the second one was imprecise and did not
>>>>>> seem to comment on the first one.
>>>>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
>>>>>>>> As I have told you many times "correctly simulated" means that each line
>>>>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
>>>>>>>> precisely corresponds to the sequence of lines specified by the x86
>>>>>>>> source-code of Px.
>>>>>>>
>>>>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
>>>>>> When I say something hundreds of times you forget that I ever said it?
>>>>>> I did not bother to post the x86 version because I have said many
>>>>>> hundreds of times that the simulating halt decider bases its halt status
>>>>>> decision on the execution trace of its correct simulation of the x86
>>>>>> source-code.
>>>>>>>
>>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
>>>>>> Every time that a simulating halt decider must abort the simulation of
>>>>>> its input to prevent the infinite simulation of this input conclusively
>>>>>> proves that this correctly simulated input cannot possibly reach its own
>>>>>> final state and halt.
>>>>>
>>>>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
>>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
>>>> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
>>>> correctly simulated by Hx.
>>>>
>>>> I am going to stop here and go over this point again and again until you
>>>> get it, before moving on to any other points.
>>>
>>> OK, we'll go through it again. You said that:
>>>
>>> [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
>>>
>>> conclusively proves that
>>>
>>> [ this correctly simulated input cannot possibly reach its own final state and halt. ]
>>>
>>> (brackets and emphasis added)
>>>
>>> So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
>>>
>>>> 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));
>>>> }
>>>> *When we examine the infinite set of Hx/Px pairs*
>>>>
>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>
>>> What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
>>>
>>>> No function Hx can be defined such that its correct simulation of its
>>>> input Px would reach the final state of this simulated Px in any finite
>>>> number of steps.
>>>
>>> Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.
>> That is not true, I have such a function. Perhaps I greatly
>> overestimated your software engineering skills.
>
> My software engineering skills are in doubt because you claim to have produced something that has been proved impossible?
>
>> *Function HH performs a correct recursive simulation of PP*
>> https://liarparadox.org/2022_09_07.zip
>
> Come on then. Does PP halt when you run it? Does HH(PP, PP) give a result in finite time and, if so, is it zero or not?

You have changed the subject again. Normally when someone changes the
subject as the basis for their rebuttal I call this the strawman deception.

*straw man*
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

I will give you the benefit of the doubt this time and call it an honest
mistake. In the future when you provide any rebuttal it must directly
address the 100% exactly precise words that I have said with zero wiggle
room.

On 9/14/2022 10:31 AM, Paul N wrote:
> ... No function Hx can be defined that correctly simulates
> its input Px at all.

When I provide an HH that does correctly simulate PP (structurally
identical to Hx/Px) then your statement has been fully refuted, then you
acknowledge that you were wrong and I am right and we move on to another
point.

Most everyone else here seems to use the despicable lying bastard
approach of the strawman deception. I will no longer tolerate that.

--
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/14/22 4:01 PM, olcott wrote:
> On 9/14/2022 2:47 PM, Paul N wrote:
>> On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
>>>>> On 9/14/2022 5:58 AM, Paul N wrote:
>>>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
>>>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
>>>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
>>>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
>>>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott
>>>>>>>>>> wrote:
>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>> Simulating halt deciders always predict what the behavior of
>>>>>>>>>>> their input
>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
>>>>>>>>>>> simulated by Hx ever reaches its final state.
>>>>>>>>>>>
>>>>>>>>>>> All of your "rebuttals" depend oon the strawman deception and
>>>>>>>>>>> never
>>>>>>>>>>> axcually refutes either of the above two precise wordings.
>>>>>>>>>>
>>>>>>>>>> You're not even correct when you say that the wording above is
>>>>>>>>>> precise.
>>>>>>>>>>
>>>>>>>>>> The second one uses "Hx" in two different contexts, one to
>>>>>>>>>> refer to a particular, accurate SHD and one to refer to any of
>>>>>>>>>> an infinite set.
>>>>>>>>>>
>>>>>>>>> *So you accept this as true*
>>>>>>>>> Simulating halt deciders always predict what the behavior of
>>>>>>>>> their input
>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
>>>>>>>>> that is correctly simulated by any Hx ever reaches its final
>>>>>>>>> state.
>>>>>>>>
>>>>>>>> Interesting that you assume I accept this, merely from the fact
>>>>>>>> that I point out that the wording is unclear.
>>>>>>>>
>>>>>>> You said that the wording of the second one was imprecise and did
>>>>>>> not
>>>>>>> seem to comment on the first one.
>>>>>>>>>> You also use the term "correctly simulated" which in the light
>>>>>>>>>> of your earlier comments is not precise. Normally the term
>>>>>>>>>> "actual behaviour" means what something actually does, and so
>>>>>>>>>> "correctly simulated" means that the simulator accurately
>>>>>>>>>> reproduces this.
>>>>>>>>> As I have told you many times "correctly simulated" means that
>>>>>>>>> each line
>>>>>>>>> of 1 to N lines of the execution trace derived by the
>>>>>>>>> simulation of Px
>>>>>>>>> precisely corresponds to the sequence of lines specified by the
>>>>>>>>> x86
>>>>>>>>> source-code of Px.
>>>>>>>>
>>>>>>>> There are two flaws with this. Firstly, though a fairly minor
>>>>>>>> point, is that the source code of Px is C, not x86. Presumably
>>>>>>>> this could be fixed, but it does show you're thinking entirely
>>>>>>>> straight.
>>>>>>> When I say something hundreds of times you forget that I ever
>>>>>>> said it?
>>>>>>> I did not bother to post the x86 version because I have said many
>>>>>>> hundreds of times that the simulating halt decider bases its halt
>>>>>>> status
>>>>>>> decision on the execution trace of its correct simulation of the x86
>>>>>>> source-code.
>>>>>>>>
>>>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx
>>>>>>>> as well. All the evidence so far is that you are getting the
>>>>>>>> simulation of Hx wrong, generally because you assume that Hx
>>>>>>>> gets stuck in a loop which know it does not do.
>>>>>>> Every time that a simulating halt decider must abort the
>>>>>>> simulation of
>>>>>>> its input to prevent the infinite simulation of this input
>>>>>>> conclusively
>>>>>>> proves that this correctly simulated input cannot possibly reach
>>>>>>> its own
>>>>>>> final state and halt.
>>>>>>
>>>>>> This seems a bit back to front. You are presumably assuming that
>>>>>> the simulation would otherwise go on forever when you decide you
>>>>>> "must" abort it.
>>>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
>>>>> pairs ever reaches its final state when 1 to ∞ steps of of Px have
>>>>> been
>>>>> correctly simulated by Hx.
>>>>>
>>>>> I am going to stop here and go over this point again and again
>>>>> until you
>>>>> get it, before moving on to any other points.
>>>>
>>>> OK, we'll go through it again. You said that:
>>>>
>>>> [ Every time that a simulating halt decider MUST abort the
>>>> simulation of its input to prevent the infinite simulation of this
>>>> input ]
>>>>
>>>> conclusively proves that
>>>>
>>>> [ this correctly simulated input cannot possibly reach its own final
>>>> state and halt. ]
>>>>
>>>> (brackets and emphasis added)
>>>>
>>>> So if something happens (the first bracket) we have proved the input
>>>> cannot reach its final state (the second bracket). What has to
>>>> happen? Well, we have to show that the aborting is a necessity to
>>>> prevent the simulation going on forever; that is to say, to prove
>>>> that the simulated P is not going to reach a final state. So we have
>>>> to have proved the conclusion to be able to use the argument at all!
>>>> I believe this sort of thing is known as "begging the question".
>>>>
>>>>> 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));
>>>>> }
>>>>> *When we examine the infinite set of Hx/Px pairs*
>>>>>
>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>
>>>> What is "existential quantification"? I presume it means more than
>>>> "because I say something exists, it does exist".
>>>>
>>>>> No function Hx can be defined such that its correct simulation of its
>>>>> input Px would reach the final state of this simulated Px in any
>>>>> finite
>>>>> number of steps.
>>>>
>>>> Strangely enough I agree with this bit. No function Hx can be
>>>> defined that correctly simulates its input Px at all.
>>> That is not true, I have such a function. Perhaps I greatly
>>> overestimated your software engineering skills.
>>
>> My software engineering skills are in doubt because you claim to have
>> produced something that has been proved impossible?
>>
>>> *Function HH performs a correct recursive simulation of PP*
>>> https://liarparadox.org/2022_09_07.zip
>>
>> Come on then. Does PP halt when you run it? Does HH(PP, PP) give a
>> result in finite time and, if so, is it zero or not?
>
> You have changed the subject again. Normally when someone changes the
> subject as the basis for their rebuttal I call this the strawman deception.
>
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> I will give you the benefit of the doubt this time and call it an honest
> mistake. In the future when you provide any rebuttal it must directly
> address the 100% exactly precise words that I have said with zero wiggle
> room.
>
> On 9/14/2022 10:31 AM, Paul N wrote:
> > ... No function Hx can be defined that correctly simulates
> > its input Px at all.
>
> When I provide an HH that does correctly simulate PP (structurally
> identical to Hx/Px) then your statement has been fully refuted, then you
> acknowledge that you were wrong and I am right and we move on to another
> point.
>
> Most everyone else here seems to use the despicable lying bastard
> approach of the strawman deception. I will no longer tolerate that.
>

On Wednesday, September 14, 2022 at 9:01:28 PM UTC+1, olcott wrote:
> On 9/14/2022 2:47 PM, Paul N wrote:
> > On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
> >> On 9/14/2022 10:31 AM, Paul N wrote:
> >>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
> >>>> On 9/14/2022 5:58 AM, Paul N wrote:
> >>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
> >>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
> >>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
> >>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
> >>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
> >>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
> >>>>>>>>>> would be if they never aborted their simulation of this input.
> >>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
> >>>>>>>>>> simulated by Hx ever reaches its final state.
> >>>>>>>>>>
> >>>>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
> >>>>>>>>>> axcually refutes either of the above two precise wordings.
> >>>>>>>>>
> >>>>>>>>> You're not even correct when you say that the wording above is precise.
> >>>>>>>>>
> >>>>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
> >>>>>>>>>
> >>>>>>>> *So you accept this as true*
> >>>>>>>> Simulating halt deciders always predict what the behavior of their input
> >>>>>>>> would be if they never aborted their simulation of this input.
> >>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
> >>>>>>>> that is correctly simulated by any Hx ever reaches its final state.
> >>>>>>>
> >>>>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
> >>>>>>>
> >>>>>> You said that the wording of the second one was imprecise and did not
> >>>>>> seem to comment on the first one.
> >>>>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
> >>>>>>>> As I have told you many times "correctly simulated" means that each line
> >>>>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
> >>>>>>>> precisely corresponds to the sequence of lines specified by the x86
> >>>>>>>> source-code of Px.
> >>>>>>>
> >>>>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
> >>>>>> When I say something hundreds of times you forget that I ever said it?
> >>>>>> I did not bother to post the x86 version because I have said many
> >>>>>> hundreds of times that the simulating halt decider bases its halt status
> >>>>>> decision on the execution trace of its correct simulation of the x86
> >>>>>> source-code.
> >>>>>>>
> >>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
> >>>>>> Every time that a simulating halt decider must abort the simulation of
> >>>>>> its input to prevent the infinite simulation of this input conclusively
> >>>>>> proves that this correctly simulated input cannot possibly reach its own
> >>>>>> final state and halt.
> >>>>>
> >>>>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
> >>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
> >>>> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
> >>>> correctly simulated by Hx.
> >>>>
> >>>> I am going to stop here and go over this point again and again until you
> >>>> get it, before moving on to any other points.
> >>>
> >>> OK, we'll go through it again. You said that:
> >>>
> >>> [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
> >>>
> >>> conclusively proves that
> >>>
> >>> [ this correctly simulated input cannot possibly reach its own final state and halt. ]
> >>>
> >>> (brackets and emphasis added)
> >>>
> >>> So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
> >>>
> >>>> 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));
> >>>> }
> >>>> *When we examine the infinite set of Hx/Px pairs*
> >>>>
> >>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
> >>>
> >>> What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
> >>>
> >>>> No function Hx can be defined such that its correct simulation of its
> >>>> input Px would reach the final state of this simulated Px in any finite
> >>>> number of steps.
> >>>
> >>> Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.
> >> That is not true, I have such a function. Perhaps I greatly
> >> overestimated your software engineering skills.
> >
> > My software engineering skills are in doubt because you claim to have produced something that has been proved impossible?
> >
> >> *Function HH performs a correct recursive simulation of PP*
> >> https://liarparadox.org/2022_09_07.zip
> >
> > Come on then. Does PP halt when you run it? Does HH(PP, PP) give a result in finite time and, if so, is it zero or not?
> You have changed the subject again. Normally when someone changes the
> subject as the basis for their rebuttal I call this the strawman deception.
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
> I will give you the benefit of the doubt this time and call it an honest
> mistake. In the future when you provide any rebuttal it must directly
> address the 100% exactly precise words that I have said with zero wiggle
> room.

Rubbish. I said that no function Hx can be defined that correctly simulates its input Px at all. You "rebutted" that by saying that you have got one. I don't believe that you have. I then ask you the basic questions about it that will help reveal whether or not you really have such a function, and you accuse me of changing the subject!

On 9/15/2022 7:26 AM, Paul N wrote:
> On Wednesday, September 14, 2022 at 9:01:28 PM UTC+1, olcott wrote:
>> On 9/14/2022 2:47 PM, Paul N wrote:
>>> On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
>>>>>> On 9/14/2022 5:58 AM, Paul N wrote:
>>>>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
>>>>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
>>>>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
>>>>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
>>>>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
>>>>>>>>>>>> simulated by Hx ever reaches its final state.
>>>>>>>>>>>>
>>>>>>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
>>>>>>>>>>>> axcually refutes either of the above two precise wordings.
>>>>>>>>>>>
>>>>>>>>>>> You're not even correct when you say that the wording above is precise.
>>>>>>>>>>>
>>>>>>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
>>>>>>>>>>>
>>>>>>>>>> *So you accept this as true*
>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
>>>>>>>>>> that is correctly simulated by any Hx ever reaches its final state.
>>>>>>>>>
>>>>>>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
>>>>>>>>>
>>>>>>>> You said that the wording of the second one was imprecise and did not
>>>>>>>> seem to comment on the first one.
>>>>>>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
>>>>>>>>>> As I have told you many times "correctly simulated" means that each line
>>>>>>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
>>>>>>>>>> precisely corresponds to the sequence of lines specified by the x86
>>>>>>>>>> source-code of Px.
>>>>>>>>>
>>>>>>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
>>>>>>>> When I say something hundreds of times you forget that I ever said it?
>>>>>>>> I did not bother to post the x86 version because I have said many
>>>>>>>> hundreds of times that the simulating halt decider bases its halt status
>>>>>>>> decision on the execution trace of its correct simulation of the x86
>>>>>>>> source-code.
>>>>>>>>>
>>>>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
>>>>>>>> Every time that a simulating halt decider must abort the simulation of
>>>>>>>> its input to prevent the infinite simulation of this input conclusively
>>>>>>>> proves that this correctly simulated input cannot possibly reach its own
>>>>>>>> final state and halt.
>>>>>>>
>>>>>>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
>>>>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
>>>>>> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
>>>>>> correctly simulated by Hx.
>>>>>>
>>>>>> I am going to stop here and go over this point again and again until you
>>>>>> get it, before moving on to any other points.
>>>>>
>>>>> OK, we'll go through it again. You said that:
>>>>>
>>>>> [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
>>>>>
>>>>> conclusively proves that
>>>>>
>>>>> [ this correctly simulated input cannot possibly reach its own final state and halt. ]
>>>>>
>>>>> (brackets and emphasis added)
>>>>>
>>>>> So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
>>>>>
>>>>>> 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));
>>>>>> }
>>>>>> *When we examine the infinite set of Hx/Px pairs*
>>>>>>
>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>
>>>>> What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
>>>>>
>>>>>> No function Hx can be defined such that its correct simulation of its
>>>>>> input Px would reach the final state of this simulated Px in any finite
>>>>>> number of steps.
>>>>>
>>>>> Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.
>>>> That is not true, I have such a function. Perhaps I greatly
>>>> overestimated your software engineering skills.
>>>
>>> My software engineering skills are in doubt because you claim to have produced something that has been proved impossible?
>>>
>>>> *Function HH performs a correct recursive simulation of PP*
>>>> https://liarparadox.org/2022_09_07.zip
>>>
>>> Come on then. Does PP halt when you run it? Does HH(PP, PP) give a result in finite time and, if so, is it zero or not?
>> You have changed the subject again. Normally when someone changes the
>> subject as the basis for their rebuttal I call this the strawman deception.
>> *straw man*
>> An intentionally misrepresented proposition that is set up because it is
>> easier to defeat than an opponent's real argument.
>> https://www.lexico.com/en/definition/straw_man
>> I will give you the benefit of the doubt this time and call it an honest
>> mistake. In the future when you provide any rebuttal it must directly
>> address the 100% exactly precise words that I have said with zero wiggle
>> room.
>
> Rubbish. I said that no function Hx can be defined that correctly simulates its input Px at all. You "rebutted" that by saying that you have got one. I don't believe that you have. I then ask you the basic questions about it that will help reveal whether or not you really have such a function, and you accuse me of changing the subject!

On Thursday, September 15, 2022 at 3:04:42 PM UTC+1, olcott wrote:
> On 9/15/2022 7:26 AM, Paul N wrote:
> > On Wednesday, September 14, 2022 at 9:01:28 PM UTC+1, olcott wrote:
> >> On 9/14/2022 2:47 PM, Paul N wrote:
> >>> On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
> >>>> On 9/14/2022 10:31 AM, Paul N wrote:
> >>>>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
> >>>>>> On 9/14/2022 5:58 AM, Paul N wrote:
> >>>>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
> >>>>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
> >>>>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
> >>>>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
> >>>>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
> >>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
> >>>>>>>>>>>> would be if they never aborted their simulation of this input.
> >>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
> >>>>>>>>>>>> simulated by Hx ever reaches its final state.
> >>>>>>>>>>>>
> >>>>>>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
> >>>>>>>>>>>> axcually refutes either of the above two precise wordings.
> >>>>>>>>>>>
> >>>>>>>>>>> You're not even correct when you say that the wording above is precise.
> >>>>>>>>>>>
> >>>>>>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
> >>>>>>>>>>>
> >>>>>>>>>> *So you accept this as true*
> >>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
> >>>>>>>>>> would be if they never aborted their simulation of this input.
> >>>>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
> >>>>>>>>>> that is correctly simulated by any Hx ever reaches its final state.
> >>>>>>>>>
> >>>>>>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
> >>>>>>>>>
> >>>>>>>> You said that the wording of the second one was imprecise and did not
> >>>>>>>> seem to comment on the first one.
> >>>>>>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
> >>>>>>>>>> As I have told you many times "correctly simulated" means that each line
> >>>>>>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
> >>>>>>>>>> precisely corresponds to the sequence of lines specified by the x86
> >>>>>>>>>> source-code of Px.
> >>>>>>>>>
> >>>>>>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
> >>>>>>>> When I say something hundreds of times you forget that I ever said it?
> >>>>>>>> I did not bother to post the x86 version because I have said many
> >>>>>>>> hundreds of times that the simulating halt decider bases its halt status
> >>>>>>>> decision on the execution trace of its correct simulation of the x86
> >>>>>>>> source-code.
> >>>>>>>>>
> >>>>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
> >>>>>>>> Every time that a simulating halt decider must abort the simulation of
> >>>>>>>> its input to prevent the infinite simulation of this input conclusively
> >>>>>>>> proves that this correctly simulated input cannot possibly reach its own
> >>>>>>>> final state and halt.
> >>>>>>>
> >>>>>>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
> >>>>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
> >>>>>> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
> >>>>>> correctly simulated by Hx.
> >>>>>>
> >>>>>> I am going to stop here and go over this point again and again until you
> >>>>>> get it, before moving on to any other points.
> >>>>>
> >>>>> OK, we'll go through it again. You said that:
> >>>>>
> >>>>> [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
> >>>>>
> >>>>> conclusively proves that
> >>>>>
> >>>>> [ this correctly simulated input cannot possibly reach its own final state and halt. ]
> >>>>>
> >>>>> (brackets and emphasis added)
> >>>>>
> >>>>> So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
> >>>>>
> >>>>>> 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));
> >>>>>> }
> >>>>>> *When we examine the infinite set of Hx/Px pairs*
> >>>>>>
> >>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
> >>>>>
> >>>>> What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
> >>>>>
> >>>>>> No function Hx can be defined such that its correct simulation of its
> >>>>>> input Px would reach the final state of this simulated Px in any finite
> >>>>>> number of steps.
> >>>>>
> >>>>> Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.
> >>>> That is not true, I have such a function. Perhaps I greatly
> >>>> overestimated your software engineering skills.
> >>>
> >>> My software engineering skills are in doubt because you claim to have produced something that has been proved impossible?
> >>>
> >>>> *Function HH performs a correct recursive simulation of PP*
> >>>> https://liarparadox.org/2022_09_07.zip
> >>>
> >>> Come on then. Does PP halt when you run it? Does HH(PP, PP) give a result in finite time and, if so, is it zero or not?
> >> You have changed the subject again. Normally when someone changes the
> >> subject as the basis for their rebuttal I call this the strawman deception.
> >> *straw man*
> >> An intentionally misrepresented proposition that is set up because it is
> >> easier to defeat than an opponent's real argument.
> >> https://www.lexico.com/en/definition/straw_man
> >> I will give you the benefit of the doubt this time and call it an honest
> >> mistake. In the future when you provide any rebuttal it must directly
> >> address the 100% exactly precise words that I have said with zero wiggle
> >> room.
> >
> > Rubbish. I said that no function Hx can be defined that correctly simulates its input Px at all. You "rebutted" that by saying that you have got one. I don't believe that you have. I then ask you the basic questions about it that will help reveal whether or not you really have such a function, and you accuse me of changing the subject!
>
> On 9/14/2022 10:31 AM, Paul N wrote:
> > ... No function Hx can be defined that correctly simulates
> > its input Px at all.
> You asked me question about a different set of functions than the set
> specified by your original statement thus changed the subject.
>
> Every Hx that correctly simulates 1 to ∞ lines of the x86 machine
> language of Px correctly simulates Px.
>
> You have to make sure to use your words much more precisely.
> >> On 9/14/2022 10:31 AM, Paul N wrote:
> >>> ... No function Hx can be defined that correctly simulates
> >>> its input Px at all.
> >> When I provide an HH that does correctly simulate PP (structurally
> >> identical to Hx/Px) then your statement has been fully refuted, then you
> >> acknowledge that you were wrong and I am right and we move on to another
> >> point.
> >>
> >> Most everyone else here seems to use the despicable lying bastard
> >> approach of the strawman deception. I will no longer tolerate that.
> >
> > Your very words are "When I provide an HH that does correctly simulate PP (structurally identical to Hx/Px)". That's your argument, not a strawman.. But you haven't provided such a function,
> *How can you say that I haven't provided such a function when it is
> right here*
> *Function HH performs a correct recursive simulation of PP*
> https://liarparadox.org/2022_09_07.zip

On 9/15/2022 9:50 AM, Paul N wrote:
> On Thursday, September 15, 2022 at 3:04:42 PM UTC+1, olcott wrote:
>> On 9/15/2022 7:26 AM, Paul N wrote:
>>> On Wednesday, September 14, 2022 at 9:01:28 PM UTC+1, olcott wrote:
>>>> On 9/14/2022 2:47 PM, Paul N wrote:
>>>>> On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
>>>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>>>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
>>>>>>>> On 9/14/2022 5:58 AM, Paul N wrote:
>>>>>>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
>>>>>>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
>>>>>>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
>>>>>>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
>>>>>>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
>>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
>>>>>>>>>>>>>> simulated by Hx ever reaches its final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
>>>>>>>>>>>>>> axcually refutes either of the above two precise wordings.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You're not even correct when you say that the wording above is precise.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
>>>>>>>>>>>>>
>>>>>>>>>>>> *So you accept this as true*
>>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
>>>>>>>>>>>> that is correctly simulated by any Hx ever reaches its final state.
>>>>>>>>>>>
>>>>>>>>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
>>>>>>>>>>>
>>>>>>>>>> You said that the wording of the second one was imprecise and did not
>>>>>>>>>> seem to comment on the first one.
>>>>>>>>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
>>>>>>>>>>>> As I have told you many times "correctly simulated" means that each line
>>>>>>>>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
>>>>>>>>>>>> precisely corresponds to the sequence of lines specified by the x86
>>>>>>>>>>>> source-code of Px.
>>>>>>>>>>>
>>>>>>>>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
>>>>>>>>>> When I say something hundreds of times you forget that I ever said it?
>>>>>>>>>> I did not bother to post the x86 version because I have said many
>>>>>>>>>> hundreds of times that the simulating halt decider bases its halt status
>>>>>>>>>> decision on the execution trace of its correct simulation of the x86
>>>>>>>>>> source-code.
>>>>>>>>>>>
>>>>>>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
>>>>>>>>>> Every time that a simulating halt decider must abort the simulation of
>>>>>>>>>> its input to prevent the infinite simulation of this input conclusively
>>>>>>>>>> proves that this correctly simulated input cannot possibly reach its own
>>>>>>>>>> final state and halt.
>>>>>>>>>
>>>>>>>>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
>>>>>>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
>>>>>>>> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
>>>>>>>> correctly simulated by Hx.
>>>>>>>>
>>>>>>>> I am going to stop here and go over this point again and again until you
>>>>>>>> get it, before moving on to any other points.
>>>>>>>
>>>>>>> OK, we'll go through it again. You said that:
>>>>>>>
>>>>>>> [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
>>>>>>>
>>>>>>> conclusively proves that
>>>>>>>
>>>>>>> [ this correctly simulated input cannot possibly reach its own final state and halt. ]
>>>>>>>
>>>>>>> (brackets and emphasis added)
>>>>>>>
>>>>>>> So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
>>>>>>>
>>>>>>>> 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));
>>>>>>>> }
>>>>>>>> *When we examine the infinite set of Hx/Px pairs*
>>>>>>>>
>>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>>>
>>>>>>> What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
>>>>>>>
>>>>>>>> No function Hx can be defined such that its correct simulation of its
>>>>>>>> input Px would reach the final state of this simulated Px in any finite
>>>>>>>> number of steps.
>>>>>>>
>>>>>>> Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.
>>>>>> That is not true, I have such a function. Perhaps I greatly
>>>>>> overestimated your software engineering skills.
>>>>>
>>>>> My software engineering skills are in doubt because you claim to have produced something that has been proved impossible?
>>>>>
>>>>>> *Function HH performs a correct recursive simulation of PP*
>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>
>>>>> Come on then. Does PP halt when you run it? Does HH(PP, PP) give a result in finite time and, if so, is it zero or not?
>>>> You have changed the subject again. Normally when someone changes the
>>>> subject as the basis for their rebuttal I call this the strawman deception.
>>>> *straw man*
>>>> An intentionally misrepresented proposition that is set up because it is
>>>> easier to defeat than an opponent's real argument.
>>>> https://www.lexico.com/en/definition/straw_man
>>>> I will give you the benefit of the doubt this time and call it an honest
>>>> mistake. In the future when you provide any rebuttal it must directly
>>>> address the 100% exactly precise words that I have said with zero wiggle
>>>> room.
>>>
>>> Rubbish. I said that no function Hx can be defined that correctly simulates its input Px at all. You "rebutted" that by saying that you have got one. I don't believe that you have. I then ask you the basic questions about it that will help reveal whether or not you really have such a function, and you accuse me of changing the subject!
>>
>> On 9/14/2022 10:31 AM, Paul N wrote:
>>> ... No function Hx can be defined that correctly simulates
>>> its input Px at all.
>> You asked me question about a different set of functions than the set
>> specified by your original statement thus changed the subject.
>>
>> Every Hx that correctly simulates 1 to ∞ lines of the x86 machine
>> language of Px correctly simulates Px.
>>
>> You have to make sure to use your words much more precisely.
>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>> ... No function Hx can be defined that correctly simulates
>>>>> its input Px at all.
>>>> When I provide an HH that does correctly simulate PP (structurally
>>>> identical to Hx/Px) then your statement has been fully refuted, then you
>>>> acknowledge that you were wrong and I am right and we move on to another
>>>> point.
>>>>
>>>> Most everyone else here seems to use the despicable lying bastard
>>>> approach of the strawman deception. I will no longer tolerate that.
>>>
>>> Your very words are "When I provide an HH that does correctly simulate PP (structurally identical to Hx/Px)". That's your argument, not a strawman. But you haven't provided such a function,
>> *How can you say that I haven't provided such a function when it is
>> right here*
>> *Function HH performs a correct recursive simulation of PP*
>> https://liarparadox.org/2022_09_07.zip
>
> Several times now Richard has done a detailed analysis of your code and you have never given the slightest hint that you have bothered reading it. So I can't be bothered to mess about with zip files and the like. You're the one claiming HH performs a correct recursive simulation of PP. Answer two simple questions about it - does PP halt when you run it?

On Thursday, September 15, 2022 at 4:02:19 PM UTC+1, olcott wrote:
> On 9/15/2022 9:50 AM, Paul N wrote:
> > On Thursday, September 15, 2022 at 3:04:42 PM UTC+1, olcott wrote:
> >> On 9/15/2022 7:26 AM, Paul N wrote:
> >>> On Wednesday, September 14, 2022 at 9:01:28 PM UTC+1, olcott wrote:
> >>>> On 9/14/2022 2:47 PM, Paul N wrote:
> >>>>> On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
> >>>>>> On 9/14/2022 10:31 AM, Paul N wrote:
> >>>>>>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
> >>>>>>>> On 9/14/2022 5:58 AM, Paul N wrote:
> >>>>>>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
> >>>>>>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
> >>>>>>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
> >>>>>>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
> >>>>>>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
> >>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
> >>>>>>>>>>>>>> would be if they never aborted their simulation of this input.
> >>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
> >>>>>>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
> >>>>>>>>>>>>>> simulated by Hx ever reaches its final state.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
> >>>>>>>>>>>>>> axcually refutes either of the above two precise wordings.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> You're not even correct when you say that the wording above is precise.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> *So you accept this as true*
> >>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
> >>>>>>>>>>>> would be if they never aborted their simulation of this input.
> >>>>>>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
> >>>>>>>>>>>> that is correctly simulated by any Hx ever reaches its final state.
> >>>>>>>>>>>
> >>>>>>>>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
> >>>>>>>>>>>
> >>>>>>>>>> You said that the wording of the second one was imprecise and did not
> >>>>>>>>>> seem to comment on the first one.
> >>>>>>>>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
> >>>>>>>>>>>> As I have told you many times "correctly simulated" means that each line
> >>>>>>>>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
> >>>>>>>>>>>> precisely corresponds to the sequence of lines specified by the x86
> >>>>>>>>>>>> source-code of Px.
> >>>>>>>>>>>
> >>>>>>>>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
> >>>>>>>>>> When I say something hundreds of times you forget that I ever said it?
> >>>>>>>>>> I did not bother to post the x86 version because I have said many
> >>>>>>>>>> hundreds of times that the simulating halt decider bases its halt status
> >>>>>>>>>> decision on the execution trace of its correct simulation of the x86
> >>>>>>>>>> source-code.
> >>>>>>>>>>>
> >>>>>>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
> >>>>>>>>>> Every time that a simulating halt decider must abort the simulation of
> >>>>>>>>>> its input to prevent the infinite simulation of this input conclusively
> >>>>>>>>>> proves that this correctly simulated input cannot possibly reach its own
> >>>>>>>>>> final state and halt.
> >>>>>>>>>
> >>>>>>>>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
> >>>>>>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
> >>>>>>>> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
> >>>>>>>> correctly simulated by Hx.
> >>>>>>>>
> >>>>>>>> I am going to stop here and go over this point again and again until you
> >>>>>>>> get it, before moving on to any other points.
> >>>>>>>
> >>>>>>> OK, we'll go through it again. You said that:
> >>>>>>>
> >>>>>>> [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
> >>>>>>>
> >>>>>>> conclusively proves that
> >>>>>>>
> >>>>>>> [ this correctly simulated input cannot possibly reach its own final state and halt. ]
> >>>>>>>
> >>>>>>> (brackets and emphasis added)
> >>>>>>>
> >>>>>>> So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
> >>>>>>>
> >>>>>>>> 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));
> >>>>>>>> }
> >>>>>>>> *When we examine the infinite set of Hx/Px pairs*
> >>>>>>>>
> >>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
> >>>>>>>
> >>>>>>> What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
> >>>>>>>
> >>>>>>>> No function Hx can be defined such that its correct simulation of its
> >>>>>>>> input Px would reach the final state of this simulated Px in any finite
> >>>>>>>> number of steps.
> >>>>>>>
> >>>>>>> Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.
> >>>>>> That is not true, I have such a function. Perhaps I greatly
> >>>>>> overestimated your software engineering skills.
> >>>>>
> >>>>> My software engineering skills are in doubt because you claim to have produced something that has been proved impossible?
> >>>>>
> >>>>>> *Function HH performs a correct recursive simulation of PP*
> >>>>>> https://liarparadox.org/2022_09_07.zip
> >>>>>
> >>>>> Come on then. Does PP halt when you run it? Does HH(PP, PP) give a result in finite time and, if so, is it zero or not?
> >>>> You have changed the subject again. Normally when someone changes the
> >>>> subject as the basis for their rebuttal I call this the strawman deception.
> >>>> *straw man*
> >>>> An intentionally misrepresented proposition that is set up because it is
> >>>> easier to defeat than an opponent's real argument.
> >>>> https://www.lexico.com/en/definition/straw_man
> >>>> I will give you the benefit of the doubt this time and call it an honest
> >>>> mistake. In the future when you provide any rebuttal it must directly
> >>>> address the 100% exactly precise words that I have said with zero wiggle
> >>>> room.
> >>>
> >>> Rubbish. I said that no function Hx can be defined that correctly simulates its input Px at all. You "rebutted" that by saying that you have got one. I don't believe that you have. I then ask you the basic questions about it that will help reveal whether or not you really have such a function, and you accuse me of changing the subject!
> >>
> >> On 9/14/2022 10:31 AM, Paul N wrote:
> >>> ... No function Hx can be defined that correctly simulates
> >>> its input Px at all.
> >> You asked me question about a different set of functions than the set
> >> specified by your original statement thus changed the subject.
> >>
> >> Every Hx that correctly simulates 1 to ∞ lines of the x86 machine
> >> language of Px correctly simulates Px.
> >>
> >> You have to make sure to use your words much more precisely.
> >>>> On 9/14/2022 10:31 AM, Paul N wrote:
> >>>>> ... No function Hx can be defined that correctly simulates
> >>>>> its input Px at all.
> >>>> When I provide an HH that does correctly simulate PP (structurally
> >>>> identical to Hx/Px) then your statement has been fully refuted, then you
> >>>> acknowledge that you were wrong and I am right and we move on to another
> >>>> point.
> >>>>
> >>>> Most everyone else here seems to use the despicable lying bastard
> >>>> approach of the strawman deception. I will no longer tolerate that.
> >>>
> >>> Your very words are "When I provide an HH that does correctly simulate PP (structurally identical to Hx/Px)". That's your argument, not a strawman. But you haven't provided such a function,
> >> *How can you say that I haven't provided such a function when it is
> >> right here*
> >> *Function HH performs a correct recursive simulation of PP*
> >> https://liarparadox.org/2022_09_07.zip
> >
> > Several times now Richard has done a detailed analysis of your code and you have never given the slightest hint that you have bothered reading it. So I can't be bothered to mess about with zip files and the like. You're the one claiming HH performs a correct recursive simulation of PP. Answer two simple questions about it - does PP halt when you run it?
> Of the infinite set of Hx/Px pairs where Hx simulates 1 to ∞ machine
> language instructions of Px some halt and others do not halt yet all of
> them do a correct simulation pf Px.
>
> Once you acknowledge that whether or not HH halts it does do a correct
> simulation of HH then we can move on to the next point.
>
> I am requiring agreement on a point before moving on to another point
> because I am requiring that this be an honest dialogue rather than a
> fervent search for anything that can be disagreed with.
> > And does HH(PP, PP) give a result in finite time and, if so, is it zero or not? If you can't answer these questions about your own function I will assume you don't have the capability of writing a function that would disprove a well-established theorem.
> I will answer those points after you agree with the prior point.

On 9/15/2022 10:30 AM, Paul N wrote:
> On Thursday, September 15, 2022 at 4:02:19 PM UTC+1, olcott wrote:
>> On 9/15/2022 9:50 AM, Paul N wrote:
>>> On Thursday, September 15, 2022 at 3:04:42 PM UTC+1, olcott wrote:
>>>> On 9/15/2022 7:26 AM, Paul N wrote:
>>>>> On Wednesday, September 14, 2022 at 9:01:28 PM UTC+1, olcott wrote:
>>>>>> On 9/14/2022 2:47 PM, Paul N wrote:
>>>>>>> On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
>>>>>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>>>>>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
>>>>>>>>>> On 9/14/2022 5:58 AM, Paul N wrote:
>>>>>>>>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
>>>>>>>>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
>>>>>>>>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
>>>>>>>>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
>>>>>>>>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
>>>>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
>>>>>>>>>>>>>>>> simulated by Hx ever reaches its final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
>>>>>>>>>>>>>>>> axcually refutes either of the above two precise wordings.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You're not even correct when you say that the wording above is precise.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *So you accept this as true*
>>>>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
>>>>>>>>>>>>>> that is correctly simulated by any Hx ever reaches its final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
>>>>>>>>>>>>>
>>>>>>>>>>>> You said that the wording of the second one was imprecise and did not
>>>>>>>>>>>> seem to comment on the first one.
>>>>>>>>>>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
>>>>>>>>>>>>>> As I have told you many times "correctly simulated" means that each line
>>>>>>>>>>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
>>>>>>>>>>>>>> precisely corresponds to the sequence of lines specified by the x86
>>>>>>>>>>>>>> source-code of Px.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
>>>>>>>>>>>> When I say something hundreds of times you forget that I ever said it?
>>>>>>>>>>>> I did not bother to post the x86 version because I have said many
>>>>>>>>>>>> hundreds of times that the simulating halt decider bases its halt status
>>>>>>>>>>>> decision on the execution trace of its correct simulation of the x86
>>>>>>>>>>>> source-code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
>>>>>>>>>>>> Every time that a simulating halt decider must abort the simulation of
>>>>>>>>>>>> its input to prevent the infinite simulation of this input conclusively
>>>>>>>>>>>> proves that this correctly simulated input cannot possibly reach its own
>>>>>>>>>>>> final state and halt.
>>>>>>>>>>>
>>>>>>>>>>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
>>>>>>>>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
>>>>>>>>>> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
>>>>>>>>>> correctly simulated by Hx.
>>>>>>>>>>
>>>>>>>>>> I am going to stop here and go over this point again and again until you
>>>>>>>>>> get it, before moving on to any other points.
>>>>>>>>>
>>>>>>>>> OK, we'll go through it again. You said that:
>>>>>>>>>
>>>>>>>>> [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
>>>>>>>>>
>>>>>>>>> conclusively proves that
>>>>>>>>>
>>>>>>>>> [ this correctly simulated input cannot possibly reach its own final state and halt. ]
>>>>>>>>>
>>>>>>>>> (brackets and emphasis added)
>>>>>>>>>
>>>>>>>>> So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
>>>>>>>>>
>>>>>>>>>> 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));
>>>>>>>>>> }
>>>>>>>>>> *When we examine the infinite set of Hx/Px pairs*
>>>>>>>>>>
>>>>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>>>>>
>>>>>>>>> What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
>>>>>>>>>
>>>>>>>>>> No function Hx can be defined such that its correct simulation of its
>>>>>>>>>> input Px would reach the final state of this simulated Px in any finite
>>>>>>>>>> number of steps.
>>>>>>>>>
>>>>>>>>> Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.
>>>>>>>> That is not true, I have such a function. Perhaps I greatly
>>>>>>>> overestimated your software engineering skills.
>>>>>>>
>>>>>>> My software engineering skills are in doubt because you claim to have produced something that has been proved impossible?
>>>>>>>
>>>>>>>> *Function HH performs a correct recursive simulation of PP*
>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>
>>>>>>> Come on then. Does PP halt when you run it? Does HH(PP, PP) give a result in finite time and, if so, is it zero or not?
>>>>>> You have changed the subject again. Normally when someone changes the
>>>>>> subject as the basis for their rebuttal I call this the strawman deception.
>>>>>> *straw man*
>>>>>> An intentionally misrepresented proposition that is set up because it is
>>>>>> easier to defeat than an opponent's real argument.
>>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>> I will give you the benefit of the doubt this time and call it an honest
>>>>>> mistake. In the future when you provide any rebuttal it must directly
>>>>>> address the 100% exactly precise words that I have said with zero wiggle
>>>>>> room.
>>>>>
>>>>> Rubbish. I said that no function Hx can be defined that correctly simulates its input Px at all. You "rebutted" that by saying that you have got one. I don't believe that you have. I then ask you the basic questions about it that will help reveal whether or not you really have such a function, and you accuse me of changing the subject!
>>>>
>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>> ... No function Hx can be defined that correctly simulates
>>>>> its input Px at all.
>>>> You asked me question about a different set of functions than the set
>>>> specified by your original statement thus changed the subject.
>>>>
>>>> Every Hx that correctly simulates 1 to ∞ lines of the x86 machine
>>>> language of Px correctly simulates Px.
>>>>
>>>> You have to make sure to use your words much more precisely.
>>>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>>>> ... No function Hx can be defined that correctly simulates
>>>>>>> its input Px at all.
>>>>>> When I provide an HH that does correctly simulate PP (structurally
>>>>>> identical to Hx/Px) then your statement has been fully refuted, then you
>>>>>> acknowledge that you were wrong and I am right and we move on to another
>>>>>> point.
>>>>>>
>>>>>> Most everyone else here seems to use the despicable lying bastard
>>>>>> approach of the strawman deception. I will no longer tolerate that.
>>>>>
>>>>> Your very words are "When I provide an HH that does correctly simulate PP (structurally identical to Hx/Px)". That's your argument, not a strawman. But you haven't provided such a function,
>>>> *How can you say that I haven't provided such a function when it is
>>>> right here*
>>>> *Function HH performs a correct recursive simulation of PP*
>>>> https://liarparadox.org/2022_09_07.zip
>>>
>>> Several times now Richard has done a detailed analysis of your code and you have never given the slightest hint that you have bothered reading it. So I can't be bothered to mess about with zip files and the like. You're the one claiming HH performs a correct recursive simulation of PP. Answer two simple questions about it - does PP halt when you run it?
>> Of the infinite set of Hx/Px pairs where Hx simulates 1 to ∞ machine
>> language instructions of Px some halt and others do not halt yet all of
>> them do a correct simulation pf Px.
>>
>> Once you acknowledge that whether or not HH halts it does do a correct
>> simulation of HH then we can move on to the next point.
>>
>> I am requiring agreement on a point before moving on to another point
>> because I am requiring that this be an honest dialogue rather than a
>> fervent search for anything that can be disagreed with.
>>> And does HH(PP, PP) give a result in finite time and, if so, is it zero or not? If you can't answer these questions about your own function I will assume you don't have the capability of writing a function that would disprove a well-established theorem.
>> I will answer those points after you agree with the prior point.
>
> I don't think you're even getting the questions right!
>
> I have no idea whether HH does a correct simulation of HH, which is what you asked.
>
> I disagree that HH does a correct simulation of PP, this is exactly what we are arguing about.

On 9/15/2022 10:30 AM, Paul N wrote:
> On Thursday, September 15, 2022 at 4:02:19 PM UTC+1, olcott wrote:
>> On 9/15/2022 9:50 AM, Paul N wrote:
>>> On Thursday, September 15, 2022 at 3:04:42 PM UTC+1, olcott wrote:
>>>> On 9/15/2022 7:26 AM, Paul N wrote:
>>>>> On Wednesday, September 14, 2022 at 9:01:28 PM UTC+1, olcott wrote:
>>>>>> On 9/14/2022 2:47 PM, Paul N wrote:
>>>>>>> On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
>>>>>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>>>>>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
>>>>>>>>>> On 9/14/2022 5:58 AM, Paul N wrote:
>>>>>>>>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
>>>>>>>>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
>>>>>>>>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
>>>>>>>>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
>>>>>>>>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott wrote:
>>>>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is correctly
>>>>>>>>>>>>>>>> simulated by Hx ever reaches its final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All of your "rebuttals" depend oon the strawman deception and never
>>>>>>>>>>>>>>>> axcually refutes either of the above two precise wordings.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You're not even correct when you say that the wording above is precise.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The second one uses "Hx" in two different contexts, one to refer to a particular, accurate SHD and one to refer to any of an infinite set.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *So you accept this as true*
>>>>>>>>>>>>>> Simulating halt deciders always predict what the behavior of their input
>>>>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px pair
>>>>>>>>>>>>>> that is correctly simulated by any Hx ever reaches its final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Interesting that you assume I accept this, merely from the fact that I point out that the wording is unclear.
>>>>>>>>>>>>>
>>>>>>>>>>>> You said that the wording of the second one was imprecise and did not
>>>>>>>>>>>> seem to comment on the first one.
>>>>>>>>>>>>>>> You also use the term "correctly simulated" which in the light of your earlier comments is not precise. Normally the term "actual behaviour" means what something actually does, and so "correctly simulated" means that the simulator accurately reproduces this.
>>>>>>>>>>>>>> As I have told you many times "correctly simulated" means that each line
>>>>>>>>>>>>>> of 1 to N lines of the execution trace derived by the simulation of Px
>>>>>>>>>>>>>> precisely corresponds to the sequence of lines specified by the x86
>>>>>>>>>>>>>> source-code of Px.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are two flaws with this. Firstly, though a fairly minor point, is that the source code of Px is C, not x86. Presumably this could be fixed, but it does show you're thinking entirely straight.
>>>>>>>>>>>> When I say something hundreds of times you forget that I ever said it?
>>>>>>>>>>>> I did not bother to post the x86 version because I have said many
>>>>>>>>>>>> hundreds of times that the simulating halt decider bases its halt status
>>>>>>>>>>>> decision on the execution trace of its correct simulation of the x86
>>>>>>>>>>>> source-code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx as well. All the evidence so far is that you are getting the simulation of Hx wrong, generally because you assume that Hx gets stuck in a loop which know it does not do.
>>>>>>>>>>>> Every time that a simulating halt decider must abort the simulation of
>>>>>>>>>>>> its input to prevent the infinite simulation of this input conclusively
>>>>>>>>>>>> proves that this correctly simulated input cannot possibly reach its own
>>>>>>>>>>>> final state and halt.
>>>>>>>>>>>
>>>>>>>>>>> This seems a bit back to front. You are presumably assuming that the simulation would otherwise go on forever when you decide you "must" abort it.
>>>>>>>>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
>>>>>>>>>> pairs ever reaches its final state when 1 to ∞ steps of of Px have been
>>>>>>>>>> correctly simulated by Hx.
>>>>>>>>>>
>>>>>>>>>> I am going to stop here and go over this point again and again until you
>>>>>>>>>> get it, before moving on to any other points.
>>>>>>>>>
>>>>>>>>> OK, we'll go through it again. You said that:
>>>>>>>>>
>>>>>>>>> [ Every time that a simulating halt decider MUST abort the simulation of its input to prevent the infinite simulation of this input ]
>>>>>>>>>
>>>>>>>>> conclusively proves that
>>>>>>>>>
>>>>>>>>> [ this correctly simulated input cannot possibly reach its own final state and halt. ]
>>>>>>>>>
>>>>>>>>> (brackets and emphasis added)
>>>>>>>>>
>>>>>>>>> So if something happens (the first bracket) we have proved the input cannot reach its final state (the second bracket). What has to happen? Well, we have to show that the aborting is a necessity to prevent the simulation going on forever; that is to say, to prove that the simulated P is not going to reach a final state. So we have to have proved the conclusion to be able to use the argument at all! I believe this sort of thing is known as "begging the question".
>>>>>>>>>
>>>>>>>>>> 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));
>>>>>>>>>> }
>>>>>>>>>> *When we examine the infinite set of Hx/Px pairs*
>>>>>>>>>>
>>>>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>>>>>
>>>>>>>>> What is "existential quantification"? I presume it means more than "because I say something exists, it does exist".
>>>>>>>>>
>>>>>>>>>> No function Hx can be defined such that its correct simulation of its
>>>>>>>>>> input Px would reach the final state of this simulated Px in any finite
>>>>>>>>>> number of steps.
>>>>>>>>>
>>>>>>>>> Strangely enough I agree with this bit. No function Hx can be defined that correctly simulates its input Px at all.
>>>>>>>> That is not true, I have such a function. Perhaps I greatly
>>>>>>>> overestimated your software engineering skills.
>>>>>>>
>>>>>>> My software engineering skills are in doubt because you claim to have produced something that has been proved impossible?
>>>>>>>
>>>>>>>> *Function HH performs a correct recursive simulation of PP*
>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>
>>>>>>> Come on then. Does PP halt when you run it? Does HH(PP, PP) give a result in finite time and, if so, is it zero or not?
>>>>>> You have changed the subject again. Normally when someone changes the
>>>>>> subject as the basis for their rebuttal I call this the strawman deception.
>>>>>> *straw man*
>>>>>> An intentionally misrepresented proposition that is set up because it is
>>>>>> easier to defeat than an opponent's real argument.
>>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>> I will give you the benefit of the doubt this time and call it an honest
>>>>>> mistake. In the future when you provide any rebuttal it must directly
>>>>>> address the 100% exactly precise words that I have said with zero wiggle
>>>>>> room.
>>>>>
>>>>> Rubbish. I said that no function Hx can be defined that correctly simulates its input Px at all. You "rebutted" that by saying that you have got one. I don't believe that you have. I then ask you the basic questions about it that will help reveal whether or not you really have such a function, and you accuse me of changing the subject!
>>>>
>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>> ... No function Hx can be defined that correctly simulates
>>>>> its input Px at all.
>>>> You asked me question about a different set of functions than the set
>>>> specified by your original statement thus changed the subject.
>>>>
>>>> Every Hx that correctly simulates 1 to ∞ lines of the x86 machine
>>>> language of Px correctly simulates Px.
>>>>
>>>> You have to make sure to use your words much more precisely.
>>>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>>>> ... No function Hx can be defined that correctly simulates
>>>>>>> its input Px at all.
>>>>>> When I provide an HH that does correctly simulate PP (structurally
>>>>>> identical to Hx/Px) then your statement has been fully refuted, then you
>>>>>> acknowledge that you were wrong and I am right and we move on to another
>>>>>> point.
>>>>>>
>>>>>> Most everyone else here seems to use the despicable lying bastard
>>>>>> approach of the strawman deception. I will no longer tolerate that.
>>>>>
>>>>> Your very words are "When I provide an HH that does correctly simulate PP (structurally identical to Hx/Px)". That's your argument, not a strawman. But you haven't provided such a function,
>>>> *How can you say that I haven't provided such a function when it is
>>>> right here*
>>>> *Function HH performs a correct recursive simulation of PP*
>>>> https://liarparadox.org/2022_09_07.zip
>>>
>>> Several times now Richard has done a detailed analysis of your code and you have never given the slightest hint that you have bothered reading it. So I can't be bothered to mess about with zip files and the like. You're the one claiming HH performs a correct recursive simulation of PP. Answer two simple questions about it - does PP halt when you run it?
>> Of the infinite set of Hx/Px pairs where Hx simulates 1 to ∞ machine
>> language instructions of Px some halt and others do not halt yet all of
>> them do a correct simulation pf Px.
>>
>> Once you acknowledge that whether or not HH halts it does do a correct
>> simulation of HH then we can move on to the next point.
>>
>> I am requiring agreement on a point before moving on to another point
>> because I am requiring that this be an honest dialogue rather than a
>> fervent search for anything that can be disagreed with.
>>> And does HH(PP, PP) give a result in finite time and, if so, is it zero or not? If you can't answer these questions about your own function I will assume you don't have the capability of writing a function that would disprove a well-established theorem.
>> I will answer those points after you agree with the prior point.
>
> I don't think you're even getting the questions right!
>
> I have no idea whether HH does a correct simulation of HH, which is what you asked.
>
> I disagree that HH does a correct simulation of PP, this is exactly what we are arguing about.

On 9/15/22 10:04 AM, olcott wrote:
> On 9/15/2022 7:26 AM, Paul N wrote:
>> On Wednesday, September 14, 2022 at 9:01:28 PM UTC+1, olcott wrote:
>>> On 9/14/2022 2:47 PM, Paul N wrote:
>>>> On Wednesday, September 14, 2022 at 4:45:14 PM UTC+1, olcott wrote:
>>>>> On 9/14/2022 10:31 AM, Paul N wrote:
>>>>>> On Wednesday, September 14, 2022 at 2:20:10 PM UTC+1, olcott wrote:
>>>>>>> On 9/14/2022 5:58 AM, Paul N wrote:
>>>>>>>> On Tuesday, September 13, 2022 at 4:06:23 PM UTC+1, olcott wrote:
>>>>>>>>> On 9/13/2022 9:43 AM, Paul N wrote:
>>>>>>>>>> On Tuesday, September 13, 2022 at 2:48:05 PM UTC+1, olcott wrote:
>>>>>>>>>>> On 9/13/2022 6:34 AM, Paul N wrote:
>>>>>>>>>>>> On Tuesday, September 13, 2022 at 12:39:20 AM UTC+1, olcott
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>>> Simulating halt deciders always predict what the behavior
>>>>>>>>>>>>> of their input
>>>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>>>> *THIS IS CORRECT AND TRUE THUS NOT AN ERROR*
>>>>>>>>>>>>> Hx correctly predicts no Px of any Hx/Px pair that is
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated by Hx ever reaches its final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All of your "rebuttals" depend oon the strawman deception
>>>>>>>>>>>>> and never
>>>>>>>>>>>>> axcually refutes either of the above two precise wordings.
>>>>>>>>>>>>
>>>>>>>>>>>> You're not even correct when you say that the wording above
>>>>>>>>>>>> is precise.
>>>>>>>>>>>>
>>>>>>>>>>>> The second one uses "Hx" in two different contexts, one to
>>>>>>>>>>>> refer to a particular, accurate SHD and one to refer to any
>>>>>>>>>>>> of an infinite set.
>>>>>>>>>>>>
>>>>>>>>>>> *So you accept this as true*
>>>>>>>>>>> Simulating halt deciders always predict what the behavior of
>>>>>>>>>>> their input
>>>>>>>>>>> would be if they never aborted their simulation of this input.
>>>>>>>>>>> Each Hx that returns 0 correctly predicts no Px of any Hx/Px
>>>>>>>>>>> pair
>>>>>>>>>>> that is correctly simulated by any Hx ever reaches its final
>>>>>>>>>>> state.
>>>>>>>>>>
>>>>>>>>>> Interesting that you assume I accept this, merely from the
>>>>>>>>>> fact that I point out that the wording is unclear.
>>>>>>>>>>
>>>>>>>>> You said that the wording of the second one was imprecise and
>>>>>>>>> did not
>>>>>>>>> seem to comment on the first one.
>>>>>>>>>>>> You also use the term "correctly simulated" which in the
>>>>>>>>>>>> light of your earlier comments is not precise. Normally the
>>>>>>>>>>>> term "actual behaviour" means what something actually does,
>>>>>>>>>>>> and so "correctly simulated" means that the simulator
>>>>>>>>>>>> accurately reproduces this.
>>>>>>>>>>> As I have told you many times "correctly simulated" means
>>>>>>>>>>> that each line
>>>>>>>>>>> of 1 to N lines of the execution trace derived by the
>>>>>>>>>>> simulation of Px
>>>>>>>>>>> precisely corresponds to the sequence of lines specified by
>>>>>>>>>>> the x86
>>>>>>>>>>> source-code of Px.
>>>>>>>>>>
>>>>>>>>>> There are two flaws with this. Firstly, though a fairly minor
>>>>>>>>>> point, is that the source code of Px is C, not x86. Presumably
>>>>>>>>>> this could be fixed, but it does show you're thinking entirely
>>>>>>>>>> straight.
>>>>>>>>> When I say something hundreds of times you forget that I ever
>>>>>>>>> said it?
>>>>>>>>> I did not bother to post the x86 version because I have said many
>>>>>>>>> hundreds of times that the simulating halt decider bases its
>>>>>>>>> halt status
>>>>>>>>> decision on the execution trace of its correct simulation of
>>>>>>>>> the x86
>>>>>>>>> source-code.
>>>>>>>>>>
>>>>>>>>>> Secondly, since Px calls Hx you need to accurately simulate Hx
>>>>>>>>>> as well. All the evidence so far is that you are getting the
>>>>>>>>>> simulation of Hx wrong, generally because you assume that Hx
>>>>>>>>>> gets stuck in a loop which know it does not do.
>>>>>>>>> Every time that a simulating halt decider must abort the
>>>>>>>>> simulation of
>>>>>>>>> its input to prevent the infinite simulation of this input
>>>>>>>>> conclusively
>>>>>>>>> proves that this correctly simulated input cannot possibly
>>>>>>>>> reach its own
>>>>>>>>> final state and halt.
>>>>>>>>
>>>>>>>> This seems a bit back to front. You are presumably assuming that
>>>>>>>> the simulation would otherwise go on forever when you decide you
>>>>>>>> "must" abort it.
>>>>>>> No not at all. I have proven that no Px of the infinite set of Hx/Px
>>>>>>> pairs ever reaches its final state when 1 to ∞ steps of of Px
>>>>>>> have been
>>>>>>> correctly simulated by Hx.
>>>>>>>
>>>>>>> I am going to stop here and go over this point again and again
>>>>>>> until you
>>>>>>> get it, before moving on to any other points.
>>>>>>
>>>>>> OK, we'll go through it again. You said that:
>>>>>>
>>>>>> [ Every time that a simulating halt decider MUST abort the
>>>>>> simulation of its input to prevent the infinite simulation of this
>>>>>> input ]
>>>>>>
>>>>>> conclusively proves that
>>>>>>
>>>>>> [ this correctly simulated input cannot possibly reach its own
>>>>>> final state and halt. ]
>>>>>>
>>>>>> (brackets and emphasis added)
>>>>>>
>>>>>> So if something happens (the first bracket) we have proved the
>>>>>> input cannot reach its final state (the second bracket). What has
>>>>>> to happen? Well, we have to show that the aborting is a necessity
>>>>>> to prevent the simulation going on forever; that is to say, to
>>>>>> prove that the simulated P is not going to reach a final state. So
>>>>>> we have to have proved the conclusion to be able to use the
>>>>>> argument at all! I believe this sort of thing is known as "begging
>>>>>> the question".
>>>>>>
>>>>>>> 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));
>>>>>>> }
>>>>>>> *When we examine the infinite set of Hx/Px pairs*
>>>>>>>
>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>>
>>>>>> What is "existential quantification"? I presume it means more than
>>>>>> "because I say something exists, it does exist".
>>>>>>
>>>>>>> No function Hx can be defined such that its correct simulation of
>>>>>>> its
>>>>>>> input Px would reach the final state of this simulated Px in any
>>>>>>> finite
>>>>>>> number of steps.
>>>>>>
>>>>>> Strangely enough I agree with this bit. No function Hx can be
>>>>>> defined that correctly simulates its input Px at all.
>>>>> That is not true, I have such a function. Perhaps I greatly
>>>>> overestimated your software engineering skills.
>>>>
>>>> My software engineering skills are in doubt because you claim to
>>>> have produced something that has been proved impossible?
>>>>
>>>>> *Function HH performs a correct recursive simulation of PP*
>>>>> https://liarparadox.org/2022_09_07.zip
>>>>
>>>> Come on then. Does PP halt when you run it? Does HH(PP, PP) give a
>>>> result in finite time and, if so, is it zero or not?
>>> You have changed the subject again. Normally when someone changes the
>>> subject as the basis for their rebuttal I call this the strawman
>>> deception.
>>> *straw man*
>>> An intentionally misrepresented proposition that is set up because it is
>>> easier to defeat than an opponent's real argument.
>>> https://www.lexico.com/en/definition/straw_man
>>> I will give you the benefit of the doubt this time and call it an honest
>>> mistake. In the future when you provide any rebuttal it must directly
>>> address the 100% exactly precise words that I have said with zero wiggle
>>> room.
>>
>> Rubbish. I said that no function Hx can be defined that correctly
>> simulates its input Px at all. You "rebutted" that by saying that you
>> have got one. I don't believe that you have. I then ask you the basic
>> questions about it that will help reveal whether or not you really
>> have such a function, and you accuse me of changing the subject!
>
> On 9/14/2022 10:31 AM, Paul N wrote:
> > ... No function Hx can be defined that correctly simulates
> > its input Px at all.
>
> You asked me question about a different set of functions than the set
> specified by your original statement thus changed the subject.
>
> Every Hx that correctly simulates 1 to ∞ lines of the x86 machine
> language of Px correctly simulates Px.
>
> You have to make sure to use your words much more precisely.