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

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