When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
You don't get to redefine that meaning of the answers.
Sorry, you ar just proving you are a pathological liar that doesn't understand what truth is.
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
You don't get to redefine that meaning of the answers.
Sorry, you ar just proving you are a pathological liar that doesn't
understand what truth is.
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting, just
not by HHH, so "can not be decided" is not a correct answer.
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting,
just not by HHH, so "can not be decided" is not a correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting,
just not by HHH, so "can not be decided" is not a correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have been lying about working on the Halting Problem.
On 8/4/24 5:58 PM, olcott wrote:
On 8/4/2024 4:43 PM, Richard Damon wrote:
On 8/4/24 5:05 PM, olcott wrote:
On 8/4/2024 3:14 PM, Richard Damon wrote:
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>>
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about
halting, just not by HHH, so "can not be decided" is not a
correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have been
lying about working on the Halting Problem.
It does seem to refute Rice.
Nope, because your criteria in not a semantic property of the INPUT
(or it is trivial, as 0 is always a correct answer).
It is only allowed to answer 0 when when
(a) The input does not halt
(b) The input has a pathological relationship with the decider.
Which means it is not a property of the INPUT, but the input and the
decider.
On 8/4/24 5:05 PM, olcott wrote:
On 8/4/2024 3:14 PM, Richard Damon wrote:
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting,
just not by HHH, so "can not be decided" is not a correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have been
lying about working on the Halting Problem.
It does seem to refute Rice.
Nope, because your criteria in not a semantic property of the INPUT (or
it is trivial, as 0 is always a correct answer).
On 8/4/2024 3:14 PM, Richard Damon wrote:
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting,
just not by HHH, so "can not be decided" is not a correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have been
lying about working on the Halting Problem.
It does seem to refute Rice.
On 8/4/2024 4:43 PM, Richard Damon wrote:
On 8/4/24 5:05 PM, olcott wrote:
On 8/4/2024 3:14 PM, Richard Damon wrote:
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about
halting, just not by HHH, so "can not be decided" is not a correct >>>>>> answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have been
lying about working on the Halting Problem.
It does seem to refute Rice.
Nope, because your criteria in not a semantic property of the INPUT
(or it is trivial, as 0 is always a correct answer).
It is only allowed to answer 0 when when
(a) The input does not halt
(b) The input has a pathological relationship with the decider.
On 8/4/24 6:15 PM, olcott wrote:
On 8/4/2024 5:02 PM, Richard Damon wrote:
On 8/4/24 5:58 PM, olcott wrote:
On 8/4/2024 4:43 PM, Richard Damon wrote:
On 8/4/24 5:05 PM, olcott wrote:
On 8/4/2024 3:14 PM, Richard Damon wrote:
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>>>>
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider* >>>>>>>>>> 1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about
halting, just not by HHH, so "can not be decided" is not a
correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have
been lying about working on the Halting Problem.
It does seem to refute Rice.
Nope, because your criteria in not a semantic property of the INPUT
(or it is trivial, as 0 is always a correct answer).
It is only allowed to answer 0 when when
(a) The input does not halt
(b) The input has a pathological relationship with the decider.
Which means it is not a property of the INPUT, but the input and the
decider.
It is a property of the input.
(a) The input does
(b) The input has
But not of JUST the input.
On 8/4/2024 5:02 PM, Richard Damon wrote:
On 8/4/24 5:58 PM, olcott wrote:
On 8/4/2024 4:43 PM, Richard Damon wrote:
On 8/4/24 5:05 PM, olcott wrote:
On 8/4/2024 3:14 PM, Richard Damon wrote:
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>>>
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about
halting, just not by HHH, so "can not be decided" is not a
correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have been >>>>>> lying about working on the Halting Problem.
It does seem to refute Rice.
Nope, because your criteria in not a semantic property of the INPUT
(or it is trivial, as 0 is always a correct answer).
It is only allowed to answer 0 when when
(a) The input does not halt
(b) The input has a pathological relationship with the decider.
Which means it is not a property of the INPUT, but the input and the
decider.
It is a property of the input.
(a) The input does
(b) The input has
On 8/4/2024 5:31 PM, Richard Damon wrote:
On 8/4/24 6:15 PM, olcott wrote:
On 8/4/2024 5:02 PM, Richard Damon wrote:
On 8/4/24 5:58 PM, olcott wrote:
On 8/4/2024 4:43 PM, Richard Damon wrote:
On 8/4/24 5:05 PM, olcott wrote:
On 8/4/2024 3:14 PM, Richard Damon wrote:
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>>>>>
I made a mistake that I corrected on a forum that allows >>>>>>>>>>> editing: *Defining a correct halting decidability decider* >>>>>>>>>>> 1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about >>>>>>>>>> halting, just not by HHH, so "can not be decided" is not a >>>>>>>>>> correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have
been lying about working on the Halting Problem.
It does seem to refute Rice.
Nope, because your criteria in not a semantic property of the
INPUT (or it is trivial, as 0 is always a correct answer).
It is only allowed to answer 0 when when
(a) The input does not halt
(b) The input has a pathological relationship with the decider.
Which means it is not a property of the INPUT, but the input and the
decider.
It is a property of the input.
(a) The input does
(b) The input has
But not of JUST the input.
It is a semantic property of the input.
I don't care if you lie about it.
On 8/4/24 6:57 PM, olcott wrote:
On 8/4/2024 5:31 PM, Richard Damon wrote:
On 8/4/24 6:15 PM, olcott wrote:
On 8/4/2024 5:02 PM, Richard Damon wrote:
On 8/4/24 5:58 PM, olcott wrote:
On 8/4/2024 4:43 PM, Richard Damon wrote:
On 8/4/24 5:05 PM, olcott wrote:
On 8/4/2024 3:14 PM, Richard Damon wrote:
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>>>>>>
I made a mistake that I corrected on a forum that allows >>>>>>>>>>>> editing: *Defining a correct halting decidability decider* >>>>>>>>>>>> 1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about >>>>>>>>>>> halting, just not by HHH, so "can not be decided" is not a >>>>>>>>>>> correct answer.
A single universal decider can correctly determine whether >>>>>>>>>> or not an input could possibly be denial-of-service-attack. >>>>>>>>>> 0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have >>>>>>>>> been lying about working on the Halting Problem.
It does seem to refute Rice.
Nope, because your criteria in not a semantic property of the
INPUT (or it is trivial, as 0 is always a correct answer).
It is only allowed to answer 0 when when
(a) The input does not halt
(b) The input has a pathological relationship with the decider.
Which means it is not a property of the INPUT, but the input and
the decider.
It is a property of the input.
(a) The input does
(b) The input has
But not of JUST the input.
It is a semantic property of the input.
I don't care if you lie about it.
Nope, because it depends on the decider.
On 8/4/2024 6:25 PM, Richard Damon wrote:
On 8/4/24 6:57 PM, olcott wrote:
On 8/4/2024 5:31 PM, Richard Damon wrote:
On 8/4/24 6:15 PM, olcott wrote:
On 8/4/2024 5:02 PM, Richard Damon wrote:
On 8/4/24 5:58 PM, olcott wrote:
On 8/4/2024 4:43 PM, Richard Damon wrote:
On 8/4/24 5:05 PM, olcott wrote:
On 8/4/2024 3:14 PM, Richard Damon wrote:
On 8/4/24 3:33 PM, olcott wrote:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it >>>>>>>>>>>>>> does.
I made a mistake that I corrected on a forum that allows >>>>>>>>>>>>> editing: *Defining a correct halting decidability decider* >>>>>>>>>>>>> 1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about >>>>>>>>>>>> halting, just not by HHH, so "can not be decided" is not a >>>>>>>>>>>> correct answer.
A single universal decider can correctly determine whether >>>>>>>>>>> or not an input could possibly be denial-of-service-attack. >>>>>>>>>>> 0=yes does not halt or pathological self-reference
1=no halts
Which isn't halt deciding, so you are just admitting you have >>>>>>>>>> been lying about working on the Halting Problem.
It does seem to refute Rice.
Nope, because your criteria in not a semantic property of the
INPUT (or it is trivial, as 0 is always a correct answer).
It is only allowed to answer 0 when when
(a) The input does not halt
(b) The input has a pathological relationship with the decider.
Which means it is not a property of the INPUT, but the input and
the decider.
It is a property of the input.
(a) The input does
(b) The input has
But not of JUST the input.
It is a semantic property of the input.
I don't care if you lie about it.
Nope, because it depends on the decider.
(b) Cannot possibly exist unless it is a property
of the input.
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it.
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it. >>>>
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
It refutes Rice
On 8/5/24 9:46 AM, olcott wrote:
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:So it is NOT an halt decider. Case closed. You've lost your time
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference >>>>> is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it. >>>>>
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider >>>
for years, and made a lot of people lose their time too.
It refutes Rice
Nope, since the criteria is not a avalid criteria, as it is a subjective criteria, and NOT a property of JUST the input.
On 8/5/2024 5:59 PM, Richard Damon wrote:
On 8/5/24 9:46 AM, olcott wrote:
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is >>>>>> a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that >>>>>> the answer is not "does not halt" if the input halts. The difference >>>>>> is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers >>>>>> it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its
decider
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
It refutes Rice
Nope, since the criteria is not a avalid criteria, as it is a
subjective criteria, and NOT a property of JUST the input.
A freaking actual execution trace is not freaking subjective.
On 8/5/24 8:55 PM, olcott wrote:
On 8/5/2024 5:59 PM, Richard Damon wrote:
On 8/5/24 9:46 AM, olcott wrote:
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is >>>>>>> a subset of the requirements for "halt decider" but still require >>>>>>> that the answer is not "halts" if the input does not halt and that >>>>>>> the answer is not "does not halt" if the input halts. The difference >>>>>>> is that a "halt decider" is required to give one of these answers >>>>>>> for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that
answers it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its
decider
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
It refutes Rice
Nope, since the criteria is not a avalid criteria, as it is a
subjective criteria, and NOT a property of JUST the input.
A freaking actual execution trace is not freaking subjective.
If the trace depends on who does it, it is.
On 8/5/2024 8:32 PM, Richard Damon wrote:
On 8/5/24 8:55 PM, olcott wrote:
On 8/5/2024 5:59 PM, Richard Damon wrote:
On 8/5/24 9:46 AM, olcott wrote:
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is >>>>>>>> a subset of the requirements for "halt decider" but still require >>>>>>>> that the answer is not "halts" if the input does not halt and that >>>>>>>> the answer is not "does not halt" if the input halts. The
difference
is that a "halt decider" is required to give one of these answers >>>>>>>> for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that
answers it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its
decider
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
It refutes Rice
Nope, since the criteria is not a avalid criteria, as it is a
subjective criteria, and NOT a property of JUST the input.
A freaking actual execution trace is not freaking subjective.
If the trace depends on who does it, it is.
There is no freaking subjectively to a sequence of x86 instructions.
DDD correctly emulated by every HHH never reaches its own "return".
This as as much a tautology as 2 + 3 = 5.
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting,
just not by HHH, so "can not be decided" is not a correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it. >>>>
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
It refutes Rice
On 2024-08-04 19:33:36 +0000, olcott said:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting,
just not by HHH, so "can not be decided" is not a correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Conventionally the value 0 is used for "no" (for example, no errors)
and value 1 for "yes". If there are different "yes" results other
numbers in addition to 1 can be used. For example, for the question
"is there anu errors?" the number may identify the error. For a
partial halt decider the best values are
-1 = does not halt
0 = not determined
1 = halts.
In C the value 0 is interpreted as false and every other number,
positive or negative, is interpreted as true in every context
where a boolean value is expected.
On 2024-08-05 11:50:53 +0000, olcott said:
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider
There is no "its decider". The identity of the decider is not a property
of the input.
On 2024-08-05 13:46:11 +0000, olcott said:
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:So it is NOT an halt decider. Case closed. You've lost your time
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference >>>>> is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it. >>>>>
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider >>>
for years, and made a lot of people lose their time too.
It refutes Rice
No, it does not. Nothing is refuted as long as you have not proven
anything.
On 8/7/2024 1:59 AM, Mikko wrote:
On 2024-08-04 19:33:36 +0000, olcott said:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting,
just not by HHH, so "can not be decided" is not a correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Conventionally the value 0 is used for "no" (for example, no errors)
and value 1 for "yes". If there are different "yes" results other
A Conventional halt decider is 1 for halts and 0 for does not halt.
0 also means input has pathological relationship to decider.
In other words 1 means good input and 0 means bad input.
numbers in addition to 1 can be used. For example, for the question
"is there anu errors?" the number may identify the error. For a
partial halt decider the best values are
-1 = does not halt
0 = not determined
1 = halts.
In C the value 0 is interpreted as false and every other number,
positive or negative, is interpreted as true in every context
where a boolean value is expected.
I have known that since K&R was the standard.
I met Bjarne Stroustrup we he went around the country
promoting his new C++ language at the local universities.
He was a tee shirt and blue jeans kind of guy.
On 8/7/2024 2:04 AM, Mikko wrote:
On 2024-08-05 11:50:53 +0000, olcott said:
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it. >>>>
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider
There is no "its decider". The identity of the decider is not a property
of the input.
1 = halts = good input = decidable
0 = (not halts or pathological) = bad input = not decidable as halting
On 8/7/2024 2:06 AM, Mikko wrote:
On 2024-08-05 13:46:11 +0000, olcott said:
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is >>>>>> a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that >>>>>> the answer is not "does not halt" if the input halts. The difference >>>>>> is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers >>>>>> it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its
decider
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
It refutes Rice
No, it does not. Nothing is refuted as long as you have not proven
anything.
1 = halts = good input = decidable
0 = (not halts or pathological) = bad input = not decidable as halting
HHH decides a non-trivial semantic property of its input.
On 8/7/2024 1:59 AM, Mikko wrote:
On 2024-08-04 19:33:36 +0000, olcott said:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does.
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting,
just not by HHH, so "can not be decided" is not a correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Conventionally the value 0 is used for "no" (for example, no errors)
and value 1 for "yes". If there are different "yes" results other
A Conventional halt decider is 1 for halts and 0 for does not halt.
0 also means input has pathological relationship to decider.
In other words 1 means good input and 0 means bad input.
On 8/7/2024 2:06 AM, Mikko wrote:
On 2024-08-05 13:46:11 +0000, olcott said:
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:So it is NOT an halt decider. Case closed. You've lost your time
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is >>>>>> a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that >>>>>> the answer is not "does not halt" if the input halts. The difference >>>>>> is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it. >>>>>>
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider >>>>
for years, and made a lot of people lose their time too.
It refutes Rice
No, it does not. Nothing is refuted as long as you have not proven anything. >>
1 = halts = good input = decidable
0 = (not halts or pathological) = bad input = not decidable as halting
HHH decides a non-trivial semantic property of its input.
On 8/7/2024 2:04 AM, Mikko wrote:
On 2024-08-05 11:50:53 +0000, olcott said:
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers it. >>>>
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider
There is no "its decider". The identity of the decider is not a property
of the input.
1 = halts = good input = decidable
0 = (not halts or pathological) = bad input = not decidable as halting
On 8/7/2024 2:06 AM, Mikko wrote:
On 2024-08-05 13:46:11 +0000, olcott said:
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is >>>>>> a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that >>>>>> the answer is not "does not halt" if the input halts. The difference >>>>>> is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that answers >>>>>> it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its
decider
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
It refutes Rice
No, it does not. Nothing is refuted as long as you have not proven
anything.
1 = halts = good input = decidable
0 = (not halts or pathological) = bad input = not decidable as halting
HHH decides a non-trivial semantic property of its input.
*Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.
On 8/8/2024 8:27 AM, Python wrote:
Le 08/08/2024 à 15:21, Peter Olcott a écrit :
...
*Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.
"well behaved" is not a property of programes or Turing Machines.
*It is a Stipulative definition* https://en.wikipedia.org/wiki/Stipulative_definition
I can stipulate that an input has the semantic property
of has_not_ate_lunch_yet where has_not_ate_lunch_yet means
that the input halts and ~has_not_ate_lunch_yet means the
input cannot be determined to halt.
"well behaved" is a property of human beings that YOU do not have.
You lie, you deceive, you abuse, you commit blasphemy in courts and
collect child pornography [this is documented].
As a bigot you believe that this can bring you to Hell.
Fortunately there is no God, no Hell, so you'll just vanished into
oblivion.
On 8/8/2024 2:17 AM, Mikko wrote:
On 2024-08-07 13:23:54 +0000, olcott said:
On 8/7/2024 2:06 AM, Mikko wrote:
On 2024-08-05 13:46:11 +0000, olcott said:
On 8/5/2024 8:44 AM, Python wrote:
Le 05/08/2024 à 13:50, olcott a écrit :
On 8/5/2024 3:08 AM, Mikko wrote:
On 2024-08-04 14:46:02 +0000, olcott said:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
That is called a "partial halt decider". The set of requirements is >>>>>>>> a subset of the requirements for "halt decider" but still require >>>>>>>> that the answer is not "halts" if the input does not halt and that >>>>>>>> the answer is not "does not halt" if the input halts. The
difference
is that a "halt decider" is required to give one of these answers >>>>>>>> for every input but a "partial halt decider" is not.
For every computation there is a partial halt decider that
answers it.
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its
decider
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
It refutes Rice
No, it does not. Nothing is refuted as long as you have not proven
anything.
1 = halts = good input = decidable
0 = (not halts or pathological) = bad input = not decidable as halting
HHH decides a non-trivial semantic property of its input.
Your "not decidable as halting" is not a property of input. Another
partial decider may be able to determine that the input is halting
and therefore decidable as halting.
https://en.wikipedia.org/wiki/Stipulative_definition
The stipulative definition of the semantic property
has_not_ate_lunch_yet means that the input halts and
~has_not_ate_lunch_yet means the input cannot be
determined to halt.
This is can be used to detect and reject denial of
service attacks that have targeted the detector.
On 8/8/2024 2:12 AM, Mikko wrote:
On 2024-08-07 13:12:43 +0000, olcott said:
On 8/7/2024 1:59 AM, Mikko wrote:
On 2024-08-04 19:33:36 +0000, olcott said:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting, >>>>>> just not by HHH, so "can not be decided" is not a correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Conventionally the value 0 is used for "no" (for example, no errors)
and value 1 for "yes". If there are different "yes" results other
A Conventional halt decider is 1 for halts and 0 for does not halt.
That is because conventionally the question is "Does thing computation
halt?" so "yes" means the same as "halts".
0 also means input has pathological relationship to decider.
It cannot mean both "does not halt" and "has pathological relationship
to decider". Those two don't mean the same.
In other words 1 means good input and 0 means bad input.
That is not the same in other words.
An input is good in one sense if it specifies a computation and bad if
it does not. In the latter case the decider is free to do anything as
the input is not in its scope.
In another sense an input is good if it is as the user wants it to be.
If the user wants a non-halting computation then a halting one is bad.
*Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.
On 8/8/2024 8:27 AM, Python wrote:
Le 08/08/2024 à 15:21, Peter Olcott a écrit :
...
*Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.
"well behaved" is not a property of programes or Turing Machines.
*It is a Stipulative definition* https://en.wikipedia.org/wiki/Stipulative_definition
I can stipulate that an input has the semantic property
of has_not_ate_lunch_yet where has_not_ate_lunch_yet means
that the input halts and ~has_not_ate_lunch_yet means the
input cannot be determined to halt.
"well behaved" is a property of human beings that YOU do not have.
You lie, you deceive, you abuse, you commit blasphemy in courts and
collect child pornography [this is documented].
As a bigot you believe that this can bring you to Hell.
Fortunately there is no God, no Hell, so you'll just vanished into
oblivion.
On 8/9/2024 3:56 AM, Mikko wrote:
On 2024-08-08 13:21:57 +0000, olcott said:
On 8/8/2024 2:12 AM, Mikko wrote:
On 2024-08-07 13:12:43 +0000, olcott said:
On 8/7/2024 1:59 AM, Mikko wrote:
On 2024-08-04 19:33:36 +0000, olcott said:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>>>
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about
halting, just not by HHH, so "can not be decided" is not a
correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Conventionally the value 0 is used for "no" (for example, no errors) >>>>>> and value 1 for "yes". If there are different "yes" results other
A Conventional halt decider is 1 for halts and 0 for does not halt.
That is because conventionally the question is "Does thing computation >>>> halt?" so "yes" means the same as "halts".
0 also means input has pathological relationship to decider.
It cannot mean both "does not halt" and "has pathological relationship >>>> to decider". Those two don't mean the same.
In other words 1 means good input and 0 means bad input.
That is not the same in other words.
An input is good in one sense if it specifies a computation and bad if >>>> it does not. In the latter case the decider is free to do anything as
the input is not in its scope.
In another sense an input is good if it is as the user wants it to be. >>>> If the user wants a non-halting computation then a halting one is bad. >>>>
*Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.
You don't need any meaning for "well-behaved". A program is good if
it satisfies its purpose.
https://en.wikipedia.org/wiki/Stipulative_definition
has_eaten_lunch is a Stipulative_definition defined below:
A program is said to have the non trivial semantic
property of has_eaten_lunch when it halts and
~has_eaten_lunch when it cannot be correctly determined
to halt. This defeat Rice's Theorem.
On 8/9/2024 3:56 AM, Mikko wrote:
On 2024-08-08 13:21:57 +0000, olcott said:
On 8/8/2024 2:12 AM, Mikko wrote:
On 2024-08-07 13:12:43 +0000, olcott said:
On 8/7/2024 1:59 AM, Mikko wrote:
On 2024-08-04 19:33:36 +0000, olcott said:
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:A single universal decider can correctly determine whether
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>>>
I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting, >>>>>>>> just not by HHH, so "can not be decided" is not a correct answer. >>>>>>>
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Conventionally the value 0 is used for "no" (for example, no errors) >>>>>> and value 1 for "yes". If there are different "yes" results other
A Conventional halt decider is 1 for halts and 0 for does not halt.
That is because conventionally the question is "Does thing computation >>>> halt?" so "yes" means the same as "halts".
0 also means input has pathological relationship to decider.
It cannot mean both "does not halt" and "has pathological relationship >>>> to decider". Those two don't mean the same.
In other words 1 means good input and 0 means bad input.
That is not the same in other words.
An input is good in one sense if it specifies a computation and bad if >>>> it does not. In the latter case the decider is free to do anything as
the input is not in its scope.
In another sense an input is good if it is as the user wants it to be. >>>> If the user wants a non-halting computation then a halting one is bad. >>>>
*Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.
You don't need any meaning for "well-behaved". A program is good if
it satisfies its purpose.
https://en.wikipedia.org/wiki/Stipulative_definition
has_eaten_lunch is a Stipulative_definition defined below:
A program is said to have the non trivial semantic
property of has_eaten_lunch when it halts and
~has_eaten_lunch when it cannot be correctly determined
to halt. This defeat Rice's Theorem.
On 8/10/2024 3:20 AM, Mikko wrote:
On 2024-08-09 13:47:34 +0000, olcott said:
On 8/9/2024 3:56 AM, Mikko wrote:
On 2024-08-08 13:21:57 +0000, olcott said:
On 8/8/2024 2:12 AM, Mikko wrote:
On 2024-08-07 13:12:43 +0000, olcott said:
On 8/7/2024 1:59 AM, Mikko wrote:That is because conventionally the question is "Does thing
On 2024-08-04 19:33:36 +0000, olcott said:A Conventional halt decider is 1 for halts and 0 for does not halt. >>>>>>
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>>>>>
I made a mistake that I corrected on a forum that allows >>>>>>>>>>> editing: *Defining a correct halting decidability decider* >>>>>>>>>>> 1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about >>>>>>>>>> halting, just not by HHH, so "can not be decided" is not a >>>>>>>>>> correct answer.
A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Conventionally the value 0 is used for "no" (for example, no
errors)
and value 1 for "yes". If there are different "yes" results other >>>>>>>
computation
halt?" so "yes" means the same as "halts".
0 also means input has pathological relationship to decider.
It cannot mean both "does not halt" and "has pathological
relationship
to decider". Those two don't mean the same.
In other words 1 means good input and 0 means bad input.
That is not the same in other words.
An input is good in one sense if it specifies a computation and
bad if
it does not. In the latter case the decider is free to do anything as >>>>>> the input is not in its scope.
In another sense an input is good if it is as the user wants it to >>>>>> be.
If the user wants a non-halting computation then a halting one is
bad.
*Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.
You don't need any meaning for "well-behaved". A program is good if
it satisfies its purpose.
https://en.wikipedia.org/wiki/Stipulative_definition
has_eaten_lunch is a Stipulative_definition defined below:
A program is said to have the non trivial semantic
property of has_eaten_lunch when it halts and
~has_eaten_lunch when it cannot be correctly determined
to halt. This defeat Rice's Theorem.
that is not a useful stipulation. And there is no way to correctly
determine that it is not possible to determine whether a computation
halts.
1=halts
0=does not halt or pathological relationship to decider
On 8/10/2024 6:20 AM, Richard Damon wrote:
On 8/10/24 7:03 AM, olcott wrote:Weasel words. DDD does specify non-halting behavior to HHH.
On 8/10/2024 3:20 AM, Mikko wrote:
On 2024-08-09 13:47:34 +0000, olcott said:
On 8/9/2024 3:56 AM, Mikko wrote:
On 2024-08-08 13:21:57 +0000, olcott said:
On 8/8/2024 2:12 AM, Mikko wrote:
On 2024-08-07 13:12:43 +0000, olcott said:
On 8/7/2024 1:59 AM, Mikko wrote:
On 2024-08-04 19:33:36 +0000, olcott said:A Conventional halt decider is 1 for halts and 0 for does not >>>>>>>>> halt.
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it >>>>>>>>>>>>>> does.
I made a mistake that I corrected on a forum that allows >>>>>>>>>>>>> editing: *Defining a correct halting decidability decider* >>>>>>>>>>>>> 1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about >>>>>>>>>>>> halting, just not by HHH, so "can not be decided" is not a >>>>>>>>>>>> correct answer.
A single universal decider can correctly determine whether >>>>>>>>>>> or not an input could possibly be denial-of-service-attack. >>>>>>>>>>> 0=yes does not halt or pathological self-reference
1=no halts
Conventionally the value 0 is used for "no" (for example, no >>>>>>>>>> errors)
and value 1 for "yes". If there are different "yes" results other >>>>>>>>>
That is because conventionally the question is "Does thing
computation
halt?" so "yes" means the same as "halts".
0 also means input has pathological relationship to decider.
It cannot mean both "does not halt" and "has pathological
relationship
to decider". Those two don't mean the same.
In other words 1 means good input and 0 means bad input.
That is not the same in other words.
An input is good in one sense if it specifies a computation and >>>>>>>> bad if
it does not. In the latter case the decider is free to do
anything as
the input is not in its scope.
In another sense an input is good if it is as the user wants it >>>>>>>> to be.
If the user wants a non-halting computation then a halting one >>>>>>>> is bad.
*Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.
You don't need any meaning for "well-behaved". A program is good if >>>>>> it satisfies its purpose.
https://en.wikipedia.org/wiki/Stipulative_definition
has_eaten_lunch is a Stipulative_definition defined below:
A program is said to have the non trivial semantic
property of has_eaten_lunch when it halts and
~has_eaten_lunch when it cannot be correctly determined
to halt. This defeat Rice's Theorem.
that is not a useful stipulation. And there is no way to correctly
determine that it is not possible to determine whether a computation
halts.
1=halts
0=does not halt or pathological relationship to decider
Subjective Requirmeent, thus not a property of JUST the input.
anyone that says otherwise is not telling the truth.
On 8/10/2024 3:20 AM, Mikko wrote:
On 2024-08-09 13:47:34 +0000, olcott said:
On 8/9/2024 3:56 AM, Mikko wrote:
On 2024-08-08 13:21:57 +0000, olcott said:
On 8/8/2024 2:12 AM, Mikko wrote:
On 2024-08-07 13:12:43 +0000, olcott said:
On 8/7/2024 1:59 AM, Mikko wrote:That is because conventionally the question is "Does thing computation >>>>>> halt?" so "yes" means the same as "halts".
On 2024-08-04 19:33:36 +0000, olcott said:A Conventional halt decider is 1 for halts and 0 for does not halt. >>>>>>
On 8/4/2024 2:05 PM, Richard Damon wrote:
On 8/4/24 2:49 PM, olcott wrote:A single universal decider can correctly determine whether
On 8/4/2024 1:38 PM, Richard Damon wrote:
On 8/4/24 10:46 AM, olcott wrote:
When we define an input that does the opposite of whatever >>>>>>>>>>>>> value that its halt decider reports there is a way for the >>>>>>>>>>>>> halt decider to report correctly.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
But false indicates that the input does not halt, but it does. >>>>>>>>>>>>
I made a mistake that I corrected on a forum that allows >>>>>>>>>>> editing: *Defining a correct halting decidability decider* >>>>>>>>>>> 1=input does halt
0=input cannot be decided to halt
And thus, not a halt decider.
Sorry, you are just showing your ignorance.
And, the problem is that a given DD *CAN* be decided about halting, >>>>>>>>>> just not by HHH, so "can not be decided" is not a correct answer. >>>>>>>>>
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no halts
Conventionally the value 0 is used for "no" (for example, no errors) >>>>>>>> and value 1 for "yes". If there are different "yes" results other >>>>>>>
0 also means input has pathological relationship to decider.
It cannot mean both "does not halt" and "has pathological relationship >>>>>> to decider". Those two don't mean the same.
In other words 1 means good input and 0 means bad input.
That is not the same in other words.
An input is good in one sense if it specifies a computation and bad if >>>>>> it does not. In the latter case the decider is free to do anything as >>>>>> the input is not in its scope.
In another sense an input is good if it is as the user wants it to be. >>>>>> If the user wants a non-halting computation then a halting one is bad. >>>>>>
*Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.
You don't need any meaning for "well-behaved". A program is good if
it satisfies its purpose.
https://en.wikipedia.org/wiki/Stipulative_definition
has_eaten_lunch is a Stipulative_definition defined below:
A program is said to have the non trivial semantic
property of has_eaten_lunch when it halts and
~has_eaten_lunch when it cannot be correctly determined
to halt. This defeat Rice's Theorem.
that is not a useful stipulation. And there is no way to correctly
determine that it is not possible to determine whether a computation
halts.
1=halts
0=does not halt or pathological relationship to decider
On 8/11/2024 1:24 AM, Mikko wrote:
On 2024-08-10 11:03:31 +0000, olcott said:
1=halts
0=does not halt or pathological relationship to decider
Which does not use the stipulation and therefore does not demonstrate
its usefulńess.
That a computation has a pathological relationship to some decider
does not prevent another partial haltdecider from determinig whther
it halts.
void DDD()
{
HHH(DDD);
return;
}
A pathological relationship to this decider <is>
a non-trivial semantic property of this input.
A correct halt decider is a Turing machine T with one accept state and
one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops.
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y does not eventually halt,
the execution of T eventually ends up in the reject state and then stops.
A correct halt decider is a Turing machine T with one accept state and
one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops.
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y does not eventually halt,
the execution of T eventually ends up in the reject state and then
stops.
On 9/3/2024 3:44 AM, Mikko wrote:What would those assumptions be?
On 2024-09-02 16:06:11 +0000, olcott said:That is why I made the isomorphic x86utm system.
A correct halt decider is a Turing machine T with one accept state andYour "definition" fails to specify "encoding". There is no standard
one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops.
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y does not eventually halt,
the execution of T eventually ends up in the reject state and then
stops.
encoding of Turing machines and tape contents.
By failing to have such a concrete system all kinds of false assumptions cannot be refuted.
The behavior of DDD emulated by HHH** <is> different than the behaviorHow can the same code have different semantics?
of the directly executed DDD** **according to the semantics of the x86 language
HHH is required to report on the behavior tat its finite string input specifies even when this requires HHH to emulate itself emulating DDD.The input specifies an aborting HHH - which you don’t simulate.
DDD never halts unless it reaches its own final halt state. The factOther than that DDD calls HHH?
that the executed HHH halts has nothing to do with this.
HHH is not allowed to report on the computation that itself is contained within.Then it is only partial, and doesn’t even solve the case it was built for.
Except for the case of pathological self-reference the behavior of the directly executed machine M is always the same as the correctlyThat sure sounds like a mistake to me.
simulated finite string ⟨M⟩.
That no one has noticed that they can differ does not create an axiomThey were never allowed, that was the definition.
where they are not allowed to differ.
No one noticed that they differ only because everyone rejected the ideaI think after 3 years that excuse has grown a bit stale.
of a simulating halt decider out-of-hand without review.
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state
and one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops.
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y does not eventually halt,
the execution of T eventually ends up in the reject state and then
stops.
Your "definition" fails to specify "encoding". There is no standard
encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
The behavior of DDD emulated by HHH** <is> different
than the behavior of the directly executed DDD**
**according to the semantics of the x86 language
HHH is required to report on the behavior tat its finite
string input specifies even when this requires HHH
to emulate itself emulating DDD.
DDD never halts unless it reaches its own final
halt state. The fact that the executed HHH halts
has nothing to do with this.
HHH is not allowed to report on the computation that
itself is contained within.
Except for the case of pathological self-reference the
behavior of the directly executed machine M is always
the same as the correctly simulated finite string ⟨M⟩.
That no one has noticed that they can differ does not
create an axiom where they are not allowed to differ.
No one noticed that they differ only because everyone
rejected the idea of a simulating halt decider out-of-hand
without review.
On 9/3/2024 1:53 PM, joes wrote:How is it ignored?
Am Tue, 03 Sep 2024 08:17:56 -0500 schrieb olcott:
On 9/3/2024 3:44 AM, Mikko wrote:What would those assumptions be?
On 2024-09-02 16:06:11 +0000, olcott said:That is why I made the isomorphic x86utm system.
Your "definition" fails to specify "encoding". There is no standard
encoding of Turing machines and tape contents.
By failing to have such a concrete system all kinds of false
assumptions cannot be refuted.
The pathological relationship between DDD and HHH really cannot beThe behavior of DDD emulated by HHH** <is> different than the behaviorHow can the same code have different semantics?
of the directly executed DDD** **according to the semantics of the x86
language
simply ignored as if it does not exist.
I thought HHH returned „DDD doesn’t halt, so I aborted it”?void DDD()HHH is required to report on the behavior tat its finite string inputThe input specifies an aborting HHH - which you don’t simulate.
specifies even when this requires HHH to emulate itself emulating DDD.
{
HHH(DDD);
OutputString("This code is unreachable by DDD emulated by HHH");
}
It has complete information, so it must do something wrong.DDD never halts unless it reaches its own final halt state. The factOther than that DDD calls HHH?
that the executed HHH halts has nothing to do with this.
sum(3,4) is not allowed to report on the sum of 5 + 6 for the sameHHH is not allowed to report on the computation that itself isThen it is only partial, and doesn’t even solve the case it was built
contained within.
for.
reason. HHH(DDD) cannot report on behavior that it cannot see.
HHH cannot correctly report on the AFTER-THE-FACT behavior that it has aborted its simulation BEFORE-THE-FACT.Can you expand on this?
Understandable. Have you tried apologising?Except for the case of pathological self-reference the behavior of theThat sure sounds like a mistake to me.
directly executed machine M is always the same as the correctly
simulated finite string ⟨M⟩.
I initially took disagreeing with this as despicable lying bastards
playing sadistic head games.
I called Ben this and that is why he is mad at me.
I’d rather believe the textbooks than your definition.When you make a definition that halt deciders compute the mapping fromThat no one has noticed that they can differ does not create an axiomThey were never allowed, that was the definition.
where they are not allowed to differ.
their inputs to the behavior that these inputs specify
and textbooks say things that seem to disagree with definition then
gullible sheep will agree with the textbooks.
The input exists independently of its simulation.No one noticed that they differ only because everyone rejected theI think after 3 years that excuse has grown a bit stale.
idea of a simulating halt decider out-of-hand without review.
For three freaking years the gullible sheep on this forum continue to
believe that the pathological relationship of the decider to its input
does not change the behavior of this input
*EVEN WHEN IT IS CONCLUSIVELY PROVED THAT IT DOES CHANGE THIS BEHAVIOR*Empirical evidence can be flawed.
On 9/3/2024 1:53 PM, joes wrote:
Am Tue, 03 Sep 2024 08:17:56 -0500 schrieb olcott:
On 9/3/2024 3:44 AM, Mikko wrote:What would those assumptions be?
On 2024-09-02 16:06:11 +0000, olcott said:That is why I made the isomorphic x86utm system.
A correct halt decider is a Turing machine T with one accept state and >>>>> one reject state such that:Your "definition" fails to specify "encoding". There is no standard
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a >>>>> real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops. >>>>> If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a >>>>> real machine X with initial tape contents Y does not eventually halt, >>>>> the execution of T eventually ends up in the reject state and then
stops.
encoding of Turing machines and tape contents.
By failing to have such a concrete system all kinds of false assumptions >>> cannot be refuted.
The behavior of DDD emulated by HHH** <is> different than the behaviorHow can the same code have different semantics?
of the directly executed DDD** **according to the semantics of the x86
language
The pathological relationship between DDD and HHH really
cannot be simply ignored as if it does not exist.
HHH is required to report on the behavior tat its finite string inputThe input specifies an aborting HHH - which you don’t simulate.>
specifies even when this requires HHH to emulate itself emulating DDD.
void DDD()
{
HHH(DDD);
OutputString("This code is unreachable by DDD emulated by HHH");
}
DDD never halts unless it reaches its own final halt state. The factOther than that DDD calls HHH?
that the executed HHH halts has nothing to do with this.
HHH is not allowed to report on the computation that itself is contained >>> within.Then it is only partial, and doesn’t even solve the case it was built
for.
int sum(int x, int y);
sum(3,4) is not allowed to report on the sum of 5 + 6
for the same reason. HHH(DDD) cannot report on behavior
that it cannot see.
HHH cannot correctly report on the AFTER-THE-FACT
behavior that it has aborted its simulation BEFORE-THE-FACT.
Except for the case of pathological self-reference the behavior of the
directly executed machine M is always the same as the correctly
simulated finite string ⟨M⟩.
That sure sounds like a mistake to me.
THE EXECUTION TRACE HAS ALWAYS PROVED THAT I AM CORRECT
FOR THREE FREAKING YEARS all the way back when it was
P correctly emulated by D.
IT REMAINS A VERIFIED FACT THAT DDD EMULATED BY HHH CANNOT
POSSIBLY REACH ITS OWN FINAL HALT STATE,
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state
and one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops.
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y does not eventually halt,
the execution of T eventually ends up in the reject state and then
stops.
Your "definition" fails to specify "encoding". There is no standard
encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
The behavior of DDD emulated by HHH** <is> different
than the behavior of the directly executed DDD**
**according to the semantics of the x86 language
HHH is required to report on the behavior tat its finite
string input specifies even when this requires HHH
to emulate itself emulating DDD.
DDD never halts unless it reaches its own final
halt state. The fact that the executed HHH halts
has nothing to do with this.
HHH is not allowed to report on the computation that
itself is contained within.
Except for the case of pathological self-reference the
behavior of the directly executed machine M is always
the same as the correctly simulated finite string ⟨M⟩.
That no one has noticed that they can differ does not
create an axiom where they are not allowed to differ.
No one noticed that they differ only because everyone
rejected the idea of a simulating halt decider out-of-hand
without review.
On 9/4/2024 5:40 AM, Fred. Zwarts wrote:
Op 03.sep.2024 om 21:54 schreef olcott:
On 9/3/2024 1:53 PM, joes wrote:
Am Tue, 03 Sep 2024 08:17:56 -0500 schrieb olcott:
On 9/3/2024 3:44 AM, Mikko wrote:What would those assumptions be?
On 2024-09-02 16:06:11 +0000, olcott said:That is why I made the isomorphic x86utm system.
A correct halt decider is a Turing machine T with one acceptYour "definition" fails to specify "encoding". There is no standard >>>>>> encoding of Turing machines and tape contents.
state and
one reject state such that:
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y eventually halts, the >>>>>>> execution of T eventually ends up in the accept state and then
stops.
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y does not eventually
halt,
the execution of T eventually ends up in the reject state and then >>>>>>> stops.
By failing to have such a concrete system all kinds of false
assumptions
cannot be refuted.
The behavior of DDD emulated by HHH** <is> different than the behavior >>>>> of the directly executed DDD** **according to the semantics of the x86 >>>>> languageHow can the same code have different semantics?
The pathological relationship between DDD and HHH really
cannot be simply ignored as if it does not exist.
HHH is required to report on the behavior tat its finite string input >>>>> specifies even when this requires HHH to emulate itself emulating DDD. >>> > The input specifies an aborting HHH - which you don’t simulate.>
void DDD()
{
HHH(DDD);
OutputString("This code is unreachable by DDD emulated by HHH");
}
DDD never halts unless it reaches its own final halt state. The fact >>>>> that the executed HHH halts has nothing to do with this.Other than that DDD calls HHH?
HHH is not allowed to report on the computation that itself isThen it is only partial, and doesn’t even solve the case it was
contained
within.
built for.
int sum(int x, int y);
sum(3,4) is not allowed to report on the sum of 5 + 6
for the same reason. HHH(DDD) cannot report on behavior
that it cannot see.
Exactly, so it should not report on halting behaviour if its stops the
simulation before the simulation could halt.
It is very stupid to say that when this proves that DDD emulated by HHH cannot possibly reach its final halt state. https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
If the simulator prevents the simulation to halt, then there is no
reason to report about the halting behaviour.
HHH cannot correctly report on the AFTER-THE-FACT
behavior that it has aborted its simulation BEFORE-THE-FACT.
Olcott seems to forget that the action to abort was programmed already
BEFORE the abort took place. So, the simulated HHH was programmed to
see the 'special condition' and abort, BEFORE the simulating HHH
aborted it.
It is incorrect to assume that the abort code that is present BEFORE
the abort takes place, would not be executed in the simulated program,
only because the simulation has not yet reached it.
In other words, before-the-fact of the abort, the simulation did not
halt and there is no reason to decide that there is non-halting
behaviour. So, the only reason to decide about the halting behaviour
is found in the code that would be executed after-the-fact. And there
we find the code to see the detection of a 'special condition' and the
abort.
Except for the case of pathological self-reference the behavior of the >>>>> directly executed machine M is always the same as the correctly
simulated finite string ⟨M⟩.
That sure sounds like a mistake to me.
THE EXECUTION TRACE HAS ALWAYS PROVED THAT I AM CORRECT
FOR THREE FREAKING YEARS all the way back when it was
P correctly emulated by D.
No, it has always shown that the abort was too soon, one cycle before
the simulated HHH would reach the code to see the 'special condition',
after which it would abort and return.
IT REMAINS A VERIFIED FACT THAT DDD EMULATED BY HHH CANNOT
POSSIBLY REACH ITS OWN FINAL HALT STATE,
Exactly, I have repeated this many times, because it proves that the
simulation is incorrect.
HHH cannot possibly simulate itself correctly up to the end. That
there is an end is proved by the direct executions, by the simulations
of the world class simulator and even by HHH1.
The meaning of the input, a finite string that describes the program,
is fixed by the semantics of the x86 language. It does not depend on
who or what interprets it.
But olcott thinks he can change the meaning of it by using a crippled
simulator that is unable to reach the end of the simulation.
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state and
one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops.
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y does not eventually halt,
the execution of T eventually ends up in the reject state and then
stops.
Your "definition" fails to specify "encoding". There is no standard
encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
The behavior of DDD emulated by HHH** <is> different
than the behavior of the directly executed DDD**
**according to the semantics of the x86 language
On 9/4/2024 5:40 AM, Fred. Zwarts wrote:
Op 03.sep.2024 om 21:54 schreef olcott:
On 9/3/2024 1:53 PM, joes wrote:
Am Tue, 03 Sep 2024 08:17:56 -0500 schrieb olcott:
On 9/3/2024 3:44 AM, Mikko wrote:What would those assumptions be?
On 2024-09-02 16:06:11 +0000, olcott said:That is why I made the isomorphic x86utm system.
A correct halt decider is a Turing machine T with one acceptYour "definition" fails to specify "encoding". There is no standard >>>>>> encoding of Turing machines and tape contents.
state and
one reject state such that:
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y eventually halts, the >>>>>>> execution of T eventually ends up in the accept state and then
stops.
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y does not eventually
halt,
the execution of T eventually ends up in the reject state and then >>>>>>> stops.
By failing to have such a concrete system all kinds of false
assumptions
cannot be refuted.
The behavior of DDD emulated by HHH** <is> different than the behavior >>>>> of the directly executed DDD** **according to the semantics of the x86 >>>>> languageHow can the same code have different semantics?
The pathological relationship between DDD and HHH really
cannot be simply ignored as if it does not exist.
HHH is required to report on the behavior tat its finite string input >>>>> specifies even when this requires HHH to emulate itself emulating DDD. >>> > The input specifies an aborting HHH - which you don’t simulate.>
void DDD()
{
HHH(DDD);
OutputString("This code is unreachable by DDD emulated by HHH");
}
DDD never halts unless it reaches its own final halt state. The fact >>>>> that the executed HHH halts has nothing to do with this.Other than that DDD calls HHH?
HHH is not allowed to report on the computation that itself isThen it is only partial, and doesn’t even solve the case it was
contained
within.
built for.
int sum(int x, int y);
sum(3,4) is not allowed to report on the sum of 5 + 6
for the same reason. HHH(DDD) cannot report on behavior
that it cannot see.
Exactly, so it should not report on halting behaviour if its stops the
simulation before the simulation could halt.
It is very stupid to say that when this proves that DDD emulated by HHH cannot possibly reach its final halt state.
On 9/4/2024 5:17 AM, Fred. Zwarts wrote:
Op 03.sep.2024 om 15:17 schreef olcott:
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state
and one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of
a real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops. >>>>>
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of
a real machine X with initial tape contents Y does not eventually
halt, the execution of T eventually ends up in the reject state and
then stops.
Your "definition" fails to specify "encoding". There is no standard
encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
The behavior of DDD emulated by HHH** <is> different
than the behavior of the directly executed DDD**
**according to the semantics of the x86 language
HHH is required to report on the behavior tat its finite
string input specifies even when this requires HHH
to emulate itself emulating DDD.
DDD never halts unless it reaches its own final
halt state. The fact that the executed HHH halts
has nothing to do with this.
HHH is not allowed to report on the computation that
itself is contained within.
But it must be able to process a finite string containing a copy of
itself, or containing a similar algorithm.
Except for the case of pathological self-reference the
behavior of the directly executed machine M is always
the same as the correctly simulated finite string ⟨M⟩.
There is no self-reference,
It is very stupid to say that when this proves there is https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
On 9/5/2024 2:39 AM, Mikko wrote:What is that assumption?
On 2024-09-03 13:17:56 +0000, olcott said:
On 9/3/2024 3:44 AM, Mikko wrote:If it were isnomorphic the same false assumtipns would apply to both.
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state
and one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a >>>>> real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then
stops.
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a >>>>> real machine X with initial tape contents Y does not eventually
halt, the execution of T eventually ends up in the reject state and
then stops.
Your "definition" fails to specify "encoding". There is no standard
encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds of false
assumptions cannot be refuted.
They do yet I cannot provide every single details of the source-code of
the Turing machine because these details would be too overwhelming.
So instead every author makes a false assumption that is simply believed
to be true with no sufficient basis to show that it isn't true.
Namely, that DDD halts.The behavior of DDD emulated by HHH** <is> different than the behaviorThe halting problem is not about a string but about a behaviour.
of the directly executed DDD** **according to the semantics of the x86
language
Is is about the behavior that this string specifies.
HHH computes the mapping from its input finite string to the behaviorThe wrinkle being that it is selfreferential. We are only interested
that this finite string specifies on the basis of DDD emulated by HHH.
DDD emulated by HHH cannot possibly reach its final halt state and onHHH cannot simulate something that calls itself; yet it halts.
this basis alone HHH is correct to reject DDD and report non-halting.
That no one bothered to notice that the behavior of an input DDD to a simulating termination analyzer HHH can be different than the behaviorThat is exactly your mistake, that you believe the simulation of a
of a directly executed DDD when there is a pathological relationship
between HHH and DDD IS NOT MY MISTAKE.
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state
and one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of
a real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops. >>>>>
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of
a real machine X with initial tape contents Y does not eventually
halt, the execution of T eventually ends up in the reject state and
then stops.
Your "definition" fails to specify "encoding". There is no standard
encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both.
They do yet I cannot provide every single details of
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
The behavior of DDD emulated by HHH** <is> different
than the behavior of the directly executed DDD**
**according to the semantics of the x86 language
The halting problem is not about a string but about a behaviour.
Is is about the behavior that this string specifies.
HHH computes the mapping from its input finite string
to the behavior that this finite string specifies on
the basis of DDD emulated by HHH.
DDD emulated by HHH cannot possibly reach its final halt
state and on this basis alone HHH is correct to reject
DDD and report non-halting.
When there is a pathological relationship to the decider
and its input then this behavior must include DDD calling
HHH to emulated itself again.
That no one bothered to notice that the behavior of an
input DDD to a simulating termination analyzer HHH can
be different than the behavior of a directly executed
DDD when there is a pathological relationship between
HHH and DDD IS NOT MY MISTAKE.
Your decider is not a halt decider if it answers about another
behaviour.
On 9/5/2024 9:27 AM, joes wrote:
Am Thu, 05 Sep 2024 08:39:14 -0500 schrieb olcott:
On 9/5/2024 2:39 AM, Mikko wrote:What is that assumption?
On 2024-09-03 13:17:56 +0000, olcott said:
On 9/3/2024 3:44 AM, Mikko wrote:If it were isnomorphic the same false assumtipns would apply to both.
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state >>>>>>> and one reject state such that:
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y eventually halts, the >>>>>>> execution of T eventually ends up in the accept state and then
stops.
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y does not eventually
halt, the execution of T eventually ends up in the reject state and >>>>>>> then stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds of false
assumptions cannot be refuted.
They do yet I cannot provide every single details of the source-code of
the Turing machine because these details would be too overwhelming.
So instead every author makes a false assumption that is simply believed >>> to be true with no sufficient basis to show that it isn't true.
Namely, that DDD halts.The behavior of DDD emulated by HHH** <is> different than the behavior >>>>> of the directly executed DDD** **according to the semantics of the x86 >>>>> languageThe halting problem is not about a string but about a behaviour.
Is is about the behavior that this string specifies.
HHH computes the mapping from its input finite string to the behaviorThe wrinkle being that it is selfreferential. We are only interested
that this finite string specifies on the basis of DDD emulated by HHH.
in the case where the DDD that calls an aborting HHH is simulated
by that same HHH.
DDD emulated by HHH cannot possibly reach its final halt state and onHHH cannot simulate something that calls itself; yet it halts.
this basis alone HHH is correct to reject DDD and report non-halting.
That no one bothered to notice that the behavior of an input DDD to aThat is exactly your mistake, that you believe the simulation of a
simulating termination analyzer HHH can be different than the behavior
of a directly executed DDD when there is a pathological relationship
between HHH and DDD IS NOT MY MISTAKE.
different program somehow has the same behaviour.
DDD emulated by HHH never reaches it final halt state.
It looks like I have to repeat this 10,000 times before
anyone ever notices that I said it at least once.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...
On 9/5/2024 9:27 AM, joes wrote:Problems in processing English? I think everybody agrees that HHH fails
Am Thu, 05 Sep 2024 08:39:14 -0500 schrieb olcott:
On 9/5/2024 2:39 AM, Mikko wrote:What is that assumption?
On 2024-09-03 13:17:56 +0000, olcott said:
On 9/3/2024 3:44 AM, Mikko wrote:If it were isnomorphic the same false assumtipns would apply to both.
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state >>>>>>> and one reject state such that:
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y eventually halts, the >>>>>>> execution of T eventually ends up in the accept state and then
stops.
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y does not eventually
halt, the execution of T eventually ends up in the reject state and >>>>>>> then stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds of false
assumptions cannot be refuted.
They do yet I cannot provide every single details of the source-code of
the Turing machine because these details would be too overwhelming.
So instead every author makes a false assumption that is simply believed >>> to be true with no sufficient basis to show that it isn't true.
Namely, that DDD halts.The behavior of DDD emulated by HHH** <is> different than the behavior >>>>> of the directly executed DDD** **according to the semantics of the x86 >>>>> languageThe halting problem is not about a string but about a behaviour.
Is is about the behavior that this string specifies.
HHH computes the mapping from its input finite string to the behaviorThe wrinkle being that it is selfreferential. We are only interested
that this finite string specifies on the basis of DDD emulated by HHH.
in the case where the DDD that calls an aborting HHH is simulated
by that same HHH.
DDD emulated by HHH cannot possibly reach its final halt state and onHHH cannot simulate something that calls itself; yet it halts.
this basis alone HHH is correct to reject DDD and report non-halting.
That no one bothered to notice that the behavior of an input DDD to aThat is exactly your mistake, that you believe the simulation of a
simulating termination analyzer HHH can be different than the behavior
of a directly executed DDD when there is a pathological relationship
between HHH and DDD IS NOT MY MISTAKE.
different program somehow has the same behaviour.
DDD emulated by HHH never reaches it final halt state.
It looks like I have to repeat this 10,000 times before
anyone ever notices that I said it at least once.
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state and >>>>> one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a >>>>> real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops. >>>>>
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a >>>>> real machine X with initial tape contents Y does not eventually halt, >>>>> the execution of T eventually ends up in the reject state and then
stops.
Your "definition" fails to specify "encoding". There is no standard
encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both.
They do yet I cannot provide every single details of
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Olcott is a strange person. At the one hand he is begging for reviews,
but he is so arrogant that he does not want to learn anything from the reviews. He has such a strong belief in his ideas, that he thinks that reviewers are lying if the prove that he is incorrect.
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept
state and one reject state such that:
If T is executed with initial tape contents equal to an encoding >>>>>>> of Turing machine X and its initial tape contents Y, and
execution of a real machine X with initial tape contents Y
eventually halts, the execution of T eventually ends up in the
accept state and then stops.
If T is executed with initial tape contents equal to an encoding >>>>>>> of Turing machine X and its initial tape contents Y, and
execution of a real machine X with initial tape contents Y does
not eventually halt, the execution of T eventually ends up in the >>>>>>> reject state and then stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both.
They do yet I cannot provide every single details of
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
I must begin where people are so far no one even understands
the concept of recursive emulation.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...
WHAT SHOULD THE NEXT STEPS BE?
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state and >>>>>>> one reject state such that:
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y eventually halts, the >>>>>>> execution of T eventually ends up in the accept state and then stops. >>>>>>>
If T is executed with initial tape contents equal to an encoding of >>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>> real machine X with initial tape contents Y does not eventually halt, >>>>>>> the execution of T eventually ends up in the reject state and then >>>>>>> stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both.
They do yet I cannot provide every single details of
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
I must begin where people are so far no one even understands
the concept of recursive emulation.
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept
state and one reject state such that:
If T is executed with initial tape contents equal to an encoding >>>>>>> of Turing machine X and its initial tape contents Y, and
execution of a real machine X with initial tape contents Y
eventually halts, the execution of T eventually ends up in the
accept state and then stops.
If T is executed with initial tape contents equal to an encoding >>>>>>> of Turing machine X and its initial tape contents Y, and
execution of a real machine X with initial tape contents Y does
not eventually halt, the execution of T eventually ends up in the >>>>>>> reject state and then stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both.
They do yet I cannot provide every single details of
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
I must begin where people are so far no one even understands
the concept of recursive emulation.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...
WHAT SHOULD THE NEXT STEPS BE?
On 9/7/2024 5:31 AM, Fred. Zwarts wrote:
Op 06.sep.2024 om 13:41 schreef olcott:
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:They do yet I cannot provide every single details of
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept >>>>>>>>> state and one reject state such that:
If T is executed with initial tape contents equal to an
encoding of Turing machine X and its initial tape contents Y, >>>>>>>>> and execution of a real machine X with initial tape contents Y >>>>>>>>> eventually halts, the execution of T eventually ends up in the >>>>>>>>> accept state and then stops.
If T is executed with initial tape contents equal to an
encoding of Turing machine X and its initial tape contents Y, >>>>>>>>> and execution of a real machine X with initial tape contents Y >>>>>>>>> does not eventually halt, the execution of T eventually ends up >>>>>>>>> in the reject state and then stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both. >>>>>
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
I must begin where people are so far no one even understands
the concept of recursive emulation.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...
WHAT SHOULD THE NEXT STEPS BE?
That has been told now several times. A correct simulation (as by
HHH1, or the unmodified world class simulator)
What comes next in the above sequence?
Changing the question to answer a different question
is the despicable lie of the strawman deception.
On 9/7/2024 3:03 AM, Mikko wrote:
On 2024-09-06 11:41:05 +0000, olcott said:
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:They do yet I cannot provide every single details of
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state and
one reject state such that:
If T is executed with initial tape contents equal to an encoding of >>>>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>>>> real machine X with initial tape contents Y eventually halts, the >>>>>>>>> execution of T eventually ends up in the accept state and then stops. >>>>>>>>>
If T is executed with initial tape contents equal to an encoding of >>>>>>>>> Turing machine X and its initial tape contents Y, and execution of a >>>>>>>>> real machine X with initial tape contents Y does not eventually halt, >>>>>>>>> the execution of T eventually ends up in the reject state and then >>>>>>>>> stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both. >>>>>
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
I must begin where people are so far no one even understands
the concept of recursive emulation.
I don't know about you but most of the participants of this discussion
seem to understand recursive simulation and how it differs from
recursion.
Both Fred and Joes think that you can just wait for it
to end on its own. Neither one of them ever answered
when I asked them: Do you know what infinite recursion is?
On 9/7/2024 3:03 AM, Mikko wrote:
On 2024-09-06 11:41:05 +0000, olcott said:
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:They do yet I cannot provide every single details of
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept >>>>>>>>> state and one reject state such that:
If T is executed with initial tape contents equal to an
encoding of Turing machine X and its initial tape contents Y, >>>>>>>>> and execution of a real machine X with initial tape contents Y >>>>>>>>> eventually halts, the execution of T eventually ends up in the >>>>>>>>> accept state and then stops.
If T is executed with initial tape contents equal to an
encoding of Turing machine X and its initial tape contents Y, >>>>>>>>> and execution of a real machine X with initial tape contents Y >>>>>>>>> does not eventually halt, the execution of T eventually ends up >>>>>>>>> in the reject state and then stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both. >>>>>
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
I must begin where people are so far no one even understands
the concept of recursive emulation.
I don't know about you but most of the participants of this discussion
seem to understand recursive simulation and how it differs from
recursion.
Both Fred and Joes think that you can just wait for it
to end on its own. Neither one of them ever answered
when I asked them: Do you know what infinite recursion is?
On 9/7/2024 5:31 AM, Fred. Zwarts wrote:
Op 06.sep.2024 om 13:41 schreef olcott:
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:They do yet I cannot provide every single details of
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept >>>>>>>>> state and one reject state such that:
If T is executed with initial tape contents equal to an
encoding of Turing machine X and its initial tape contents Y, >>>>>>>>> and execution of a real machine X with initial tape contents Y >>>>>>>>> eventually halts, the execution of T eventually ends up in the >>>>>>>>> accept state and then stops.
If T is executed with initial tape contents equal to an
encoding of Turing machine X and its initial tape contents Y, >>>>>>>>> and execution of a real machine X with initial tape contents Y >>>>>>>>> does not eventually halt, the execution of T eventually ends up >>>>>>>>> in the reject state and then stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both. >>>>>
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
I must begin where people are so far no one even understands
the concept of recursive emulation.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...
WHAT SHOULD THE NEXT STEPS BE?
That has been told now several times. A correct simulation (as by
HHH1, or the unmodified world class simulator)
What comes next in the above sequence?
Changing the question to answer a different question
is the despicable lie of the strawman deception.
On 9/8/2024 4:27 AM, Mikko wrote:
On 2024-09-07 13:54:04 +0000, olcott said:
On 9/7/2024 3:03 AM, Mikko wrote:
On 2024-09-06 11:41:05 +0000, olcott said:
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:They do yet I cannot provide every single details of
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept state and
one reject state such that:
If T is executed with initial tape contents equal to an encoding of >>>>>>>>>>> Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y eventually halts, the >>>>>>>>>>> execution of T eventually ends up in the accept state and then stops.
If T is executed with initial tape contents equal to an encoding of >>>>>>>>>>> Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y does not eventually halt,
the execution of T eventually ends up in the reject state and then >>>>>>>>>>> stops.
Your "definition" fails to specify "encoding". There is no standard >>>>>>>>>> encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to both. >>>>>>>
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
I must begin where people are so far no one even understands
the concept of recursive emulation.
I don't know about you but most of the participants of this discussion >>>> seem to understand recursive simulation and how it differs from
recursion.
Both Fred and Joes think that you can just wait for it
to end on its own. Neither one of them ever answered
when I asked them: Do you know what infinite recursion is?
Recursion is a fairly simple concept but do you understand what
"infinite" means?
Unless the outer directly executed HHH aborts its
emulation of DDD it is infinite recursive emulation.
Whether or not the outer directly executed HHH aborts
its emulation DDD never reaches its "return" instruction
final halt state thus cannot possibly halt.
On 9/8/2024 4:27 AM, Mikko wrote:
On 2024-09-07 13:54:04 +0000, olcott said:
On 9/7/2024 3:03 AM, Mikko wrote:
On 2024-09-06 11:41:05 +0000, olcott said:
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
On 9/5/2024 2:39 AM, Mikko wrote:
On 2024-09-03 13:17:56 +0000, olcott said:
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
A correct halt decider is a Turing machine T with one accept >>>>>>>>>>> state and one reject state such that:
If T is executed with initial tape contents equal to an
encoding of Turing machine X and its initial tape contents Y, >>>>>>>>>>> and execution of a real machine X with initial tape contents >>>>>>>>>>> Y eventually halts, the execution of T eventually ends up in >>>>>>>>>>> the accept state and then stops.
If T is executed with initial tape contents equal to an
encoding of Turing machine X and its initial tape contents Y, >>>>>>>>>>> and execution of a real machine X with initial tape contents >>>>>>>>>>> Y does not eventually halt, the execution of T eventually >>>>>>>>>>> ends up in the reject state and then stops.
Your "definition" fails to specify "encoding". There is no >>>>>>>>>> standard
encoding of Turing machines and tape contents.
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds
of false assumptions cannot be refuted.
If it were isnomorphic the same false assumtipns would apply to >>>>>>>> both.
They do yet I cannot provide every single details of
the source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
I must begin where people are so far no one even understands
the concept of recursive emulation.
I don't know about you but most of the participants of this discussion >>>> seem to understand recursive simulation and how it differs from
recursion.
Both Fred and Joes think that you can just wait for it
to end on its own. Neither one of them ever answered
when I asked them: Do you know what infinite recursion is?
Recursion is a fairly simple concept but do you understand what
"infinite" means?
Unless the outer directly executed HHH aborts its
emulation of DDD it is infinite recursive emulation.
Whether or not the outer directly executed HHH aborts
its emulation DDD never reaches its "return" instruction
final halt state thus cannot possibly halt.
HHH(DDD) cannot report on behavior
that it cannot see.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 496 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 61:48:23 |
| Calls: | 9,762 |
| Calls today: | 3 |
| Files: | 13,744 |
| Messages: | 6,185,637 |