olcott <NoOne@NoWhere.com> writes:

> On 4/12/2022 7:49 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>
>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>
>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>>> own state.
>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>
>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>>> its own final state.
>>>>>>>>
>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>
>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>>> say and I'll stop quoting it.
>>>>>
>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>> like it must be identical to the correct simulation of the input to
>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>
>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>>> false?
>>>
>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>> reach the final state of this input then we know that it never halts
>>> even if everyone in the universe disagrees.
>>
>> So you plan to keep posting the same sentence in an attempt to take
>> the focus off the fact that H is obviously wrong?
>
> Then you must mean

WHOOP! WHOOP! WHOOP! Danger Will Robinson.

You should avoid trying to paraphrase other people. Your replies
suggest you don't often understand the various points being put to you,
so when you try to re-word them the results are usually bogus.

> that a correctly simulated input that would never reaches its own
> final state is still a computation that halts.

I meant what I said. If you are not sure that I meant, asking
well-chosen questions about it is the way to go.

--
Ben.

On 4/12/2022 9:02 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/12/2022 7:49 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>
>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>>>> own state.
>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>
>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>>>> its own final state.
>>>>>>>>>
>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>
>>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>>>> say and I'll stop quoting it.
>>>>>>
>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>> like it must be identical to the correct simulation of the input to
>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>
>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>>>> false?
>>>>
>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>> reach the final state of this input then we know that it never halts
>>>> even if everyone in the universe disagrees.
>>>
>>> So you plan to keep posting the same sentence in an attempt to take
>>> the focus off the fact that H is obviously wrong?
>>
>> Then you must mean
>
> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>
> You should avoid trying to paraphrase other people. Your replies
> suggest you don't often understand the various points being put to you,
> so when you try to re-word them the results are usually bogus.
>
>> that a correctly simulated input that would never reaches its own
>> final state is still a computation that halts.
>
> I meant what I said. If you are not sure that I meant, asking
> well-chosen questions about it is the way to go.
>

We know [by definition] that a correctly simulated input that would
never reach its own final state is not a halting computation.

Are you saying that the definition of halting is incorrect?

Are you saying that the correctly simulated input to H(P,P) does reach
its own final state?

--
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 4/12/2022 9:05 PM, olcott wrote:
> On 4/12/2022 9:02 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>
>>>>>>>>>>>>>> The truth is not determined by who does or does not agree
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> something.  But to find the truth of the matter you must
>>>>>>>>>>>>>> first stop
>>>>>>>>>>>>>> talking literal nonsense.  The arguments to H (what you
>>>>>>>>>>>>>> call the
>>>>>>>>>>>>>> "input") are two pointers.  What does simulating two
>>>>>>>>>>>>>> pointers mean?
>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first
>>>>>>>>>>>>>> pointer with the
>>>>>>>>>>>>>> second as it's argument.  That simulation, according to
>>>>>>>>>>>>>> you, will halt
>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey,
>>>>>>>>>>>>>> language).
>>>>>>>>>>>>>> It will halt because the direct call P(P) halts.
>>>>>>>>>>>>>> Everything here halts
>>>>>>>>>>>>>> (according to you).  That's why H is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You simply are ignoring the actual execution trace that
>>>>>>>>>>>>> conclusively
>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach
>>>>>>>>>>>>> its final
>>>>>>>>>>>>> own state.
>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made
>>>>>>>>>>>> the mistake
>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you
>>>>>>>>>>>> posted that
>>>>>>>>>>>> as well).  You a free to retract any of these at any time,
>>>>>>>>>>>> but until you
>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>
>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever
>>>>>>>>>>> reaches
>>>>>>>>>>> its own final state.
>>>>>>>>>>
>>>>>>>>>> Waffle.  HP(P) halts so (P,P) == false is wrong.  You can retract
>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>> these facts (since they come from you in the first place).  Until
>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>
>>>>>>>>> It is the case that the simulated input never reaches its
>>>>>>>>> [00000970]
>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>> You can verify a thousand more irrelevant facts.  The facts that
>>>>>>>> matter
>>>>>>>> are already known: that P(P) halts and that H(P,P) == false.
>>>>>>>> Are you
>>>>>>>> presenting any verified facts that corrects this mistake?  If
>>>>>>>> so, just
>>>>>>>> say and I'll stop quoting it.
>>>>>>>
>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>> H(P,P).  It turns out that intuition is incorrect.
>>>>>>
>>>>>> So which fact are you retracting?  That P(P) halts or that H(P,P) ==
>>>>>> false?
>>>>>
>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>> reach the final state of this input then we know that it never halts
>>>>> even if everyone in the universe disagrees.
>>>>
>>>> So you plan to keep posting the same sentence in an attempt to take
>>>> the focus off the fact that H is obviously wrong?
>>>
>>> Then you must mean
>>
>> WHOOP!  WHOOP!  WHOOP!  Danger Will Robinson.
>>
>> You should avoid trying to paraphrase other people.  Your replies
>> suggest you don't often understand the various points being put to you,
>> so when you try to re-word them the results are usually bogus.
>>
>>> that a correctly simulated input that would never reaches its own
>>> final state is still a computation that halts.
>>
>> I meant what I said.  If you are not sure that I meant, asking
>> well-chosen questions about it is the way to go.
>>
>
> We know [by definition] that a correctly simulated input that would
> never reach its own final state is not a halting computation.
>
> Are you saying that the definition of halting is incorrect?
>
> Are you saying that the correctly simulated input to H(P,P) does reach
> its own final state?

If X & Y logically entails Z and we have X and Y then Z is entailed.

--
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 Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
> On 4/12/2022 9:02 PM, Ben wrote:
> > olcott <No...@NoWhere.com> writes:
> >
> >> On 4/12/2022 7:49 PM, Ben wrote:
> >>> olcott <No...@NoWhere.com> writes:
> >>>
> >>>> On 4/12/2022 8:06 AM, Ben wrote:
> >>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>> On 4/11/2022 8:02 PM, Ben wrote:
> >>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>
> >>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
> >>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>
> >>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
> >>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
> >>>>>>>
> >>>>>>>>>>>>> The truth is not determined by who does or does not agree with
> >>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
> >>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
> >>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
> >>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
> >>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
> >>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
> >>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
> >>>>>>>>>>>>> (according to you). That's why H is wrong.
> >>>>>>>>>>>>
> >>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
> >>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
> >>>>>>>>>>>> own state.
> >>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
> >>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
> >>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
> >>>>>>>>>>> do, your H is wrong by your own supplied traces.
> >>>>>>>>>>
> >>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
> >>>>>>>>>> its own final state.
> >>>>>>>>>
> >>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
> >>>>>>> typo: "so H(P,P) == false is wrong"
> >>>>>>>>> these facts (since they come from you in the first place). Until
> >>>>>>>>> then, you've told us that your H is wrong.
> >>>>>>>>
> >>>>>>>> It is the case that the simulated input never reaches its [00000970]
> >>>>>>>> machine address, no waffle there merely an easily verified fact.
> >>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
> >>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
> >>>>>>> presenting any verified facts that corrects this mistake? If so, just
> >>>>>>> say and I'll stop quoting it.
> >>>>>>
> >>>>>> The sequence of configurations specified by P(P) intuitively seems
> >>>>>> like it must be identical to the correct simulation of the input to
> >>>>>> H(P,P). It turns out that intuition is incorrect.
> >>>>>
> >>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
> >>>>> false?
> >>>>
> >>>> As long as the correctly simulated input to H(P,P) cannot possibly
> >>>> reach the final state of this input then we know that it never halts
> >>>> even if everyone in the universe disagrees.
> >>>
> >>> So you plan to keep posting the same sentence in an attempt to take
> >>> the focus off the fact that H is obviously wrong?
> >>
> >> Then you must mean
> >
> > WHOOP! WHOOP! WHOOP! Danger Will Robinson.
> >
> > You should avoid trying to paraphrase other people. Your replies
> > suggest you don't often understand the various points being put to you,
> > so when you try to re-word them the results are usually bogus.
> >
> >> that a correctly simulated input that would never reaches its own
> >> final state is still a computation that halts.
> >
> > I meant what I said. If you are not sure that I meant, asking
> > well-chosen questions about it is the way to go.
> >
> We know [by definition] that a correctly simulated input that would
> never reach its own final state is not a halting computation.
>
> Are you saying that the definition of halting is incorrect?
>
> Are you saying that the correctly simulated input to H(P,P) does reach
> its own final state?

As a matter of fact it does.

Given that H will abort and report non-halting, if we create another function Hb which has the same halting criteria as H but defers aborting for k additional steps, we see that Hb(P,P) remains in UTM mode and simulates the input P,P to a final state and reports halting.

So the correctly simulated input to H(P,P) i.e. (P,P) does halt. Therefore H does not perform a correct simulation of (P,P) because it aborts too soon.

olcott <NoOne@NoWhere.com> writes:

> On 4/12/2022 9:02 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>
>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>>>>> own state.
>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>
>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>>>>> its own final state.
>>>>>>>>>>
>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>
>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>>>>> say and I'll stop quoting it.
>>>>>>>
>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>>
>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>>>>> false?
>>>>>
>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>> reach the final state of this input then we know that it never halts
>>>>> even if everyone in the universe disagrees.
>>>>
>>>> So you plan to keep posting the same sentence in an attempt to take
>>>> the focus off the fact that H is obviously wrong?
>>>
>>> Then you must mean
>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>> You should avoid trying to paraphrase other people. Your replies
>> suggest you don't often understand the various points being put to you,
>> so when you try to re-word them the results are usually bogus.
>>
>>> that a correctly simulated input that would never reaches its own
>>> final state is still a computation that halts.
>>
>> I meant what I said. If you are not sure that I meant, asking
>> well-chosen questions about it is the way to go.
>
> We know [by definition] that a correctly simulated input that would
> never reach its own final state is not a halting computation.

Deception alert: "would" rather than "does". Also, delete "correctly".
You only need an adverb in the exceptional case: "incorrectly
simulated", "partially simulated". Also the "input" to H are it's
parameters. The parameters are both C pointers. What does it mean to
simulate two pointers? And "final state" is a term from Turing machines
but H and P are C functions.

I'd re-word it in a sane way, but you'd reject my re-wording (I know
because I did in a few years ago). This is all old hat.

> Are you saying that the definition of halting is incorrect?

No. You don't know what it is, but it's not incorrect. You could try
to say what it is, but I doubt you can without the long list of category
errors above.

> Are you saying that the correctly simulated input to H(P,P) does reach
> its own final state?

Simulating P(P) and calling P(P) have the same halting status. They
both halt or neither halts.

--
Ben.

On 4/12/22 9:58 PM, olcott wrote:
> On 4/12/2022 8:55 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 7:47 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/12/2022 8:09 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>>>>> I am only talking about H(P,P) now because if someone imagines
>>>>>>> that it
>>>>>>> does differently that it does an actual execution trace proves that
>>>>>>> they are incorrect as a matter of objective fact with zero room for
>>>>>>> debate.
>>>>>>
>>>>>> That's good because you have been 100% clear about H.  It's wrong
>>>>>> because P(P) halts (according to you) and H(P,P) == false
>>>>>> (according to
>>>>>> you).
>>>>>
>>>>> Why do you insist that a halt decider must compute the mapping from
>>>>> non-inputs: P(P) when you know that it only computes the mapping from
>>>>> inputs H(P,P) ?
>>>>
>>>> I don't.  H takes arguments (what you insist on calling inputs) and
>>>> maps
>>>> them to a result.  The correct result is defined by people who know
>>>> what
>>>> the halting problem is -- you don't get to decide.  You may never
>>>> understand the specification, but you only need to know one fact about
>>>> it: mapping the "inputs" P and P to false is wrong.
>>>
>>> So in other words you are saying that mere opinions carry more weight
>>> than the following verified fact:
>>
>> The facts that (a) H(P,P) == false and (b) P(P) halts are not in dispute
>> (so far as I know).  That H mapping P and P to false is wrong is a
>> matter of definition.  There are no opinions being expressed here at
>> all.
>>
>
> So you agree that an input that never halts is a halting computation.
>

He didn't say that, and you know it, so your statement is just a LIE.

Which part of his statement do you disagree with?

(a) That H(P,P) actually returns false
(b) That P(P), when actually run, Halts
(c) That the DEFINITION of H (as a Halt Deciding Turing Machine) is that
H(<M>, w) is suppose to return Halting if M(w) Halts, and non-halting if
M(w) never halts.

I am pretty sure you disagree with (c), but that IS the definition, so
that means you YOU are wrong to disagree with it, as DEFINITIONS are
DEFINITIONS, and not subject to being changed just because you don't
like them.

On 4/12/22 10:05 PM, olcott wrote:
> On 4/12/2022 9:02 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>
>>>>>>>>>>>>>> The truth is not determined by who does or does not agree
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> something.  But to find the truth of the matter you must
>>>>>>>>>>>>>> first stop
>>>>>>>>>>>>>> talking literal nonsense.  The arguments to H (what you
>>>>>>>>>>>>>> call the
>>>>>>>>>>>>>> "input") are two pointers.  What does simulating two
>>>>>>>>>>>>>> pointers mean?
>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first
>>>>>>>>>>>>>> pointer with the
>>>>>>>>>>>>>> second as it's argument.  That simulation, according to
>>>>>>>>>>>>>> you, will halt
>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey,
>>>>>>>>>>>>>> language).
>>>>>>>>>>>>>> It will halt because the direct call P(P) halts.
>>>>>>>>>>>>>> Everything here halts
>>>>>>>>>>>>>> (according to you).  That's why H is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You simply are ignoring the actual execution trace that
>>>>>>>>>>>>> conclusively
>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach
>>>>>>>>>>>>> its final
>>>>>>>>>>>>> own state.
>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made
>>>>>>>>>>>> the mistake
>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you
>>>>>>>>>>>> posted that
>>>>>>>>>>>> as well).  You a free to retract any of these at any time,
>>>>>>>>>>>> but until you
>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>
>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever
>>>>>>>>>>> reaches
>>>>>>>>>>> its own final state.
>>>>>>>>>>
>>>>>>>>>> Waffle.  HP(P) halts so (P,P) == false is wrong.  You can retract
>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>> these facts (since they come from you in the first place).  Until
>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>
>>>>>>>>> It is the case that the simulated input never reaches its
>>>>>>>>> [00000970]
>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>> You can verify a thousand more irrelevant facts.  The facts that
>>>>>>>> matter
>>>>>>>> are already known: that P(P) halts and that H(P,P) == false.
>>>>>>>> Are you
>>>>>>>> presenting any verified facts that corrects this mistake?  If
>>>>>>>> so, just
>>>>>>>> say and I'll stop quoting it.
>>>>>>>
>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>> H(P,P).  It turns out that intuition is incorrect.
>>>>>>
>>>>>> So which fact are you retracting?  That P(P) halts or that H(P,P) ==
>>>>>> false?
>>>>>
>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>> reach the final state of this input then we know that it never halts
>>>>> even if everyone in the universe disagrees.
>>>>
>>>> So you plan to keep posting the same sentence in an attempt to take
>>>> the focus off the fact that H is obviously wrong?
>>>
>>> Then you must mean
>>
>> WHOOP!  WHOOP!  WHOOP!  Danger Will Robinson.
>>
>> You should avoid trying to paraphrase other people.  Your replies
>> suggest you don't often understand the various points being put to you,
>> so when you try to re-word them the results are usually bogus.
>>
>>> that a correctly simulated input that would never reaches its own
>>> final state is still a computation that halts.
>>
>> I meant what I said.  If you are not sure that I meant, asking
>> well-chosen questions about it is the way to go.
>>
>
> We know [by definition] that a correctly simulated input that would
> never reach its own final state is not a halting computation.

But we don't HAVE a correctly simulated input that would never reach its
own final state that is actually indicated as such by the halt decider
in question.
>
> Are you saying that the definition of halting is incorrect?
>
> Are you saying that the correctly simulated input to H(P,P) does reach
> its own final state?
>

YES. AS YOU HAVE PROVEN. (assuming that H(P,P) == false)

On 4/12/22 10:08 PM, olcott wrote:
> On 4/12/2022 9:05 PM, olcott wrote:
>> On 4/12/2022 9:02 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>
>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> something.  But to find the truth of the matter you must
>>>>>>>>>>>>>>> first stop
>>>>>>>>>>>>>>> talking literal nonsense.  The arguments to H (what you
>>>>>>>>>>>>>>> call the
>>>>>>>>>>>>>>> "input") are two pointers.  What does simulating two
>>>>>>>>>>>>>>> pointers mean?
>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first
>>>>>>>>>>>>>>> pointer with the
>>>>>>>>>>>>>>> second as it's argument.  That simulation, according to
>>>>>>>>>>>>>>> you, will halt
>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant,
>>>>>>>>>>>>>>> sciencey, language).
>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts.
>>>>>>>>>>>>>>> Everything here halts
>>>>>>>>>>>>>>> (according to you).  That's why H is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that
>>>>>>>>>>>>>> conclusively
>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach
>>>>>>>>>>>>>> its final
>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you
>>>>>>>>>>>>> made the mistake
>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false
>>>>>>>>>>>>> (you posted that
>>>>>>>>>>>>> as well).  You a free to retract any of these at any time,
>>>>>>>>>>>>> but until you
>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>
>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever
>>>>>>>>>>>> reaches
>>>>>>>>>>>> its own final state.
>>>>>>>>>>>
>>>>>>>>>>> Waffle.  HP(P) halts so (P,P) == false is wrong.  You can
>>>>>>>>>>> retract
>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>> these facts (since they come from you in the first place).
>>>>>>>>>>> Until
>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>
>>>>>>>>>> It is the case that the simulated input never reaches its
>>>>>>>>>> [00000970]
>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>>> You can verify a thousand more irrelevant facts.  The facts
>>>>>>>>> that matter
>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false.
>>>>>>>>> Are you
>>>>>>>>> presenting any verified facts that corrects this mistake?  If
>>>>>>>>> so, just
>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>
>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>>> H(P,P).  It turns out that intuition is incorrect.
>>>>>>>
>>>>>>> So which fact are you retracting?  That P(P) halts or that H(P,P) ==
>>>>>>> false?
>>>>>>
>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>>> reach the final state of this input then we know that it never halts
>>>>>> even if everyone in the universe disagrees.
>>>>>
>>>>> So you plan to keep posting the same sentence in an attempt to take
>>>>> the focus off the fact that H is obviously wrong?
>>>>
>>>> Then you must mean
>>>
>>> WHOOP!  WHOOP!  WHOOP!  Danger Will Robinson.
>>>
>>> You should avoid trying to paraphrase other people.  Your replies
>>> suggest you don't often understand the various points being put to you,
>>> so when you try to re-word them the results are usually bogus.
>>>
>>>> that a correctly simulated input that would never reaches its own
>>>> final state is still a computation that halts.
>>>
>>> I meant what I said.  If you are not sure that I meant, asking
>>> well-chosen questions about it is the way to go.
>>>
>>
>> We know [by definition] that a correctly simulated input that would
>> never reach its own final state is not a halting computation.
>>
>> Are you saying that the definition of halting is incorrect?
>>
>> Are you saying that the correctly simulated input to H(P,P) does reach
>> its own final state?
>
> If X & Y logically entails Z and we have X and Y then Z is entailed.
>
>

Except that you don't have X & Y.

olcott <NoOne@NoWhere.com> writes:

> On 4/12/2022 8:55 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 7:47 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/12/2022 8:09 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>>>>> I am only talking about H(P,P) now because if someone imagines that it
>>>>>>> does differently that it does an actual execution trace proves that
>>>>>>> they are incorrect as a matter of objective fact with zero room for
>>>>>>> debate.
>>>>>>
>>>>>> That's good because you have been 100% clear about H. It's wrong
>>>>>> because P(P) halts (according to you) and H(P,P) == false (according to
>>>>>> you).
>>>>>
>>>>> Why do you insist that a halt decider must compute the mapping from
>>>>> non-inputs: P(P) when you know that it only computes the mapping from
>>>>> inputs H(P,P) ?
>>>>
>>>> I don't. H takes arguments (what you insist on calling inputs) and maps
>>>> them to a result. The correct result is defined by people who know what
>>>> the halting problem is -- you don't get to decide. You may never
>>>> understand the specification, but you only need to know one fact about
>>>> it: mapping the "inputs" P and P to false is wrong.
>>>
>>> So in other words you are saying that mere opinions carry more weight
>>> than the following verified fact:
>>
>> The facts that (a) H(P,P) == false and (b) P(P) halts are not in dispute
>> (so far as I know). That H mapping P and P to false is wrong is a
>> matter of definition. There are no opinions being expressed here at
>> all.
>
> So you agree that an input that never halts is a halting computation.

Don't be silly. As the culmination of 17 years of work, this looks
pathetic. Either retract one of your previously asserted facts (that
P(P) halts or that H(P,P) == false) or say that your H is not deciding
halting, but something else.

--
Ben.

On 4/12/2022 9:29 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/12/2022 9:02 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>
>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>
>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>>>>>> its own final state.
>>>>>>>>>>>
>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>
>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>
>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>>>
>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>>>>>> false?
>>>>>>
>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>>> reach the final state of this input then we know that it never halts
>>>>>> even if everyone in the universe disagrees.
>>>>>
>>>>> So you plan to keep posting the same sentence in an attempt to take
>>>>> the focus off the fact that H is obviously wrong?
>>>>
>>>> Then you must mean
>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>>> You should avoid trying to paraphrase other people. Your replies
>>> suggest you don't often understand the various points being put to you,
>>> so when you try to re-word them the results are usually bogus.
>>>
>>>> that a correctly simulated input that would never reaches its own
>>>> final state is still a computation that halts.
>>>
>>> I meant what I said. If you are not sure that I meant, asking
>>> well-chosen questions about it is the way to go.
>>
>> We know [by definition] that a correctly simulated input that would
>> never reach its own final state is not a halting computation.
>
> Deception alert: "would" rather than "does".

A simulating halt decider cannot wait for an otherwise infinite sequence
of configurations to end, so "would" is correct.

> Also, delete "correctly".

Without the word "correctly" People simply stick to the view that it
must be incorrect. I would use a different language for academia.

> You only need an adverb in the exceptional case: "incorrectly
> simulated", "partially simulated". Also the "input" to H are it's
> parameters. The parameters are both C pointers. What does it mean to
> simulate two pointers?

We can't actually pass a finite string to a "C" function so we have to
use pointers to strings.

> And "final state" is a term from Turing machines
> but H and P are C functions.
>

I mean in in a perfectly analogous way.

> I'd re-word it in a sane way, but you'd reject my re-wording (I know
> because I did in a few years ago). This is all old hat.
>
>> Are you saying that the definition of halting is incorrect?
>
> No. You don't know what it is, but it's not incorrect. You could try
> to say what it is, but I doubt you can without the long list of category
> errors above.
>

I have already quoted this very many dozens of times:

>> Are you saying that the correctly simulated input to H(P,P) does reach
>> its own final state?
>
> Simulating P(P) and calling P(P) have the same halting status. They
> both halt or neither halts.
>

I never bring this up because it always causes a short-circuit in your
brain: The execution of P(P) is not computationally equivalent to the
correct simulation of the input to H(P,P).

That is why I focus on the X proves Y

(X) We can verify that the simulated input to H(P,P) fails to meet the
Linz definition of

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

(Y) When H(P,P) returns false it is correct.

I CAN'T POSSIBLE BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR Y.

--
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 4/12/2022 9:13 PM, Dennis Bush wrote:
> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
>> On 4/12/2022 9:02 PM, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>
>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>
>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>>>>>> its own final state.
>>>>>>>>>>>
>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>
>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>
>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>>>
>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>>>>>> false?
>>>>>>
>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>>> reach the final state of this input then we know that it never halts
>>>>>> even if everyone in the universe disagrees.
>>>>>
>>>>> So you plan to keep posting the same sentence in an attempt to take
>>>>> the focus off the fact that H is obviously wrong?
>>>>
>>>> Then you must mean
>>>
>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>>>
>>> You should avoid trying to paraphrase other people. Your replies
>>> suggest you don't often understand the various points being put to you,
>>> so when you try to re-word them the results are usually bogus.
>>>
>>>> that a correctly simulated input that would never reaches its own
>>>> final state is still a computation that halts.
>>>
>>> I meant what I said. If you are not sure that I meant, asking
>>> well-chosen questions about it is the way to go.
>>>
>> We know [by definition] that a correctly simulated input that would
>> never reach its own final state is not a halting computation.
>>
>> Are you saying that the definition of halting is incorrect?
>>
>> Are you saying that the correctly simulated input to H(P,P) does reach
>> its own final state?
>
> As a matter of fact it does.
>

The simulated input to H(P,P) cannot possibly reach its own final state
it keeps repeating [00000956] to [00000961] until aborted.

_P()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax // push P
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx // push P
[00000961](05) e8c0feffff call 00000826 // call H(P,P)
The above keeps repeating until aborted

[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp
[00000970](01) c3 ret // final state.
Size in bytes:(0027) [00000970]

--
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 4/12/2022 9:37 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/12/2022 8:55 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/12/2022 7:47 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/12/2022 8:09 AM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>>>>>> I am only talking about H(P,P) now because if someone imagines that it
>>>>>>>> does differently that it does an actual execution trace proves that
>>>>>>>> they are incorrect as a matter of objective fact with zero room for
>>>>>>>> debate.
>>>>>>>
>>>>>>> That's good because you have been 100% clear about H. It's wrong
>>>>>>> because P(P) halts (according to you) and H(P,P) == false (according to
>>>>>>> you).
>>>>>>
>>>>>> Why do you insist that a halt decider must compute the mapping from
>>>>>> non-inputs: P(P) when you know that it only computes the mapping from
>>>>>> inputs H(P,P) ?
>>>>>
>>>>> I don't. H takes arguments (what you insist on calling inputs) and maps
>>>>> them to a result. The correct result is defined by people who know what
>>>>> the halting problem is -- you don't get to decide. You may never
>>>>> understand the specification, but you only need to know one fact about
>>>>> it: mapping the "inputs" P and P to false is wrong.
>>>>
>>>> So in other words you are saying that mere opinions carry more weight
>>>> than the following verified fact:
>>>
>>> The facts that (a) H(P,P) == false and (b) P(P) halts are not in dispute
>>> (so far as I know). That H mapping P and P to false is wrong is a
>>> matter of definition. There are no opinions being expressed here at
>>> all.
>>
>> So you agree that an input that never halts is a halting computation.
>
> Don't be silly. As the culmination of 17 years of work, this looks
> pathetic. Either retract one of your previously asserted facts (that
> P(P) halts or that H(P,P) == false) or say that your H is not deciding
> halting, but something else.
>

That is why I focus on the X proves Y

(X) We can verify that the simulated input to H(P,P) fails to meet the
Linz definition of

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

(Y) When H(P,P) returns false it is correct.

I CAN'T POSSIBLY BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR Y.

--
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 Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
> On 4/12/2022 9:13 PM, Dennis Bush wrote:
> > On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
> >> On 4/12/2022 9:02 PM, Ben wrote:
> >>> olcott <No...@NoWhere.com> writes:
> >>>
> >>>> On 4/12/2022 7:49 PM, Ben wrote:
> >>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>> On 4/12/2022 8:06 AM, Ben wrote:
> >>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>
> >>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
> >>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>
> >>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
> >>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
> >>>>>>>>>
> >>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
> >>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
> >>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
> >>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
> >>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
> >>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
> >>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
> >>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
> >>>>>>>>>>>>>>> (according to you). That's why H is wrong.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
> >>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
> >>>>>>>>>>>>>> own state.
> >>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
> >>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
> >>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
> >>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
> >>>>>>>>>>>> its own final state.
> >>>>>>>>>>>
> >>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
> >>>>>>>>> typo: "so H(P,P) == false is wrong"
> >>>>>>>>>>> these facts (since they come from you in the first place). Until
> >>>>>>>>>>> then, you've told us that your H is wrong.
> >>>>>>>>>>
> >>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
> >>>>>>>>>> machine address, no waffle there merely an easily verified fact.
> >>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
> >>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
> >>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
> >>>>>>>>> say and I'll stop quoting it.
> >>>>>>>>
> >>>>>>>> The sequence of configurations specified by P(P) intuitively seems
> >>>>>>>> like it must be identical to the correct simulation of the input to
> >>>>>>>> H(P,P). It turns out that intuition is incorrect.
> >>>>>>>
> >>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
> >>>>>>> false?
> >>>>>>
> >>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
> >>>>>> reach the final state of this input then we know that it never halts
> >>>>>> even if everyone in the universe disagrees.
> >>>>>
> >>>>> So you plan to keep posting the same sentence in an attempt to take
> >>>>> the focus off the fact that H is obviously wrong?
> >>>>
> >>>> Then you must mean
> >>>
> >>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
> >>>
> >>> You should avoid trying to paraphrase other people. Your replies
> >>> suggest you don't often understand the various points being put to you,
> >>> so when you try to re-word them the results are usually bogus.
> >>>
> >>>> that a correctly simulated input that would never reaches its own
> >>>> final state is still a computation that halts.
> >>>
> >>> I meant what I said. If you are not sure that I meant, asking
> >>> well-chosen questions about it is the way to go.
> >>>
> >> We know [by definition] that a correctly simulated input that would
> >> never reach its own final state is not a halting computation.
> >>
> >> Are you saying that the definition of halting is incorrect?
> >>
> >> Are you saying that the correctly simulated input to H(P,P) does reach
> >> its own final state?
> >
> > As a matter of fact it does.
> >
> The simulated input to H(P,P) cannot possibly reach its own final state
> it keeps repeating [00000956] to [00000961] until aborted.
>
> _P()
> [00000956](01) 55 push ebp
> [00000957](02) 8bec mov ebp,esp
> [00000959](03) 8b4508 mov eax,[ebp+08]
> [0000095c](01) 50 push eax // push P
> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> [00000960](01) 51 push ecx // push P
> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> The above keeps repeating until aborted
>
>
> [00000966](03) 83c408 add esp,+08
> [00000969](02) 85c0 test eax,eax
> [0000096b](02) 7402 jz 0000096f
> [0000096d](02) ebfe jmp 0000096d
> [0000096f](01) 5d pop ebp
> [00000970](01) c3 ret // final state.
> Size in bytes:(0027) [00000970]

And when Hb simulates this input, it reaches a final state. Therefore H is wrong to report non-halting.

On 4/12/2022 9:56 PM, Dennis Bush wrote:
> On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
>> On 4/12/2022 9:13 PM, Dennis Bush wrote:
>>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
>>>> On 4/12/2022 9:02 PM, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>>>>>>>> its own final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>>>
>>>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>>>>>
>>>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>>>>>>>> false?
>>>>>>>>
>>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>>>>> reach the final state of this input then we know that it never halts
>>>>>>>> even if everyone in the universe disagrees.
>>>>>>>
>>>>>>> So you plan to keep posting the same sentence in an attempt to take
>>>>>>> the focus off the fact that H is obviously wrong?
>>>>>>
>>>>>> Then you must mean
>>>>>
>>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>>>>>
>>>>> You should avoid trying to paraphrase other people. Your replies
>>>>> suggest you don't often understand the various points being put to you,
>>>>> so when you try to re-word them the results are usually bogus.
>>>>>
>>>>>> that a correctly simulated input that would never reaches its own
>>>>>> final state is still a computation that halts.
>>>>>
>>>>> I meant what I said. If you are not sure that I meant, asking
>>>>> well-chosen questions about it is the way to go.
>>>>>
>>>> We know [by definition] that a correctly simulated input that would
>>>> never reach its own final state is not a halting computation.
>>>>
>>>> Are you saying that the definition of halting is incorrect?
>>>>
>>>> Are you saying that the correctly simulated input to H(P,P) does reach
>>>> its own final state?
>>>
>>> As a matter of fact it does.
>>>
>> The simulated input to H(P,P) cannot possibly reach its own final state
>> it keeps repeating [00000956] to [00000961] until aborted.
>>
>> _P()
>> [00000956](01) 55 push ebp
>> [00000957](02) 8bec mov ebp,esp
>> [00000959](03) 8b4508 mov eax,[ebp+08]
>> [0000095c](01) 50 push eax // push P
>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>> [00000960](01) 51 push ecx // push P
>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>> The above keeps repeating until aborted
>>
>>
>> [00000966](03) 83c408 add esp,+08
>> [00000969](02) 85c0 test eax,eax
>> [0000096b](02) 7402 jz 0000096f
>> [0000096d](02) ebfe jmp 0000096d
>> [0000096f](01) 5d pop ebp
>> [00000970](01) c3 ret // final state.
>> Size in bytes:(0027) [00000970]
>
> And when Hb simulates this input, it reaches a final state. Therefore H is wrong to report non-halting.

A dishonest attempt at the strawman fallacy.

Bill up the street did not rob the liquor store I know this because the
other guy that I know named Bill was watching TV at the time of the
robbery.

--
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 4/12/22 10:54 PM, olcott wrote:
> On 4/12/2022 9:37 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 8:55 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/12/2022 7:47 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/12/2022 8:09 AM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>>>>>>> I am only talking about H(P,P) now because if someone imagines
>>>>>>>>> that it
>>>>>>>>> does differently that it does an actual execution trace proves
>>>>>>>>> that
>>>>>>>>> they are incorrect as a matter of objective fact with zero room
>>>>>>>>> for
>>>>>>>>> debate.
>>>>>>>>
>>>>>>>> That's good because you have been 100% clear about H.  It's wrong
>>>>>>>> because P(P) halts (according to you) and H(P,P) == false
>>>>>>>> (according to
>>>>>>>> you).
>>>>>>>
>>>>>>> Why do you insist that a halt decider must compute the mapping from
>>>>>>> non-inputs: P(P) when you know that it only computes the mapping
>>>>>>> from
>>>>>>> inputs H(P,P) ?
>>>>>>
>>>>>> I don't.  H takes arguments (what you insist on calling inputs)
>>>>>> and maps
>>>>>> them to a result.  The correct result is defined by people who
>>>>>> know what
>>>>>> the halting problem is -- you don't get to decide.  You may never
>>>>>> understand the specification, but you only need to know one fact
>>>>>> about
>>>>>> it: mapping the "inputs" P and P to false is wrong.
>>>>>
>>>>> So in other words you are saying that mere opinions carry more weight
>>>>> than the following verified fact:
>>>>
>>>> The facts that (a) H(P,P) == false and (b) P(P) halts are not in
>>>> dispute
>>>> (so far as I know).  That H mapping P and P to false is wrong is a
>>>> matter of definition.  There are no opinions being expressed here at
>>>> all.
>>>
>>> So you agree that an input that never halts is a halting computation.
>>
>> Don't be silly.  As the culmination of 17 years of work, this looks
>> pathetic.  Either retract one of your previously asserted facts (that
>> P(P) halts or that H(P,P) == false) or say that your H is not deciding
>> halting, but something else.
>>
>
> That is why I focus on the X proves Y
>
> (X) We can verify that the simulated input to H(P,P) fails to meet the
> Linz definition of
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)

No, you haven't, because the definition doesn't talk about simulations
of inputs, but about Turing Machines.

The Linz definition needs tp be applied to that actual Turing Machine,
that would be H^, as it is applied to the input <H^>.

Since H^ applied to <H^> DOES HALT (if H reject <H^> <H^>) then it DOES
meet Linz defintion of a Halting Computation.

>
> (Y) When H(P,P) returns false it is correct.
>
> I CAN'T POSSIBLY BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR Y.
>
>

Since X isn't true, you don't have X & Y, so you haven't proven Z.

FAIL.

On Tuesday, April 12, 2022 at 10:59:47 PM UTC-4, olcott wrote:
> On 4/12/2022 9:56 PM, Dennis Bush wrote:
> > On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
> >> On 4/12/2022 9:13 PM, Dennis Bush wrote:
> >>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
> >>>> On 4/12/2022 9:02 PM, Ben wrote:
> >>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>> On 4/12/2022 7:49 PM, Ben wrote:
> >>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>
> >>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
> >>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>
> >>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
> >>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
> >>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
> >>>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
> >>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
> >>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
> >>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
> >>>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
> >>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
> >>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
> >>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
> >>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
> >>>>>>>>>>>>>>>> own state.
> >>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
> >>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
> >>>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
> >>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
> >>>>>>>>>>>>>> its own final state.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
> >>>>>>>>>>> typo: "so H(P,P) == false is wrong"
> >>>>>>>>>>>>> these facts (since they come from you in the first place). Until
> >>>>>>>>>>>>> then, you've told us that your H is wrong.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
> >>>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
> >>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
> >>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
> >>>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
> >>>>>>>>>>> say and I'll stop quoting it.
> >>>>>>>>>>
> >>>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
> >>>>>>>>>> like it must be identical to the correct simulation of the input to
> >>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
> >>>>>>>>>
> >>>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
> >>>>>>>>> false?
> >>>>>>>>
> >>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
> >>>>>>>> reach the final state of this input then we know that it never halts
> >>>>>>>> even if everyone in the universe disagrees.
> >>>>>>>
> >>>>>>> So you plan to keep posting the same sentence in an attempt to take
> >>>>>>> the focus off the fact that H is obviously wrong?
> >>>>>>
> >>>>>> Then you must mean
> >>>>>
> >>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
> >>>>>
> >>>>> You should avoid trying to paraphrase other people. Your replies
> >>>>> suggest you don't often understand the various points being put to you,
> >>>>> so when you try to re-word them the results are usually bogus.
> >>>>>
> >>>>>> that a correctly simulated input that would never reaches its own
> >>>>>> final state is still a computation that halts.
> >>>>>
> >>>>> I meant what I said. If you are not sure that I meant, asking
> >>>>> well-chosen questions about it is the way to go.
> >>>>>
> >>>> We know [by definition] that a correctly simulated input that would
> >>>> never reach its own final state is not a halting computation.
> >>>>
> >>>> Are you saying that the definition of halting is incorrect?
> >>>>
> >>>> Are you saying that the correctly simulated input to H(P,P) does reach
> >>>> its own final state?
> >>>
> >>> As a matter of fact it does.
> >>>
> >> The simulated input to H(P,P) cannot possibly reach its own final state
> >> it keeps repeating [00000956] to [00000961] until aborted.
> >>
> >> _P()
> >> [00000956](01) 55 push ebp
> >> [00000957](02) 8bec mov ebp,esp
> >> [00000959](03) 8b4508 mov eax,[ebp+08]
> >> [0000095c](01) 50 push eax // push P
> >> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> >> [00000960](01) 51 push ecx // push P
> >> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> >> The above keeps repeating until aborted
> >>
> >>
> >> [00000966](03) 83c408 add esp,+08
> >> [00000969](02) 85c0 test eax,eax
> >> [0000096b](02) 7402 jz 0000096f
> >> [0000096d](02) ebfe jmp 0000096d
> >> [0000096f](01) 5d pop ebp
> >> [00000970](01) c3 ret // final state.
> >> Size in bytes:(0027) [00000970]
> >
> > And when Hb simulates this input, it reaches a final state. Therefore H is wrong to report non-halting.
> A dishonest attempt at the strawman fallacy.
>
> Bill up the street did not rob the liquor store I know this because the
> other guy that I know named Bill was watching TV at the time of the
> robbery.

On 4/12/2022 10:05 PM, Dennis Bush wrote:
> On Tuesday, April 12, 2022 at 10:59:47 PM UTC-4, olcott wrote:
>> On 4/12/2022 9:56 PM, Dennis Bush wrote:
>>> On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
>>>> On 4/12/2022 9:13 PM, Dennis Bush wrote:
>>>>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
>>>>>> On 4/12/2022 9:02 PM, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>>>>>>>>>> its own final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>>>>>
>>>>>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>>>>>>>
>>>>>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>>>>>>>>>> false?
>>>>>>>>>>
>>>>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>>>>>>> reach the final state of this input then we know that it never halts
>>>>>>>>>> even if everyone in the universe disagrees.
>>>>>>>>>
>>>>>>>>> So you plan to keep posting the same sentence in an attempt to take
>>>>>>>>> the focus off the fact that H is obviously wrong?
>>>>>>>>
>>>>>>>> Then you must mean
>>>>>>>
>>>>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>>>>>>>
>>>>>>> You should avoid trying to paraphrase other people. Your replies
>>>>>>> suggest you don't often understand the various points being put to you,
>>>>>>> so when you try to re-word them the results are usually bogus.
>>>>>>>
>>>>>>>> that a correctly simulated input that would never reaches its own
>>>>>>>> final state is still a computation that halts.
>>>>>>>
>>>>>>> I meant what I said. If you are not sure that I meant, asking
>>>>>>> well-chosen questions about it is the way to go.
>>>>>>>
>>>>>> We know [by definition] that a correctly simulated input that would
>>>>>> never reach its own final state is not a halting computation.
>>>>>>
>>>>>> Are you saying that the definition of halting is incorrect?
>>>>>>
>>>>>> Are you saying that the correctly simulated input to H(P,P) does reach
>>>>>> its own final state?
>>>>>
>>>>> As a matter of fact it does.
>>>>>
>>>> The simulated input to H(P,P) cannot possibly reach its own final state
>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>
>>>> _P()
>>>> [00000956](01) 55 push ebp
>>>> [00000957](02) 8bec mov ebp,esp
>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>> [0000095c](01) 50 push eax // push P
>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>> [00000960](01) 51 push ecx // push P
>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>> The above keeps repeating until aborted
>>>>
>>>>
>>>> [00000966](03) 83c408 add esp,+08
>>>> [00000969](02) 85c0 test eax,eax
>>>> [0000096b](02) 7402 jz 0000096f
>>>> [0000096d](02) ebfe jmp 0000096d
>>>> [0000096f](01) 5d pop ebp
>>>> [00000970](01) c3 ret // final state.
>>>> Size in bytes:(0027) [00000970]
>>>
>>> And when Hb simulates this input, it reaches a final state. Therefore H is wrong to report non-halting.
>> A dishonest attempt at the strawman fallacy.
>>
>> Bill up the street did not rob the liquor store I know this because the
>> other guy that I know named Bill was watching TV at the time of the
>> robbery.
>
> So in other words you have no rebuttal because you know that Hb(P,P) == true is correct and proves that H(P,P)==false is incorrect.

On 4/12/22 10:49 PM, olcott wrote:
> On 4/12/2022 9:29 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 9:02 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>>
>>>>>>>>>>>>>>>> The truth is not determined by who does or does not
>>>>>>>>>>>>>>>> agree with
>>>>>>>>>>>>>>>> something.  But to find the truth of the matter you must
>>>>>>>>>>>>>>>> first stop
>>>>>>>>>>>>>>>> talking literal nonsense.  The arguments to H (what you
>>>>>>>>>>>>>>>> call the
>>>>>>>>>>>>>>>> "input") are two pointers.  What does simulating two
>>>>>>>>>>>>>>>> pointers mean?
>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first
>>>>>>>>>>>>>>>> pointer with the
>>>>>>>>>>>>>>>> second as it's argument.  That simulation, according to
>>>>>>>>>>>>>>>> you, will halt
>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant,
>>>>>>>>>>>>>>>> sciencey, language).
>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts.
>>>>>>>>>>>>>>>> Everything here halts
>>>>>>>>>>>>>>>> (according to you).  That's why H is wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that
>>>>>>>>>>>>>>> conclusively
>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly
>>>>>>>>>>>>>>> reach its final
>>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you
>>>>>>>>>>>>>> made the mistake
>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false
>>>>>>>>>>>>>> (you posted that
>>>>>>>>>>>>>> as well).  You a free to retract any of these at any time,
>>>>>>>>>>>>>> but until you
>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P)
>>>>>>>>>>>>> ever reaches
>>>>>>>>>>>>> its own final state.
>>>>>>>>>>>>
>>>>>>>>>>>> Waffle.  HP(P) halts so (P,P) == false is wrong.  You can
>>>>>>>>>>>> retract
>>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>>> these facts (since they come from you in the first place).
>>>>>>>>>>>> Until
>>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>>
>>>>>>>>>>> It is the case that the simulated input never reaches its
>>>>>>>>>>> [00000970]
>>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>>>> You can verify a thousand more irrelevant facts.  The facts
>>>>>>>>>> that matter
>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false.
>>>>>>>>>> Are you
>>>>>>>>>> presenting any verified facts that corrects this mistake?  If
>>>>>>>>>> so, just
>>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>>
>>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>>>> like it must be identical to the correct simulation of the
>>>>>>>>> input to
>>>>>>>>> H(P,P).  It turns out that intuition is incorrect.
>>>>>>>>
>>>>>>>> So which fact are you retracting?  That P(P) halts or that
>>>>>>>> H(P,P) ==
>>>>>>>> false?
>>>>>>>
>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>>>> reach the final state of this input then we know that it never halts
>>>>>>> even if everyone in the universe disagrees.
>>>>>>
>>>>>> So you plan to keep posting the same sentence in an attempt to take
>>>>>> the focus off the fact that H is obviously wrong?
>>>>>
>>>>> Then you must mean
>>>> WHOOP!  WHOOP!  WHOOP!  Danger Will Robinson.
>>>> You should avoid trying to paraphrase other people.  Your replies
>>>> suggest you don't often understand the various points being put to you,
>>>> so when you try to re-word them the results are usually bogus.
>>>>
>>>>> that a correctly simulated input that would never reaches its own
>>>>> final state is still a computation that halts.
>>>>
>>>> I meant what I said.  If you are not sure that I meant, asking
>>>> well-chosen questions about it is the way to go.
>>>
>>> We know [by definition] that a correctly simulated input that would
>>> never reach its own final state is not a halting computation.
>>
>> Deception alert: "would" rather than "does".
>
> A simulating halt decider cannot wait for an otherwise infinite sequence
> of configurations to end, so "would" is correct.

Nope.

Because SINCE your simulating Halt Decider DOES abort its simulation,
then a correct simulation of the input does halt.

The fact that you can't make you simulating halt decider actual DO a
correct simulation and answer at the same time is irrelvent, you need to
look at the machine you actual claim to be correct, which has to fail in
one of the ways.

>
>>  Also, delete "correctly".
>
> Without the word "correctly" People simply stick to the view that it
> must be incorrect. I would use a different language for academia.

Except that your simulation is NOT correct, as a correct simulation of
something matches its actual behavior, and thus a correct simulation of
a Turing Machine can't abort its simulation as the Turing Machine didn't
just disappear.

>
>> You only need an adverb in the exceptional case: "incorrectly
>> simulated", "partially simulated".  Also the "input" to H are it's
>> parameters.  The parameters are both C pointers.  What does it mean to
>> simulate two pointers?
>
> We can't actually pass a finite string to a "C" function so we have to
> use pointers to strings.

On Tuesday, April 12, 2022 at 11:09:11 PM UTC-4, olcott wrote:
> On 4/12/2022 10:05 PM, Dennis Bush wrote:
> > On Tuesday, April 12, 2022 at 10:59:47 PM UTC-4, olcott wrote:
> >> On 4/12/2022 9:56 PM, Dennis Bush wrote:
> >>> On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
> >>>> On 4/12/2022 9:13 PM, Dennis Bush wrote:
> >>>>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
> >>>>>> On 4/12/2022 9:02 PM, Ben wrote:
> >>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>
> >>>>>>>> On 4/12/2022 7:49 PM, Ben wrote:
> >>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>
> >>>>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
> >>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
> >>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
> >>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
> >>>>>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
> >>>>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
> >>>>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
> >>>>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
> >>>>>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
> >>>>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
> >>>>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
> >>>>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
> >>>>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
> >>>>>>>>>>>>>>>>>> own state.
> >>>>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
> >>>>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
> >>>>>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
> >>>>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
> >>>>>>>>>>>>>>>> its own final state.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
> >>>>>>>>>>>>> typo: "so H(P,P) == false is wrong"
> >>>>>>>>>>>>>>> these facts (since they come from you in the first place).. Until
> >>>>>>>>>>>>>>> then, you've told us that your H is wrong.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
> >>>>>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
> >>>>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
> >>>>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
> >>>>>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
> >>>>>>>>>>>>> say and I'll stop quoting it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
> >>>>>>>>>>>> like it must be identical to the correct simulation of the input to
> >>>>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
> >>>>>>>>>>>
> >>>>>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
> >>>>>>>>>>> false?
> >>>>>>>>>>
> >>>>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
> >>>>>>>>>> reach the final state of this input then we know that it never halts
> >>>>>>>>>> even if everyone in the universe disagrees.
> >>>>>>>>>
> >>>>>>>>> So you plan to keep posting the same sentence in an attempt to take
> >>>>>>>>> the focus off the fact that H is obviously wrong?
> >>>>>>>>
> >>>>>>>> Then you must mean
> >>>>>>>
> >>>>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
> >>>>>>>
> >>>>>>> You should avoid trying to paraphrase other people. Your replies
> >>>>>>> suggest you don't often understand the various points being put to you,
> >>>>>>> so when you try to re-word them the results are usually bogus.
> >>>>>>>
> >>>>>>>> that a correctly simulated input that would never reaches its own
> >>>>>>>> final state is still a computation that halts.
> >>>>>>>
> >>>>>>> I meant what I said. If you are not sure that I meant, asking
> >>>>>>> well-chosen questions about it is the way to go.
> >>>>>>>
> >>>>>> We know [by definition] that a correctly simulated input that would
> >>>>>> never reach its own final state is not a halting computation.
> >>>>>>
> >>>>>> Are you saying that the definition of halting is incorrect?
> >>>>>>
> >>>>>> Are you saying that the correctly simulated input to H(P,P) does reach
> >>>>>> its own final state?
> >>>>>
> >>>>> As a matter of fact it does.
> >>>>>
> >>>> The simulated input to H(P,P) cannot possibly reach its own final state
> >>>> it keeps repeating [00000956] to [00000961] until aborted.
> >>>>
> >>>> _P()
> >>>> [00000956](01) 55 push ebp
> >>>> [00000957](02) 8bec mov ebp,esp
> >>>> [00000959](03) 8b4508 mov eax,[ebp+08]
> >>>> [0000095c](01) 50 push eax // push P
> >>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [00000960](01) 51 push ecx // push P
> >>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> >>>> The above keeps repeating until aborted
> >>>>
> >>>>
> >>>> [00000966](03) 83c408 add esp,+08
> >>>> [00000969](02) 85c0 test eax,eax
> >>>> [0000096b](02) 7402 jz 0000096f
> >>>> [0000096d](02) ebfe jmp 0000096d
> >>>> [0000096f](01) 5d pop ebp
> >>>> [00000970](01) c3 ret // final state.
> >>>> Size in bytes:(0027) [00000970]
> >>>
> >>> And when Hb simulates this input, it reaches a final state. Therefore H is wrong to report non-halting.
> >> A dishonest attempt at the strawman fallacy.
> >>
> >> Bill up the street did not rob the liquor store I know this because the
> >> other guy that I know named Bill was watching TV at the time of the
> >> robbery.
> >
> > So in other words you have no rebuttal because you know that Hb(P,P) == true is correct and proves that H(P,P)==false is incorrect.
> Hb(P,P) is off topic because it proves nothing and you know that it
> proves nothing and is just a disgusting attempt at a head game.

On 4/12/22 10:59 PM, olcott wrote:
> On 4/12/2022 9:56 PM, Dennis Bush wrote:
>> On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
>>> On 4/12/2022 9:13 PM, Dennis Bush wrote:
>>>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
>>>>> On 4/12/2022 9:02 PM, Ben wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The truth is not determined by who does or does not
>>>>>>>>>>>>>>>>>> agree with
>>>>>>>>>>>>>>>>>> something. But to find the truth of the matter you
>>>>>>>>>>>>>>>>>> must first stop
>>>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you
>>>>>>>>>>>>>>>>>> call the
>>>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two
>>>>>>>>>>>>>>>>>> pointers mean?
>>>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first
>>>>>>>>>>>>>>>>>> pointer with the
>>>>>>>>>>>>>>>>>> second as it's argument. That simulation, according to
>>>>>>>>>>>>>>>>>> you, will halt
>>>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant,
>>>>>>>>>>>>>>>>>> sciencey, language).
>>>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts.
>>>>>>>>>>>>>>>>>> Everything here halts
>>>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that
>>>>>>>>>>>>>>>>> conclusively
>>>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly
>>>>>>>>>>>>>>>>> reach its final
>>>>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you
>>>>>>>>>>>>>>>> made the mistake
>>>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false
>>>>>>>>>>>>>>>> (you posted that
>>>>>>>>>>>>>>>> as well). You a free to retract any of these at any
>>>>>>>>>>>>>>>> time, but until you
>>>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P)
>>>>>>>>>>>>>>> ever reaches
>>>>>>>>>>>>>>> its own final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can
>>>>>>>>>>>>>> retract
>>>>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>>>>> these facts (since they come from you in the first place).
>>>>>>>>>>>>>> Until
>>>>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the case that the simulated input never reaches its
>>>>>>>>>>>>> [00000970]
>>>>>>>>>>>>> machine address, no waffle there merely an easily verified
>>>>>>>>>>>>> fact.
>>>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts
>>>>>>>>>>>> that matter
>>>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false.
>>>>>>>>>>>> Are you
>>>>>>>>>>>> presenting any verified facts that corrects this mistake? If
>>>>>>>>>>>> so, just
>>>>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>>>>
>>>>>>>>>>> The sequence of configurations specified by P(P) intuitively
>>>>>>>>>>> seems
>>>>>>>>>>> like it must be identical to the correct simulation of the
>>>>>>>>>>> input to
>>>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>>>>>>
>>>>>>>>>> So which fact are you retracting? That P(P) halts or that
>>>>>>>>>> H(P,P) ==
>>>>>>>>>> false?
>>>>>>>>>
>>>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>>>>>> reach the final state of this input then we know that it never
>>>>>>>>> halts
>>>>>>>>> even if everyone in the universe disagrees.
>>>>>>>>
>>>>>>>> So you plan to keep posting the same sentence in an attempt to take
>>>>>>>> the focus off the fact that H is obviously wrong?
>>>>>>>
>>>>>>> Then you must mean
>>>>>>
>>>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>>>>>>
>>>>>> You should avoid trying to paraphrase other people. Your replies
>>>>>> suggest you don't often understand the various points being put to
>>>>>> you,
>>>>>> so when you try to re-word them the results are usually bogus.
>>>>>>
>>>>>>> that a correctly simulated input that would never reaches its own
>>>>>>> final state is still a computation that halts.
>>>>>>
>>>>>> I meant what I said. If you are not sure that I meant, asking
>>>>>> well-chosen questions about it is the way to go.
>>>>>>
>>>>> We know [by definition] that a correctly simulated input that would
>>>>> never reach its own final state is not a halting computation.
>>>>>
>>>>> Are you saying that the definition of halting is incorrect?
>>>>>
>>>>> Are you saying that the correctly simulated input to H(P,P) does reach
>>>>> its own final state?
>>>>
>>>> As a matter of fact it does.
>>>>
>>> The simulated input to H(P,P) cannot possibly reach its own final state
>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>
>>> _P()
>>> [00000956](01) 55 push ebp
>>> [00000957](02) 8bec mov ebp,esp
>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>> [0000095c](01) 50 push eax // push P
>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>> [00000960](01) 51 push ecx // push P
>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>> The above keeps repeating until aborted
>>>
>>>
>>> [00000966](03) 83c408 add esp,+08
>>> [00000969](02) 85c0 test eax,eax
>>> [0000096b](02) 7402 jz 0000096f
>>> [0000096d](02) ebfe jmp 0000096d
>>> [0000096f](01) 5d pop ebp
>>> [00000970](01) c3 ret // final state.
>>> Size in bytes:(0027) [00000970]
>>
>> And when Hb simulates this input, it reaches a final state.  Therefore
>> H is wrong to report non-halting.
>
> A dishonest attempt at the strawman fallacy.
>
> Bill up the street did not rob the liquor store I know this because the
> other guy that I know named Bill was watching TV at the time of the
> robbery.
>

On 4/12/2022 10:15 PM, Dennis Bush wrote:
> On Tuesday, April 12, 2022 at 11:09:11 PM UTC-4, olcott wrote:
>> On 4/12/2022 10:05 PM, Dennis Bush wrote:
>>> On Tuesday, April 12, 2022 at 10:59:47 PM UTC-4, olcott wrote:
>>>> On 4/12/2022 9:56 PM, Dennis Bush wrote:
>>>>> On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
>>>>>> On 4/12/2022 9:13 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
>>>>>>>> On 4/12/2022 9:02 PM, Ben wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>>>>>>>>>>>> its own final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>>>>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>>>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>>>>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>>>>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>>>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>>>>>>>>>>>> false?
>>>>>>>>>>>>
>>>>>>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>>>>>>>>> reach the final state of this input then we know that it never halts
>>>>>>>>>>>> even if everyone in the universe disagrees.
>>>>>>>>>>>
>>>>>>>>>>> So you plan to keep posting the same sentence in an attempt to take
>>>>>>>>>>> the focus off the fact that H is obviously wrong?
>>>>>>>>>>
>>>>>>>>>> Then you must mean
>>>>>>>>>
>>>>>>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>>>>>>>>>
>>>>>>>>> You should avoid trying to paraphrase other people. Your replies
>>>>>>>>> suggest you don't often understand the various points being put to you,
>>>>>>>>> so when you try to re-word them the results are usually bogus.
>>>>>>>>>
>>>>>>>>>> that a correctly simulated input that would never reaches its own
>>>>>>>>>> final state is still a computation that halts.
>>>>>>>>>
>>>>>>>>> I meant what I said. If you are not sure that I meant, asking
>>>>>>>>> well-chosen questions about it is the way to go.
>>>>>>>>>
>>>>>>>> We know [by definition] that a correctly simulated input that would
>>>>>>>> never reach its own final state is not a halting computation.
>>>>>>>>
>>>>>>>> Are you saying that the definition of halting is incorrect?
>>>>>>>>
>>>>>>>> Are you saying that the correctly simulated input to H(P,P) does reach
>>>>>>>> its own final state?
>>>>>>>
>>>>>>> As a matter of fact it does.
>>>>>>>
>>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
>>>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>>>
>>>>>> _P()
>>>>>> [00000956](01) 55 push ebp
>>>>>> [00000957](02) 8bec mov ebp,esp
>>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>>>> [0000095c](01) 50 push eax // push P
>>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>>>> [00000960](01) 51 push ecx // push P
>>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>>>> The above keeps repeating until aborted
>>>>>>
>>>>>>
>>>>>> [00000966](03) 83c408 add esp,+08
>>>>>> [00000969](02) 85c0 test eax,eax
>>>>>> [0000096b](02) 7402 jz 0000096f
>>>>>> [0000096d](02) ebfe jmp 0000096d
>>>>>> [0000096f](01) 5d pop ebp
>>>>>> [00000970](01) c3 ret // final state.
>>>>>> Size in bytes:(0027) [00000970]
>>>>>
>>>>> And when Hb simulates this input, it reaches a final state. Therefore H is wrong to report non-halting.
>>>> A dishonest attempt at the strawman fallacy.
>>>>
>>>> Bill up the street did not rob the liquor store I know this because the
>>>> other guy that I know named Bill was watching TV at the time of the
>>>> robbery.
>>>
>>> So in other words you have no rebuttal because you know that Hb(P,P) == true is correct and proves that H(P,P)==false is incorrect.
>> Hb(P,P) is off topic because it proves nothing and you know that it
>> proves nothing and is just a disgusting attempt at a head game.
>
> It is not off topic because it directly contradicts your desired result. That you haven't explained why it's wrong is a confirmation of this.
>
>> That is why I focus on the X proves Y
>>
>> (X) We can verify that the simulated input to H(P,P) fails to meet the
>> Linz definition of
>>
>> computation that halts … the Turing machine will halt whenever it enters
>> a final state. (Linz:1990:234)
>
> FALSE, because an incorrect simulation is not the same as a turing machine.
>
>> (Y) When H(P,P) returns false it is correct.
>
> FALSE, as proved by Hb(P,P) returning true for the same input.
>
>>
>> I CAN'T POSSIBLY BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR Y.
>
> If the simulated input to H(P,P) fails to meet the definition of halting, then Ha3(N,5) also fails to meet that same definition of halting. So that along shows that your criteria is bogus.

On 4/12/22 11:08 PM, olcott wrote:
> On 4/12/2022 10:05 PM, Dennis Bush wrote:
>> On Tuesday, April 12, 2022 at 10:59:47 PM UTC-4, olcott wrote:
>>> On 4/12/2022 9:56 PM, Dennis Bush wrote:
>>>> On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
>>>>> On 4/12/2022 9:13 PM, Dennis Bush wrote:
>>>>>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
>>>>>>> On 4/12/2022 9:02 PM, Ben wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The truth is not determined by who does or does not
>>>>>>>>>>>>>>>>>>>> agree with
>>>>>>>>>>>>>>>>>>>> something. But to find the truth of the matter you
>>>>>>>>>>>>>>>>>>>> must first stop
>>>>>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what
>>>>>>>>>>>>>>>>>>>> you call the
>>>>>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two
>>>>>>>>>>>>>>>>>>>> pointers mean?
>>>>>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the
>>>>>>>>>>>>>>>>>>>> first pointer with the
>>>>>>>>>>>>>>>>>>>> second as it's argument. That simulation, according
>>>>>>>>>>>>>>>>>>>> to you, will halt
>>>>>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant,
>>>>>>>>>>>>>>>>>>>> sciencey, language).
>>>>>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts.
>>>>>>>>>>>>>>>>>>>> Everything here halts
>>>>>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace
>>>>>>>>>>>>>>>>>>> that conclusively
>>>>>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly
>>>>>>>>>>>>>>>>>>> reach its final
>>>>>>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting
>>>>>>>>>>>>>>>>>> (you made the mistake
>>>>>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return
>>>>>>>>>>>>>>>>>> false (you posted that
>>>>>>>>>>>>>>>>>> as well). You a free to retract any of these at any
>>>>>>>>>>>>>>>>>> time, but until you
>>>>>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P)
>>>>>>>>>>>>>>>>> ever reaches
>>>>>>>>>>>>>>>>> its own final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can
>>>>>>>>>>>>>>>> retract
>>>>>>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>>>>>>> these facts (since they come from you in the first
>>>>>>>>>>>>>>>> place). Until
>>>>>>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is the case that the simulated input never reaches its
>>>>>>>>>>>>>>> [00000970]
>>>>>>>>>>>>>>> machine address, no waffle there merely an easily
>>>>>>>>>>>>>>> verified fact.
>>>>>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts
>>>>>>>>>>>>>> that matter
>>>>>>>>>>>>>> are already known: that P(P) halts and that H(P,P) ==
>>>>>>>>>>>>>> false. Are you
>>>>>>>>>>>>>> presenting any verified facts that corrects this mistake?
>>>>>>>>>>>>>> If so, just
>>>>>>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The sequence of configurations specified by P(P)
>>>>>>>>>>>>> intuitively seems
>>>>>>>>>>>>> like it must be identical to the correct simulation of the
>>>>>>>>>>>>> input to
>>>>>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>>>>>>>>
>>>>>>>>>>>> So which fact are you retracting? That P(P) halts or that
>>>>>>>>>>>> H(P,P) ==
>>>>>>>>>>>> false?
>>>>>>>>>>>
>>>>>>>>>>> As long as the correctly simulated input to H(P,P) cannot
>>>>>>>>>>> possibly
>>>>>>>>>>> reach the final state of this input then we know that it
>>>>>>>>>>> never halts
>>>>>>>>>>> even if everyone in the universe disagrees.
>>>>>>>>>>
>>>>>>>>>> So you plan to keep posting the same sentence in an attempt to
>>>>>>>>>> take
>>>>>>>>>> the focus off the fact that H is obviously wrong?
>>>>>>>>>
>>>>>>>>> Then you must mean
>>>>>>>>
>>>>>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>>>>>>>>
>>>>>>>> You should avoid trying to paraphrase other people. Your replies
>>>>>>>> suggest you don't often understand the various points being put
>>>>>>>> to you,
>>>>>>>> so when you try to re-word them the results are usually bogus.
>>>>>>>>
>>>>>>>>> that a correctly simulated input that would never reaches its own
>>>>>>>>> final state is still a computation that halts.
>>>>>>>>
>>>>>>>> I meant what I said. If you are not sure that I meant, asking
>>>>>>>> well-chosen questions about it is the way to go.
>>>>>>>>
>>>>>>> We know [by definition] that a correctly simulated input that would
>>>>>>> never reach its own final state is not a halting computation.
>>>>>>>
>>>>>>> Are you saying that the definition of halting is incorrect?
>>>>>>>
>>>>>>> Are you saying that the correctly simulated input to H(P,P) does
>>>>>>> reach
>>>>>>> its own final state?
>>>>>>
>>>>>> As a matter of fact it does.
>>>>>>
>>>>> The simulated input to H(P,P) cannot possibly reach its own final
>>>>> state
>>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>>
>>>>> _P()
>>>>> [00000956](01) 55 push ebp
>>>>> [00000957](02) 8bec mov ebp,esp
>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>>> [0000095c](01) 50 push eax // push P
>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>>> [00000960](01) 51 push ecx // push P
>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>>> The above keeps repeating until aborted
>>>>>
>>>>>
>>>>> [00000966](03) 83c408 add esp,+08
>>>>> [00000969](02) 85c0 test eax,eax
>>>>> [0000096b](02) 7402 jz 0000096f
>>>>> [0000096d](02) ebfe jmp 0000096d
>>>>> [0000096f](01) 5d pop ebp
>>>>> [00000970](01) c3 ret // final state.
>>>>> Size in bytes:(0027) [00000970]
>>>>
>>>> And when Hb simulates this input, it reaches a final state.
>>>> Therefore H is wrong to report non-halting.
>>> A dishonest attempt at the strawman fallacy.
>>>
>>> Bill up the street did not rob the liquor store I know this because the
>>> other guy that I know named Bill was watching TV at the time of the
>>> robbery.
>>
>> So in other words you have no rebuttal because you know that Hb(P,P)
>> == true is correct and proves that H(P,P)==false is incorrect.
>
> Hb(P,P) is off topic because it proves nothing and you know that it
> proves nothing and is just a disgusting attempt at a head game.

On Tuesday, April 12, 2022 at 11:17:52 PM UTC-4, olcott wrote:
> On 4/12/2022 10:15 PM, Dennis Bush wrote:
> > On Tuesday, April 12, 2022 at 11:09:11 PM UTC-4, olcott wrote:
> >> On 4/12/2022 10:05 PM, Dennis Bush wrote:
> >>> On Tuesday, April 12, 2022 at 10:59:47 PM UTC-4, olcott wrote:
> >>>> On 4/12/2022 9:56 PM, Dennis Bush wrote:
> >>>>> On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
> >>>>>> On 4/12/2022 9:13 PM, Dennis Bush wrote:
> >>>>>>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
> >>>>>>>> On 4/12/2022 9:02 PM, Ben wrote:
> >>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>
> >>>>>>>>>> On 4/12/2022 7:49 PM, Ben wrote:
> >>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
> >>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
> >>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
> >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
> >>>>>>>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
> >>>>>>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
> >>>>>>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
> >>>>>>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
> >>>>>>>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
> >>>>>>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
> >>>>>>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
> >>>>>>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
> >>>>>>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
> >>>>>>>>>>>>>>>>>>>> own state.
> >>>>>>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
> >>>>>>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
> >>>>>>>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
> >>>>>>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
> >>>>>>>>>>>>>>>>>> its own final state.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
> >>>>>>>>>>>>>>> typo: "so H(P,P) == false is wrong"
> >>>>>>>>>>>>>>>>> these facts (since they come from you in the first place). Until
> >>>>>>>>>>>>>>>>> then, you've told us that your H is wrong.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
> >>>>>>>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
> >>>>>>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
> >>>>>>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
> >>>>>>>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
> >>>>>>>>>>>>>>> say and I'll stop quoting it.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
> >>>>>>>>>>>>>> like it must be identical to the correct simulation of the input to
> >>>>>>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
> >>>>>>>>>>>>> false?
> >>>>>>>>>>>>
> >>>>>>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
> >>>>>>>>>>>> reach the final state of this input then we know that it never halts
> >>>>>>>>>>>> even if everyone in the universe disagrees.
> >>>>>>>>>>>
> >>>>>>>>>>> So you plan to keep posting the same sentence in an attempt to take
> >>>>>>>>>>> the focus off the fact that H is obviously wrong?
> >>>>>>>>>>
> >>>>>>>>>> Then you must mean
> >>>>>>>>>
> >>>>>>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
> >>>>>>>>>
> >>>>>>>>> You should avoid trying to paraphrase other people. Your replies
> >>>>>>>>> suggest you don't often understand the various points being put to you,
> >>>>>>>>> so when you try to re-word them the results are usually bogus.
> >>>>>>>>>
> >>>>>>>>>> that a correctly simulated input that would never reaches its own
> >>>>>>>>>> final state is still a computation that halts.
> >>>>>>>>>
> >>>>>>>>> I meant what I said. If you are not sure that I meant, asking
> >>>>>>>>> well-chosen questions about it is the way to go.
> >>>>>>>>>
> >>>>>>>> We know [by definition] that a correctly simulated input that would
> >>>>>>>> never reach its own final state is not a halting computation.
> >>>>>>>>
> >>>>>>>> Are you saying that the definition of halting is incorrect?
> >>>>>>>>
> >>>>>>>> Are you saying that the correctly simulated input to H(P,P) does reach
> >>>>>>>> its own final state?
> >>>>>>>
> >>>>>>> As a matter of fact it does.
> >>>>>>>
> >>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
> >>>>>> it keeps repeating [00000956] to [00000961] until aborted.
> >>>>>>
> >>>>>> _P()
> >>>>>> [00000956](01) 55 push ebp
> >>>>>> [00000957](02) 8bec mov ebp,esp
> >>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
> >>>>>> [0000095c](01) 50 push eax // push P
> >>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>> [00000960](01) 51 push ecx // push P
> >>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> >>>>>> The above keeps repeating until aborted
> >>>>>>
> >>>>>>
> >>>>>> [00000966](03) 83c408 add esp,+08
> >>>>>> [00000969](02) 85c0 test eax,eax
> >>>>>> [0000096b](02) 7402 jz 0000096f
> >>>>>> [0000096d](02) ebfe jmp 0000096d
> >>>>>> [0000096f](01) 5d pop ebp
> >>>>>> [00000970](01) c3 ret // final state.
> >>>>>> Size in bytes:(0027) [00000970]
> >>>>>
> >>>>> And when Hb simulates this input, it reaches a final state. Therefore H is wrong to report non-halting.
> >>>> A dishonest attempt at the strawman fallacy.
> >>>>
> >>>> Bill up the street did not rob the liquor store I know this because the
> >>>> other guy that I know named Bill was watching TV at the time of the
> >>>> robbery.
> >>>
> >>> So in other words you have no rebuttal because you know that Hb(P,P) == true is correct and proves that H(P,P)==false is incorrect.
> >> Hb(P,P) is off topic because it proves nothing and you know that it
> >> proves nothing and is just a disgusting attempt at a head game.
> >
> > It is not off topic because it directly contradicts your desired result.. That you haven't explained why it's wrong is a confirmation of this.
> >
> >> That is why I focus on the X proves Y
> >>
> >> (X) We can verify that the simulated input to H(P,P) fails to meet the
> >> Linz definition of
> >>
> >> computation that halts … the Turing machine will halt whenever it enters
> >> a final state. (Linz:1990:234)
> >
> > FALSE, because an incorrect simulation is not the same as a turing machine.
> >
> >> (Y) When H(P,P) returns false it is correct.
> >
> > FALSE, as proved by Hb(P,P) returning true for the same input.
> >
> >>
> >> I CAN'T POSSIBLY BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR Y.
> >
> > If the simulated input to H(P,P) fails to meet the definition of halting, then Ha3(N,5) also fails to meet that same definition of halting. So that along shows that your criteria is bogus.
> I can see that you don't want this dialogue to continue.
> I will not tolerate head games.

On 4/12/2022 10:20 PM, Dennis Bush wrote:
> On Tuesday, April 12, 2022 at 11:17:52 PM UTC-4, olcott wrote:
>> On 4/12/2022 10:15 PM, Dennis Bush wrote:
>>> On Tuesday, April 12, 2022 at 11:09:11 PM UTC-4, olcott wrote:
>>>> On 4/12/2022 10:05 PM, Dennis Bush wrote:
>>>>> On Tuesday, April 12, 2022 at 10:59:47 PM UTC-4, olcott wrote:
>>>>>> On 4/12/2022 9:56 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
>>>>>>>> On 4/12/2022 9:13 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
>>>>>>>>>> On 4/12/2022 9:02 PM, Ben wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2022 7:49 PM, Ben wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>>>>>>>>>>>>>> own state.
>>>>>>>>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>>>>>>>>>>>>>> its own final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>>>>>>>>>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>>>>>>>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>>>>>>>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>>>>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>>>>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>>>>>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>>>>>>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>>>>>>>>>>>>>> say and I'll stop quoting it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>>>>>>>>>>>>> like it must be identical to the correct simulation of the input to
>>>>>>>>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>>>>>>>>>>>>>> false?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>>>>>>>>>>>>> reach the final state of this input then we know that it never halts
>>>>>>>>>>>>>> even if everyone in the universe disagrees.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So you plan to keep posting the same sentence in an attempt to take
>>>>>>>>>>>>> the focus off the fact that H is obviously wrong?
>>>>>>>>>>>>
>>>>>>>>>>>> Then you must mean
>>>>>>>>>>>
>>>>>>>>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
>>>>>>>>>>>
>>>>>>>>>>> You should avoid trying to paraphrase other people. Your replies
>>>>>>>>>>> suggest you don't often understand the various points being put to you,
>>>>>>>>>>> so when you try to re-word them the results are usually bogus.
>>>>>>>>>>>
>>>>>>>>>>>> that a correctly simulated input that would never reaches its own
>>>>>>>>>>>> final state is still a computation that halts.
>>>>>>>>>>>
>>>>>>>>>>> I meant what I said. If you are not sure that I meant, asking
>>>>>>>>>>> well-chosen questions about it is the way to go.
>>>>>>>>>>>
>>>>>>>>>> We know [by definition] that a correctly simulated input that would
>>>>>>>>>> never reach its own final state is not a halting computation.
>>>>>>>>>>
>>>>>>>>>> Are you saying that the definition of halting is incorrect?
>>>>>>>>>>
>>>>>>>>>> Are you saying that the correctly simulated input to H(P,P) does reach
>>>>>>>>>> its own final state?
>>>>>>>>>
>>>>>>>>> As a matter of fact it does.
>>>>>>>>>
>>>>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
>>>>>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00000956](01) 55 push ebp
>>>>>>>> [00000957](02) 8bec mov ebp,esp
>>>>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>>>>>> [0000095c](01) 50 push eax // push P
>>>>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [00000960](01) 51 push ecx // push P
>>>>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>>>>>> The above keeps repeating until aborted
>>>>>>>>
>>>>>>>>
>>>>>>>> [00000966](03) 83c408 add esp,+08
>>>>>>>> [00000969](02) 85c0 test eax,eax
>>>>>>>> [0000096b](02) 7402 jz 0000096f
>>>>>>>> [0000096d](02) ebfe jmp 0000096d
>>>>>>>> [0000096f](01) 5d pop ebp
>>>>>>>> [00000970](01) c3 ret // final state.
>>>>>>>> Size in bytes:(0027) [00000970]
>>>>>>>
>>>>>>> And when Hb simulates this input, it reaches a final state. Therefore H is wrong to report non-halting.
>>>>>> A dishonest attempt at the strawman fallacy.
>>>>>>
>>>>>> Bill up the street did not rob the liquor store I know this because the
>>>>>> other guy that I know named Bill was watching TV at the time of the
>>>>>> robbery.
>>>>>
>>>>> So in other words you have no rebuttal because you know that Hb(P,P) == true is correct and proves that H(P,P)==false is incorrect.
>>>> Hb(P,P) is off topic because it proves nothing and you know that it
>>>> proves nothing and is just a disgusting attempt at a head game.
>>>
>>> It is not off topic because it directly contradicts your desired result. That you haven't explained why it's wrong is a confirmation of this.
>>>
>>>> That is why I focus on the X proves Y
>>>>
>>>> (X) We can verify that the simulated input to H(P,P) fails to meet the
>>>> Linz definition of
>>>>
>>>> computation that halts … the Turing machine will halt whenever it enters
>>>> a final state. (Linz:1990:234)
>>>
>>> FALSE, because an incorrect simulation is not the same as a turing machine.
>>>
>>>> (Y) When H(P,P) returns false it is correct.
>>>
>>> FALSE, as proved by Hb(P,P) returning true for the same input.
>>>
>>>>
>>>> I CAN'T POSSIBLY BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR Y.
>>>
>>> If the simulated input to H(P,P) fails to meet the definition of halting, then Ha3(N,5) also fails to meet that same definition of halting. So that along shows that your criteria is bogus.
>> I can see that you don't want this dialogue to continue.
>> I will not tolerate head games.
>
> Translation:
>
> "I will not tolerate arguments that conclusively prove me wrong because I can't bear the though of having wasted the last 17 years".

On Tuesday, April 12, 2022 at 11:23:46 PM UTC-4, olcott wrote:
> On 4/12/2022 10:20 PM, Dennis Bush wrote:
> > On Tuesday, April 12, 2022 at 11:17:52 PM UTC-4, olcott wrote:
> >> On 4/12/2022 10:15 PM, Dennis Bush wrote:
> >>> On Tuesday, April 12, 2022 at 11:09:11 PM UTC-4, olcott wrote:
> >>>> On 4/12/2022 10:05 PM, Dennis Bush wrote:
> >>>>> On Tuesday, April 12, 2022 at 10:59:47 PM UTC-4, olcott wrote:
> >>>>>> On 4/12/2022 9:56 PM, Dennis Bush wrote:
> >>>>>>> On Tuesday, April 12, 2022 at 10:53:05 PM UTC-4, olcott wrote:
> >>>>>>>> On 4/12/2022 9:13 PM, Dennis Bush wrote:
> >>>>>>>>> On Tuesday, April 12, 2022 at 10:06:02 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 4/12/2022 9:02 PM, Ben wrote:
> >>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 4/12/2022 7:49 PM, Ben wrote:
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 4/12/2022 8:06 AM, Ben wrote:
> >>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 4/11/2022 8:02 PM, Ben wrote:
> >>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
> >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
> >>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The truth is not determined by who does or does not agree with
> >>>>>>>>>>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
> >>>>>>>>>>>>>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
> >>>>>>>>>>>>>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
> >>>>>>>>>>>>>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
> >>>>>>>>>>>>>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
> >>>>>>>>>>>>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
> >>>>>>>>>>>>>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
> >>>>>>>>>>>>>>>>>>>>>>> (according to you). That's why H is wrong.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
> >>>>>>>>>>>>>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
> >>>>>>>>>>>>>>>>>>>>>> own state.
> >>>>>>>>>>>>>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
> >>>>>>>>>>>>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
> >>>>>>>>>>>>>>>>>>>>> as well). You a free to retract any of these at any time, but until you
> >>>>>>>>>>>>>>>>>>>>> do, your H is wrong by your own supplied traces.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
> >>>>>>>>>>>>>>>>>>>> its own final state.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
> >>>>>>>>>>>>>>>>> typo: "so H(P,P) == false is wrong"
> >>>>>>>>>>>>>>>>>>> these facts (since they come from you in the first place). Until
> >>>>>>>>>>>>>>>>>>> then, you've told us that your H is wrong.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It is the case that the simulated input never reaches its [00000970]
> >>>>>>>>>>>>>>>>>> machine address, no waffle there merely an easily verified fact.
> >>>>>>>>>>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
> >>>>>>>>>>>>>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
> >>>>>>>>>>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
> >>>>>>>>>>>>>>>>> say and I'll stop quoting it.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The sequence of configurations specified by P(P) intuitively seems
> >>>>>>>>>>>>>>>> like it must be identical to the correct simulation of the input to
> >>>>>>>>>>>>>>>> H(P,P). It turns out that intuition is incorrect.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
> >>>>>>>>>>>>>>> false?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> As long as the correctly simulated input to H(P,P) cannot possibly
> >>>>>>>>>>>>>> reach the final state of this input then we know that it never halts
> >>>>>>>>>>>>>> even if everyone in the universe disagrees.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So you plan to keep posting the same sentence in an attempt to take
> >>>>>>>>>>>>> the focus off the fact that H is obviously wrong?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Then you must mean
> >>>>>>>>>>>
> >>>>>>>>>>> WHOOP! WHOOP! WHOOP! Danger Will Robinson.
> >>>>>>>>>>>
> >>>>>>>>>>> You should avoid trying to paraphrase other people. Your replies
> >>>>>>>>>>> suggest you don't often understand the various points being put to you,
> >>>>>>>>>>> so when you try to re-word them the results are usually bogus..
> >>>>>>>>>>>
> >>>>>>>>>>>> that a correctly simulated input that would never reaches its own
> >>>>>>>>>>>> final state is still a computation that halts.
> >>>>>>>>>>>
> >>>>>>>>>>> I meant what I said. If you are not sure that I meant, asking
> >>>>>>>>>>> well-chosen questions about it is the way to go.
> >>>>>>>>>>>
> >>>>>>>>>> We know [by definition] that a correctly simulated input that would
> >>>>>>>>>> never reach its own final state is not a halting computation.
> >>>>>>>>>>
> >>>>>>>>>> Are you saying that the definition of halting is incorrect?
> >>>>>>>>>>
> >>>>>>>>>> Are you saying that the correctly simulated input to H(P,P) does reach
> >>>>>>>>>> its own final state?
> >>>>>>>>>
> >>>>>>>>> As a matter of fact it does.
> >>>>>>>>>
> >>>>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
> >>>>>>>> it keeps repeating [00000956] to [00000961] until aborted.
> >>>>>>>>
> >>>>>>>> _P()
> >>>>>>>> [00000956](01) 55 push ebp
> >>>>>>>> [00000957](02) 8bec mov ebp,esp
> >>>>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>> [0000095c](01) 50 push eax // push P
> >>>>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>> [00000960](01) 51 push ecx // push P
> >>>>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> >>>>>>>> The above keeps repeating until aborted
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> [00000966](03) 83c408 add esp,+08
> >>>>>>>> [00000969](02) 85c0 test eax,eax
> >>>>>>>> [0000096b](02) 7402 jz 0000096f
> >>>>>>>> [0000096d](02) ebfe jmp 0000096d
> >>>>>>>> [0000096f](01) 5d pop ebp
> >>>>>>>> [00000970](01) c3 ret // final state.
> >>>>>>>> Size in bytes:(0027) [00000970]
> >>>>>>>
> >>>>>>> And when Hb simulates this input, it reaches a final state. Therefore H is wrong to report non-halting.
> >>>>>> A dishonest attempt at the strawman fallacy.
> >>>>>>
> >>>>>> Bill up the street did not rob the liquor store I know this because the
> >>>>>> other guy that I know named Bill was watching TV at the time of the
> >>>>>> robbery.
> >>>>>
> >>>>> So in other words you have no rebuttal because you know that Hb(P,P) == true is correct and proves that H(P,P)==false is incorrect.
> >>>> Hb(P,P) is off topic because it proves nothing and you know that it
> >>>> proves nothing and is just a disgusting attempt at a head game.
> >>>
> >>> It is not off topic because it directly contradicts your desired result. That you haven't explained why it's wrong is a confirmation of this.
> >>>
> >>>> That is why I focus on the X proves Y
> >>>>
> >>>> (X) We can verify that the simulated input to H(P,P) fails to meet the
> >>>> Linz definition of
> >>>>
> >>>> computation that halts … the Turing machine will halt whenever it enters
> >>>> a final state. (Linz:1990:234)
> >>>
> >>> FALSE, because an incorrect simulation is not the same as a turing machine.
> >>>
> >>>> (Y) When H(P,P) returns false it is correct.
> >>>
> >>> FALSE, as proved by Hb(P,P) returning true for the same input.
> >>>
> >>>>
> >>>> I CAN'T POSSIBLY BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR Y.
> >>>
> >>> If the simulated input to H(P,P) fails to meet the definition of halting, then Ha3(N,5) also fails to meet that same definition of halting. So that along shows that your criteria is bogus.
> >> I can see that you don't want this dialogue to continue.
> >> I will not tolerate head games.
> >
> > Translation:
> >
> > "I will not tolerate arguments that conclusively prove me wrong because I can't bear the though of having wasted the last 17 years".
> You are trying to prove that Bill Smith is not guilty because Bill Jones
> didn't do it.