Does anyone know the solution to the problem of halting olcott's Usenet posts?

/Flibble

--
😎

On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
> Does anyone know the solution to the problem of halting olcott's Usenet posts?

Everyone halts. For this case, specifically, there is an unproven
and empirically untested hypothesis about an early halt that occurs
if everyone stops responding.

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

On 02/05/2021 15:03, Kaz Kylheku wrote:
> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>> Does anyone know the solution to the problem of halting olcott's Usenet posts?
>
> Everyone halts. For this case, specifically, there is an unproven
> and empirically untested hypothesis about an early halt that occurs
> if everyone stops responding.
>

We can ask him to stop. We can't prove that he will.

>> Does anyone know the solution to the problem of halting olcott's Usenet posts?

> Everyone halts. For this case, specifically, there is an unproven
> and empirically untested hypothesis about an early halt that occurs
> if everyone stops responding.

The only halting-problem is whether he will halt to post off-topic
issues to comp.lang.c/c++.

On 5/2/2021 9:15 AM, Richard Harnden wrote:
> On 02/05/2021 15:03, Kaz Kylheku wrote:
>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>> Does anyone know the solution to the problem of halting olcott's
>>> Usenet posts?
>>
>> Everyone halts. For this case, specifically, there is an unproven
>> and empirically untested hypothesis about an early halt that occurs
>> if everyone stops responding.
>>
>
> We can ask him to stop.  We can't prove that he will.

The bigger question is when are my reviewers going to provide an
accurate review?

It is a fact that this infinite recursion detection criteria is correct:

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

It is a fact that this criteria correctly decides all calls from
H_Hat() to Halts() are infinitely recursive:

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

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);
}

All of the details including a fresh execution trace are provided here:

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 02/05/2021 14:15, Mr Flibble wrote:
> Does anyone know the solution to the problem of halting olcott's
> Usenet posts?
>
> /Flibble
>
Killfile should work for you. Try it.

I am surprised you are asking this because you like trolls here. I have seen you are responding to that religious nutter on every post he writes about his saviour Mr Christ.

On 5/2/2021 9:03 AM, Kaz Kylheku wrote:
> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>> Does anyone know the solution to the problem of halting olcott's Usenet posts?
>
> Everyone halts. For this case, specifically, there is an unproven
> and empirically untested hypothesis about an early halt that occurs
> if everyone stops responding.
>

I am going to continue to post until an accurate review proves that I a
right or proves that I am wrong. This will remain true even if no one on
this forum ever responds. In this case the reason for posting is to
establish my copyright ownership of every incremental improvement.

Occasional cross-posts are for redundant backup of my key ideas

The bigger question is when are my reviewers going to provide an
accurate review?

It is a fact that this infinite recursion detection criteria is correct:

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

It is a fact that this criteria correctly decides all calls from
H_Hat() to Halts() are infinitely recursive:

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

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);
}

All of the details including a fresh execution trace are provided here:

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 02/05/2021 16:21, olcott wrote:
>
> 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);
> }
>

You keep posting this or something very similar.

That doesn't make it correct. It doesn't matter how many times you
repeat it.

On 5/2/2021 11:11 AM, Richard Harnden wrote:
> On 02/05/2021 16:21, olcott wrote:
>>
>> 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);
>> }
>>
>
> You keep posting this or something very similar.
>
> That doesn't make it correct. It doesn't matter how many times you
> repeat it.
>

This is the part that makes it correct:

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

All of the details including a fresh execution trace are provided here:

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 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>> Does anyone know the solution to the problem of halting olcott's
>>>> Usenet posts?
>>>
>>> Everyone halts. For this case, specifically, there is an unproven
>>> and empirically untested hypothesis about an early halt that occurs
>>> if everyone stops responding.
>>>
>>
>> We can ask him to stop.  We can't prove that he will.
>
> The bigger question is when are my reviewers going to provide an
> accurate review?
>
> It is a fact that this infinite recursion detection criteria is correct:
>
> If the execution trace of function Y() shows:
> function X() is called twice in sequence from the same machine address
> of Y()
> with the same parameters to X()
> with no conditional branch or indexed jump instructions in Y()
> with no function call returns from X()
> then the function call from Y() to X() is infinitely recursive.

This is only "right" from the perspective of an objective observation
that is not involved in the computation, and has no effect on it.

The function X() cannot itself make this observation. X has access to
only its parameters, and its parameters do not carry any information
indicating to X that it has been called twice from the same address
or any such thing. How can they; the parameters are *always the same*.
Therefore they cannot distinguish the first call from the second call
from the third call ...

A function having adcess to past execution traces is an imperative
procedure, which is completely invalid.

It may be possible to rigorously define the halting criteria using
imperative procedures, but it has to be in a completely different way.
(After all, Turing's machine is imperative: it mutates a tape.) You
cannot simply use a definition built around functions and just
substitute procedures into it.

I believe this to be an accurate review of your definition. It points to
flaws in the definition. You have done nothing to correct the definition
to fix the flaws; you simply keep re-asserting the same definition as
correct.

On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>> Usenet posts?
>>>>
>>>> Everyone halts. For this case, specifically, there is an unproven
>>>> and empirically untested hypothesis about an early halt that occurs
>>>> if everyone stops responding.
>>>>
>>>
>>> We can ask him to stop.  We can't prove that he will.
>>
>> The bigger question is when are my reviewers going to provide an
>> accurate review?
>>
>> It is a fact that this infinite recursion detection criteria is correct:
>>
>> If the execution trace of function Y() shows:
>> function X() is called twice in sequence from the same machine address
>> of Y()
>> with the same parameters to X()
>> with no conditional branch or indexed jump instructions in Y()
>> with no function call returns from X()
>> then the function call from Y() to X() is infinitely recursive.
>
> This is only "right" from the perspective of an objective observation
> that is not involved in the computation, and has no effect on it.
>
> The function X() cannot itself make this observation. X has access to
> only its parameters, and its parameters do not carry any information
> indicating to X that it has been called twice from the same address
> or any such thing. How can they; the parameters are *always the same*.
> Therefore they cannot distinguish the first call from the second call
> from the third call ...
>
> A function having adcess to past execution traces is an imperative
> procedure, which is completely invalid.

This is ridiculous, it is just like saying that I must be wrong on the
basis that you really believe that I am wrong.

You have to concretely prove these dogmatic statements. When you attempt
to do this it becomes obvious the the code shown in this link does what
you say is utterly impossible:

All of the details including a fresh execution trace are provided here:

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

> It may be possible to rigorously define the halting criteria using
> imperative procedures, but it has to be in a completely different way.
> (After all, Turing's machine is imperative: it mutates a tape.) You
> cannot simply use a definition built around functions and just
> substitute procedures into it.
>
> I believe this to be an accurate review of your definition. It points to
> flaws in the definition. You have done nothing to correct the definition
> to fix the flaws; you simply keep re-asserting the same definition as
> correct.

You essentially only said that you really believe that I am wrong.
Since I provided an execution trace of code doing what you said is
impossible your assertion that it is impossible is utterly refuted.

What is you motive for making such nutty statements?

--
Copyright 2021 Pete Olcott

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

On 5/2/2021 11:01 AM, Real Troll wrote:
>
>> I am going to continue to post until an accurate review proves that I
>> a right or proves that I am wrong.
>
>
> Don't be sure about that because people will get fed up of you and write
> to your NewsServer provider:
>
> <
> abuse@giganews.com
>>
>
> So be very careful before you test people's tolerance threshold here.
>

Since all of my posts have the analysis of "C" code as their primary
focus, none of my posts can be reasonably construed as off topic for C
or C++ groups.

This is the "C" code that is the primary focus of all of my posts:

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);
}

Can a C/C++ function be defined that correctly decides whether or not
H_Hat((u32)H_Hat) halts?

--
Copyright 2021 Pete Olcott

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

On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>> Usenet posts?
>>>>>
>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>> and empirically untested hypothesis about an early halt that occurs
>>>>> if everyone stops responding.
>>>>>
>>>>
>>>> We can ask him to stop.  We can't prove that he will.
>>>
>>> The bigger question is when are my reviewers going to provide an
>>> accurate review?
>>>
>>> It is a fact that this infinite recursion detection criteria is correct:
>>>
>>> If the execution trace of function Y() shows:
>>> function X() is called twice in sequence from the same machine address
>>> of Y()
>>> with the same parameters to X()
>>> with no conditional branch or indexed jump instructions in Y()
>>> with no function call returns from X()
>>> then the function call from Y() to X() is infinitely recursive.
>>
>> This is only "right" from the perspective of an objective observation
>> that is not involved in the computation, and has no effect on it.
>>
>> The function X() cannot itself make this observation. X has access to
>> only its parameters, and its parameters do not carry any information
>> indicating to X that it has been called twice from the same address
>> or any such thing. How can they; the parameters are *always the same*.
>> Therefore they cannot distinguish the first call from the second call
>> from the third call ...
>>
>> A function having adcess to past execution traces is an imperative
>> procedure, which is completely invalid.
>
> This is ridiculous, it is just like saying that I must be wrong on the
> basis that you really believe that I am wrong.
>
> You have to concretely prove these dogmatic statements. When you attempt

1. You're trying to refute a proof which has a similar structure to the
X and Y arrangement above.

2. In that proof, the entities corresponding to X and Y are functions,
and not imperative procedures. They have no access to some global,
mutating state holding execution traces; such a situation would
violate the conditions of the proof.

3. The proof says, specifically, that X cannot decide the halting situation.
Either X returns the wrong value, or does not return.
(The proof does not say that the situation's halting is not decidable,
as such; it most certainly is decidable.)

You've come along claiming the obvious: "Look, the situation is
decidable. If I supply a definition of X which simply executes Y, then X
does not return because X and Y are caught in an infinite recursion.
If X and Y are implemented in C and the machine code is run on a special
simulator, that simulator can detect the recursion after just a few
calls and call it non-halting.

Okay, so what? That doesn't refute the proof:

1. You have not shown that X can return, with the correct answer,
contrary to what the proof claims. The proof claims that specifically
X cannot decide.

2. The X definition you have provided is not required or specified by
the proof; the proof makes a general claim about all possible
possible X functions that otherwise meet the criteria, including
functions that do not simply execute Y. In other words, the runaway
recursion itself is not a given. It is possible to have definitions
of X which return a value, and for those cases, the proof shows that
for any definition of X which returns, the value is incorrect.
You have not disproved this.

The above is a complete and accurate review of the main ideas in your
work, free of any bias.

If you want a different review, ask other people elsewhere.

If you ask enough people in the world, someone will flatter your ears.

My advice is, though: under no circumstances give them any money
or let them stay in your home.

On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>>> Usenet posts?
>>>>>>
>>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>>> and empirically untested hypothesis about an early halt that occurs
>>>>>> if everyone stops responding.
>>>>>>
>>>>>
>>>>> We can ask him to stop.  We can't prove that he will.
>>>>
>>>> The bigger question is when are my reviewers going to provide an
>>>> accurate review?
>>>>
>>>> It is a fact that this infinite recursion detection criteria is correct:
>>>>
>>>> If the execution trace of function Y() shows:
>>>> function X() is called twice in sequence from the same machine address
>>>> of Y()
>>>> with the same parameters to X()
>>>> with no conditional branch or indexed jump instructions in Y()
>>>> with no function call returns from X()
>>>> then the function call from Y() to X() is infinitely recursive.
>>>
>>> This is only "right" from the perspective of an objective observation
>>> that is not involved in the computation, and has no effect on it.
>>>
>>> The function X() cannot itself make this observation. X has access to
>>> only its parameters, and its parameters do not carry any information
>>> indicating to X that it has been called twice from the same address
>>> or any such thing. How can they; the parameters are *always the same*.
>>> Therefore they cannot distinguish the first call from the second call
>>> from the third call ...
>>>
>>> A function having adcess to past execution traces is an imperative
>>> procedure, which is completely invalid.
>>
>> This is ridiculous, it is just like saying that I must be wrong on the
>> basis that you really believe that I am wrong.
>>
>> You have to concretely prove these dogmatic statements. When you attempt
>

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

> 1. You're trying to refute a proof which has a similar structure to the
> X and Y arrangement above.
>
> 2. In that proof, the entities corresponding to X and Y are functions,
> and not imperative procedures. They have no access to some global,
> mutating state holding execution traces; such a situation would
> violate the conditions of the proof.
>
> 3. The proof says, specifically, that X cannot decide the halting situation.
> Either X returns the wrong value, or does not return.
> (The proof does not say that the situation's halting is not decidable,
> as such; it most certainly is decidable.)
>
> You've come along claiming the obvious: "Look, the situation is
> decidable. If I supply a definition of X which simply executes Y, then X
> does not return because X and Y are caught in an infinite recursion.
> If X and Y are implemented in C and the machine code is run on a special
> simulator, that simulator can detect the recursion after just a few
> calls and call it non-halting.
>
> Okay, so what? That doesn't refute the proof:
>
> 1. You have not shown that X can return, with the correct answer,
> contrary to what the proof claims. The proof claims that specifically
> X cannot decide.
>
> 2. The X definition you have provided is not required or specified by
> the proof; the proof makes a general claim about all possible
> possible X functions that otherwise meet the criteria, including
> functions that do not simply execute Y. In other words, the runaway
> recursion itself is not a given. It is possible to have definitions
> of X which return a value, and for those cases, the proof shows that
> for any definition of X which returns, the value is incorrect.
> You have not disproved this.
>
> The above is a complete and accurate review of the main ideas in your
> work, free of any bias.
>
> If you want a different review, ask other people elsewhere.
>
> If you ask enough people in the world, someone will flatter your ears.
>
> My advice is, though: under no circumstances give them any money
> or let them stay in your home.
>

--
Copyright 2021 Pete Olcott

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

On 5/2/21 11:21 AM, olcott wrote:
> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>> Does anyone know the solution to the problem of halting olcott's
>>>> Usenet posts?
>>>
>>> Everyone halts. For this case, specifically, there is an unproven
>>> and empirically untested hypothesis about an early halt that occurs
>>> if everyone stops responding.
>>>
>>
>> We can ask him to stop.  We can't prove that he will.
>
> The bigger question is when are my reviewers going to provide an
> accurate review?
>
> It is a fact that this infinite recursion detection criteria is correct:
>
> If the execution trace of function Y() shows:
> function X() is called twice in sequence from the same machine address
> of Y()
> with the same parameters to X()
> with no conditional branch or indexed jump instructions in Y()
> with no function call returns from X()
> then the function call from Y() to X() is infinitely recursive.
>
> It is a fact that this criteria correctly  decides all calls from
> H_Hat() to Halts() are infinitely recursive:
>
> If the execution trace of H_Hat() by function Halts() shows:
> (1) Function Halts() is called twice in sequence from the same machine
> address of H_Hat().
> (2) With the same parameters to Halts().
> (3) With no conditional branch or indexed jump instructions in H_Hat().
> (4) With no function call returns from Halts().
> then the function call from H_Hat() to Halts() is infinitely recursive.
>
> 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);
> }
>
> All of the details including a fresh execution trace are provided here:
>
> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>
>

We HAVE given you the accurate review. Your ideas are WRONG.

H_Hat does Halt, as is proven by:

1) Halts is stipulated to meet the requirements of a Halt Decider for
Computation Theory, as used in the proof of Linz and Sipser.

2) Halts is stipulated to return non-Halting on Halts(H_Hat, H_Hat) when
asked directly.

3) H_Hat is stipulated to be built like Linz or Sipser, in that it will
halt when the Halt decider it is built on decides H_Hat’s input is
non-Halting on itself.

4) 1 Means that Halts is a Computation, and will always return the same
answer (or never return an answer) for a given input.

5) H_Hat when run as a Machine will perform the Computation Halts(H_Hat,
H_Hat)

6) by 4 and 2, this means that Halts will return the decision on
non-halting to H_Hat

7) By 3, this means that H_Hat will Halt.

8) This means that H_Hat is a Halting Computation, and because of 2,
Halts is wrong.

You have even posted the trace that shows it as follows:

On 4/27/21 12:55 AM, olcott wrote:
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
> [00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push
> 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call
> 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov
> eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov
> ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call
> 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov
> eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov
> ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call
> 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov
> eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov
> ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call
> 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov
> [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword
> [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret
> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)
>

A Halting Computation can NOT be a non-halting computation

H_Hat does NOT have recursion

Halts NEVER actually calls H_Hat, so there absolutely isn't recursion by
any accurate definition of the word.

Your "trace" isn't even an accurate trace of the execution of any
machine in the system unless you are converting a 'simulation' into a
'call' (which are different actions).

Your whole premise is broken, and the best that can said is that it
appears that you have gotten you logic to a point that your logical
system is now inconsistent.

If you would like to actually show where an error has been made in ANY
of the arguements that show you are wrong, you might be able to make
some progress.

Note, this does NOT mean, try to prove to opposite, but show the real
logical error in why the proof that H_Hat halts is wrong.

You of course can 'PROVE' the opposite given your logic has gone
inconsistent, you need to find logical flaws in the arguement.

On 5/2/21 12:18 PM, olcott wrote:
> On 5/2/2021 11:11 AM, Richard Harnden wrote:
>> On 02/05/2021 16:21, olcott wrote:
>>>
>>> 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);
>>> }
>>>
>>
>> You keep posting this or something very similar.
>>
>> That doesn't make it correct. It doesn't matter how many times you
>> repeat it.
>>
>
> This is the part that makes it correct:
>
> If the execution trace of function Y() shows:
> function X() is called twice in sequence from the same machine address
> of Y()
> with the same parameters to X()
> with no conditional branch or indexed jump instructions in Y()
> with no function call returns from X()
> then the function call from Y() to X() is infinitely recursive.
>
>
>
> All of the details including a fresh execution trace are provided here:
>
> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>
>
>

Your saying to does not make it right. You are using bad definitions.

On 5/2/2021 12:50 PM, olcott wrote:
> On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>>>> Usenet posts?
>>>>>>>
>>>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>>>> and empirically untested hypothesis about an early halt that occurs
>>>>>>> if everyone stops responding.
>>>>>>>
>>>>>>
>>>>>> We can ask him to stop.  We can't prove that he will.
>>>>>
>>>>> The bigger question is when are my reviewers going to provide an
>>>>> accurate review?
>>>>>
>>>>> It is a fact that this infinite recursion detection criteria is
>>>>> correct:
>>>>>
>>>>> If the execution trace of function Y() shows:
>>>>> function X() is called twice in sequence from the same machine address
>>>>> of Y()
>>>>> with the same parameters to X()
>>>>> with no conditional branch or indexed jump instructions in Y()
>>>>> with no function call returns from X()
>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>
>>>> This is only "right" from the perspective of an objective observation
>>>> that is not involved in the computation, and has no effect on it.
>>>>
>>>> The function X() cannot itself make this observation. X has access to
>>>> only its parameters, and its parameters do not carry any information
>>>> indicating to X that it has been called twice from the same address
>>>> or any such thing. How can they; the parameters are *always the same*.
>>>> Therefore they cannot distinguish the first call from the second call
>>>> from the third call ...
>>>>
>>>> A function having adcess to past execution traces is an imperative
>>>> procedure, which is completely invalid.
>>>
>>> This is ridiculous, it is just like saying that I must be wrong on the
>>> basis that you really believe that I am wrong.
>>>
>>> You have to concretely prove these dogmatic statements. When you attempt
>>
>
> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>
>
>
>> 1. You're trying to refute a proof which has a similar structure to the
>>     X and Y arrangement above.
>>
>> 2. In that proof, the entities corresponding to X and Y are functions,
>>     and not imperative procedures. They have no access to some global,
>>     mutating state holding execution traces; such a situation would
>>     violate the conditions of the proof.

So you are saying that an adapted UTM that recognizes the infinite
recursion pattern of its input, stops simulating its input on this
basis, and decides not halting on this input,

IS SIMPLY NOT ALLOWED ?

--
Copyright 2021 Pete Olcott

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

On 02/05/2021 18:55, olcott wrote:
> On 5/2/2021 12:50 PM, olcott wrote:
>> On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>>>>> Usenet posts?
>>>>>>>>
>>>>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>>>>> and empirically untested hypothesis about an early halt that occurs
>>>>>>>> if everyone stops responding.
>>>>>>>>
>>>>>>>
>>>>>>> We can ask him to stop.  We can't prove that he will.
>>>>>>
>>>>>> The bigger question is when are my reviewers going to provide an
>>>>>> accurate review?
>>>>>>
>>>>>> It is a fact that this infinite recursion detection criteria is correct:
>>>>>>
>>>>>> If the execution trace of function Y() shows:
>>>>>> function X() is called twice in sequence from the same machine address
>>>>>> of Y()
>>>>>> with the same parameters to X()
>>>>>> with no conditional branch or indexed jump instructions in Y()
>>>>>> with no function call returns from X()
>>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>
>>>>> This is only "right" from the perspective of an objective observation
>>>>> that is not involved in the computation, and has no effect on it.
>>>>>
>>>>> The function X() cannot itself make this observation. X has access to
>>>>> only its parameters, and its parameters do not carry any information
>>>>> indicating to X that it has been called twice from the same address
>>>>> or any such thing. How can they; the parameters are *always the same*.
>>>>> Therefore they cannot distinguish the first call from the second call
>>>>> from the third call ...
>>>>>
>>>>> A function having adcess to past execution traces is an imperative
>>>>> procedure, which is completely invalid.
>>>>
>>>> This is ridiculous, it is just like saying that I must be wrong on the
>>>> basis that you really believe that I am wrong.
>>>>
>>>> You have to concretely prove these dogmatic statements. When you attempt
>>>
>>
>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>
>>
>>
>>> 1. You're trying to refute a proof which has a similar structure to the
>>>     X and Y arrangement above.
>>>
>>> 2. In that proof, the entities corresponding to X and Y are functions,
>>>     and not imperative procedures. They have no access to some global,
>>>     mutating state holding execution traces; such a situation would
>>>     violate the conditions of the proof.
>
> So you are saying that an adapted UTM that recognizes the infinite recursion
> pattern of its input, stops simulating its input on this basis, and decides not
> halting on this input,
>
> IS SIMPLY NOT ALLOWED ?

Your solution cannot recognize infinite recursion because your solution
disregards branching logic and state that branching logic is predicated on.

In general an algorithm contains LOGIC acting on STATE and the longer you
continue to ignore this fact the more time you will waste (in addition to
wasting the time of people reading and replying to your Usenet posts). I pity
you and your obtuseness.

/Flibble

--
😎

On 5/2/2021 1:14 PM, Mr Flibble wrote:
> On 02/05/2021 18:55, olcott wrote:
>> On 5/2/2021 12:50 PM, olcott wrote:
>>> On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>>>>>> Usenet posts?
>>>>>>>>>
>>>>>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>>>>>> and empirically untested hypothesis about an early halt that
>>>>>>>>> occurs
>>>>>>>>> if everyone stops responding.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We can ask him to stop.  We can't prove that he will.
>>>>>>>
>>>>>>> The bigger question is when are my reviewers going to provide an
>>>>>>> accurate review?
>>>>>>>
>>>>>>> It is a fact that this infinite recursion detection criteria is
>>>>>>> correct:
>>>>>>>
>>>>>>> If the execution trace of function Y() shows:
>>>>>>> function X() is called twice in sequence from the same machine
>>>>>>> address
>>>>>>> of Y()
>>>>>>> with the same parameters to X()
>>>>>>> with no conditional branch or indexed jump instructions in Y()
>>>>>>> with no function call returns from X()
>>>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>>
>>>>>> This is only "right" from the perspective of an objective observation
>>>>>> that is not involved in the computation, and has no effect on it.
>>>>>>
>>>>>> The function X() cannot itself make this observation. X has access to
>>>>>> only its parameters, and its parameters do not carry any information
>>>>>> indicating to X that it has been called twice from the same address
>>>>>> or any such thing. How can they; the parameters are *always the
>>>>>> same*.
>>>>>> Therefore they cannot distinguish the first call from the second call
>>>>>> from the third call ...
>>>>>>
>>>>>> A function having adcess to past execution traces is an imperative
>>>>>> procedure, which is completely invalid.
>>>>>
>>>>> This is ridiculous, it is just like saying that I must be wrong on the
>>>>> basis that you really believe that I am wrong.
>>>>>
>>>>> You have to concretely prove these dogmatic statements. When you
>>>>> attempt
>>>>
>>>
>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>>
>>>
>>>
>>>> 1. You're trying to refute a proof which has a similar structure to the
>>>>     X and Y arrangement above.
>>>>
>>>> 2. In that proof, the entities corresponding to X and Y are functions,
>>>>     and not imperative procedures. They have no access to some global,
>>>>     mutating state holding execution traces; such a situation would
>>>>     violate the conditions of the proof.
>>
>> So you are saying that an adapted UTM that recognizes the infinite
>> recursion pattern of its input, stops simulating its input on this
>> basis, and decides not halting on this input,
>>
>> IS SIMPLY NOT ALLOWED ?
>
> Your solution cannot recognize infinite recursion because your solution
> disregards branching logic and state that branching logic is predicated on.
>
This is provably false:

It is a fact that this infinite recursion detection criteria is correct:
If the execution trace of function Y() shows:
function X() is called twice in sequence from the same machine address
of Y()
with the same parameters to X()
with no conditional branch or indexed jump instructions in Y()
with no function call returns from X()
then the function call from Y() to X() is infinitely recursive.

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

> In general an algorithm contains LOGIC acting on STATE and the longer
> you continue to ignore this fact the more time you will waste (in
> addition to wasting the time of people reading and replying to your
> Usenet posts). I pity you and your obtuseness.
>
> /Flibble
>

--
Copyright 2021 Pete Olcott

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

On 5/2/21 2:18 PM, olcott wrote:
> On 5/2/2021 1:14 PM, Mr Flibble wrote:
>> On 02/05/2021 18:55, olcott wrote:
>>> On 5/2/2021 12:50 PM, olcott wrote:
>>>> On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>
>>>>>>>>>> wrote:
>>>>>>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>>>>>>> Usenet posts?
>>>>>>>>>>
>>>>>>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>>>>>>> and empirically untested hypothesis about an early halt that
>>>>>>>>>> occurs
>>>>>>>>>> if everyone stops responding.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We can ask him to stop.  We can't prove that he will.
>>>>>>>>
>>>>>>>> The bigger question is when are my reviewers going to provide an
>>>>>>>> accurate review?
>>>>>>>>
>>>>>>>> It is a fact that this infinite recursion detection criteria is
>>>>>>>> correct:
>>>>>>>>
>>>>>>>> If the execution trace of function Y() shows:
>>>>>>>> function X() is called twice in sequence from the same machine
>>>>>>>> address
>>>>>>>> of Y()
>>>>>>>> with the same parameters to X()
>>>>>>>> with no conditional branch or indexed jump instructions in Y()
>>>>>>>> with no function call returns from X()
>>>>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>>>
>>>>>>> This is only "right" from the perspective of an objective
>>>>>>> observation
>>>>>>> that is not involved in the computation, and has no effect on it.
>>>>>>>
>>>>>>> The function X() cannot itself make this observation. X has
>>>>>>> access to
>>>>>>> only its parameters, and its parameters do not carry any information
>>>>>>> indicating to X that it has been called twice from the same address
>>>>>>> or any such thing. How can they; the parameters are *always the
>>>>>>> same*.
>>>>>>> Therefore they cannot distinguish the first call from the second
>>>>>>> call
>>>>>>> from the third call ...
>>>>>>>
>>>>>>> A function having adcess to past execution traces is an imperative
>>>>>>> procedure, which is completely invalid.
>>>>>>
>>>>>> This is ridiculous, it is just like saying that I must be wrong on
>>>>>> the
>>>>>> basis that you really believe that I am wrong.
>>>>>>
>>>>>> You have to concretely prove these dogmatic statements. When you
>>>>>> attempt
>>>>>
>>>>
>>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>>>
>>>>
>>>>
>>>>> 1. You're trying to refute a proof which has a similar structure to
>>>>> the
>>>>>     X and Y arrangement above.
>>>>>
>>>>> 2. In that proof, the entities corresponding to X and Y are functions,
>>>>>     and not imperative procedures. They have no access to some global,
>>>>>     mutating state holding execution traces; such a situation would
>>>>>     violate the conditions of the proof.
>>>
>>> So you are saying that an adapted UTM that recognizes the infinite
>>> recursion pattern of its input, stops simulating its input on this
>>> basis, and decides not halting on this input,
>>>
>>> IS SIMPLY NOT ALLOWED ?
>>
>> Your solution cannot recognize infinite recursion because your
>> solution disregards branching logic and state that branching logic is
>> predicated on.
>>
> This is provably false:
>
> It is a fact that this infinite recursion detection criteria is correct:
> If the execution trace of function Y() shows:
> function X() is called twice in sequence from the same machine address
> of Y()
> with the same parameters to X()
> with no conditional branch or indexed jump instructions in Y()
> with no function call returns from X()
> then the function call from Y() to X() is infinitely recursive.
>

No, that is incorrect, because it ignores that the X() called by Y() is
running within the compuation of Y, so any decision it makes is part of
the computation of Y(), thus if X() will terminate the loop, Y() is not
infinitely recursive.

Maybe you are inventing a new definition, but it doesn't apply to this
problem.

>
> If the execution trace of H_Hat() by function Halts() shows:
> (1) Function Halts() is called twice in sequence from the same machine
> address of H_Hat().
> (2) With the same parameters to Halts().
> (3) With no conditional branch or indexed jump instructions in H_Hat().
> (4) With no function call returns from Halts().
> then the function call from H_Hat() to Halts() is infinitely recursive.
>
>
>> In general an algorithm contains LOGIC acting on STATE and the longer
>> you continue to ignore this fact the more time you will waste (in
>> addition to wasting the time of people reading and replying to your
>> Usenet posts). I pity you and your obtuseness.
>>
>> /Flibble
>>
>
>

On 5/2/2021 1:40 PM, Richard Damon wrote:
> On 5/2/21 2:18 PM, olcott wrote:
>> On 5/2/2021 1:14 PM, Mr Flibble wrote:
>>> On 02/05/2021 18:55, olcott wrote:
>>>> On 5/2/2021 12:50 PM, olcott wrote:
>>>>> On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
>>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>>>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>>>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>>>>>>>> Usenet posts?
>>>>>>>>>>>
>>>>>>>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>>>>>>>> and empirically untested hypothesis about an early halt that
>>>>>>>>>>> occurs
>>>>>>>>>>> if everyone stops responding.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We can ask him to stop.  We can't prove that he will.
>>>>>>>>>
>>>>>>>>> The bigger question is when are my reviewers going to provide an
>>>>>>>>> accurate review?
>>>>>>>>>
>>>>>>>>> It is a fact that this infinite recursion detection criteria is
>>>>>>>>> correct:
>>>>>>>>>
>>>>>>>>> If the execution trace of function Y() shows:
>>>>>>>>> function X() is called twice in sequence from the same machine
>>>>>>>>> address
>>>>>>>>> of Y()
>>>>>>>>> with the same parameters to X()
>>>>>>>>> with no conditional branch or indexed jump instructions in Y()
>>>>>>>>> with no function call returns from X()
>>>>>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>>>>
>>>>>>>> This is only "right" from the perspective of an objective
>>>>>>>> observation
>>>>>>>> that is not involved in the computation, and has no effect on it.
>>>>>>>>
>>>>>>>> The function X() cannot itself make this observation. X has
>>>>>>>> access to
>>>>>>>> only its parameters, and its parameters do not carry any information
>>>>>>>> indicating to X that it has been called twice from the same address
>>>>>>>> or any such thing. How can they; the parameters are *always the
>>>>>>>> same*.
>>>>>>>> Therefore they cannot distinguish the first call from the second
>>>>>>>> call
>>>>>>>> from the third call ...
>>>>>>>>
>>>>>>>> A function having adcess to past execution traces is an imperative
>>>>>>>> procedure, which is completely invalid.
>>>>>>>
>>>>>>> This is ridiculous, it is just like saying that I must be wrong on
>>>>>>> the
>>>>>>> basis that you really believe that I am wrong.
>>>>>>>
>>>>>>> You have to concretely prove these dogmatic statements. When you
>>>>>>> attempt
>>>>>>
>>>>>
>>>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>>>>
>>>>>
>>>>>
>>>>>> 1. You're trying to refute a proof which has a similar structure to
>>>>>> the
>>>>>>     X and Y arrangement above.
>>>>>>
>>>>>> 2. In that proof, the entities corresponding to X and Y are functions,
>>>>>>     and not imperative procedures. They have no access to some global,
>>>>>>     mutating state holding execution traces; such a situation would
>>>>>>     violate the conditions of the proof.
>>>>
>>>> So you are saying that an adapted UTM that recognizes the infinite
>>>> recursion pattern of its input, stops simulating its input on this
>>>> basis, and decides not halting on this input,
>>>>
>>>> IS SIMPLY NOT ALLOWED ?
>>>
>>> Your solution cannot recognize infinite recursion because your
>>> solution disregards branching logic and state that branching logic is
>>> predicated on.
>>>
>> This is provably false:
>>
>> It is a fact that this infinite recursion detection criteria is correct:
>> If the execution trace of function Y() shows:
>> function X() is called twice in sequence from the same machine address
>> of Y()
>> with the same parameters to X()
>> with no conditional branch or indexed jump instructions in Y()
>> with no function call returns from X()
>> then the function call from Y() to X() is infinitely recursive.
>>
>
> No, that is incorrect, because it ignores that the X() called by Y() is
> running within the compuation of Y, so any decision it makes is part of
> the computation of Y(), thus if X() will terminate the loop, Y() is not
> infinitely recursive.
>
> Maybe you are inventing a new definition, but it doesn't apply to this
> problem.

To simplify things a bit more...

H_Hat2(u32 P)
{ Simulate(P, P);
}

int main()
{ Simulate(H_Hat2, H_Hat2);
H_Hat2(H_Hat2);
}

Both copmutations specified on line 1 and 2 of main() specify infinite
recursion.

If Simulate() had enough intelligence to see this infinite recursion
so that it could stop its simulation, both lines 1 and 2 of main()
still specify infinite recursion that will never stop unless the
simulation is halted at some point.

>>
>> If the execution trace of H_Hat() by function Halts() shows:
>> (1) Function Halts() is called twice in sequence from the same machine
>> address of H_Hat().
>> (2) With the same parameters to Halts().
>> (3) With no conditional branch or indexed jump instructions in H_Hat().
>> (4) With no function call returns from Halts().
>> then the function call from H_Hat() to Halts() is infinitely recursive.
>>
>>
>>> In general an algorithm contains LOGIC acting on STATE and the longer
>>> you continue to ignore this fact the more time you will waste (in
>>> addition to wasting the time of people reading and replying to your
>>> Usenet posts). I pity you and your obtuseness.
>>>
>>> /Flibble
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

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

On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
> On 5/2/2021 12:50 PM, olcott wrote:
>> On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>>>>> Usenet posts?
>>>>>>>>
>>>>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>>>>> and empirically untested hypothesis about an early halt that occurs
>>>>>>>> if everyone stops responding.
>>>>>>>>
>>>>>>>
>>>>>>> We can ask him to stop.  We can't prove that he will.
>>>>>>
>>>>>> The bigger question is when are my reviewers going to provide an
>>>>>> accurate review?
>>>>>>
>>>>>> It is a fact that this infinite recursion detection criteria is
>>>>>> correct:
>>>>>>
>>>>>> If the execution trace of function Y() shows:
>>>>>> function X() is called twice in sequence from the same machine address
>>>>>> of Y()
>>>>>> with the same parameters to X()
>>>>>> with no conditional branch or indexed jump instructions in Y()
>>>>>> with no function call returns from X()
>>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>
>>>>> This is only "right" from the perspective of an objective observation
>>>>> that is not involved in the computation, and has no effect on it.
>>>>>
>>>>> The function X() cannot itself make this observation. X has access to
>>>>> only its parameters, and its parameters do not carry any information
>>>>> indicating to X that it has been called twice from the same address
>>>>> or any such thing. How can they; the parameters are *always the same*.
>>>>> Therefore they cannot distinguish the first call from the second call
>>>>> from the third call ...
>>>>>
>>>>> A function having adcess to past execution traces is an imperative
>>>>> procedure, which is completely invalid.
>>>>
>>>> This is ridiculous, it is just like saying that I must be wrong on the
>>>> basis that you really believe that I am wrong.
>>>>
>>>> You have to concretely prove these dogmatic statements. When you attempt
>>>
>>
>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>
>>
>>
>>> 1. You're trying to refute a proof which has a similar structure to the
>>>     X and Y arrangement above.
>>>
>>> 2. In that proof, the entities corresponding to X and Y are functions,
>>>     and not imperative procedures. They have no access to some global,
>>>     mutating state holding execution traces; such a situation would
>>>     violate the conditions of the proof.
>
> So you are saying that an adapted UTM that recognizes the infinite
> recursion pattern of its input, stops simulating its input on this
> basis, and decides not halting on this input,
>
> IS SIMPLY NOT ALLOWED ?

To clarify, that is false. Rather:

1) There is a proof that this recognizing machine cannot be the function
identified as X above. This is the proof you're trying to dislodge.

2) The only way the machine can possibly be X is if it conforms to the
requirements imposed on X: that it's a pure function of the two
arguments.

3) You're obviously not conforming to the requiremnts in your
implementation. You are endowing X with "super powers" beyond
what a function is capable of. Without any information in its
arguments, which are always the same, X can tell that it has been
called twice.

The idea is that a refutation of a proof should meet all of its conditions
and demonstrate the conclusion to be false. E.g. if a proof claims that
no element in some set has a certain property, you must show the
existence of such an element, while holding all of the assumptions and
requirements of the proof to be true. For instance, you cannot change
the kind of element that the set is of, or the nature of the property
in consideration. You can't rewrite the proof to suit your refutation.

This idea no way carries any personal bias or dogma coming from me;
it is completly uncontroversial.

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

On 5/2/21 3:30 PM, olcott wrote:
> On 5/2/2021 1:40 PM, Richard Damon wrote:
>> On 5/2/21 2:18 PM, olcott wrote:
>>> On 5/2/2021 1:14 PM, Mr Flibble wrote:
>>>> On 02/05/2021 18:55, olcott wrote:
>>>>> On 5/2/2021 12:50 PM, olcott wrote:
>>>>>> On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
>>>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>>>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>>>>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>>>>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>>>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Does anyone know the solution to the problem of halting
>>>>>>>>>>>>> olcott's
>>>>>>>>>>>>> Usenet posts?
>>>>>>>>>>>>
>>>>>>>>>>>> Everyone halts. For this case, specifically, there is an
>>>>>>>>>>>> unproven
>>>>>>>>>>>> and empirically untested hypothesis about an early halt that
>>>>>>>>>>>> occurs
>>>>>>>>>>>> if everyone stops responding.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We can ask him to stop.  We can't prove that he will.
>>>>>>>>>>
>>>>>>>>>> The bigger question is when are my reviewers going to provide an
>>>>>>>>>> accurate review?
>>>>>>>>>>
>>>>>>>>>> It is a fact that this infinite recursion detection criteria is
>>>>>>>>>> correct:
>>>>>>>>>>
>>>>>>>>>> If the execution trace of function Y() shows:
>>>>>>>>>> function X() is called twice in sequence from the same machine
>>>>>>>>>> address
>>>>>>>>>> of Y()
>>>>>>>>>> with the same parameters to X()
>>>>>>>>>> with no conditional branch or indexed jump instructions in Y()
>>>>>>>>>> with no function call returns from X()
>>>>>>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>>>>>
>>>>>>>>> This is only "right" from the perspective of an objective
>>>>>>>>> observation
>>>>>>>>> that is not involved in the computation, and has no effect on it.
>>>>>>>>>
>>>>>>>>> The function X() cannot itself make this observation. X has
>>>>>>>>> access to
>>>>>>>>> only its parameters, and its parameters do not carry any
>>>>>>>>> information
>>>>>>>>> indicating to X that it has been called twice from the same
>>>>>>>>> address
>>>>>>>>> or any such thing. How can they; the parameters are *always the
>>>>>>>>> same*.
>>>>>>>>> Therefore they cannot distinguish the first call from the second
>>>>>>>>> call
>>>>>>>>> from the third call ...
>>>>>>>>>
>>>>>>>>> A function having adcess to past execution traces is an imperative
>>>>>>>>> procedure, which is completely invalid.
>>>>>>>>
>>>>>>>> This is ridiculous, it is just like saying that I must be wrong on
>>>>>>>> the
>>>>>>>> basis that you really believe that I am wrong.
>>>>>>>>
>>>>>>>> You have to concretely prove these dogmatic statements. When you
>>>>>>>> attempt
>>>>>>>
>>>>>>
>>>>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 1. You're trying to refute a proof which has a similar structure to
>>>>>>> the
>>>>>>>      X and Y arrangement above.
>>>>>>>
>>>>>>> 2. In that proof, the entities corresponding to X and Y are
>>>>>>> functions,
>>>>>>>      and not imperative procedures. They have no access to some
>>>>>>> global,
>>>>>>>      mutating state holding execution traces; such a situation would
>>>>>>>      violate the conditions of the proof.
>>>>>
>>>>> So you are saying that an adapted UTM that recognizes the infinite
>>>>> recursion pattern of its input, stops simulating its input on this
>>>>> basis, and decides not halting on this input,
>>>>>
>>>>> IS SIMPLY NOT ALLOWED ?
>>>>
>>>> Your solution cannot recognize infinite recursion because your
>>>> solution disregards branching logic and state that branching logic is
>>>> predicated on.
>>>>
>>> This is provably false:
>>>
>>> It is a fact that this infinite recursion detection criteria is correct:
>>> If the execution trace of function Y() shows:
>>> function X() is called twice in sequence from the same machine address
>>> of Y()
>>> with the same parameters to X()
>>> with no conditional branch or indexed jump instructions in Y()
>>> with no function call returns from X()
>>> then the function call from Y() to X() is infinitely recursive.
>>>
>>
>> No, that is incorrect, because it ignores that the X() called by Y() is
>> running within the compuation of Y, so any decision it makes is part of
>> the computation of Y(), thus if X() will terminate the loop, Y() is not
>> infinitely recursive.
>>
>> Maybe you are inventing a new definition, but it doesn't apply to this
>> problem.
>
>
> To simplify things a bit more...
>
>
> H_Hat2(u32 P)
> {
>  Simulate(P, P);
> }
>
> int main()
> {
>  Simulate(H_Hat2, H_Hat2);
>  H_Hat2(H_Hat2);
> }
>
> Both copmutations specified on line 1 and 2 of main() specify infinite
> recursion.
>
> If Simulate() had enough intelligence to see this infinite recursion
> so that it could stop its simulation, both lines 1 and 2 of main()
> still specify infinite recursion that will never stop unless the
> simulation is halted at some point.
>

No argument that H_Hat2 using Simulate in non-Halting IF Simulate is a
real simulator. The 'proof' of infinite execution is BASED on the
Simulator not stopping.

If Simulate was 'smart enough to stop Simulating' it wouldn't be a
proper simulator, as it didn't simulate the infinite loop, thus the
infinite loop proofs don't apply.

Since we KNOW (from your stipulations) that Halts will terminate its
simulation of H_Hat, H_Hat is a Halting Computation.

If Simulate is smart enough to stop simulating, then H_Hat2 is too,
since it does stop.

Sounds like a straw-man to me.

The key point is that when H_Hat uses Halts to decide on its input, then
Halts decision that it think the input is non-halting is a decision by
the algorithm of H_Hat to stop, and thus we don't have an infinite
execution in H_Hat, but a finite one.

Using a Simulator that doesn't meet the full definition of a Simulator
doesn't prove anything.

>>>
>>> If the execution trace of H_Hat() by function Halts() shows:
>>> (1) Function Halts() is called twice in sequence from the same machine
>>> address of H_Hat().
>>> (2) With the same parameters to Halts().
>>> (3) With no conditional branch or indexed jump instructions in H_Hat().
>>> (4) With no function call returns from Halts().
>>> then the function call from H_Hat() to Halts() is infinitely recursive.
>>>
>>>
>>>> In general an algorithm contains LOGIC acting on STATE and the longer
>>>> you continue to ignore this fact the more time you will waste (in
>>>> addition to wasting the time of people reading and replying to your
>>>> Usenet posts). I pity you and your obtuseness.
>>>>
>>>> /Flibble
>>>>
>>>
>>>
>>
>
>

On 5/2/2021 2:57 PM, Kaz Kylheku wrote:
> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>> On 5/2/2021 12:50 PM, olcott wrote:
>>> On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>>>>>> Usenet posts?
>>>>>>>>>
>>>>>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>>>>>> and empirically untested hypothesis about an early halt that occurs
>>>>>>>>> if everyone stops responding.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We can ask him to stop.  We can't prove that he will.
>>>>>>>
>>>>>>> The bigger question is when are my reviewers going to provide an
>>>>>>> accurate review?
>>>>>>>
>>>>>>> It is a fact that this infinite recursion detection criteria is
>>>>>>> correct:
>>>>>>>
>>>>>>> If the execution trace of function Y() shows:
>>>>>>> function X() is called twice in sequence from the same machine address
>>>>>>> of Y()
>>>>>>> with the same parameters to X()
>>>>>>> with no conditional branch or indexed jump instructions in Y()
>>>>>>> with no function call returns from X()
>>>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>>
>>>>>> This is only "right" from the perspective of an objective observation
>>>>>> that is not involved in the computation, and has no effect on it.
>>>>>>
>>>>>> The function X() cannot itself make this observation. X has access to
>>>>>> only its parameters, and its parameters do not carry any information
>>>>>> indicating to X that it has been called twice from the same address
>>>>>> or any such thing. How can they; the parameters are *always the same*.
>>>>>> Therefore they cannot distinguish the first call from the second call
>>>>>> from the third call ...
>>>>>>
>>>>>> A function having adcess to past execution traces is an imperative
>>>>>> procedure, which is completely invalid.
>>>>>
>>>>> This is ridiculous, it is just like saying that I must be wrong on the
>>>>> basis that you really believe that I am wrong.
>>>>>
>>>>> You have to concretely prove these dogmatic statements. When you attempt
>>>>
>>>
>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>>
>>>
>>>
>>>> 1. You're trying to refute a proof which has a similar structure to the
>>>>     X and Y arrangement above.
>>>>
>>>> 2. In that proof, the entities corresponding to X and Y are functions,
>>>>     and not imperative procedures. They have no access to some global,
>>>>     mutating state holding execution traces; such a situation would
>>>>     violate the conditions of the proof.
>>
>> So you are saying that an adapted UTM that recognizes the infinite
>> recursion pattern of its input, stops simulating its input on this
>> basis, and decides not halting on this input,
>>
>> IS SIMPLY NOT ALLOWED ?
>
> To clarify, that is false. Rather:
>
> 1) There is a proof that this recognizing machine cannot be the function
> identified as X above. This is the proof you're trying to dislodge.

You stubbornly refuse to acknowledge that a UTM that simulates a machine
that simulates another machine that simulates yet another machine is all
simply data processed by the UTM, thus (as long as it halts) a single
computation.

--
Copyright 2021 Pete Olcott

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

On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
> On 5/2/2021 2:57 PM, Kaz Kylheku wrote:
>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>> On 5/2/2021 12:50 PM, olcott wrote:
>>>> On 5/2/2021 12:39 PM, Kaz Kylheku wrote:
>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>> On 5/2/2021 11:38 AM, Kaz Kylheku wrote:
>>>>>>> On 2021-05-02, olcott <NoOne@NoWhere.com> wrote:
>>>>>>>> On 5/2/2021 9:15 AM, Richard Harnden wrote:
>>>>>>>>> On 02/05/2021 15:03, Kaz Kylheku wrote:
>>>>>>>>>> On 2021-05-02, Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:
>>>>>>>>>>> Does anyone know the solution to the problem of halting olcott's
>>>>>>>>>>> Usenet posts?
>>>>>>>>>>
>>>>>>>>>> Everyone halts. For this case, specifically, there is an unproven
>>>>>>>>>> and empirically untested hypothesis about an early halt that occurs
>>>>>>>>>> if everyone stops responding.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We can ask him to stop.  We can't prove that he will.
>>>>>>>>
>>>>>>>> The bigger question is when are my reviewers going to provide an
>>>>>>>> accurate review?
>>>>>>>>
>>>>>>>> It is a fact that this infinite recursion detection criteria is
>>>>>>>> correct:
>>>>>>>>
>>>>>>>> If the execution trace of function Y() shows:
>>>>>>>> function X() is called twice in sequence from the same machine address
>>>>>>>> of Y()
>>>>>>>> with the same parameters to X()
>>>>>>>> with no conditional branch or indexed jump instructions in Y()
>>>>>>>> with no function call returns from X()
>>>>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>>>
>>>>>>> This is only "right" from the perspective of an objective observation
>>>>>>> that is not involved in the computation, and has no effect on it.
>>>>>>>
>>>>>>> The function X() cannot itself make this observation. X has access to
>>>>>>> only its parameters, and its parameters do not carry any information
>>>>>>> indicating to X that it has been called twice from the same address
>>>>>>> or any such thing. How can they; the parameters are *always the same*.
>>>>>>> Therefore they cannot distinguish the first call from the second call
>>>>>>> from the third call ...
>>>>>>>
>>>>>>> A function having adcess to past execution traces is an imperative
>>>>>>> procedure, which is completely invalid.
>>>>>>
>>>>>> This is ridiculous, it is just like saying that I must be wrong on the
>>>>>> basis that you really believe that I am wrong.
>>>>>>
>>>>>> You have to concretely prove these dogmatic statements. When you attempt
>>>>>
>>>>
>>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>>>
>>>>
>>>>
>>>>> 1. You're trying to refute a proof which has a similar structure to the
>>>>>     X and Y arrangement above.
>>>>>
>>>>> 2. In that proof, the entities corresponding to X and Y are functions,
>>>>>     and not imperative procedures. They have no access to some global,
>>>>>     mutating state holding execution traces; such a situation would
>>>>>     violate the conditions of the proof.
>>>
>>> So you are saying that an adapted UTM that recognizes the infinite
>>> recursion pattern of its input, stops simulating its input on this
>>> basis, and decides not halting on this input,
>>>
>>> IS SIMPLY NOT ALLOWED ?
>>
>> To clarify, that is false. Rather:
>>
>> 1) There is a proof that this recognizing machine cannot be the function
>> identified as X above. This is the proof you're trying to dislodge.
>
> You stubbornly refuse to acknowledge that a UTM that simulates a machine
> that simulates another machine that simulates yet another machine is all
> simply data processed by the UTM, thus (as long as it halts) a single
> computation.

The issue is not that you do not have a computation. You probably do.
You evidently have repeatable test cases; you can execute your rig
repeatedly and obtain the same traces.

The issue is that is simply that the procedure which corresponds to X
is not a function. The application of the imperative procedure X to its
arguments is not a TM, as required.

Given the call X(p, i), we cannot convert X, p and i into the initial
contents of a Turing tape, such that the conditions of your halting
criteria are satisfied.

If we correctly treat X(p, i) as a Turing machine, whereby the tape's
contents depend only on X, p and i, then X cannot tell that it has been
called twice. The definition of X, and the two arguments, are always the
same (this is one of your conditions). Therefore, the tape is always
the same, and the calculation which X performs is always the same.

There is no room for it to be different based on the condition "X is
called twice". If X(p, i) is a Turing machine, it cannot perform one
computation when it's executed the first time and then a different
computation when it's executed a second time.

It may well be that the two (or more) calls to X(p, i) are Turing
machines. You've arranged for them to be different Turing machines
though. You've done that by sneaking in an additional input in the form
of global state. That has to be included on the tape.

The proof requires that the thing corresponding to X(p, i) is one Turing
machine, not two or three different Turing machines distinguished by
additional hidden input.

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