On 7/23/2022 11:47 AM, Skep Dick wrote:
> On Saturday, 23 July 2022 at 17:30:12 UTC+2, olcott wrote:
>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>> On 7/23/22 10:27 AM, olcott wrote:
>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>> THIS IS PROVABLY TRUE
>>>>>>> I am only referring to the correctly simulated input to H(P,P) that
>>>>>>> never halts no matter what. The directly executed P(P) specifies an
>>>>>>> entirely different sequence of instructions.
>>>>>>
>>>>>> You realise this is essentially the same as saying "Reality does not
>>>>>> agree with my predictions, but my predictions are nevertheless
>>>>>> correct" ?
>>>>>
>>>>>
>>>>> In programming language theory, semantics is the field concerned with
>>>>> the rigorous mathematical study of the meaning of programming
>>>>> languages.[1] It does so by evaluating the meaning of syntactically
>>>>> valid strings defined by a specific programming language, showing the
>>>>> computation involved. In such a case that the evaluation would be of
>>>>> syntactically invalid strings, the result would be non-computation.
>>>>> Semantics describes the processes a computer follows when executing a
>>>>> program in that specific language.
>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>
>>>>> The code proves that the correctly simulated input would never reach
>>>>> its "return" instruction.
>>>>>
>>>>
>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>> The correct execution trace of the correctly simulated input to H(P,P)
>>>> conclusively proves that the simulated P cannot possibly reach its
>>>> "return" instruction.
>>>>
>>>> Humans having sufficient technical knowledge can see this and H can
>>>> see this. To say that I am incorrect based on not having having
>>>> sufficient technical knowledge is both incorrect and rude.
>>>>
>>>
>>> No, because your proof isn't correct, even if you think it is.
>>>
>> That you say that I am wrong on the basis that you do not know that the
>> semantics of the x86 language proves that I am correct causes me to
>> ignore almost all of your posts.
>
> Semantics don't prove anything.
>

*This is how we verify that the simulation is correct*
In programming language theory, semantics is the field concerned with
the rigorous mathematical study of the meaning of programming
languages.[1] It does so by evaluating the meaning of syntactically
valid strings defined by a specific programming language, showing the
computation involved. In such a case that the evaluation would be of
syntactically invalid strings, the result would be non-computation.
Semantics describes the processes a computer follows when executing a
program in that specific language.
https://en.wikipedia.org/wiki/Semantics_(computer_science)

We verify that the execution trace of the simulated input has the
behavior that the simulated x86 source-code specifies, line-by-line.

--
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 Saturday, 23 July 2022 at 18:49:28 UTC+2, olcott wrote:
> On 7/23/2022 11:47 AM, Skep Dick wrote:
> > On Saturday, 23 July 2022 at 17:30:12 UTC+2, olcott wrote:
> >> On 7/23/2022 10:27 AM, Richard Damon wrote:
> >>> On 7/23/22 10:27 AM, olcott wrote:
> >>>> On 7/23/2022 8:30 AM, olcott wrote:
> >>>>> On 7/23/2022 8:11 AM, Paul N wrote:
> >>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
> >>>>>>> THIS IS PROVABLY TRUE
> >>>>>>> I am only referring to the correctly simulated input to H(P,P) that
> >>>>>>> never halts no matter what. The directly executed P(P) specifies an
> >>>>>>> entirely different sequence of instructions.
> >>>>>>
> >>>>>> You realise this is essentially the same as saying "Reality does not
> >>>>>> agree with my predictions, but my predictions are nevertheless
> >>>>>> correct" ?
> >>>>>
> >>>>>
> >>>>> In programming language theory, semantics is the field concerned with
> >>>>> the rigorous mathematical study of the meaning of programming
> >>>>> languages.[1] It does so by evaluating the meaning of syntactically
> >>>>> valid strings defined by a specific programming language, showing the
> >>>>> computation involved. In such a case that the evaluation would be of
> >>>>> syntactically invalid strings, the result would be non-computation.
> >>>>> Semantics describes the processes a computer follows when executing a
> >>>>> program in that specific language.
> >>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
> >>>>>
> >>>>> The code proves that the correctly simulated input would never reach
> >>>>> its "return" instruction.
> >>>>>
> >>>>
> >>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
> >>>> The correct execution trace of the correctly simulated input to H(P,P)
> >>>> conclusively proves that the simulated P cannot possibly reach its
> >>>> "return" instruction.
> >>>>
> >>>> Humans having sufficient technical knowledge can see this and H can
> >>>> see this. To say that I am incorrect based on not having having
> >>>> sufficient technical knowledge is both incorrect and rude.
> >>>>
> >>>
> >>> No, because your proof isn't correct, even if you think it is.
> >>>
> >> That you say that I am wrong on the basis that you do not know that the
> >> semantics of the x86 language proves that I am correct causes me to
> >> ignore almost all of your posts.
> >
> > Semantics don't prove anything.
> >
> *This is how we verify that the simulation is correct*
> In programming language theory, semantics is the field concerned with
> the rigorous mathematical study of the meaning of programming
> languages.[1] It does so by evaluating the meaning of syntactically
> valid strings defined by a specific programming language, showing the
> computation involved. In such a case that the evaluation would be of
> syntactically invalid strings, the result would be non-computation.
> Semantics describes the processes a computer follows when executing a
> program in that specific language.
> https://en.wikipedia.org/wiki/Semantics_(computer_science)
> We verify that the execution trace of the simulated input has the
> behavior that the simulated x86 source-code specifies, line-by-line.

The execution trace doesn't matter. That's implementation detail.

The semantic property of the function which we are interested in is the fact that it doesn't halt.

A function which does halt is not the same thing as a function which halts.

This is a semantic fact.

On 7/23/2022 12:12 PM, Skep Dick wrote:
> On Saturday, 23 July 2022 at 18:49:28 UTC+2, olcott wrote:
>> On 7/23/2022 11:47 AM, Skep Dick wrote:
>>> On Saturday, 23 July 2022 at 17:30:12 UTC+2, olcott wrote:
>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>> I am only referring to the correctly simulated input to H(P,P) that
>>>>>>>>> never halts no matter what. The directly executed P(P) specifies an
>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>
>>>>>>>> You realise this is essentially the same as saying "Reality does not
>>>>>>>> agree with my predictions, but my predictions are nevertheless
>>>>>>>> correct" ?
>>>>>>>
>>>>>>>
>>>>>>> In programming language theory, semantics is the field concerned with
>>>>>>> the rigorous mathematical study of the meaning of programming
>>>>>>> languages.[1] It does so by evaluating the meaning of syntactically
>>>>>>> valid strings defined by a specific programming language, showing the
>>>>>>> computation involved. In such a case that the evaluation would be of
>>>>>>> syntactically invalid strings, the result would be non-computation.
>>>>>>> Semantics describes the processes a computer follows when executing a
>>>>>>> program in that specific language.
>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>
>>>>>>> The code proves that the correctly simulated input would never reach
>>>>>>> its "return" instruction.
>>>>>>>
>>>>>>
>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>> The correct execution trace of the correctly simulated input to H(P,P)
>>>>>> conclusively proves that the simulated P cannot possibly reach its
>>>>>> "return" instruction.
>>>>>>
>>>>>> Humans having sufficient technical knowledge can see this and H can
>>>>>> see this. To say that I am incorrect based on not having having
>>>>>> sufficient technical knowledge is both incorrect and rude.
>>>>>>
>>>>>
>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>
>>>> That you say that I am wrong on the basis that you do not know that the
>>>> semantics of the x86 language proves that I am correct causes me to
>>>> ignore almost all of your posts.
>>>
>>> Semantics don't prove anything.
>>>
>> *This is how we verify that the simulation is correct*
>> In programming language theory, semantics is the field concerned with
>> the rigorous mathematical study of the meaning of programming
>> languages.[1] It does so by evaluating the meaning of syntactically
>> valid strings defined by a specific programming language, showing the
>> computation involved. In such a case that the evaluation would be of
>> syntactically invalid strings, the result would be non-computation.
>> Semantics describes the processes a computer follows when executing a
>> program in that specific language.
>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>> We verify that the execution trace of the simulated input has the
>> behavior that the simulated x86 source-code specifies, line-by-line.
>
> The execution trace doesn't matter. That's implementation detail.
>
> The semantic property of the function which we are interested in is the fact that it doesn't halt.
>
> A function which does halt is not the same thing as a function which halts.
>
> This is a semantic fact.

The execution trace of the behavior of the input to H(P,P) that H
correctly simulates is the ultimate measure of whether or not this input
halts. That you don't understand this key point would seem to make
further dialogue with you fruitless.

--
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 Saturday, 23 July 2022 at 19:18:24 UTC+2, olcott wrote:
> On 7/23/2022 12:12 PM, Skep Dick wrote:
> > On Saturday, 23 July 2022 at 18:49:28 UTC+2, olcott wrote:
> >> On 7/23/2022 11:47 AM, Skep Dick wrote:
> >>> On Saturday, 23 July 2022 at 17:30:12 UTC+2, olcott wrote:
> >>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
> >>>>> On 7/23/22 10:27 AM, olcott wrote:
> >>>>>> On 7/23/2022 8:30 AM, olcott wrote:
> >>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
> >>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
> >>>>>>>>> THIS IS PROVABLY TRUE
> >>>>>>>>> I am only referring to the correctly simulated input to H(P,P) that
> >>>>>>>>> never halts no matter what. The directly executed P(P) specifies an
> >>>>>>>>> entirely different sequence of instructions.
> >>>>>>>>
> >>>>>>>> You realise this is essentially the same as saying "Reality does not
> >>>>>>>> agree with my predictions, but my predictions are nevertheless
> >>>>>>>> correct" ?
> >>>>>>>
> >>>>>>>
> >>>>>>> In programming language theory, semantics is the field concerned with
> >>>>>>> the rigorous mathematical study of the meaning of programming
> >>>>>>> languages.[1] It does so by evaluating the meaning of syntactically
> >>>>>>> valid strings defined by a specific programming language, showing the
> >>>>>>> computation involved. In such a case that the evaluation would be of
> >>>>>>> syntactically invalid strings, the result would be non-computation.
> >>>>>>> Semantics describes the processes a computer follows when executing a
> >>>>>>> program in that specific language.
> >>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
> >>>>>>>
> >>>>>>> The code proves that the correctly simulated input would never reach
> >>>>>>> its "return" instruction.
> >>>>>>>
> >>>>>>
> >>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
> >>>>>> The correct execution trace of the correctly simulated input to H(P,P)
> >>>>>> conclusively proves that the simulated P cannot possibly reach its
> >>>>>> "return" instruction.
> >>>>>>
> >>>>>> Humans having sufficient technical knowledge can see this and H can
> >>>>>> see this. To say that I am incorrect based on not having having
> >>>>>> sufficient technical knowledge is both incorrect and rude.
> >>>>>>
> >>>>>
> >>>>> No, because your proof isn't correct, even if you think it is.
> >>>>>
> >>>> That you say that I am wrong on the basis that you do not know that the
> >>>> semantics of the x86 language proves that I am correct causes me to
> >>>> ignore almost all of your posts.
> >>>
> >>> Semantics don't prove anything.
> >>>
> >> *This is how we verify that the simulation is correct*
> >> In programming language theory, semantics is the field concerned with
> >> the rigorous mathematical study of the meaning of programming
> >> languages.[1] It does so by evaluating the meaning of syntactically
> >> valid strings defined by a specific programming language, showing the
> >> computation involved. In such a case that the evaluation would be of
> >> syntactically invalid strings, the result would be non-computation.
> >> Semantics describes the processes a computer follows when executing a
> >> program in that specific language.
> >> https://en.wikipedia.org/wiki/Semantics_(computer_science)
> >> We verify that the execution trace of the simulated input has the
> >> behavior that the simulated x86 source-code specifies, line-by-line.
> >
> > The execution trace doesn't matter. That's implementation detail.
> >
> > The semantic property of the function which we are interested in is the fact that it doesn't halt.
> >
> > A function which does halt is not the same thing as a function which halts.
> >
> > This is a semantic fact.
> The execution trace of the behavior of the input to H(P,P) that H
> correctly simulates is the ultimate measure of whether or not this input
> halts. That you don't understand this key point would seem to make
> further dialogue with you fruitless.

That you don't understand the problem is what has been making dialogue fruitless all along.

The game is called "Will Skepdick call Pete Olcott an idiot?"

If you guess that I'll call you an idiiot then I won't.
If you guess that I won't call you an idiot then I will.

Go ahead and "correctly" simulate the "ultimate measure" of whether I am going to call you an idiot or not.

On 7/23/22 12:37 PM, olcott wrote:
> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>
>> On 7/23/22 12:05 PM, olcott wrote:
>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>> I am only referring to the correctly simulated input to H(P,P)
>>>>>>>>>> that
>>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>>> specifies an
>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>
>>>>>>>>> You realise this is essentially the same as saying "Reality
>>>>>>>>> does not agree with my predictions, but my predictions are
>>>>>>>>> nevertheless correct" ?
>>>>>>>>
>>>>>>>>
>>>>>>>> In programming language theory, semantics is the field concerned
>>>>>>>> with the rigorous mathematical study of the meaning of
>>>>>>>> programming languages.[1] It does so by evaluating the meaning
>>>>>>>> of syntactically valid strings defined by a specific programming
>>>>>>>> language, showing the computation involved. In such a case that
>>>>>>>> the evaluation would be of syntactically invalid strings, the
>>>>>>>> result would be non-computation. Semantics describes the
>>>>>>>> processes a computer follows when executing a program in that
>>>>>>>> specific language.
>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>
>>>>>>>> The code proves that the correctly simulated input would never
>>>>>>>> reach its "return" instruction.
>>>>>>>>
>>>>>>>
>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>> The correct execution trace of the correctly simulated input to
>>>>>>> H(P,P) conclusively proves that the simulated P cannot possibly
>>>>>>> reach its "return" instruction.
>>>>>>>
>>>>>>> Humans having sufficient technical knowledge can see this and H
>>>>>>> can see this. To say that I am incorrect based on not having
>>>>>>> having sufficient technical knowledge is both incorrect and rude.
>>>>>>>
>>>>>>
>>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>>
>>>>> That you say that I am wrong on the basis that you do not know that
>>>>> the semantics of the x86 language proves that I am correct causes
>>>>> me to ignore almost all of your posts.
>>>>>
>>>>
>>>> I have pointed out errors in the proofs that you just won't make an
>>>> effort to rebut,
>>>
>>> That is another thing that you do.
>>> I make one point and then you change the subject as your rebuttal.
>>
>> How is pointing out an error in your proof a change of subject?
>>
>
> I claim that X is true and your rebuttal is that you believe that Y is
> false.

No, you claim X is true and try to give a proof, showing that because of
a, b, and c, X must be true.

I point out that c isn't actually a true statement.

That is a rebuttal.

You answer has always been to just restate a, b, and c, and never being
able to give a source of ANYONE who supports you that the point I ask
about it actually true.

Being unable to cite a source for ANY of your "rules" that you start
from says you don't actually HAVE a proof, just a rhetorical argument. I
think the issue is you just don't know what an actual proof should look
like. You use a lot of words without understanding, which shows your
ignorance.

>
> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>
> I am only referring to the fact that the semantics of the x86 language
> conclusively proves that the correctly simulated input to H(P,P) by H
> cannot possibly ever reach the "return" instruction of P.

Nope, doesn't show it. More of your made up "proof".

Note, the key point of your arguement, and the point you get wrong,
actually has NOTHING to do with the x86 language.

Simple point of observation, change you target processor for you
compiler and replace the emulatior with an emulator for that processor,
(and the appropriate references in your decider) and the argument would
be EXACTLY the same, so you aren't using anything about the x86 itself

>
> The only relevant rebuttal is a step-by-step proof showing line-by-line
> of the source-code of P exactly how H diverges from its correct x86
> emulation of its input.
>

First, you have it backwards. The PROOF needs to be the step by step
proof, a rebutal only needs to point out ONE error in the proof.

And I HAVE pointed out the error but you don't look at it.

You claim a rule, often numbered (3) that says that non-halting is
proven by there not being a conditional instruction inside the C
function P to end the loop. There is no such rule, not one that allows
for H to be a decider that can decide to abort its simulation.

Until you can actually PROVE your rules, or at least cite a source that
vouches for it, your proof has become undone, based on having an
unproven (and untrue) premise. No amount of just claiming it must be
true removes that defect from your proof. ANY premise of a proof that
have been challenged must be proven or the proof falls apart.

The divergence in the correct x86 behavior is that the correct x86
behavior of a call to H will be followed by the actual behavior of the
function H. You code errs in that in build on logic that INCORRECTLY
presumes that H will just unconditionally simulate its input (so your
rule 3 is correct) when that isn't the actual behavior of H.

The x86 behavior that H has seen does NOT provide any proof for your
claim, so by claiming it does just points out your lie.

ALL the x86 behavior that H has looked at proves is that the function
P(P) calls H(P,P) which proves NOTHING about halting.

Only by looking at the ACTUAL behavior of H(P,P) can you say anything
about this functions behavior.

Since H never actually looks at that behavior, it is just a blatant lie
to say that the behavior it has seen proves anything about the final
behavior of P(P).

> This is your last chance before I won't even glance at your messages for
> a long time.
>

And the world will see me tearing your "logic" tpo pieces and asking for
a rebuttal, witht he comment that no rebuttal implies you don't have
one, and will see that you don't actually have a rebuttal.

If that is what you want, go ahead, and seal your doom. Might not have
that much affect long term since you have pretty much already killed any
hope making a believable story and the simplest searches will show
everyone pointing out your errors and you ignoring them, showing you
don't understand what you are talking about.

Initially, I thought that maybe you had some interesting ideas to
discuss about the nature of truth, but you have basically proven that
you don't understand even the most simple basics of what Truth actually is.

The fact that you think that unproven claims and twisted word trump the
actual behavior of machines shows what you think of real Truth.

On 7/23/2022 12:43 PM, Richard Damon wrote:
> On 7/23/22 12:37 PM, olcott wrote:
>> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>>
>>> On 7/23/22 12:05 PM, olcott wrote:
>>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>>> I am only referring to the correctly simulated input to
>>>>>>>>>>> H(P,P) that
>>>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>>>> specifies an
>>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>>
>>>>>>>>>> You realise this is essentially the same as saying "Reality
>>>>>>>>>> does not agree with my predictions, but my predictions are
>>>>>>>>>> nevertheless correct" ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In programming language theory, semantics is the field
>>>>>>>>> concerned with the rigorous mathematical study of the meaning
>>>>>>>>> of programming languages.[1] It does so by evaluating the
>>>>>>>>> meaning of syntactically valid strings defined by a specific
>>>>>>>>> programming language, showing the computation involved. In such
>>>>>>>>> a case that the evaluation would be of syntactically invalid
>>>>>>>>> strings, the result would be non-computation. Semantics
>>>>>>>>> describes the processes a computer follows when executing a
>>>>>>>>> program in that specific language.
>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>
>>>>>>>>> The code proves that the correctly simulated input would never
>>>>>>>>> reach its "return" instruction.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>>> The correct execution trace of the correctly simulated input to
>>>>>>>> H(P,P) conclusively proves that the simulated P cannot possibly
>>>>>>>> reach its "return" instruction.
>>>>>>>>
>>>>>>>> Humans having sufficient technical knowledge can see this and H
>>>>>>>> can see this. To say that I am incorrect based on not having
>>>>>>>> having sufficient technical knowledge is both incorrect and rude.
>>>>>>>>
>>>>>>>
>>>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>>>
>>>>>> That you say that I am wrong on the basis that you do not know
>>>>>> that the semantics of the x86 language proves that I am correct
>>>>>> causes me to ignore almost all of your posts.
>>>>>>
>>>>>
>>>>> I have pointed out errors in the proofs that you just won't make an
>>>>> effort to rebut,
>>>>
>>>> That is another thing that you do.
>>>> I make one point and then you change the subject as your rebuttal.
>>>
>>> How is pointing out an error in your proof a change of subject?
>>>
>>
>> I claim that X is true and your rebuttal is that you believe that Y is
>> false.
>
> No, you claim X is true and try to give a proof, showing that because of
> a, b, and c, X must be true.
>
> I point out that c isn't actually a true statement.
>
> That is a rebuttal.
>
> You answer has always been to just restate a, b, and c, and never being
> able to give a source of ANYONE who supports you that the point I ask
> about it actually true.
>
> Being unable to cite a source for ANY of your "rules" that you start
> from says you don't actually HAVE a proof, just a rhetorical argument. I
> think the issue is you just don't know what an actual proof should look
> like. You use a lot of words without understanding, which shows your
> ignorance.
>
>>
>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>
>> I am only referring to the fact that the semantics of the x86 language
>> conclusively proves that the correctly simulated input to H(P,P) by H
>> cannot possibly ever reach the "return" instruction of P.
>
> Nope, doesn't show it. More of your made up "proof".
>
> Note, the key point of your arguement, and the point you get wrong,
> actually has NOTHING to do with the x86 language.
>
> Simple point of observation, change you target processor for you
> compiler and replace the emulatior with an emulator for that processor,
> (and the appropriate references in your decider) and the argument would
> be EXACTLY the same, so you aren't using anything about the x86 itself
>
>>
>> The only relevant rebuttal is a step-by-step proof showing
>> line-by-line of the source-code of P exactly how H diverges from its
>> correct x86 emulation of its input.
>>
>
> First, you have it backwards. The PROOF needs to be the step by step
> proof, a rebutal only needs to point out ONE error in the proof.
>
> And I HAVE pointed out the error but you don't look at it.
>
> You claim a rule, often numbered (3) that says that non-halting is
> proven by there not being a conditional instruction inside the C
> function P to end the loop. There is no such rule, not one that allows
> for H to be a decider that can decide to abort its simulation.
>
> Until you can actually PROVE your rules, or at least cite a source that
> vouches for it, your proof has become undone, based on having an
> unproven (and untrue) premise. No amount of just claiming it must be
> true removes that defect from your proof. ANY premise of a proof that
> have been challenged must be proven or the proof falls apart.
>
> The divergence in the correct x86 behavior is that the correct x86
> behavior of a call to H will be followed by the actual behavior of the
> function H. You code errs in that in build on logic that INCORRECTLY
> presumes that H will just unconditionally simulate its input (so your
> rule 3 is correct) when that isn't the actual behavior of H.
>
> The x86 behavior that H has seen does NOT provide any proof for your
> claim, so by claiming it does just points out your lie.
So then you are saying that the behavior shown in the correct execution
trace of the input that H(P,P) correctly simulates is incorrect even
though it is correct?

--
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 7/23/22 1:57 PM, olcott wrote:
> On 7/23/2022 12:43 PM, Richard Damon wrote:
>> On 7/23/22 12:37 PM, olcott wrote:
>>> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>>>
>>>> On 7/23/22 12:05 PM, olcott wrote:
>>>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>>>> I am only referring to the correctly simulated input to
>>>>>>>>>>>> H(P,P) that
>>>>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>>>>> specifies an
>>>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>>>
>>>>>>>>>>> You realise this is essentially the same as saying "Reality
>>>>>>>>>>> does not agree with my predictions, but my predictions are
>>>>>>>>>>> nevertheless correct" ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In programming language theory, semantics is the field
>>>>>>>>>> concerned with the rigorous mathematical study of the meaning
>>>>>>>>>> of programming languages.[1] It does so by evaluating the
>>>>>>>>>> meaning of syntactically valid strings defined by a specific
>>>>>>>>>> programming language, showing the computation involved. In
>>>>>>>>>> such a case that the evaluation would be of syntactically
>>>>>>>>>> invalid strings, the result would be non-computation.
>>>>>>>>>> Semantics describes the processes a computer follows when
>>>>>>>>>> executing a program in that specific language.
>>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>>
>>>>>>>>>> The code proves that the correctly simulated input would never
>>>>>>>>>> reach its "return" instruction.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>>>> The correct execution trace of the correctly simulated input to
>>>>>>>>> H(P,P) conclusively proves that the simulated P cannot possibly
>>>>>>>>> reach its "return" instruction.
>>>>>>>>>
>>>>>>>>> Humans having sufficient technical knowledge can see this and H
>>>>>>>>> can see this. To say that I am incorrect based on not having
>>>>>>>>> having sufficient technical knowledge is both incorrect and rude.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>>>>
>>>>>>> That you say that I am wrong on the basis that you do not know
>>>>>>> that the semantics of the x86 language proves that I am correct
>>>>>>> causes me to ignore almost all of your posts.
>>>>>>>
>>>>>>
>>>>>> I have pointed out errors in the proofs that you just won't make
>>>>>> an effort to rebut,
>>>>>
>>>>> That is another thing that you do.
>>>>> I make one point and then you change the subject as your rebuttal.
>>>>
>>>> How is pointing out an error in your proof a change of subject?
>>>>
>>>
>>> I claim that X is true and your rebuttal is that you believe that Y
>>> is false.
>>
>> No, you claim X is true and try to give a proof, showing that because
>> of a, b, and c, X must be true.
>>
>> I point out that c isn't actually a true statement.
>>
>> That is a rebuttal.
>>
>> You answer has always been to just restate a, b, and c, and never
>> being able to give a source of ANYONE who supports you that the point
>> I ask about it actually true.
>>
>> Being unable to cite a source for ANY of your "rules" that you start
>> from says you don't actually HAVE a proof, just a rhetorical argument.
>> I think the issue is you just don't know what an actual proof should
>> look like. You use a lot of words without understanding, which shows
>> your ignorance.
>>
>>>
>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>
>>> I am only referring to the fact that the semantics of the x86
>>> language conclusively proves that the correctly simulated input to
>>> H(P,P) by H cannot possibly ever reach the "return" instruction of P.
>>
>> Nope, doesn't show it. More of your made up "proof".
>>
>> Note, the key point of your arguement, and the point you get wrong,
>> actually has NOTHING to do with the x86 language.
>>
>> Simple point of observation, change you target processor for you
>> compiler and replace the emulatior with an emulator for that
>> processor, (and the appropriate references in your decider) and the
>> argument would be EXACTLY the same, so you aren't using anything about
>> the x86 itself
>>
>>>
>>> The only relevant rebuttal is a step-by-step proof showing
>>> line-by-line of the source-code of P exactly how H diverges from its
>>> correct x86 emulation of its input.
>>>
>>
>> First, you have it backwards. The PROOF needs to be the step by step
>> proof, a rebutal only needs to point out ONE error in the proof.
>>
>> And I HAVE pointed out the error but you don't look at it.
>>
>> You claim a rule, often numbered (3) that says that non-halting is
>> proven by there not being a conditional instruction inside the C
>> function P to end the loop. There is no such rule, not one that allows
>> for H to be a decider that can decide to abort its simulation.
>>
>> Until you can actually PROVE your rules, or at least cite a source
>> that vouches for it, your proof has become undone, based on having an
>> unproven (and untrue) premise. No amount of just claiming it must be
>> true removes that defect from your proof. ANY premise of a proof that
>> have been challenged must be proven or the proof falls apart.
>>
>> The divergence in the correct x86 behavior is that the correct x86
>> behavior of a call to H will be followed by the actual behavior of the
>> function H. You code errs in that in build on logic that INCORRECTLY
>> presumes that H will just unconditionally simulate its input (so your
>> rule 3 is correct) when that isn't the actual behavior of H.
>>
>> The x86 behavior that H has seen does NOT provide any proof for your
>> claim, so by claiming it does just points out your lie.
> So then you are saying that the behavior shown in the correct execution
> trace of the input that H(P,P) correctly simulates is incorrect even
> though it is correct?
>

Look again at your execution trace.

All they say is that when P calls H(P,P) that H aborted it simulation
and decided that the input was non-halting.

That, by itself, doesn't prove that the input IS non-halting. Only that
H claims it.

So yes, you can say from the traces that P(P) will call H(P,P). From the
traces you can't say anything about halting, that requires using
information and logic beyond the traces.

Why do you ignore the other trace you have posted that shows that a
correct and complete trace of P(P), which IS the required behavior of
the input of H(P,P), shows that it does halt?

Isn't THAT actual PROOF that the correct AND COMPLETE simulation of the
input to H(P,P) will reach the return instruction.

Is your problem that you think that if we stop simulating a machine in
the middle that makes a machihe/program that WOULD halt if allowed to
continue non-halting because the correct but partial simulation didn't
get there?

On 7/23/2022 1:20 PM, Richard Damon wrote:
> On 7/23/22 1:57 PM, olcott wrote:
>> On 7/23/2022 12:43 PM, Richard Damon wrote:
>>> On 7/23/22 12:37 PM, olcott wrote:
>>>> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>>>>
>>>>> On 7/23/22 12:05 PM, olcott wrote:
>>>>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>>>>> I am only referring to the correctly simulated input to
>>>>>>>>>>>>> H(P,P) that
>>>>>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>>>>>> specifies an
>>>>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>>>>
>>>>>>>>>>>> You realise this is essentially the same as saying "Reality
>>>>>>>>>>>> does not agree with my predictions, but my predictions are
>>>>>>>>>>>> nevertheless correct" ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In programming language theory, semantics is the field
>>>>>>>>>>> concerned with the rigorous mathematical study of the meaning
>>>>>>>>>>> of programming languages.[1] It does so by evaluating the
>>>>>>>>>>> meaning of syntactically valid strings defined by a specific
>>>>>>>>>>> programming language, showing the computation involved. In
>>>>>>>>>>> such a case that the evaluation would be of syntactically
>>>>>>>>>>> invalid strings, the result would be non-computation.
>>>>>>>>>>> Semantics describes the processes a computer follows when
>>>>>>>>>>> executing a program in that specific language.
>>>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>>>
>>>>>>>>>>> The code proves that the correctly simulated input would
>>>>>>>>>>> never reach its "return" instruction.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>>>>> The correct execution trace of the correctly simulated input
>>>>>>>>>> to H(P,P) conclusively proves that the simulated P cannot
>>>>>>>>>> possibly reach its "return" instruction.
>>>>>>>>>>
>>>>>>>>>> Humans having sufficient technical knowledge can see this and
>>>>>>>>>> H can see this. To say that I am incorrect based on not having
>>>>>>>>>> having sufficient technical knowledge is both incorrect and rude.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>>>>>
>>>>>>>> That you say that I am wrong on the basis that you do not know
>>>>>>>> that the semantics of the x86 language proves that I am correct
>>>>>>>> causes me to ignore almost all of your posts.
>>>>>>>>
>>>>>>>
>>>>>>> I have pointed out errors in the proofs that you just won't make
>>>>>>> an effort to rebut,
>>>>>>
>>>>>> That is another thing that you do.
>>>>>> I make one point and then you change the subject as your rebuttal.
>>>>>
>>>>> How is pointing out an error in your proof a change of subject?
>>>>>
>>>>
>>>> I claim that X is true and your rebuttal is that you believe that Y
>>>> is false.
>>>
>>> No, you claim X is true and try to give a proof, showing that because
>>> of a, b, and c, X must be true.
>>>
>>> I point out that c isn't actually a true statement.
>>>
>>> That is a rebuttal.
>>>
>>> You answer has always been to just restate a, b, and c, and never
>>> being able to give a source of ANYONE who supports you that the point
>>> I ask about it actually true.
>>>
>>> Being unable to cite a source for ANY of your "rules" that you start
>>> from says you don't actually HAVE a proof, just a rhetorical
>>> argument. I think the issue is you just don't know what an actual
>>> proof should look like. You use a lot of words without understanding,
>>> which shows your ignorance.
>>>
>>>>
>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>
>>>> I am only referring to the fact that the semantics of the x86
>>>> language conclusively proves that the correctly simulated input to
>>>> H(P,P) by H cannot possibly ever reach the "return" instruction of P.
>>>
>>> Nope, doesn't show it. More of your made up "proof".
>>>
>>> Note, the key point of your arguement, and the point you get wrong,
>>> actually has NOTHING to do with the x86 language.
>>>
>>> Simple point of observation, change you target processor for you
>>> compiler and replace the emulatior with an emulator for that
>>> processor, (and the appropriate references in your decider) and the
>>> argument would be EXACTLY the same, so you aren't using anything
>>> about the x86 itself
>>>
>>>>
>>>> The only relevant rebuttal is a step-by-step proof showing
>>>> line-by-line of the source-code of P exactly how H diverges from its
>>>> correct x86 emulation of its input.
>>>>
>>>
>>> First, you have it backwards. The PROOF needs to be the step by step
>>> proof, a rebutal only needs to point out ONE error in the proof.
>>>
>>> And I HAVE pointed out the error but you don't look at it.
>>>
>>> You claim a rule, often numbered (3) that says that non-halting is
>>> proven by there not being a conditional instruction inside the C
>>> function P to end the loop. There is no such rule, not one that
>>> allows for H to be a decider that can decide to abort its simulation.
>>>
>>> Until you can actually PROVE your rules, or at least cite a source
>>> that vouches for it, your proof has become undone, based on having an
>>> unproven (and untrue) premise. No amount of just claiming it must be
>>> true removes that defect from your proof. ANY premise of a proof that
>>> have been challenged must be proven or the proof falls apart.
>>>
>>> The divergence in the correct x86 behavior is that the correct x86
>>> behavior of a call to H will be followed by the actual behavior of
>>> the function H. You code errs in that in build on logic that
>>> INCORRECTLY presumes that H will just unconditionally simulate its
>>> input (so your rule 3 is correct) when that isn't the actual behavior
>>> of H.
>>>
>>> The x86 behavior that H has seen does NOT provide any proof for your
>>> claim, so by claiming it does just points out your lie.
>> So then you are saying that the behavior shown in the correct
>> execution trace of the input that H(P,P) correctly simulates is
>> incorrect even though it is correct?
>>
>
> Look again at your execution trace.
>
> All they say is that when P calls H(P,P) that H aborted it simulation
> and decided that the input was non-halting.

That is not all that it says. It also shows that P would never stop
unless it was aborted.

On 7/23/22 2:26 PM, olcott wrote:
> On 7/23/2022 1:20 PM, Richard Damon wrote:
>> On 7/23/22 1:57 PM, olcott wrote:
>>> On 7/23/2022 12:43 PM, Richard Damon wrote:
>>>> On 7/23/22 12:37 PM, olcott wrote:
>>>>> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/23/22 12:05 PM, olcott wrote:
>>>>>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>>>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>>>>>> I am only referring to the correctly simulated input to
>>>>>>>>>>>>>> H(P,P) that
>>>>>>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>>>>>>> specifies an
>>>>>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You realise this is essentially the same as saying "Reality
>>>>>>>>>>>>> does not agree with my predictions, but my predictions are
>>>>>>>>>>>>> nevertheless correct" ?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In programming language theory, semantics is the field
>>>>>>>>>>>> concerned with the rigorous mathematical study of the
>>>>>>>>>>>> meaning of programming languages.[1] It does so by
>>>>>>>>>>>> evaluating the meaning of syntactically valid strings
>>>>>>>>>>>> defined by a specific programming language, showing the
>>>>>>>>>>>> computation involved. In such a case that the evaluation
>>>>>>>>>>>> would be of syntactically invalid strings, the result would
>>>>>>>>>>>> be non-computation. Semantics describes the processes a
>>>>>>>>>>>> computer follows when executing a program in that specific
>>>>>>>>>>>> language.
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>>>>
>>>>>>>>>>>> The code proves that the correctly simulated input would
>>>>>>>>>>>> never reach its "return" instruction.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>>>>>> The correct execution trace of the correctly simulated input
>>>>>>>>>>> to H(P,P) conclusively proves that the simulated P cannot
>>>>>>>>>>> possibly reach its "return" instruction.
>>>>>>>>>>>
>>>>>>>>>>> Humans having sufficient technical knowledge can see this and
>>>>>>>>>>> H can see this. To say that I am incorrect based on not
>>>>>>>>>>> having having sufficient technical knowledge is both
>>>>>>>>>>> incorrect and rude.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>>>>>>
>>>>>>>>> That you say that I am wrong on the basis that you do not know
>>>>>>>>> that the semantics of the x86 language proves that I am correct
>>>>>>>>> causes me to ignore almost all of your posts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have pointed out errors in the proofs that you just won't make
>>>>>>>> an effort to rebut,
>>>>>>>
>>>>>>> That is another thing that you do.
>>>>>>> I make one point and then you change the subject as your rebuttal.
>>>>>>
>>>>>> How is pointing out an error in your proof a change of subject?
>>>>>>
>>>>>
>>>>> I claim that X is true and your rebuttal is that you believe that Y
>>>>> is false.
>>>>
>>>> No, you claim X is true and try to give a proof, showing that
>>>> because of a, b, and c, X must be true.
>>>>
>>>> I point out that c isn't actually a true statement.
>>>>
>>>> That is a rebuttal.
>>>>
>>>> You answer has always been to just restate a, b, and c, and never
>>>> being able to give a source of ANYONE who supports you that the
>>>> point I ask about it actually true.
>>>>
>>>> Being unable to cite a source for ANY of your "rules" that you start
>>>> from says you don't actually HAVE a proof, just a rhetorical
>>>> argument. I think the issue is you just don't know what an actual
>>>> proof should look like. You use a lot of words without
>>>> understanding, which shows your ignorance.
>>>>
>>>>>
>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>
>>>>> I am only referring to the fact that the semantics of the x86
>>>>> language conclusively proves that the correctly simulated input to
>>>>> H(P,P) by H cannot possibly ever reach the "return" instruction of P.
>>>>
>>>> Nope, doesn't show it. More of your made up "proof".
>>>>
>>>> Note, the key point of your arguement, and the point you get wrong,
>>>> actually has NOTHING to do with the x86 language.
>>>>
>>>> Simple point of observation, change you target processor for you
>>>> compiler and replace the emulatior with an emulator for that
>>>> processor, (and the appropriate references in your decider) and the
>>>> argument would be EXACTLY the same, so you aren't using anything
>>>> about the x86 itself
>>>>
>>>>>
>>>>> The only relevant rebuttal is a step-by-step proof showing
>>>>> line-by-line of the source-code of P exactly how H diverges from
>>>>> its correct x86 emulation of its input.
>>>>>
>>>>
>>>> First, you have it backwards. The PROOF needs to be the step by step
>>>> proof, a rebutal only needs to point out ONE error in the proof.
>>>>
>>>> And I HAVE pointed out the error but you don't look at it.
>>>>
>>>> You claim a rule, often numbered (3) that says that non-halting is
>>>> proven by there not being a conditional instruction inside the C
>>>> function P to end the loop. There is no such rule, not one that
>>>> allows for H to be a decider that can decide to abort its simulation.
>>>>
>>>> Until you can actually PROVE your rules, or at least cite a source
>>>> that vouches for it, your proof has become undone, based on having
>>>> an unproven (and untrue) premise. No amount of just claiming it must
>>>> be true removes that defect from your proof. ANY premise of a proof
>>>> that have been challenged must be proven or the proof falls apart.
>>>>
>>>> The divergence in the correct x86 behavior is that the correct x86
>>>> behavior of a call to H will be followed by the actual behavior of
>>>> the function H. You code errs in that in build on logic that
>>>> INCORRECTLY presumes that H will just unconditionally simulate its
>>>> input (so your rule 3 is correct) when that isn't the actual
>>>> behavior of H.
>>>>
>>>> The x86 behavior that H has seen does NOT provide any proof for your
>>>> claim, so by claiming it does just points out your lie.
>>> So then you are saying that the behavior shown in the correct
>>> execution trace of the input that H(P,P) correctly simulates is
>>> incorrect even though it is correct?
>>>
>>
>> Look again at your execution trace.
>>
>> All they say is that when P calls H(P,P) that H aborted it simulation
>> and decided that the input was non-halting.
>
> That is not all that it says. It also shows that P would never stop
> unless it was aborted.
>

On 7/23/2022 1:38 PM, Richard Damon wrote:
> On 7/23/22 2:26 PM, olcott wrote:
>> On 7/23/2022 1:20 PM, Richard Damon wrote:
>>> On 7/23/22 1:57 PM, olcott wrote:
>>>> On 7/23/2022 12:43 PM, Richard Damon wrote:
>>>>> On 7/23/22 12:37 PM, olcott wrote:
>>>>>> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 7/23/22 12:05 PM, olcott wrote:
>>>>>>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>>>>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>>>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>>>>>>> I am only referring to the correctly simulated input to
>>>>>>>>>>>>>>> H(P,P) that
>>>>>>>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>>>>>>>> specifies an
>>>>>>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You realise this is essentially the same as saying
>>>>>>>>>>>>>> "Reality does not agree with my predictions, but my
>>>>>>>>>>>>>> predictions are nevertheless correct" ?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> In programming language theory, semantics is the field
>>>>>>>>>>>>> concerned with the rigorous mathematical study of the
>>>>>>>>>>>>> meaning of programming languages.[1] It does so by
>>>>>>>>>>>>> evaluating the meaning of syntactically valid strings
>>>>>>>>>>>>> defined by a specific programming language, showing the
>>>>>>>>>>>>> computation involved. In such a case that the evaluation
>>>>>>>>>>>>> would be of syntactically invalid strings, the result would
>>>>>>>>>>>>> be non-computation. Semantics describes the processes a
>>>>>>>>>>>>> computer follows when executing a program in that specific
>>>>>>>>>>>>> language.
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The code proves that the correctly simulated input would
>>>>>>>>>>>>> never reach its "return" instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>>>>>>> The correct execution trace of the correctly simulated input
>>>>>>>>>>>> to H(P,P) conclusively proves that the simulated P cannot
>>>>>>>>>>>> possibly reach its "return" instruction.
>>>>>>>>>>>>
>>>>>>>>>>>> Humans having sufficient technical knowledge can see this
>>>>>>>>>>>> and H can see this. To say that I am incorrect based on not
>>>>>>>>>>>> having having sufficient technical knowledge is both
>>>>>>>>>>>> incorrect and rude.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>>>>>>>
>>>>>>>>>> That you say that I am wrong on the basis that you do not know
>>>>>>>>>> that the semantics of the x86 language proves that I am
>>>>>>>>>> correct causes me to ignore almost all of your posts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have pointed out errors in the proofs that you just won't
>>>>>>>>> make an effort to rebut,
>>>>>>>>
>>>>>>>> That is another thing that you do.
>>>>>>>> I make one point and then you change the subject as your rebuttal.
>>>>>>>
>>>>>>> How is pointing out an error in your proof a change of subject?
>>>>>>>
>>>>>>
>>>>>> I claim that X is true and your rebuttal is that you believe that
>>>>>> Y is false.
>>>>>
>>>>> No, you claim X is true and try to give a proof, showing that
>>>>> because of a, b, and c, X must be true.
>>>>>
>>>>> I point out that c isn't actually a true statement.
>>>>>
>>>>> That is a rebuttal.
>>>>>
>>>>> You answer has always been to just restate a, b, and c, and never
>>>>> being able to give a source of ANYONE who supports you that the
>>>>> point I ask about it actually true.
>>>>>
>>>>> Being unable to cite a source for ANY of your "rules" that you
>>>>> start from says you don't actually HAVE a proof, just a rhetorical
>>>>> argument. I think the issue is you just don't know what an actual
>>>>> proof should look like. You use a lot of words without
>>>>> understanding, which shows your ignorance.
>>>>>
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>
>>>>>> I am only referring to the fact that the semantics of the x86
>>>>>> language conclusively proves that the correctly simulated input to
>>>>>> H(P,P) by H cannot possibly ever reach the "return" instruction of P.
>>>>>
>>>>> Nope, doesn't show it. More of your made up "proof".
>>>>>
>>>>> Note, the key point of your arguement, and the point you get wrong,
>>>>> actually has NOTHING to do with the x86 language.
>>>>>
>>>>> Simple point of observation, change you target processor for you
>>>>> compiler and replace the emulatior with an emulator for that
>>>>> processor, (and the appropriate references in your decider) and the
>>>>> argument would be EXACTLY the same, so you aren't using anything
>>>>> about the x86 itself
>>>>>
>>>>>>
>>>>>> The only relevant rebuttal is a step-by-step proof showing
>>>>>> line-by-line of the source-code of P exactly how H diverges from
>>>>>> its correct x86 emulation of its input.
>>>>>>
>>>>>
>>>>> First, you have it backwards. The PROOF needs to be the step by
>>>>> step proof, a rebutal only needs to point out ONE error in the proof.
>>>>>
>>>>> And I HAVE pointed out the error but you don't look at it.
>>>>>
>>>>> You claim a rule, often numbered (3) that says that non-halting is
>>>>> proven by there not being a conditional instruction inside the C
>>>>> function P to end the loop. There is no such rule, not one that
>>>>> allows for H to be a decider that can decide to abort its simulation.
>>>>>
>>>>> Until you can actually PROVE your rules, or at least cite a source
>>>>> that vouches for it, your proof has become undone, based on having
>>>>> an unproven (and untrue) premise. No amount of just claiming it
>>>>> must be true removes that defect from your proof. ANY premise of a
>>>>> proof that have been challenged must be proven or the proof falls
>>>>> apart.
>>>>>
>>>>> The divergence in the correct x86 behavior is that the correct x86
>>>>> behavior of a call to H will be followed by the actual behavior of
>>>>> the function H. You code errs in that in build on logic that
>>>>> INCORRECTLY presumes that H will just unconditionally simulate its
>>>>> input (so your rule 3 is correct) when that isn't the actual
>>>>> behavior of H.
>>>>>
>>>>> The x86 behavior that H has seen does NOT provide any proof for
>>>>> your claim, so by claiming it does just points out your lie.
>>>> So then you are saying that the behavior shown in the correct
>>>> execution trace of the input that H(P,P) correctly simulates is
>>>> incorrect even though it is correct?
>>>>
>>>
>>> Look again at your execution trace.
>>>
>>> All they say is that when P calls H(P,P) that H aborted it simulation
>>> and decided that the input was non-halting.
>>
>> That is not all that it says. It also shows that P would never stop
>> unless it was aborted.
>>
>
> WHERE?
You already admitted this dozens of times.

On 7/23/22 2:48 PM, olcott wrote:
> On 7/23/2022 1:38 PM, Richard Damon wrote:
>> On 7/23/22 2:26 PM, olcott wrote:
>>> On 7/23/2022 1:20 PM, Richard Damon wrote:
>>>> On 7/23/22 1:57 PM, olcott wrote:
>>>>> On 7/23/2022 12:43 PM, Richard Damon wrote:
>>>>>> On 7/23/22 12:37 PM, olcott wrote:
>>>>>>> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 7/23/22 12:05 PM, olcott wrote:
>>>>>>>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>>>>>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>>>>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>>>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>>>>>>>> I am only referring to the correctly simulated input to
>>>>>>>>>>>>>>>> H(P,P) that
>>>>>>>>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>>>>>>>>> specifies an
>>>>>>>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You realise this is essentially the same as saying
>>>>>>>>>>>>>>> "Reality does not agree with my predictions, but my
>>>>>>>>>>>>>>> predictions are nevertheless correct" ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In programming language theory, semantics is the field
>>>>>>>>>>>>>> concerned with the rigorous mathematical study of the
>>>>>>>>>>>>>> meaning of programming languages.[1] It does so by
>>>>>>>>>>>>>> evaluating the meaning of syntactically valid strings
>>>>>>>>>>>>>> defined by a specific programming language, showing the
>>>>>>>>>>>>>> computation involved. In such a case that the evaluation
>>>>>>>>>>>>>> would be of syntactically invalid strings, the result
>>>>>>>>>>>>>> would be non-computation. Semantics describes the
>>>>>>>>>>>>>> processes a computer follows when executing a program in
>>>>>>>>>>>>>> that specific language.
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The code proves that the correctly simulated input would
>>>>>>>>>>>>>> never reach its "return" instruction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>>>>>>>> The correct execution trace of the correctly simulated
>>>>>>>>>>>>> input to H(P,P) conclusively proves that the simulated P
>>>>>>>>>>>>> cannot possibly reach its "return" instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Humans having sufficient technical knowledge can see this
>>>>>>>>>>>>> and H can see this. To say that I am incorrect based on not
>>>>>>>>>>>>> having having sufficient technical knowledge is both
>>>>>>>>>>>>> incorrect and rude.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>>>>>>>>
>>>>>>>>>>> That you say that I am wrong on the basis that you do not
>>>>>>>>>>> know that the semantics of the x86 language proves that I am
>>>>>>>>>>> correct causes me to ignore almost all of your posts.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have pointed out errors in the proofs that you just won't
>>>>>>>>>> make an effort to rebut,
>>>>>>>>>
>>>>>>>>> That is another thing that you do.
>>>>>>>>> I make one point and then you change the subject as your rebuttal.
>>>>>>>>
>>>>>>>> How is pointing out an error in your proof a change of subject?
>>>>>>>>
>>>>>>>
>>>>>>> I claim that X is true and your rebuttal is that you believe that
>>>>>>> Y is false.
>>>>>>
>>>>>> No, you claim X is true and try to give a proof, showing that
>>>>>> because of a, b, and c, X must be true.
>>>>>>
>>>>>> I point out that c isn't actually a true statement.
>>>>>>
>>>>>> That is a rebuttal.
>>>>>>
>>>>>> You answer has always been to just restate a, b, and c, and never
>>>>>> being able to give a source of ANYONE who supports you that the
>>>>>> point I ask about it actually true.
>>>>>>
>>>>>> Being unable to cite a source for ANY of your "rules" that you
>>>>>> start from says you don't actually HAVE a proof, just a rhetorical
>>>>>> argument. I think the issue is you just don't know what an actual
>>>>>> proof should look like. You use a lot of words without
>>>>>> understanding, which shows your ignorance.
>>>>>>
>>>>>>>
>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>
>>>>>>> I am only referring to the fact that the semantics of the x86
>>>>>>> language conclusively proves that the correctly simulated input
>>>>>>> to H(P,P) by H cannot possibly ever reach the "return"
>>>>>>> instruction of P.
>>>>>>
>>>>>> Nope, doesn't show it. More of your made up "proof".
>>>>>>
>>>>>> Note, the key point of your arguement, and the point you get
>>>>>> wrong, actually has NOTHING to do with the x86 language.
>>>>>>
>>>>>> Simple point of observation, change you target processor for you
>>>>>> compiler and replace the emulatior with an emulator for that
>>>>>> processor, (and the appropriate references in your decider) and
>>>>>> the argument would be EXACTLY the same, so you aren't using
>>>>>> anything about the x86 itself
>>>>>>
>>>>>>>
>>>>>>> The only relevant rebuttal is a step-by-step proof showing
>>>>>>> line-by-line of the source-code of P exactly how H diverges from
>>>>>>> its correct x86 emulation of its input.
>>>>>>>
>>>>>>
>>>>>> First, you have it backwards. The PROOF needs to be the step by
>>>>>> step proof, a rebutal only needs to point out ONE error in the proof.
>>>>>>
>>>>>> And I HAVE pointed out the error but you don't look at it.
>>>>>>
>>>>>> You claim a rule, often numbered (3) that says that non-halting is
>>>>>> proven by there not being a conditional instruction inside the C
>>>>>> function P to end the loop. There is no such rule, not one that
>>>>>> allows for H to be a decider that can decide to abort its simulation.
>>>>>>
>>>>>> Until you can actually PROVE your rules, or at least cite a source
>>>>>> that vouches for it, your proof has become undone, based on having
>>>>>> an unproven (and untrue) premise. No amount of just claiming it
>>>>>> must be true removes that defect from your proof. ANY premise of a
>>>>>> proof that have been challenged must be proven or the proof falls
>>>>>> apart.
>>>>>>
>>>>>> The divergence in the correct x86 behavior is that the correct x86
>>>>>> behavior of a call to H will be followed by the actual behavior of
>>>>>> the function H. You code errs in that in build on logic that
>>>>>> INCORRECTLY presumes that H will just unconditionally simulate its
>>>>>> input (so your rule 3 is correct) when that isn't the actual
>>>>>> behavior of H.
>>>>>>
>>>>>> The x86 behavior that H has seen does NOT provide any proof for
>>>>>> your claim, so by claiming it does just points out your lie.
>>>>> So then you are saying that the behavior shown in the correct
>>>>> execution trace of the input that H(P,P) correctly simulates is
>>>>> incorrect even though it is correct?
>>>>>
>>>>
>>>> Look again at your execution trace.
>>>>
>>>> All they say is that when P calls H(P,P) that H aborted it
>>>> simulation and decided that the input was non-halting.
>>>
>>> That is not all that it says. It also shows that P would never stop
>>> unless it was aborted.
>>>
>>
>> WHERE?
> You already admitted this dozens of times.
>

On 7/23/2022 2:41 PM, Richard Damon wrote:
>
> On 7/23/22 2:48 PM, olcott wrote:
>> On 7/23/2022 1:38 PM, Richard Damon wrote:
>>> On 7/23/22 2:26 PM, olcott wrote:
>>>> On 7/23/2022 1:20 PM, Richard Damon wrote:
>>>>> On 7/23/22 1:57 PM, olcott wrote:
>>>>>> On 7/23/2022 12:43 PM, Richard Damon wrote:
>>>>>>> On 7/23/22 12:37 PM, olcott wrote:
>>>>>>>> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 7/23/22 12:05 PM, olcott wrote:
>>>>>>>>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>>>>>>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>>>>>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>>>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>>>>>>>>> I am only referring to the correctly simulated input to
>>>>>>>>>>>>>>>>> H(P,P) that
>>>>>>>>>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>>>>>>>>>> specifies an
>>>>>>>>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You realise this is essentially the same as saying
>>>>>>>>>>>>>>>> "Reality does not agree with my predictions, but my
>>>>>>>>>>>>>>>> predictions are nevertheless correct" ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In programming language theory, semantics is the field
>>>>>>>>>>>>>>> concerned with the rigorous mathematical study of the
>>>>>>>>>>>>>>> meaning of programming languages.[1] It does so by
>>>>>>>>>>>>>>> evaluating the meaning of syntactically valid strings
>>>>>>>>>>>>>>> defined by a specific programming language, showing the
>>>>>>>>>>>>>>> computation involved. In such a case that the evaluation
>>>>>>>>>>>>>>> would be of syntactically invalid strings, the result
>>>>>>>>>>>>>>> would be non-computation. Semantics describes the
>>>>>>>>>>>>>>> processes a computer follows when executing a program in
>>>>>>>>>>>>>>> that specific language.
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The code proves that the correctly simulated input would
>>>>>>>>>>>>>>> never reach its "return" instruction.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>>>>>>>>> The correct execution trace of the correctly simulated
>>>>>>>>>>>>>> input to H(P,P) conclusively proves that the simulated P
>>>>>>>>>>>>>> cannot possibly reach its "return" instruction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Humans having sufficient technical knowledge can see this
>>>>>>>>>>>>>> and H can see this. To say that I am incorrect based on
>>>>>>>>>>>>>> not having having sufficient technical knowledge is both
>>>>>>>>>>>>>> incorrect and rude.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>>>>>>>>>
>>>>>>>>>>>> That you say that I am wrong on the basis that you do not
>>>>>>>>>>>> know that the semantics of the x86 language proves that I am
>>>>>>>>>>>> correct causes me to ignore almost all of your posts.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I have pointed out errors in the proofs that you just won't
>>>>>>>>>>> make an effort to rebut,
>>>>>>>>>>
>>>>>>>>>> That is another thing that you do.
>>>>>>>>>> I make one point and then you change the subject as your
>>>>>>>>>> rebuttal.
>>>>>>>>>
>>>>>>>>> How is pointing out an error in your proof a change of subject?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I claim that X is true and your rebuttal is that you believe
>>>>>>>> that Y is false.
>>>>>>>
>>>>>>> No, you claim X is true and try to give a proof, showing that
>>>>>>> because of a, b, and c, X must be true.
>>>>>>>
>>>>>>> I point out that c isn't actually a true statement.
>>>>>>>
>>>>>>> That is a rebuttal.
>>>>>>>
>>>>>>> You answer has always been to just restate a, b, and c, and never
>>>>>>> being able to give a source of ANYONE who supports you that the
>>>>>>> point I ask about it actually true.
>>>>>>>
>>>>>>> Being unable to cite a source for ANY of your "rules" that you
>>>>>>> start from says you don't actually HAVE a proof, just a
>>>>>>> rhetorical argument. I think the issue is you just don't know
>>>>>>> what an actual proof should look like. You use a lot of words
>>>>>>> without understanding, which shows your ignorance.
>>>>>>>
>>>>>>>>
>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>
>>>>>>>> I am only referring to the fact that the semantics of the x86
>>>>>>>> language conclusively proves that the correctly simulated input
>>>>>>>> to H(P,P) by H cannot possibly ever reach the "return"
>>>>>>>> instruction of P.
>>>>>>>
>>>>>>> Nope, doesn't show it. More of your made up "proof".
>>>>>>>
>>>>>>> Note, the key point of your arguement, and the point you get
>>>>>>> wrong, actually has NOTHING to do with the x86 language.
>>>>>>>
>>>>>>> Simple point of observation, change you target processor for you
>>>>>>> compiler and replace the emulatior with an emulator for that
>>>>>>> processor, (and the appropriate references in your decider) and
>>>>>>> the argument would be EXACTLY the same, so you aren't using
>>>>>>> anything about the x86 itself
>>>>>>>
>>>>>>>>
>>>>>>>> The only relevant rebuttal is a step-by-step proof showing
>>>>>>>> line-by-line of the source-code of P exactly how H diverges from
>>>>>>>> its correct x86 emulation of its input.
>>>>>>>>
>>>>>>>
>>>>>>> First, you have it backwards. The PROOF needs to be the step by
>>>>>>> step proof, a rebutal only needs to point out ONE error in the
>>>>>>> proof.
>>>>>>>
>>>>>>> And I HAVE pointed out the error but you don't look at it.
>>>>>>>
>>>>>>> You claim a rule, often numbered (3) that says that non-halting
>>>>>>> is proven by there not being a conditional instruction inside the
>>>>>>> C function P to end the loop. There is no such rule, not one that
>>>>>>> allows for H to be a decider that can decide to abort its
>>>>>>> simulation.
>>>>>>>
>>>>>>> Until you can actually PROVE your rules, or at least cite a
>>>>>>> source that vouches for it, your proof has become undone, based
>>>>>>> on having an unproven (and untrue) premise. No amount of just
>>>>>>> claiming it must be true removes that defect from your proof. ANY
>>>>>>> premise of a proof that have been challenged must be proven or
>>>>>>> the proof falls apart.
>>>>>>>
>>>>>>> The divergence in the correct x86 behavior is that the correct
>>>>>>> x86 behavior of a call to H will be followed by the actual
>>>>>>> behavior of the function H. You code errs in that in build on
>>>>>>> logic that INCORRECTLY presumes that H will just unconditionally
>>>>>>> simulate its input (so your rule 3 is correct) when that isn't
>>>>>>> the actual behavior of H.
>>>>>>>
>>>>>>> The x86 behavior that H has seen does NOT provide any proof for
>>>>>>> your claim, so by claiming it does just points out your lie.
>>>>>> So then you are saying that the behavior shown in the correct
>>>>>> execution trace of the input that H(P,P) correctly simulates is
>>>>>> incorrect even though it is correct?
>>>>>>
>>>>>
>>>>> Look again at your execution trace.
>>>>>
>>>>> All they say is that when P calls H(P,P) that H aborted it
>>>>> simulation and decided that the input was non-halting.
>>>>
>>>> That is not all that it says. It also shows that P would never stop
>>>> unless it was aborted.
>>>>
>>>
>>> WHERE?
>> You already admitted this dozens of times.
>>
>
> Nope, not with THIS H. You make that mistake a lot, you confuse your H's.
>

On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
> This H correctly determines that its simulated input: (P,P) would never
> stop unless aborted.

Then how come P does the exact opposite of what H "correctly determines"?

Every time!

On 7/23/22 3:46 PM, olcott wrote:
> On 7/23/2022 2:41 PM, Richard Damon wrote:
>>
>> On 7/23/22 2:48 PM, olcott wrote:
>>> On 7/23/2022 1:38 PM, Richard Damon wrote:
>>>> On 7/23/22 2:26 PM, olcott wrote:
>>>>> On 7/23/2022 1:20 PM, Richard Damon wrote:
>>>>>> On 7/23/22 1:57 PM, olcott wrote:
>>>>>>> On 7/23/2022 12:43 PM, Richard Damon wrote:
>>>>>>>> On 7/23/22 12:37 PM, olcott wrote:
>>>>>>>>> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 7/23/22 12:05 PM, olcott wrote:
>>>>>>>>>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>>>>>>>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>>>>>>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>>>>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>>>>>>>>>> I am only referring to the correctly simulated input
>>>>>>>>>>>>>>>>>> to H(P,P) that
>>>>>>>>>>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>>>>>>>>>>> specifies an
>>>>>>>>>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You realise this is essentially the same as saying
>>>>>>>>>>>>>>>>> "Reality does not agree with my predictions, but my
>>>>>>>>>>>>>>>>> predictions are nevertheless correct" ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In programming language theory, semantics is the field
>>>>>>>>>>>>>>>> concerned with the rigorous mathematical study of the
>>>>>>>>>>>>>>>> meaning of programming languages.[1] It does so by
>>>>>>>>>>>>>>>> evaluating the meaning of syntactically valid strings
>>>>>>>>>>>>>>>> defined by a specific programming language, showing the
>>>>>>>>>>>>>>>> computation involved. In such a case that the evaluation
>>>>>>>>>>>>>>>> would be of syntactically invalid strings, the result
>>>>>>>>>>>>>>>> would be non-computation. Semantics describes the
>>>>>>>>>>>>>>>> processes a computer follows when executing a program in
>>>>>>>>>>>>>>>> that specific language.
>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The code proves that the correctly simulated input would
>>>>>>>>>>>>>>>> never reach its "return" instruction.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>>>>>>>>>> The correct execution trace of the correctly simulated
>>>>>>>>>>>>>>> input to H(P,P) conclusively proves that the simulated P
>>>>>>>>>>>>>>> cannot possibly reach its "return" instruction.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Humans having sufficient technical knowledge can see this
>>>>>>>>>>>>>>> and H can see this. To say that I am incorrect based on
>>>>>>>>>>>>>>> not having having sufficient technical knowledge is both
>>>>>>>>>>>>>>> incorrect and rude.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, because your proof isn't correct, even if you think it
>>>>>>>>>>>>>> is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> That you say that I am wrong on the basis that you do not
>>>>>>>>>>>>> know that the semantics of the x86 language proves that I
>>>>>>>>>>>>> am correct causes me to ignore almost all of your posts.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I have pointed out errors in the proofs that you just won't
>>>>>>>>>>>> make an effort to rebut,
>>>>>>>>>>>
>>>>>>>>>>> That is another thing that you do.
>>>>>>>>>>> I make one point and then you change the subject as your
>>>>>>>>>>> rebuttal.
>>>>>>>>>>
>>>>>>>>>> How is pointing out an error in your proof a change of subject?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I claim that X is true and your rebuttal is that you believe
>>>>>>>>> that Y is false.
>>>>>>>>
>>>>>>>> No, you claim X is true and try to give a proof, showing that
>>>>>>>> because of a, b, and c, X must be true.
>>>>>>>>
>>>>>>>> I point out that c isn't actually a true statement.
>>>>>>>>
>>>>>>>> That is a rebuttal.
>>>>>>>>
>>>>>>>> You answer has always been to just restate a, b, and c, and
>>>>>>>> never being able to give a source of ANYONE who supports you
>>>>>>>> that the point I ask about it actually true.
>>>>>>>>
>>>>>>>> Being unable to cite a source for ANY of your "rules" that you
>>>>>>>> start from says you don't actually HAVE a proof, just a
>>>>>>>> rhetorical argument. I think the issue is you just don't know
>>>>>>>> what an actual proof should look like. You use a lot of words
>>>>>>>> without understanding, which shows your ignorance.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>
>>>>>>>>> I am only referring to the fact that the semantics of the x86
>>>>>>>>> language conclusively proves that the correctly simulated input
>>>>>>>>> to H(P,P) by H cannot possibly ever reach the "return"
>>>>>>>>> instruction of P.
>>>>>>>>
>>>>>>>> Nope, doesn't show it. More of your made up "proof".
>>>>>>>>
>>>>>>>> Note, the key point of your arguement, and the point you get
>>>>>>>> wrong, actually has NOTHING to do with the x86 language.
>>>>>>>>
>>>>>>>> Simple point of observation, change you target processor for you
>>>>>>>> compiler and replace the emulatior with an emulator for that
>>>>>>>> processor, (and the appropriate references in your decider) and
>>>>>>>> the argument would be EXACTLY the same, so you aren't using
>>>>>>>> anything about the x86 itself
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The only relevant rebuttal is a step-by-step proof showing
>>>>>>>>> line-by-line of the source-code of P exactly how H diverges
>>>>>>>>> from its correct x86 emulation of its input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> First, you have it backwards. The PROOF needs to be the step by
>>>>>>>> step proof, a rebutal only needs to point out ONE error in the
>>>>>>>> proof.
>>>>>>>>
>>>>>>>> And I HAVE pointed out the error but you don't look at it.
>>>>>>>>
>>>>>>>> You claim a rule, often numbered (3) that says that non-halting
>>>>>>>> is proven by there not being a conditional instruction inside
>>>>>>>> the C function P to end the loop. There is no such rule, not one
>>>>>>>> that allows for H to be a decider that can decide to abort its
>>>>>>>> simulation.
>>>>>>>>
>>>>>>>> Until you can actually PROVE your rules, or at least cite a
>>>>>>>> source that vouches for it, your proof has become undone, based
>>>>>>>> on having an unproven (and untrue) premise. No amount of just
>>>>>>>> claiming it must be true removes that defect from your proof.
>>>>>>>> ANY premise of a proof that have been challenged must be proven
>>>>>>>> or the proof falls apart.
>>>>>>>>
>>>>>>>> The divergence in the correct x86 behavior is that the correct
>>>>>>>> x86 behavior of a call to H will be followed by the actual
>>>>>>>> behavior of the function H. You code errs in that in build on
>>>>>>>> logic that INCORRECTLY presumes that H will just unconditionally
>>>>>>>> simulate its input (so your rule 3 is correct) when that isn't
>>>>>>>> the actual behavior of H.
>>>>>>>>
>>>>>>>> The x86 behavior that H has seen does NOT provide any proof for
>>>>>>>> your claim, so by claiming it does just points out your lie.
>>>>>>> So then you are saying that the behavior shown in the correct
>>>>>>> execution trace of the input that H(P,P) correctly simulates is
>>>>>>> incorrect even though it is correct?
>>>>>>>
>>>>>>
>>>>>> Look again at your execution trace.
>>>>>>
>>>>>> All they say is that when P calls H(P,P) that H aborted it
>>>>>> simulation and decided that the input was non-halting.
>>>>>
>>>>> That is not all that it says. It also shows that P would never stop
>>>>> unless it was aborted.
>>>>>
>>>>
>>>> WHERE?
>>> You already admitted this dozens of times.
>>>
>>
>> Nope, not with THIS H. You make that mistake a lot, you confuse your H's.
>>
>
> This H correctly determines that its simulated input: (P,P) would never
> stop unless aborted.
>
>

On Saturday, 23 July 2022 at 19:57:19 UTC+2, olcott wrote:
> So then you are saying that the behavior shown in the correct execution
> trace of the input that H(P,P) correctly simulates is incorrect even
> though it is correct?

If you predict that I won't call you an idiot, then I will.
If you predict that I will call you an idiot, then I won't.

Is your "correct" prediction/simulation that I will call you an idiot correct, or incorrect?

On 7/23/2022 2:50 PM, Skep Dick wrote:
> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
>> This H correctly determines that its simulated input: (P,P) would never
>> stop unless aborted.
>
> Then how come P does the exact opposite of what H "correctly determines"?
>
> Every time!

It has been conclusively proven that the directly executed P(P)
specifies a different sequence of instructions than the correctly
simulated input to H(P,P) that H correctly simulates.

That you don't believe this proof because you don't understand the
execution trace that proves this is less than no actual rebuttal at all.

That you say that I am wrong entirely on the basis of your lack of
understanding of the x86 language is dishonest and rude.

The same thing can be seen at the C level so you have no excuse for this
mistake.

--
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 7/23/2022 2:59 PM, Skep Dick wrote:
> On Saturday, 23 July 2022 at 19:57:19 UTC+2, olcott wrote:
>> So then you are saying that the behavior shown in the correct execution
>> trace of the input that H(P,P) correctly simulates is incorrect even
>> though it is correct?
>
> If you predict that I won't call you an idiot, then I will.
> If you predict that I will call you an idiot, then I won't.
>
> Is your "correct" prediction/simulation that I will call you an idiot correct, or incorrect?

Drop this or I will block you

--
Copyright 2022 Pete Olcott

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

On Sat, 23 Jul 2022 15:08:40 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/23/2022 2:50 PM, Skep Dick wrote:
> > On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
> >> This H correctly determines that its simulated input: (P,P) would
> >> never stop unless aborted.
> >
> > Then how come P does the exact opposite of what H "correctly
> > determines"?
> >
> > Every time!
>
> It has been conclusively proven that the directly executed P(P)
> specifies a different sequence of instructions than the correctly
> simulated input to H(P,P) that H correctly simulates.
>
> That you don't believe this proof because you don't understand the
> execution trace that proves this is less than no actual rebuttal at
> all.
>
> That you say that I am wrong entirely on the basis of your lack of
> understanding of the x86 language is dishonest and rude.
>
> The same thing can be seen at the C level so you have no excuse for
> this mistake.

The mistake is yours: a SHD which exhibits infinite recursion which has
to be "aborted" before a correct decision can be made is obviously an
error.

/Flibble

On 7/23/2022 2:59 PM, Richard Damon wrote:
>
> On 7/23/22 3:46 PM, olcott wrote:
>> On 7/23/2022 2:41 PM, Richard Damon wrote:
>>>
>>> On 7/23/22 2:48 PM, olcott wrote:
>>>> On 7/23/2022 1:38 PM, Richard Damon wrote:
>>>>> On 7/23/22 2:26 PM, olcott wrote:
>>>>>> On 7/23/2022 1:20 PM, Richard Damon wrote:
>>>>>>> On 7/23/22 1:57 PM, olcott wrote:
>>>>>>>> On 7/23/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>> On 7/23/22 12:37 PM, olcott wrote:
>>>>>>>>>> On 7/23/2022 11:23 AM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 7/23/22 12:05 PM, olcott wrote:
>>>>>>>>>>>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/23/22 11:30 AM, olcott wrote:
>>>>>>>>>>>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>>>>>>>>>>>> I am only referring to the correctly simulated input
>>>>>>>>>>>>>>>>>>> to H(P,P) that
>>>>>>>>>>>>>>>>>>> never halts no matter what. The directly executed
>>>>>>>>>>>>>>>>>>> P(P) specifies an
>>>>>>>>>>>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You realise this is essentially the same as saying
>>>>>>>>>>>>>>>>>> "Reality does not agree with my predictions, but my
>>>>>>>>>>>>>>>>>> predictions are nevertheless correct" ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In programming language theory, semantics is the field
>>>>>>>>>>>>>>>>> concerned with the rigorous mathematical study of the
>>>>>>>>>>>>>>>>> meaning of programming languages.[1] It does so by
>>>>>>>>>>>>>>>>> evaluating the meaning of syntactically valid strings
>>>>>>>>>>>>>>>>> defined by a specific programming language, showing the
>>>>>>>>>>>>>>>>> computation involved. In such a case that the
>>>>>>>>>>>>>>>>> evaluation would be of syntactically invalid strings,
>>>>>>>>>>>>>>>>> the result would be non-computation. Semantics
>>>>>>>>>>>>>>>>> describes the processes a computer follows when
>>>>>>>>>>>>>>>>> executing a program in that specific language.
>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The code proves that the correctly simulated input
>>>>>>>>>>>>>>>>> would never reach its "return" instruction.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>>>>>>>>>>>> The correct execution trace of the correctly simulated
>>>>>>>>>>>>>>>> input to H(P,P) conclusively proves that the simulated P
>>>>>>>>>>>>>>>> cannot possibly reach its "return" instruction.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Humans having sufficient technical knowledge can see
>>>>>>>>>>>>>>>> this and H can see this. To say that I am incorrect
>>>>>>>>>>>>>>>> based on not having having sufficient technical
>>>>>>>>>>>>>>>> knowledge is both incorrect and rude.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, because your proof isn't correct, even if you think
>>>>>>>>>>>>>>> it is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That you say that I am wrong on the basis that you do not
>>>>>>>>>>>>>> know that the semantics of the x86 language proves that I
>>>>>>>>>>>>>> am correct causes me to ignore almost all of your posts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have pointed out errors in the proofs that you just won't
>>>>>>>>>>>>> make an effort to rebut,
>>>>>>>>>>>>
>>>>>>>>>>>> That is another thing that you do.
>>>>>>>>>>>> I make one point and then you change the subject as your
>>>>>>>>>>>> rebuttal.
>>>>>>>>>>>
>>>>>>>>>>> How is pointing out an error in your proof a change of subject?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I claim that X is true and your rebuttal is that you believe
>>>>>>>>>> that Y is false.
>>>>>>>>>
>>>>>>>>> No, you claim X is true and try to give a proof, showing that
>>>>>>>>> because of a, b, and c, X must be true.
>>>>>>>>>
>>>>>>>>> I point out that c isn't actually a true statement.
>>>>>>>>>
>>>>>>>>> That is a rebuttal.
>>>>>>>>>
>>>>>>>>> You answer has always been to just restate a, b, and c, and
>>>>>>>>> never being able to give a source of ANYONE who supports you
>>>>>>>>> that the point I ask about it actually true.
>>>>>>>>>
>>>>>>>>> Being unable to cite a source for ANY of your "rules" that you
>>>>>>>>> start from says you don't actually HAVE a proof, just a
>>>>>>>>> rhetorical argument. I think the issue is you just don't know
>>>>>>>>> what an actual proof should look like. You use a lot of words
>>>>>>>>> without understanding, which shows your ignorance.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>>>>
>>>>>>>>>> I am only referring to the fact that the semantics of the x86
>>>>>>>>>> language conclusively proves that the correctly simulated
>>>>>>>>>> input to H(P,P) by H cannot possibly ever reach the "return"
>>>>>>>>>> instruction of P.
>>>>>>>>>
>>>>>>>>> Nope, doesn't show it. More of your made up "proof".
>>>>>>>>>
>>>>>>>>> Note, the key point of your arguement, and the point you get
>>>>>>>>> wrong, actually has NOTHING to do with the x86 language.
>>>>>>>>>
>>>>>>>>> Simple point of observation, change you target processor for
>>>>>>>>> you compiler and replace the emulatior with an emulator for
>>>>>>>>> that processor, (and the appropriate references in your
>>>>>>>>> decider) and the argument would be EXACTLY the same, so you
>>>>>>>>> aren't using anything about the x86 itself
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The only relevant rebuttal is a step-by-step proof showing
>>>>>>>>>> line-by-line of the source-code of P exactly how H diverges
>>>>>>>>>> from its correct x86 emulation of its input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> First, you have it backwards. The PROOF needs to be the step by
>>>>>>>>> step proof, a rebutal only needs to point out ONE error in the
>>>>>>>>> proof.
>>>>>>>>>
>>>>>>>>> And I HAVE pointed out the error but you don't look at it.
>>>>>>>>>
>>>>>>>>> You claim a rule, often numbered (3) that says that non-halting
>>>>>>>>> is proven by there not being a conditional instruction inside
>>>>>>>>> the C function P to end the loop. There is no such rule, not
>>>>>>>>> one that allows for H to be a decider that can decide to abort
>>>>>>>>> its simulation.
>>>>>>>>>
>>>>>>>>> Until you can actually PROVE your rules, or at least cite a
>>>>>>>>> source that vouches for it, your proof has become undone, based
>>>>>>>>> on having an unproven (and untrue) premise. No amount of just
>>>>>>>>> claiming it must be true removes that defect from your proof.
>>>>>>>>> ANY premise of a proof that have been challenged must be proven
>>>>>>>>> or the proof falls apart.
>>>>>>>>>
>>>>>>>>> The divergence in the correct x86 behavior is that the correct
>>>>>>>>> x86 behavior of a call to H will be followed by the actual
>>>>>>>>> behavior of the function H. You code errs in that in build on
>>>>>>>>> logic that INCORRECTLY presumes that H will just
>>>>>>>>> unconditionally simulate its input (so your rule 3 is correct)
>>>>>>>>> when that isn't the actual behavior of H.
>>>>>>>>>
>>>>>>>>> The x86 behavior that H has seen does NOT provide any proof for
>>>>>>>>> your claim, so by claiming it does just points out your lie.
>>>>>>>> So then you are saying that the behavior shown in the correct
>>>>>>>> execution trace of the input that H(P,P) correctly simulates is
>>>>>>>> incorrect even though it is correct?
>>>>>>>>
>>>>>>>
>>>>>>> Look again at your execution trace.
>>>>>>>
>>>>>>> All they say is that when P calls H(P,P) that H aborted it
>>>>>>> simulation and decided that the input was non-halting.
>>>>>>
>>>>>> That is not all that it says. It also shows that P would never
>>>>>> stop unless it was aborted.
>>>>>>
>>>>>
>>>>> WHERE?
>>>> You already admitted this dozens of times.
>>>>
>>>
>>> Nope, not with THIS H. You make that mistake a lot, you confuse your
>>> H's.
>>>
>>
>> This H correctly determines that its simulated input: (P,P) would
>> never stop unless aborted.
>>
>>
>
> HOW?
You already acknowledged that you know how, many times.

On Saturday, 23 July 2022 at 22:09:20 UTC+2, olcott wrote:
> On 7/23/2022 2:59 PM, Skep Dick wrote:
> > On Saturday, 23 July 2022 at 19:57:19 UTC+2, olcott wrote:
> >> So then you are saying that the behavior shown in the correct execution
> >> trace of the input that H(P,P) correctly simulates is incorrect even
> >> though it is correct?
> >
> > If you predict that I won't call you an idiot, then I will.
> > If you predict that I will call you an idiot, then I won't.
> >
> > Is your "correct" prediction/simulation that I will call you an idiot correct, or incorrect?
> Drop this or I will block you

You can't block me. This is Usenet.

My identity is undecidable.

On Saturday, 23 July 2022 at 22:08:48 UTC+2, olcott wrote:
> On 7/23/2022 2:50 PM, Skep Dick wrote:
> > On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
> >> This H correctly determines that its simulated input: (P,P) would never
> >> stop unless aborted.
> >
> > Then how come P does the exact opposite of what H "correctly determines"?
> >
> > Every time!
> It has been conclusively proven that the directly executed P(P)
> specifies a different sequence of instructions than the correctly
> simulated input to H(P,P) that H correctly simulates.
>
> That you don't believe this proof because you don't understand the
> execution trace that proves this is less than no actual rebuttal at all.
>
> That you say that I am wrong entirely on the basis of your lack of
> understanding of the x86 language is dishonest and rude.

That you say that it has been "conclusively proven", and that the simulation is "correct" is entirely based on your opinion.

It's on the basis of your lack of understanding of computation. It is dishonest and rude.

On Saturday, 23 July 2022 at 22:08:48 UTC+2, olcott wrote:
> On 7/23/2022 2:50 PM, Skep Dick wrote:
> > On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
> >> This H correctly determines that its simulated input: (P,P) would never
> >> stop unless aborted.
> >
> > Then how come P does the exact opposite of what H "correctly determines"?
> >
> > Every time!
> It has been conclusively proven that the directly executed P(P)
> specifies a different sequence of instructions than the correctly
> simulated input to H(P,P) that H correctly simulates.
>
> That you don't believe this proof because you don't understand the
> execution trace that proves this is less than no actual rebuttal at all.
>
> That you say that I am wrong entirely on the basis of your lack of
> understanding of the x86 language is dishonest and rude.
>
> The same thing can be seen at the C level so you have no excuse for this
> mistake.

It has been conclusively and correctly proven (on the basis of the x86 language) that 1+1=3 !!!

#include <stdio.h>
int plus(int a, int b){
if ( (a ==1) && (b==1)){
return 3;
}
return a+b;
} int main(){
printf("1 + 1 = %d \n", plus(1,1));
}

➜ ~ gcc h.c
➜ ~ ./a.out
1 + 1 = 3

On 7/23/22 4:08 PM, olcott wrote:
> On 7/23/2022 2:50 PM, Skep Dick wrote:
>> On Saturday, 23 July 2022 at 21:46:34 UTC+2, olcott wrote:
>>> This H correctly determines that its simulated input: (P,P) would never
>>> stop unless aborted.
>>
>> Then how come P does the exact opposite of what H "correctly determines"?
>>
>> Every time!
>
> It has been conclusively proven that the directly executed P(P)
> specifies a different sequence of instructions than the correctly
> simulated input to H(P,P) that H correctly simulates.

Then you are admitting that P is not the "impossible program" of the
proof, so your setup is NOT a counter example.

>
> That you don't believe this proof because you don't understand the
> execution trace that proves this is less than no actual rebuttal at all.

The trace proves no such thing. Here is a basic of the x86 question for
you, what is the first instruction executed in P(P) that differs from
the correct simulation of H(P,P)?

>
> That you say that I am wrong entirely on the basis of your lack of
> understanding of the x86 language is dishonest and rude.
>

So, show your great knowledge and answer the question, what is the first
instruction that was correctly simulated that differs from the same
instruction in the actual execution?

How and Why is the results different.

FAILURE TO ANSWER PROVES YOU ARE A LIAR.

> The same thing can be seen at the C level so you have no excuse for this
> mistake.
>