On 09/05/2021 19:27, olcott wrote:
> The latest version of my paper as an attachment.
> I have never done attachments to USENET messages before.
> I am doing this primarily for archival backup purposes.

Until you address the issue of program state and branching logic predicated on
that state your "paper" is worthless and your "refutation" is vacuous.

/Flibble

--
😎

On 5/9/2021 2:01 PM, Mr Flibble wrote:
> On 09/05/2021 19:27, olcott wrote:
>> The latest version of my paper as an attachment.
>> I have never done attachments to USENET messages before.
>> I am doing this primarily for archival backup purposes.
>
> Until you address the issue of program state and branching logic
> predicated on that state your "paper" is worthless and your "refutation"
> is vacuous.
>
> /Flibble
>

That you believe that there is such an issue is an error on your part.
Others will understand that you are mistaken when you elaborate the
details of your position.

If the execution trace of function Y() shows:
(1) function X() is called twice in sequence from the same machine
address of Y()
(2) with the same parameters to X()
(3) with no conditional branch or indexed jump instructions in Y()
(4) with no function call returns from X()
then the function call from Y() to X() is infinitely recursive.

The above criteria does correctly recognize the subset of infinite
recursion / infinitely nested simulation such that Halts() does
correctly decide not halting on the x86 machine language trace of H_Hat().

void H_Hat(u32 P)
{ u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}

http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 09/05/2021 20:11, olcott wrote:
> On 5/9/2021 2:01 PM, Mr Flibble wrote:
>> On 09/05/2021 19:27, olcott wrote:
>>> The latest version of my paper as an attachment.
>>> I have never done attachments to USENET messages before.
>>> I am doing this primarily for archival backup purposes.
>>
>> Until you address the issue of program state and branching logic predicated on
>> that state your "paper" is worthless and your "refutation" is vacuous.
>>
>> /Flibble
>>
>
> That you believe that there is such an issue is an error on your part.
> Others will understand that you are mistaken when you elaborate the details of
> your position.
>
>
> If the execution trace of function Y() shows:
>    (1)  function X() is called twice in sequence from the same machine address
> of Y()
>    (2)  with the same parameters to X()
>    (3)  with no conditional branch or indexed jump instructions in Y()
>    (4)  with no function call returns from X()
> then the function call from Y() to X() is infinitely recursive.
>
> The above criteria does correctly recognize the subset of infinite recursion /
> infinitely nested simulation such that Halts() does correctly decide not halting
> on the x86 machine language trace of H_Hat().
>
> void H_Hat(u32 P)
> {
>   u32 Input_Halts = Halts(P, P);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
> int main()
> {
>   u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
>   Output("Input_Would_Halt = ", Input_Would_Halt);
> }
>
>
> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf

You repeat yourself over and over without adding anything new. I can do the same:

Until you address the issue of program state and branching logic predicated on
that state your "paper" is worthless and your "refutation" is vacuous.

/Flibble

--
😎

On 5/9/2021 3:03 PM, Mr Flibble wrote:
> On 09/05/2021 20:11, olcott wrote:
>> On 5/9/2021 2:01 PM, Mr Flibble wrote:
>>> On 09/05/2021 19:27, olcott wrote:
>>>> The latest version of my paper as an attachment.
>>>> I have never done attachments to USENET messages before.
>>>> I am doing this primarily for archival backup purposes.
>>>
>>> Until you address the issue of program state and branching logic
>>> predicated on that state your "paper" is worthless and your
>>> "refutation" is vacuous.
>>>
>>> /Flibble
>>>
>>
>> That you believe that there is such an issue is an error on your part.
>> Others will understand that you are mistaken when you elaborate the
>> details of your position.
>>
>>
>> If the execution trace of function Y() shows:
>>     (1)  function X() is called twice in sequence from the same
>> machine address of Y()
>>     (2)  with the same parameters to X()
>>     (3)  with no conditional branch or indexed jump instructions in Y()
>>     (4)  with no function call returns from X()
>> then the function call from Y() to X() is infinitely recursive.
>>
>> The above criteria does correctly recognize the subset of infinite
>> recursion / infinitely nested simulation such that Halts() does
>> correctly decide not halting on the x86 machine language trace of
>> H_Hat().
>>
>> void H_Hat(u32 P)
>> {
>>    u32 Input_Halts = Halts(P, P);
>>    if (Input_Halts)
>>      HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>    u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
>>    Output("Input_Would_Halt = ", Input_Would_Halt);
>> }
>>
>>
>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>
>
> You repeat yourself over and over without adding anything new. I can do
> the same:
>
> Until you address the issue of program state and branching logic

Until you explain what you mean about "branching logic" people will not
be able to tell which mistake you are making.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 09/05/2021 21:11, olcott wrote:
> On 5/9/2021 3:03 PM, Mr Flibble wrote:
>> On 09/05/2021 20:11, olcott wrote:
>>> On 5/9/2021 2:01 PM, Mr Flibble wrote:
>>>> On 09/05/2021 19:27, olcott wrote:
>>>>> The latest version of my paper as an attachment.
>>>>> I have never done attachments to USENET messages before.
>>>>> I am doing this primarily for archival backup purposes.
>>>>
>>>> Until you address the issue of program state and branching logic predicated
>>>> on that state your "paper" is worthless and your "refutation" is vacuous.
>>>>
>>>> /Flibble
>>>>
>>>
>>> That you believe that there is such an issue is an error on your part.
>>> Others will understand that you are mistaken when you elaborate the details
>>> of your position.
>>>
>>>
>>> If the execution trace of function Y() shows:
>>>     (1)  function X() is called twice in sequence from the same machine
>>> address of Y()
>>>     (2)  with the same parameters to X()
>>>     (3)  with no conditional branch or indexed jump instructions in Y()
>>>     (4)  with no function call returns from X()
>>> then the function call from Y() to X() is infinitely recursive.
>>>
>>> The above criteria does correctly recognize the subset of infinite recursion
>>> / infinitely nested simulation such that Halts() does correctly decide not
>>> halting on the x86 machine language trace of H_Hat().
>>>
>>> void H_Hat(u32 P)
>>> {
>>>    u32 Input_Halts = Halts(P, P);
>>>    if (Input_Halts)
>>>      HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
>>>    Output("Input_Would_Halt = ", Input_Would_Halt);
>>> }
>>>
>>>
>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>
>>
>>
>> You repeat yourself over and over without adding anything new. I can do the same:
>>
>> Until you address the issue of program state and branching logic
>
> Until you explain what you mean about "branching logic" people will not be able
> to tell which mistake you are making.

Turing machines execute algorithms and algorithms, in the general case, include
branching logic (conditional expressions). Unless you address the general case
rather than the brain-dead specific case of an algorithm that doesn't do any
useful work you are not adding anything of value to the discourse. It is really
fucking simple, dear.

/Flibble

--
😎

On 5/9/2021 3:33 PM, Mr Flibble wrote:
> On 09/05/2021 21:11, olcott wrote:
>> On 5/9/2021 3:03 PM, Mr Flibble wrote:
>>> On 09/05/2021 20:11, olcott wrote:
>>>> On 5/9/2021 2:01 PM, Mr Flibble wrote:
>>>>> On 09/05/2021 19:27, olcott wrote:
>>>>>> The latest version of my paper as an attachment.
>>>>>> I have never done attachments to USENET messages before.
>>>>>> I am doing this primarily for archival backup purposes.
>>>>>
>>>>> Until you address the issue of program state and branching logic
>>>>> predicated on that state your "paper" is worthless and your
>>>>> "refutation" is vacuous.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> That you believe that there is such an issue is an error on your part.
>>>> Others will understand that you are mistaken when you elaborate the
>>>> details of your position.
>>>>
>>>>
>>>> If the execution trace of function Y() shows:
>>>>     (1)  function X() is called twice in sequence from the same
>>>> machine address of Y()
>>>>     (2)  with the same parameters to X()
>>>>     (3)  with no conditional branch or indexed jump instructions in Y()
>>>>     (4)  with no function call returns from X()
>>>> then the function call from Y() to X() is infinitely recursive.
>>>>
>>>> The above criteria does correctly recognize the subset of infinite
>>>> recursion / infinitely nested simulation such that Halts() does
>>>> correctly decide not halting on the x86 machine language trace of
>>>> H_Hat().
>>>>
>>>> void H_Hat(u32 P)
>>>> {
>>>>    u32 Input_Halts = Halts(P, P);
>>>>    if (Input_Halts)
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
>>>>    Output("Input_Would_Halt = ", Input_Would_Halt);
>>>> }
>>>>
>>>>
>>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>>
>>>
>>>
>>>
>>> You repeat yourself over and over without adding anything new. I can
>>> do the same:
>>>
>>> Until you address the issue of program state and branching logic
>>
>> Until you explain what you mean about "branching logic" people will
>> not be able to tell which mistake you are making.
>
> Turing machines execute algorithms and algorithms, in the general case,
> include branching logic (conditional expressions). Unless you address
> the general case rather than the brain-dead specific case of an
> algorithm that doesn't do any useful work you are not adding anything of
> value to the discourse. It is really fucking simple, dear.
>
> /Flibble
>

Now everyone can see your error:

You are saying that correctly refuting the halting proofs is of no value
at all until after I actually solve the halting problem.

Everyone here will be able to see that this understanding is woefully
incorrect. By correctly refuting the halting problem proofs others will
be able to begin working on solving the halting problem now that I have
proved that solving the halting problem is not proved to be impossible.

I changed the follow up to comp.theory

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/9/2021 1:39 PM, olcott wrote:
> On 5/9/2021 3:33 PM, Mr Flibble wrote:
>> On 09/05/2021 21:11, olcott wrote:
>>> On 5/9/2021 3:03 PM, Mr Flibble wrote:
>>>> On 09/05/2021 20:11, olcott wrote:
>>>>> On 5/9/2021 2:01 PM, Mr Flibble wrote:
>>>>>> On 09/05/2021 19:27, olcott wrote:
>>>>>>> The latest version of my paper as an attachment.
>>>>>>> I have never done attachments to USENET messages before.
>>>>>>> I am doing this primarily for archival backup purposes.
>>>>>>
>>>>>> Until you address the issue of program state and branching logic
>>>>>> predicated on that state your "paper" is worthless and your
>>>>>> "refutation" is vacuous.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> That you believe that there is such an issue is an error on your part.
>>>>> Others will understand that you are mistaken when you elaborate the
>>>>> details of your position.
>>>>>
>>>>>
>>>>> If the execution trace of function Y() shows:
>>>>>     (1)  function X() is called twice in sequence from the same
>>>>> machine address of Y()
>>>>>     (2)  with the same parameters to X()
>>>>>     (3)  with no conditional branch or indexed jump instructions in
>>>>> Y()
>>>>>     (4)  with no function call returns from X()
>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>
>>>>> The above criteria does correctly recognize the subset of infinite
>>>>> recursion / infinitely nested simulation such that Halts() does
>>>>> correctly decide not halting on the x86 machine language trace of
>>>>> H_Hat().
>>>>>
>>>>> void H_Hat(u32 P)
>>>>> {
>>>>>    u32 Input_Halts = Halts(P, P);
>>>>>    if (Input_Halts)
>>>>>      HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
>>>>>    Output("Input_Would_Halt = ", Input_Would_Halt);
>>>>> }
>>>>>
>>>>>
>>>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> You repeat yourself over and over without adding anything new. I can
>>>> do the same:
>>>>
>>>> Until you address the issue of program state and branching logic
>>>
>>> Until you explain what you mean about "branching logic" people will
>>> not be able to tell which mistake you are making.
>>
>> Turing machines execute algorithms and algorithms, in the general
>> case, include branching logic (conditional expressions). Unless you
>> address the general case rather than the brain-dead specific case of
>> an algorithm that doesn't do any useful work you are not adding
>> anything of value to the discourse. It is really fucking simple, dear.
>>
>> /Flibble
>>
>
> Now everyone can see your error:
>
> You are saying that correctly refuting the halting proofs is of no value
> at all until after I actually solve the halting problem.

whoosh!

>
> Everyone here will be able to see that this understanding is woefully
> incorrect. By correctly refuting the halting problem proofs others will
> be able to begin working on solving the halting problem now that I have
> proved that solving the halting problem is not proved to be impossible.
>
> I changed the follow up to comp.theory
>

Oh my! You are damaged, big time.

In article <WjWlI.555068$BHVc.471766@fx32.ams4>,
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:

> On 09/05/2021 19:27, olcott wrote:
> > The latest version of my paper as an attachment.
> > I have never done attachments to USENET messages before.
> > I am doing this primarily for archival backup purposes.
>
> Until you address the issue of program state and branching logic predicated
> on
> that state your "paper" is worthless and your "refutation" is vacuous.
>
> /Flibble

Some number theory conjectures can be expressed as turing
machines that either halt on disproved or do not halt if proven.
Let a halting problem decider work on these, and then I'll take
this crap seriouslike.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On 5/9/2021 3:45 PM, Siri Cruise wrote:
> In article <WjWlI.555068$BHVc.471766@fx32.ams4>,
> Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>
>> On 09/05/2021 19:27, olcott wrote:
>>> The latest version of my paper as an attachment.
>>> I have never done attachments to USENET messages before.
>>> I am doing this primarily for archival backup purposes.
>>
>> Until you address the issue of program state and branching logic predicated
>> on
>> that state your "paper" is worthless and your "refutation" is vacuous.
>>
>> /Flibble
>
> Some number theory conjectures can be expressed as turing
> machines that either halt on disproved or do not halt if proven.
> Let a halting problem decider work on these, and then I'll take
> this crap seriouslike.
>

When we base halting on answering questions that currently have no known
answers this does not derive the conventional notion of halting
undecidability. It is not the case that the correct answer is impossible
to provide, we just don't know what that answer is right now.

In any case this does not refute my claim to have refuted the
conventional halting problem proofs.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 09/05/2021 21:54, olcott wrote:
> On 5/9/2021 3:45 PM, Siri Cruise wrote:
>> In article <WjWlI.555068$BHVc.471766@fx32.ams4>,
>>   Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>
>>> On 09/05/2021 19:27, olcott wrote:
>>>> The latest version of my paper as an attachment.
>>>> I have never done attachments to USENET messages before.
>>>> I am doing this primarily for archival backup purposes.
>>>
>>> Until you address the issue of program state and branching logic predicated
>>> on
>>> that state your "paper" is worthless and your "refutation" is vacuous.
>>>
>>> /Flibble
>>
>> Some number theory conjectures can be expressed as turing
>> machines that either halt on disproved or do not halt if proven.
>> Let a halting problem decider work on these, and then I'll take
>> this crap seriouslike.
>>
>
> When we base halting on answering questions that currently have no known answers
> this does not derive the conventional notion of halting undecidability. It is
> not the case that the correct answer is impossible to provide, we just don't
> know what that answer is right now.
>
> In any case this does not refute my claim to have refuted the conventional
> halting problem proofs.

You repeat yourself over and over without adding anything new. I can do the same:

Until you address the issue of program state and branching logic predicated on
that state your "paper" is worthless and your "refutation" is vacuous.

/Flibble

--
😎

In article <0vednVI61bCe0QX9nZ2dnUU7-U3NnZ2d@giganews.com>,
olcott <NoOne@NoWhere.com> wrote:

> When we base halting on answering questions that currently have no known
> answers this does not derive the conventional notion of halting
> undecidability. It is not the case that the correct answer is impossible
> to provide, we just don't know what that answer is right now.

In other words you can solve whether a specific TM will halt
after someone else proves whether it will halt. That's a really
impressive skill.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On 5/9/2021 3:56 PM, Mr Flibble wrote:
> On 09/05/2021 21:54, olcott wrote:
>> On 5/9/2021 3:45 PM, Siri Cruise wrote:
>>> In article <WjWlI.555068$BHVc.471766@fx32.ams4>,
>>>   Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>
>>>> On 09/05/2021 19:27, olcott wrote:
>>>>> The latest version of my paper as an attachment.
>>>>> I have never done attachments to USENET messages before.
>>>>> I am doing this primarily for archival backup purposes.
>>>>
>>>> Until you address the issue of program state and branching logic
>>>> predicated
>>>> on
>>>> that state your "paper" is worthless and your "refutation" is vacuous.
>>>>
>>>> /Flibble
>>>
>>> Some number theory conjectures can be expressed as turing
>>> machines that either halt on disproved or do not halt if proven.
>>> Let a halting problem decider work on these, and then I'll take
>>> this crap seriouslike.
>>>
>>
>> When we base halting on answering questions that currently have no
>> known answers this does not derive the conventional notion of halting
>> undecidability. It is not the case that the correct answer is
>> impossible to provide, we just don't know what that answer is right now.
>>
>> In any case this does not refute my claim to have refuted the
>> conventional halting problem proofs.
>
> You repeat yourself over and over without adding anything new. I can do
> the same:
>
> Until you address the issue of program state and branching logic
> predicated on that state your "paper" is worthless and your "refutation"
> is vacuous.
>
> /Flibble
>

What you mean is that correctly refuting the conventional halting
problem proofs is worthless until I actually solve the halting problem.

Everyone that sufficiently understands the halting problem proofs would
disagree.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/9/2021 4:00 PM, Siri Cruise wrote:
> In article <0vednVI61bCe0QX9nZ2dnUU7-U3NnZ2d@giganews.com>,
> olcott <NoOne@NoWhere.com> wrote:
>
>> When we base halting on answering questions that currently have no known
>> answers this does not derive the conventional notion of halting
>> undecidability. It is not the case that the correct answer is impossible
>> to provide, we just don't know what that answer is right now.
>
> In other words you can solve whether a specific TM will halt
> after someone else proves whether it will halt. That's a really
> impressive skill.
>

I have correctly refuted the conventional halting problem proofs.
If you are saying that is of no consequence people sufficiently
understanding these proofs would disagree.

http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/9/21 5:00 PM, olcott wrote:
> On 5/9/2021 3:56 PM, Mr Flibble wrote:
>> On 09/05/2021 21:54, olcott wrote:
>>> On 5/9/2021 3:45 PM, Siri Cruise wrote:
>>>> In article <WjWlI.555068$BHVc.471766@fx32.ams4>,
>>>>   Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>
>>>>> On 09/05/2021 19:27, olcott wrote:
>>>>>> The latest version of my paper as an attachment.
>>>>>> I have never done attachments to USENET messages before.
>>>>>> I am doing this primarily for archival backup purposes.
>>>>>
>>>>> Until you address the issue of program state and branching logic
>>>>> predicated
>>>>> on
>>>>> that state your "paper" is worthless and your "refutation" is vacuous.
>>>>>
>>>>> /Flibble
>>>>
>>>> Some number theory conjectures can be expressed as turing
>>>> machines that either halt on disproved or do not halt if proven.
>>>> Let a halting problem decider work on these, and then I'll take
>>>> this crap seriouslike.
>>>>
>>>
>>> When we base halting on answering questions that currently have no
>>> known answers this does not derive the conventional notion of halting
>>> undecidability. It is not the case that the correct answer is
>>> impossible to provide, we just don't know what that answer is right now.
>>>
>>> In any case this does not refute my claim to have refuted the
>>> conventional halting problem proofs.
>>
>> You repeat yourself over and over without adding anything new. I can
>> do the same:
>>
>> Until you address the issue of program state and branching logic
>> predicated on that state your "paper" is worthless and your
>> "refutation" is vacuous.
>>
>> /Flibble
>>
>
> What you mean is that correctly refuting the conventional halting
> problem proofs is worthless until I actually solve the halting problem.
>
> Everyone that sufficiently understands the halting problem proofs would
> disagree.
>

Except that you HAVEN'T refuted the one set of conventional halting
problem proofs that you have aimed to, and in fact, providing a
counter-example to them isn't actually refuting them. It just shows that
somewhere the logic is wrong or inconsistent, and the most likely spot
for that will be in your crazy assumptions, so you REALLY need better
ground for them.

To actually refute the proofs, you have to show a logical error in their
argument, and I don't think you would actually recognize a logical
argument if it bit you.

On 5/9/21 5:04 PM, olcott wrote:
> On 5/9/2021 4:00 PM, Siri Cruise wrote:
>> In article <0vednVI61bCe0QX9nZ2dnUU7-U3NnZ2d@giganews.com>,
>>   olcott <NoOne@NoWhere.com> wrote:
>>
>>> When we base halting on answering questions that currently have no known
>>> answers this does not derive the conventional notion of halting
>>> undecidability. It is not the case that the correct answer is impossible
>>> to provide, we just don't know what that answer is right now.
>>
>> In other words you can solve whether a specific TM will halt
>> after someone else proves whether it will halt. That's a really
>> impressive skill.
>>
>
> I have correctly refuted the conventional halting problem proofs.
> If you are saying that is of no consequence people sufficiently
> understanding these proofs would disagree.
>
> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>

No you haven't. You have come up with a convoluted (and flawed) set of
logic with which you make a 'proof' that a machine that can be shown to
halt is actually a non-halting computation.

All you have done is proved your logic system is inconsistant.

olcott <NoOne@NoWhere.com> writes:

> I have correctly refuted the conventional halting problem proofs.

No. In fifteen years you have not been able to show an single error in
any proof.

Your recent posts are not even about the halting problem because you
don't accept that the correct answer for all pairs that denote halting
computations is "yes", and "no" for all other inputs. In fact, you even
doubt that halting entails halting:

"the fact that a computation halts does not entail that it is a halting
computation" Peter Olcott, May 2021.

--
Ben.

On 5/9/2021 5:32 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I have correctly refuted the conventional halting problem proofs.
>
> No. In fifteen years you have not been able to show an single error in
> any proof.
>
> Your recent posts are not even about the halting problem because you
> don't accept that the correct answer for all pairs that denote halting
> computations is "yes", and "no" for all other inputs. In fact, you even
> doubt that halting entails halting:
>
> "the fact that a computation halts does not entail that it is a halting
> computation" Peter Olcott, May 2021.
>

I will try to make my words more precise:

That the computation (of the partial simulation of an infinite loop)
halts does not entail that the infinite loop is a halting computation.

That the computation (of the partial simulation of an X) halts does not
entail that the X is a halting computation.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/9/21 6:57 PM, olcott wrote:
> On 5/9/2021 5:32 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I have correctly refuted the conventional halting problem proofs.
>>
>> No.  In fifteen years you have not been able to show an single error in
>> any proof.
>>
>> Your recent posts are not even about the halting problem because you
>> don't accept that the correct answer for all pairs that denote halting
>> computations is "yes", and "no" for all other inputs.  In fact, you even
>> doubt that halting entails halting:
>>
>>    "the fact that a computation halts does not entail that it is a
>> halting
>>    computation"   Peter Olcott, May 2021.
>>
>
> I will try to make my words more precise:
>
> That the computation (of the partial simulation of an infinite loop)
> halts does not entail that the infinite loop is a halting computation.
>
> That the computation (of the partial simulation of an X) halts does not
> entail that the X is a halting computation.
>

IF your statement is that the stopping of the simulation by the
simulator because it thinks the computation is non-halting does not show
that the computation is halting, I think we all agree to that an no one
has said any different. I think you just get so stuck into thinking
about simulations that when WE talk about actually runnning machines,
you still think about simulations.

Will you positively state that if we run that actual machine itself, and
it halts, that it is a Halting Computation? Lay to rest positively that
you would even consider a different definition?

On 5/9/2021 6:10 PM, Richard Damon wrote:
> On 5/9/21 6:57 PM, olcott wrote:
>> On 5/9/2021 5:32 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I have correctly refuted the conventional halting problem proofs.
>>>
>>> No.  In fifteen years you have not been able to show an single error in
>>> any proof.
>>>
>>> Your recent posts are not even about the halting problem because you
>>> don't accept that the correct answer for all pairs that denote halting
>>> computations is "yes", and "no" for all other inputs.  In fact, you even
>>> doubt that halting entails halting:
>>>
>>>    "the fact that a computation halts does not entail that it is a
>>> halting
>>>    computation"   Peter Olcott, May 2021.
>>>
>>
>> I will try to make my words more precise:
>>
>> That the computation (of the partial simulation of an infinite loop)
>> halts does not entail that the infinite loop is a halting computation.
>>
>> That the computation (of the partial simulation of an X) halts does not
>> entail that the X is a halting computation.
>>
>
> IF your statement is that the stopping of the simulation by the
> simulator because it thinks the computation is non-halting does not show
> that the computation is halting, I think we all agree to that an no one
> has said any different. I think you just get so stuck into thinking
> about simulations that when WE talk about actually runnning machines,
> you still think about simulations.
>
>
> Will you positively state that if we run that actual machine itself, and
> it halts, that it is a Halting Computation? Lay to rest positively that
> you would even consider a different definition?
>

**My whole proof is boiled down to as simple as this:**
When the execution trace of H_Hat() correctly matches a correct
non-halting behavior pattern then the decision of non-halting is
impossibly incorrect.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/9/21 7:38 PM, olcott wrote:
> On 5/9/2021 6:10 PM, Richard Damon wrote:

>> IF your statement is that the stopping of the simulation by the
>> simulator because it thinks the computation is non-halting does not show
>> that the computation is halting, I think we all agree to that an no one
>> has said any different. I think you just get so stuck into thinking
>> about simulations that when WE talk about actually runnning machines,
>> you still think about simulations.
>>
>>
>> Will you positively state that if we run that actual machine itself, and
>> it halts, that it is a Halting Computation? Lay to rest positively that
>> you would even consider a different definition?
>>
>
> **My whole proof is boiled down to as simple as this:**
> When the execution trace of H_Hat() correctly matches a correct
> non-halting behavior pattern then the decision of non-halting is
> impossibly incorrect.
>
>

BUT, do you agree that if when we run a machine itself, that if it
Halts, then it is a Halting Computation?

Without you agreeing to that, then you phrase isn't properly defined,
because the meaning of a CORRECT non-halting pattern needs to be tested
with a proper definition of Halting.

With correct definitions, you statement is a tautology, as by definition
making a correct decision is correct, but if you apply wrong definitions
then it is an error DUE to the wrong definitions.

Your evasion of making that statement puts a shadow on you whole
argument which is largely based on rhetoric, and not logic.

On 5/9/2021 7:07 PM, Richard Damon wrote:
> On 5/9/21 7:38 PM, olcott wrote:
>> On 5/9/2021 6:10 PM, Richard Damon wrote:
>
>>> IF your statement is that the stopping of the simulation by the
>>> simulator because it thinks the computation is non-halting does not show
>>> that the computation is halting, I think we all agree to that an no one
>>> has said any different. I think you just get so stuck into thinking
>>> about simulations that when WE talk about actually runnning machines,
>>> you still think about simulations.
>>>
>>>
>>> Will you positively state that if we run that actual machine itself, and
>>> it halts, that it is a Halting Computation? Lay to rest positively that
>>> you would even consider a different definition?
>>>
>>
>> **My whole proof is boiled down to as simple as this:**
>> When the execution trace of H_Hat() correctly matches a correct
>> non-halting behavior pattern then the decision of non-halting is
>> impossibly incorrect.
>>
>>
>
> BUT, do you agree that if when we run a machine itself, that if it
> Halts, then it is a Halting Computation?

When any computation only halts because it was aborted at some point
then this aborted computation <is not> a halting computation.
H_Hat(H_Hat) only halts because it is aborted at some point.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 2021-05-10, olcott <NoOne@NoWhere.com> wrote:
> On 5/9/2021 7:07 PM, Richard Damon wrote:
>> On 5/9/21 7:38 PM, olcott wrote:
>>> On 5/9/2021 6:10 PM, Richard Damon wrote:
>>
>>>> IF your statement is that the stopping of the simulation by the
>>>> simulator because it thinks the computation is non-halting does not show
>>>> that the computation is halting, I think we all agree to that an no one
>>>> has said any different. I think you just get so stuck into thinking
>>>> about simulations that when WE talk about actually runnning machines,
>>>> you still think about simulations.
>>>>
>>>>
>>>> Will you positively state that if we run that actual machine itself, and
>>>> it halts, that it is a Halting Computation? Lay to rest positively that
>>>> you would even consider a different definition?
>>>>
>>>
>>> **My whole proof is boiled down to as simple as this:**
>>> When the execution trace of H_Hat() correctly matches a correct
>>> non-halting behavior pattern then the decision of non-halting is
>>> impossibly incorrect.
>>>
>>>
>>
>> BUT, do you agree that if when we run a machine itself, that if it
>> Halts, then it is a Halting Computation?
>
> When any computation only halts because it was aborted at some point
> then this aborted computation <is not> a halting computation.
> H_Hat(H_Hat) only halts because it is aborted at some point.

That simply isn't true. Halts puts together a simulation, performs
it step by step while checking some condition and at some point it
stops doing that, and returns. It isn't aborted; it returns normally due
to its own decision.

Halts returns 0 to H_Hat, and then H_Hat bails of its own accord.

Nothing is aborted, just a simulation inside Halts.

Moreover, the abort of the simulation, or the conclusion drawn from it,
is itself incorrect. Inside the simulation, H_Hat is also calling
Halts, and that Halts will return 0 if it is stepped far enough.
What is aborted is not a non-terminating calculation. Rather, a
terminating calculation is prematurely aborted.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 5/9/21 8:11 PM, olcott wrote:
> On 5/9/2021 7:07 PM, Richard Damon wrote:
>> On 5/9/21 7:38 PM, olcott wrote:
>>> On 5/9/2021 6:10 PM, Richard Damon wrote:
>>
>>>> IF your statement is that the stopping of the simulation by the
>>>> simulator because it thinks the computation is non-halting does not
>>>> show
>>>> that the computation is halting, I think we all agree to that an no one
>>>> has said any different. I think you just get so stuck into thinking
>>>> about simulations that when WE talk about actually runnning machines,
>>>> you still think about simulations.
>>>>
>>>>
>>>> Will you positively state that if we run that actual machine itself,
>>>> and
>>>> it halts, that it is a Halting Computation? Lay to rest positively that
>>>> you would even consider a different definition?
>>>>
>>>
>>> **My whole proof is boiled down to as simple as this:**
>>> When the execution trace of H_Hat() correctly matches a correct
>>> non-halting behavior pattern then the decision of non-halting is
>>> impossibly incorrect.
>>>
>>>
>>
>> BUT, do you agree that if when we run a machine itself, that if it
>> Halts, then it is a Halting Computation?
>
> When any computation only halts because it was aborted at some point
> then this aborted computation <is not> a halting computation.
> H_Hat(H_Hat) only halts because it is aborted at some point.
>

FALSE.

H_Hat(H_Hat) when run as a machine has NOTHING that CAN abort it.

Remember, I said H_Hat run as a machine, not as an input to Halts.

It calls Halts(H_Hat, H_Hat) which then simulates the machine
description which it is given, which just happens to match the
description of the machine it is running in, and Halts will abort its
simulation of that description. IT can NOT abort the machine that called
it, at least not a be a computation and a decider, at least if H_Hat was
built by the instructions,

So which is you lie:

Are you intentionally conflating that it aborted a simulation and trying
to say that this somehow automagically aborts the actual machine that
was running that called it?

or

Is Halts NOT a decider, because it NEVER returned its answer in the
manner required?

or

Is Halts NOT even a computation, doing different things based on
different environments of being called, and thus not even a Turing
Machine Equivalent?

Please explain which ERROR you are making?

On 5/9/2021 7:25 PM, Kaz Kylheku wrote:
> On 2021-05-10, olcott <NoOne@NoWhere.com> wrote:
>> On 5/9/2021 7:07 PM, Richard Damon wrote:
>>> On 5/9/21 7:38 PM, olcott wrote:
>>>> On 5/9/2021 6:10 PM, Richard Damon wrote:
>>>
>>>>> IF your statement is that the stopping of the simulation by the
>>>>> simulator because it thinks the computation is non-halting does not show
>>>>> that the computation is halting, I think we all agree to that an no one
>>>>> has said any different. I think you just get so stuck into thinking
>>>>> about simulations that when WE talk about actually runnning machines,
>>>>> you still think about simulations.
>>>>>
>>>>>
>>>>> Will you positively state that if we run that actual machine itself, and
>>>>> it halts, that it is a Halting Computation? Lay to rest positively that
>>>>> you would even consider a different definition?
>>>>>
>>>>
>>>> **My whole proof is boiled down to as simple as this:**
>>>> When the execution trace of H_Hat() correctly matches a correct
>>>> non-halting behavior pattern then the decision of non-halting is
>>>> impossibly incorrect.
>>>>
>>>>
>>>
>>> BUT, do you agree that if when we run a machine itself, that if it
>>> Halts, then it is a Halting Computation?
>>
>> When any computation only halts because it was aborted at some point
>> then this aborted computation <is not> a halting computation.
>> H_Hat(H_Hat) only halts because it is aborted at some point.
>
> That simply isn't true.

The more you continue to dodge this point the less honest you prove to be:

*My whole proof is boiled down to as simple as this:*
When the execution trace of H_Hat() correctly matches a correct
non-halting behavior pattern then the decision of non-halting is
impossibly incorrect.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/9/2021 7:30 PM, Richard Damon wrote:
> On 5/9/21 8:11 PM, olcott wrote:
>> On 5/9/2021 7:07 PM, Richard Damon wrote:
>>> On 5/9/21 7:38 PM, olcott wrote:
>>>> On 5/9/2021 6:10 PM, Richard Damon wrote:
>>>
>>>>> IF your statement is that the stopping of the simulation by the
>>>>> simulator because it thinks the computation is non-halting does not
>>>>> show
>>>>> that the computation is halting, I think we all agree to that an no one
>>>>> has said any different. I think you just get so stuck into thinking
>>>>> about simulations that when WE talk about actually runnning machines,
>>>>> you still think about simulations.
>>>>>
>>>>>
>>>>> Will you positively state that if we run that actual machine itself,
>>>>> and
>>>>> it halts, that it is a Halting Computation? Lay to rest positively that
>>>>> you would even consider a different definition?
>>>>>
>>>>
>>>> **My whole proof is boiled down to as simple as this:**
>>>> When the execution trace of H_Hat() correctly matches a correct
>>>> non-halting behavior pattern then the decision of non-halting is
>>>> impossibly incorrect.
>>>>
>>>>
>>>
>>> BUT, do you agree that if when we run a machine itself, that if it
>>> Halts, then it is a Halting Computation?
>>
>> When any computation only halts because it was aborted at some point
>> then this aborted computation <is not> a halting computation.
>> H_Hat(H_Hat) only halts because it is aborted at some point.
>>
>
> FALSE.
>
> H_Hat(H_Hat) when run as a machine has NOTHING that CAN abort it.
>
void H_Hat(u32 P)
{

// Halts correctly decides that H_Hat(H_Hat)
// specifies Infinitely recursive simulation
// and it is aborted right here.

u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein