Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> There then seems to be confusion between "nested simulation" and
> "recursion" which isn't confined to PO. It's not clear exactly what is
> going on because we don't have the source of H and questions about how
> H distinguishes its own output from the output of the program it is
> simulating haven't been answered.

What is your take on why PO is hiding H? Even the instructions of H are
never shown in a trace. I ask because you are invariably generous in
your replies and I wonder what the generous interpretation of hiding
the one thing, H itself, that would answer all question immediately is.

--
Ben.

On 5/25/2022 2:16 AM, Malcolm McLean wrote:
> On Wednesday, 25 May 2022 at 04:05:50 UTC+1, Dennis Bush wrote:
>> On Tuesday, May 24, 2022 at 11:00:22 PM UTC-4, olcott wrote:
>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply disagreement
>>>>>>>>>>>>>>>>>>>>> with an
>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
>>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret" instruction
>>>>>>>>>>>>>>>>>>>> is because
>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does not
>>>>>>>>>>>>>>>>>>>> exist in
>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation of
>>>>>>>>>>>>>>>>>>> the machine
>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction of
>>>>>>>>>>>>>>>>>>> P in 0 to
>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be a
>>>>>>>>>>>>>>>>>> decider or it
>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You have to actually stick with the words that I actually
>>>>>>>>>>>>>>>>> said as the
>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of
>>>>>>>>>>>>>>>>> P in 0 to
>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
>>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction that H
>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86 source
>>>>>>>>>>>>>> code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes in
>>>>>>>>>>>>>> its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking that
>>>>>>>>>>>>>> it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean that
>>>>>>>>>>>>>>> either one
>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does not
>>>>>>>>>>>>>> perform a correct simulation of its input.
>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>>> of the
>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>
>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not correct
>>>>>>>>>>>> because it aborts too soon as demonstrated by Hb(Pa,Pa)==1
>>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>>> is not
>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>
>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>> specifies to
>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>
>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>> You continue to be a liar.
>>>>>>>>
>>>>>>>> So no rebuttal, which means you're unable to. Which means you admit
>>>>>>>> I'm right.
>>>>>>>>
>>>>>>>> So what are you going to do with yourself now that you're no longer
>>>>>>>> working on the halting problem?
>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>
>>>>>>> Now that I have all of the objections boiled down to simply disagreeing
>>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>>> that I
>>>>>>> am correct.
>>>>>>
>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>
>>>>> Shows that they are not basing their decision on the execution trace
>>>>> that is actually specified by the x86 source-code of P.
>>>>>
>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P) and
>>>>> H1(P,P). You can't even manage to tell the truth about the names of
>>>>> functions.
>>>>>
>>>>
>>>> The names really make that much difference?
>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>> executed showing every detail of their correct simulation of their inputs.
>>>
>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
>>> down to specifics.
>> No, Ha is a *specific* decider with a fixed algorithm (the one you claim can detect infinite simulation in Pn(Pn)), as is Hb also a *specific* decider which is related to Ha.
>>> The only place that Dennis can hide his deception is
>>> in deliberate vagnueness.
>> You're projecting once again. You sometimes say "H" and "P" when you mean Ha and Pa, and sometimes say "H" and "P" when you mean Hn and Pn. The one hiding behind vagueness is you.
>
> H shows the [correct] execution trace of P, until P calls H, at which point the trace ceases.
> H is now simulating H, and the simulated H outputs the next nine instructions of P.
>
> It isn't made clear from the trace that this is not the output of the simulator, but
> output of the simulated program.
>
> There then seems to be confusion between "nested simulation" and "recursion" which
Nested simulation derives the same behavior pattern as recursion.

On 5/25/2022 8:14 AM, Ben wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> There then seems to be confusion between "nested simulation" and
>> "recursion" which isn't confined to PO. It's not clear exactly what is
>> going on because we don't have the source of H and questions about how
>> H distinguishes its own output from the output of the program it is
>> simulating haven't been answered.
>
> What is your take on why PO is hiding H? Even the instructions of H are
> never shown in a trace. I ask because you are invariably generous in
> your replies and I wonder what the generous interpretation of hiding
> the one thing, H itself, that would answer all question immediately is.
>

As I have said many hundreds of times you can verify that I am correct
on the basis of what I provided.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

In fact you actually only need much less than I provided to prove that I
am correct. The following can be correctly determined entirely on the
basis of the above x86 source-code for P.

It is an easily verified fact that the correct x86 emulation of the
input to H(P,P) would never reach the "ret" instruction of P in 0 to
infinity steps of the correct x86 emulation of P by H.

If you don't understand this then you won't understand something that is
1000-fold more complicated.

If I show you something that is 1000-fold more complicated now you will
have hundreds of other totally extraneous distractions that prevent you
from paying attention to my simple proof. You will confuse your own lack
of understanding of this complexity as dozens of more errors that must
be investigated before we can go back to the simple proof.

Because this simplest proof so obviously proves my point it seems
unreasonable for me to believe that others do not fully understand it.
Thus when they disagree with it I can't believe that they don't know
they are lying.

--
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 5/25/2022 6:01 AM, Richard Damon wrote:
> On 5/24/22 11:00 PM, olcott wrote:
>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>> On 5/24/22 10:50 PM, olcott wrote:
>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
>>>>>>>>>>>>>>>>> a decider or it
>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>> of the
>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>
>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>> is not
>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>
>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>> specifies to
>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>> and H1 is correct.
>>>>>>>>>
>>>>>>>>> Then by this same logic you agree that
>>>>>>>> You continue to be a liar.
>>>>>>>
>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>> admit I'm right.
>>>>>>>
>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>> longer working on the halting problem?
>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>
>>>>>> Now that I have all of the objections boiled down to simply
>>>>>> disagreeing
>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>> that I
>>>>>> am correct.
>>>>>
>>>>> The verifiable fact that everyone (except you) can see is that
>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>
>>>> Shows that they are not basing their decision on the execution trace
>>>> that is actually specified by the x86 source-code of P.
>>>>
>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
>>>> and H1(P,P). You can't even manage to tell the truth about the names
>>>> of functions.
>>>>
>>>
>>> The names really make that much difference?
>> H(P,P) and H1(P,P) are fully operational C functions that can be
>> executed showing every detail of their correct simulation of their
>> inputs.
>>
>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
>> down to specifics. The only place that Dennis can hide his deception
>> is in deliberate vagnueness.
>>
>
> So, you don't understand what peeople are saying. For you it is just
> that you are right and others are wrong.

On Wednesday, May 25, 2022 at 10:03:15 AM UTC-4, olcott wrote:
> On 5/25/2022 8:14 AM, Ben wrote:
> > Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >
> >> There then seems to be confusion between "nested simulation" and
> >> "recursion" which isn't confined to PO. It's not clear exactly what is
> >> going on because we don't have the source of H and questions about how
> >> H distinguishes its own output from the output of the program it is
> >> simulating haven't been answered.
> >
> > What is your take on why PO is hiding H? Even the instructions of H are
> > never shown in a trace. I ask because you are invariably generous in
> > your replies and I wonder what the generous interpretation of hiding
> > the one thing, H itself, that would answer all question immediately is.
> >
> As I have said many hundreds of times you can verify that I am correct
> on the basis of what I provided.
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> In fact you actually only need much less than I provided to prove that I
> am correct. The following can be correctly determined entirely on the
> basis of the above x86 source-code for P.
> It is an easily verified fact that the correct x86 emulation of the
> input to H(P,P) would never reach the "ret" instruction of P in 0 to
> infinity steps of the correct x86 emulation of P by H.

This is exactly why I use Ha/Hn and Pa/Pn, because you're deceptively using H and P to refer to multiple different computations.

If H aborts its input then it does not simulate for an infinite number of steps, so then it is Ha and the P that calls it is Pa. Ha(Pa,Pa)==0 is not correct because it aborts too soon. Hb(Pa,Pa)==1 and H1(Pa,Pa)==1 both demonstrate this fact by simulating this same input to a final state. Remember, there is NO EXCEPTION FOR SELF REFERENCE.

If H does not abort its input, then H is Hn and the P that calls it is Pn. Pn(Pn) does not halt but then neither does Hn(Pn,Pn) and thus fails to make a decision.

So when you say: the input to H(P,P) would never reach the "ret" instruction of P in 0 to infinity steps of the correct x86 emulation of P by H.

What you're actually saying is that Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.

Let's also note that your above statement assumes that H/Ha/Hn performs a correct simulation, which is exactly what you're trying to prove. So what you're saying is "H is correct because H is correct" which is nonsense.

> If you don't understand this then you won't understand something that is
> 1000-fold more complicated.
>
> If I show you something that is 1000-fold more complicated now you will
> have hundreds of other totally extraneous distractions that prevent you
> from paying attention to my simple proof. You will confuse your own lack
> of understanding of this complexity as dozens of more errors that must
> be investigated before we can go back to the simple proof.
>
> Because this simplest proof so obviously proves my point it seems
> unreasonable for me to believe that others do not fully understand it.
> Thus when they disagree with it I can't believe that they don't know
> they are lying.
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
> On 5/25/2022 6:01 AM, Richard Damon wrote:
> > On 5/24/22 11:00 PM, olcott wrote:
> >> On 5/24/2022 9:54 PM, Richard Damon wrote:
> >>> On 5/24/22 10:50 PM, olcott wrote:
> >>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
> >>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
> >>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
> >>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
> >>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
> >>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
> >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
> >>>>>>>>>>>>>>>>>>>> disagreement with an
> >>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
> >>>>>>>>>>>>>>>>>>>> with a
> >>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
> >>>>>>>>>>>>>>>>>>>> that H(P,P)==0
> >>>>>>>>>>>>>>>>>>>> is correct:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
> >>>>>>>>>>>>>>>>>>>> input pair of
> >>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
> >>>>>>>>>>>>>>>>>>>> and criterion
> >>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
> >>>>>>>>>>>>>>>>>>>> reach its "ret"
> >>>>>>>>>>>>>>>>>>>> instruction.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
> >>>>>>>>>>>>>>>>>>> instruction is because
> >>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
> >>>>>>>>>>>>>>>>>>> not exist in
> >>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
> >>>>>>>>>>>>>>>>>>> erroneous.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
> >>>>>>>>>>>>>>>>>> function named H
> >>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
> >>>>>>>>>>>>>>>>>> of the machine
> >>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
> >>>>>>>>>>>>>>>>>> of P in 0 to
> >>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
> >>>>>>>>>>>>>>>>> a decider or it
> >>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
> >>>>>>>>>>>>>>>>> have introduced
> >>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
> >>>>>>>>>>>>>>>>> merely a tool for
> >>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
> >>>>>>>>>>>>>>>>> proofs you are
> >>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You have to actually stick with the words that I
> >>>>>>>>>>>>>>>> actually said as the
> >>>>>>>>>>>>>>>> basis of any rebuttal.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
> >>>>>>>>>>>>>>>> emulation of the
> >>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
> >>>>>>>>>>>>>>>> of P in 0 to
> >>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
> >>>>>>>>>>>>>>> you know this
> >>>>>>>>>>>>>>> is a lie.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
> >>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
> >>>>>>>>>>>>>> that H
> >>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
> >>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
> >>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
> >>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
> >>>>>>>>>>>>> Ha3(N,5)==0 is correct.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
> >>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The only possible way for a simulator to actually be
> >>>>>>>>>>>>>> incorrect is that
> >>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
> >>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
> >>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
> >>>>>>>>>>>>> happens with Ha(Pa,Pa).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
> >>>>>>>>>>>>>> as the
> >>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
> >>>>>>>>>>>>>> that either one
> >>>>>>>>>>>>>> of them is incorrect.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
> >>>>>>>>>>>>> not perform a correct simulation of its input.
> >>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
> >>>>>>>>>>>> of the
> >>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
> >>>>>>>>>>>
> >>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
> >>>>>>>>>>> correct because it aborts too soon as demonstrated by
> >>>>>>>>>>> Hb(Pa,Pa)==1
> >>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
> >>>>>>>>>> is not
> >>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
> >>>>>>>>>>
> >>>>>>>>>> It is the actual behavior that the x86 source-code of P
> >>>>>>>>>> specifies to
> >>>>>>>>>> H(P,P) and H1(P,P)
> >>>>>>>>>> that determines whether or not its simulation by H
> >>>>>>>>>> and H1 is correct.
> >>>>>>>>>
> >>>>>>>>> Then by this same logic you agree that
> >>>>>>>> You continue to be a liar.
> >>>>>>>
> >>>>>>> So no rebuttal, which means you're unable to. Which means you
> >>>>>>> admit I'm right.
> >>>>>>>
> >>>>>>> So what are you going to do with yourself now that you're no
> >>>>>>> longer working on the halting problem?
> >>>>>> Escalate the review to a higher caliber reviewer.
> >>>>>>
> >>>>>> Now that I have all of the objections boiled down to simply
> >>>>>> disagreeing
> >>>>>> with two verifiable facts higher caliber reviewers should confirm
> >>>>>> that I
> >>>>>> am correct.
> >>>>>
> >>>>> The verifiable fact that everyone (except you) can see is that
> >>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
> >>>>
> >>>> Shows that they are not basing their decision on the execution trace
> >>>> that is actually specified by the x86 source-code of P.
> >>>>
> >>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
> >>>> and H1(P,P). You can't even manage to tell the truth about the names
> >>>> of functions.
> >>>>
> >>>
> >>> The names really make that much difference?
> >> H(P,P) and H1(P,P) are fully operational C functions that can be
> >> executed showing every detail of their correct simulation of their
> >> inputs.
> >>
> >> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
> >> down to specifics. The only place that Dennis can hide his deception
> >> is in deliberate vagnueness.
> >>
> >
> > So, you don't understand what peeople are saying. For you it is just
> > that you are right and others are wrong.
> Ha(Pa,Pa) is fully operational code named H(P,P)
> Hb(Pa,Pa) is fully operational code named H1(P,P)
>
> I can prove that the actual behavior of the correct x86 emulation of
> actual input to H(P,P) never reaches its "ret" instruction with a full
> execution trace of P.
>
> I can prove that the actual behavior of the correct x86 emulation of
> actual input to H1(P,P) reaches its "ret" instruction with a full
> execution trace of P.
>
> I can prove that both of these execution traces are correct on the basis
> of the behavior that is specified by the x86 source-code for P.
>
> We can't do any of these things with the purely imaginary Ha(Pa,Pa) and
> Hb(Pa,Pa). Dennis wants to keep things vague so that his deceptive and
> fake rebuttal is not exposed for what it is.

On 5/25/2022 6:04 AM, Richard Damon wrote:
>
> On 5/24/22 11:04 PM, olcott wrote:
>> On 5/24/2022 9:57 PM, Dennis Bush wrote:
>>> On Tuesday, May 24, 2022 at 10:50:51 PM UTC-4, olcott wrote:
>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
>>>>>>>>>>>>>>>>> a decider or it
>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>> of the
>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>
>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>> is not
>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>
>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>> specifies to
>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>> and H1 is correct.
>>>>>>>>>
>>>>>>>>> Then by this same logic you agree that
>>>>>>>> You continue to be a liar.
>>>>>>>
>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>> admit I'm right.
>>>>>>>
>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>> longer working on the halting problem?
>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>
>>>>>> Now that I have all of the objections boiled down to simply
>>>>>> disagreeing
>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>> that I
>>>>>> am correct.
>>>>>
>>>>> The verifiable fact that everyone (except you) can see is that
>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>> Shows that they are not basing their decision on the execution trace
>>>> that is actually specified by the x86 source-code of P.
>>>>
>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa)
>>>
>>> There absolutely is because I stipulated them to be so.
>>
>> Then run Hb(Pa,Pa) and show me the excution trace of its input.
>> You make things deliberately vague to hide your deception.
>>
>> I can prove that the behavior of the input to H(P,P) and H1(P,P) is
>> not the same and this can be proved to be correct on the basis of the
>> behavior that the x86 source-code of P specifies.
>>
>
> Then you prove your system inconsistent, and the inputs are the
> representation of the same computation, and thus must always be the same
> thing.

On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
> On 5/25/2022 6:01 AM, Richard Damon wrote:
> > On 5/24/22 11:00 PM, olcott wrote:
> >> On 5/24/2022 9:54 PM, Richard Damon wrote:
> >>> On 5/24/22 10:50 PM, olcott wrote:
> >>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
> >>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
> >>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
> >>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
> >>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
> >>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
> >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
> >>>>>>>>>>>>>>>>>>>> disagreement with an
> >>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
> >>>>>>>>>>>>>>>>>>>> with a
> >>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
> >>>>>>>>>>>>>>>>>>>> that H(P,P)==0
> >>>>>>>>>>>>>>>>>>>> is correct:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
> >>>>>>>>>>>>>>>>>>>> input pair of
> >>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
> >>>>>>>>>>>>>>>>>>>> and criterion
> >>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
> >>>>>>>>>>>>>>>>>>>> reach its "ret"
> >>>>>>>>>>>>>>>>>>>> instruction.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
> >>>>>>>>>>>>>>>>>>> instruction is because
> >>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
> >>>>>>>>>>>>>>>>>>> not exist in
> >>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
> >>>>>>>>>>>>>>>>>>> erroneous.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
> >>>>>>>>>>>>>>>>>> function named H
> >>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
> >>>>>>>>>>>>>>>>>> of the machine
> >>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
> >>>>>>>>>>>>>>>>>> of P in 0 to
> >>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
> >>>>>>>>>>>>>>>>> a decider or it
> >>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
> >>>>>>>>>>>>>>>>> have introduced
> >>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
> >>>>>>>>>>>>>>>>> merely a tool for
> >>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
> >>>>>>>>>>>>>>>>> proofs you are
> >>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You have to actually stick with the words that I
> >>>>>>>>>>>>>>>> actually said as the
> >>>>>>>>>>>>>>>> basis of any rebuttal.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
> >>>>>>>>>>>>>>>> emulation of the
> >>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
> >>>>>>>>>>>>>>>> of P in 0 to
> >>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
> >>>>>>>>>>>>>>> you know this
> >>>>>>>>>>>>>>> is a lie.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
> >>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
> >>>>>>>>>>>>>> that H
> >>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
> >>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
> >>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
> >>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
> >>>>>>>>>>>>> Ha3(N,5)==0 is correct.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
> >>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The only possible way for a simulator to actually be
> >>>>>>>>>>>>>> incorrect is that
> >>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
> >>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
> >>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
> >>>>>>>>>>>>> happens with Ha(Pa,Pa).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
> >>>>>>>>>>>>>> as the
> >>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
> >>>>>>>>>>>>>> that either one
> >>>>>>>>>>>>>> of them is incorrect.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
> >>>>>>>>>>>>> not perform a correct simulation of its input.
> >>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
> >>>>>>>>>>>> of the
> >>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
> >>>>>>>>>>>
> >>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
> >>>>>>>>>>> correct because it aborts too soon as demonstrated by
> >>>>>>>>>>> Hb(Pa,Pa)==1
> >>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
> >>>>>>>>>> is not
> >>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
> >>>>>>>>>>
> >>>>>>>>>> It is the actual behavior that the x86 source-code of P
> >>>>>>>>>> specifies to
> >>>>>>>>>> H(P,P) and H1(P,P)
> >>>>>>>>>> that determines whether or not its simulation by H
> >>>>>>>>>> and H1 is correct.
> >>>>>>>>>
> >>>>>>>>> Then by this same logic you agree that
> >>>>>>>> You continue to be a liar.
> >>>>>>>
> >>>>>>> So no rebuttal, which means you're unable to. Which means you
> >>>>>>> admit I'm right.
> >>>>>>>
> >>>>>>> So what are you going to do with yourself now that you're no
> >>>>>>> longer working on the halting problem?
> >>>>>> Escalate the review to a higher caliber reviewer.
> >>>>>>
> >>>>>> Now that I have all of the objections boiled down to simply
> >>>>>> disagreeing
> >>>>>> with two verifiable facts higher caliber reviewers should confirm
> >>>>>> that I
> >>>>>> am correct.
> >>>>>
> >>>>> The verifiable fact that everyone (except you) can see is that
> >>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
> >>>>
> >>>> Shows that they are not basing their decision on the execution trace
> >>>> that is actually specified by the x86 source-code of P.
> >>>>
> >>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
> >>>> and H1(P,P). You can't even manage to tell the truth about the names
> >>>> of functions.
> >>>>
> >>>
> >>> The names really make that much difference?
> >> H(P,P) and H1(P,P) are fully operational C functions that can be
> >> executed showing every detail of their correct simulation of their
> >> inputs.
> >>
> >> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
> >> down to specifics. The only place that Dennis can hide his deception
> >> is in deliberate vagnueness.
> >>
> >
> > So, you don't understand what peeople are saying. For you it is just
> > that you are right and others are wrong.
> Ha(Pa,Pa) is fully operational code named H(P,P)
> Hb(Pa,Pa) is fully operational code named H1(P,P)
>
> I can prove that the actual behavior of the correct x86 emulation of
> actual input to H(P,P) never reaches its "ret" instruction with a full
> execution trace of P.
>
> I can prove that the actual behavior of the correct x86 emulation of
> actual input to H1(P,P) reaches its "ret" instruction with a full
> execution trace of P.
>
> I can prove that both of these execution traces are correct on the basis
> of the behavior that is specified by the x86 source-code for P.

On 5/25/2022 6:06 AM, Richard Damon wrote:
> On 5/24/22 11:12 PM, olcott wrote:
>> On 5/24/2022 10:10 PM, Dennis Bush wrote:
>>> On Tuesday, May 24, 2022 at 11:05:05 PM UTC-4, olcott wrote:
>>>> On 5/24/2022 9:57 PM, Dennis Bush wrote:
>>>>> On Tuesday, May 24, 2022 at 10:50:51 PM UTC-4, olcott wrote:
>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software
>>>>>>>>>>>>>>>>>>>>>> engineer with a
>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates
>>>>>>>>>>>>>>>>>>>>>> its input pair of
>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function
>>>>>>>>>>>>>>>>>>>>>> P and criterion
>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would
>>>>>>>>>>>>>>>>>>>>>> never reach its "ret"
>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to
>>>>>>>>>>>>>>>>>>> be a decider or it
>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as
>>>>>>>>>>>>>>>>>>> you have introduced
>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
>>>>>>>>>>>>>>>>>> instruction of P in 0 to
>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this
>>>>>>>>>>>>>>>>> happening, you know this
>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator
>>>>>>>>>>>>>>>>> can.
>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of
>>>>>>>>>>>>>>>> P specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly
>>>>>>>>>>>>>>> what happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting
>>>>>>>>>>>>>>>> behavior as the
>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>> By this same despicable liar reasoning we can know that
>>>>>>>>>>>> Fluffy is not
>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>
>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>> specifies to
>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>
>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>> You continue to be a liar.
>>>>>>>>>
>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>> admit I'm right.
>>>>>>>>>
>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>> longer working on the halting problem?
>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>
>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>> disagreeing
>>>>>>>> with two verifiable facts higher caliber reviewers should
>>>>>>>> confirm that I
>>>>>>>> am correct.
>>>>>>>
>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>> Shows that they are not basing their decision on the execution trace
>>>>>> that is actually specified by the x86 source-code of P.
>>>>>>
>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa)
>>>>>
>>>>> There absolutely is because I stipulated them to be so.
>>>> Then run Hb(Pa,Pa) and show me the excution trace of its input.
>>>
>>> Give me your code and I'll be happy to.
>>
>> If you would at least quit lying about the names of functions I can
>> provide a trace of H(P,P) and H1(P,P).
>>
>
> The fact that you call it a lie to lable a specific version of one of
> your class of functions with a name shows that you don't understand what
> you have been talking about.
>

On 5/25/2022 9:15 AM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 10:03:15 AM UTC-4, olcott wrote:
>> On 5/25/2022 8:14 AM, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> There then seems to be confusion between "nested simulation" and
>>>> "recursion" which isn't confined to PO. It's not clear exactly what is
>>>> going on because we don't have the source of H and questions about how
>>>> H distinguishes its own output from the output of the program it is
>>>> simulating haven't been answered.
>>>
>>> What is your take on why PO is hiding H? Even the instructions of H are
>>> never shown in a trace. I ask because you are invariably generous in
>>> your replies and I wonder what the generous interpretation of hiding
>>> the one thing, H itself, that would answer all question immediately is.
>>>
>> As I have said many hundreds of times you can verify that I am correct
>> on the basis of what I provided.
>>
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax // push P
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx // push P
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> In fact you actually only need much less than I provided to prove that I
>> am correct. The following can be correctly determined entirely on the
>> basis of the above x86 source-code for P.
>> It is an easily verified fact that the correct x86 emulation of the
>> input to H(P,P) would never reach the "ret" instruction of P in 0 to
>> infinity steps of the correct x86 emulation of P by H.
>
> This is exactly why I use Ha/Hn and Pa/Pn, because you're deceptively using H and P to refer to multiple different computations.
H(P,P) is a fully operational version of what you refer to as Ha(Pa,Pa)
H1(P,P) is a fully operational version of what you refer to as Hb(Pa,Pa)

I can prove that H(P,P)==0 and H1(P,P)==1 by providing the full
execution trace of the correct x86 emulation of their input.

I can prove that this is a correct x86 execution trace of their input on
the basis of the behavior that the x86 source-code of P specifies.

With your imaginary functions you can continue to deceptively
incorrectly imagine that they do not do what I claim.

In the bright light of day of the actual execution of H(P,P) and H1(P,P)
it becomes totally obvious that you are incorrect.

--
Copyright 2022 Pete Olcott

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

On 5/25/2022 9:16 AM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
>> On 5/25/2022 6:01 AM, Richard Damon wrote:
>>> On 5/24/22 11:00 PM, olcott wrote:
>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
>>>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
>>>>>>>>>>>>>>>>>>> a decider or it
>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
>>>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>>>> is not
>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>
>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>> specifies to
>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>
>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>> You continue to be a liar.
>>>>>>>>>
>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>> admit I'm right.
>>>>>>>>>
>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>> longer working on the halting problem?
>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>
>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>> disagreeing
>>>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>>>> that I
>>>>>>>> am correct.
>>>>>>>
>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>
>>>>>> Shows that they are not basing their decision on the execution trace
>>>>>> that is actually specified by the x86 source-code of P.
>>>>>>
>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
>>>>>> and H1(P,P). You can't even manage to tell the truth about the names
>>>>>> of functions.
>>>>>>
>>>>>
>>>>> The names really make that much difference?
>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>>> executed showing every detail of their correct simulation of their
>>>> inputs.
>>>>
>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
>>>> down to specifics. The only place that Dennis can hide his deception
>>>> is in deliberate vagnueness.
>>>>
>>>
>>> So, you don't understand what peeople are saying. For you it is just
>>> that you are right and others are wrong.
>> Ha(Pa,Pa) is fully operational code named H(P,P)
>> Hb(Pa,Pa) is fully operational code named H1(P,P)
>>
>> I can prove that the actual behavior of the correct x86 emulation of
>> actual input to H(P,P) never reaches its "ret" instruction with a full
>> execution trace of P.
>>
>> I can prove that the actual behavior of the correct x86 emulation of
>> actual input to H1(P,P) reaches its "ret" instruction with a full
>> execution trace of P.
>>
>> I can prove that both of these execution traces are correct on the basis
>> of the behavior that is specified by the x86 source-code for P.
>>
>> We can't do any of these things with the purely imaginary Ha(Pa,Pa) and
>> Hb(Pa,Pa). Dennis wants to keep things vague so that his deceptive and
>> fake rebuttal is not exposed for what it is.
>
> Projection. You're the one keeping thing vague by not making it clear exactly which computation you're referring to.

On 5/25/2022 9:20 AM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
>> On 5/25/2022 6:01 AM, Richard Damon wrote:
>>> On 5/24/22 11:00 PM, olcott wrote:
>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
>>>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
>>>>>>>>>>>>>>>>>>> a decider or it
>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
>>>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>>>> is not
>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>
>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>> specifies to
>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>
>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>> You continue to be a liar.
>>>>>>>>>
>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>> admit I'm right.
>>>>>>>>>
>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>> longer working on the halting problem?
>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>
>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>> disagreeing
>>>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>>>> that I
>>>>>>>> am correct.
>>>>>>>
>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>
>>>>>> Shows that they are not basing their decision on the execution trace
>>>>>> that is actually specified by the x86 source-code of P.
>>>>>>
>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
>>>>>> and H1(P,P). You can't even manage to tell the truth about the names
>>>>>> of functions.
>>>>>>
>>>>>
>>>>> The names really make that much difference?
>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>>> executed showing every detail of their correct simulation of their
>>>> inputs.
>>>>
>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
>>>> down to specifics. The only place that Dennis can hide his deception
>>>> is in deliberate vagnueness.
>>>>
>>>
>>> So, you don't understand what peeople are saying. For you it is just
>>> that you are right and others are wrong.
>> Ha(Pa,Pa) is fully operational code named H(P,P)
>> Hb(Pa,Pa) is fully operational code named H1(P,P)
>>
>> I can prove that the actual behavior of the correct x86 emulation of
>> actual input to H(P,P) never reaches its "ret" instruction with a full
>> execution trace of P.
>>
>> I can prove that the actual behavior of the correct x86 emulation of
>> actual input to H1(P,P) reaches its "ret" instruction with a full
>> execution trace of P.
>>
>> I can prove that both of these execution traces are correct on the basis
>> of the behavior that is specified by the x86 source-code for P.
>
> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>

On Wednesday, May 25, 2022 at 10:27:14 AM UTC-4, olcott wrote:
> On 5/25/2022 9:15 AM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 10:03:15 AM UTC-4, olcott wrote:
> >> On 5/25/2022 8:14 AM, Ben wrote:
> >>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>
> >>>> There then seems to be confusion between "nested simulation" and
> >>>> "recursion" which isn't confined to PO. It's not clear exactly what is
> >>>> going on because we don't have the source of H and questions about how
> >>>> H distinguishes its own output from the output of the program it is
> >>>> simulating haven't been answered.
> >>>
> >>> What is your take on why PO is hiding H? Even the instructions of H are
> >>> never shown in a trace. I ask because you are invariably generous in
> >>> your replies and I wonder what the generous interpretation of hiding
> >>> the one thing, H itself, that would answer all question immediately is.
> >>>
> >> As I have said many hundreds of times you can verify that I am correct
> >> on the basis of what I provided.
> >>
> >> _P()
> >> [00001352](01) 55 push ebp
> >> [00001353](02) 8bec mov ebp,esp
> >> [00001355](03) 8b4508 mov eax,[ebp+08]
> >> [00001358](01) 50 push eax // push P
> >> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >> [0000135c](01) 51 push ecx // push P
> >> [0000135d](05) e840feffff call 000011a2 // call H
> >> [00001362](03) 83c408 add esp,+08
> >> [00001365](02) 85c0 test eax,eax
> >> [00001367](02) 7402 jz 0000136b
> >> [00001369](02) ebfe jmp 00001369
> >> [0000136b](01) 5d pop ebp
> >> [0000136c](01) c3 ret
> >> Size in bytes:(0027) [0000136c]
> >>
> >> In fact you actually only need much less than I provided to prove that I
> >> am correct. The following can be correctly determined entirely on the
> >> basis of the above x86 source-code for P.
> >> It is an easily verified fact that the correct x86 emulation of the
> >> input to H(P,P) would never reach the "ret" instruction of P in 0 to
> >> infinity steps of the correct x86 emulation of P by H.
> >
> > This is exactly why I use Ha/Hn and Pa/Pn, because you're deceptively using H and P to refer to multiple different computations.
> H(P,P) is a fully operational version of what you refer to as Ha(Pa,Pa)
> H1(P,P) is a fully operational version of what you refer to as Hb(Pa,Pa)
>
> I can prove that H(P,P)==0 and H1(P,P)==1 by providing the full
> execution trace of the correct x86 emulation of their input.
>
> I can prove that this is a correct x86 execution trace of their input on
> the basis of the behavior that the x86 source-code of P specifies.
>
> With your imaginary functions you can continue to deceptively
> incorrectly imagine that they do not do what I claim.
>
> In the bright light of day of the actual execution of H(P,P) and H1(P,P)
> it becomes totally obvious that you are incorrect.

All you'll show is that H1(P,P)==1 proves that H(P,P)==0 is incorrect because H aborts too soon.

And if you provide execution traces of Ha3(N,5) and Ha7(N,5), you'll find that you come to the exact same conclusion: that Ha3(N,5)==0 and Ha7(N,5)==1 are both correct according to your criteria.

On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote:
> On 5/25/2022 9:20 AM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
> >> On 5/25/2022 6:01 AM, Richard Damon wrote:
> >>> On 5/24/22 11:00 PM, olcott wrote:
> >>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
> >>>>> On 5/24/22 10:50 PM, olcott wrote:
> >>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
> >>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
> >>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
> >>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
> >>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
> >>>>>>>>>>>>>>>>>>>>>> disagreement with an
> >>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
> >>>>>>>>>>>>>>>>>>>>>> with a
> >>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
> >>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
> >>>>>>>>>>>>>>>>>>>>>> is correct:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
> >>>>>>>>>>>>>>>>>>>>>> input pair of
> >>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
> >>>>>>>>>>>>>>>>>>>>>> and criterion
> >>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
> >>>>>>>>>>>>>>>>>>>>>> reach its "ret"
> >>>>>>>>>>>>>>>>>>>>>> instruction.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
> >>>>>>>>>>>>>>>>>>>>> instruction is because
> >>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
> >>>>>>>>>>>>>>>>>>>>> not exist in
> >>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
> >>>>>>>>>>>>>>>>>>>>> erroneous.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
> >>>>>>>>>>>>>>>>>>>> function named H
> >>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
> >>>>>>>>>>>>>>>>>>>> of the machine
> >>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
> >>>>>>>>>>>>>>>>>>>> of P in 0 to
> >>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
> >>>>>>>>>>>>>>>>>>> a decider or it
> >>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
> >>>>>>>>>>>>>>>>>>> have introduced
> >>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
> >>>>>>>>>>>>>>>>>>> merely a tool for
> >>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
> >>>>>>>>>>>>>>>>>>> proofs you are
> >>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
> >>>>>>>>>>>>>>>>>> actually said as the
> >>>>>>>>>>>>>>>>>> basis of any rebuttal.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
> >>>>>>>>>>>>>>>>>> emulation of the
> >>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
> >>>>>>>>>>>>>>>>>> of P in 0 to
> >>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
> >>>>>>>>>>>>>>>>> you know this
> >>>>>>>>>>>>>>>>> is a lie.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
> >>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
> >>>>>>>>>>>>>>>> that H
> >>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
> >>>>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
> >>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
> >>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
> >>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
> >>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
> >>>>>>>>>>>>>>>> incorrect is that
> >>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
> >>>>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
> >>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
> >>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
> >>>>>>>>>>>>>>>> as the
> >>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
> >>>>>>>>>>>>>>>> that either one
> >>>>>>>>>>>>>>>> of them is incorrect.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
> >>>>>>>>>>>>>>> not perform a correct simulation of its input.
> >>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
> >>>>>>>>>>>>>> of the
> >>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
> >>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
> >>>>>>>>>>>>> Hb(Pa,Pa)==1
> >>>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
> >>>>>>>>>>>> is not
> >>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
> >>>>>>>>>>>> specifies to
> >>>>>>>>>>>> H(P,P) and H1(P,P)
> >>>>>>>>>>>> that determines whether or not its simulation by H
> >>>>>>>>>>>> and H1 is correct.
> >>>>>>>>>>>
> >>>>>>>>>>> Then by this same logic you agree that
> >>>>>>>>>> You continue to be a liar.
> >>>>>>>>>
> >>>>>>>>> So no rebuttal, which means you're unable to. Which means you
> >>>>>>>>> admit I'm right.
> >>>>>>>>>
> >>>>>>>>> So what are you going to do with yourself now that you're no
> >>>>>>>>> longer working on the halting problem?
> >>>>>>>> Escalate the review to a higher caliber reviewer.
> >>>>>>>>
> >>>>>>>> Now that I have all of the objections boiled down to simply
> >>>>>>>> disagreeing
> >>>>>>>> with two verifiable facts higher caliber reviewers should confirm
> >>>>>>>> that I
> >>>>>>>> am correct.
> >>>>>>>
> >>>>>>> The verifiable fact that everyone (except you) can see is that
> >>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
> >>>>>>
> >>>>>> Shows that they are not basing their decision on the execution trace
> >>>>>> that is actually specified by the x86 source-code of P.
> >>>>>>
> >>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
> >>>>>> and H1(P,P). You can't even manage to tell the truth about the names
> >>>>>> of functions.
> >>>>>>
> >>>>>
> >>>>> The names really make that much difference?
> >>>> H(P,P) and H1(P,P) are fully operational C functions that can be
> >>>> executed showing every detail of their correct simulation of their
> >>>> inputs.
> >>>>
> >>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
> >>>> down to specifics. The only place that Dennis can hide his deception
> >>>> is in deliberate vagnueness.
> >>>>
> >>>
> >>> So, you don't understand what peeople are saying. For you it is just
> >>> that you are right and others are wrong.
> >> Ha(Pa,Pa) is fully operational code named H(P,P)
> >> Hb(Pa,Pa) is fully operational code named H1(P,P)
> >>
> >> I can prove that the actual behavior of the correct x86 emulation of
> >> actual input to H(P,P) never reaches its "ret" instruction with a full
> >> execution trace of P.
> >>
> >> I can prove that the actual behavior of the correct x86 emulation of
> >> actual input to H1(P,P) reaches its "ret" instruction with a full
> >> execution trace of P.
> >>
> >> I can prove that both of these execution traces are correct on the basis
> >> of the behavior that is specified by the x86 source-code for P.
> >
> > Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
> >
> If H(P,P) is proven to be correct then there is no need to look at
> anything else. I am not writing a paper about every program that can
> possibly ever be written. I am wring a paper about H(P,P). Once
> H(P,P)==0 is proven to be correct then all of the HP proof are refuted.

On 5/25/2022 9:33 AM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 10:27:14 AM UTC-4, olcott wrote:
>> On 5/25/2022 9:15 AM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 10:03:15 AM UTC-4, olcott wrote:
>>>> On 5/25/2022 8:14 AM, Ben wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> There then seems to be confusion between "nested simulation" and
>>>>>> "recursion" which isn't confined to PO. It's not clear exactly what is
>>>>>> going on because we don't have the source of H and questions about how
>>>>>> H distinguishes its own output from the output of the program it is
>>>>>> simulating haven't been answered.
>>>>>
>>>>> What is your take on why PO is hiding H? Even the instructions of H are
>>>>> never shown in a trace. I ask because you are invariably generous in
>>>>> your replies and I wonder what the generous interpretation of hiding
>>>>> the one thing, H itself, that would answer all question immediately is.
>>>>>
>>>> As I have said many hundreds of times you can verify that I am correct
>>>> on the basis of what I provided.
>>>>
>>>> _P()
>>>> [00001352](01) 55 push ebp
>>>> [00001353](02) 8bec mov ebp,esp
>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>> [00001358](01) 50 push eax // push P
>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000135c](01) 51 push ecx // push P
>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>> [00001362](03) 83c408 add esp,+08
>>>> [00001365](02) 85c0 test eax,eax
>>>> [00001367](02) 7402 jz 0000136b
>>>> [00001369](02) ebfe jmp 00001369
>>>> [0000136b](01) 5d pop ebp
>>>> [0000136c](01) c3 ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> In fact you actually only need much less than I provided to prove that I
>>>> am correct. The following can be correctly determined entirely on the
>>>> basis of the above x86 source-code for P.
>>>> It is an easily verified fact that the correct x86 emulation of the
>>>> input to H(P,P) would never reach the "ret" instruction of P in 0 to
>>>> infinity steps of the correct x86 emulation of P by H.
>>>
>>> This is exactly why I use Ha/Hn and Pa/Pn, because you're deceptively using H and P to refer to multiple different computations.
>> H(P,P) is a fully operational version of what you refer to as Ha(Pa,Pa)
>> H1(P,P) is a fully operational version of what you refer to as Hb(Pa,Pa)
>>
>> I can prove that H(P,P)==0 and H1(P,P)==1 by providing the full
>> execution trace of the correct x86 emulation of their input.
>>
>> I can prove that this is a correct x86 execution trace of their input on
>> the basis of the behavior that the x86 source-code of P specifies.
>>
>> With your imaginary functions you can continue to deceptively
>> incorrectly imagine that they do not do what I claim.
>>
>> In the bright light of day of the actual execution of H(P,P) and H1(P,P)
>> it becomes totally obvious that you are incorrect.
>
> All you'll show is that H1(P,P)==1 proves that H(P,P)==0 is incorrect because H aborts too soon.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

In other words you are claiming that the outer H can simply wait for an
inner H to abort its simulation knowing that each inner H is doing the
same thing thus no H ever aborts its simulation.

>
> And if you provide execution traces of Ha3(N,5) and Ha7(N,5), you'll find that you come to the exact same conclusion: that Ha3(N,5)==0 and Ha7(N,5)==1 are both correct according to your criteria.

--
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 5/25/2022 9:35 AM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote:
>> On 5/25/2022 9:20 AM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
>>>> On 5/25/2022 6:01 AM, Richard Damon wrote:
>>>>> On 5/24/22 11:00 PM, olcott wrote:
>>>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
>>>>>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
>>>>>>>>>>>>>>>>>>>>> a decider or it
>>>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
>>>>>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
>>>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>>>> specifies to
>>>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>>>> You continue to be a liar.
>>>>>>>>>>>
>>>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>>>> admit I'm right.
>>>>>>>>>>>
>>>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>>>> longer working on the halting problem?
>>>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>>>
>>>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>>>> disagreeing
>>>>>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>>>>>> that I
>>>>>>>>>> am correct.
>>>>>>>>>
>>>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>>>
>>>>>>>> Shows that they are not basing their decision on the execution trace
>>>>>>>> that is actually specified by the x86 source-code of P.
>>>>>>>>
>>>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
>>>>>>>> and H1(P,P). You can't even manage to tell the truth about the names
>>>>>>>> of functions.
>>>>>>>>
>>>>>>>
>>>>>>> The names really make that much difference?
>>>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>>>>> executed showing every detail of their correct simulation of their
>>>>>> inputs.
>>>>>>
>>>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
>>>>>> down to specifics. The only place that Dennis can hide his deception
>>>>>> is in deliberate vagnueness.
>>>>>>
>>>>>
>>>>> So, you don't understand what peeople are saying. For you it is just
>>>>> that you are right and others are wrong.
>>>> Ha(Pa,Pa) is fully operational code named H(P,P)
>>>> Hb(Pa,Pa) is fully operational code named H1(P,P)
>>>>
>>>> I can prove that the actual behavior of the correct x86 emulation of
>>>> actual input to H(P,P) never reaches its "ret" instruction with a full
>>>> execution trace of P.
>>>>
>>>> I can prove that the actual behavior of the correct x86 emulation of
>>>> actual input to H1(P,P) reaches its "ret" instruction with a full
>>>> execution trace of P.
>>>>
>>>> I can prove that both of these execution traces are correct on the basis
>>>> of the behavior that is specified by the x86 source-code for P.
>>>
>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>
>> If H(P,P) is proven to be correct then there is no need to look at
>> anything else. I am not writing a paper about every program that can
>> possibly ever be written. I am wring a paper about H(P,P). Once
>> H(P,P)==0 is proven to be correct then all of the HP proof are refuted.
>
> If your proof of H(P,P)==0 being correct also concludes that Ha3(N,5)==0 is correct, then you have an invalid proof as it creates nonsense results.

On Wednesday, May 25, 2022 at 10:46:14 AM UTC-4, olcott wrote:
> On 5/25/2022 9:33 AM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 10:27:14 AM UTC-4, olcott wrote:
> >> On 5/25/2022 9:15 AM, Dennis Bush wrote:
> >>> On Wednesday, May 25, 2022 at 10:03:15 AM UTC-4, olcott wrote:
> >>>> On 5/25/2022 8:14 AM, Ben wrote:
> >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>
> >>>>>> There then seems to be confusion between "nested simulation" and
> >>>>>> "recursion" which isn't confined to PO. It's not clear exactly what is
> >>>>>> going on because we don't have the source of H and questions about how
> >>>>>> H distinguishes its own output from the output of the program it is
> >>>>>> simulating haven't been answered.
> >>>>>
> >>>>> What is your take on why PO is hiding H? Even the instructions of H are
> >>>>> never shown in a trace. I ask because you are invariably generous in
> >>>>> your replies and I wonder what the generous interpretation of hiding
> >>>>> the one thing, H itself, that would answer all question immediately is.
> >>>>>
> >>>> As I have said many hundreds of times you can verify that I am correct
> >>>> on the basis of what I provided.
> >>>>
> >>>> _P()
> >>>> [00001352](01) 55 push ebp
> >>>> [00001353](02) 8bec mov ebp,esp
> >>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>> [00001358](01) 50 push eax // push P
> >>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [0000135c](01) 51 push ecx // push P
> >>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>> [00001362](03) 83c408 add esp,+08
> >>>> [00001365](02) 85c0 test eax,eax
> >>>> [00001367](02) 7402 jz 0000136b
> >>>> [00001369](02) ebfe jmp 00001369
> >>>> [0000136b](01) 5d pop ebp
> >>>> [0000136c](01) c3 ret
> >>>> Size in bytes:(0027) [0000136c]
> >>>>
> >>>> In fact you actually only need much less than I provided to prove that I
> >>>> am correct. The following can be correctly determined entirely on the
> >>>> basis of the above x86 source-code for P.
> >>>> It is an easily verified fact that the correct x86 emulation of the
> >>>> input to H(P,P) would never reach the "ret" instruction of P in 0 to
> >>>> infinity steps of the correct x86 emulation of P by H.
> >>>
> >>> This is exactly why I use Ha/Hn and Pa/Pn, because you're deceptively using H and P to refer to multiple different computations.
> >> H(P,P) is a fully operational version of what you refer to as Ha(Pa,Pa)
> >> H1(P,P) is a fully operational version of what you refer to as Hb(Pa,Pa)
> >>
> >> I can prove that H(P,P)==0 and H1(P,P)==1 by providing the full
> >> execution trace of the correct x86 emulation of their input.
> >>
> >> I can prove that this is a correct x86 execution trace of their input on
> >> the basis of the behavior that the x86 source-code of P specifies.
> >>
> >> With your imaginary functions you can continue to deceptively
> >> incorrectly imagine that they do not do what I claim.
> >>
> >> In the bright light of day of the actual execution of H(P,P) and H1(P,P)
> >> it becomes totally obvious that you are incorrect.
> >
> > All you'll show is that H1(P,P)==1 proves that H(P,P)==0 is incorrect because H aborts too soon.
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
> In other words you are claiming that the outer H can simply wait for an
> inner H to abort its simulation knowing that each inner H is doing the
> same thing thus no H ever aborts its simulation.

See, now you're talking about Hn and Pn. Pn(Pn) does not halt, but neither does Hn(Pn,Pn) so it's can't give an answer.

If H does abort, i.e. Ha, then H1(Pa,Pa) waits for the Ha embedded in Pa to abort and returns 1.

> >
> > And if you provide execution traces of Ha3(N,5) and Ha7(N,5), you'll find that you come to the exact same conclusion: that Ha3(N,5)==0 and Ha7(N,5)==1 are both correct according to your criteria.
> --

On Wednesday, May 25, 2022 at 10:55:11 AM UTC-4, olcott wrote:
> On 5/25/2022 9:35 AM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote:
> >> On 5/25/2022 9:20 AM, Dennis Bush wrote:
> >>> On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
> >>>> On 5/25/2022 6:01 AM, Richard Damon wrote:
> >>>>> On 5/24/22 11:00 PM, olcott wrote:
> >>>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
> >>>>>>> On 5/24/22 10:50 PM, olcott wrote:
> >>>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
> >>>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
> >>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
> >>>>>>>>>>>>>>>>>>>>>>>> disagreement with an
> >>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
> >>>>>>>>>>>>>>>>>>>>>>>> with a
> >>>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
> >>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
> >>>>>>>>>>>>>>>>>>>>>>>> is correct:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
> >>>>>>>>>>>>>>>>>>>>>>>> input pair of
> >>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
> >>>>>>>>>>>>>>>>>>>>>>>> and criterion
> >>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
> >>>>>>>>>>>>>>>>>>>>>>>> reach its "ret"
> >>>>>>>>>>>>>>>>>>>>>>>> instruction.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
> >>>>>>>>>>>>>>>>>>>>>>> instruction is because
> >>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
> >>>>>>>>>>>>>>>>>>>>>>> not exist in
> >>>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
> >>>>>>>>>>>>>>>>>>>>>>> erroneous.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
> >>>>>>>>>>>>>>>>>>>>>> function named H
> >>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
> >>>>>>>>>>>>>>>>>>>>>> of the machine
> >>>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
> >>>>>>>>>>>>>>>>>>>>>> of P in 0 to
> >>>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
> >>>>>>>>>>>>>>>>>>>>> a decider or it
> >>>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
> >>>>>>>>>>>>>>>>>>>>> have introduced
> >>>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
> >>>>>>>>>>>>>>>>>>>>> merely a tool for
> >>>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
> >>>>>>>>>>>>>>>>>>>>> proofs you are
> >>>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
> >>>>>>>>>>>>>>>>>>>> actually said as the
> >>>>>>>>>>>>>>>>>>>> basis of any rebuttal.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
> >>>>>>>>>>>>>>>>>>>> emulation of the
> >>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
> >>>>>>>>>>>>>>>>>>>> of P in 0 to
> >>>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
> >>>>>>>>>>>>>>>>>>> you know this
> >>>>>>>>>>>>>>>>>>> is a lie.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
> >>>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
> >>>>>>>>>>>>>>>>>> that H
> >>>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
> >>>>>>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
> >>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
> >>>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
> >>>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
> >>>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
> >>>>>>>>>>>>>>>>>> incorrect is that
> >>>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
> >>>>>>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
> >>>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
> >>>>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
> >>>>>>>>>>>>>>>>>> as the
> >>>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
> >>>>>>>>>>>>>>>>>> that either one
> >>>>>>>>>>>>>>>>>> of them is incorrect.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
> >>>>>>>>>>>>>>>>> not perform a correct simulation of its input.
> >>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
> >>>>>>>>>>>>>>>> of the
> >>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
> >>>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
> >>>>>>>>>>>>>>> Hb(Pa,Pa)==1
> >>>>>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
> >>>>>>>>>>>>>> is not
> >>>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
> >>>>>>>>>>>>>> specifies to
> >>>>>>>>>>>>>> H(P,P) and H1(P,P)
> >>>>>>>>>>>>>> that determines whether or not its simulation by H
> >>>>>>>>>>>>>> and H1 is correct.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Then by this same logic you agree that
> >>>>>>>>>>>> You continue to be a liar.
> >>>>>>>>>>>
> >>>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
> >>>>>>>>>>> admit I'm right.
> >>>>>>>>>>>
> >>>>>>>>>>> So what are you going to do with yourself now that you're no
> >>>>>>>>>>> longer working on the halting problem?
> >>>>>>>>>> Escalate the review to a higher caliber reviewer.
> >>>>>>>>>>
> >>>>>>>>>> Now that I have all of the objections boiled down to simply
> >>>>>>>>>> disagreeing
> >>>>>>>>>> with two verifiable facts higher caliber reviewers should confirm
> >>>>>>>>>> that I
> >>>>>>>>>> am correct.
> >>>>>>>>>
> >>>>>>>>> The verifiable fact that everyone (except you) can see is that
> >>>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
> >>>>>>>>
> >>>>>>>> Shows that they are not basing their decision on the execution trace
> >>>>>>>> that is actually specified by the x86 source-code of P.
> >>>>>>>>
> >>>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
> >>>>>>>> and H1(P,P). You can't even manage to tell the truth about the names
> >>>>>>>> of functions.
> >>>>>>>>
> >>>>>>>
> >>>>>>> The names really make that much difference?
> >>>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
> >>>>>> executed showing every detail of their correct simulation of their
> >>>>>> inputs.
> >>>>>>
> >>>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
> >>>>>> down to specifics. The only place that Dennis can hide his deception
> >>>>>> is in deliberate vagnueness.
> >>>>>>
> >>>>>
> >>>>> So, you don't understand what peeople are saying. For you it is just
> >>>>> that you are right and others are wrong.
> >>>> Ha(Pa,Pa) is fully operational code named H(P,P)
> >>>> Hb(Pa,Pa) is fully operational code named H1(P,P)
> >>>>
> >>>> I can prove that the actual behavior of the correct x86 emulation of
> >>>> actual input to H(P,P) never reaches its "ret" instruction with a full
> >>>> execution trace of P.
> >>>>
> >>>> I can prove that the actual behavior of the correct x86 emulation of
> >>>> actual input to H1(P,P) reaches its "ret" instruction with a full
> >>>> execution trace of P.
> >>>>
> >>>> I can prove that both of these execution traces are correct on the basis
> >>>> of the behavior that is specified by the x86 source-code for P.
> >>>
> >>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
> >>>
> >> If H(P,P) is proven to be correct then there is no need to look at
> >> anything else. I am not writing a paper about every program that can
> >> possibly ever be written. I am wring a paper about H(P,P). Once
> >> H(P,P)==0 is proven to be correct then all of the HP proof are refuted.
> >
> > If your proof of H(P,P)==0 being correct also concludes that Ha3(N,5)==0 is correct, then you have an invalid proof as it creates nonsense results.
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
> It is an easily verified fact that the correct x86 emulation of the
> input to H(P,P) would never reach the "ret" instruction of P in 0 to
> infinity steps of the correct x86 emulation of P by H.

On 25/05/2022 08:16, Malcolm McLean wrote:
<..snip..>
> H shows the [correct] execution trace of P, until P calls H, at which point the trace ceases.
> H is now simulating H, and the simulated H outputs the next nine instructions of P.
>
> It isn't made clear from the trace that this is not the output of the simulator, but
> output of the simulated program.

A couple of years ago I told PO he needed to include some kind of "emulation id/level" column in his
trace. He actually took up this suggestion for about a week, and then removed it, saying it was
confusing people! (So it's not like PO /can't/ implement this clarification, more that he
deliberately wants to avoid it...)

>
> There then seems to be confusion between "nested simulation" and "recursion" which
> isn't confined to PO.

Yes I think PO doesn't properly understand the implications of using simulation versus direct call.
In his mind he has some idea of a processor confined to a loop, i.e. the processor is executing the
same instructions over and over, with essentially the same data so it can never break out. He
invents some rule which characterises when such a loop is occuring (nested calls to the same routine
with the same parameters, or whatever - the details change over time and don't really matter).

To be clear, such a rule (patched up/enhanced) might eventually be a valid rule IN A SINGLE
PROCESSOR TRACE environment, but is OBVIOUSLY (to all but PO) not valid when applied to a
MERGED-SIMULATION-TRACE. If not clear, that's because there is no "processor" which generates the
trace, and "branches to the same address blah blah.." are not made by the same logical processor.
So it is not really a "loop" in the (single processor) sense where the rule might be made to work.
The outer procesor is still running but hidden from the trace, and can obviously break the recursion
/from the outside/ when it detects some condition in the emulated trace.

I can't say I've noticed anyone other than PO who has not understood this distinction, but who
knows... Hmm, there was the case when PO "took his case" to some x86 based newsgroup - he presented
his trace [without the emulation level column] to the group, and asked what they thought was going
on with his program - he thought it was looping... There was not any mention of simulation, or that
the trace was anything other than a [single] processor trace. Unsurprisingly someone there said his
code was looping! But it would be unfair to say that person wasn't unaware of the distinction
between direct call recursion and recursive simulation - he was just tricked.

> It's not clear exactly what is going on because we don't have the
> source of H and questions about how H distinguishes its own output from the output
> of the program it is simulating haven't been answered.

It's true we don't know the details of how PO is doing this, but we can see what's effectively going
on, I'd say. It is /as though/ there is one "master trace" of all the nested simulations maintained
by the x86utm somewhere in the address space of its virtual x86 processor. There is just one such
address space used by all PO's H,H^ simulations that are going on, i.e. they all share global memory
and access to what is effectively a global trace table that they can inspect.

Whether a deeply simulated H can see the trace entries for its outer emulator I'm not sure - it
shouldn't be able to do that of course, but in any case I see no sign that PO is using such a flaw
to cheat: I think everything he says has plausible interpretations that do not need him to cheat in
that particular way.

So you could imagine that the H simulations see what is effectively a version of the
"merged-simulation-trace" that PO posts here all the time, but probably including all its own
execution trace records. I'd guess within H, PO has logic to exclude trace records matching H's own
address range, because he doesn't want e.g. conditional branches within H to spoil a "..and no
conditional branches.." clause in his matching rule (or whatever, doesn't really matter).

Anyway, I lost any enthusiasm I might have had for knowing "exactly" what PO is doing long ago
[probably on the day he went back on his original statement that he was going to publish everything
he produced here on Usenet - all code for H, H^ and for his x86utm.exe].

We know more than enough of that to see the major mistakes he makes. And e.g. knowing exactly how
he feeds (deeply) nested simulation trace entries to an outer H doesn't in any way affect the nature
of those mistakes!!!!! IF PO claimed that his H was some kind of /universal/ halt decider, these
details would become important, because for example TMs can't use "their own machine addresses" to
affect their own behaviour, or access a global x86utm-maintained nested simulation trace. But PO
does not need to make such a claim (although he occasionally suggests as much!) since he only has to
deal with ONE USE CASE: his H and H^. Even if his code is a total failure as an approach for a
universal decider, he can and does just fall back on the fact that it only has to "work correctly"
for this one scenario.

[So, if code doesn't have to work universally, but just on one scenario, what does it even mean to
say the code is "correct" - why not just code the right answer for that one scenario and forget all
the complicated tracing logic? I remember you correctly pointed this out to PO right at the start
(years ago now)! The problem for PO would be that then (as now) his H,H^ counterexample would
obviously fail, AND HE WOULD HAVE NOTHING HE COULD INVENT TO EXPLAIN WHY IT WAS REALLY WORKING, EVEN
THOUGH IT WAS OBVIOUSLY FAILING. So the purpose of all the complicated and semi-secret H code is
ultimately just to give PO some excuse to confuse himself! It enables him to think "I'm using a
correct test, so the answer it gives is correct by definition, even though the answer it gives is
demonstrably wrong. In the end PO just really really really really believes his test is sound! :) ]

> But from what PO is saying,
> it seems that "nested simulation" is being treated as "recursion" for the infinite loop
> detection step.

Yes, PO does not properly account for the qualitative differences between recursive call/recursive
simulation. He has stated his "rule" works equally for both, although he couldn't begin to prove it
works even for the relatively simple direct call environment. (Well, maybe not so simple on an
actual x86 processor! - but remember the fall-back: it only has to work "correctly" for his one use
case...)

Mike.

On Wed, 25 May 2022 08:46:56 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/25/2022 2:16 AM, Malcolm McLean wrote:
> > On Wednesday, 25 May 2022 at 04:05:50 UTC+1, Dennis Bush wrote:
> >> On Tuesday, May 24, 2022 at 11:00:22 PM UTC-4, olcott wrote:
> >>> On 5/24/2022 9:54 PM, Richard Damon wrote:
> >>>> On 5/24/22 10:50 PM, olcott wrote:
> >>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
> >>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
> >>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
> >>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
> >>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
> >>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott
> >>>>>>>>>> wrote:
> >>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
> >>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
> >>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
> >>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
> >>>>>>>>>>>>>>>>>>>>> disagreement with an
> >>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software
> >>>>>>>>>>>>>>>>>>>>> engineer with a
> >>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily
> >>>>>>>>>>>>>>>>>>>>> confirm that H(P,P)==0
> >>>>>>>>>>>>>>>>>>>>> is correct:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates
> >>>>>>>>>>>>>>>>>>>>> its input pair of
> >>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of
> >>>>>>>>>>>>>>>>>>>>> function P and criterion
> >>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would
> >>>>>>>>>>>>>>>>>>>>> never reach its "ret"
> >>>>>>>>>>>>>>>>>>>>> instruction.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
> >>>>>>>>>>>>>>>>>>>> instruction is because
> >>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that
> >>>>>>>>>>>>>>>>>>>> does not exist in
> >>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H
> >>>>>>>>>>>>>>>>>>>> is erroneous.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> For the time being I am only referring to when
> >>>>>>>>>>>>>>>>>>> the C function named H
> >>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86
> >>>>>>>>>>>>>>>>>>> emulation of the machine
> >>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret"
> >>>>>>>>>>>>>>>>>>> instruction of P in 0 to
> >>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed
> >>>>>>>>>>>>>>>>>> to be a decider or it
> >>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as
> >>>>>>>>>>>>>>>>>> you have introduced
> >>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
> >>>>>>>>>>>>>>>>>> merely a tool for
> >>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as
> >>>>>>>>>>>>>>>>>> the proofs you are
> >>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite
> >>>>>>>>>>>>>>>>>> recursion.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> You have to actually stick with the words that I
> >>>>>>>>>>>>>>>>> actually said as the
> >>>>>>>>>>>>>>>>> basis of any rebuttal.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
> >>>>>>>>>>>>>>>>> emulation of the
> >>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
> >>>>>>>>>>>>>>>>> instruction of P in 0 to
> >>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by
> >>>>>>>>>>>>>>>>> H.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Since you have posted a trace which shows this
> >>>>>>>>>>>>>>>> happening, you know this
> >>>>>>>>>>>>>>>> is a lie.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT
> >>>>>>>>>>>>>>>> simulator can.
> >>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every
> >>>>>>>>>>>>>>> instruction that H simulates is exactly what the x86
> >>>>>>>>>>>>>>> source-code for P specifies.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
> >>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
> >>>>>>>>>>>>>> source code for N specifies. Therefore, according to
> >>>>>>>>>>>>>> you, Ha3(N,5)==0 is correct.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no
> >>>>>>>>>>>>>> mistakes in its simulation doesn't mean that it's
> >>>>>>>>>>>>>> correct.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The only possible way for a simulator to actually be
> >>>>>>>>>>>>>>> incorrect is that
> >>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code
> >>>>>>>>>>>>>>> of P specifies.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly
> >>>>>>>>>>>>>> thinking that it is a non-halting computation. Which
> >>>>>>>>>>>>>> is exactly what happens with Ha(Pa,Pa).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting
> >>>>>>>>>>>>>>> behavior as the
> >>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not
> >>>>>>>>>>>>>>> mean that either one
> >>>>>>>>>>>>>>> of them is incorrect.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem,
> >>>>>>>>>>>>>> does not perform a correct simulation of its input.
> >>>>>>>>>>>>> It is an easily verified fact that the correct x86
> >>>>>>>>>>>>> emulation of the
> >>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
> >>>>>>>>>>>>> of P
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
> >>>>>>>>>>>> correct because it aborts too soon as demonstrated by
> >>>>>>>>>>>> Hb(Pa,Pa)==1
> >>>>>>>>>>> By this same despicable liar reasoning we can know that
> >>>>>>>>>>> Fluffy is not
> >>>>>>>>>>> a white cat entirely on the basis that Rover is a black
> >>>>>>>>>>> dog.
> >>>>>>>>>>>
> >>>>>>>>>>> It is the actual behavior that the x86 source-code of P
> >>>>>>>>>>> specifies to
> >>>>>>>>>>> H(P,P) and H1(P,P)
> >>>>>>>>>>> that determines whether or not its simulation by H
> >>>>>>>>>>> and H1 is correct.
> >>>>>>>>>>
> >>>>>>>>>> Then by this same logic you agree that
> >>>>>>>>> You continue to be a liar.
> >>>>>>>>
> >>>>>>>> So no rebuttal, which means you're unable to. Which means
> >>>>>>>> you admit I'm right.
> >>>>>>>>
> >>>>>>>> So what are you going to do with yourself now that you're no
> >>>>>>>> longer working on the halting problem?
> >>>>>>> Escalate the review to a higher caliber reviewer.
> >>>>>>>
> >>>>>>> Now that I have all of the objections boiled down to simply
> >>>>>>> disagreeing with two verifiable facts higher caliber
> >>>>>>> reviewers should confirm that I
> >>>>>>> am correct.
> >>>>>>
> >>>>>> The verifiable fact that everyone (except you) can see is that
> >>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
> >>>>>
> >>>>> Shows that they are not basing their decision on the execution
> >>>>> trace that is actually specified by the x86 source-code of P.
> >>>>>
> >>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named
> >>>>> H(P,P) and H1(P,P). You can't even manage to tell the truth
> >>>>> about the names of functions.
> >>>>>
> >>>>
> >>>> The names really make that much difference?
> >>> H(P,P) and H1(P,P) are fully operational C functions that can be
> >>> executed showing every detail of their correct simulation of
> >>> their inputs.
> >>>
> >>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be
> >>> pinned down to specifics.
> >> No, Ha is a *specific* decider with a fixed algorithm (the one you
> >> claim can detect infinite simulation in Pn(Pn)), as is Hb also a
> >> *specific* decider which is related to Ha.
> >>> The only place that Dennis can hide his deception is
> >>> in deliberate vagnueness.
> >> You're projecting once again. You sometimes say "H" and "P" when
> >> you mean Ha and Pa, and sometimes say "H" and "P" when you mean Hn
> >> and Pn. The one hiding behind vagueness is you.
> >
> > H shows the [correct] execution trace of P, until P calls H, at
> > which point the trace ceases. H is now simulating H, and the
> > simulated H outputs the next nine instructions of P.
> >
> > It isn't made clear from the trace that this is not the output of
> > the simulator, but output of the simulated program.
> >
> > There then seems to be confusion between "nested simulation" and
> > "recursion" which
> Nested simulation derives the same behavior pattern as recursion.
>
> > isn't confined to PO. It's not clear exactly what is going on
> > because we don't have the source of H and questions about how H
> > distinguishes its own output from the output of the program it is
> > simulating haven't been answered.
>
> The operating system screens out displaying the any operating system
> code.
>
> > But from what PO is saying,
> > it seems that "nested simulation" is being treated as "recursion"
> > for the infinite loop detection step.
>
> Nested simulation derives the same behavior pattern as recursion.
>
> H simulates P
> ...[00001352][0021233e][00212342] 55 push ebp // enter P
> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50 push eax // push P
> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51 push ecx // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> The simulated P calls H
> H is simulated simulating P yet the simulation of H is not shown
> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50 push eax // push P
> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Click here to read the complete article

On 5/25/2022 11:34 AM, Mr Flibble wrote:
> On Wed, 25 May 2022 08:46:56 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/25/2022 2:16 AM, Malcolm McLean wrote:
>>> On Wednesday, 25 May 2022 at 04:05:50 UTC+1, Dennis Bush wrote:
>>>> On Tuesday, May 24, 2022 at 11:00:22 PM UTC-4, olcott wrote:
>>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software
>>>>>>>>>>>>>>>>>>>>>>> engineer with a
>>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily
>>>>>>>>>>>>>>>>>>>>>>> confirm that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates
>>>>>>>>>>>>>>>>>>>>>>> its input pair of
>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of
>>>>>>>>>>>>>>>>>>>>>>> function P and criterion
>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would
>>>>>>>>>>>>>>>>>>>>>>> never reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that
>>>>>>>>>>>>>>>>>>>>>> does not exist in
>>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H
>>>>>>>>>>>>>>>>>>>>>> is erroneous.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when
>>>>>>>>>>>>>>>>>>>>> the C function named H
>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86
>>>>>>>>>>>>>>>>>>>>> emulation of the machine
>>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret"
>>>>>>>>>>>>>>>>>>>>> instruction of P in 0 to
>>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed
>>>>>>>>>>>>>>>>>>>> to be a decider or it
>>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as
>>>>>>>>>>>>>>>>>>>> you have introduced
>>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as
>>>>>>>>>>>>>>>>>>>> the proofs you are
>>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite
>>>>>>>>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
>>>>>>>>>>>>>>>>>>> instruction of P in 0 to
>>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by
>>>>>>>>>>>>>>>>>>> H.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this
>>>>>>>>>>>>>>>>>> happening, you know this
>>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT
>>>>>>>>>>>>>>>>>> simulator can.
>>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>>> instruction that H simulates is exactly what the x86
>>>>>>>>>>>>>>>>> source-code for P specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to
>>>>>>>>>>>>>>>> you, Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no
>>>>>>>>>>>>>>>> mistakes in its simulation doesn't mean that it's
>>>>>>>>>>>>>>>> correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code
>>>>>>>>>>>>>>>>> of P specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly
>>>>>>>>>>>>>>>> thinking that it is a non-halting computation. Which
>>>>>>>>>>>>>>>> is exactly what happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting
>>>>>>>>>>>>>>>>> behavior as the
>>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not
>>>>>>>>>>>>>>>>> mean that either one
>>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem,
>>>>>>>>>>>>>>>> does not perform a correct simulation of its input.
>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>> of P
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>>> By this same despicable liar reasoning we can know that
>>>>>>>>>>>>> Fluffy is not
>>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black
>>>>>>>>>>>>> dog.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>>> specifies to
>>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>>> You continue to be a liar.
>>>>>>>>>>
>>>>>>>>>> So no rebuttal, which means you're unable to. Which means
>>>>>>>>>> you admit I'm right.
>>>>>>>>>>
>>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>>> longer working on the halting problem?
>>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>>
>>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>>> disagreeing with two verifiable facts higher caliber
>>>>>>>>> reviewers should confirm that I
>>>>>>>>> am correct.
>>>>>>>>
>>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>>
>>>>>>> Shows that they are not basing their decision on the execution
>>>>>>> trace that is actually specified by the x86 source-code of P.
>>>>>>>
>>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named
>>>>>>> H(P,P) and H1(P,P). You can't even manage to tell the truth
>>>>>>> about the names of functions.
>>>>>>>
>>>>>>
>>>>>> The names really make that much difference?
>>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>>>> executed showing every detail of their correct simulation of
>>>>> their inputs.
>>>>>
>>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be
>>>>> pinned down to specifics.
>>>> No, Ha is a *specific* decider with a fixed algorithm (the one you
>>>> claim can detect infinite simulation in Pn(Pn)), as is Hb also a
>>>> *specific* decider which is related to Ha.
>>>>> The only place that Dennis can hide his deception is
>>>>> in deliberate vagnueness.
>>>> You're projecting once again. You sometimes say "H" and "P" when
>>>> you mean Ha and Pa, and sometimes say "H" and "P" when you mean Hn
>>>> and Pn. The one hiding behind vagueness is you.
>>>
>>> H shows the [correct] execution trace of P, until P calls H, at
>>> which point the trace ceases. H is now simulating H, and the
>>> simulated H outputs the next nine instructions of P.
>>>
>>> It isn't made clear from the trace that this is not the output of
>>> the simulator, but output of the simulated program.
>>>
>>> There then seems to be confusion between "nested simulation" and
>>> "recursion" which
>> Nested simulation derives the same behavior pattern as recursion.
>>
>>> isn't confined to PO. It's not clear exactly what is going on
>>> because we don't have the source of H and questions about how H
>>> distinguishes its own output from the output of the program it is
>>> simulating haven't been answered.
>>
>> The operating system screens out displaying the any operating system
>> code.
>>
>>> But from what PO is saying,
>>> it seems that "nested simulation" is being treated as "recursion"
>>> for the infinite loop detection step.
>>
>> Nested simulation derives the same behavior pattern as recursion.
>>
>> H simulates P
>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>> ...[00001358][0021233a][00001352] 50 push eax // push P
>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>
>> The simulated P calls H
>> H is simulated simulating P yet the simulation of H is not shown
>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>> ...[00001358][0025cd62][00001352] 50 push eax // push P
>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> This infinite recursion is (a) not present in the proofs you are
> attempting to refute and (b) specious.
>
> /Flibble
>

On Wed, 25 May 2022 12:43:42 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/25/2022 11:34 AM, Mr Flibble wrote:
> > On Wed, 25 May 2022 08:46:56 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/25/2022 2:16 AM, Malcolm McLean wrote:
> >>> On Wednesday, 25 May 2022 at 04:05:50 UTC+1, Dennis Bush wrote:
> >>>> On Tuesday, May 24, 2022 at 11:00:22 PM UTC-4, olcott wrote:
> >>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
> >>>>>> On 5/24/22 10:50 PM, olcott wrote:
> >>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
> >>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
> >>>>>>>>
> >>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
> >>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott
> >>>>>>>>>> wrote:
> >>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
> >>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
> >>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
> >>>>>>>>>>>>>>>>>>>>>>> disagreement with an
> >>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software
> >>>>>>>>>>>>>>>>>>>>>>> engineer with a
> >>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily
> >>>>>>>>>>>>>>>>>>>>>>> confirm that H(P,P)==0
> >>>>>>>>>>>>>>>>>>>>>>> is correct:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly
> >>>>>>>>>>>>>>>>>>>>>>> emulates its input pair of
> >>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of
> >>>>>>>>>>>>>>>>>>>>>>> function P and criterion
> >>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would
> >>>>>>>>>>>>>>>>>>>>>>> never reach its "ret"
> >>>>>>>>>>>>>>>>>>>>>>> instruction.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
> >>>>>>>>>>>>>>>>>>>>>> instruction is because
> >>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that
> >>>>>>>>>>>>>>>>>>>>>> does not exist in
> >>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your
> >>>>>>>>>>>>>>>>>>>>>> H is erroneous.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when
> >>>>>>>>>>>>>>>>>>>>> the C function named H
> >>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86
> >>>>>>>>>>>>>>>>>>>>> emulation of the machine
> >>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret"
> >>>>>>>>>>>>>>>>>>>>> instruction of P in 0 to
> >>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86
> >>>>>>>>>>>>>>>>>>>>> emulation.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed
> >>>>>>>>>>>>>>>>>>>> to be a decider or it
> >>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that
> >>>>>>>>>>>>>>>>>>>> as you have introduced
> >>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and
> >>>>>>>>>>>>>>>>>>>> is merely a tool for
> >>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as
> >>>>>>>>>>>>>>>>>>>> the proofs you are
> >>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite
> >>>>>>>>>>>>>>>>>>>> recursion.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
> >>>>>>>>>>>>>>>>>>> actually said as the
> >>>>>>>>>>>>>>>>>>> basis of any rebuttal.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
> >>>>>>>>>>>>>>>>>>> emulation of the
> >>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
> >>>>>>>>>>>>>>>>>>> instruction of P in 0 to
> >>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P
> >>>>>>>>>>>>>>>>>>> by H.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this
> >>>>>>>>>>>>>>>>>> happening, you know this
> >>>>>>>>>>>>>>>>>> is a lie.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT
> >>>>>>>>>>>>>>>>>> simulator can.
> >>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every
> >>>>>>>>>>>>>>>>> instruction that H simulates is exactly what the x86
> >>>>>>>>>>>>>>>>> source-code for P specifies.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
> >>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the
> >>>>>>>>>>>>>>>> x86 source code for N specifies. Therefore,
> >>>>>>>>>>>>>>>> according to you, Ha3(N,5)==0 is correct.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no
> >>>>>>>>>>>>>>>> mistakes in its simulation doesn't mean that it's
> >>>>>>>>>>>>>>>> correct.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
> >>>>>>>>>>>>>>>>> incorrect is that
> >>>>>>>>>>>>>>>>> its simulation diverges from what the x86
> >>>>>>>>>>>>>>>>> source-code of P specifies.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly
> >>>>>>>>>>>>>>>> thinking that it is a non-halting computation. Which
> >>>>>>>>>>>>>>>> is exactly what happens with Ha(Pa,Pa).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting
> >>>>>>>>>>>>>>>>> behavior as the
> >>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not
> >>>>>>>>>>>>>>>>> mean that either one
> >>>>>>>>>>>>>>>>> of them is incorrect.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem,
> >>>>>>>>>>>>>>>> does not perform a correct simulation of its input.
> >>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
> >>>>>>>>>>>>>>> emulation of the
> >>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
> >>>>>>>>>>>>>>> instruction of P
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
> >>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
> >>>>>>>>>>>>>> Hb(Pa,Pa)==1
> >>>>>>>>>>>>> By this same despicable liar reasoning we can know that
> >>>>>>>>>>>>> Fluffy is not
> >>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black
> >>>>>>>>>>>>> dog.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
> >>>>>>>>>>>>> specifies to
> >>>>>>>>>>>>> H(P,P) and H1(P,P)
> >>>>>>>>>>>>> that determines whether or not its simulation by H
> >>>>>>>>>>>>> and H1 is correct.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Then by this same logic you agree that
> >>>>>>>>>>> You continue to be a liar.
> >>>>>>>>>>
> >>>>>>>>>> So no rebuttal, which means you're unable to. Which means
> >>>>>>>>>> you admit I'm right.
> >>>>>>>>>>
> >>>>>>>>>> So what are you going to do with yourself now that you're
> >>>>>>>>>> no longer working on the halting problem?
> >>>>>>>>> Escalate the review to a higher caliber reviewer.
> >>>>>>>>>
> >>>>>>>>> Now that I have all of the objections boiled down to simply
> >>>>>>>>> disagreeing with two verifiable facts higher caliber
> >>>>>>>>> reviewers should confirm that I
> >>>>>>>>> am correct.
> >>>>>>>>
> >>>>>>>> The verifiable fact that everyone (except you) can see is
> >>>>>>>> that Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
> >>>>>>>
> >>>>>>> Shows that they are not basing their decision on the execution
> >>>>>>> trace that is actually specified by the x86 source-code of P.
> >>>>>>>
> >>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named
> >>>>>>> H(P,P) and H1(P,P). You can't even manage to tell the truth
> >>>>>>> about the names of functions.
> >>>>>>>
> >>>>>>
> >>>>>> The names really make that much difference?
> >>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
> >>>>> executed showing every detail of their correct simulation of
> >>>>> their inputs.
> >>>>>
> >>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be
> >>>>> pinned down to specifics.
> >>>> No, Ha is a *specific* decider with a fixed algorithm (the one
> >>>> you claim can detect infinite simulation in Pn(Pn)), as is Hb
> >>>> also a *specific* decider which is related to Ha.
> >>>>> The only place that Dennis can hide his deception is
> >>>>> in deliberate vagnueness.
> >>>> You're projecting once again. You sometimes say "H" and "P" when
> >>>> you mean Ha and Pa, and sometimes say "H" and "P" when you mean
> >>>> Hn and Pn. The one hiding behind vagueness is you.
> >>>
> >>> H shows the [correct] execution trace of P, until P calls H, at
> >>> which point the trace ceases. H is now simulating H, and the
> >>> simulated H outputs the next nine instructions of P.
> >>>
> >>> It isn't made clear from the trace that this is not the output of
> >>> the simulator, but output of the simulated program.
> >>>
> >>> There then seems to be confusion between "nested simulation" and
> >>> "recursion" which
> >> Nested simulation derives the same behavior pattern as recursion.
> >>
> >>> isn't confined to PO. It's not clear exactly what is going on
> >>> because we don't have the source of H and questions about how H
> >>> distinguishes its own output from the output of the program it is
> >>> simulating haven't been answered.
> >>
> >> The operating system screens out displaying the any operating
> >> system code.
> >>
> >>> But from what PO is saying,
> >>> it seems that "nested simulation" is being treated as "recursion"
> >>> for the infinite loop detection step.
> >>
> >> Nested simulation derives the same behavior pattern as recursion.
> >>
> >> H simulates P
> >> ...[00001352][0021233e][00212342] 55 push ebp //
> >> enter P ...[00001353][0021233e][00212342] 8bec mov ebp,esp
> >> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
> >> ...[00001358][0021233a][00001352] 50 push eax // push
> >> P ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
> >> ...[0000135c][00212336][00001352] 51 push ecx // push
> >> P ...[0000135d][00212332][00001362] e840feffff call 000011a2 //
> >> call H
> >>
> >> The simulated P calls H
> >> H is simulated simulating P yet the simulation of H is not shown
> >> ...[00001352][0025cd66][0025cd6a] 55 push ebp //
> >> enter P ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> >> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> >> ...[00001358][0025cd62][00001352] 50 push eax // push
> >> P ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> >> ...[0000135c][0025cd5e][00001352] 51 push ecx // push
> >> P ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 //
> >> call H Local Halt Decider: Infinite Recursion Detected Simulation
> >> Stopped
> >
> > This infinite recursion is (a) not present in the proofs you are
> > attempting to refute and (b) specious.
> >
> > /Flibble
> >
>
> When we assume that the halt decider bases its halt status decision
> on the behavior of its correctly simulated input then the infinitely
> nested simulation <is> in all of the conventional proofs.