On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
> On 7/29/2022 10:18 PM, Dennis Bush wrote:
> > On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
> >> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >>>
> >>> On 7/29/22 10:47 PM, olcott wrote:
> >>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>>>> On 7/29/22 10:11 PM, olcott wrote:
> >>>>> IT is absolutely true that any function call that creates infinite
> >>>>> recursion will never return to its caller.
> >>>> That is great that you said this, I may stop totally ignoring every
> >>>> one of your posts without even glancing at them for half a second.
> >>>>
> >>>> It is also true that the correctly simulated input to H(P,P) by H
> >>>> would never reach its "ret" instruction(final state), thus never halt
> >>>> according to:
> >>>>
> >>>> *computation that halts* … the Turing machine will halt whenever it
> >>>> enters a final state. (Linz:1990:234)
> >>>>
> >>>> whether or not H(P,P) ever aborts the simulation of its input.
> >>>
> >>> Nope. You have that WRONG.
> >>>
> >>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
> >>> never returns the answer, so that H isn't a correct halt decider.
> >>>
> >> As usual you resort to the strawman deception:
> >>
> >> *straw man*
> >> An intentionally misrepresented proposition that is set up because it is
> >> easier to defeat than an opponent's real argument.
> >> https://www.lexico.com/en/definition/straw_man
> >>
> >> *The question is*
> >> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
> >> instruction of P whether or not H ever aborts its simulation of P?
> >
> > Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
> >
> > Therefore H is not a halt decider because it is answering the wrong question.
> >
> >>
> >> The lack of an honest answer to this question gets you totally ignored
> >> (yet not blocked to protect comp.c and comp.c++) all of the time for a
> >> long time.
> >
> > That you don't like the correct answer doesn't make it dishonest.
> I picked up that you are only trolling be a short while ago. Before this
> I thought it was very probable yet less than 100% certain. That you
> sustain the straw man deception make my assessment of your motives
> complete.

That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.

On 7/29/2022 10:32 PM, Dennis Bush wrote:
> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>>
>>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>>> IT is absolutely true that any function call that creates infinite
>>>>>>> recursion will never return to its caller.
>>>>>> That is great that you said this, I may stop totally ignoring every
>>>>>> one of your posts without even glancing at them for half a second.
>>>>>>
>>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>>> would never reach its "ret" instruction(final state), thus never halt
>>>>>> according to:
>>>>>>
>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>> enters a final state. (Linz:1990:234)
>>>>>>
>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>>
>>>>> Nope. You have that WRONG.
>>>>>
>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>>
>>>> As usual you resort to the strawman deception:
>>>>
>>>> *straw man*
>>>> An intentionally misrepresented proposition that is set up because it is
>>>> easier to defeat than an opponent's real argument.
>>>> https://www.lexico.com/en/definition/straw_man
>>>>
>>>> *The question is*
>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
>>>> instruction of P whether or not H ever aborts its simulation of P?
>>>
>>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
>>>
>>> Therefore H is not a halt decider because it is answering the wrong question.
>>>
>>>>
>>>> The lack of an honest answer to this question gets you totally ignored
>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
>>>> long time.
>>>
>>> That you don't like the correct answer doesn't make it dishonest.
>> I picked up that you are only trolling be a short while ago. Before this
>> I thought it was very probable yet less than 100% certain. That you
>> sustain the straw man deception make my assessment of your motives
>> complete.
>
> That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
>

H(P,P) does correctly determine the actual halt status of its input.
While people dodge this point the dialogue remains dead.

--
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 Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
> On 7/29/2022 10:32 PM, Dennis Bush wrote:
> > On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
> >> On 7/29/2022 10:18 PM, Dennis Bush wrote:
> >>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
> >>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >>>>>
> >>>>> On 7/29/22 10:47 PM, olcott wrote:
> >>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>>>>>> On 7/29/22 10:11 PM, olcott wrote:
> >>>>>>> IT is absolutely true that any function call that creates infinite
> >>>>>>> recursion will never return to its caller.
> >>>>>> That is great that you said this, I may stop totally ignoring every
> >>>>>> one of your posts without even glancing at them for half a second.
> >>>>>>
> >>>>>> It is also true that the correctly simulated input to H(P,P) by H
> >>>>>> would never reach its "ret" instruction(final state), thus never halt
> >>>>>> according to:
> >>>>>>
> >>>>>> *computation that halts* … the Turing machine will halt whenever it
> >>>>>> enters a final state. (Linz:1990:234)
> >>>>>>
> >>>>>> whether or not H(P,P) ever aborts the simulation of its input.
> >>>>>
> >>>>> Nope. You have that WRONG.
> >>>>>
> >>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
> >>>>> never returns the answer, so that H isn't a correct halt decider.
> >>>>>
> >>>> As usual you resort to the strawman deception:
> >>>>
> >>>> *straw man*
> >>>> An intentionally misrepresented proposition that is set up because it is
> >>>> easier to defeat than an opponent's real argument.
> >>>> https://www.lexico.com/en/definition/straw_man
> >>>>
> >>>> *The question is*
> >>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
> >>>> instruction of P whether or not H ever aborts its simulation of P?
> >>>
> >>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
> >>>
> >>> Therefore H is not a halt decider because it is answering the wrong question.
> >>>
> >>>>
> >>>> The lack of an honest answer to this question gets you totally ignored
> >>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
> >>>> long time.
> >>>
> >>> That you don't like the correct answer doesn't make it dishonest.
> >> I picked up that you are only trolling be a short while ago. Before this
> >> I thought it was very probable yet less than 100% certain. That you
> >> sustain the straw man deception make my assessment of your motives
> >> complete.
> >
> > That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
> >
> H(P,P) does correctly determine the actual halt status of its input.
> While people dodge this point the dialogue remains dead.

And that's the problem. H(P,P) isn't supposed to determine the halt status of "its input". It's supposed to determine the halt status of P(P) which it fails to do.

On 7/29/22 11:12 PM, olcott wrote:
> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>
>> On 7/29/22 10:47 PM, olcott wrote:
>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>> IT is absolutely true that any function call that creates infinite
>>>> recursion will never return to its caller.
>>> That is great that you said this, I may stop totally ignoring every
>>> one of your posts without even glancing at them for half a second.
>>>
>>> It is also true that the correctly simulated input to H(P,P) by H
>>> would never reach its "ret" instruction(final state), thus never halt
>>> according to:
>>>
>>> *computation that halts* … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> whether or not H(P,P) ever aborts the simulation of its input.
>>
>> Nope. You have that WRONG.
>>
>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>> never returns the answer, so that H isn't a correct halt decider.
>>
>
> As usual you resort to the strawman deception:
>
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> *The question is*
> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
> instruction of P whether or not H ever aborts its simulation of P?
>

No, that isn't the question if H is a Halt Decider, YOU are putting up
the Strawman

The question that H needs to answer is does the program and input
represented by the input to H reach a final state (Halt) or not.

> The lack of an honest answer to this question gets you totally ignored
> (yet not blocked to protect comp.c and comp.c++) all of the time for a
> long time.
>

Your problem is you don't look at the honest question!

You also seem tho have a short memory, and don't like it when answers
are actually COMPLETE and explain what they actually mean. You just say
that adding the explaintion that shows why it makes H an INCORRECT Halt
Decider (but maybe a correct POOP decider) as off topic,

Yes, you have shown that no possible H can simulate its input to the
final return instruction within it. THIS IS NOT THE DEFINITION OF HALTING.

What this proves is that there does not exist an H can not actually
prove that the P built from it will ever halt. This does NOT mean that
the P built from it doesn't Halt.

The H's that never abort, do prove that the P built from them don't
halt, but don't give that answer, so fail to be deciders.

The H's that do abort, while maybe creating a correct PARTIAL simulation
of the input that didn't reach the return in that PARTIAL simumlation,
doesn't show that the COMPLETE simulation doesn't reach that return
instruction.

You present a claimed "proof" that it can't happen, but that proof is
base on LIES, aka false premises, that just show how ignorant of the
actual rules of logic and computations you are.

The fact that you just keep repeating those lies, even when they have
been pointed out to you just shows that you don't actually care about
trying to actually prove your statement, but are only on a path to try
to deceive others into beleiving your lies.

On 7/29/22 11:47 PM, olcott wrote:
> On 7/29/2022 10:32 PM, Dennis Bush wrote:
>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>>>> IT is absolutely true that any function call that creates infinite
>>>>>>>> recursion will never return to its caller.
>>>>>>> That is great that you said this, I may stop totally ignoring every
>>>>>>> one of your posts without even glancing at them for half a second.
>>>>>>>
>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>>>> would never reach its "ret" instruction(final state), thus never
>>>>>>> halt
>>>>>>> according to:
>>>>>>>
>>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>
>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>>>
>>>>>> Nope. You have that WRONG.
>>>>>>
>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>>>
>>>>> As usual you resort to the strawman deception:
>>>>>
>>>>> *straw man*
>>>>> An intentionally misrepresented proposition that is set up because
>>>>> it is
>>>>> easier to defeat than an opponent's real argument.
>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>
>>>>> *The question is*
>>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
>>>>> instruction of P whether or not H ever aborts its simulation of P?
>>>>
>>>> Which is not the question a halt decider must answer. If H is a halt
>>>> decider, H(P,P) *must* answer if P(P) halts, not if there exists an
>>>> implementation of the function H that can simulate the function call
>>>> P(P) to a final state.
>>>>
>>>> Therefore H is not a halt decider because it is answering the wrong
>>>> question.
>>>>
>>>>>
>>>>> The lack of an honest answer to this question gets you totally ignored
>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
>>>>> long time.
>>>>
>>>> That you don't like the correct answer doesn't make it dishonest.
>>> I picked up that you are only trolling be a short while ago. Before this
>>> I thought it was very probable yet less than 100% certain. That you
>>> sustain the straw man deception make my assessment of your motives
>>> complete.
>>
>> That I point out that you're giving the correct answer to the wrong
>> question isn't a strawman error.  It's pointing out that you're not
>> solving the problem you think you're solving.
>>
>
> H(P,P) does correctly determine the actual halt status of its input.
> While people dodge this point the dialogue remains dead.
>

No, it doesn't, as if H is actually a Halt Decider, then BY DEFINITION
this input represents P(P) but you claim that it doesn't mean that.

As has been pointed out many times, "Inputs", aka "Stirngs" don't have
ANY sort of behavior in and of themselves, but only by what they represent.

If the input to H(P,P) doesn't represent P(P), then why does P make that
call to ask about itself?

All you have done is PROVED that H actually isn't a Halt Decider.

On Saturday, 30 July 2022 at 04:11:50 UTC+2, olcott wrote:
> No further replies form me until you answer this question:
OK. Do as you please.

But I won't answer your question until you answer mine... Will I call you an idiot?

> Do you comprehend that every function called in infinite recursion never
> returns any value to its caller?
Do you comprehend that this is not always true. Even you don't believe it's true!

Why does the definition of an infinitely recursive function halt?

Infinite definitions halt!

> I am trying to get my work validated before I die of cancer so I have no
> patience for head games.
Just as well... this is not a headgame, but a demonstration of your misunderstanding.

Either I will show sympathy for your terminal ilness or I won't,

If you guess that I will show sympathy, then I won't.
If you guess that I won't show sympathy, then I will.

Guess correctly whether I will show sympathy; or not.

On 7/29/22 11:27 PM, olcott wrote:
> On 7/29/2022 10:18 PM, Dennis Bush wrote:
>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>
>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>> IT is absolutely true that any function call that creates infinite
>>>>>> recursion will never return to its caller.
>>>>> That is great that you said this, I may stop totally ignoring every
>>>>> one of your posts without even glancing at them for half a second.
>>>>>
>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>> would never reach its "ret" instruction(final state), thus never halt
>>>>> according to:
>>>>>
>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>>
>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>
>>>> Nope. You have that WRONG.
>>>>
>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>
>>> As usual you resort to the strawman deception:
>>>
>>> *straw man*
>>> An intentionally misrepresented proposition that is set up because it is
>>> easier to defeat than an opponent's real argument.
>>> https://www.lexico.com/en/definition/straw_man
>>>
>>> *The question is*
>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
>>> instruction of P whether or not H ever aborts its simulation of P?
>>
>> Which is not the question a halt decider must answer.  If H is a halt
>> decider, H(P,P) *must* answer if P(P) halts, not if there exists an
>> implementation of the function H that can simulate the function call
>> P(P) to a final state.
>>
>> Therefore H is not a halt decider because it is answering the wrong
>> question.
>>
>>>
>>> The lack of an honest answer to this question gets you totally ignored
>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
>>> long time.
>>
>> That you don't like the correct answer doesn't make it dishonest.
>
> I picked up that you are only trolling be a short while ago. Before this
> I thought it was very probable yet less than 100% certain. That you
> sustain the straw man deception make my assessment of your motives
> complete.
>

You DO realize that by calling references to the actual Halitng Problem
a "Strawman", you are admitting that you H isn't answering the Halting
Problem?

Nice to see you being "Honest" for once.

On Fri, 29 Jul 2022 22:47:45 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/29/2022 10:32 PM, Dennis Bush wrote:
> > On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
> >> On 7/29/2022 10:18 PM, Dennis Bush wrote:
> >>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
> >>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >>>>>
> >>>>> On 7/29/22 10:47 PM, olcott wrote:
> >>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>>>>>> On 7/29/22 10:11 PM, olcott wrote:
> >>>>>>> IT is absolutely true that any function call that creates
> >>>>>>> infinite recursion will never return to its caller.
> >>>>>> That is great that you said this, I may stop totally ignoring
> >>>>>> every one of your posts without even glancing at them for half
> >>>>>> a second.
> >>>>>>
> >>>>>> It is also true that the correctly simulated input to H(P,P)
> >>>>>> by H would never reach its "ret" instruction(final state),
> >>>>>> thus never halt according to:
> >>>>>>
> >>>>>> *computation that halts* … the Turing machine will halt
> >>>>>> whenever it enters a final state. (Linz:1990:234)
> >>>>>>
> >>>>>> whether or not H(P,P) ever aborts the simulation of its input.
> >>>>>>
> >>>>>
> >>>>> Nope. You have that WRONG.
> >>>>>
> >>>>> If H doesn't abort, then yes, then P(P) will never halt, but
> >>>>> H(P,P) never returns the answer, so that H isn't a correct halt
> >>>>> decider.
> >>>> As usual you resort to the strawman deception:
> >>>>
> >>>> *straw man*
> >>>> An intentionally misrepresented proposition that is set up
> >>>> because it is easier to defeat than an opponent's real argument.
> >>>> https://www.lexico.com/en/definition/straw_man
> >>>>
> >>>> *The question is*
> >>>> Does the input to H(P,P) correctly simulated by H ever reach the
> >>>> "ret" instruction of P whether or not H ever aborts its
> >>>> simulation of P?
> >>>
> >>> Which is not the question a halt decider must answer. If H is a
> >>> halt decider, H(P,P) *must* answer if P(P) halts, not if there
> >>> exists an implementation of the function H that can simulate the
> >>> function call P(P) to a final state.
> >>>
> >>> Therefore H is not a halt decider because it is answering the
> >>> wrong question.
> >>>>
> >>>> The lack of an honest answer to this question gets you totally
> >>>> ignored (yet not blocked to protect comp.c and comp.c++) all of
> >>>> the time for a long time.
> >>>
> >>> That you don't like the correct answer doesn't make it dishonest.
> >>>
> >> I picked up that you are only trolling be a short while ago.
> >> Before this I thought it was very probable yet less than 100%
> >> certain. That you sustain the straw man deception make my
> >> assessment of your motives complete.
> >
> > That I point out that you're giving the correct answer to the wrong
> > question isn't a strawman error. It's pointing out that you're not
> > solving the problem you think you're solving.
>
> H(P,P) does correctly determine the actual halt status of its input.
> While people dodge this point the dialogue remains dead.

No, your H gets the halt decision of the following wrong:

void Px()
{ (void)H(Px, Px);
}

My SHD gets the answer correct (i.e. that Px halts).

/Flibble

On 7/30/2022 7:05 AM, Skep Dick wrote:
> On Saturday, 30 July 2022 at 04:11:50 UTC+2, olcott wrote:
>> No further replies form me until you answer this question:
> OK. Do as you please.
>
> But I won't answer your question until you answer mine... Will I call you an idiot?
>
>
>> Do you comprehend that every function called in infinite recursion never
>> returns any value to its caller?
>
> Do you comprehend that this is not always true. Even you don't believe it's true!
>

Then you could provide a counter-example showing a function called in
infinite recursion returning a value to the function that called it in
infinitie recursion.

--
Copyright 2022 Pete Olcott

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

On 7/29/2022 10:50 PM, Dennis Bush wrote:
> On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
>> On 7/29/2022 10:32 PM, Dennis Bush wrote:
>>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
>>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
>>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
>>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>>>>> IT is absolutely true that any function call that creates infinite
>>>>>>>>> recursion will never return to its caller.
>>>>>>>> That is great that you said this, I may stop totally ignoring every
>>>>>>>> one of your posts without even glancing at them for half a second.
>>>>>>>>
>>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>>>>> would never reach its "ret" instruction(final state), thus never halt
>>>>>>>> according to:
>>>>>>>>
>>>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>
>>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>>>>
>>>>>>> Nope. You have that WRONG.
>>>>>>>
>>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>>>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>>>>
>>>>>> As usual you resort to the strawman deception:
>>>>>>
>>>>>> *straw man*
>>>>>> An intentionally misrepresented proposition that is set up because it is
>>>>>> easier to defeat than an opponent's real argument.
>>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>>
>>>>>> *The question is*
>>>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
>>>>>> instruction of P whether or not H ever aborts its simulation of P?
>>>>>
>>>>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
>>>>>
>>>>> Therefore H is not a halt decider because it is answering the wrong question.
>>>>>
>>>>>>
>>>>>> The lack of an honest answer to this question gets you totally ignored
>>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
>>>>>> long time.
>>>>>
>>>>> That you don't like the correct answer doesn't make it dishonest.
>>>> I picked up that you are only trolling be a short while ago. Before this
>>>> I thought it was very probable yet less than 100% certain. That you
>>>> sustain the straw man deception make my assessment of your motives
>>>> complete.
>>>
>>> That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
>>>
>> H(P,P) does correctly determine the actual halt status of its input.
>> While people dodge this point the dialogue remains dead.
>
> And that's the problem. H(P,P) isn't supposed to determine the halt status of "its input". It's supposed to determine the halt status of P(P) which it fails to do.

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

--
Copyright 2022 Pete Olcott

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

On Sat, 30 Jul 2022 10:20:22 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/30/2022 7:05 AM, Skep Dick wrote:
> > On Saturday, 30 July 2022 at 04:11:50 UTC+2, olcott wrote:
> >> No further replies form me until you answer this question:
> > OK. Do as you please.
> >
> > But I won't answer your question until you answer mine... Will I
> > call you an idiot?
> >
> >
> >> Do you comprehend that every function called in infinite recursion
> >> never returns any value to its caller?
> >
> > Do you comprehend that this is not always true. Even you don't
> > believe it's true!
>
> Then you could provide a counter-example showing a function called in
> infinite recursion returning a value to the function that called it
> in infinitie recursion.

[Strachey 1965] and associated proofs DO NOT HAVE INFINITE RECURSION.

/Flibble

On 7/30/2022 6:17 AM, Richard Damon wrote:
>
> On 7/29/22 11:12 PM, olcott wrote:
>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>
>>> On 7/29/22 10:47 PM, olcott wrote:
>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>> IT is absolutely true that any function call that creates infinite
>>>>> recursion will never return to its caller.
>>>> That is great that you said this, I may stop totally ignoring every
>>>> one of your posts without even glancing at them for half a second.
>>>>
>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>> would never reach its "ret" instruction(final state), thus never
>>>> halt according to:
>>>>
>>>> *computation that halts* … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>
>>> Nope. You have that WRONG.
>>>
>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>> never returns the answer, so that H isn't a correct halt decider.
>>>
>>
>> As usual you resort to the strawman deception:
>>
>> *straw man*
>> An intentionally misrepresented proposition that is set up because it
>> is easier to defeat than an opponent's real argument.
>> https://www.lexico.com/en/definition/straw_man
>>
>> *The question is*
>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
>> instruction of P whether or not H ever aborts its simulation of P?
>>
>
> No, that isn't the question

*Until you answer that question you will be ignored*
Make sure you put [question answered] in the subject line because I
won't even glance at any of your other replies until then.

I will only tolerate an honest dialogue which requires that points of
mutual agreement be reached. Without points of mutual agreement the
dialogue is not an honest dialogue and I will not tolerate this
dishonestly.

--
Copyright 2022 Pete Olcott

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

On 7/30/22 11:23 AM, olcott wrote:
> On 7/29/2022 10:50 PM, Dennis Bush wrote:
>> On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
>>> On 7/29/2022 10:32 PM, Dennis Bush wrote:
>>>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
>>>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
>>>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
>>>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>>>>>> IT is absolutely true that any function call that creates
>>>>>>>>>> infinite
>>>>>>>>>> recursion will never return to its caller.
>>>>>>>>> That is great that you said this, I may stop totally ignoring
>>>>>>>>> every
>>>>>>>>> one of your posts without even glancing at them for half a second.
>>>>>>>>>
>>>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>>>>>> would never reach its "ret" instruction(final state), thus
>>>>>>>>> never halt
>>>>>>>>> according to:
>>>>>>>>>
>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>> whenever it
>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>
>>>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>>>>>
>>>>>>>> Nope. You have that WRONG.
>>>>>>>>
>>>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>>>>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>>>>>
>>>>>>> As usual you resort to the strawman deception:
>>>>>>>
>>>>>>> *straw man*
>>>>>>> An intentionally misrepresented proposition that is set up
>>>>>>> because it is
>>>>>>> easier to defeat than an opponent's real argument.
>>>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>>>
>>>>>>> *The question is*
>>>>>>> Does the input to H(P,P) correctly simulated by H ever reach the
>>>>>>> "ret"
>>>>>>> instruction of P whether or not H ever aborts its simulation of P?
>>>>>>
>>>>>> Which is not the question a halt decider must answer. If H is a
>>>>>> halt decider, H(P,P) *must* answer if P(P) halts, not if there
>>>>>> exists an implementation of the function H that can simulate the
>>>>>> function call P(P) to a final state.
>>>>>>
>>>>>> Therefore H is not a halt decider because it is answering the
>>>>>> wrong question.
>>>>>>
>>>>>>>
>>>>>>> The lack of an honest answer to this question gets you totally
>>>>>>> ignored
>>>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time
>>>>>>> for a
>>>>>>> long time.
>>>>>>
>>>>>> That you don't like the correct answer doesn't make it dishonest.
>>>>> I picked up that you are only trolling be a short while ago. Before
>>>>> this
>>>>> I thought it was very probable yet less than 100% certain. That you
>>>>> sustain the straw man deception make my assessment of your motives
>>>>> complete.
>>>>
>>>> That I point out that you're giving the correct answer to the wrong
>>>> question isn't a strawman error. It's pointing out that you're not
>>>> solving the problem you think you're solving.
>>>>
>>> H(P,P) does correctly determine the actual halt status of its input.
>>> While people dodge this point the dialogue remains dead.
>>
>> And that's the problem.  H(P,P) isn't supposed to determine the halt
>> status of "its input".  It's supposed to determine the halt status of
>> P(P) which it fails to do.
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
>

And the actual behavior of the input to H(P,P) MUST BE the behavior of
P(P) or you are lying that you are following the Halting Problem.

Remember H(M,x) accepts if M(x) Halts, and rejects if M(x) never Halts.
DEFINITION.

This is also clearly shown by the fact that this is what P is doing in
its call to H(P,P), and P is DEFINED To be asking H about what P does
with its input.

So, Which ways are your claims wrong.

Does H just give the wrong answer?

Is P not the program it needs to be?

Do H just do incorrect analysis of its input and derive a wrong answer
because of that?

Are you just an IDIOT?

On Sat, 30 Jul 2022 10:30:25 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/30/2022 6:17 AM, Richard Damon wrote:
> >
> > On 7/29/22 11:12 PM, olcott wrote:
> >> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >>>
> >>> On 7/29/22 10:47 PM, olcott wrote:
> >>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>>>> On 7/29/22 10:11 PM, olcott wrote:
> >>>>> IT is absolutely true that any function call that creates
> >>>>> infinite recursion will never return to its caller.
> >>>> That is great that you said this, I may stop totally ignoring
> >>>> every one of your posts without even glancing at them for half a
> >>>> second.
> >>>>
> >>>> It is also true that the correctly simulated input to H(P,P) by
> >>>> H would never reach its "ret" instruction(final state), thus
> >>>> never halt according to:
> >>>>
> >>>> *computation that halts* … the Turing machine will halt whenever
> >>>> it enters a final state. (Linz:1990:234)
> >>>>
> >>>> whether or not H(P,P) ever aborts the simulation of its input.
> >>>
> >>> Nope. You have that WRONG.
> >>>
> >>> If H doesn't abort, then yes, then P(P) will never halt, but
> >>> H(P,P) never returns the answer, so that H isn't a correct halt
> >>> decider.
> >>
> >> As usual you resort to the strawman deception:
> >>
> >> *straw man*
> >> An intentionally misrepresented proposition that is set up because
> >> it is easier to defeat than an opponent's real argument.
> >> https://www.lexico.com/en/definition/straw_man
> >>
> >> *The question is*
> >> Does the input to H(P,P) correctly simulated by H ever reach the
> >> "ret" instruction of P whether or not H ever aborts its simulation
> >> of P?
> >
> > No, that isn't the question
>
> *Until you answer that question you will be ignored*
> Make sure you put [question answered] in the subject line because I
> won't even glance at any of your other replies until then.
>
> I will only tolerate an honest dialogue which requires that points of
> mutual agreement be reached. Without points of mutual agreement the
> dialogue is not an honest dialogue and I will not tolerate this
> dishonestly.

In your mind an honest dialogue is a dialogue in which Olcott says
Olcott is correct and everyone else is incorrect when pointing out that
Olcott is incorrect.

/Flibble

On Saturday, July 30, 2022 at 11:23:25 AM UTC-4, olcott wrote:
> On 7/29/2022 10:50 PM, Dennis Bush wrote:
> > On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
> >> On 7/29/2022 10:32 PM, Dennis Bush wrote:
> >>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
> >>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
> >>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
> >>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >>>>>>>
> >>>>>>> On 7/29/22 10:47 PM, olcott wrote:
> >>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
> >>>>>>>>> IT is absolutely true that any function call that creates infinite
> >>>>>>>>> recursion will never return to its caller.
> >>>>>>>> That is great that you said this, I may stop totally ignoring every
> >>>>>>>> one of your posts without even glancing at them for half a second.
> >>>>>>>>
> >>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
> >>>>>>>> would never reach its "ret" instruction(final state), thus never halt
> >>>>>>>> according to:
> >>>>>>>>
> >>>>>>>> *computation that halts* … the Turing machine will halt whenever it
> >>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>
> >>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
> >>>>>>>
> >>>>>>> Nope. You have that WRONG.
> >>>>>>>
> >>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
> >>>>>>> never returns the answer, so that H isn't a correct halt decider.
> >>>>>>>
> >>>>>> As usual you resort to the strawman deception:
> >>>>>>
> >>>>>> *straw man*
> >>>>>> An intentionally misrepresented proposition that is set up because it is
> >>>>>> easier to defeat than an opponent's real argument.
> >>>>>> https://www.lexico.com/en/definition/straw_man
> >>>>>>
> >>>>>> *The question is*
> >>>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
> >>>>>> instruction of P whether or not H ever aborts its simulation of P?
> >>>>>
> >>>>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
> >>>>>
> >>>>> Therefore H is not a halt decider because it is answering the wrong question.
> >>>>>
> >>>>>>
> >>>>>> The lack of an honest answer to this question gets you totally ignored
> >>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
> >>>>>> long time.
> >>>>>
> >>>>> That you don't like the correct answer doesn't make it dishonest.
> >>>> I picked up that you are only trolling be a short while ago. Before this
> >>>> I thought it was very probable yet less than 100% certain. That you
> >>>> sustain the straw man deception make my assessment of your motives
> >>>> complete.
> >>>
> >>> That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
> >>>
> >> H(P,P) does correctly determine the actual halt status of its input.
> >> While people dodge this point the dialogue remains dead.
> >
> > And that's the problem. H(P,P) isn't supposed to determine the halt status of "its input". It's supposed to determine the halt status of P(P) which it fails to do.
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.

FALSE. A halt decider must map the halting function. The halting function maps Pa(Pa) to halting. Your Ha does not.

Therefore Ha is not a halt decider.

On 7/30/22 11:30 AM, olcott wrote:
> On 7/30/2022 6:17 AM, Richard Damon wrote:
>>
>> On 7/29/22 11:12 PM, olcott wrote:
>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>
>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>> IT is absolutely true that any function call that creates infinite
>>>>>> recursion will never return to its caller.
>>>>> That is great that you said this, I may stop totally ignoring every
>>>>> one of your posts without even glancing at them for half a second.
>>>>>
>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>> would never reach its "ret" instruction(final state), thus never
>>>>> halt according to:
>>>>>
>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>>
>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>
>>>> Nope. You have that WRONG.
>>>>
>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>
>>>
>>> As usual you resort to the strawman deception:
>>>
>>> *straw man*
>>> An intentionally misrepresented proposition that is set up because it
>>> is easier to defeat than an opponent's real argument.
>>> https://www.lexico.com/en/definition/straw_man
>>>
>>> *The question is*
>>> Does the input to H(P,P) correctly simulated by H ever reach the
>>> "ret" instruction of P whether or not H ever aborts its simulation of P?
>>>
>>
>> No, that isn't the question
>
> *Until you answer that question you will be ignored*
> Make sure you put [question answered] in the subject line because I
> won't even glance at any of your other replies until then.
>
> I will only tolerate an honest dialogue which requires that points of
> mutual agreement be reached. Without points of mutual agreement the
> dialogue is not an honest dialogue and I will not tolerate this
> dishonestly.
>
>

So, you admit that you don't actually care about Halting, but only your
POOP problem?

That is the direct consequence of your statement.

And, as I have said many times before:

Yes, you can show that NO verison of H can correctly simulate this input
to the "return" instruction, but that doesn't mean H is correct to
return non-halting. But it doesn't prove what you claim.

You get TWO different "classes" of H, that generate different classes of
results, the first, we can call Hn, which won't abort its simulation,
and the Pn built form that Hn, will in fact make Pn(Pn) non-halting as
yoyu claim, but Hn(Pn,Pn) also gets caught in that infinite loop and
thus never gives that answer and fails to be a decider.

The other class of H, wc can call Ha, because it WILL (incorretly)
decide to abort its simulation and return 0. The Pa built from this can
be shown to have Pa(Pa) to be Halting, as Pa(Pa) will call Ha(Pa,Pa)
which will (by your logic) treat it INCORRECTLY as a call to Ha(Pn,Pn)
and thus decide INCORRECTLY to abort its simulation and return 0 to Pa
and that Pa will return (aka Halt).

Thus

Pn(Pn) is non-halting, but Hn(Pn,Pn) never returns that answer.
Pa(Pa) hatls so Ha(Pa,Pa) which returns 0 is wrong.

Not all is lost, since

Ha(Pn,Pn) is correct that Pn(Pm) is non-halting and Hn(Pa,Pa) will
simulate that input to the halting point (since it won't abort) and
correctly decide that it is Halting. The problem is these aren't the
cases you need to decide.

So, you statement that no H can simulate its input to the return doens't
prove that it is the right answer for a HALTING DECIDER, and the right
answer for THAT is based on the machine that was given to it. Partial
simulations, even if "correct" for what they show do not prove
non-halting. You need to look at the actual machine, or the equivalent
unaborted simulation, which in this case both halt not that long after H
stopped its simulation.

Yes, with CORRECT rules, you can SOMETIMES prove from the partial
simulatin that it would never reach a final state, but for that you need
to use CORRECT rules. Your rule (3) that doesn't look at the H that P
calls, is just an incorrect rule and you repeatedly claiming it just
shows you don't understand how logic works, or even what it means to
prove something in a formal logic system.

You are just PROVING your own stupidity. I do wonder if you have just
brainwashed yourself into believing your own lies, or if you just lost
contact with reality and don't actualy care about what it actually true.

On 7/30/2022 10:41 AM, Dennis Bush wrote:
> On Saturday, July 30, 2022 at 11:23:25 AM UTC-4, olcott wrote:
>> On 7/29/2022 10:50 PM, Dennis Bush wrote:
>>> On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
>>>> On 7/29/2022 10:32 PM, Dennis Bush wrote:
>>>>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
>>>>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
>>>>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
>>>>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>>>>>>> IT is absolutely true that any function call that creates infinite
>>>>>>>>>>> recursion will never return to its caller.
>>>>>>>>>> That is great that you said this, I may stop totally ignoring every
>>>>>>>>>> one of your posts without even glancing at them for half a second.
>>>>>>>>>>
>>>>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>>>>>>> would never reach its "ret" instruction(final state), thus never halt
>>>>>>>>>> according to:
>>>>>>>>>>
>>>>>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>
>>>>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>>>>>>
>>>>>>>>> Nope. You have that WRONG.
>>>>>>>>>
>>>>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>>>>>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>>>>>>
>>>>>>>> As usual you resort to the strawman deception:
>>>>>>>>
>>>>>>>> *straw man*
>>>>>>>> An intentionally misrepresented proposition that is set up because it is
>>>>>>>> easier to defeat than an opponent's real argument.
>>>>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>>>>
>>>>>>>> *The question is*
>>>>>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
>>>>>>>> instruction of P whether or not H ever aborts its simulation of P?
>>>>>>>
>>>>>>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
>>>>>>>
>>>>>>> Therefore H is not a halt decider because it is answering the wrong question.
>>>>>>>
>>>>>>>>
>>>>>>>> The lack of an honest answer to this question gets you totally ignored
>>>>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
>>>>>>>> long time.
>>>>>>>
>>>>>>> That you don't like the correct answer doesn't make it dishonest.
>>>>>> I picked up that you are only trolling be a short while ago. Before this
>>>>>> I thought it was very probable yet less than 100% certain. That you
>>>>>> sustain the straw man deception make my assessment of your motives
>>>>>> complete.
>>>>>
>>>>> That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
>>>>>
>>>> H(P,P) does correctly determine the actual halt status of its input.
>>>> While people dodge this point the dialogue remains dead.
>>>
>>> And that's the problem. H(P,P) isn't supposed to determine the halt status of "its input". It's supposed to determine the halt status of P(P) which it fails to do.
>> A halt decider must compute the mapping from its inputs to an accept or
>> reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>
> FALSE. A halt decider must map the halting function.

The behavior of any sequence of instructions that is not an actual input
to H is not in the domain of the function that H computes.

When you ask Bill a question he is supposed to answer the question asked
and not some other question that is only in your head.

--
Copyright 2022 Pete Olcott

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

On Saturday, July 30, 2022 at 12:39:39 PM UTC-4, olcott wrote:
> On 7/30/2022 10:41 AM, Dennis Bush wrote:
> > On Saturday, July 30, 2022 at 11:23:25 AM UTC-4, olcott wrote:
> >> On 7/29/2022 10:50 PM, Dennis Bush wrote:
> >>> On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
> >>>> On 7/29/2022 10:32 PM, Dennis Bush wrote:
> >>>>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
> >>>>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
> >>>>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
> >>>>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >>>>>>>>>
> >>>>>>>>> On 7/29/22 10:47 PM, olcott wrote:
> >>>>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>>>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
> >>>>>>>>>>> IT is absolutely true that any function call that creates infinite
> >>>>>>>>>>> recursion will never return to its caller.
> >>>>>>>>>> That is great that you said this, I may stop totally ignoring every
> >>>>>>>>>> one of your posts without even glancing at them for half a second.
> >>>>>>>>>>
> >>>>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
> >>>>>>>>>> would never reach its "ret" instruction(final state), thus never halt
> >>>>>>>>>> according to:
> >>>>>>>>>>
> >>>>>>>>>> *computation that halts* … the Turing machine will halt whenever it
> >>>>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>>>
> >>>>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
> >>>>>>>>>
> >>>>>>>>> Nope. You have that WRONG.
> >>>>>>>>>
> >>>>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
> >>>>>>>>> never returns the answer, so that H isn't a correct halt decider.
> >>>>>>>>>
> >>>>>>>> As usual you resort to the strawman deception:
> >>>>>>>>
> >>>>>>>> *straw man*
> >>>>>>>> An intentionally misrepresented proposition that is set up because it is
> >>>>>>>> easier to defeat than an opponent's real argument.
> >>>>>>>> https://www.lexico.com/en/definition/straw_man
> >>>>>>>>
> >>>>>>>> *The question is*
> >>>>>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
> >>>>>>>> instruction of P whether or not H ever aborts its simulation of P?
> >>>>>>>
> >>>>>>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
> >>>>>>>
> >>>>>>> Therefore H is not a halt decider because it is answering the wrong question.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> The lack of an honest answer to this question gets you totally ignored
> >>>>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
> >>>>>>>> long time.
> >>>>>>>
> >>>>>>> That you don't like the correct answer doesn't make it dishonest.
> >>>>>> I picked up that you are only trolling be a short while ago. Before this
> >>>>>> I thought it was very probable yet less than 100% certain. That you
> >>>>>> sustain the straw man deception make my assessment of your motives
> >>>>>> complete.
> >>>>>
> >>>>> That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
> >>>>>
> >>>> H(P,P) does correctly determine the actual halt status of its input.
> >>>> While people dodge this point the dialogue remains dead.
> >>>
> >>> And that's the problem. H(P,P) isn't supposed to determine the halt status of "its input". It's supposed to determine the halt status of P(P) which it fails to do.
> >> A halt decider must compute the mapping from its inputs to an accept or
> >> reject state on the basis of the actual behavior that is actually
> >> specified by these inputs.
> >
> > FALSE. A halt decider must map the halting function.
> The behavior of any sequence of instructions that is not an actual input
> to H is not in the domain of the function that H computes.

Then why do you insist that Ha(Pa,Pa) reports the behavior of Pn(Pn)?

>
> When you ask Bill a question he is supposed to answer the question asked
> and not some other question that is only in your head.

Correct. We asked Bill if Pa(Pa) halts, not if "the input" to Ha(Pa,Pa) halts.

On 7/30/2022 10:56 AM, Richard Damon wrote:
>
> On 7/30/22 11:30 AM, olcott wrote:
>> On 7/30/2022 6:17 AM, Richard Damon wrote:
>>>
>>> On 7/29/22 11:12 PM, olcott wrote:
>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>>
>>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>>> IT is absolutely true that any function call that creates
>>>>>>> infinite recursion will never return to its caller.
>>>>>> That is great that you said this, I may stop totally ignoring
>>>>>> every one of your posts without even glancing at them for half a
>>>>>> second.
>>>>>>
>>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>>> would never reach its "ret" instruction(final state), thus never
>>>>>> halt according to:
>>>>>>
>>>>>> *computation that halts* … the Turing machine will halt whenever
>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>
>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>>
>>>>> Nope. You have that WRONG.
>>>>>
>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>>
>>>>
>>>> As usual you resort to the strawman deception:
>>>>
>>>> *straw man*
>>>> An intentionally misrepresented proposition that is set up because
>>>> it is easier to defeat than an opponent's real argument.
>>>> https://www.lexico.com/en/definition/straw_man
>>>>
>>>> *The question is*
>>>> Does the input to H(P,P) correctly simulated by H ever reach the
>>>> "ret" instruction of P whether or not H ever aborts its simulation
>>>> of P?
>>>>
>>>
>>> No, that isn't the question
>>
>> *Until you answer that question you will be ignored*
>> Make sure you put [question answered] in the subject line because I
>> won't even glance at any of your other replies until then.
>>
>> I will only tolerate an honest dialogue which requires that points of
>> mutual agreement be reached. Without points of mutual agreement the
>> dialogue is not an honest dialogue and I will not tolerate this
>> dishonestly.
>>
>>
>
> So, you admit that you don't actually care about Halting, but only your
> POOP problem?
>
> That is the direct consequence of your statement.
>
>
> And, as I have said many times before:
>
> Yes, you can show that NO verison of H can correctly simulate this input
> to the "return" instruction, but that doesn't mean H is correct to
> return non-halting. But it doesn't prove what you claim.
You always phrase this as if the x86 emulation of the input to H(P,P) by
H is somehow incorrect, yet we can verify that the line-by-line
execution trace of the simulated input to H(P,P) exactly matches the
line-by-line behavior specified by the x86 source-code of P.

This means that it is untruthful to say that H(P,P) cannot simulate its
input until this input reaches the "ret" instruction of P as if this
simulation was incorrect.

The truthful way of saying this is that the correct simulation of the
input to H(P,P) never reaches its "ret" instruction because this input
specifies infinitely recursive simulation to H.

Because a simulating halt decider must always abort its simulation of
every input that would otherwise keep running the fact that H aborts its
simulation does not negate the fact that the input specified a
non-halting behavior pattern to H.

The correct x86 emulation of the input to H(P,P) by H never reaches the
final state of P (The "ret" instruction of P) whether or not H ever
aborts its simulation, therefore because

*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

H correctly rejects its input as non-halting.

--
Copyright 2022 Pete Olcott

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

On 7/30/22 12:39 PM, olcott wrote:
> On 7/30/2022 10:41 AM, Dennis Bush wrote:
>> On Saturday, July 30, 2022 at 11:23:25 AM UTC-4, olcott wrote:
>>> On 7/29/2022 10:50 PM, Dennis Bush wrote:
>>>> On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
>>>>> On 7/29/2022 10:32 PM, Dennis Bush wrote:
>>>>>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
>>>>>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
>>>>>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
>>>>>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>>>>>>>> IT is absolutely true that any function call that creates
>>>>>>>>>>>> infinite
>>>>>>>>>>>> recursion will never return to its caller.
>>>>>>>>>>> That is great that you said this, I may stop totally ignoring
>>>>>>>>>>> every
>>>>>>>>>>> one of your posts without even glancing at them for half a
>>>>>>>>>>> second.
>>>>>>>>>>>
>>>>>>>>>>> It is also true that the correctly simulated input to H(P,P)
>>>>>>>>>>> by H
>>>>>>>>>>> would never reach its "ret" instruction(final state), thus
>>>>>>>>>>> never halt
>>>>>>>>>>> according to:
>>>>>>>>>>>
>>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>>> whenever it
>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>
>>>>>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>>>>>>>
>>>>>>>>>> Nope. You have that WRONG.
>>>>>>>>>>
>>>>>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but
>>>>>>>>>> H(P,P)
>>>>>>>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>>>>>>>
>>>>>>>>> As usual you resort to the strawman deception:
>>>>>>>>>
>>>>>>>>> *straw man*
>>>>>>>>> An intentionally misrepresented proposition that is set up
>>>>>>>>> because it is
>>>>>>>>> easier to defeat than an opponent's real argument.
>>>>>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>>>>>
>>>>>>>>> *The question is*
>>>>>>>>> Does the input to H(P,P) correctly simulated by H ever reach
>>>>>>>>> the "ret"
>>>>>>>>> instruction of P whether or not H ever aborts its simulation of P?
>>>>>>>>
>>>>>>>> Which is not the question a halt decider must answer. If H is a
>>>>>>>> halt decider, H(P,P) *must* answer if P(P) halts, not if there
>>>>>>>> exists an implementation of the function H that can simulate the
>>>>>>>> function call P(P) to a final state.
>>>>>>>>
>>>>>>>> Therefore H is not a halt decider because it is answering the
>>>>>>>> wrong question.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The lack of an honest answer to this question gets you totally
>>>>>>>>> ignored
>>>>>>>>> (yet not blocked to protect comp.c and comp.c++) all of the
>>>>>>>>> time for a
>>>>>>>>> long time.
>>>>>>>>
>>>>>>>> That you don't like the correct answer doesn't make it dishonest.
>>>>>>> I picked up that you are only trolling be a short while ago.
>>>>>>> Before this
>>>>>>> I thought it was very probable yet less than 100% certain. That you
>>>>>>> sustain the straw man deception make my assessment of your motives
>>>>>>> complete.
>>>>>>
>>>>>> That I point out that you're giving the correct answer to the
>>>>>> wrong question isn't a strawman error. It's pointing out that
>>>>>> you're not solving the problem you think you're solving.
>>>>>>
>>>>> H(P,P) does correctly determine the actual halt status of its input.
>>>>> While people dodge this point the dialogue remains dead.
>>>>
>>>> And that's the problem. H(P,P) isn't supposed to determine the halt
>>>> status of "its input". It's supposed to determine the halt status of
>>>> P(P) which it fails to do.
>>> A halt decider must compute the mapping from its inputs to an accept or
>>> reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> FALSE.  A halt decider must map the halting function.
>
> The behavior of any sequence of instructions that is not an actual input
> to H is not in the domain of the function that H computes.
>
> When you ask Bill a question he is supposed to answer the question asked
> and not some other question that is only in your head.
>

And what instruction would that be?

P has as its input the FULL contents of the memory that it is running
in, which has ALL the x86 instructins that the direct execution of P
executres.

Thus, the behavior of P(P) IS the behaivor of the input to H(P,P). The
difference is that H is INCORRECT in its assumption of what H does.

THAT H's FAULT, and YOURS as the programmer.

Remember, when we ask H about pogram P(P), you have shown that we ask it
by calling H(P,P), after all, that is what the P that YOU provided and
claim meets the specification for the "impossible program" in the proof
(It ask the decider about its own behavior with this input by passing a
representation of itself). Thus H IS being asked about P(P).

If it isn't, then FIX YOUR BUG IN P.

All you are doing is showing you don't know how to tell the truth.

On Saturday, July 30, 2022 at 12:39:39 PM UTC-4, olcott wrote:
> On 7/30/2022 10:41 AM, Dennis Bush wrote:
> > On Saturday, July 30, 2022 at 11:23:25 AM UTC-4, olcott wrote:
> >> On 7/29/2022 10:50 PM, Dennis Bush wrote:
> >>> On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
> >>>> On 7/29/2022 10:32 PM, Dennis Bush wrote:
> >>>>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
> >>>>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
> >>>>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
> >>>>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >>>>>>>>>
> >>>>>>>>> On 7/29/22 10:47 PM, olcott wrote:
> >>>>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>>>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
> >>>>>>>>>>> IT is absolutely true that any function call that creates infinite
> >>>>>>>>>>> recursion will never return to its caller.
> >>>>>>>>>> That is great that you said this, I may stop totally ignoring every
> >>>>>>>>>> one of your posts without even glancing at them for half a second.
> >>>>>>>>>>
> >>>>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
> >>>>>>>>>> would never reach its "ret" instruction(final state), thus never halt
> >>>>>>>>>> according to:
> >>>>>>>>>>
> >>>>>>>>>> *computation that halts* … the Turing machine will halt whenever it
> >>>>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>>>
> >>>>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
> >>>>>>>>>
> >>>>>>>>> Nope. You have that WRONG.
> >>>>>>>>>
> >>>>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
> >>>>>>>>> never returns the answer, so that H isn't a correct halt decider.
> >>>>>>>>>
> >>>>>>>> As usual you resort to the strawman deception:
> >>>>>>>>
> >>>>>>>> *straw man*
> >>>>>>>> An intentionally misrepresented proposition that is set up because it is
> >>>>>>>> easier to defeat than an opponent's real argument.
> >>>>>>>> https://www.lexico.com/en/definition/straw_man
> >>>>>>>>
> >>>>>>>> *The question is*
> >>>>>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
> >>>>>>>> instruction of P whether or not H ever aborts its simulation of P?
> >>>>>>>
> >>>>>>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
> >>>>>>>
> >>>>>>> Therefore H is not a halt decider because it is answering the wrong question.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> The lack of an honest answer to this question gets you totally ignored
> >>>>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
> >>>>>>>> long time.
> >>>>>>>
> >>>>>>> That you don't like the correct answer doesn't make it dishonest.
> >>>>>> I picked up that you are only trolling be a short while ago. Before this
> >>>>>> I thought it was very probable yet less than 100% certain. That you
> >>>>>> sustain the straw man deception make my assessment of your motives
> >>>>>> complete.
> >>>>>
> >>>>> That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
> >>>>>
> >>>> H(P,P) does correctly determine the actual halt status of its input.
> >>>> While people dodge this point the dialogue remains dead.
> >>>
> >>> And that's the problem. H(P,P) isn't supposed to determine the halt status of "its input". It's supposed to determine the halt status of P(P) which it fails to do.
> >> A halt decider must compute the mapping from its inputs to an accept or
> >> reject state on the basis of the actual behavior that is actually
> >> specified by these inputs.
> >
> > FALSE. A halt decider must map the halting function.
> The behavior of any sequence of instructions that is not an actual input
> to H is not in the domain of the function that H computes.

But it *is* in the domain. If a halt decider H can exist, then for *any* algorithm X and *any* input Y it is required to compute the following mapping:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt.

So yes Pa(Pa) is in the domain of Ha and is represented as Ha(Pa,Pa).

To claim otherwise is to agree that no such H can exist because it can't even be asked the required question.

On 7/30/2022 11:52 AM, Dennis Bush wrote:
> On Saturday, July 30, 2022 at 12:39:39 PM UTC-4, olcott wrote:
>> On 7/30/2022 10:41 AM, Dennis Bush wrote:
>>> On Saturday, July 30, 2022 at 11:23:25 AM UTC-4, olcott wrote:
>>>> On 7/29/2022 10:50 PM, Dennis Bush wrote:
>>>>> On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
>>>>>> On 7/29/2022 10:32 PM, Dennis Bush wrote:
>>>>>>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
>>>>>>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
>>>>>>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
>>>>>>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>>>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>>>>>>>>> IT is absolutely true that any function call that creates infinite
>>>>>>>>>>>>> recursion will never return to its caller.
>>>>>>>>>>>> That is great that you said this, I may stop totally ignoring every
>>>>>>>>>>>> one of your posts without even glancing at them for half a second.
>>>>>>>>>>>>
>>>>>>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>>>>>>>>> would never reach its "ret" instruction(final state), thus never halt
>>>>>>>>>>>> according to:
>>>>>>>>>>>>
>>>>>>>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>
>>>>>>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>>>>>>>>
>>>>>>>>>>> Nope. You have that WRONG.
>>>>>>>>>>>
>>>>>>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>>>>>>>>>> never returns the answer, so that H isn't a correct halt decider.
>>>>>>>>>>>
>>>>>>>>>> As usual you resort to the strawman deception:
>>>>>>>>>>
>>>>>>>>>> *straw man*
>>>>>>>>>> An intentionally misrepresented proposition that is set up because it is
>>>>>>>>>> easier to defeat than an opponent's real argument.
>>>>>>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>>>>>>
>>>>>>>>>> *The question is*
>>>>>>>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
>>>>>>>>>> instruction of P whether or not H ever aborts its simulation of P?
>>>>>>>>>
>>>>>>>>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
>>>>>>>>>
>>>>>>>>> Therefore H is not a halt decider because it is answering the wrong question.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The lack of an honest answer to this question gets you totally ignored
>>>>>>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
>>>>>>>>>> long time.
>>>>>>>>>
>>>>>>>>> That you don't like the correct answer doesn't make it dishonest.
>>>>>>>> I picked up that you are only trolling be a short while ago. Before this
>>>>>>>> I thought it was very probable yet less than 100% certain. That you
>>>>>>>> sustain the straw man deception make my assessment of your motives
>>>>>>>> complete.
>>>>>>>
>>>>>>> That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
>>>>>>>
>>>>>> H(P,P) does correctly determine the actual halt status of its input.
>>>>>> While people dodge this point the dialogue remains dead.
>>>>>
>>>>> And that's the problem. H(P,P) isn't supposed to determine the halt status of "its input". It's supposed to determine the halt status of P(P) which it fails to do.
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>
>>> FALSE. A halt decider must map the halting function.
>> The behavior of any sequence of instructions that is not an actual input
>> to H is not in the domain of the function that H computes.
>
> Then why do you insist that Ha(Pa,Pa) reports the behavior of Pn(Pn)?
>

You know that I never said anything like that. Your statement is a
bald-faced lie. Whenever you change the subject away from H(P,P) I call
you out for the strawman deception.

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

>>
>> When you ask Bill a question he is supposed to answer the question asked
>> and not some other question that is only in your head.
>
> Correct. We asked Bill if Pa(Pa) halts, not if "the input" to Ha(Pa,Pa) halts.

We ask H(P,P) does its input specify a non-halting sequence of
instructions? We do not ask H does some other unspecified sequence of
instructions halt?

Anything that is not an input to H is not in the domain of the function
that H computes. H *is not* a mind reader.

Everyone simply assumes that the correct x86 emulation of the input to
H(P,P) must have the same behavior as the direct execution of P(P) even
though the provably correct execution traces** of each prove otherwise.
This is a break form reality.

** The line-by-line execution trace of the input to H(P,P) that H
simulates exactly matches the line-by-line x86 source-code of P.

The line-by-line execution trace of P(P) exactly matches the
line-by-line x86 source-code of P.

They are not the same sequence of instructions and have different
behavior on this basis.

--
Copyright 2022 Pete Olcott

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

On Saturday, July 30, 2022 at 1:07:51 PM UTC-4, olcott wrote:
> On 7/30/2022 11:52 AM, Dennis Bush wrote:
> > On Saturday, July 30, 2022 at 12:39:39 PM UTC-4, olcott wrote:
> >> On 7/30/2022 10:41 AM, Dennis Bush wrote:
> >>> On Saturday, July 30, 2022 at 11:23:25 AM UTC-4, olcott wrote:
> >>>> On 7/29/2022 10:50 PM, Dennis Bush wrote:
> >>>>> On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
> >>>>>> On 7/29/2022 10:32 PM, Dennis Bush wrote:
> >>>>>>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
> >>>>>>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
> >>>>>>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 7/29/22 10:47 PM, olcott wrote:
> >>>>>>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>>>>>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
> >>>>>>>>>>>>> IT is absolutely true that any function call that creates infinite
> >>>>>>>>>>>>> recursion will never return to its caller.
> >>>>>>>>>>>> That is great that you said this, I may stop totally ignoring every
> >>>>>>>>>>>> one of your posts without even glancing at them for half a second.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
> >>>>>>>>>>>> would never reach its "ret" instruction(final state), thus never halt
> >>>>>>>>>>>> according to:
> >>>>>>>>>>>>
> >>>>>>>>>>>> *computation that halts* … the Turing machine will halt whenever it
> >>>>>>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>>>>>
> >>>>>>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
> >>>>>>>>>>>
> >>>>>>>>>>> Nope. You have that WRONG.
> >>>>>>>>>>>
> >>>>>>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
> >>>>>>>>>>> never returns the answer, so that H isn't a correct halt decider.
> >>>>>>>>>>>
> >>>>>>>>>> As usual you resort to the strawman deception:
> >>>>>>>>>>
> >>>>>>>>>> *straw man*
> >>>>>>>>>> An intentionally misrepresented proposition that is set up because it is
> >>>>>>>>>> easier to defeat than an opponent's real argument.
> >>>>>>>>>> https://www.lexico.com/en/definition/straw_man
> >>>>>>>>>>
> >>>>>>>>>> *The question is*
> >>>>>>>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
> >>>>>>>>>> instruction of P whether or not H ever aborts its simulation of P?
> >>>>>>>>>
> >>>>>>>>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
> >>>>>>>>>
> >>>>>>>>> Therefore H is not a halt decider because it is answering the wrong question.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The lack of an honest answer to this question gets you totally ignored
> >>>>>>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
> >>>>>>>>>> long time.
> >>>>>>>>>
> >>>>>>>>> That you don't like the correct answer doesn't make it dishonest.
> >>>>>>>> I picked up that you are only trolling be a short while ago. Before this
> >>>>>>>> I thought it was very probable yet less than 100% certain. That you
> >>>>>>>> sustain the straw man deception make my assessment of your motives
> >>>>>>>> complete.
> >>>>>>>
> >>>>>>> That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
> >>>>>>>
> >>>>>> H(P,P) does correctly determine the actual halt status of its input.
> >>>>>> While people dodge this point the dialogue remains dead.
> >>>>>
> >>>>> And that's the problem. H(P,P) isn't supposed to determine the halt status of "its input". It's supposed to determine the halt status of P(P) which it fails to do.
> >>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>> reject state on the basis of the actual behavior that is actually
> >>>> specified by these inputs.
> >>>
> >>> FALSE. A halt decider must map the halting function.
> >> The behavior of any sequence of instructions that is not an actual input
> >> to H is not in the domain of the function that H computes.
> >
> > Then why do you insist that Ha(Pa,Pa) reports the behavior of Pn(Pn)?
> >
> You know that I never said anything like that. Your statement is a
> bald-faced lie. Whenever you change the subject away from H(P,P) I call
> you out for the strawman deception.

Actually, that's exactly what you've been saying this whole time. You just don't realize it.

You use "H" to sometimes refer to Ha and sometimes use it to refer to Hn, and similarly with P/Pa/Pn.

Pn(Pn) has infinite simulation. Ha was built to recognize this and correctly computes Ha(Pn,Pn)==0. Pa(Pa) does not have infinite simulation, but Ha(Pa,Pa) thinks that it was given Pn(Pn) which does.

> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
>
> >>
> >> When you ask Bill a question he is supposed to answer the question asked
> >> and not some other question that is only in your head.
> >
> > Correct. We asked Bill if Pa(Pa) halts, not if "the input" to Ha(Pa,Pa) halts.
> We ask H(P,P) does its input specify a non-halting sequence of
> instructions? We do not ask H does some other unspecified sequence of
> instructions halt?

No, we're asking if P(P) halts.

>
> Anything that is not an input to H is not in the domain of the function
> that H computes. H *is not* a mind reader.

Then you admit that H is not a halt decider because it does not have the same domain as a halt decider, which is *any* algorithm given *any* input.

>
> Everyone simply assumes that the correct x86 emulation of the input to
> H(P,P) must have the same behavior as the direct execution of P(P)
>even

No one assumes that. By the definition of what a halt decider is required to do:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt.

It is *stipulated* to be the same.

> though the provably correct execution traces** of each prove otherwise.
> This is a break form reality.

Correct but not complete, and both correct and complete is what matters.

>
> ** The line-by-line execution trace of the input to H(P,P) that H
> simulates exactly matches the line-by-line x86 source-code of P.

And the line-by-line execution trace of the input to Ha3(N,5) that Ha3 simulates exactly matches the line-by-line x86 source-code of N. So according to you Ha3(N,5) does a correct simulation of its input.

>
> The line-by-line execution trace of P(P) exactly matches the
> line-by-line x86 source-code of P.

And the line-by-line execution trace of N(5) exactly matches the line-by-line x86 source-code of N.

>
> They are not the same sequence of instructions and have different
> behavior on this basis.

On 7/30/22 12:52 PM, olcott wrote:
> On 7/30/2022 10:56 AM, Richard Damon wrote:
>>
>> On 7/30/22 11:30 AM, olcott wrote:
>>> On 7/30/2022 6:17 AM, Richard Damon wrote:
>>>>
>>>> On 7/29/22 11:12 PM, olcott wrote:
>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/29/22 10:47 PM, olcott wrote:
>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>>>>> IT is absolutely true that any function call that creates
>>>>>>>> infinite recursion will never return to its caller.
>>>>>>> That is great that you said this, I may stop totally ignoring
>>>>>>> every one of your posts without even glancing at them for half a
>>>>>>> second.
>>>>>>>
>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>>>>> would never reach its "ret" instruction(final state), thus never
>>>>>>> halt according to:
>>>>>>>
>>>>>>> *computation that halts* … the Turing machine will halt whenever
>>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>>
>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>>>>
>>>>>> Nope. You have that WRONG.
>>>>>>
>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but
>>>>>> H(P,P) never returns the answer, so that H isn't a correct halt
>>>>>> decider.
>>>>>>
>>>>>
>>>>> As usual you resort to the strawman deception:
>>>>>
>>>>> *straw man*
>>>>> An intentionally misrepresented proposition that is set up because
>>>>> it is easier to defeat than an opponent's real argument.
>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>
>>>>> *The question is*
>>>>> Does the input to H(P,P) correctly simulated by H ever reach the
>>>>> "ret" instruction of P whether or not H ever aborts its simulation
>>>>> of P?
>>>>>
>>>>
>>>> No, that isn't the question
>>>
>>> *Until you answer that question you will be ignored*
>>> Make sure you put [question answered] in the subject line because I
>>> won't even glance at any of your other replies until then.
>>>
>>> I will only tolerate an honest dialogue which requires that points of
>>> mutual agreement be reached. Without points of mutual agreement the
>>> dialogue is not an honest dialogue and I will not tolerate this
>>> dishonestly.
>>>
>>>
>>
>> So, you admit that you don't actually care about Halting, but only
>> your POOP problem?
>>
>> That is the direct consequence of your statement.
>>
>>
>> And, as I have said many times before:
>>
>> Yes, you can show that NO verison of H can correctly simulate this
>> input to the "return" instruction, but that doesn't mean H is correct
>> to return non-halting. But it doesn't prove what you claim.
> You always phrase this as if the x86 emulation of the input to H(P,P) by
> H is somehow incorrect, yet we can verify that the line-by-line
> execution trace of the simulated input to H(P,P) exactly matches the
> line-by-line behavior specified by the x86 source-code of P.

It is INCOMPLETE, and thus doesn't show the ultimate behavior of the
PROGRAM that it represents.

You are just showing your decitefulness of whating to use the word
correct in two different meanings. Normally, a "Correct Simulation" of
something implies that the simulation is also COMPLETE, or at least
complete enough to actually show the properties in question. You keep on
trying to insist on the technical meaning of haven't made a mistake in
the part that was done, but not requiring the job to be finished. That
is ok, but on HONEST person wouldn't object to people adding the PARTIAL
modifier to it.

>
> This means that it is untruthful to say that H(P,P) cannot simulate its
> input until this input reaches the "ret" instruction of P as if this
> simulation was incorrect.

No, where did I says that? That is your problem. You need to put words
in other peoples mouths becuase you don't have correct words to put in
yours. H can never simulate its input till it reachs the Halt
instruction, because any H that tries fails to answer, so you have
programmed your H to stop short. Your problem is you then try to make it
sound like that means the actual program is non-halting, when you havn't
actually shown that.

My disagreement isn't that H can't get to the ret instruction, but that
you want to characterize that as CORRECT behavior, when it isn't.

>
> The truthful way of saying this is that the correct simulation of the
> input to H(P,P) never reaches its "ret" instruction because this input
> specifies infinitely recursive simulation to H.

Nope, that is NOT the reason it doesn't reach that results for the class
Ha. That class fails to reach the return instruction because H stops
before it reached the end, and because is stop and returns 0, then the
actual program P(P) will have finite behavior and stop, and thus there
is NO actual "infinite recursion" for H to try to blame.

Your problem is you use wrong rules to try to detect this infinite
recursion. Wrong Rules give wrong answers (at least at times).

>
> Because a simulating halt decider must always abort its simulation of
> every input that would otherwise keep running the fact that H aborts its
> simulation does not negate the fact that the input specified a
> non-halting behavior pattern to H.

Right, but the input wouldn't keep on going if properly simulated by a
proper simulator.

You forget that to ask H about this input, you have fixed your design to
a SPECIFIEC H. If this H answers 0 for H(P,P), then it is an established
fact that this H DOES abort its simulation, and thus an actual correct
simulation of THIS input (not the other input built on a different H) by
a correct and complete simulator (which H isn't)

>
> The correct x86 emulation of the input to H(P,P) by H never reaches the
> final state of P (The "ret" instruction of P) whether or not H ever
> aborts its simulation, therefore because

The correct AND PARTIAL x86 emulation of the input to H(P,P) by H never
reaches the final state of P.

The correct and COMPLETE x86 emulation of the exact same input by a UTM
equivalent simulator WILL reach the final state of P if H(P,P) aborts
its simulation and returns 0.

>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)

Right, and the Turing Machine is the direct execution of P(P) which
Halts if H(P,P) returns 0.
>
> H correctly rejects its input as non-halting.
>

Nope.

PROVED WRONG.

You are just proving yourself to be a liar, or and idiot.

Per the definition you quote, the test of Halting the the Turing
Machine, that is the ACTUAL PROGRAM, not the simulation of the machine
by the decider.

P(P) Halts {if H(P,P) returns 0}, so H(P,P) can't be the correct answer.

That is just saying you black cat is correctly determined to be your
white dog.

You just don't seem to understand those words. Kind of a bad place for
someone who likes to claim things by the meaning of the words to be
shown that they don't actually know the meaning of those words.

On Saturday, 30 July 2022 at 18:39:39 UTC+2, olcott wrote:
> On 7/30/2022 10:41 AM, Dennis Bush wrote:
> > On Saturday, July 30, 2022 at 11:23:25 AM UTC-4, olcott wrote:
> >> On 7/29/2022 10:50 PM, Dennis Bush wrote:
> >>> On Friday, July 29, 2022 at 11:47:53 PM UTC-4, olcott wrote:
> >>>> On 7/29/2022 10:32 PM, Dennis Bush wrote:
> >>>>> On Friday, July 29, 2022 at 11:27:34 PM UTC-4, olcott wrote:
> >>>>>> On 7/29/2022 10:18 PM, Dennis Bush wrote:
> >>>>>>> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
> >>>>>>>> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >>>>>>>>>
> >>>>>>>>> On 7/29/22 10:47 PM, olcott wrote:
> >>>>>>>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>>>>>>>>>> On 7/29/22 10:11 PM, olcott wrote:
> >>>>>>>>>>> IT is absolutely true that any function call that creates infinite
> >>>>>>>>>>> recursion will never return to its caller.
> >>>>>>>>>> That is great that you said this, I may stop totally ignoring every
> >>>>>>>>>> one of your posts without even glancing at them for half a second.
> >>>>>>>>>>
> >>>>>>>>>> It is also true that the correctly simulated input to H(P,P) by H
> >>>>>>>>>> would never reach its "ret" instruction(final state), thus never halt
> >>>>>>>>>> according to:
> >>>>>>>>>>
> >>>>>>>>>> *computation that halts* … the Turing machine will halt whenever it
> >>>>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>>>
> >>>>>>>>>> whether or not H(P,P) ever aborts the simulation of its input.
> >>>>>>>>>
> >>>>>>>>> Nope. You have that WRONG.
> >>>>>>>>>
> >>>>>>>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
> >>>>>>>>> never returns the answer, so that H isn't a correct halt decider.
> >>>>>>>>>
> >>>>>>>> As usual you resort to the strawman deception:
> >>>>>>>>
> >>>>>>>> *straw man*
> >>>>>>>> An intentionally misrepresented proposition that is set up because it is
> >>>>>>>> easier to defeat than an opponent's real argument.
> >>>>>>>> https://www.lexico.com/en/definition/straw_man
> >>>>>>>>
> >>>>>>>> *The question is*
> >>>>>>>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
> >>>>>>>> instruction of P whether or not H ever aborts its simulation of P?
> >>>>>>>
> >>>>>>> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
> >>>>>>>
> >>>>>>> Therefore H is not a halt decider because it is answering the wrong question.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> The lack of an honest answer to this question gets you totally ignored
> >>>>>>>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
> >>>>>>>> long time.
> >>>>>>>
> >>>>>>> That you don't like the correct answer doesn't make it dishonest.
> >>>>>> I picked up that you are only trolling be a short while ago. Before this
> >>>>>> I thought it was very probable yet less than 100% certain. That you
> >>>>>> sustain the straw man deception make my assessment of your motives
> >>>>>> complete.
> >>>>>
> >>>>> That I point out that you're giving the correct answer to the wrong question isn't a strawman error. It's pointing out that you're not solving the problem you think you're solving.
> >>>>>
> >>>> H(P,P) does correctly determine the actual halt status of its input.
> >>>> While people dodge this point the dialogue remains dead.
> >>>
> >>> And that's the problem. H(P,P) isn't supposed to determine the halt status of "its input". It's supposed to determine the halt status of P(P) which it fails to do.
> >> A halt decider must compute the mapping from its inputs to an accept or
> >> reject state on the basis of the actual behavior that is actually
> >> specified by these inputs.
> >
> > FALSE. A halt decider must map the halting function.
> The behavior of any sequence of instructions that is not an actual input
> to H is not in the domain of the function that H computes.
>
> When you ask Bill a question he is supposed to answer the question asked
> and not some other question that is only in your head.

The domain of H is ALL functions.

H is supposed to be a generic. It's supposed to answer "Does it halt?" for ALL functions.
You know what generics are, right?

https://en.wikipedia.org/wiki/Generic_function