Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Olcott
340 views
Skip to first unread message
Mr Flibble
Aug 17, 2022, 12:46:40 PM8/17/22
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
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
Aug 17, 2022, 1:03:41 PM8/17/22
to
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
Aug 17, 2022, 1:06:47 PM8/17/22
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
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
the following:
https://en.wikipedia.org/wiki/Hubris
/Flibble
Jeff Barnett
Aug 17, 2022, 5:47:27 PM8/17/22
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
> 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
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
Aug 20, 2022, 11:01:38 AM8/20/22
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.
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
Aug 20, 2022, 11:24:07 AM8/20/22
to
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
Aug 20, 2022, 2:32:14 PM8/20/22
to
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
Aug 20, 2022, 2:32:59 PM8/20/22
to
"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
Aug 20, 2022, 2:50:22 PM8/20/22
to
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
Aug 20, 2022, 2:52:48 PM8/20/22
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
halts. Until you resolve this false positive you do not have a valid
SHD.
/Flibble
olcott
Aug 20, 2022, 3:00:50 PM8/20/22
to
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;
}
{
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
}
_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
Size in bytes:(0007) [00001108]
olcott
Aug 20, 2022, 3:06:39 PM8/20/22
to
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
Aug 20, 2022, 3:09:11 PM8/20/22
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
halt decider.
/Flibble
olcott
Aug 20, 2022, 3:18:36 PM8/20/22
to
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
Aug 20, 2022, 3:27:52 PM8/20/22
to
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.
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.
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]
>
>
>
Fallacy of Proof by Exampe.
Richard Damon
Aug 20, 2022, 3:29:39 PM8/20/22
to
It is a figment of your imagination and VOIDS your "proof".
FAIL.
Mr Flibble
Aug 20, 2022, 3:30:48 PM8/20/22
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.
which you chose to simply ignore.
Richard Damon
Aug 20, 2022, 3:32:56 PM8/20/22
to
(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)
(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 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
Aug 20, 2022, 3:46:12 PM8/20/22
to
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
Aug 20, 2022, 4:00:35 PM8/20/22
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.
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
Aug 20, 2022, 4:04:49 PM8/20/22
to
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
Aug 20, 2022, 4:20:49 PM8/20/22
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.
*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
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;
}
{
Infinite_Recursion(N);
Mr Flibble
Aug 20, 2022, 4:35:37 PM8/20/22
to
invalid.
/Flibble
Ben Bacarisse
Aug 20, 2022, 4:53:51 PM8/20/22
to
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.
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?
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.
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.
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.
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
Aug 20, 2022, 5:01:37 PM8/20/22
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.
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*
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.
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.
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
Aug 20, 2022, 5:05:43 PM8/20/22
to
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
Aug 20, 2022, 5:11:37 PM8/20/22
to
>
> *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 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
Aug 20, 2022, 5:13:52 PM8/20/22
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.
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
Aug 20, 2022, 5:14:58 PM8/20/22
to
> 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.
>
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
Aug 20, 2022, 5:17:08 PM8/20/22
to
On 8/20/22 5:01 PM, olcott wrote:
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.
>
>
>
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
Aug 20, 2022, 5:18:52 PM8/20/22
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.
>
>
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
Aug 20, 2022, 5:27:24 PM8/20/22
to
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
Aug 20, 2022, 5:29:42 PM8/20/22
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
machine description always provides the actual behavior specified by
this machine description.
Therefore the actual behavior of the actual input is what the behavior
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.
non-halting sequence of instructions.
Richard Damon
Aug 20, 2022, 5:59:35 PM8/20/22
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.
>
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.
>
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
Aug 20, 2022, 6:00:33 PM8/20/22
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.
>
>
Jeff Barnett
Aug 20, 2022, 6:11:58 PM8/20/22
to
On 8/20/2022 3:18 PM, Richard Damon wrote:
>
> On 8/20/22 5:13 PM, olcott wrote:
<SNIP> garbage
>
> On 8/20/22 5:13 PM, olcott wrote:
> 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.
should be obvious after decades of this bullshit.
--
Jeff Barnett
olcott
Aug 20, 2022, 6:33:15 PM8/20/22
to
machine description always provides the actual behavior specified by
this machine description.
(2) Therefore the actual behavior of the actual input is what the
this machine description.
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
complete simulation of this input.
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
non-halting sequence of instructions.
impossible to correctly accept (1) and deny (2).
Richard Damon
Aug 20, 2022, 6:59:24 PM8/20/22
to
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).
>
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
Aug 20, 2022, 7:10:21 PM8/20/22
to
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
Aug 20, 2022, 7:28:10 PM8/20/22
to
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
Aug 20, 2022, 7:40:30 PM8/20/22
to
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
Aug 20, 2022, 7:42:13 PM8/20/22
to
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
Aug 20, 2022, 8:14:54 PM8/20/22
to
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
Aug 20, 2022, 8:16:05 PM8/20/22
to
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
Aug 20, 2022, 9:06:40 PM8/20/22
to
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
Aug 20, 2022, 9:07:36 PM8/20/22
to
Not how Turing Machine work.
Not how C functions work either.
FAIL.
You are just proving your ignorance.
Richard Damon
Aug 20, 2022, 9:10:25 PM8/20/22
to
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
Aug 20, 2022, 9:45:18 PM8/20/22
to
at the first element of its tape?
> Not how C functions work either.
>
> FAIL.
>
> You are just proving your ignorance.
Richard Damon
Aug 20, 2022, 9:48:57 PM8/20/22
to
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
Aug 20, 2022, 9:50:07 PM8/20/22
to
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.
running after reporting 0 it is wrong so it has to keep on running to
meet your objection.
olcott
Aug 20, 2022, 10:04:53 PM8/20/22
to
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.)
>
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
Aug 20, 2022, 10:08:03 PM8/20/22
to
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.
>
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
Aug 20, 2022, 10:14:02 PM8/20/22
to
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.
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.
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
Aug 20, 2022, 10:18:50 PM8/20/22
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
> So you are saying that it is impossible for a TM to write a binary digit
> at the first element of its tape?
>
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
Aug 20, 2022, 10:40:22 PM8/20/22
to
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
Aug 20, 2022, 11:08:04 PM8/20/22
to
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
Aug 21, 2022, 2:10:10 AM8/21/22
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
> 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
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
Aug 21, 2022, 5:00:13 AM8/21/22
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 for any X and Y?
In the classical formulation X and H are Turing machines. Y is a finite
> 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 for any X and Y?
string of symbols from some finite set. H(X,Y) denotes a computation where
H is given a finite string that represents X and Y so that each can be
reconstructed.
> 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;
> }
void P(string x)
{
string arg = pair(x, x);
boolean Halt_Status = H(arg);
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.
With Turing machines the possibilities are:
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.
1. H halts with the answer true.
2. H halts with the answer false.
3. H halts but answers neither true nor false.
4. H does not halt.
If 3 or 4 happens then H is not a halt decider, i.e., not a solution
to the problem. If H(P, P) halts with the answer true then P(P) does
not halt so H is not a halt decider. If H(P, P) halts with the
answer false then P(P) halts so H is not a halt decider.
The restriction to non-simulating non-aborting H is not necessary.
The requirements are the same anyway.
> 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.
Basically the disagreement is about the meaning of "correct".
> 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.
Mikko
Mikko
Aug 21, 2022, 5:08:04 AM8/21/22
to
On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
> Op 20.aug..2022 om 17:23 schreef olcott:
>> *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.
>>
>
> 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.
Note that reaching return instruction is not the same as halting as
specified in the original problem. Halting as required to be determined
in the halting problem means that the computation as arrived to a any
situation where the program does not specify the next action. The classical
problem statement is about Turing machines where "return" is not defined.
Mikko
> Op 20.aug..2022 om 17:23 schreef olcott:
>> *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.
>>
>
> 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.
Note that reaching return instruction is not the same as halting as
specified in the original problem. Halting as required to be determined
in the halting problem means that the computation as arrived to a any
situation where the program does not specify the next action. The classical
problem statement is about Turing machines where "return" is not defined.
Mikko
Mikko
Aug 21, 2022, 5:12:16 AM8/21/22
to
On 2022-08-20 15:23:58 +0000, olcott said:
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
Note that an important part of the definition is omitted: the definition
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
of "final state" is not quoted because that would make much harder to
reject Linz' definition and use a different meaning instead.
Mikko
Ben Bacarisse
Aug 21, 2022, 7:14:18 AM8/21/22
to
preferred definition or the one in some recommended text. As for the
research community, it's a non-issue as all forms are fundamentally
equivalent.
--
Ben.
Richard Damon
Aug 21, 2022, 7:35:14 AM8/21/22
to
computation returns to "its caller" is not a bad equivalent the the
halting state of a Turing Machine.
The inital call / return become the equivalents of the initial and final
states of the Turing Machine as far as actually building up a larger
computation out of pieces.
It is how a function "yields" its answer to its user.
Mikko
Aug 21, 2022, 9:12:18 AM8/21/22
to
call exit. Only if we know that a program does not terminate otherwise
we may equate final return to halt.
Mikko
olcott
Aug 21, 2022, 9:21:28 AM8/21/22
to
first tape element.
olcott
Aug 21, 2022, 9:30:18 AM8/21/22
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.
The correct and complete simulation by H(P,P) of its input would never
machine description always provides the actual behavior specified by
this machine description.
reach its final state and halt, thus the input to H(P,P) specifies a
non-halting sequence of instructions.
>> 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.
>
> Basically the disagreement is about the meaning of "correct".
>
> Mikko
>
olcott
Aug 21, 2022, 9:34:06 AM8/21/22
to
On 8/21/2022 4:08 AM, Mikko wrote:
> On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
>
>> Op 20.aug..2022 om 17:23 schreef olcott:
>
>>> *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.
>>>
>>
>> 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.
>
> Note that reaching return instruction is not the same as halting as
> specified in the original problem.
Of course "return" is not defined for Turing Machines, only a final
> On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
>
>> Op 20.aug..2022 om 17:23 schreef olcott:
>
>>> *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.
>>>
>>
>> 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.
>
> Note that reaching return instruction is not the same as halting as
> specified in the original problem.
state is defined for TM's. The final state of a C function is its
"return" instruction.
> Halting as required to be determined
> in the halting problem means that the computation as arrived to a any
> situation where the program does not specify the next action.
> The classical
> problem statement is about Turing machines where "return" is not defined.
>
> Mikko
>
olcott
Aug 21, 2022, 9:40:32 AM8/21/22
to
On 8/21/2022 4:12 AM, Mikko wrote:
> On 2022-08-20 15:23:58 +0000, olcott said:
>
>> *computation that halts* … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>
> Note that an important part of the definition is omitted: the definition
> of "final state" is not quoted because
Everyone here knows what a final state is:
> On 2022-08-20 15:23:58 +0000, olcott said:
>
>> *computation that halts* … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>
> Note that an important part of the definition is omitted: the definition
> of "final state" is not quoted because
A configuration for which δ is not defined...
we will Assume that no transitions are defined for any final state.
> that would make much harder to
> reject Linz' definition and use a different meaning instead.
>
> Mikko
>
olcott
Aug 21, 2022, 9:48:23 AM8/21/22
to
On 8/21/2022 4:12 AM, Mikko wrote:
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
}
No transitions are defined for __asm hlt.
Mikko
Aug 21, 2022, 10:45:19 AM8/21/22
to
On 2022-08-21 13:33:59 +0000, olcott said:
> On 8/21/2022 4:08 AM, Mikko wrote:
>> Halting as required to be determined
>> in the halting problem means that the computation as arrived to a any
>> situation where the program does not specify the next action.
>
> AKA a final state.
But not necessarily a return statement. For example, an exit call
> On 8/21/2022 4:08 AM, Mikko wrote:
>> Halting as required to be determined
>> in the halting problem means that the computation as arrived to a any
>> situation where the program does not specify the next action.
>
> AKA a final state.
could be used instead.
Mikko
Shvili, the Kookologist
Aug 21, 2022, 11:16:17 AM8/21/22
to
On Sat, 20 Aug 2022 16:01:31 -0500, in article <crudnRbncP4E1pz-
nZ2dnZfq...@giganews.com>, olcott wrote:
[snip]
> It is common knowledge that [...]
Have you noticed that almost every time you use this phrase, you're
wrong?
So also this time.
> [...] the correct and complete simulation of a
> machine description [...]
Machine descriptions are never simulated -- they're just sequences
of symbols.
and don't have any defined behaviour. The machines they *represent*
may be
simulated.
> [...] always provides the actual behavior specified by
> this machine description.
This is almost, but not quite, correct (if you fix it according to
the
previous paragraph). It would have been completely correct, if it
weren't
for the fact that you're using an utterly bizarre meaning for the
phrase
> 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.
Let M be a given machine, with machine description [M], and let w
be
a given input tape, with tape description [w]. Then the
"simulation"
UTM([M],[w]) has exactly the same result (i.e. exactly the same
behaviour)
as the direct computation M(w). This is actually the definition of
a UTM.
Another way of expressing this is: M(w) and UTM([M],[w]) compute
the same
partial function.
You have made it abundantly clear that when you say "the actual
behavior
specified by this machine description", you do *not* mean "the
actual
behavior specified by this machine description", because that's
simply
the behaviour of M(w). What you *do* mean is "the behaviour of your
particular, broken and incomplete, quasi-simulation based on [M]
and [w]".
Why is it broken? Because it *doesn't* have the same behaviour as M
(w),
nor as UTM([M],[w]). A correct simulation *means* that it has the
same
behaviour as M(w).
Why is it incomplete? Because it aborts its "simulation" before it
reaches
a halting configuration of the machine represented by its input,
and it
does so on invalidly.
Why is it a quasi-simulation? Because it depends on external input
that is
contained in neither [M] nor [w]. You have said, on numerous
occasions,
that the behaviour of your "H(P,P)" depends on the specific memory
location of "P". Well, then that location is an external input.
Your H is
*not* analogous to Linz' H([M],[w]).
This is the point where you usually barf up your stanza about how
the
behaviour of your "H(P,P)" cannot be expected to be computed "from
the
non-input P(P)". This is obviously idiotic, for the following
reasons:
1) A purported halt decider H([M],[w]) is *not* required to compute
its
result *from* M(w), but to *match* M(w). Computing *from* M(w)
would be
completely pointless, because the decider would already know the
answer.
Since you seem unable to understand anything but arguments from
analogy, let me re-use one that you yourself have employed:
Suppose
we want to construct an addition algorithm add(x,y). If you were
to
complain that add(5,7) cannot be required to compute its result
"from
the non-input 12", you would, quite rightly, be regarded as a
complete
nitwit. Can you now guess why you're universally regarded as a
complete
nitwit?
2) The behaviour of UTM([M],[w]) is *defined* to match the
behaviour of M(w),
and UTMs very evidently do exist. The information contained in
[M] and [w]
is obviously enough to match the behaviour of M(w). The fact
that your
"simulator" fails in this regard, is proof that your
"simulator" is
defective -- *not* that you have discovered a "loop hole", or
that halting
theorem is faulty, or anything of that kind -- only that you're
working
with a broken simulator.
> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
A lot of people have pointed out many kinds of errors in your
reasoning.
You usually respond with some form "proof by regurgitation". I
expect you
will do so to this post.
> 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.
Yeah, that's just a bunch of equivocations on "correctly", "its
input",
"non-halting behavior", and more. Please learn to write clearly.
Also, could you *please* stop misreading Linz! He *doesn't* say
that a TM
halts, only if it enters a "final state". What he actually says is:
"A Turing machine is said to halt whenever it reaches a
configuration
for which delta is not defined; this is possible because delta
is a
partial function. In fact, we will assume that no transitions
are
defined for any final state, so the Turing machine will halt
the TM
halts in a non-final state. It is, on the other hand, understood
that a TM
*only* stops running if enters a configuration for which the
transition
function is undefined.
"Final states" only concern the *interpretation* of the value of a
computation -- *not* whether the TM halts or not.
This means that "halting" and "stops running" are the exact the
same things.
And obviously, "running" and "being simulated" are two entirely
different
things.
nZ2dnZfq...@giganews.com>, olcott wrote:
[snip]
> It is common knowledge that [...]
Have you noticed that almost every time you use this phrase, you're
wrong?
So also this time.
> [...] the correct and complete simulation of a
> machine description [...]
Machine descriptions are never simulated -- they're just sequences
of symbols.
and don't have any defined behaviour. The machines they *represent*
may be
simulated.
> [...] always provides the actual behavior specified by
> this machine description.
This is almost, but not quite, correct (if you fix it according to
the
previous paragraph). It would have been completely correct, if it
weren't
for the fact that you're using an utterly bizarre meaning for the
phrase
"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.
Let M be a given machine, with machine description [M], and let w
be
a given input tape, with tape description [w]. Then the
"simulation"
UTM([M],[w]) has exactly the same result (i.e. exactly the same
behaviour)
as the direct computation M(w). This is actually the definition of
a UTM.
Another way of expressing this is: M(w) and UTM([M],[w]) compute
the same
partial function.
You have made it abundantly clear that when you say "the actual
behavior
specified by this machine description", you do *not* mean "the
actual
behavior specified by this machine description", because that's
simply
the behaviour of M(w). What you *do* mean is "the behaviour of your
particular, broken and incomplete, quasi-simulation based on [M]
and [w]".
Why is it broken? Because it *doesn't* have the same behaviour as M
(w),
nor as UTM([M],[w]). A correct simulation *means* that it has the
same
behaviour as M(w).
Why is it incomplete? Because it aborts its "simulation" before it
reaches
a halting configuration of the machine represented by its input,
and it
does so on invalidly.
Why is it a quasi-simulation? Because it depends on external input
that is
contained in neither [M] nor [w]. You have said, on numerous
occasions,
that the behaviour of your "H(P,P)" depends on the specific memory
location of "P". Well, then that location is an external input.
Your H is
*not* analogous to Linz' H([M],[w]).
This is the point where you usually barf up your stanza about how
the
behaviour of your "H(P,P)" cannot be expected to be computed "from
the
non-input P(P)". This is obviously idiotic, for the following
reasons:
1) A purported halt decider H([M],[w]) is *not* required to compute
its
result *from* M(w), but to *match* M(w). Computing *from* M(w)
would be
completely pointless, because the decider would already know the
answer.
Since you seem unable to understand anything but arguments from
analogy, let me re-use one that you yourself have employed:
Suppose
we want to construct an addition algorithm add(x,y). If you were
to
complain that add(5,7) cannot be required to compute its result
"from
the non-input 12", you would, quite rightly, be regarded as a
complete
nitwit. Can you now guess why you're universally regarded as a
complete
nitwit?
2) The behaviour of UTM([M],[w]) is *defined* to match the
behaviour of M(w),
and UTMs very evidently do exist. The information contained in
[M] and [w]
is obviously enough to match the behaviour of M(w). The fact
that your
"simulator" fails in this regard, is proof that your
"simulator" is
defective -- *not* that you have discovered a "loop hole", or
that halting
theorem is faulty, or anything of that kind -- only that you're
working
with a broken simulator.
> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
reasoning.
You usually respond with some form "proof by regurgitation". I
expect you
will do so to this post.
> 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.
input",
"non-halting behavior", and more. Please learn to write clearly.
Also, could you *please* stop misreading Linz! He *doesn't* say
that a TM
halts, only if it enters a "final state". What he actually says is:
"A Turing machine is said to halt whenever it reaches a
configuration
for which delta is not defined; this is possible because delta
is a
partial function. In fact, we will assume that no transitions
are
defined for any final state, so the Turing machine will halt
whenever
it enters a final state."
So, for a general TM, there may well be configurations for which
it enters a final state."
the TM
halts in a non-final state. It is, on the other hand, understood
that a TM
*only* stops running if enters a configuration for which the
transition
function is undefined.
"Final states" only concern the *interpretation* of the value of a
computation -- *not* whether the TM halts or not.
This means that "halting" and "stops running" are the exact the
same things.
And obviously, "running" and "being simulated" are two entirely
different
things.
olcott
Aug 21, 2022, 11:36:20 AM8/21/22
to
{
int Halt_Status = UTM(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
HERE: goto HERE;
}
The behavior of the actual input to the simulating halt decider is the
behavior of the above. Since C functions do not actually have UTM's a
more accurate way of sayoing this is:
void P(ptr x)
{
int Halt_Status = Simulate(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
HERE: goto HERE;
}
The behavior of UTM(P,P) or Simulate(P,P) is not the behavior of the
actual input to H(P,P) because it is at a different point in the
execution trace than H(P,P).
Shvili, the Kookologist
Aug 21, 2022, 1:08:35 PM8/21/22
to
[Re-post: line wrapping went haywire!]
M(w), nor as UTM([M],[w]). A correct simulation *means* that it has
Shvili, the Kookologist
Aug 21, 2022, 1:08:36 PM8/21/22
to
On Sun, 21 Aug 2022 10:36:12 -0500, in article <edqcnTmwUr5IzZ_-
nZ2dnZfq...@giganews.com>, olcott wrote:
>
> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
[sorry about the strange wrapping -- I have no idea what happened there!]
nZ2dnZfq...@giganews.com>, olcott wrote:
>
> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
> > On Sat, 20 Aug 2022 16:01:31 -0500, in article <crudnRbncP4E1pz-
> > nZ2dnZfq...@giganews.com>, olcott wrote:
> >
> > [snip]
> >
> >> It is common knowledge that [...]
>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>>A lot of people have pointed out many kinds of errors in
>>regurgitation". I expect you will do so to this post.
[snip]
>
> void P(ptr x)
> {
<BLARGH!>
Are you actually actively trying to prove my point?
Richard Damon
Aug 21, 2022, 2:00:18 PM8/21/22
to
On 8/21/22 9:33 AM, olcott wrote:
> On 8/21/2022 4:08 AM, Mikko wrote:
>> On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
>>
>>> Op 20.aug..2022 om 17:23 schreef olcott:
>>
>>>> *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.
>>>>
>>>
>>> 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.
>>
>> Note that reaching return instruction is not the same as halting as
>> specified in the original problem.
>
>
> Of course "return" is not defined for Turing Machines, only a final
> state is defined for TM's. The final state of a C function is its
> "return" instruction.
So if your H function doesn't reach its return instruction in finite
> On 8/21/2022 4:08 AM, Mikko wrote:
>> On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
>>
>>> Op 20.aug..2022 om 17:23 schreef olcott:
>>
>>>> *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.
>>>>
>>>
>>> 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.
>>
>> Note that reaching return instruction is not the same as halting as
>> specified in the original problem.
>
>
> Of course "return" is not defined for Turing Machines, only a final
> state is defined for TM's. The final state of a C function is its
> "return" instruction.
time, it hasn't given a result.
Richard Damon
Aug 21, 2022, 2:04:23 PM8/21/22
to
You forget the question that the Halt Decider is being asked to solve,
which is what the machine represented by its input would do.
That starts at that exact point.
You are just confirming that you H isn't actually a Halt Decider, even
though you claim it is, which just proves you are a LIAR.
Richard Damon
Aug 21, 2022, 2:09:23 PM8/21/22
to
actually does a correct and complete simulation of its input, is the H
that doesn't abort its simulation and thus never answers so fails to be
a Halt Decider.
THe H that does try to argue that it is correct in aborting it
simulation doesn't actually do a correct and complete simulation, so has
made your criteria invalid. It is a different program, having a
different specific implementation than the one in the previous
paragraph, so the P that it is analyzing, that is calling IT, and not
the H from above isn't being correctly analyised when H presumes it is
calling that above H.
Thus, it is WRONG.
olcott
Aug 21, 2022, 2:20:37 PM8/21/22
to
than the last instruction of a sequence of instructions then:
When we define a halt state as any state where there are no transitions
on the current input and current state then the correct and complete
simulation by H(P,P) of its input never enters a halt state of this
simulated input.
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
Richard Damon
Aug 21, 2022, 2:28:13 PM8/21/22
to
actually a computation.
a call to exit() is only an answer if done as part of the "whole
program" at which it is the program returning an answer to the
"Operating System"
A sub-function called a a function in a program that exits like this,
makes its sub-function not-a-computation.
Throwing an exection is really just a special form of return with just a
change of the default from the caller needing to handle the return
value, to the caller being able to just default to passing that return
value it its caller.
olcott
Aug 21, 2022, 8:45:22 PM8/21/22
to
machine description always provides the actual behavior specified by
this machine description.
That you (and others such as Ben) reject that the correct and complete
simulation by H(P,P) of its input does provide the actual behavior of
this input also rejects the notion of a UTM which you accept, thus you
(and all others holding this view such as Ben) contradict yourself
(themselves).
olcott
Aug 21, 2022, 8:48:45 PM8/21/22
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.
H0(Infinite_Loop) H(Infinite_Recursion, 0x777) and H(P,P) all do this
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.
correctly.
Richard Damon
Aug 21, 2022, 9:04:23 PM8/21/22
to
>
> That you (and others such as Ben) reject that the correct and complete
> simulation by H(P,P) of its input does provide the actual behavior of
> this input also rejects the notion of a UTM which you accept, thus you
> (and all others holding this view such as Ben) contradict yourself
> (themselves).
>
input to H when done by an actual pure simulator/UTM?
The only H that actually does a correct and complete simulation of its
input is the H that never answers, so it fails to be a decider.
All other H's that answer, do not do a correct and complet simulation of
their input and make incorrect predictions of the behavior of the x86
code given as the input to H because the presume the H that P calls does
not behave like that H actually does, and thus are wrong.
There is no such thing as "The behavior of H if it didn't abort its
simulation" because the "H" that refers to is NOT the H that the input
contains.
You are just proving your stupdity.
Please show the code for your H that actually does a complete and
correct simulation of the input AT THE x86 INSTRUCITON LEVEL, and
returns the answer.
Note, it is NOT allowed to replace any of the code that is part of the
PROGRAM P (which includes ALL the code that P calls) with something that
doesn't actually match the behavior of that code when actually executed.
Thus, since H(P,P) returns 0, you "simulation" needs to show all calls
to H(P,P) eventually returning 0.
You claim that the input to H(P,P) isn;t doesn't behave the same as the
input to Simulate(P,P) is just a LIE, as the input is IDENTICAL, and the
DEFINITION of a correct simulation is the behavior that that sequence of
instructions would do if applied to an actuall x86 processor.
If you want to claim a difference, you need to show the EXACT
instruction, properly simulated, where that difference occurs.
Your previous attemps, just show that you H doesn't correct "simulate"
the behavior of teh call to H(P,P) because H makes an INCORRECT
deduction about that call that doesn't match the actual behavior.
PUT UP OR SHUT UP.
Any "It is obvious" like claim needs a citation to someone who is
respected by the community agreeing with you, or it is just a LIE on you
part.
Richard Damon
Aug 21, 2022, 9:12:14 PM8/21/22
to
correctly matched.
>
> 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.
NEVER DOES a correct and complete sikmulation, that definition is
invalid as it is asking about the behavior of something that never happened.
What color shoe did Napolean walk on Mars with?
What you do is change the input program to do the test.
If you want to use a criteria like that you need to define your H as
taking 3 parameters, the program, its data, and a flag if you are doing
a halt decision or just a pure simulation.
P(x) call H(x,x,decide)
H needs to answer H(p,x,decide) return 1 if H(p,x,simulate) halts in
finite time, and return 0 if H(p,x,simulate) would never halt after an
unbounded number of steps.
That way you don't change the input when you ask if it would never halt
if not aborted.
Of course, you don't do that, because is shows that you H is wrong, as
P(P) WILL HALT, as show by H(P,P,simulate) halting if H(P,P,decide)
return 0, showing that is an incorrect answer.
>
> H0(Infinite_Loop) H(Infinite_Recursion, 0x777) and H(P,P) all do this
> correctly.
>
olcott
Aug 21, 2022, 9:37:39 PM8/21/22
to
H(P,P) then it is fine, otherwise it is not the same as the simulation
by H(P,P).
void P(ptr x)
{
int Halt_Status = Simulator(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
HERE: goto HERE;
return;
}
olcott
Aug 21, 2022, 9:44:16 PM8/21/22
to
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until H aborts its simulation*
Richard Damon
Aug 21, 2022, 11:14:14 PM8/21/22
to
instruction sequence specified by the code of P (and the routines it
calls) and has ZERO dependency on what happened before that call if P is
a Pure funcition, which it will if H was a pure function.
You claim that it matters is an admission that your H isn't actually a
pure function.
Note, I think from the code you provided, H actaully IS a pure function,
it is just incorrect about its decision of its input because it assumes
that H isn't actually a pure function.
FAIL.
Richard Damon
Aug 21, 2022, 11:24:24 PM8/21/22
to
abort, and if it doesn't, then the input never matched the pattern and H
fails to answer.
The key is that that ACTUAL correct simulation of that input would then be:
(@) Simulate(P,P) simulates P(P) that calls a simulated H(P,P)
(a) that simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until the H simulated in step (@) aborts its simulation*
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
(e) That simulated H returns 0 to the simulate P(P) in (@)
(f) That simulated P(P) returns and thus halts.
What step of that simulation is incorrect?
Which x86 instruction did it not simulate correctly?
Remember, you just provided in YOUR (a) - (d) a claimed correct exection
trace of H(P,P), so that trace is a correct part of the simulation of
the P(P) that calls that H(P,P)
If you disagree, prove otherwise and point out the ACTUAL INSTRUCTION
that the above doesn't match
PUT UP OR SHUT UP or be proved a liar.
Note, in your pattern, the beginning
"(a) H(P,P) simulates" isn't actually part of the simulation of the
input, as a correct simultion of an input is independent of what
simulates it, it just matters what rules have been defined for the
simulation.
You have fully defined that by stating it is an x86 simulation of the
code of P that has been provided. (Which must include the code of H, or
it doesn't actually specify the computation).
olcott
Aug 21, 2022, 11:27:21 PM8/21/22
to
{
P(P); // depends on the return value from H(P,P);
}
The input to H(P,P) that H correctly simulates cannot possibly depend on
the return value from H because this return value is unreachable by P:
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until H aborts its simulation*
simulated P and the executed P.
> if P is
> a Pure funcition, which it will if H was a pure function.
>
> You claim that it matters is an admission that your H isn't actually a
> pure function.
>
> Note, I think from the code you provided, H actaully IS a pure function,
> it is just incorrect about its decision of its input because it assumes
> that H isn't actually a pure function.
>
> FAIL.
>
>> void P(ptr x)
>> {
>> int Halt_Status = Simulator(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>>
>
Richard Damon
Aug 21, 2022, 11:37:58 PM8/21/22
to
the limitation of your algorithm, doesn't mean it gets to ignore it.
Not, Mr Flibble has shown a way that H CAN determine the behavior of P
based on the return value of H, even though H can simulate the path
through itself.
(As I pointed out a long time ago too).
>
> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...
> *Until H aborts its simulation*
>
> This dependency difference causes the different behavior between the
> simulated P and the executed P.
the value that H(P,P) returns, unless H(P,P) never returns a value to
ANYBODY.
Your H just gets it wrong because it "guesses" wrong because it used
unsound logic.
FAIL.
olcott
Aug 22, 2022, 10:25:22 AM8/22/22
to
Would the input simulated by H reach the final state of this input if H
never aborts its simulation of this input?
An answer of no always means that the input specifies a non-halting
sequence of instructions.
*Furthermore* because the input that H correctly simulates would never
stop running unless H aborts its simulation of this input and
It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.
behavior of its actual input that H cannot base its halt status decision
on the behavior of the direct execution of P(P).
This means that the standard definition of the halting function IS WRONG
because it directly contradicts other correct definitions.
olcott
Aug 22, 2022, 10:31:55 AM8/22/22
to
correctly return to its caller. People that believe that it can are as
wrong as if they disagreed with arithmetic.
If computer science says that a function called in finite recursion must
return to its caller then computer science is wrong, one might as well
have said the cats must be dogs.
>>
>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>> (b) that simulates P(P) that calls a simulated H(P,P)
>> (c) that simulates P(P) that calls a simulated H(P,P)
>> (d) that simulates P(P) that calls a simulated H(P,P)...
>> *Until H aborts its simulation*
>>
>> This dependency difference causes the different behavior between the
>> simulated P and the executed P.
>
> Nope, the CORRECT AND COMPLETE simulation of the input does depend on
> the value that H(P,P) returns, unless H(P,P) never returns a value to
> ANYBODY.
>
> Your H just gets it wrong because it "guesses" wrong because it used
> unsound logic.
>
You know that the correct and complete simulation by H(P,P) of its input
would never reach the final state of this input.
You also know that the correct and complete simulation of its input is
the correct measure of the actual behavior of this input:
It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.
Mikko
Aug 22, 2022, 10:55:43 AM8/22/22
to
On 2022-08-22 14:25:13 +0000, olcott said:
> The question is always:
> Would the input simulated by H reach the final state of this input if H
> never aborts its simulation of this input?
That is your qestion. The halting problem's question is "Does the Turing
> The question is always:
> Would the input simulated by H reach the final state of this input if H
> never aborts its simulation of this input?
machine T halt when given the input I?" and the problem itself is whether
there is a Turing machine that can always correctly answer that question.
> This means that the standard definition of the halting function IS
> WRONG because it directly contradicts other correct definitions.
by avoiding any use of the term "halting function". There are other
words you can use instead.
Mikko
olcott
Aug 22, 2022, 11:12:05 AM8/22/22
to
On 8/22/2022 9:55 AM, Mikko wrote:
> On 2022-08-22 14:25:13 +0000, olcott said:
>
>> The question is always:
>> Would the input simulated by H reach the final state of this input if
>> H never aborts its simulation of this input?
>
> That is your qestion. The halting problem's question is "Does the Turing
> machine T halt when given the input I?" and the problem itself is whether
> there is a Turing machine that can always correctly answer that question.
>
*The generic form of the question is*
> On 2022-08-22 14:25:13 +0000, olcott said:
>
>> The question is always:
>> Would the input simulated by H reach the final state of this input if
>> H never aborts its simulation of this input?
>
> That is your qestion. The halting problem's question is "Does the Turing
> machine T halt when given the input I?" and the problem itself is whether
> there is a Turing machine that can always correctly answer that question.
>
Does the finite string input specific a sequence of instruction that
reach their own final state?
It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.
The correct and complete simulation by H(P,P) of its input would never
reach its final state and halt, thus the input to H(P,P) specifies a
non-halting sequence of instructions.
>> This means that the standard definition of the halting function IS
>> WRONG because it directly contradicts other correct definitions.
>
> The definition is not wrong. You can avoid all problem in the definition
> by avoiding any use of the term "halting function". There are other
> words you can use instead.
>
> Mikko
>
The standard definition of the halting function sometimes requires the
>> WRONG because it directly contradicts other correct definitions.
>
> The definition is not wrong. You can avoid all problem in the definition
> by avoiding any use of the term "halting function". There are other
> words you can use instead.
>
> Mikko
>
halt status decision to be based on something other than the actual
behavior of the actual input, and in those cases IT IS WRONG!
int sum(int x, int y)
{
return x + y;
}
If sum(3,4) returned the sum of 5 + 7 we would know that it is wrong.
Likewise H(P,P) cannot be based on the behavior of the directly executed
P(P).
main()
{
P(P); // depends on the return value from H(P,P);
}
The input to H(P,P) that H correctly simulates cannot possibly depend on
the return value from H because this return value is unreachable by P:
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until H aborts its simulation*
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until H aborts its simulation*
This dependency difference causes the different behavior between the
simulated P and the executed P.
simulated P and the executed P.
olcott
Aug 22, 2022, 11:24:14 AM8/22/22
to
On 8/22/2022 10:11 AM, olcott wrote:
> On 8/22/2022 9:55 AM, Mikko wrote:
>> On 2022-08-22 14:25:13 +0000, olcott said:
>>
>>> The question is always:
>>> Would the input simulated by H reach the final state of this input if
>>> H never aborts its simulation of this input?
>>
>> That is your qestion. The halting problem's question is "Does the Turing
>> machine T halt when given the input I?" and the problem itself is whether
>> there is a Turing machine that can always correctly answer that question.
>>
>
> *The generic form of the question is*
> Does the finite string input specific a sequence of instruction that
> reach their own final state?
>
Does the finite string input SPECIFY a sequence of INSTRUCTIONS that
> On 8/22/2022 9:55 AM, Mikko wrote:
>> On 2022-08-22 14:25:13 +0000, olcott said:
>>
>>> The question is always:
>>> Would the input simulated by H reach the final state of this input if
>>> H never aborts its simulation of this input?
>>
>> That is your qestion. The halting problem's question is "Does the Turing
>> machine T halt when given the input I?" and the problem itself is whether
>> there is a Turing machine that can always correctly answer that question.
>>
>
> *The generic form of the question is*
> Does the finite string input specific a sequence of instruction that
> reach their own final state?
>
Mr Flibble
Aug 22, 2022, 12:21:41 PM8/22/22
to
is *not* infinitely recursive (as you have been told many times) so of
course it is quite valid for it to return a value to its caller. The
only thing that suffers from infinite recursion is your broken mess.
>
> If computer science says that a function called in finite recursion
> must return to its caller then computer science is wrong, one might
> as well have said the cats must be dogs.
to its caller is *by definition* not infinitely recursive.
The Flibble Signaling Halt Decider (TM) just works, your mess does not.
/Flibble
olcott
Aug 22, 2022, 1:04:18 PM8/22/22
to
concept of unreachable code:
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
HERE: goto HERE;
return;
}
{
Output("Input_Halts = ", H(P, P));
}
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until H aborts its simulation*
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until H aborts its simulation*
Mr Flibble
Aug 22, 2022, 1:15:06 PM8/22/22
to
On Mon, 22 Aug 2022 12:04:11 -0500
Virtually every reply you make now totally ignores what you are replying
to and instead is just regurgitation of the the same old shit.
I have shown on several occasions in replies to you that I fully
understand the concept of unreachable code.
Again: the Flibble Signaling Halt Decider (TM) is *NOT* recursive so
your traces don't apply to it, your traces only apply to your broken
mess which has to "abort" the infinite recursion which is YOUR design
mistake.
/Flibble
to and instead is just regurgitation of the the same old shit.
I have shown on several occasions in replies to you that I fully
understand the concept of unreachable code.
Again: the Flibble Signaling Halt Decider (TM) is *NOT* recursive so
your traces don't apply to it, your traces only apply to your broken
mess which has to "abort" the infinite recursion which is YOUR design
mistake.
/Flibble
olcott
Aug 22, 2022, 1:39:49 PM8/22/22
to
before the first recursive call is invoked, it remains an easily
verified fact that P specifies infinitely recursive simulation to every
simulating halt decider.
Mr Flibble
Aug 22, 2022, 1:43:45 PM8/22/22
to
On Mon, 22 Aug 2022 12:39:41 -0500
Obviously not a verified fact given the Flibble Signaling Halt
Decider (TM) is an example of a simulating halt decider that is *not*
recursive ergo there is no recursive simulation: instead there is a
forking simulation that allows the decider to return a value to its
caller in each fork.
/Flibble
Decider (TM) is an example of a simulating halt decider that is *not*
recursive ergo there is no recursive simulation: instead there is a
forking simulation that allows the decider to return a value to its
caller in each fork.
/Flibble
olcott
Aug 22, 2022, 1:50:28 PM8/22/22
to
no more and no less then this behavior results:
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until H aborts its simulation*
When H(P,P) simulates anything besides exactly what its input specifies
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until H aborts its simulation*
then its simulation is incorrect.
Mr Flibble
Aug 22, 2022, 1:53:52 PM8/22/22
to
On Mon, 22 Aug 2022 12:50:20 -0500
Nope, the definition of a halt decider does not specify that a
simulating halt decider must be recursive in nature.
If you disagree then provide a link to a peer reviewed paper which
states that a simulating halt decider must be recursive in nature.
/Flibble
simulating halt decider must be recursive in nature.
If you disagree then provide a link to a peer reviewed paper which
states that a simulating halt decider must be recursive in nature.
/Flibble
It is loading more messages.
0 new messages