Olcott

325 views
Skip to first unread message

Mr Flibble

unread,
Aug 17, 2022, 12:46:40 PMAug 17
to
Olcott, which of the following do you think is more likely?

1) Olcott is correct and everybody else is wrong.
2) Olcott is wrong and everybody else is correct.

Which one is more likely hasn't changed for all the years you've been
attempting to shill your simulating halting decider. I find it amusing
that I came up with, in less than 24 hours, a simulating halting
decider that doesn't have the flaws your SHD has.

/Flibble

olcott

unread,
Aug 17, 2022, 1:03:41 PMAug 17
to
Prior to Pythagoras there was a universal consensus that the Earth was
flat.


It was around 500 B.C. that Pythagoras first proposed a spherical Earth,
mainly on aesthetic grounds rather than on any physical evidence. Like
many Greeks, he believed the sphere was the most perfect shape. Possibly
the first to propose a spherical Earth based on actual physical evidence
was Aristotle (384-322 B.C.), who listed several arguments for a
spherical Earth: ships disappear hull first when they sail over the
horizon, Earth casts a round shadow on the moon during a lunar eclipse,
and different constellations are visible at different latitudes.
https://www.aps.org/publications/apsnews/200606/history.cfm


--
Copyright 2022 Pete Olcott

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

Mr Flibble

unread,
Aug 17, 2022, 1:06:47 PMAug 17
to
On Wed, 17 Aug 2022 12:03:35 -0500
olcott <No...@NoWhere.com> wrote:

> On 8/17/2022 11:46 AM, Mr Flibble wrote:
> > Olcott, which of the following do you think is more likely?
> >
> > 1) Olcott is correct and everybody else is wrong.
> > 2) Olcott is wrong and everybody else is correct.
> >
> > Which one is more likely hasn't changed for all the years you've
> > been attempting to shill your simulating halting decider. I find
> > it amusing that I came up with, in less than 24 hours, a simulating
> > halting decider that doesn't have the flaws your SHD has.
> >
> > /Flibble
> >
>
> Prior to Pythagoras there was a universal consensus that the Earth
> was flat.
>
>
> It was around 500 B.C. that Pythagoras first proposed a spherical
> Earth, mainly on aesthetic grounds rather than on any physical
> evidence. Like many Greeks, he believed the sphere was the most
> perfect shape. Possibly the first to propose a spherical Earth based
> on actual physical evidence was Aristotle (384-322 B.C.), who listed
> several arguments for a spherical Earth: ships disappear hull first
> when they sail over the horizon, Earth casts a round shadow on the
> moon during a lunar eclipse, and different constellations are visible
> at different latitudes.
> https://www.aps.org/publications/apsnews/200606/history.cfm

So you are claiming to be a modern-day Pythagoras? I suggest you read
the following:

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

/Flibble

Jeff Barnett

unread,
Aug 17, 2022, 5:47:27 PMAug 17
to
On 8/17/2022 11:03 AM, olcott wrote:
> On 8/17/2022 11:46 AM, Mr Flibble wrote:
>> Olcott, which of the following do you think is more likely?
>>
>> 1) Olcott is correct and everybody else is wrong.
>> 2) Olcott is wrong and everybody else is correct.
>>
>> Which one is more likely hasn't changed for all the years you've been
>> attempting to shill your simulating halting decider.  I find it amusing
>> that I came up with, in less than 24 hours, a simulating halting
>> decider that doesn't have the flaws your SHD has.
>>
>> /Flibble
>>
>
> Prior to Pythagoras there was a universal consensus that the Earth was
> flat.
>
>
> It was around 500 B.C. that Pythagoras first proposed a spherical Earth,
> mainly on aesthetic grounds rather than on any physical evidence. Like
> many Greeks, he believed the sphere was the most perfect shape. Possibly
> the first to propose a spherical Earth based on actual physical evidence
> was Aristotle (384-322 B.C.), who listed several arguments for a
> spherical Earth: ships disappear hull first when they sail over the
> horizon, Earth casts a round shadow on the moon during a lunar eclipse,
> and different constellations are visible at different latitudes.
> https://www.aps.org/publications/apsnews/200606/history.cfm

So that is some of the many reasons that you are nothing like a
modern-day Pythagoras - no results, now or ever, that anyone would care
about.

Another reason is that he would not eat beans and you do.

It seems that every one of your health infractions directly deadens your
brain. You really must do a better job of taking care of yourself. We
folks out here are hoping this trend stops before your head is solid Jello.
--
Jeff Barnett

Fred. Zwarts

unread,
Aug 20, 2022, 11:01:38 AMAug 20
to
Op 17.aug..2022 om 18:46 schreef Mr Flibble:
I have been following these discussions for many months now. I have a
strong impression that there is little progress. It seems that people
are running in circles. I am not an expert in this field. Maybe it helps
if a non-expert tries to summarize the discussion. Please, be patient
when correcting me if I make any mistake.

First the problem this is al about:
In computation theory we can denote a program with X and its input with
Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite
number of steps, but another program X and/or input Y may not halt in a
finite number of steps. The question is, is it possible to create a
program H that when given any program X with its input Y can tell in a
finite number of steps whether X(Y) halts or not? In other words, will
H(X,Y) always halt after a finite number of steps with the correct
answer for any X and Y?

I hope that this is a correct formulation of the problem.

The classical proof that it is not possible is the idea that it is
always possible to create a program P that uses H, with itself as input,
but behaves opposite to what H returns. In a C-like language it would be
something like:

void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

If there would be a hypothetical non-simulating non-aborting H, which
would always halts with the correct answer, then it is clear that there
would be a contradiction if we ask H about P with H(P,P). Because there
are only three possibilities:
1. If H would return true (halting) in a finite number of steps, then P
would start an endless loop, so H(P,P) does not halt in a finite number
of steps.
2. If H would return false (non-halting) in a finite number of steps,
then P returns immediately, so H returns a wrong result.
3. If H does not return, then it does not return in a finite number of
steps, so it is not the H where the problem asked for.

I think everybody agrees up to this point.

Now Olcott has created a simulating aborting H, which, when given P with
input P [so H(P,P)], creates a trace of the execution and at the point
where P calls H, it uses the following logic: If H were the hypothetical
non-aborting H, then an infinite recursion would happen at this point.
Therefore, Olcott's simulating H aborts the simulation and returns false
(0).

Does everybody still agree up to this point?

Now the opinions diverge.
Olcott thinks that his H gives the correct answer that P would not halt
when P would call the hypothetical non-aborting H, so, it must also be
the correct answer when P actually calls the actual aborting H.

Others have a different opinion and argue that P does not call the
hypothetical non-aborting H, but the actual aborting H, which does not
go in infinite recursion, but returns false in a finite number of steps.
Therefore, H's result is wrong.

Is this a correct summary of the disagreement? If not, please, tell me
where the summary failed. Maybe we can then find the point of divergence
of opinions easier.

olcott

unread,
Aug 20, 2022, 11:24:07 AMAug 20
to
*You did a very good job summing this up*
The key nuance of divergence is that halting means that when H(P,P)
correctly simulates its input that this input would reach the "return"
instruction (final state) of P. H(P,P) correctly determines that its
correct simulation of its input would never reach the "return"
instruction of P.

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

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

When-so-ever the correct partial simulation of a machine description
correctly matches a correct infinite behavior pattern then it is certain
that this machine description specifies infinite behavior.

In other words the SHD decider correctly predicts that its correct and
complete simulation of its input would never reach the final state of
this input.

*HERE IS THE SIMPLEST CASE OF THAT*
void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0((u32)Infinite_Loop));
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

> Others have a different opinion and argue that P does not call the
> hypothetical non-aborting H, but the actual aborting H, which does not
> go in infinite recursion, but returns false in a finite number of steps.
> Therefore, H's result is wrong.
>
> Is this a correct summary of the disagreement? If not, please, tell me
> where the summary failed. Maybe we can then find the point of divergence
> of opinions easier.
>


Mr Flibble

unread,
Aug 20, 2022, 2:32:14 PMAug 20
to
And here is a case where your H gets the answer wrong:

void Px(void (*x)())
{
(void) H(x, x);
return;
}

Px always halts if H returns to Px (and a valid halt decider must
always return a decision to its caller).

/Flibble

Richard Damon

unread,
Aug 20, 2022, 2:32:59 PMAug 20
to
The key point is the conventional proof doesn't assume a
"Non-simulating" decider, but ANY decider, no matter how it determines
its answer.

The key error of Olcott, is the mistaken idea that just because H
happens to be a simulating Halt Decider, it gets to change the criteria
that it needs to decide on, and rather than being does the computation
the input represents [that is M(x) for a call to H(M,x) ], halt or never
halt, but can we decide instead of on a did "H need to abort its
simulation" criteria, and that this "need" affect EVERY COPY of H that
exists in the world. (He confuses that last point by mashing the code of
the decided program and the decider into a single program and having the
decided program share code with the decider instead of being an
independent copy, as it would need to be to actually implement as Turing
Machines.

Because of this, H is actually deciding on the wrong input, the H that
aborts is actually reporting the results of the input program P built on
the H that doesn't abort, which is a different input then the input
program P built on the H that does abort.

olcott

unread,
Aug 20, 2022, 2:50:22 PMAug 20
to
This one uses my prior version of H named HH where the infinitely
recursive simulation is easier to see.

void Px(void (*x)())
{
(void) HH(x, x);
return;
}

int main()
{
Output("Input_Halts = ", HH(Px, Px));
}

_Px()
[000010b2](01) 55 push ebp
[000010b3](02) 8bec mov ebp,esp
[000010b5](03) 8b4508 mov eax,[ebp+08]
[000010b8](01) 50 push eax
[000010b9](03) 8b4d08 mov ecx,[ebp+08]
[000010bc](01) 51 push ecx
[000010bd](05) e8e0fbffff call 00000ca2
[000010c2](03) 83c408 add esp,+08
[000010c5](01) 5d pop ebp
[000010c6](01) c3 ret
Size in bytes:(0021) [000010c6]

_main()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](05) 68b2100000 push 000010b2
[000010da](05) 68b2100000 push 000010b2
[000010df](05) e8befbffff call 00000ca2
[000010e4](03) 83c408 add esp,+08
[000010e7](01) 50 push eax
[000010e8](05) 6863040000 push 00000463
[000010ed](05) e890f3ffff call 00000482
[000010f2](03) 83c408 add esp,+08
[000010f5](02) 33c0 xor eax,eax
[000010f7](01) 5d pop ebp
[000010f8](01) c3 ret
Size in bytes:(0039) [000010f8]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00101b8d][00000000] 55 push ebp
[000010d3][00101b8d][00000000] 8bec mov ebp,esp
[000010d5][00101b89][000010b2] 68b2100000 push 000010b2
[000010da][00101b85][000010b2] 68b2100000 push 000010b2
[000010df][00101b81][000010e4] e8befbffff call 00000ca2
New slave_stack at:101c31

Begin Local Halt Decider Simulation Execution Trace Stored at:111c39
[000010b2][00111c25][00111c29] 55 push ebp
[000010b3][00111c25][00111c29] 8bec mov ebp,esp
[000010b5][00111c25][00111c29] 8b4508 mov eax,[ebp+08]
[000010b8][00111c21][000010b2] 50 push eax // push Px
[000010b9][00111c21][000010b2] 8b4d08 mov ecx,[ebp+08]
[000010bc][00111c1d][000010b2] 51 push ecx // push Px
[000010bd][00111c19][000010c2] e8e0fbffff call 00000ca2 // call HH
New slave_stack at:14c659
[000010b2][0015c64d][0015c651] 55 push ebp
[000010b3][0015c64d][0015c651] 8bec mov ebp,esp
[000010b5][0015c64d][0015c651] 8b4508 mov eax,[ebp+08]
[000010b8][0015c649][000010b2] 50 push eax // push Px
[000010b9][0015c649][000010b2] 8b4d08 mov ecx,[ebp+08]
[000010bc][0015c645][000010b2] 51 push ecx // push Px
[000010bd][0015c641][000010c2] e8e0fbffff call 00000ca2 // call HH
*Local Halt Decider: Infinite Recursion Detected Simulation Stopped*

*When HH(Px,Px) simulates its input it sees that*
(1) Function HH(Px,Px) is called twice in sequence from the same machine
address of Px().
(2) With the same arguments to HH(Px,Px).
(3) With no control flow instructions between the invocation of Px() and
its call to HH(Px,Px) that could possibly escape repeated simulations.

[000010e4][00101b8d][00000000] 83c408 add esp,+08
[000010e7][00101b89][00000000] 50 push eax
[000010e8][00101b85][00000463] 6863040000 push 00000463
[000010ed][00101b85][00000463] e890f3ffff call 00000482
Input_Halts = 0
[000010f2][00101b8d][00000000] 83c408 add esp,+08
[000010f5][00101b8d][00000000] 33c0 xor eax,eax
[000010f7][00101b91][00000018] 5d pop ebp
[000010f8][00101b95][00000000] c3 ret
Number of Instructions Executed(15322) == 229 Pages

Mr Flibble

unread,
Aug 20, 2022, 2:52:48 PMAug 20
to
On Sat, 20 Aug 2022 13:50:15 -0500
All your trace is doing is confirming that H gets the answer wrong, Px
halts. Until you resolve this false positive you do not have a valid
SHD.

/Flibble

olcott

unread,
Aug 20, 2022, 3:00:50 PMAug 20
to
It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.

That you and others reject this when it is applied to my simulating halt
decider implicitly rejects the notion of a UTM. Since you and others do
accept the notion of a UTM, I have just proven that your reasoning is
incoherent and/or inconsistent.

Whenever the simulating halt decider correctly predicts that its correct
and complete simulation of its input would never reach the final state
of this input, then the SHD is correct to reject its input as non-halting.

*HERE IS THE SIMPLEST CASE OF THAT*
void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0((u32)Infinite_Loop));
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

olcott

unread,
Aug 20, 2022, 3:06:39 PMAug 20
to
Because HH is a simulating halt decider (SHD) it continues to perform a
pure x86 emulation of its input until it correctly matches a non-halting
behavior pattern proving that the simulated input would never reach its
own final state.

(a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
(b) that simulates Px(Px) that calls a simulated HH(Px,Px)
(c) that simulates Px(Px) that calls a simulated HH(Px,Px)
(d) that simulates Px(Px) that calls a simulated HH(Px,Px)
*Until HH aborts its simulation*

All those having sufficient software engineering technical competence
can see this.

Mr Flibble

unread,
Aug 20, 2022, 3:09:11 PMAug 20
to
On Sat, 20 Aug 2022 14:06:32 -0500
Px always halts if H is a valid halt decider. Your H is not a valid
halt decider.

/Flibble

olcott

unread,
Aug 20, 2022, 3:18:36 PMAug 20
to
You can make dogmatic statements** like that to try and hide your
ignorance of software engineering yet are not fooling anyone that
actually has sufficient technical competence in software engineering.

** Utterly bereft of any supporting reasoning.

Richard Damon

unread,
Aug 20, 2022, 3:27:52 PMAug 20
to
Right. COMPLETE.

The H that answers non-halting does NOT do a COMPLETE simulation of its
input.

If that input is given to a UTM equivalent, the COMPLETE simulation of
that input (which still calls H) will Halt.

THUS, H was wrong.

>
> That you and others reject this when it is applied to my simulating halt
> decider implicitly rejects the notion of a UTM. Since you and others do
> accept the notion of a UTM, I have just proven that your reasoning is
> incoherent and/or inconsistent.

Becaue you have no H that answers non-Halting that also has a COMPLETE
simulation of its input that will not halt even after an unbounded
number of steps.

>
> Whenever the simulating halt decider correctly predicts that its correct
> and complete simulation of its input would never reach the final state
> of this input, then the SHD is correct to reject its input as non-halting.

FALSE.

IF it doesn't actually DO a complete simulation, talking about what the
complete simulation it would do is MEANINGLESS.

You H is answering about a different input then the one given to it.

>
> *HERE IS THE SIMPLEST CASE OF THAT*
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0((u32)Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001102](01)  55         push ebp
> [00001103](02)  8bec       mov ebp,esp
> [00001105](02)  ebfe       jmp 00001105
> [00001107](01)  5d         pop ebp
> [00001108](01)  c3         ret
> Size in bytes:(0007) [00001108]
>
>
>

Red Herring.

Fallacy of Proof by Exampe.

Richard Damon

unread,
Aug 20, 2022, 3:29:39 PMAug 20
to
And property (3) IS an INCORRECT criteria to show non-halting behavior.

It is a figment of your imagination and VOIDS your "proof".

FAIL.

Mr Flibble

unread,
Aug 20, 2022, 3:30:48 PMAug 20
to
On Sat, 20 Aug 2022 14:18:28 -0500
Myself and others have provided supporting reasoning on many occasions
which you chose to simply ignore.

Richard Damon

unread,
Aug 20, 2022, 3:32:56 PMAug 20
to
And the correct and complete simulation of the input to HH(Px,Px) is

(a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
(b) that simulates Px(Px) that calls a simulated HH(Px,Px)
(c) that simulates Px(Px) that calls a simulated HH(Px,Px)
(d) that simulates Px(Px) that calls a simulated HH(Px,Px)
(e) that simulates Px(Px) that calls a simulated HH(Px,Px)

*Until the SIMULATED HH from (a) abort ITS simulate.
(f) returns 0 to the simulated Px(Px) from (a)
(g) which returns, and thus Halts.

Thus, the COMPLETE simulation of the input to HH, which we agree shows
the actual behavior of the input to HH, comes to a Halt

The HH(Px,Px) returning 0 is INCORRECT.

olcott

unread,
Aug 20, 2022, 3:46:12 PMAug 20
to
This sequence of instructions provides the correct and complete
simulation of the input to H(P,P):

void Px(void (*x)())
{
(void) Simulate(x, x);
return;
}

You provide the pure simulation at the wrong point in the execution
trace. In any case even in your incorrect execution trace the Px that HH
simulates never reaches its own final state, thus never halts.

Fred. Zwarts

unread,
Aug 20, 2022, 4:00:35 PMAug 20
to
Op 20.aug..2022 om 17:23 schreef olcott:
Thanks for the confirmation, because I was not completely sure about my
last sentence above. But I am glad that I understood you correctly that
your aborting H answers the question for P calling the hypothetical
non-aborting H.

You derive the final answer (for P calling the actual aborting H)
indirectly from the first answer, because it cannot be answered
directly, as it would not reach the return instruction.

olcott

unread,
Aug 20, 2022, 4:04:49 PMAug 20
to
When-so-ever a simulating halt decider (SHD) correctly performs a
partial simulation of its input and the behavior of this partial
simulation correctly matches a non-halting behavior pattern then the
SHD halt decider can correctly report non-halting.

A non-halting behavior pattern is correct when-so-ever matching this
behavior pattern proves that the correct and complete simulation of the
input by SHD would never reach the final state of this simulated input.

olcott

unread,
Aug 20, 2022, 4:20:49 PMAug 20
to
*Here is my newly revised clearer explanation*

When-so-ever a simulating halt decider (SHD) correctly performs a
partial simulation of its input and the behavior of this partial
simulation correctly matches a non-halting behavior pattern then the
SHD halt decider can correctly report non-halting.

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

A non-halting behavior pattern is correct when-so-ever matching this
behavior pattern proves that the correct and complete simulation of the
input by SHD would never reach the final state of this simulated input.

The above system equally applies to all non-halting inputs explicitly
including the pathological input defined below:

*In computability theory, the halting problem is the problem*
of determining, from a description of an arbitrary computer
program and an input, whether the program will finish running,
or continue to run forever. Alan Turing proved in 1936 that a
general algorithm to solve the halting problem for all possible
program-input pairs cannot exist.

For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass its own
source and its input to H and then specifically do the opposite of
what H predicts P will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

*Linz, Peter 1990*. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

*Two more inputs that are correctly decided using this same system*

void Infinite_Loop()
{
HERE: goto HERE;
}

void Infinite_Recursion(int N)
{
Infinite_Recursion(N);

Mr Flibble

unread,
Aug 20, 2022, 4:35:37 PMAug 20
to
Your halting decider gets the answer wrong for Px ergo it is
invalid.

/Flibble

Ben Bacarisse

unread,
Aug 20, 2022, 4:53:51 PMAug 20
to
Yes, that's a reasonable summary. PO knows that no such H is possible
so he is just pushing two silly arguments: (a) that H(X,Y) == false for
at least one X and Y where X(Y) halts is correct, despite it being
clearly wrong; and (b) that even specifying that H(X,Y) must answer
about X(Y), rather than something else that he's made up, is wrong.

Both objections are risible, yet that have managed to generate a lot of
posts!

The fuel for all the debate comes from the fact that PO has wisely
abandoned talking about Turing machines because there was not enough
room for confusion. After all, formal models of computation are
designed to facilitate clear and un-ambiguous proofs.

> The classical proof that it is not possible is the idea that it is
> always possible to create a program P that uses H, with itself as
> input, but behaves opposite to what H returns. In a C-like language it
> would be something like:
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> If there would be a hypothetical non-simulating non-aborting H, which
> would always halts with the correct answer, then it is clear that
> there would be a contradiction if we ask H about P with
> H(P,P). Because there are only three possibilities:
> 1. If H would return true (halting) in a finite number of steps, then
> P would start an endless loop, so H(P,P) does not halt in a finite
> number of steps.
> 2. If H would return false (non-halting) in a finite number of steps,
> then P returns immediately, so H returns a wrong result.
> 3. If H does not return, then it does not return in a finite number of
> steps, so it is not the H where the problem asked for.
>
> I think everybody agrees up to this point.

No. PO rejects the very definition of the problem he is pretending to
care about. There is absolutely no dispute about the facts that (1)
H(P,P) == false and (2) P(P) halts.

Every post in reply to PO should start and stop with that fact. There
is nothing else to talk about.

> Now Olcott has created a simulating aborting H, which, when given P
> with input P [so H(P,P)], creates a trace of the execution and at the
> point where P calls H, it uses the following logic: If H were the
> hypothetical non-aborting H, then an infinite recursion would happen
> at this point. Therefore, Olcott's simulating H aborts the simulation
> and returns false (0).
>
> Does everybody still agree up to this point?

That's his ruse, yes, but you should not be colluding with the idea that
what "would happen if" is in any way relevant to the halting problem.
He's been trying to sneak this trick past credulous readers for years in
many different disguises. P(P) halts, but it wouldn't if... is not
maths but junk. 33 would be prime if it weren't divisible by 3 and 11.

> Now the opinions diverge.

They diverged long before this! PO rejects the very idea that a halt
decider might tell up what we want to know: that H(X,Y) == false if, and
only if, X(Y) does not halt.

> Olcott thinks that his H gives the correct answer that P would not
> halt when P would call the hypothetical non-aborting H, so, it must
> also be the correct answer when P actually calls the actual aborting
> H.

He may think that. I doubt his mind is that clear. After years of
coming up with ever more obscure what to justify the wrong answer, he
has toughly confused himself.

> Others have a different opinion and argue that P does not call the
> hypothetical non-aborting H, but the actual aborting H, which does not
> go in infinite recursion, but returns false in a finite number of
> steps. Therefore, H's result is wrong.

Someone my think that but, as you can see from your definition of the
halting problem at the top of this post, H is wrong, not by virtue of
anything it does, but because it simply does not meet the definition of
a halt decider (even if it's only in this one instance).

> Is this a correct summary of the disagreement? If not, please, tell me
> where the summary failed. Maybe we can then find the point of
> divergence of opinions easier.

You won't even get PO to agree to your problem definition because he
does not dispute the fact (and we not have the source code to see for
ourselves) that H(P,P) == false even though P(P) halts. These
undisputed facts should, in my opinion, be the start and end of every
reply to PO.

--
Ben.

olcott

unread,
Aug 20, 2022, 5:01:37 PMAug 20
to
It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.

That you and others reject this when it is applied to my simulating halt
decider implicitly rejects the notion of a UTM. Since you and others do
accept the notion of a UTM, I have just proven that your reasoning is
incoherent and/or inconsistent.


*NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*

When-so-ever a simulating halt decider (SHD) correctly performs a
partial simulation of its input and the behavior of this partial
simulation correctly matches a non-halting behavior pattern then the SHD
halt decider can correctly report non-halting.

A non-halting behavior pattern is correct when-so-ever matching this
behavior pattern proves that the correct and complete simulation of the
input by SHD would never reach the final state of this simulated input.



Richard Damon

unread,
Aug 20, 2022, 5:05:43 PMAug 20
to
Nope, because you changed P!

P MUST be


void Px(void (*x)()) {
HH(x,x);
}

As that is the P that was defined.

Then have main be:

int main() {
// The original call to HH
Output("Input_Halts = ", HH(Px, Px));

// The test
Simulate(Px,Px);
Output("But Px(Px) Halts");
}

I.E just DO the correct and complete simulation of the input to HH.

That is the plain meaning of the words.

Youy keep on trying to change the P that is the input to H to "prove"
your answer.

THIS IS NOT ALLOWED, and shows that you are just a cheat.

Richard Damon

unread,
Aug 20, 2022, 5:11:37 PMAug 20
to
CORRECTLY is the key, and that pattern needs to be a CORRECT PATTERN.

>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.

Nope, bad words,

The pattern is correct if when-so-ever matching this behavior pattern
proves that the correct and complete simulate of the input by a PURE
SIMULATOR would never reach the final state.

Note, your pattern even fails for your definition, as if the SHD has the
pattern in it, then it never actually does a correct and complete
simulation, so you can't "prove" what it does.

You don't get to look at P with a version of the SHD that doesn't have
the abort with a SHD that does have the abort and say that it passed the
test.

The P must use the SHD that decides it, which has the abort, which makes
the pattern incorrect.

FAIL.

olcott

unread,
Aug 20, 2022, 5:13:52 PMAug 20
to
*NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
When-so-ever a simulating halt decider (SHD) correctly performs a
partial simulation of its input and the behavior of this partial
simulation correctly matches a non-halting behavior pattern then the SHD
halt decider can correctly report non-halting.

A non-halting behavior pattern is correct when-so-ever matching this
behavior pattern proves that the correct and complete simulation of the
input by SHD would never reach the final state of this simulated input.

Richard Damon

unread,
Aug 20, 2022, 5:14:58 PMAug 20
to
Right

> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.
>

WRONG,

Not by the SHD, since BY DEFINITION, a SHD that had that pattern in it
would not do a complete simulation, so you have nothing to actually show
you were correcrt.

Please show the COMPLETE simulation of the input done by the SHD that
shows non-halting that it the exact same SHD that answers non-halting,
for an input that calls that SHD.


You need to test by a pure simulator, not the SHD.

FAIL.

Richard Damon

unread,
Aug 20, 2022, 5:17:08 PMAug 20
to
On 8/20/22 5:01 PM, olcott wrote:
The error has been pointed out many times, but you have proved yourself
to be too dumb to understand it.

>
> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a non-halting behavior pattern then the SHD
> halt decider can correctly report non-halting.
>
> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.
>
>
>

Since you definition of Halting doesn't match the Halting Problem, you
are just talking about POOP.

Halting is based on the ACTUAL EXECTUION of the machine, not by an
aborted simulation done by the SHD.

Sometimes it is right, but not in this case.

FAIL.

Richard Damon

unread,
Aug 20, 2022, 5:18:52 PMAug 20
to
I just did.

> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a non-halting behavior pattern then the SHD
> halt decider can correctly report non-halting.
>
> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.
>
>

I just showed you the error which you didn't bother even trying to
refute, which is just proof that you don't have a clue how to attempt
because you understand you are wrong.

You are just proving you are a pathological liar, or totally utterly
incompetent and stupid.

FAIL.

olcott

unread,
Aug 20, 2022, 5:27:24 PMAug 20
to
Therefore the actual behavior of the actual input is what the behavior
of the input would be if the SHD performed a correct and complete
simulation of this input.

The fact that the simulated input never reaches its own final state in
the above case conclusively proves that this input specifies a
non-halting sequence of instructions.

olcott

unread,
Aug 20, 2022, 5:29:42 PMAug 20
to
It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.

Therefore the actual behavior of the actual input is what the behavior
of the input would be if the SHD performed a correct and complete
simulation of this input.

The fact that the simulated input would never reach its own final state
in the above case conclusively proves that this input specifies a
non-halting sequence of instructions.


Richard Damon

unread,
Aug 20, 2022, 5:59:35 PMAug 20
to
Right

>
> Therefore the actual behavior of the actual input is what the behavior
> of the input would be if the SHD performed a correct and complete
> simulation of this input.
>

No. Because the SHD was defined to NOT do a complete simulation, but to
abort it. The "SHD that does a complete simulation" is a different
function than the one deciding, so it isn't the one that P is calling,
so its behavior is irrelvent.


> The fact that the simulated input would never reach its own final state
> in the above case conclusively proves that this input specifies a
> non-halting sequence of instructions.
>

Nope. Wrong Machine, The only machine that behaves that way doesn't answer.

The fact that Simulate(Px,Px) does Halt for any HH that answers
HH(Px,Px) proves that it is wrong to say non-halting.

Simulate(Px,Px) is what you just references (if not by name) as the
correct and complete simulation of the machine description that was
given to HH.


You keep on having two different functions that you call H (or HH) that
you conflate in your logic.

It doesn't matter what H/HH would have done if different, it matters
what the P does that calls the H/HH that you do have.

Richard Damon

unread,
Aug 20, 2022, 6:00:33 PMAug 20
to
Right.

>
> Therefore the actual behavior of the actual input is what the behavior
> of the input would be if the SHD performed a correct and complete
> simulation of this input.

Wrong, explained in other message.

>
> The fact that the simulated input never reaches its own final state in
> the above case conclusively proves that this input specifies a
> non-halting sequence of instructions.
>
>

Wrong. Explained in other message.

Jeff Barnett

unread,
Aug 20, 2022, 6:11:58 PMAug 20
to
On 8/20/2022 3:18 PM, Richard Damon wrote:
>
> On 8/20/22 5:13 PM, olcott wrote:

<SNIP> garbage

> I just showed you the error which you didn't bother even trying to
> refute, which is just proof that you don't have a clue how to attempt
> because you understand you are wrong.
>
> You are just proving you are a pathological liar, or totally utterly
> incompetent and stupid.

Why don't you include "all of the above" in the above? It certainly
should be obvious after decades of this bullshit.
--
Jeff Barnett

olcott

unread,
Aug 20, 2022, 6:33:15 PMAug 20
to
(1) It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.

(2) Therefore the actual behavior of the actual input is what the
behavior of the input would be if the SHD performed a correct and
complete simulation of this input.

(3) The fact that the simulated input would never reach its own final
state in the above case conclusively proves that this input specifies a
non-halting sequence of instructions.

Because (1) is known to be true and (2) logically follows from (1) it is
impossible to correctly accept (1) and deny (2).

Richard Damon

unread,
Aug 20, 2022, 6:59:24 PMAug 20
to
Nope. Proves you are an idiot. Because the SHD DOES abort it simulation,
there is no "If it didn't" case to look at.

What is the results of program X doing operation Y if program X never
actually does operation Y.

It is an ill defined condition.

> (3) The fact that the simulated input would never reach its own final
> state in the above case conclusively proves that this input specifies a
> non-halting sequence of instructions.
>
> Because (1) is known to be true and (2) logically follows from (1) it is
> impossible to correctly accept (1) and deny (2).
>

If you want to try to express your words in a correct formulation, you
could do the following.

H is defined to take THREE parameters:

P the program to decide on,
d the data for that program, and
s a flag that forces the decider to be a pure simulator and not a decider.


THen

H(P,d,0) is correct to return 1 if H(P,d,1) Halts, and
H(P,d,0) is correct to return 0 if H(P,d,1) will never halt but run forever.

P(x) is then defined to call H(x,x,0)

And the H to decide it by the call H(P,P,0)

You will find that by your logic:

H(P,P,0) will return 0, but H(P,P,1) will Halt, so it is wrong.

Or we will see that H(P,P,1) doesn't actually correctly simulate its
input, for instance if it thinks that the call H(P,P,0) in P behaves
differently then the call to H(P,P,0) done by main.

NOW you can ask about what the H would do if it doesn't abort, because
you can make that happen without changing the code for H.

Changing the code for H isn't allowed, as that affects the "input" to H,
since it is the x86 assembly code for the PROGRAM P (not just the
function) as that is what the definitions require.

olcott

unread,
Aug 20, 2022, 7:10:21 PMAug 20
to
You are still doing the pure simulation at the wrong point in the
execution trace.

x86utm Halt7.obj 1 // runs every instance of H as a pure simulator
x86utm Halt7.obj 0 // runs every instance of H as a halt decider

olcott

unread,
Aug 20, 2022, 7:28:10 PMAug 20
to
*We could prove my point another way too*

The simulating halt decider writes a 1 or a 0 to a specific tape
location that is initialized to blank. It does this as soon as it
correctly detects that its complete simulation would never stop running.

HERE IS THE KEY DIFFERENCE:
H continues to perform this complete simulation, thus never stops
running. Because it has reported this it is correct.

The assumption that H must stop to report its decision is refuted.

Richard Damon

unread,
Aug 20, 2022, 7:40:30 PMAug 20
to
But x86utm Halts7.obj 1 will never answer
and x86utm Halts7.obj 0 will have H answer about the wrong P, it answers
about the P in the other case, which is wrong.
This can be shown by having main call P(P) and show that it returns.


You don't change the H that P calls, because that is changing the input
to H.

FAIL.

You are just

Richard Damon

unread,
Aug 20, 2022, 7:42:13 PMAug 20
to
Nope, because H needs to stop to give the answer.

Your H you just defined never answers, so fails to be a decider.

FAIL.

You just don't know how Turing Machines work.

Can H "return" a value if it never returns?

NO.
>

olcott

unread,
Aug 20, 2022, 8:14:54 PMAug 20
to
That is needs to stop to give its answer
IS A FALSE ASSUMPTION.

As soon as H knows the answer it writes a 1 or a 0 to a specific tape
location and then it keeps on running.

olcott

unread,
Aug 20, 2022, 8:16:05 PMAug 20
to
Yet proves that: Halts7.obj 0
is correct.

> and x86utm Halts7.obj 0 will have H answer about the wrong P, it answers
> about the P in the other case, which is wrong.
> This can be shown by having main call P(P) and show that it returns.
>
>
> You don't change the H that P calls, because that is changing the input
> to H.
>
> FAIL.
>
> You are just


Richard Damon

unread,
Aug 20, 2022, 9:06:40 PMAug 20
to
Nope, because you changed the input.

FAIL.

That parameter changed th e behavior of H, you are looking at the wrong
function P.

The CORRECT way to do that was as I described it above:


The behavior of H(P,P,1) verifies the correct answer for H(P,P,0)

Richard Damon

unread,
Aug 20, 2022, 9:07:36 PMAug 20
to
Nope.

Not how Turing Machine work.

Not how C functions work either.

FAIL.

You are just proving your ignorance.

Richard Damon

unread,
Aug 20, 2022, 9:10:25 PMAug 20
to
Remember, Linz DEFINED his H to answer by what final state it ended in,
and comments that this is without loss of generality.

That is because if you defined you H to write the answer on a given
location of the tape, you just need to add a "tail" to the Turing
Machine to go to that location on the tape and then go to the accept
state or reject state, becuase the tape is only looked at when the
machine halts.

DEFINITIONS you know.

olcott

unread,
Aug 20, 2022, 9:45:18 PMAug 20
to
So you are saying that it is impossible for a TM to write a binary digit
at the first element of its tape?



> Not how C functions work either.
>
> FAIL.
>
> You are just proving your ignorance.




Richard Damon

unread,
Aug 20, 2022, 9:48:57 PMAug 20
to
No, but it doesn't count as an answer until the machine stops.

This is because the results are usable until it does (if, for instance,
you attach the algorithm for another Turing Machine after it.)

You are just showing your ignorance.

olcott

unread,
Aug 20, 2022, 9:50:07 PMAug 20
to
None-the-less H could write a 1 or a 0 to the first element of its tape
and keep on running. That the TM must halt to decide is simply not true.
This is another case where CS simply didn't bother to think things through.

> That is because if you defined you H to write the answer on a given
> location of the tape, you just need to add a "tail" to the Turing
> Machine to go to that location on the tape and then go to the accept
> state or reject state, becuase the tape is only looked at when the
> machine halts.
>
> DEFINITIONS you know.

Another TM would have to do that because you insist that when H stops
running after reporting 0 it is wrong so it has to keep on running to
meet your objection.

olcott

unread,
Aug 20, 2022, 10:04:53 PMAug 20
to
That is only an arbitrary rule that has no actual basis in sound
reasoning. People that only learn things by rote never notice that some
rules have no actual basis in reasoning and are thus merely arbitrary
conventions.

> This is because the results are usable until it does (if, for instance,
> you attach the algorithm for another Turing Machine after it.)
>

An other TM can be constantly polling that fixed memory location and
report the results. This machine could light up a 40 foot billboard that
says H(P,P) has correctly determined that its input does not halt.

None of this convoluted nonsense is required if you simply accept the
fact that the simulating halt decider is already correct.

> You are just showing your ignorance.
>
>>
>>
>>> Not how C functions work either.
>>>
>>> FAIL.
>>>
>>> You are just proving your ignorance.
>>
>>
>>
>>
>


Richard Damon

unread,
Aug 20, 2022, 10:08:03 PMAug 20
to
Nope.

Does a C function "Return an answer" if it never reaches its return
instruction?

Remember, we are talking "Single Threaded" computations here.

Seams you are having problem with fundamental definition of basic
computer programming.

Remember the DEFINITION of a Decider, a Machine that HALTS for all inputs.

You H isn't a decider if it doesn't halt, so can't be a Halt Decder.

>
>> That is because if you defined you H to write the answer on a given
>> location of the tape, you just need to add a "tail" to the Turing
>> Machine to go to that location on the tape and then go to the accept
>> state or reject state, becuase the tape is only looked at when the
>> machine halts.
>>
>> DEFINITIONS you know.
>
> Another TM would have to do that because you insist that when H stops
> running after reporting 0 it is wrong so it has to keep on running to
> meet your objection.
>

So you admit that the only why H can not be wrong is to not answer?

Note, another TM can't access the tape of this TM except by cascading
there code, so they become part of a larger TM.

You ar just showing your ignorance.

Richard Damon

unread,
Aug 20, 2022, 10:14:02 PMAug 20
to
Nope. Fundamental to how Turing Machines work.

Can you C function H return an answer to Main and still keep running?

Nope.

>
>> This is because the results are usable until it does (if, for
>> instance, you attach the algorithm for another Turing Machine after it.)
>>
>
> An other TM can be constantly polling that fixed memory location and
> report the results. This machine could light up a 40 foot billboard that
> says H(P,P) has correctly determined that its input does not halt.

Nope. Not in the Turing Machine Model.

FAIL.

PROOF of your Ignorance.

Note, if it could do that, then P could, and once H signals that the
answer is there, then P gets the signal and halts.

You can't have it both ways.

>
> None of this convoluted nonsense is required if you simply accept the
> fact that the simulating halt decider is already correct.

Nope, you are just showing your ignorance.

It ISN"t Correct, because if it gives an answer so that someone can use
it, P can use it and act contrary.

If it hasn't given an answer so P can use it, it hasn't given an answer
that anything else can use.

FAIL.

dklei...@gmail.com

unread,
Aug 20, 2022, 10:18:50 PMAug 20
to
On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:

> So you are saying that it is impossible for a TM to write a binary digit
> at the first element of its tape?
>
The concept "first element of its tape" is ambigious and usually
defined so as to be constantly changing. How something like
H returns anything needs to be carefully defined. Perhaps Linz
does define it elsewhere in his book.

Richard Damon

unread,
Aug 20, 2022, 10:40:22 PMAug 20
to
Some models of Turing Machines have a fixed end that can't be extended,
so there is a first element. This does lead to other issues that need to
be handled.

PO just thinks of the tape as memory locations, so the concept of
element NOT having a address whould be too confusing for him.

olcott

unread,
Aug 20, 2022, 11:08:04 PMAug 20
to
At least some of the definitions of TM's have only a unidirectional
tapes thus inherently have a first element.

page 10
https://basics.sjtu.edu.cn/~yuxi/teaching/computability2013/slides/4.%20Turing%20Machine.pdf

dklei...@gmail.com

unread,
Aug 21, 2022, 2:10:10 AMAug 21
to
On Saturday, August 20, 2022 at 8:08:04 PM UTC-7, olcott wrote:
> On 8/20/2022 9:18 PM, dklei...@gmail.com wrote:
> > On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:
> >
> >> So you are saying that it is impossible for a TM to write a binary digit
> >> at the first element of its tape?
> >>
> > The concept "first element of its tape" is ambigious and usually
> > defined so as to be constantly changing. How something like
> > H returns anything needs to be carefully defined. Perhaps Linz
> > does define it elsewhere in his book.
> At least some of the definitions of TM's have only a unidirectional
> tapes thus inherently have a first element.
>
> page 10
> https://basics.sjtu.edu.cn/~yuxi/teaching/computability2013/slides/4.%20Turing%20Machine.pdf

That version of Turing Machines is somewhat eccentric. I wonder
what the situation is among the research community. Is there any
kind of consensus today about what a standard Turing Machine
is. Is the machine described in Wikipedia the standard?

Mikko

unread,
Aug 21, 2022, 5:00:13 AMAug 21
to
On 2022-08-20 15:01:34 +0000, Fred. Zwarts said:

> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>> Olcott, which of the following do you think is more likely?
>>
>> 1) Olcott is correct and everybody else is wrong.
>> 2) Olcott is wrong and everybody else is correct.
>>
>> Which one is more likely hasn't changed for all the years you've been
>> attempting to shill your simulating halting decider. I find it amusing
>> that I came up with, in less than 24 hours, a simulating halting
>> decider that doesn't have the flaws your SHD has.
>>
>> /Flibble
>>
>
> I have been following these discussions for many months now. I have a
> strong impression that there is little progress. It seems that people
> are running in circles. I am not an expert in this field. Maybe it
> helps if a non-expert tries to summarize the discussion. Please, be
> patient when correcting me if I make any mistake.
>
> First the problem this is al about:
> In computation theory we can denote a program with X and its input with
> Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite
> number of steps, but another program X and/or input Y may not halt in a
> finite number of steps. The question is, is it possible to create a
> program H that when given any program X with its input Y can tell in a
> finite number of steps whether X(Y) halts or not? In other words, will
> H(X,Y) always halt after a finite number of steps with the correct
> answer f