On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
Which start with the assumption that the following mapping is computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD
emulated by HHH this includes HHH emulating itself emulating DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the above
mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD
emulated by HHH this includes HHH emulating itself emulating DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined to
be non-halting.
it is not incomputable as the problem itself is ill-
formed due to a category (type) error.
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of
the simulating kind.
Such input forms a category error which results in the halting
problem being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
Which start with the assumption that the following mapping is
computable and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()Which is a contradiction. Therefore the assumption that the above
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD
emulated by HHH this includes HHH emulating itself emulating DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined
to be non-halting.
mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs including Linz. It is impossible to prove something which is
ill-formed in the first place.
/Flibble
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
You only get something that appears that way when a false assumption is
made, namely that the halting function is computable.
On 5/5/2025 1:37 PM, olcott wrote:
On 5/5/2025 11:13 AM, Mr Flibble wrote:In other words, you're demonstrating that you don't understand proof by contradiction, a concept taught to and understood by high school
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of
the simulating kind.
Such input forms a category error which results in the halting
problem being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
Which start with the assumption that the following mapping is
computable and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()Which is a contradiction. Therefore the assumption that the above
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>> emulated by HHH this includes HHH emulating itself emulating DD.
This matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined to be non-halting.
mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs including Linz. It is impossible to prove something which is
ill-formed in the first place.
/Flibble
The above example is category error because it asks HHH(DD) to report
on the direct execution of DD() and the input to HHH specifies a
different sequence of steps.
students more than 50 years your junior.
On 5/5/2025 2:14 PM, olcott wrote:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:When BOTH Boolean RETURN VALUES are the wrong answer THEN THE PROBLEM
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of >>>>>>> the simulating kind.
Such input forms a category error which results in the halting
problem being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>> halting problem proofs.
Which start with the assumption that the following mapping is
computable and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()Which is a contradiction. Therefore the assumption that the above
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of
DD emulated by HHH this includes HHH emulating itself emulating DD. >>>>>> This matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined to be non-halting.
mapping is computable is proven false, as Linz and others have
proved and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs including Linz. It is impossible to prove something which is
ill-formed in the first place.
/Flibble
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
IS ILL-FORMED. Self-contradiction must be screened out as semantically
incorrect.
In other words, you're claiming that there exists an algorithm, i.e. a
fixed immutable sequence of instructions, that neither halts nor does
not halt when executed directly.
Show it.
Failure to do so in your next reply or within one hour of your next
posting in this newsgroup will be taken as your official on-the-record admission that the halting problem is NOT ill-formed and that the below criteria is VALID:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
On 5/5/2025 3:54 PM, olcott wrote:
On 5/5/2025 2:49 PM, dbush wrote:In other words, you don't understand what the halting problem is about, because that is EXACTLY the question.
On 5/5/2025 3:38 PM, olcott wrote:That is not even the actual question.
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:Is this sentence true or false: "What time is it?"
Is "halts" the correct answer for H to return? NO Is "does not
halt" the correct answer for H to return? NO Both Boolean return >>>>>> values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
is also "undecidable" because it is not a proposition having a truth
value.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
Can Carol correctly answer “no” to this (yes/no) question?
Both Yes and No are the wrong answer proving that the question is
incorrect when the context of who is asked is understood to be a
linguistically required aspect of the full meaning of the question.
And "does algorthm X with input Y halt when executed directly" has a
single well defined answer.
I want to know if any arbitrary algorithm X with input Y will halt when executed directly. It would be *very* useful to me if I had an
algorithm H that could tell me that in *all* possible cases. If so, I
could solve the Goldbach conjecture, among many other unsolved problems.
Does an algorithm H exist that can tell me that or not?
On Mon, 05 May 2025 16:00:11 -0400, dbush wrote:
On 5/5/2025 3:54 PM, olcott wrote:
That is not even the actual question.
In other words, you don't understand what the halting problem is about,
because that is EXACTLY the question.
I want to know if any arbitrary algorithm X with input Y will halt when
executed directly. It would be *very* useful to me if I had an
algorithm H that could tell me that in *all* possible cases. If so, I
could solve the Goldbach conjecture, among many other unsolved problems.
Does an algorithm H exist that can tell me that or not?
That isn't what the halting problem is about at all: the halting problem
is about pathological input being undecidable but not for the reason
claimed in any halting problem proof.
/Flibble
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
is also "undecidable" because it is not a proposition
having a truth value.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
Can Carol correctly answer “no” to this (yes/no) question?
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
On Mon, 05 May 2025 16:00:11 -0400, dbush wrote:
I want to know if any arbitrary algorithm X with input Y will halt when
executed directly. It would be *very* useful to me if I had an
algorithm H that could tell me that in *all* possible cases. If so, I
could solve the Goldbach conjecture, among many other unsolved problems.
Does an algorithm H exist that can tell me that or not?
That isn't what the halting problem is about at all:
the halting problem
is about pathological input being undecidable but not for the reason
claimed in any halting problem proof.
That question is in many textbooks yet is still
wrong because functions computed by models of
computation such as Turing Machines or RASP machines
are only allowed to use actual inputs as their basis.
When everyone here insists is that we simply ignore
the above fundamental rule of how functions must be
computed they are necessarily incorrect.
On 05/05/2025 21:03, Mr Flibble wrote:
On Mon, 05 May 2025 16:00:11 -0400, dbush wrote:
<snip>
I want to know if any arbitrary algorithm X with input Y will halt
when executed directly. It would be *very* useful to me if I had an
algorithm H that could tell me that in *all* possible cases. If so, I
could solve the Goldbach conjecture, among many other unsolved
problems.
Does an algorithm H exist that can tell me that or not?
That isn't what the halting problem is about at all:
Yes, it is.
the halting problem is about pathological input being undecidable but
not for the reason claimed in any halting problem proof.
By "pathological input", you mean a program the halt behaviour of which
is undecidable. So we are in agreement, even if you don't yet realise
it.
On 5/5/2025 5:08 PM, olcott wrote:
No TM can compute the square root of a dead rabbit either.
Strawman. The square root of a dead rabbit does not exist,
but
the question of whether any arbitrary algorithm X with input Y
halts when executed directly has a correct answer in all cases.
It's just that no algorithm exists that can compute that mapping,
as proven by Linz and other and as you have *explicitly* agreed
is correct.
It has a correct answer that cannot ever be computed
On Mon, 05 May 2025 21:57:42 +0100, Richard Heathfield wrote:
On 05/05/2025 21:03, Mr Flibble wrote:
On Mon, 05 May 2025 16:00:11 -0400, dbush wrote:
<snip>
I want to know if any arbitrary algorithm X with input Y will halt
when executed directly. It would be *very* useful to me if I had an
algorithm H that could tell me that in *all* possible cases. If so, I >>>> could solve the Goldbach conjecture, among many other unsolved
problems.
Does an algorithm H exist that can tell me that or not?
That isn't what the halting problem is about at all:
Yes, it is.
the halting problem is about pathological input being undecidable but
not for the reason claimed in any halting problem proof.
By "pathological input", you mean a program the halt behaviour of which
is undecidable. So we are in agreement, even if you don't yet realise
it.
No we are not in agreement
and I suspect you are being dishonest and know
this already.
On 05/05/2025 22:35, Mr Flibble wrote:
On Mon, 05 May 2025 21:57:42 +0100, Richard Heathfield wrote:
On 05/05/2025 21:03, Mr Flibble wrote:
On Mon, 05 May 2025 16:00:11 -0400, dbush wrote:
<snip>
I want to know if any arbitrary algorithm X with input Y will halt
when executed directly. It would be *very* useful to me if I had an >>>>> algorithm H that could tell me that in *all* possible cases. If so, >>>>> I could solve the Goldbach conjecture, among many other unsolved
problems.
Does an algorithm H exist that can tell me that or not?
That isn't what the halting problem is about at all:
Yes, it is.
the halting problem is about pathological input being undecidable but
not for the reason claimed in any halting problem proof.
By "pathological input", you mean a program the halt behaviour of
which is undecidable. So we are in agreement, even if you don't yet
realise it.
No we are not in agreement
You now acknowledge the existence of programs whose fate is undecidable.
You give it a different name, sure, but it's the same thing.
and I suspect you are being dishonest and know this already.
On the contrary, when you talk about 'pathological input' you use the
term to describe uncomputable mappings between programs and termination statuses, so you're rather closer to the truth than you perhaps
intended.
To put it in terms you might be able to understand better:
Turing hypothesised the existence of a universal halt decider,
but then showed that were such a decider to exist it would be possible
to use it to create a 'pathological input' that it couldn't decide, so
it follows that no decider can possibly be universal. /At best/, it can decide for all non-pathological inputs.
When we examine this as 100% fully encoded in a
fully specified programming language
thenn we can
see that the whole idea of an input that does the
opposite of whatever value its termination analyzer
returns cannot actually exist. The contradictory
part is unreachable.
On Mon, 05 May 2025 22:51:12 +0100, Richard Heathfield wrote:
and I suspect you are being dishonest and know this already.
On the contrary, when you talk about 'pathological input' you use the
term to describe uncomputable mappings between programs and termination
statuses, so you're rather closer to the truth than you perhaps
intended.
To put it in terms you might be able to understand better:
Turing hypothesised the existence of a universal halt decider,
but then showed that were such a decider to exist it would be possible
to use it to create a 'pathological input' that it couldn't decide, so
it follows that no decider can possibly be universal. /At best/, it can
decide for all non-pathological inputs.
I agree with that final statement:
"/At best/, it can decide for all non-pathological inputs."
However you and others have NOT made that statement in this forum up until this point; I wonder why that is? Learn by rote intellectual dishonesty perhaps?
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD. https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input
is correctly determined to be non-halting.
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
/Flibble
There are different ways of framing the problem.
The only one that matters is that HHH(DD) does
correctly determine that DD never halts.
It is the problem incorrect specification that creates
the contradiction.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
*EVERYONE IGNORES THIS*
It is very simple the mapping from inputs to outputs
must have a well defined sequence of steps.
On 5/6/2025 12:51 AM, Richard Heathfield wrote:
On 06/05/2025 00:30, olcott wrote:
There are different ways of framing the problem.
The only one that matters is that HHH(DD) does
correctly determine that DD never halts.
That may be the only one that matters to you.
It refutes ALL of the conventional HP proofs.
The one that matters to computer scientists, though, is the one
that shows why some questions are undecidable.
Because they are are framed incorrectly.
On 5/5/2025 1:37 PM, olcott wrote:No, the input specifies exactly the same sequence of steps, but HHH
On 5/5/2025 11:13 AM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>>> simulating kind.
Such input forms a category error which results in the halting
problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
Which start with the assumption that the following mapping is
computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>> emulated by HHH this includes HHH emulating itself emulating DD. This >>>>> matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined >>>>> to be non-halting.
Which is a contradiction. Therefore the assumption that the above
mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem proofs >>> including Linz. It is impossible to prove something which is ill-formed >>> in the first place.
/Flibble
The above example is category error because it asks
HHH(DD) to report on the direct execution of DD() and
the input to HHH specifies a different sequence of steps.
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>>> simulating kind.
Such input forms a category error which results in the halting
problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
Which start with the assumption that the following mapping is
computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>> emulated by HHH this includes HHH emulating itself emulating DD. This >>>>> matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined >>>>> to be non-halting.
Which is a contradiction. Therefore the assumption that the above
mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem proofs >>> including Linz. It is impossible to prove something which is ill-formed >>> in the first place.
/Flibble
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
On 5/5/2025 1:06 PM, Mr Flibble wrote:
On Mon, 05 May 2025 13:45:07 -0400, dbush wrote:
On 5/5/2025 1:37 PM, olcott wrote:
On 5/5/2025 11:13 AM, Mr Flibble wrote:In other words, you're demonstrating that you don't understand proof by
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of >>>>>>>> the simulating kind.
Such input forms a category error which results in the halting >>>>>>>> problem being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>>> halting problem proofs.
Which start with the assumption that the following mapping is
computable and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) >>>>>> X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()Which is a contradiction. Therefore the assumption that the above >>>>>> mapping is computable is proven false, as Linz and others have proved >>>>>> and as you have *explicitly* agreed is correct.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>>>> emulated by HHH this includes HHH emulating itself emulating DD. >>>>>>> This matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined to be non-halting.
The category (type) error manifests in all extant halting problem
proofs including Linz. It is impossible to prove something which is >>>>> ill-formed in the first place.
/Flibble
The above example is category error because it asks HHH(DD) to report
on the direct execution of DD() and the input to HHH specifies a
different sequence of steps.
contradiction, a concept taught to and understood by high school
students more than 50 years your junior.
For proof by contradiction to be valid the contradition has to be well-
formed which in the case of the Halting Problem it is not.
/Flibble
Yes. Self-contradiction is always ill-formed.
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
On 5/5/2025 12:45 PM, dbush wrote:
On 5/5/2025 1:37 PM, olcott wrote:
On 5/5/2025 11:13 AM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of >>>>>>> the
simulating kind.
Such input forms a category error which results in the halting
problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>> halting problem proofs.
Which start with the assumption that the following mapping is
computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>>> emulated by HHH this includes HHH emulating itself emulating DD. This >>>>>> matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined >>>>>> to be non-halting.
Which is a contradiction. Therefore the assumption that the above
mapping is computable is proven false, as Linz and others have proved >>>>> and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs
including Linz. It is impossible to prove something which is ill-
formed
in the first place.
/Flibble
The above example is category error because it asks
HHH(DD) to report on the direct execution of DD() and
the input to HHH specifies a different sequence of steps.
In other words, you're demonstrating that you don't understand proof
by contradiction, a concept taught to and understood by high school
students more than 50 years your junior.
Self-contradiction is semantically ill-formed and has
nothing to do with proof by contradiction.
On 5/5/2025 1:14 PM, dbush wrote:
On 5/5/2025 2:09 PM, olcott wrote:
On 5/5/2025 12:45 PM, dbush wrote:
On 5/5/2025 1:37 PM, olcott wrote:
On 5/5/2025 11:13 AM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>>>> halting problem proofs.
Which start with the assumption that the following mapping is
computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes >>>>>>> the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior >>>>>>>> of DD
emulated by HHH this includes HHH emulating itself emulating DD. >>>>>>>> This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the above >>>>>>> mapping is computable is proven false, as Linz and others have
proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs
including Linz. It is impossible to prove something which is ill- >>>>>> formed
in the first place.
/Flibble
The above example is category error because it asks
HHH(DD) to report on the direct execution of DD() and
the input to HHH specifies a different sequence of steps.
In other words, you're demonstrating that you don't understand proof
by contradiction, a concept taught to and understood by high school
students more than 50 years your junior.
Self-contradiction is semantically ill-formed and has
nothing to do with proof by contradiction.
The contradiction comes about as a result of the assumption that an
algorithm exists that computes the following mapping,
NOT AT ALL.
The self-contradiction comes when an input D
to a termination analyzer H is actually able
to do the opposite of whatever value that H
returns. In this case BOTH Boolean RETURN
VALUES ARE THE WRONG ANSWER.
On 5/5/2025 1:14 PM, dbush wrote:
On 5/5/2025 2:09 PM, olcott wrote:
On 5/5/2025 12:45 PM, dbush wrote:
On 5/5/2025 1:37 PM, olcott wrote:
On 5/5/2025 11:13 AM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>>>> halting problem proofs.
Which start with the assumption that the following mapping is
computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes >>>>>>> the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior >>>>>>>> of DD
emulated by HHH this includes HHH emulating itself emulating DD. >>>>>>>> This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the above >>>>>>> mapping is computable is proven false, as Linz and others have
proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs
including Linz. It is impossible to prove something which is ill- >>>>>> formed
in the first place.
/Flibble
The above example is category error because it asks
HHH(DD) to report on the direct execution of DD() and
the input to HHH specifies a different sequence of steps.
In other words, you're demonstrating that you don't understand proof
by contradiction, a concept taught to and understood by high school
students more than 50 years your junior.
Self-contradiction is semantically ill-formed and has
nothing to do with proof by contradiction.
The contradiction comes about as a result of the assumption that an
algorithm exists that computes the following mapping,
NOT AT ALL.
The self-contradiction comes when an input D
to a termination analyzer H is actually able
to do the opposite of whatever value that H
returns. In this case BOTH Boolean RETURN
VALUES ARE THE WRONG ANSWER.
D conditions its behavior on the value that H returns
to it. This means that there are two instances of D
paired with corresponding instances of H.
This will be too difficult for you if you don't
understand the notion of hypothetical possibilities.
Is "halts" the correct answer for H to return?
Is "does not halt" the correct answer for H to return?
Both Boolean return values are the wrong answerBECAUSE THE INPUT IS SELF-CONTRADICTORY.
On 5/5/2025 3:27 PM, Alan Mackenzie wrote:And G is executed a finite number of times, because embedded H has code
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Mon, 05 May 2025 16:00:11 -0400, dbush wrote:
On 5/5/2025 3:54 PM, olcott wrote:
[ .... ]
That is not even the actual question.
In other words, you don't understand what the halting problem is about, >>>> because that is EXACTLY the question.
I want to know if any arbitrary algorithm X with input Y will halt when >>>> executed directly. It would be *very* useful to me if I had an
algorithm H that could tell me that in *all* possible cases. If so, I >>>> could solve the Goldbach conjecture, among many other unsolved
problems.
Does an algorithm H exist that can tell me that or not?
That isn't what the halting problem is about at all: the halting problem >>> is about pathological input being undecidable but not for the reason
claimed in any halting problem proof.
Linz's proof (according to Ben Bacarisse last Thursday) is a trivial
corollary of the fact, proved in chapter 11 of his book, that not all
recursively enumerable languages are recursive. There is no mention of
"pathological input" anywhere in that proof.
None-the-less The Linz proof does require a pathological
relationship between the input and the embedded termination
analyzer.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
OK, show one program for which both answers are wrong.
Each program either halts, or does not halt, one answer is always
correct and the other one is incorrect.
It is logically impossible that counter example exists. We must
agree that not both answers can be wrong.
There is no self-contradiction. Only deciders that contradict the
correct answer.
On 5/5/2025 2:49 PM, dbush wrote:
On 5/5/2025 3:38 PM, olcott wrote:
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
is also "undecidable" because it is not a proposition
having a truth value.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
Can Carol correctly answer “no” to this (yes/no) question?
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
And "does algorthm X with input Y halt when executed directly" has a
single well defined answer.
That is not even the actual question.
Does the finite string input DD to HHH specify
a computation that halts? No it does not.
On 5/5/2025 5:54 PM, Richard Heathfield wrote:
On 05/05/2025 23:25, olcott wrote:
More specifically the proof that a general halt decider cannot exist has several fatal flaws. The only important one is that the "impossible"thenn we can see that the whole idea of an input that does the
opposite of whatever value its termination analyzer returns cannot
actually exist. The contradictory part is unreachable.
Or, more generally, you can't write a universal halt decider.
input is correctly determined to be non-halting. The proof of this is in
the parts that you ignore because you don't understand them.
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>>> simulating kind.
Such input forms a category error which results in the halting problem >>>>>> being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
Which start with the assumption that the following mapping is computable >>>> and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>> emulated by HHH this includes HHH emulating itself emulating DD. This >>>>> matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined >>>>> to be non-halting.
Which is a contradiction. Therefore the assumption that the above
mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem proofs >>> including Linz. It is impossible to prove something which is ill-formed >>> in the first place.
/Flibble
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
You only get something that appears that way when a false assumption is
made, namely that the halting function is computable.
The mapping from the input HHH(DD) finite string of
machine code to DOES SPECIFY RECURSIVE EMULATION
THAT WOULD PREVENT DD FROM EVER HALTING.
On 5/5/2025 2:12 PM, dbush wrote:
On 5/5/2025 2:47 PM, olcott wrote:
On 5/5/2025 1:21 PM, dbush wrote:
On 5/5/2025 2:14 PM, olcott wrote:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>>>>> halting problem proofs.
Which start with the assumption that the following mapping is computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>>>>>> emulated by HHH this includes HHH emulating itself emulating DD. This >>>>>>>>> matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined >>>>>>>>> to be non-halting.
Which is a contradiction. Therefore the assumption that the above >>>>>>>> mapping is computable is proven false, as Linz and others have proved >>>>>>>> and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem proofs
including Linz. It is impossible to prove something which is ill- formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
In other words, you're claiming that there exists an algorithm, i.e. a >>>> fixed immutable sequence of instructions, that neither halts nor does
not halt when executed directly.
That is not what I said.
Then there's no category error, and the halting function is well
defined. It's just that no algorithm can compute it.
It is insufficiently defined thus causing it
to be incoherently defined.
On 5/5/2025 11:13 AM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>> simulating kind.
Such input forms a category error which results in the halting problem >>>>> being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
Which start with the assumption that the following mapping is computable >>> and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD
emulated by HHH this includes HHH emulating itself emulating DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the above
mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem proofs
including Linz. It is impossible to prove something which is ill-formed
in the first place.
/Flibble
The above example is category error because it asks
HHH(DD) to report on the direct execution of DD() and
the input to HHH specifies a different sequence of steps.
On 5/5/2025 1:37 PM, olcott wrote:
On 5/5/2025 11:13 AM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>>> simulating kind.
Such input forms a category error which results in the halting problem >>>>>> being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
Which start with the assumption that the following mapping is computable >>>> and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>> emulated by HHH this includes HHH emulating itself emulating DD. This >>>>> matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined >>>>> to be non-halting.
Which is a contradiction. Therefore the assumption that the above
mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem proofs >>> including Linz. It is impossible to prove something which is ill-formed >>> in the first place.
/Flibble
The above example is category error because it asks
HHH(DD) to report on the direct execution of DD() and
the input to HHH specifies a different sequence of steps.
In other words, you're demonstrating that you don't understand proof by contradiction, a concept taught to and understood by high school
students more than 50 years your junior.
On 5/5/2025 2:49 PM, dbush wrote:
On 5/5/2025 3:38 PM, olcott wrote:
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
is also "undecidable" because it is not a proposition
having a truth value.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
Can Carol correctly answer “no” to this (yes/no) question?
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
And "does algorthm X with input Y halt when executed directly" has a
single well defined answer.
That is not even the actual question.
Does the finite string input DD to HHH specify
a computation that halts? No it does not.
On 5/5/2025 2:23 PM, Richard Heathfield wrote:Wrong, the correct answer is "no", Carol cannot correctly answer no.
On 05/05/2025 20:20, olcott wrote:
Is this sentence true or false: "What time is it?"Is "halts" the correct answer for H to return? NO Is "does not halt"
the correct answer for H to return? NO Both Boolean return values are
the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
is also "undecidable" because it is not a proposition having a truth
value.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound proposition having a truth value.
Can Carol correctly answer “no” to this (yes/no) question?
Both Yes and No are the wrong answer proving that the question is
incorrect when the context of who is asked is understood to be a linguistically required aspect of the full meaning of the question.
On 5/5/2025 2:12 PM, dbush wrote:What categories are being confused?
On 5/5/2025 2:47 PM, olcott wrote:
On 5/5/2025 1:21 PM, dbush wrote:
On 5/5/2025 2:14 PM, olcott wrote:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>>>> of the simulating kind.
Such input forms a category error which results in the halting >>>>>>>>>> problem being ill-formed as currently defined.
Incorrectly, because the HHH that DD calls does in fact contain an abort.When HHH computes the mapping from *its input* to the behavior >>>>>>>>> of DD emulated by HHH this includes HHH emulating itself
emulating DD. This matches the infinite recursion behavior
pattern.
Including the supposed halting decider HHH.When BOTH Boolean RETURN VALUES are the wrong answer THEN THEThus the Halting Problem's "impossible" input is correctlyWhich is a contradiction. Therefore the assumption that the
determined to be non-halting.
above mapping is computable is proven false, as Linz and others >>>>>>>> have proved and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem >>>>>>> proofs including Linz. It is impossible to prove something which >>>>>>> is ill-formed in the first place.
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
PROBLEM IS ILL-FORMED. Self-contradiction must be screened out as
semantically incorrect.
You said that both return values of HHH(DD) are incorrect.In other words, you're claiming that there exists an algorithm, i.e.That is not what I said.
a fixed immutable sequence of instructions, that neither halts nor
does not halt when executed directly.
The mathematical association of programs to their halting state (whenThen there's no category error, and the halting function is well
defined. It's just that no algorithm can compute it.
It is insufficiently defined thus causing it to be incoherently defined.
Compute the mapping FROM INPUTS.There is indeed no concrete implementation of an algorithm that does that.
The details of this cannot be as easily seen with the somewhat vague abstraction of Turing Machines that do not even have a standard language definition.There are many equivalent definitions.
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
Such input forms a category error which results in the halting problem >>>> being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that it
refutes, and thus your talk about correctly emulated by HHH is just a
lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the representation of
a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
On 5/5/2025 3:53 PM, Richard Heathfield wrote:
On 05/05/2025 20:38, olcott wrote:
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
20:45GMT, give or take.
is also "undecidable" because it is not a proposition
having a truth value.
No, it's computable and therefore decidable. Your computer is
perfectly capable of displaying its interpretation of the time.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
But we know that it halts at the full stop.
Can Carol correctly answer “no” to this (yes/no) question?
You have, I see, learned that not all yes/no questions are decidable.
Well done! You're coming along nicely.
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
The question is grammatically and syntactically unremarkable. I see no
grounds for claiming that it's 'incorrect'. It's just undecidable.
You appear to be trying to overturn the Halting Problem by claiming
that Turing somehow cheated. You're entitled to hold that opinion, but
it's not one that will gain any traction with peer reviewers when you
try to publish.
*EVERYONE IGNORES THIS*
It is very simple the mapping from inputs to outputs
must have a well defined sequence of steps.
On Mon, 05 May 2025 14:21:06 -0400, dbush wrote:DD can most definitely be executed, and it halts.
On 5/5/2025 2:14 PM, olcott wrote:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
When BOTH Boolean RETURN VALUES are the wrong answer THEN THE PROBLEMWhen HHH computes the mapping from *its input* to the behavior of >>>>>>> DD emulated by HHH this includes HHH emulating itself emulatingWhich is a contradiction. Therefore the assumption that the above >>>>>> mapping is computable is proven false, as Linz and others have
DD.
This matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined to be non-halting.
proved and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs including Linz. It is impossible to prove something which is >>>>> ill-formed in the first place.
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
IS ILL-FORMED. Self-contradiction must be screened out as semantically
incorrect.
In other words, you're claiming that there exists an algorithm, i.e. a
fixed immutable sequence of instructions, that neither halts nor does
not halt when executed directly.
It neither halts nor does not halt because it is predicated on a
category (type) error so it CANNOT be executed directly.
We have code for DD and a claimed HHH.Failure to do so in your next reply or within one hour of your next
posting in this newsgroup will be taken as your official on-the-record
admission that the halting problem is NOT ill-formed and that the below
criteria is VALID:
There is nothing to execute directly; if you try to by using a
simulating halt decider you get infinite recursion as a manifestation of
the category (type) error in the problem definition.
On 5/5/2025 5:35 PM, dbush wrote:
On 5/5/2025 6:29 PM, olcott wrote:
On 5/5/2025 5:00 PM, dbush wrote:
On 5/5/2025 5:40 PM, Richard Heathfield wrote:
On 05/05/2025 22:31, dbush wrote:
It's just that no algorithm exists that can compute that mapping,
as proven by Linz and other and as you have *explicitly* agreed is >>>>>> correct.
He's coming round to the idea, albeit slowly. He can't bring
himself to describe the mapping as 'incomputable' or 'undecidable',
but he's started to claim that such a mapping is 'incorrect', which
is a tacit acknowledgement that it exists.
Oh, he's agreed to it many times. Here's a partial list:
On 3/24/2025 10:07 PM, olcott wrote:
A halt decider cannot exist
On 4/28/2025 2:47 PM, olcott wrote:
On 4/28/2025 11:54 AM, dbush wrote:instructions) X described as <X> with input Y:
And the halting function below is not a computable function:;
;
It is NEVER a computable function
;
Given any algorithm (i.e. a fixed immutable sequence of
computes the following mapping:;
A solution to the halting problem is an algorithm H that
executed directly;
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>> >> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
On 3/14/2025 1:19 PM, olcott wrote:
When we define the HP as having H return a value
corresponding to the halting behavior of input D
and input D can actually does the opposite of whatever
value that H returns, then we have boxed ourselves
in to a problem having no solution.
On 6/21/2024 1:22 PM, olcott wrote:
the logical impossibility of specifying a halt decider H
that correctly reports the halt status of input D that is
defined to do the opposite of whatever value that H reports.
Of course this is impossible.
On 7/4/2023 12:57 AM, olcott wrote:
If you frame the problem in that a halt decider must divide upfinite
strings pairs into those that halt when directly executed andthose that
do not, then no single program can do this.
On 5/5/2025 5:39 PM, olcott wrote:
On 5/5/2025 4:31 PM, dbush wrote:when
Strawman. The square root of a dead rabbit does not exist, but the >>>> >> question of whether any arbitrary algorithm X with input Y halts
executed directly has a correct answer in all cases.;
;
It has a correct answer that cannot ever be computed
There never has been any input that could
ever actually do the opposite of whatever
value that its termination analyzer returns.
That part of its code was ALWAYS unreachable.
None-the-less you have agreed on many occasions that the theorem which
the halting problem proofs prove is correct.
There are different ways of framing the problem.
The only one that matters is that HHH(DD) does
correctly determine that DD never halts.
On 5/5/2025 11:16 AM, dbush wrote:...when simulated by HHH. Yes, it cannot simulate DD or itself correctly.
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
When BOTH Boolean RETURN VALUES are the wrong answer THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must be screened out as semantically incorrect.When HHH computes the mapping from *its input* to the behavior of DD >>>>> emulated by HHH this includes HHH emulating itself emulating DD.Which is a contradiction. Therefore the assumption that the above
This matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined to be non-halting.
mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs including Linz. It is impossible to prove something which is
ill-formed in the first place.
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
You only get something that appears that way when a false assumption isThe mapping from the input HHH(DD) finite string of machine code to DOES SPECIFY RECURSIVE EMULATION THAT WOULD PREVENT DD FROM EVER HALTING.
made, namely that the halting function is computable.
On 5/5/2025 11:42 AM, Mr Flibble wrote:D is actually able to be written assuming H exists. It does not contradict itself but H.
On Mon, 05 May 2025 10:51:40 -0500, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
Such input forms a category error which results in the halting
problem being ill-formed as currently defined.
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
When HHH computes the mapping from *its input* to the behavior of DD
emulated by HHH this includes HHH emulating itself emulating DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined
to be non-halting.
Disagree: infinite recursion maps to incomputable rather than
non-halting and I reject that: it is not incomputable as the problem
itself is ill- formed due to a category (type) error.
It is only ill-formed when construed in one of two ways:
(a) If D was actually able to do the opposite of whatever value that H returns then it is ill-formed because it is self-contradictory.
(b) If the problem is defined to have HHH report on the direct executionYes, HHH cannot simulate itself the same way as its direct execution.
of DD() then it is ill-formed because HHH is required to report on
different behavior than its input DD actually specifies.
The call from the directly executed DD() to HHH(DD) returns. The call
from the correctly emulated DD() to HHH(DD)
CANNOT POSSIBLY RETURN. The directly executed HHH DOES RETURN.
On 5/5/2025 5:00 PM, dbush wrote:It is not unreachable, as proven by direct execution and world-class simulators. It is unreachable for HHH, because of a bug which makes that
On 5/5/2025 5:40 PM, Richard Heathfield wrote:
On 05/05/2025 22:31, dbush wrote:
It's just that no algorithm exists that can compute that mapping, as
proven by Linz and other and as you have *explicitly* agreed is
correct.
He's coming round to the idea, albeit slowly. He can't bring himself
to describe the mapping as 'incomputable' or 'undecidable', but he's
started to claim that such a mapping is 'incorrect', which is a tacit
acknowledgement that it exists.
Oh, he's agreed to it many times. Here's a partial list:
On 3/24/2025 10:07 PM, olcott wrote:
A halt decider cannot exist
On 4/28/2025 2:47 PM, olcott wrote:
On 4/28/2025 11:54 AM, dbush wrote:instructions) X described as <X> with input Y:
And the halting function below is not a computable function:;
;
It is NEVER a computable function
;
Given any algorithm (i.e. a fixed immutable sequence of
the following mapping:;
A solution to the halting problem is an algorithm H that computes
directly;
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
On 3/14/2025 1:19 PM, olcott wrote:
When we define the HP as having H return a value
corresponding to the halting behavior of input D
and input D can actually does the opposite of whatever
value that H returns, then we have boxed ourselves
in to a problem having no solution.
On 6/21/2024 1:22 PM, olcott wrote:
the logical impossibility of specifying a halt decider H
that correctly reports the halt status of input D that is
defined to do the opposite of whatever value that H reports.
Of course this is impossible.
On 7/4/2023 12:57 AM, olcott wrote:
If you frame the problem in that a halt decider must divide up finitethat
strings pairs into those that halt when directly executed and those
do not, then no single program can do this.
On 5/5/2025 5:39 PM, olcott wrote:
On 5/5/2025 4:31 PM, dbush wrote:
Strawman. The square root of a dead rabbit does not exist, but the;
question of whether any arbitrary algorithm X with input Y halts when >> >> executed directly has a correct answer in all cases.
;
It has a correct answer that cannot ever be computed
There never has been any input that could
ever actually do the opposite of whatever
value that its termination analyzer returns.
That part of its code was ALWAYS unreachable.
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is not
possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/5/2025 10:17 AM, Mr Flibble wrote:It is supposed to map to the direct execution in order for it to be a simulator.
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
I prefer to look at it as a counter-example that refutes all of the
halting problem proofs.
When HHH computes the mapping from *its input* to the behavior of DD
emulated by HHH this includes HHH emulating itself emulating DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined toMaking the direct execution halt, which it actually does, in line with
be non-halting.
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
Which starts with the assumption that an algorithm exists that
performs the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
DO COMPUTE THAT THE INPUT IS NON-HALTING
IFF (if and only if) the mapping FROM INPUTS
IS COMPUTED.
i.e. it is found to map something other than the above function
which is a contradiction.
The above function VIOLATES COMPUTER SCIENCE.
You make no attempt to show how my claim
THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT
you simply take that same quote from a computer
science textbook as the infallible word-of-God.
All you are doing is showing that you don't understand proof by
contradiction,
Not at all. The COMPUTER SCIENCE of your requirements IS WRONG!
On 5/6/2025 12:51 AM, Richard Heathfield wrote:
On 06/05/2025 00:30, olcott wrote:
There are different ways of framing the problem.
The only one that matters is that HHH(DD) does
correctly determine that DD never halts.
That may be the only one that matters to you.
It refutes ALL of the conventional HP proofs.
The one that matters to computer scientists, though, is the one that
shows why some questions are undecidable.
Because they are are framed incorrectly.
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
Such input forms a category error which results in the halting problem >>>> being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that it
refutes, and thus your talk about correctly emulated by HHH is just a
lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the representation of
a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to report
on the direct execution of DD() and the input to HHH specifies a
different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence
of steps as DD. HHH just answers about a different sequence of steps
instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>H should simulate its actual input D that calls the aborting H, not a hypothetical version of D that calls a pure simulator.
If simulating halt decider H correctly simulates its input D until
H correctly determines that its simulated D *would never stop
running unless aborted* then
*input D* is the actual input *would never stop running unless aborted*
is the hypothetical H/D pair where H does not abort.
You cannot possibly show the exact execution trace where DD is correctly emulated by HHH and this emulated DD reaches past its own machineDuh, no simulator can simulate itself correctly. But HHH1 can simulate
address [0000213c].
On 05/05/2025 23:02, Mr Flibble wrote:
On Mon, 05 May 2025 22:51:12 +0100, Richard Heathfield wrote:
<snip>
and I suspect you are being dishonest and know this already.
On the contrary, when you talk about 'pathological input' you use the
term to describe uncomputable mappings between programs and
termination statuses, so you're rather closer to the truth than you
perhaps intended.
To put it in terms you might be able to understand better:
Turing hypothesised the existence of a universal halt decider,
but then showed that were such a decider to exist it would be possible
to use it to create a 'pathological input' that it couldn't decide, so
it follows that no decider can possibly be universal. /At best/, it
can decide for all non-pathological inputs.
I agree with that final statement:
"/At best/, it can decide for all non-pathological inputs."
However you and others have NOT made that statement in this forum up
until this point; I wonder why that is? Learn by rote intellectual
dishonesty perhaps?
You're quick to suggest dishonesty, aren't you?
But no, it's not dishonesty. My description (above) is a perfectly
vanilla description of the standard halting problem, except that instead
of 'undecidable' I wrote 'pathological'.
I deduce that you simply don't understand standard terminology.
On 2025-05-05 15:17:58 +0000, Mr Flibble said:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
The "decider" is not a decider if there is an infinite recursion. Every
input causes an infinite exectuion on some non-decider.
It does not make sense to call every input "pathological".
It may make some sense to say that no input is "pathological" but that
does not make the word "pathological" useful.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
Every question whether a particluar Turing machine with a particular
input halts is a valid halting question. That the question may be too
hard for some does notmake it a category error.
Besides, if there were a category error you would already have said
which word was of which category instead of which category.
I clearly defined what is meant by "pathological input" in the OP; you
don't get to redefine terms at will as an attempt to move the goal posts:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is not
possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
On 5/6/2025 5:59 AM, Richard Damon wrote:
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
Which starts with the assumption that an algorithm exists that
performs the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
DO COMPUTE THAT THE INPUT IS NON-HALTING
IFF (if and only if) the mapping FROM INPUTS
IS COMPUTED.
i.e. it is found to map something other than the above function
which is a contradiction.
The above function VIOLATES COMPUTER SCIENCE.
You make no attempt to show how my claim
THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT
you simply take that same quote from a computer
science textbook as the infallible word-of-God.
All you are doing is showing that you don't understand proof by
contradiction,
Not at all. The COMPUTER SCIENCE of your requirements IS WRONG!
No, YOU don't understand what Computer Science actually is talking about.
Every function computed by a model of computation
must apply a specific sequence of steps that are
specified by the model to the actual finite string
input.
HHH(DD) must emulate DD according to the rules
of the x86 language.
THIS DOES DERIVE THAT THE CORRECTLY EMULATED DD DOES NOT HALT.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/6/2025 10:53 AM, joes wrote:
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to report >>>>> on the direct execution of DD() and the input to HHH specifies a
different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence
of steps as DD. HHH just answers about a different sequence of steps
instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D until
H correctly determines that its simulated D *would never stop >>> running unless aborted* then
*input D* is the actual input *would never stop running unless aborted*
is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a
hypothetical version of D that calls a pure simulator.
*would never stop running unless aborted*
refers to the same HHH that DD calls yet
this hypothetical HHH does not abort.
You cannot possibly show the exact execution trace where DD is correctly >>> emulated by HHH and this emulated DD reaches past its own machine
address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can simulate
DD/HHH.
HHH does simulate itself correctly yet must create
a separate process context for each recursive emulation.
Each process context has its own stack and set of
virtual registers.
On 5/6/2025 6:06 AM, Richard Damon wrote:
On 5/5/25 10:29 PM, olcott wrote:
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>>> simulating kind.
Such input forms a category error which results in the halting
problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that it
refutes, and thus your talk about correctly emulated by HHH is just
a lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the representation
of a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
Can't be, as the input needs to be about a program, which must, by the
definition of a program, include all its algorithm.
Yes, there are steps that also occur in the termination analyzer, but
they have been effectively copied into the program the input describes.
Note, nothing says that the representation of the program has to be an
assembly level description of it. It has to be a complete description,
that 100% defines the results the code will generate (and if it will
generate) but it doesn't need to be the exact assembly code,
YOU even understand that, as you present the code as "C" code, which
isn't assembly.
What you forget is that the input program INCLUDES as its definiton,
all of the code it uses, and thus the call to the decider it is built
on includes that code into the decider, and that is a FIXED and
DETERMINDED version of the decider, the one that THIS version of the
input is designed to make wrong.
This doesn't change when you hypothosize a different decider looking
at THIS input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
Refers to a hypothetical HHH/DD pair of the same HHH that
DD calls except that this hypothetical HHH never aborts.
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no attempt to >>>>> show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT you >>>>> simply take that same quote from a computer science textbook as theDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only if) the >>>>>>> mapping FROM INPUTS IS COMPUTED.i.e. it is found to map something other than the above function
which is a contradiction.
infallible word-of-God.
You are very confused. An algorithm or program computes a function.Every function computed by a model of computation must apply a specific sequence of steps that are specified by the model to the actual finiteNo, YOU don't understand what Computer Science actually is talkingAll you are doing is showing that you don't understand proof byNot at all. The COMPUTER SCIENCE of your requirements IS WRONG!
contradiction,
about.
string input.
HHH(DD) must emulate DD according to the rules of the x86 language.It does derive that, but it is not correct.
THIS DOES DERIVE THAT THE CORRECTLY EMULATED DD DOES NOT HALT.
That everyone here thinks that HHH can simply ignore the rules of theNo, we think the call should actually be simulated completely, since
x86 language and jump over the "call" instruction to the "ret"
instruction seems quite stupid to me.
On 5/6/2025 4:30 AM, Mikko wrote:
On 2025-05-05 19:27:18 +0000, olcott said:
On 5/5/2025 2:12 PM, dbush wrote:
On 5/5/2025 2:47 PM, olcott wrote:
On 5/5/2025 1:21 PM, dbush wrote:
On 5/5/2025 2:14 PM, olcott wrote:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a >>>>>>>>>>>> decider of the
simulating kind.
Such input forms a category error which results in the >>>>>>>>>>>> halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all >>>>>>>>>>> of the
halting problem proofs.
Which start with the assumption that the following mapping is >>>>>>>>>> computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed
directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH >>>>>>>>>>> and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the
behavior of DD
emulated by HHH this includes HHH emulating itself emulating >>>>>>>>>>> DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly >>>>>>>>>>> determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the >>>>>>>>>> above
mapping is computable is proven false, as Linz and others have >>>>>>>>>> proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting
problem proofs
including Linz. It is impossible to prove something which is >>>>>>>>> ill- formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed
directly. Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
In other words, you're claiming that there exists an algorithm,
i.e. a fixed immutable sequence of instructions, that neither
halts nor does not halt when executed directly.
That is not what I said.
Then there's no category error, and the halting function is well
defined. It's just that no algorithm can compute it.
It is insufficiently defined thus causing it
to be incoherently defined.
It is well defined. There are computations that halt and computations
that
do not. Nothing else is in the scope of the halting problem.
It is incorrectly defined when-so-ever it is not specified
that a specific sequence of steps must be applied to the
input to derive the output.
That DD() halts therefore I guess that DD correctly
emulated by HHH must halt too IS NOT A SPECIFIC SEQUENCE OF STEPS.
It is merely an incorrect guess.
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is not possible to construct a
universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
That you lack the technical knowledge required
to trace through the steps and say that I am
wrong anyway is a reckless disregard for the truth.
On 5/6/2025 4:26 AM, Mikko wrote:
On 2025-05-05 18:14:25 +0000, olcott said:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>>> halting problem proofs.
Which start with the assumption that the following mapping is
computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>>>> emulated by HHH this includes HHH emulating itself emulating DD. >>>>>>> This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the above >>>>>> mapping is computable is proven false, as Linz and others have proved >>>>>> and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs
including Linz. It is impossible to prove something which is ill-
formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
Irrelevant. One of the boolean values (the one not returned) is the
right one as can be determined e.g. with an UTM.
You only get something that appears that way when a false assumption
is made, namely that the halting function is computable.
The mapping from the input HHH(DD) finite string of
machine code to DOES SPECIFY RECURSIVE EMULATION
THAT WOULD PREVENT DD FROM EVER HALTING.
No, it does not. HHH returns 0 and DD halts.
You can't show the detailed steps of the execution
trace of DD emulated by HHH (according to the rules
of the x86 language) where DD halts because you are wrong.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/6/2025 5:59 AM, Richard Damon wrote:
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
Which starts with the assumption that an algorithm exists that
performs the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
DO COMPUTE THAT THE INPUT IS NON-HALTING
IFF (if and only if) the mapping FROM INPUTS
IS COMPUTED.
i.e. it is found to map something other than the above function
which is a contradiction.
The above function VIOLATES COMPUTER SCIENCE.
You make no attempt to show how my claim
THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT
you simply take that same quote from a computer
science textbook as the infallible word-of-God.
All you are doing is showing that you don't understand proof by
contradiction,
Not at all. The COMPUTER SCIENCE of your requirements IS WRONG!
No, YOU don't understand what Computer Science actually is talking about.
Every function computed by a model of computation
must apply a specific sequence of steps that are
specified by the model to the actual finite string
input.
HHH(DD) must emulate DD according to the rules
of the x86 language.
THIS DOES DERIVE THAT THE CORRECTLY EMULATED DD DOES NOT HALT.
That everyone here thinks that HHH can simply ignore
the rules of the x86 language and jump over the "call"
instruction to the "ret" instruction seems quite stupid
to me.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no attempt to >>>>>>> show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT you >>>>>>> simply take that same quote from a computer science textbook as the >>>>>>> infallible word-of-God.DO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only if) the >>>>>>>>> mapping FROM INPUTS IS COMPUTED.i.e. it is found to map something other than the above function >>>>>>>> which is a contradiction.
Every function computed by a model of computation must apply a specificNo, YOU don't understand what Computer Science actually is talkingAll you are doing is showing that you don't understand proof byNot at all. The COMPUTER SCIENCE of your requirements IS WRONG!
contradiction,
about.
sequence of steps that are specified by the model to the actual finite
string input.
You are very confused. An algorithm or program computes a function.
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
On 5/6/2025 3:49 PM, dbush wrote:
On 5/6/2025 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make noDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only if) >>>>>>>>>>> thei.e. it is found to map something other than the above function >>>>>>>>>> which is a contradiction.
mapping FROM INPUTS IS COMPUTED.
attempt to
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS
INCORRECT you
simply take that same quote from a computer science textbook as >>>>>>>>> the
infallible word-of-God.
Every function computed by a model of computation must apply aNo, YOU don't understand what Computer Science actually is talking >>>>>> about.All you are doing is showing that you don't understand proof by >>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG!
specific
sequence of steps that are specified by the model to the actual finite >>>>> string input.
You are very confused. An algorithm or program computes a function.
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
False. Anything that correctly associates a function's input to a
function's output for all elements of the function's domain does in
fact compute that function.
For example, given this function:
For all integers X and Y:
(X,Y) maps to 5
This algorithm computes it:
int foo(int X, int Y) { return 5; }
The rules that must be applied to the inputs
are the rules of arithmetic. Since the input
was ignored foo() did not compute the sum
of any input. INPUTS must be transformed into
OUTPUTS using rules.
This is brand new computer science that I just created.
It can be inferred from the other details of what
computable functions are:
INPUTS must correspond to OUTPUTS.
There must be some process that ensures that
INPUTS correspond to OUTPUTS. Every process
must have some sequence of steps.
On 5/6/2025 2:10 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 20:47 schreef olcott:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is not
possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
That you do not understand it, does not mean that it has not been
provided to you. It has, many times. If you do not know that you are
wrong, you must be very stupid.
Everything besides a machine address by machine
address of DD emulated by HHH (according to the
rules of the x86 language) where the emulated
DD reaches its own "ret" instruction
*IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION*
Most of my reviewers switch to rhetoric when they
know that they are wrong and still want to disagree.
Disagreement (not truth) is their highest priority.
On 5/6/2025 4:12 PM, dbush wrote:
On 5/6/2025 4:57 PM, olcott wrote:
On 5/6/2025 3:49 PM, dbush wrote:
On 5/6/2025 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no >>>>>>>>>>> attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only >>>>>>>>>>>>> if) thei.e. it is found to map something other than the above function >>>>>>>>>>>> which is a contradiction.
mapping FROM INPUTS IS COMPUTED.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS
INCORRECT you
simply take that same quote from a computer science textbook >>>>>>>>>>> as the
infallible word-of-God.
Every function computed by a model of computation must apply aAll you are doing is showing that you don't understand proof by >>>>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>> No, YOU don't understand what Computer Science actually is talking >>>>>>>> about.
specific
sequence of steps that are specified by the model to the actual
finite
string input.
You are very confused. An algorithm or program computes a function. >>>>>>
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
False. Anything that correctly associates a function's input to a
function's output for all elements of the function's domain does in
fact compute that function.
For example, given this function:
For all integers X and Y:
(X,Y) maps to 5
This algorithm computes it:
int foo(int X, int Y) { return 5; }
The rules that must be applied to the inputs
are
Anything that can associate the input with the output.
WRONG!
Any defined process that CAUSES an INPUT to be associated
with an OUTPUT.
On 5/6/2025 6:06 AM, Richard Damon wrote:
On 5/5/25 10:29 PM, olcott wrote:
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>>> simulating kind.
Such input forms a category error which results in the halting
problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that it
refutes, and thus your talk about correctly emulated by HHH is just
a lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the representation
of a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
Can't be, as the input needs to be about a program, which must, by the
definition of a program, include all its algorithm.
Yes, there are steps that also occur in the termination analyzer, but
they have been effectively copied into the program the input describes.
Note, nothing says that the representation of the program has to be an
assembly level description of it. It has to be a complete description,
that 100% defines the results the code will generate (and if it will
generate) but it doesn't need to be the exact assembly code,
YOU even understand that, as you present the code as "C" code, which
isn't assembly.
What you forget is that the input program INCLUDES as its definiton,
all of the code it uses, and thus the call to the decider it is built
on includes that code into the decider, and that is a FIXED and
DETERMINDED version of the decider, the one that THIS version of the
input is designed to make wrong.
This doesn't change when you hypothosize a different decider looking
at THIS input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
Refers to a hypothetical HHH/DD pair of the same HHH that
DD calls except that this hypothetical HHH never aborts.
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is not
possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that HHH
aborts,
When you trace through the actual steps you
will see that this is counter-factual.
That you lack the technical knowledge required
to trace through the steps and say that I am
wrong anyway is a reckless disregard for the truth.
On 5/6/2025 3:31 PM, dbush wrote:
On 5/6/2025 4:25 PM, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is
not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that HHH
aborts,
When you trace through the actual steps you
will see that this is counter-factual.
Then what is the first instruction emulated by HHH that differs from
the emulation performed by UTM?
HHH1 is exactly the same as HHH except that DD
does not call HHH1. This IS the UTM emulator.
It does not abort.
With HHH1(DD) the call from DD to HHH(DD) returns.
With HHH(DD) the call from DD to HHH(DD) cannot possibly return.
THIS IS BECAUSE
HHH1(DD) DOES NOT HAVE a pathological relationship to DD.
HHH(DD) DOES HAVE a pathological relationship to DD.
On 5/6/2025 4:17 PM, dbush wrote:
On 5/6/2025 5:03 PM, olcott wrote:
On 5/6/2025 3:51 PM, dbush wrote:
On 5/6/2025 4:46 PM, olcott wrote:
On 5/6/2025 3:31 PM, dbush wrote:
On 5/6/2025 4:25 PM, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact that it >>>>>>>>>>>> is not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that >>>>>>>> HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
Then what is the first instruction emulated by HHH that differs
from the emulation performed by UTM?
HHH1 is exactly the same as HHH except that DD
does not call HHH1. This IS the UTM emulator.
It does not abort.
Last chance:
What is the first instruction emulated by HHH that differs from the
emulation performed by HHH1?
Go back and read the part you ignored moron.
Let the record show that Peter Olcott has neglected to identify an
instruction that HHH emulates differently from HHH1.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
On 5/6/2025 4:47 AM, Mikko wrote:
On 2025-05-05 19:54:55 +0000, olcott said:
On 5/5/2025 2:49 PM, dbush wrote:
On 5/5/2025 3:38 PM, olcott wrote:
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
is also "undecidable" because it is not a proposition
having a truth value.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
Can Carol correctly answer “no” to this (yes/no) question?
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
And "does algorthm X with input Y halt when executed directly" has a
single well defined answer.
That is not even the actual question.
Does the finite string input DD to HHH specify
a computation that halts? No it does not.
That question is a category error. The halting question is not about
finite strings but about computations.
HHH must compute the mapping from its finite string
of x86 code input to the actual behavior that this
finite string input specifies.
The same thing goes for TM's
H must compute the mapping from the finite string
TM source-code input to the behavior that this TM
source-code specifies.
On 5/6/2025 7:12 AM, dbush wrote:
On 5/6/2025 12:55 AM, olcott wrote:
On 5/5/2025 3:53 PM, Richard Heathfield wrote:
On 05/05/2025 20:38, olcott wrote:
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
20:45GMT, give or take.
is also "undecidable" because it is not a proposition
having a truth value.
No, it's computable and therefore decidable. Your computer is
perfectly capable of displaying its interpretation of the time.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
But we know that it halts at the full stop.
Can Carol correctly answer “no” to this (yes/no) question?
You have, I see, learned that not all yes/no questions are
decidable. Well done! You're coming along nicely.
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
The question is grammatically and syntactically unremarkable. I see
no grounds for claiming that it's 'incorrect'. It's just undecidable.
You appear to be trying to overturn the Halting Problem by claiming
that Turing somehow cheated. You're entitled to hold that opinion,
but it's not one that will gain any traction with peer reviewers
when you try to publish.
*EVERYONE IGNORES THIS*
It is very simple the mapping from inputs to outputs
must have a well defined sequence of steps.
FALSE!!!
There is no requirement that mappings have steps to compute them.
The requirement is that OUTPUTS must correspond
to INPUTS. This requires that outputs must be
derived from INPUTS.
When DD is correctly emulated by HHH it is only
allowed to apply the specific sequence specified
by the x86 language to derive the behavior specified
by this input.
Everyone here seems to think that HHH is allowed
to ignore the "call" instruction in DD and jump
directly to the "ret" instruction in DD.
On 5/6/2025 2:16 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 19:54 schreef olcott:
On 5/6/2025 6:06 AM, Richard Damon wrote:
On 5/5/25 10:29 PM, olcott wrote:
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that it
refutes, and thus your talk about correctly emulated by HHH is
just a lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the representation >>>>>> of a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
Can't be, as the input needs to be about a program, which must, by
the definition of a program, include all its algorithm.
Yes, there are steps that also occur in the termination analyzer,
but they have been effectively copied into the program the input
describes.
Note, nothing says that the representation of the program has to be
an assembly level description of it. It has to be a complete
description, that 100% defines the results the code will generate
(and if it will generate) but it doesn't need to be the exact
assembly code,
YOU even understand that, as you present the code as "C" code, which
isn't assembly.
What you forget is that the input program INCLUDES as its definiton,
all of the code it uses, and thus the call to the decider it is
built on includes that code into the decider, and that is a FIXED
and DETERMINDED version of the decider, the one that THIS version of
the input is designed to make wrong.
This doesn't change when you hypothosize a different decider looking
at THIS input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
Refers to a hypothetical HHH/DD pair of the same HHH that
DD calls except that this hypothetical HHH never aborts.
HHH should decide about its actual input, not about a hypothetical input.
That is not what Professor Sipser agreed to.
*would never stop running unless aborted*
is the hypothetical HHH/DD pair where HHH
and DD are exactly the same except that
this hypothetical HHH never aborts.
On 5/6/2025 5:43 PM, Richard Damon wrote:
On 5/6/25 11:10 AM, olcott wrote:
On 5/6/2025 4:26 AM, Mikko wrote:
On 2025-05-05 18:14:25 +0000, olcott said:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of >>>>>>>>> the
halting problem proofs.
Which start with the assumption that the following mapping is
computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior >>>>>>>>> of DD
emulated by HHH this includes HHH emulating itself emulating >>>>>>>>> DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the above >>>>>>>> mapping is computable is proven false, as Linz and others have >>>>>>>> proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem >>>>>>> proofs
including Linz. It is impossible to prove something which is
ill- formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
Irrelevant. One of the boolean values (the one not returned) is the
right one as can be determined e.g. with an UTM.
You only get something that appears that way when a falseThe mapping from the input HHH(DD) finite string of
assumption is made, namely that the halting function is computable. >>>>>
machine code to DOES SPECIFY RECURSIVE EMULATION
THAT WOULD PREVENT DD FROM EVER HALTING.
No, it does not. HHH returns 0 and DD halts.
You can't show the detailed steps of the execution
trace of DD emulated by HHH (according to the rules
of the x86 language) where DD halts because you are wrong.
Because a trace of DD correctly emulatd by HHH doesn't exist as HHH
doesn't correctly emulate DD
Show what the execution trace of DD emulated by HHH
according to the rules of the x86 language should be
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/6/2025 5:43 PM, Richard Damon wrote:
On 5/6/25 11:10 AM, olcott wrote:
On 5/6/2025 4:26 AM, Mikko wrote:
On 2025-05-05 18:14:25 +0000, olcott said:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of >>>>>>>>> the
halting problem proofs.
Which start with the assumption that the following mapping is
computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior >>>>>>>>> of DD
emulated by HHH this includes HHH emulating itself emulating >>>>>>>>> DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the above >>>>>>>> mapping is computable is proven false, as Linz and others have >>>>>>>> proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem >>>>>>> proofs
including Linz. It is impossible to prove something which is
ill- formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed directly.
Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
Irrelevant. One of the boolean values (the one not returned) is the
right one as can be determined e.g. with an UTM.
You only get something that appears that way when a falseThe mapping from the input HHH(DD) finite string of
assumption is made, namely that the halting function is computable. >>>>>
machine code to DOES SPECIFY RECURSIVE EMULATION
THAT WOULD PREVENT DD FROM EVER HALTING.
No, it does not. HHH returns 0 and DD halts.
You can't show the detailed steps of the execution
trace of DD emulated by HHH (according to the rules
of the x86 language) where DD halts because you are wrong.
Because a trace of DD correctly emulatd by HHH doesn't exist as HHH
doesn't correctly emulate DD
Show what the execution trace of DD emulated by HHH
according to the rules of the x86 language should be
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is not possible to construct a
universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the two traces side by side some time
ago, and they were indeed IDENTICAL line for line up to the point where HHH decided to discontinue
simulating.
That is counter-factual.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* refers to the actual HHH/DD pair
*would never stop running unless aborted*
refers to the hypothetical HHH/DD pair where
HHH and DDD are exactly the same except that
this hypothetical HHH does not abort the
simulation of its input.
The trace by UTM continued further, with DD returning some time later.
The above HHH1(DD) is this UTM.
The DD correctly emulated by HHH cannot possibly return.
Not even after an infinite number of steps of correct emulation.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
HHH and UTM emulate DD exactly the same up until the point
that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of
the two traces side by side some time ago, and they were indeed
IDENTICAL line for line up to the point where HHH decided to
discontinue simulating.
That is counter-factual.
On 5/6/2025 10:16 PM, dbush wrote:Oh really? What do they do differently?
On 5/6/2025 11:11 PM, olcott wrote:
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:HHH1(DD) the call from DD to HHH(DD) returns.
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:HHH and UTM emulate DD exactly the same up until the point that >>>>>>>> HHH aborts,
On 5/6/2025 1:54 AM, olcott wrote:Machine address by machine address specifics that you know that >>>>>>>>> you cannot provide because you know that you are wrong.
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:What are the exact steps for DD to be emulated by HHH
It is the problem incorrect specification that creates the >>>>>>>>>>>>> contradiction.Not at all. The contradiction arises from the fact that it is >>>>>>>>>>>> not possible to construct a universal decider.
Everyone here insists that functions computed by models of >>>>>>>>>>>>> computation can ignore inputs and base their output on >>>>>>>>>>>>> something else.
I don't think anyone's saying that.
Maybe you don't read so well.
according to the semantics of the x86 language? *Only an >>>>>>>>>>> execution trace will do*
The exact same steps for DD to be emulated by UTM.
When you trace through the actual steps you will see that this is >>>>>>> counter-factual.
No, it is exactly right. Remember, I posted a comparison of the
two traces side by side some time ago, and they were indeed
IDENTICAL line for line up to the point where HHH decided to
discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the same up to >>>> the point where HHH discontinued the simulation. How can it be
"counter-factual"?
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
A call that returns and a call that cannot possibly return *are not
exactly the same thing*
They are exactly the same up to the point that HHH aborted,
Counter-Factual they are exactly the same up until The simulated /
executed DD calls HHH(DD).
It is a long time later that HHH aborts the simulation of its input DD.When does that happen?
After the executed DD calls the executed HHH(DD) HHH emulates DD then emulates itself emulating DD. This is a very long time after the*You* post the traces then.
divergence point.
On 5/6/2025 6:00 PM, Richard Damon wrote:A correct simulation is one that produces the same behaviour as the
On 5/6/25 1:54 PM, olcott wrote:
On 5/6/2025 6:06 AM, Richard Damon wrote:
On 5/5/25 10:29 PM, olcott wrote:
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
Can't be, as the input needs to be about a program, which must, byWhen HHH computes the mapping from *its input* to the behavior of >>>>>>> DD emulated by HHH this includes HHH emulating itself emulatingAnd *ITS INPUT*, for the HHH that answers 0, is the representation >>>>>> of a program
DD. This matches the infinite recursion behavior pattern.
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise sequence of steps.
With pathological self-reference some of these steps are inside the
termination analyzer.
the definition of a program, include all its algorithm.
Yes, there are steps that also occur in the termination analyzer, but
they have been effectively copied into the program the input
describes.
Right, but a correct simulation of D does halt,What you forget is that the input program INCLUDES as its definiton,*would never stop running unless aborted*
all of the code it uses, and thus the call to the decider it is built
on includes that code into the decider, and that is a FIXED and
DETERMINDED version of the decider, the one that THIS version of the
input is designed to make wrong.
This doesn't change when you hypothosize a different decider looking
at THIS input.
Refers to a hypothetical HHH/DD pair of the same HHH that DD calls
except that this hypothetical HHH never aborts.
How the Hell is breaking the rules specified by the x86 languageThe rule that you may not abort? The rule that you may not simulate hypothetical code?
possibly correct?
On 5/6/2025 5:57 PM, Richard Damon wrote:
On 5/6/25 5:56 PM, olcott wrote:
On 5/6/2025 4:12 PM, dbush wrote:
On 5/6/2025 4:57 PM, olcott wrote:
On 5/6/2025 3:49 PM, dbush wrote:
On 5/6/2025 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
What does it violate?The above function VIOLATES COMPUTER SCIENCE. You make no >>>>>>>>>>>>> attempt to show how my claim THAT IT VIOLATES COMPUTER >>>>>>>>>>>>> SCIENCE IS INCORRECT you simply take that same quote from a >>>>>>>>>>>>> computer science textbook as the infallible word-of-God.
It's not ignoring the input if they all map to the same value. How wouldAnd it does, it causes ALL inputs to be associated with the value 5.WRONG!The rules that must be applied to the inputs areFalse. Anything that correctly associates a function's input to a >>>>>> function's output for all elements of the function's domain does in >>>>>> fact compute that function.Nothing computes a function unless it applies a specific set ofEvery function computed by a model of computation must apply a >>>>>>>>> specific sequence of steps that are specified by the model to >>>>>>>>> the actual finite string input.
You are very confused. An algorithm or program computes a
function.
rules to its actual input to derive its output. Anything that
ignores its input is not computing a function.
For example, given this function:
For all integers X and Y:
(X,Y) maps to 5
This algorithm computes it:
int foo(int X, int Y) { return 5; }
Anything that can associate the input with the output.
Any defined process that CAUSES an INPUT to be associated with an
OUTPUT.
Ignoring the input cannot possibly be construed as computing the mapping
from the input.
On 5/5/2025 11:51 AM, olcott wrote:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
There are two different DD instances that have had
provably different behavior for at least three years.
On 5/6/2025 4:30 AM, Mikko wrote:
On 2025-05-05 19:27:18 +0000, olcott said:
On 5/5/2025 2:12 PM, dbush wrote:
On 5/5/2025 2:47 PM, olcott wrote:
On 5/5/2025 1:21 PM, dbush wrote:
On 5/5/2025 2:14 PM, olcott wrote:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>>>>>>> halting problem proofs.
Which start with the assumption that the following mapping is computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD
emulated by HHH this includes HHH emulating itself emulating DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the above >>>>>>>>>> mapping is computable is proven false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem proofs
including Linz. It is impossible to prove something which is ill- formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed directly. >>>>>>>> Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
In other words, you're claiming that there exists an algorithm, i.e. a >>>>>> fixed immutable sequence of instructions, that neither halts nor does >>>>>> not halt when executed directly.
That is not what I said.
Then there's no category error, and the halting function is well
defined. It's just that no algorithm can compute it.
It is insufficiently defined thus causing it
to be incoherently defined.
It is well defined. There are computations that halt and computations that >> do not. Nothing else is in the scope of the halting problem.
It is incorrectly defined when-so-ever it is not specified
that a specific sequence of steps must be applied to the
input to derive the output.
That everyone here thinks that HHH can simply ignore
the rules of the x86 language and jump over the "call"
instruction to the "ret" instruction seems quite stupid
to me.
On 5/6/2025 4:47 AM, Mikko wrote:
On 2025-05-05 19:54:55 +0000, olcott said:
On 5/5/2025 2:49 PM, dbush wrote:
On 5/5/2025 3:38 PM, olcott wrote:
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
is also "undecidable" because it is not a proposition
having a truth value.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
Can Carol correctly answer “no” to this (yes/no) question?
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
And "does algorthm X with input Y halt when executed directly" has a
single well defined answer.
That is not even the actual question.
Does the finite string input DD to HHH specify
a computation that halts? No it does not.
That question is a category error. The halting question is not about
finite strings but about computations.
HHH must compute the mapping from its finite string
of x86 code input to the actual behavior that this
finite string input specifies.
On 5/6/2025 4:35 AM, Mikko wrote:
On 2025-05-05 17:37:20 +0000, olcott said:
On 5/5/2025 11:13 AM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>>>> simulating kind.
Such input forms a category error which results in the halting problem >>>>>>> being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>> halting problem proofs.
Which start with the assumption that the following mapping is computable >>>>> and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>>> emulated by HHH this includes HHH emulating itself emulating DD. This >>>>>> matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined >>>>>> to be non-halting.
Which is a contradiction. Therefore the assumption that the above
mapping is computable is proven false, as Linz and others have proved >>>>> and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem proofs >>>> including Linz. It is impossible to prove something which is ill-formed >>>> in the first place.
/Flibble
The above example is category error because it asks
HHH(DD) to report on the direct execution of DD() and
the input to HHH specifies a different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence
of steps as DD. HHH just answers about a different sequence of steps
instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* is the actual input
*would never stop running unless aborted*
is the hypothetical H/D pair where H does not abort.
You cannot possibly show the exact execution trace
On Tue, 06 May 2025 11:41:21 +0300, Mikko wrote:
On 2025-05-05 15:17:58 +0000, Mr Flibble said:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
The "decider" is not a decider if there is an infinite recursion. Every
input causes an infinite exectuion on some non-decider.
It does not make sense to call every input "pathological".
It may make some sense to say that no input is "pathological" but that
does not make the word "pathological" useful.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
Every question whether a particluar Turing machine with a particular
input halts is a valid halting question. That the question may be too
hard for some does notmake it a category error.
Besides, if there were a category error you would already have said
which word was of which category instead of which category.
The two categories (types) in the category error are:
1) The decider.
2) The self-referencial (wrt the decider) input passed to the decider.
On 5/6/2025 10:53 AM, joes wrote:
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to report >>>>> on the direct execution of DD() and the input to HHH specifies a
different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence
of steps as DD. HHH just answers about a different sequence of steps
instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D until
H correctly determines that its simulated D *would never stop
running unless aborted* then
*input D* is the actual input *would never stop running unless aborted*
is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a
hypothetical version of D that calls a pure simulator.
*would never stop running unless aborted*
refers to the same HHH that DD calls yet
this hypothetical HHH does not abort.
You cannot possibly show the exact execution trace where DD is correctly >>> emulated by HHH and this emulated DD reaches past its own machine
address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can simulate
DD/HHH.
HHH does simulate itself correctly yet must create
On 5/6/2025 5:41 PM, Richard Damon wrote:
On 5/6/25 11:23 AM, olcott wrote:
On 5/6/2025 4:30 AM, Mikko wrote:
On 2025-05-05 19:27:18 +0000, olcott said:
On 5/5/2025 2:12 PM, dbush wrote:
On 5/5/2025 2:47 PM, olcott wrote:
On 5/5/2025 1:21 PM, dbush wrote:
On 5/5/2025 2:14 PM, olcott wrote:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input: >>>>>>>>>>>>>>
Input that would cause infinite recursion when using a >>>>>>>>>>>>>> decider of the
simulating kind.
Such input forms a category error which results in the >>>>>>>>>>>>>> halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes >>>>>>>>>>>>> all of the
halting problem proofs.
Which start with the assumption that the following mapping >>>>>>>>>>>> is computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>> instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>>> computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>> executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH >>>>>>>>>>>>> and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>
When HHH computes the mapping from *its input* to the >>>>>>>>>>>>> behavior of DD
emulated by HHH this includes HHH emulating itself
emulating DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly >>>>>>>>>>>>> determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the >>>>>>>>>>>> above
mapping is computable is proven false, as Linz and others >>>>>>>>>>>> have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting >>>>>>>>>>> problem proofs
including Linz. It is impossible to prove something which is >>>>>>>>>>> ill- formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed
directly. Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
In other words, you're claiming that there exists an algorithm, >>>>>>>> i.e. a fixed immutable sequence of instructions, that neither
halts nor does not halt when executed directly.
That is not what I said.
Then there's no category error, and the halting function is well
defined. It's just that no algorithm can compute it.
It is insufficiently defined thus causing it
to be incoherently defined.
It is well defined. There are computations that halt and
computations that
do not. Nothing else is in the scope of the halting problem.
It is incorrectly defined when-so-ever it is not specified
that a specific sequence of steps must be applied to the
input to derive the output.
Functions don't define the steps that create the mapping.
It is algorithms that perform them
We are saying the same thing here using different words.
There must be an algorithm having a specified sequence
of steps that are applied to the input to derive the output.
Op 07.mei.2025 om 03:39 schreef olcott:
There must be an algorithm having a specified sequence
of steps that are applied to the input to derive the output.
Your 'must' has no basis.
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make noDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only if) >>>>>>>>>>> thei.e. it is found to map something other than the above function >>>>>>>>>> which is a contradiction.
mapping FROM INPUTS IS COMPUTED.
attempt to
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS
INCORRECT you
simply take that same quote from a computer science textbook as >>>>>>>>> the
infallible word-of-God.
Every function computed by a model of computation must apply aNo, YOU don't understand what Computer Science actually is talking >>>>>> about.All you are doing is showing that you don't understand proof by >>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG!
specific
sequence of steps that are specified by the model to the actual finite >>>>> string input.
You are very confused. An algorithm or program computes a function.
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
Right, so HHH needs to apply the rules that it was designed with.
And that means it breaks the criteria that you say it needs to do to
get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
On 5/6/2025 2:16 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 19:54 schreef olcott:
On 5/6/2025 6:06 AM, Richard Damon wrote:
On 5/5/25 10:29 PM, olcott wrote:
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that it
refutes, and thus your talk about correctly emulated by HHH is
just a lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the representation >>>>>> of a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
Can't be, as the input needs to be about a program, which must, by
the definition of a program, include all its algorithm.
Yes, there are steps that also occur in the termination analyzer,
but they have been effectively copied into the program the input
describes.
Note, nothing says that the representation of the program has to be
an assembly level description of it. It has to be a complete
description, that 100% defines the results the code will generate
(and if it will generate) but it doesn't need to be the exact
assembly code,
YOU even understand that, as you present the code as "C" code, which
isn't assembly.
What you forget is that the input program INCLUDES as its definiton,
all of the code it uses, and thus the call to the decider it is
built on includes that code into the decider, and that is a FIXED
and DETERMINDED version of the decider, the one that THIS version of
the input is designed to make wrong.
This doesn't change when you hypothosize a different decider looking
at THIS input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
Refers to a hypothetical HHH/DD pair of the same HHH that
DD calls except that this hypothetical HHH never aborts.
HHH should decide about its actual input, not about a hypothetical input.
That is not what Professor Sipser agreed to.
*would never stop running unless aborted*
is the hypothetical HHH/DD pair where HHH
and DD are exactly the same except that
this hypothetical HHH never aborts.
On 5/6/2025 5:49 PM, Richard Damon wrote:
On 5/6/25 2:05 PM, olcott wrote:
On 5/6/2025 5:59 AM, Richard Damon wrote:
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
Which starts with the assumption that an algorithm exists that >>>>>>>> performs the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
DO COMPUTE THAT THE INPUT IS NON-HALTING
IFF (if and only if) the mapping FROM INPUTS
IS COMPUTED.
i.e. it is found to map something other than the above function >>>>>>>> which is a contradiction.
The above function VIOLATES COMPUTER SCIENCE.
You make no attempt to show how my claim
THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT
you simply take that same quote from a computer
science textbook as the infallible word-of-God.
All you are doing is showing that you don't understand proof by
contradiction,
Not at all. The COMPUTER SCIENCE of your requirements IS WRONG!
No, YOU don't understand what Computer Science actually is talking
about.
Every function computed by a model of computation
must apply a specific sequence of steps that are
specified by the model to the actual finite string
input.
Right, "Computed by a model of computation", that
HHH(DD) must emulate DD according to the rules
of the x86 language.
Right, which is doesn't do.
Remember, your HHH stop processing at a CALL HHH instruction.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
*input D* until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* // the actual input
*would never stop running unless aborted*
// A hypothetical HHH/DD pair where HHH and DD are
// exactly the same except that this HHH does not abort.
On 5/6/2025 2:10 PM, Fred. Zwarts wrote:That has been show hundredths of times. That you ignore it and keep
Op 06.mei.2025 om 20:47 schreef olcott:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is not
possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
That you do not understand it, does not mean that it has not been
provided to you. It has, many times. If you do not know that you are
wrong, you must be very stupid.
Everything besides a machine address by machine
address of DD emulated by HHH (according to the
rules of the x86 language) where the emulated
DD reaches its own "ret" instruction
*IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION*
On 5/6/2025 10:16 PM, dbush wrote:
On 5/6/2025 11:11 PM, olcott wrote:
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact that it >>>>>>>>>>>> is not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that >>>>>>>> HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the
two traces side by side some time ago, and they were indeed
IDENTICAL line for line up to the point where HHH decided to
discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the same up
to the point where HHH discontinued the simulation. How can it be
"counter-factual"?
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
A call that returns and a call that cannot possibly
return *are not exactly the same thing*
They are exactly the same up to the point that HHH aborted,
Counter-Factual they are exactly the same up until
The simulated / executed DD calls HHH(DD).
It is a long time later that HHH aborts the
simulation of its input DD.
After the executed DD calls the executed HHH(DD)
HHH emulates DD then emulates itself emulating DD.
This is a very long time after the divergence point.
On 5/6/2025 2:38 PM, dbush wrote:
On 5/6/2025 2:55 PM, olcott wrote:
On 5/6/2025 7:12 AM, dbush wrote:
On 5/6/2025 12:55 AM, olcott wrote:
On 5/5/2025 3:53 PM, Richard Heathfield wrote:
On 05/05/2025 20:38, olcott wrote:
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
20:45GMT, give or take.
is also "undecidable" because it is not a proposition
having a truth value.
No, it's computable and therefore decidable. Your computer is
perfectly capable of displaying its interpretation of the time.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
But we know that it halts at the full stop.
Can Carol correctly answer “no” to this (yes/no) question?
You have, I see, learned that not all yes/no questions are
decidable. Well done! You're coming along nicely.
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
The question is grammatically and syntactically unremarkable. I
see no grounds for claiming that it's 'incorrect'. It's just
undecidable.
You appear to be trying to overturn the Halting Problem by
claiming that Turing somehow cheated. You're entitled to hold that >>>>>> opinion, but it's not one that will gain any traction with peer
reviewers when you try to publish.
*EVERYONE IGNORES THIS*
It is very simple the mapping from inputs to outputs
must have a well defined sequence of steps.
FALSE!!!
There is no requirement that mappings have steps to compute them.
The requirement is that
Assuming that an algorithm exists that can compute the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
OUTPUTS must correspond
to INPUTS. This requires that outputs must be
derived from INPUTS.
And when a contradiction is reached that proves the above assumption
false, as Linz and others have proved, and you have *explicitly*
admitted is correct.
As I already said Linz is only correct when the halting
problem proof is construed as having an input that can
actually do the opposite of whatever value the termination
analyzer returns. Since this is false, Linz is wrong.
When the behavior of the input to HHH(DD) is measured
by DD emulated by HHH according to the rules of the x86
language the code designed to thwart HHH is unreachable.
On 5/6/2025 3:42 PM, dbush wrote:
On 5/6/2025 4:33 PM, olcott wrote:
On 5/6/2025 2:38 PM, dbush wrote:
On 5/6/2025 2:55 PM, olcott wrote:
On 5/6/2025 7:12 AM, dbush wrote:
On 5/6/2025 12:55 AM, olcott wrote:
On 5/5/2025 3:53 PM, Richard Heathfield wrote:
On 05/05/2025 20:38, olcott wrote:
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO >>>>>>>>>>> Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
20:45GMT, give or take.
is also "undecidable" because it is not a proposition
having a truth value.
No, it's computable and therefore decidable. Your computer is
perfectly capable of displaying its interpretation of the time. >>>>>>>>
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound >>>>>>>>> proposition having a truth value.
But we know that it halts at the full stop.
Can Carol correctly answer “no” to this (yes/no) question? >>>>>>>>You have, I see, learned that not all yes/no questions are
decidable. Well done! You're coming along nicely.
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
The question is grammatically and syntactically unremarkable. I >>>>>>>> see no grounds for claiming that it's 'incorrect'. It's just
undecidable.
You appear to be trying to overturn the Halting Problem by
claiming that Turing somehow cheated. You're entitled to hold
that opinion, but it's not one that will gain any traction with >>>>>>>> peer reviewers when you try to publish.
*EVERYONE IGNORES THIS*
It is very simple the mapping from inputs to outputs
must have a well defined sequence of steps.
FALSE!!!
There is no requirement that mappings have steps to compute them.
The requirement is that
Assuming that an algorithm exists that can compute the following
mapping:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
OUTPUTS must correspond
to INPUTS. This requires that outputs must be
derived from INPUTS.
And when a contradiction is reached that proves the above assumption
false, as Linz and others have proved, and you have *explicitly*
admitted is correct.
As I already said Linz is only correct when the halting
problem proof is construed as
After assuming that an algorithm exists to map the halting function
having an input that can
actually do the opposite of whatever value the termination
analyzer returns. Since this is false,
That proves the above assumption false, as Linz and others have proved
and as you have *explicitly* agreed is correct.
The fundamental basic assumption of all of the halting
problem proofs is that an input can actually do the
opposite of whatever value its decider returns.
THIS ASSUMPTION IS FALSE.
THE "DOING THE OPPOSITE" CODE IS UNREACHABLE.
On 5/6/2025 9:30 PM, Richard Damon wrote:
On 5/6/25 9:45 PM, olcott wrote:
On 5/6/2025 5:43 PM, Richard Damon wrote:
On 5/6/25 11:10 AM, olcott wrote:
On 5/6/2025 4:26 AM, Mikko wrote:
On 2025-05-05 18:14:25 +0000, olcott said:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a >>>>>>>>>>>> decider of the
simulating kind.
Such input forms a category error which results in the >>>>>>>>>>>> halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all >>>>>>>>>>> of the
halting problem proofs.
Which start with the assumption that the following mapping is >>>>>>>>>> computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed
directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH >>>>>>>>>>> and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the
behavior of DD
emulated by HHH this includes HHH emulating itself emulating >>>>>>>>>>> DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly >>>>>>>>>>> determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the >>>>>>>>>> above
mapping is computable is proven false, as Linz and others have >>>>>>>>>> proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting
problem proofs
including Linz. It is impossible to prove something which is >>>>>>>>> ill- formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed
directly. Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
Irrelevant. One of the boolean values (the one not returned) is the >>>>>> right one as can be determined e.g. with an UTM.
You only get something that appears that way when a falseThe mapping from the input HHH(DD) finite string of
assumption is made, namely that the halting function is computable. >>>>>>>
machine code to DOES SPECIFY RECURSIVE EMULATION
THAT WOULD PREVENT DD FROM EVER HALTING.
No, it does not. HHH returns 0 and DD halts.
You can't show the detailed steps of the execution
trace of DD emulated by HHH (according to the rules
of the x86 language) where DD halts because you are wrong.
Because a trace of DD correctly emulatd by HHH doesn't exist as HHH
doesn't correctly emulate DD
Show what the execution trace of DD emulated by HHH
according to the rules of the x86 language should be
Since HHH doesn't actually do that, your question is void.
You say it is wrong unless you are lying
you can point out what the correct steps should be.
The way that everyone can know that you are lying
is you will forever dodge the question what the
correct steps should be.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/6/2025 9:48 PM, dbush wrote:
On 5/6/2025 10:44 PM, olcott wrote:
On 5/6/2025 9:34 PM, Richard Damon wrote:
On 5/6/25 9:47 PM, olcott wrote:
On 5/6/2025 5:43 PM, Richard Damon wrote:
On 5/6/25 11:10 AM, olcott wrote:
On 5/6/2025 4:26 AM, Mikko wrote:
On 2025-05-05 18:14:25 +0000, olcott said:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input: >>>>>>>>>>>>>>
Input that would cause infinite recursion when using a >>>>>>>>>>>>>> decider of the
simulating kind.
Such input forms a category error which results in the >>>>>>>>>>>>>> halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes >>>>>>>>>>>>> all of the
halting problem proofs.
Which start with the assumption that the following mapping >>>>>>>>>>>> is computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>> instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>>> computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>> executed
directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH >>>>>>>>>>>>> and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>
When HHH computes the mapping from *its input* to the >>>>>>>>>>>>> behavior of DD
emulated by HHH this includes HHH emulating itself
emulating DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly >>>>>>>>>>>>> determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the >>>>>>>>>>>> above
mapping is computable is proven false, as Linz and others >>>>>>>>>>>> have proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting >>>>>>>>>>> problem proofs
including Linz. It is impossible to prove something which is >>>>>>>>>>> ill- formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed
directly. Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
Irrelevant. One of the boolean values (the one not returned) is the >>>>>>>> right one as can be determined e.g. with an UTM.
You only get something that appears that way when a false
assumption is made, namely that the halting function is
computable.
The mapping from the input HHH(DD) finite string of
machine code to DOES SPECIFY RECURSIVE EMULATION
THAT WOULD PREVENT DD FROM EVER HALTING.
No, it does not. HHH returns 0 and DD halts.
You can't show the detailed steps of the execution
trace of DD emulated by HHH (according to the rules
of the x86 language) where DD halts because you are wrong.
Because a trace of DD correctly emulatd by HHH doesn't exist as
HHH doesn't correctly emulate DD
Show what the execution trace of DD emulated by HHH
according to the rules of the x86 language should be
Since HHH doesn't do that,
and you cannot possibly point out what the correct
steps should be
The steps that UTM / HHH1 takes that HHH does not,
which are the steps of DD emulated by HHH
according to the rules of the x86 language
such that the simulated DD reaches its "ret"
instruction like the directly executed DD() does.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/6/2025 5:57 PM, Richard Damon wrote:
On 5/6/25 5:56 PM, olcott wrote:
On 5/6/2025 4:12 PM, dbush wrote:
On 5/6/2025 4:57 PM, olcott wrote:
On 5/6/2025 3:49 PM, dbush wrote:
On 5/6/2025 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no >>>>>>>>>>>>> attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only >>>>>>>>>>>>>>> if) thei.e. it is found to map something other than the above >>>>>>>>>>>>>> function
mapping FROM INPUTS IS COMPUTED.
which is a contradiction.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS >>>>>>>>>>>>> INCORRECT you
simply take that same quote from a computer science
textbook as the
infallible word-of-God.
Every function computed by a model of computation must apply a >>>>>>>>> specificabout.All you are doing is showing that you don't understand proof by >>>>>>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>>>> No, YOU don't understand what Computer Science actually is >>>>>>>>>> talking
sequence of steps that are specified by the model to the actual >>>>>>>>> finite
string input.
You are very confused. An algorithm or program computes a function. >>>>>>>>
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
False. Anything that correctly associates a function's input to a >>>>>> function's output for all elements of the function's domain does
in fact compute that function.
For example, given this function:
For all integers X and Y:
(X,Y) maps to 5
This algorithm computes it:
int foo(int X, int Y) { return 5; }
The rules that must be applied to the inputs
are
Anything that can associate the input with the output.
WRONG!
Any defined process that CAUSES an INPUT to be associated
with an OUTPUT.
And it does, it causes ALL inputs to be associated with the value 5.
Ignoring the input cannot possibly be construed
as computing the mapping from the input.
On 5/6/2025 5:56 PM, Richard Damon wrote:
On 5/6/25 4:57 PM, olcott wrote:
On 5/6/2025 3:49 PM, dbush wrote:
On 5/6/2025 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no >>>>>>>>>>> attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only >>>>>>>>>>>>> if) thei.e. it is found to map something other than the above function >>>>>>>>>>>> which is a contradiction.
mapping FROM INPUTS IS COMPUTED.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS
INCORRECT you
simply take that same quote from a computer science textbook >>>>>>>>>>> as the
infallible word-of-God.
Every function computed by a model of computation must apply aAll you are doing is showing that you don't understand proof by >>>>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>> No, YOU don't understand what Computer Science actually is talking >>>>>>>> about.
specific
sequence of steps that are specified by the model to the actual
finite
string input.
You are very confused. An algorithm or program computes a function. >>>>>>
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
False. Anything that correctly associates a function's input to a
function's output for all elements of the function's domain does in
fact compute that function.
For example, given this function:
For all integers X and Y:
(X,Y) maps to 5
This algorithm computes it:
int foo(int X, int Y) { return 5; }
The rules that must be applied to the inputs
are the rules of arithmetic. Since the input
was ignored foo() did not compute the sum
of any input. INPUTS must be transformed into
OUTPUTS using rules.
What rules said the method that must be used to get the answer?
The rules of the mapping define a way to get the correct answer, not
the only way to determine it.
Guessing is not one of the correct ways.
This is brand new computer science that I just created.
It can be inferred from the other details of what
computable functions are:
In other words you are admitting that you are just lying about
everythinng you said being applicable to the actual problems since you
are just talking about Olcott-Prorgramms which no one cares about, and
you probably can't actually define.
I expanded the knowledge of computer science by deducing
that functions computed by models of computation must apply
a specific sequence of steps to their inputs to derive
their outputs is proven by the fact that OUTPUTS must
correspond to INPUTS.
*Apply an algorithm TO INPUTS to derive OUTPUTS*
Thus all instances of models of computation that
ignore their inputs are not computing functions.
Computable functions have their analog in software
engineering. https://en.wikipedia.org/wiki/Pure_function
INPUTS must correspond to OUTPUTS.
There must be some process that ensures that
INPUTS correspond to OUTPUTS. Every process
must have some sequence of steps.
So?
The sequence of steps of DD emulated by HHH must
be according to the rules of the x86 language.
That doesn't seem to be that different from what classical theory
defines as a computation in a computational model.
Your problem is you confuse that with the mappings that Computations
are trying to compute to be correct.
And return 5, *IS* a sequence of steps, perhaps of just length 1.
It is required to be a sequence of steps of arithmetic
applied to the inputs.
On 5/6/2025 9:34 PM, Richard Damon wrote:
On 5/6/25 9:47 PM, olcott wrote:
On 5/6/2025 5:43 PM, Richard Damon wrote:
On 5/6/25 11:10 AM, olcott wrote:
On 5/6/2025 4:26 AM, Mikko wrote:
On 2025-05-05 18:14:25 +0000, olcott said:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a >>>>>>>>>>>> decider of the
simulating kind.
Such input forms a category error which results in the >>>>>>>>>>>> halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all >>>>>>>>>>> of the
halting problem proofs.
Which start with the assumption that the following mapping is >>>>>>>>>> computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed
directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH >>>>>>>>>>> and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the
behavior of DD
emulated by HHH this includes HHH emulating itself emulating >>>>>>>>>>> DD. This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly >>>>>>>>>>> determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the >>>>>>>>>> above
mapping is computable is proven false, as Linz and others have >>>>>>>>>> proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting
problem proofs
including Linz. It is impossible to prove something which is >>>>>>>>> ill- formed
in the first place.
/Flibble
All algorithms either halt or do not halt when executed
directly. Therefore the problem is not ill formed.
When BOTH Boolean RETURN VALUES are the wrong answer
THEN THE PROBLEM IS ILL-FORMED. Self-contradiction must
be screened out as semantically incorrect.
Irrelevant. One of the boolean values (the one not returned) is the >>>>>> right one as can be determined e.g. with an UTM.
You only get something that appears that way when a falseThe mapping from the input HHH(DD) finite string of
assumption is made, namely that the halting function is computable. >>>>>>>
machine code to DOES SPECIFY RECURSIVE EMULATION
THAT WOULD PREVENT DD FROM EVER HALTING.
No, it does not. HHH returns 0 and DD halts.
You can't show the detailed steps of the execution
trace of DD emulated by HHH (according to the rules
of the x86 language) where DD halts because you are wrong.
Because a trace of DD correctly emulatd by HHH doesn't exist as HHH
doesn't correctly emulate DD
Show what the execution trace of DD emulated by HHH
according to the rules of the x86 language should be
Since HHH doesn't do that,
and you cannot possibly point out what the correct
steps should be because you know that you are lying.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make noDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only if) >>>>>>>>>>> thei.e. it is found to map something other than the above function >>>>>>>>>> which is a contradiction.
mapping FROM INPUTS IS COMPUTED.
attempt to
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS
INCORRECT you
simply take that same quote from a computer science textbook as >>>>>>>>> the
infallible word-of-God.
Every function computed by a model of computation must apply aNo, YOU don't understand what Computer Science actually is talking >>>>>> about.All you are doing is showing that you don't understand proof by >>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG!
specific
sequence of steps that are specified by the model to the actual finite >>>>> string input.
You are very confused. An algorithm or program computes a function.
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
Right, so HHH needs to apply the rules that it was designed with.
And that means it breaks the criteria that you say it needs to do to
get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
Is the hypothetical HHH/DD pair where HHH does not abort.
Note, the rules of how to compute say NOTHING about what is the
correct answer to the question, the definition of the function to be
computed does that, and that clearly says to look at the behavior of
the program the input represents
That has always been stupidly wrong.
Look at the behavior that the finite string input specifies.
Not look at some behavior that cannot possibly be derived by
applying the rules of the x86 language to this finite string input.
On 5/6/2025 5:49 PM, Richard Damon wrote:
On 5/6/25 2:05 PM, olcott wrote:
On 5/6/2025 5:59 AM, Richard Damon wrote:
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
Which starts with the assumption that an algorithm exists that >>>>>>>> performs the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
DO COMPUTE THAT THE INPUT IS NON-HALTING
IFF (if and only if) the mapping FROM INPUTS
IS COMPUTED.
i.e. it is found to map something other than the above function >>>>>>>> which is a contradiction.
The above function VIOLATES COMPUTER SCIENCE.
You make no attempt to show how my claim
THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT
you simply take that same quote from a computer
science textbook as the infallible word-of-God.
All you are doing is showing that you don't understand proof by
contradiction,
Not at all. The COMPUTER SCIENCE of your requirements IS WRONG!
No, YOU don't understand what Computer Science actually is talking
about.
Every function computed by a model of computation
must apply a specific sequence of steps that are
specified by the model to the actual finite string
input.
Right, "Computed by a model of computation", that
HHH(DD) must emulate DD according to the rules
of the x86 language.
Right, which is doesn't do.
Remember, your HHH stop processing at a CALL HHH instruction.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
*input D* until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* // the actual input
*would never stop running unless aborted*
// A hypothetical HHH/DD pair where HHH and DD are
// exactly the same except that this HHH does not abort.
On 5/6/2025 5:59 PM, Richard Damon wrote:
On 5/6/25 3:20 PM, olcott wrote:
On 5/6/2025 2:10 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 20:47 schreef olcott:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is
not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
That you do not understand it, does not mean that it has not been
provided to you. It has, many times. If you do not know that you are
wrong, you must be very stupid.
Everything besides a machine address by machine
address of DD emulated by HHH (according to the
rules of the x86 language) where the emulated
DD reaches its own "ret" instruction
In other words, if people don't agree with your fantasy that is just
in error, then "they" must be wrong.
No, it
*IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION*
No, YOU are a dishoneast dodge from the actual question
Most of my reviewers switch to rhetoric when they
know that they are wrong and still want to disagree.
Disagreement (not truth) is their highest priority.
Nope, that is just you projecting again.
You keep saying the DD emulated by HHH according
to the rules of the x86 language is wrong.
You keep arguing that HHH is required to break these
rules to conform with the common misconception that HHH
is required to report on the direct execution of DD().
How the Hell can breaking the rules specified
by the x86 language possibly be correct?
On 5/6/2025 6:00 PM, Richard Damon wrote:
On 5/6/25 1:54 PM, olcott wrote:
On 5/6/2025 6:06 AM, Richard Damon wrote:
On 5/5/25 10:29 PM, olcott wrote:
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that it
refutes, and thus your talk about correctly emulated by HHH is
just a lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the representation >>>>>> of a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
Can't be, as the input needs to be about a program, which must, by
the definition of a program, include all its algorithm.
Yes, there are steps that also occur in the termination analyzer,
but they have been effectively copied into the program the input
describes.
Note, nothing says that the representation of the program has to be
an assembly level description of it. It has to be a complete
description, that 100% defines the results the code will generate
(and if it will generate) but it doesn't need to be the exact
assembly code,
YOU even understand that, as you present the code as "C" code, which
isn't assembly.
What you forget is that the input program INCLUDES as its definiton,
all of the code it uses, and thus the call to the decider it is
built on includes that code into the decider, and that is a FIXED
and DETERMINDED version of the decider, the one that THIS version of
the input is designed to make wrong.
This doesn't change when you hypothosize a different decider looking
at THIS input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
Refers to a hypothetical HHH/DD pair of the same HHH that
DD calls except that this hypothetical HHH never aborts.
Right, but a correct simulation of D does halt,
How the Hell is breaking the rules specified
by the x86 language possibly correct?
I could say that the sum of 5 + 7 is a dirty sock
according to the rules of random gibberish.
When I go by the rules of arithmetic I am proved
wrong.
DD <is> emulated by HHH according to the rules
of the x86 language that specify the HHH also
emulates itself emulating DD
until HHH determines that for the hypothetical
HHH/DD pair where the hypothetical HHH never
aborts DD would never stop running.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
refers to the hypothetical HHH/DD pair where
HHH never aborts its simulation.
On 5/6/2025 7:12 AM, dbush wrote:Yes, and it is not allowed to just assume HHH doesn't halt.
On 5/6/2025 12:55 AM, olcott wrote:
The requirement is that OUTPUTS must correspond to INPUTS. This requires*EVERYONE IGNORES THIS*FALSE!!!
It is very simple the mapping from inputs to outputs must have a well
defined sequence of steps.
There is no requirement that mappings have steps to compute them.
that outputs must be derived from INPUTS.
When DD is correctly emulated by HHH it is only allowed to apply the
specific sequence specified by the x86 language to derive the behavior specified by this input.
Everyone here seems to think that HHH is allowed to ignore the "call" instruction in DD and jump directly to the "ret" instruction in DD.We know the call to HHH returns because it is a decider. You seem to
On 5/7/2025 1:18 AM, Richard Heathfield wrote:
There's also an important difference between claiming that
Mike's claim is counter-factual and /proving/ that his claim is
counter-factual.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The reason that I get angry is that everyone here
has denied that verified fact for three years.
Can it really be true that most people here don't
hardly have any clue about actual programming?
Mike says he's posted evidence in support of his claim. I
haven't seen it, but of the two of you I will unhesitatingly
take his word for it rather than yours. Have you posted a
rebuttal? If not, why not?
The rebuttal is that
Even the simple code shown above proves that DD
correctly simulated by HHH cannot possibly reach its
own halt state.
I never take anyone's word, not even my doctor's word.
On 5/7/2025 1:18 AM, Richard Heathfield wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
<snip>
HHH and UTM emulate DD exactly the same up until the point that
HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the two
traces side by side some time ago, and they were indeed IDENTICAL
line for line up to the point where HHH decided to discontinue
simulating.
That is counter-factual.
People who can be bothered to check for themselves can check for
themselves.
People who (like me) can't be arsed to go through the palaver of
getting your code to work must instead decide who they think is more
credible - you or Mike.
No contest.
If you want people to believe you, you've got your work cut out.
Shooting emotionally from the hip (as you do) isn't as convincing as
explaining precisely, logically, and dispassionately why you're right
(as Mike does).
If I were to run a book right now on an independent investigation of
the point in the trace where the two traces diverge, I could offer
astronomical odds on your claim without any fear of losing a penny,
but no matter what odds I offered on Mike I would quickly have to
close the book on his claim or face bankruptcy.
It isn't just your logic that needs a lot off work; it's your
presentation, too. You come across as someone who /believes/ you're
right, but it's not enough to call down lightning on Mike the heretic;
Mike manages to keep calm because he /knows/ he's right. There's a
huge and important difference between the two.
There's also an important difference between claiming that Mike's
claim is counter-factual and /proving/ that his claim is counter-factual.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Any sufficiently competent C programmer can see that
when DD is correctly simulated by HHH that this
simulated DD cannot get past its call to HHH(DD).
The reason that I get angry is that everyone here
has denied that verified fact for three years.
Can it really be true that most people here don't
hardly have any clue about actual programming?
Mike says he's posted evidence in support of his claim. I haven't seen
it, but of the two of you I will unhesitatingly take his word for it
rather than yours. Have you posted a rebuttal? If not, why not?
The rebuttal is that
Even the simple code shown above proves that DD
correctly simulated by HHH cannot possibly reach its
own halt state.
I never take anyone's word, not even my doctor's word.
On 5/7/2025 4:48 AM, Mikko wrote:
On 2025-05-06 18:40:16 +0000, olcott said:
On 5/6/2025 10:53 AM, joes wrote:
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to
report
on the direct execution of DD() and the input to HHH specifies a >>>>>>> different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence >>>>>> of steps as DD. HHH just answers about a different sequence of steps >>>>>> instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D until
H correctly determines that its simulated D *would never stop
running unless aborted* then
*input D* is the actual input *would never stop running unless
aborted*
is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a
hypothetical version of D that calls a pure simulator.
*would never stop running unless aborted*
refers to the same HHH that DD calls yet
this hypothetical HHH does not abort.
You cannot possibly show the exact execution trace where DD is
correctly
emulated by HHH and this emulated DD reaches past its own machine
address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can simulate >>>> DD/HHH.
HHH does simulate itself correctly yet must create
No, it cannot simulate itself to the point where it returns.
HHH(DD) does return.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its *simulated D*
*would never stop running unless aborted* then
HHH only need simulate DD until it correctly determines
*simulated D would never stop running unless aborted*
This refers to a hypothetical HHH/DD pair where HHH never aborts.
On 5/7/2025 6:01 AM, Richard Damon wrote:
On 5/6/25 10:28 PM, olcott wrote:
On 5/6/2025 5:59 PM, Richard Damon wrote:
On 5/6/25 3:20 PM, olcott wrote:
On 5/6/2025 2:10 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 20:47 schreef olcott:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is >>>>>>>>>> not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
That you do not understand it, does not mean that it has not been
provided to you. It has, many times. If you do not know that you
are wrong, you must be very stupid.
Everything besides a machine address by machine
address of DD emulated by HHH (according to the
rules of the x86 language) where the emulated
DD reaches its own "ret" instruction
In other words, if people don't agree with your fantasy that is just
in error, then "they" must be wrong.
No, it
*IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION*
No, YOU are a dishoneast dodge from the actual question
Most of my reviewers switch to rhetoric when they
know that they are wrong and still want to disagree.
Disagreement (not truth) is their highest priority.
Nope, that is just you projecting again.
You keep saying the DD emulated by HHH according
to the rules of the x86 language is wrong.
Right, because it stops wnen it should not.
You keep arguing that HHH is required to break these
rules to conform with the common misconception that HHH
is required to report on the direct execution of DD().
No, it needs to keep to them, which it doesn\'t.
Where did I say it must break the rules?
DD correctly simulated by HHH according to the rules
of the x86 language cannot possibly halt.
On 5/7/2025 6:33 AM, joes wrote:
Am Tue, 06 May 2025 13:55:03 -0500 schrieb olcott:
On 5/6/2025 7:12 AM, dbush wrote:Yes, and it is not allowed to just assume HHH doesn't halt.
On 5/6/2025 12:55 AM, olcott wrote:
The requirement is that OUTPUTS must correspond to INPUTS. This requires >>> that outputs must be derived from INPUTS.*EVERYONE IGNORES THIS*FALSE!!!
It is very simple the mapping from inputs to outputs must have a well >>>>> defined sequence of steps.
There is no requirement that mappings have steps to compute them.
When DD is correctly emulated by HHH it is only allowed to apply the
specific sequence specified by the x86 language to derive the behavior
specified by this input.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH (as every competent C programmer can see)
sees that DD correctly simulated by HHH cannot
possibly reach its of "return" instruction.
It is very difficult for me to accept that everyone
here has been mostly clueless about actual programming
so that they deny this.
It's funny, you're asking for a correct simulation by HHH, but HHH
can't do it, so that's impossible. That doesn't make it right.
A "correct simulation" cannot be based on some misconception
about what the end result is supposed to be. It must be based
on the behavior that the finite string actually specifies.
If you don't have any clue about programming thus cannot
possibly verify my claim and you still claim that I
am wrong THAT IS DISHONEST.
You can claim that it is your opinion that I am wrong.
When you claim that I am actually wrong knowing full
well that you cannot possibly verify my proof that I
am correct this is a *reckless disregard for the truth*
On 5/7/2025 5:55 AM, Richard Damon wrote:
On 5/6/25 10:09 PM, olcott wrote:
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no >>>>>>>>>>> attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only >>>>>>>>>>>>> if) thei.e. it is found to map something other than the above function >>>>>>>>>>>> which is a contradiction.
mapping FROM INPUTS IS COMPUTED.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS
INCORRECT you
simply take that same quote from a computer science textbook >>>>>>>>>>> as the
infallible word-of-God.
Every function computed by a model of computation must apply aAll you are doing is showing that you don't understand proof by >>>>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>> No, YOU don't understand what Computer Science actually is talking >>>>>>>> about.
specific
sequence of steps that are specified by the model to the actual
finite
string input.
You are very confused. An algorithm or program computes a function. >>>>>>
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
Right, so HHH needs to apply the rules that it was designed with.
And that means it breaks the criteria that you say it needs to do to
get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
No, to be a correct emulator it needs to continue until it reaches the
end,
It can get the right answer if it emulates the input to the point that
it can show that a
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
Right, that UTM(D) would never halt.
*would never stop running unless aborted*
Is the hypothetical HHH/DD pair where HHH does not abort.
Nope, can't change DD, it is your hypothetical HHH, which has become
UTM, when given the ORIGINAL DD, which calls the ORIGINAL HHH, as that
code was part of the definition of DD.
HHH bases its decision on what the behavior of DD
would be if a hypothetical version of its own self
never aborted.
On 5/7/2025 6:12 AM, Richard Damon wrote:
On 5/6/25 10:40 PM, olcott wrote:
On 5/6/2025 6:00 PM, Richard Damon wrote:
Right, how is HHH correct to abort its emulation?Right, but a correct simulation of D does halt,How the Hell is breaking the rules specified by the x86 language
possibly correct?
Where are *his* words?I still have the original email.*would never stop running unless aborted*That second paragraph is a lie and a misquote.
refers to the hypothetical HHH/DD pair where HHH never aborts
its simulation.
Ben has already verified this.
This is an actual cut-and-paste of the words
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is not possible to construct a
universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the two traces side by side some
time ago, and they were indeed IDENTICAL line for line up to the point where HHH decided to
discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the same up to the point where HHH
discontinued the simulation. How can it be "counter-factual"?
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
A call that returns and a call that cannot possibly
return *are not exactly the same thing*
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* refers to the actual HHH/DD pair
..which is not to be changed during hypothetical modifications to H
*would never stop running unless aborted*
refers to the hypothetical HHH/DD pair where
HHH and DDD are exactly the same except that
this hypothetical HHH does not abort the
simulation of its input.
No, that doesn't work in your x86utm because you mix up code (HHH) and data (DD, which directly
calls HHH). DD must be "exactly the same" / including all its subroutines/,
Not at all. Professor Sipser agreed that the actual
HHH/DD must base its decision on the hypothetical
HHH/DD that never aborts its simulation.
*would never stop running unless aborted*yawn
*would never stop running unless aborted*
*would never stop running unless aborted*
but DD calls HHH so HHH must be exactly the same, otherwise the input has been changed which is
NOT ALLOWED.
Intuitively it would seem that way until you examine
every single detail 100% completely.
To make this work you have to create a /new/ "HHH that does not abort the simulation".
Professor Sipser already agreed that the actual HHH/DD
must base its decision on the hypothetical HHH/DD
that never aborts.
E.g. clone HHH to HHH_hypothetical then take out the abort logic from HHH_hypothetical. From
main() call HHH_hypothetical(DD). That way DD is unchanged as required.
The trace by UTM continued further, with DD returning some time later. >>>>
The above HHH1(DD) is this UTM.
HHH1 will serve in this case, since it happens to not abort due to your coding errors.
It does not happen to not abort due to coding
errors. That is a reckless disregard for the truth.
The code has specified exactly why it need not
abort for several years now.
It would be cleaner to make a function UTM() which just has the DebugStep loop and no abort logic.
Professor Sipser already agreed that the actual HHH/DD
must base its decision on the hypothetical HHH/DD
that never aborts, AKA your UTM.
So... are you saying that HHH has seen enough of the simulation to correctly determined that
HHH1(DD) never returns? That would be bizarre, since you know HHH1(DD) /does/ return.
Functions computed by models of computation must
apply the steps of an algorithm *to the input*
to derive the outputs.
HHH has seen enough of the execution trace of DD
to know that
*simulated D would never stop running unless aborted*
This refers to the hypothetical HHH/DD pair such that
HHH never aborts.
On 07/05/2025 11:26, Fred. Zwarts wrote:
Op 07.mei.2025 om 03:39 schreef olcott:
<snip>
There must be an algorithm having a specified sequence of steps thatYour 'must' has no basis.
are applied to the input to derive the output.
Not only that, but he is literally begging the question - i.e. assuming
as true that which he hopes to prove. "All questions must be decidable, therefore all questions are decidable."
Turing assumed the same thing: "All questions are decidable." But he
went on to demonstrate that if the assumption is true, it must be false
- a patent absurdity that shows that his original assumption was false.
On 07/05/2025 17:17, Mr Flibble wrote:
<nonsense snipped>
Nothing left.
On Wed, 07 May 2025 18:03:01 +0100, Richard Heathfield wrote:
On 07/05/2025 17:17, Mr Flibble wrote:
<nonsense snipped>
Nothing left.
Nonsense? Nothing left? Yes, it is YOU that has no argument.
On 5/6/2025 4:30 AM, Mikko wrote:
On 2025-05-05 19:27:18 +0000, olcott said:
On 5/5/2025 2:12 PM, dbush wrote:
On 5/5/2025 2:47 PM, olcott wrote:
On 5/5/2025 1:21 PM, dbush wrote:
On 5/5/2025 2:14 PM, olcott wrote:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
Oh wow. As a simulator, HHH must produce the same behaviour as the direct execution.It is incorrectly defined when-so-ever it is not specified that aThat is not what I said.When BOTH Boolean RETURN VALUES are the wrong answer THEN THEThe category (type) error manifests in all extant haltingWhen HHH computes the mapping from *its input* to the behavior >>>>>>>>>>> of DD emulated by HHH this includes HHH emulating itself >>>>>>>>>>> emulating DD. This matches the infinite recursion behavior >>>>>>>>>>> pattern.Which is a contradiction. Therefore the assumption that the >>>>>>>>>> above mapping is computable is proven false, as Linz and others >>>>>>>>>> have proved and as you have *explicitly* agreed is correct. >>>>>>>>>
Thus the Halting Problem's "impossible" input is correctly >>>>>>>>>>> determined to be non-halting.
problem proofs including Linz. It is impossible to prove
something which is ill- formed in the first place.
All algorithms either halt or do not halt when executed directly. >>>>>>>> Therefore the problem is not ill formed.
PROBLEM IS ILL-FORMED. Self-contradiction must be screened out as >>>>>>> semantically incorrect.
In other words, you're claiming that there exists an algorithm,
i.e. a fixed immutable sequence of instructions, that neither halts >>>>>> nor does not halt when executed directly.
Then there's no category error, and the halting function is well
defined. It's just that no algorithm can compute it.
It is insufficiently defined thus causing it to be incoherently
defined.
It is well defined. There are computations that halt and computations
that do not. Nothing else is in the scope of the halting problem.
specific sequence of steps must be applied to the input to derive the
output.
That DD() halts therefore I guess that DD correctly emulated by HHH must
halt too IS NOT A SPECIFIC SEQUENCE OF STEPS.
It is merely an incorrect guess.
On 5/6/2025 10:53 AM, joes wrote:Then it is not the same HHH.
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to
report on the direct execution of DD() and the input to HHH
specifies a different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence
of steps as DD. HHH just answers about a different sequence of steps
instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D *would never
stop running unless aborted* then
*input D* is the actual input *would never stop running unless
aborted* is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a*would never stop running unless aborted*
hypothetical version of D that calls a pure simulator.
refers to the same HHH that DD calls yet this hypothetical HHH does not abort.
No, HHH simulates only one program. Anything the simulated programYou cannot possibly show the exact execution trace where DD is
correctly emulated by HHH and this emulated DD reaches past its own
machine address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can simulateHHH does simulate itself correctly yet must create a separate process
DD/HHH.
context for each recursive emulation.
Each process context has its own stack and set of virtual registers.
On 5/7/2025 10:44 AM, Mike Terry wrote:
On 07/05/2025 04:11, olcott wrote:
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact that it is not possible to construct
a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the two traces side by side some
time ago, and they were indeed IDENTICAL line for line up to the point where HHH decided to
discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the same up to the point where HHH
discontinued the simulation. How can it be "counter-factual"?
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
A call that returns and a call that cannot possibly
return *are not exactly the same thing*
You need to read what posters actually say. I said the traces were the same up to the point where
HHH stops simulating.
THAT IS COUNTER-FACTUAL.
HHH continues to emulate DD long after their paths diverge.
HHH1 only emulates DD once.
HHH emulates DD once and then emulates itself emulating DD.
I didn't say anything about calls that return or do not return "being the same thing" and none of
what you relates to whether what I said was correct.
Look, if you insist the traces are not the same up to the point where HHH stops simulating, show
the two traces and we'll just look and see! Simples.
HHH1(DD) emulates DD once.
HHH(DD) emulates DD once and then emulates itself emulating DD.
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD [000021c6][0010386a][000021cb] e853f3ffff call 0000151e // call HHH1
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000213e][0011390e][00113912] 55 push ebp [0000213f][0011390e][00113912] 8bec mov ebp,esp [00002141][0011390a][00103916] 51 push ecx [00002142][00113906][0000213e] 683e210000 push 0000213e // push DD [00002147][00113902][0000214c] e8a2f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
Begin Local Halt Decider Simulation Execution Trace Stored at:15e346 [0000213e][0015e336][0015e33a] 55 push ebp [0000213f][0015e336][0015e33a] 8bec mov ebp,esp [00002141][0015e332][0014e33e] 51 push ecx [00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD [00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call HHH
New slave_stack at:198d66
[0000213e][001a8d5e][001a8d62] 55 push ebp [0000213f][001a8d5e][001a8d62] 8bec mov ebp,esp [00002141][001a8d5a][00198d66] 51 push ecx [00002142][001a8d56][0000213e] 683e210000 push 0000213e [00002147][001a8d52][0000214c] e8a2f4ffff call 000015ee
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[0000214c][0011390a][00103916] 83c404 add esp,+04 [0000214f][0011390a][00000000] 8945fc mov [ebp-04],eax [00002152][0011390a][00000000] 837dfc00 cmp dword [ebp-04],+00 [00002156][0011390a][00000000] 7402 jz 0000215a [0000215a][0011390a][00000000] 8b45fc mov eax,[ebp-04] [0000215d][0011390e][00113912] 8be5 mov esp,ebp [0000215f][00113912][000015d3] 5d pop ebp [00002160][00113916][0003a980] c3 ret [000021cb][00103872][00000000] 83c404 add esp,+04 [000021ce][0010386e][00000001] 50 push eax [000021cf][0010386a][0000075f] 685f070000 push 0000075f [000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 1
[000021d9][00103872][00000000] 83c408 add esp,+08 [000021dc][00103872][00000000] 33c0 xor eax,eax [000021de][00103876][00000018] 5d pop ebp [000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(400885) == 5983 Pages
At this point, no need to be too formal, just a high level trace, e.g. referencing C code rather
than instruction addresses...
The directed graph of the x86 code leaves zero
room for incorrect interpretation.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* refers to the actual HHH/DD pair
..which is not to be changed during hypothetical modifications to H
*would never stop running unless aborted*
refers to the hypothetical HHH/DD pair where
HHH and DDD are exactly the same except that
this hypothetical HHH does not abort the
simulation of its input.
No, that doesn't work in your x86utm because you mix up code (HHH) and data (DD, which directly
calls HHH). DD must be "exactly the same" / including all its subroutines/,
Not at all. Professor Sipser agreed that the actual
HHH/DD must base its decision on the hypothetical
HHH/DD that never aborts its simulation.
Nonsense. He is taking it as read that the input is not changed. What he agreed was that the
actual HHH can base its decision on the hypothetical HHH that never aborts its simulation, running
against *identical input* DD. Identical means has identical behaviour to original DD, in
particular it calls original HHH,
No it does not.
*simulated D would never stop running unless aborted*
refers to a hypothetical HHH that does not abort.
not some modified HHH or UTM.
Of course, Sipser would not understand how you have mangled the design of your utmx86 environment.
He would naturally take it that you were correctly implementing basic features of the TM halting
problem, like the input data being totally distinct from the TM state table. So it would simply
never occur to him that in your world, changing the code of HHH would have any effect on the data
input DD, which explains why he does not explicitly mention that.
yawn
*would never stop running unless aborted*
*would never stop running unless aborted*
*would never stop running unless aborted*
but DD calls HHH so HHH must be exactly the same, otherwise the input has been changed which is
NOT ALLOWED.
Intuitively it would seem that way until you examine
every single detail 100% completely.
To make this work you have to create a /new/ "HHH that does not abort the simulation".
Professor Sipser already agreed that the actual HHH/DD
must base its decision on the hypothetical HHH/DD
that never aborts.
You are quite incapable of understanding what Sipser was agreeing to.
*simulated D would never stop running unless aborted*
doesn't really leave much subjective leeway of interpretation.
This can only mean the behavior of DD when a hypothetical
HHH that never aborts would replace the body of the actual HHH.
More generally you have a problem understanding what other people believe and what they are
communicating to you. I've suggested you have some neural wiring issue, and for sure this would
be tied in to that somehow.
No it is all a matter of people not bothering to pay
enough attention because of their mental bias that
I must be wrong.
Regardless of that, you are trying to use Sipser's quote as an appeal to authority, which you
understand is a fallacy but think its ok to do it anyway. [Even though you are quick to accuse
other people of doing that when it suits you.]
An appeal to a qualified authority is inductively sound.
Just stop mentioning Sipser's quote altogether! It is not helping your case in any shape or form.
E.g. clone HHH to HHH_hypothetical then take out the abort logic from HHH_hypothetical. From
main() call HHH_hypothetical(DD). That way DD is unchanged as required. >>>>
The trace by UTM continued further, with DD returning some time later. >>>>>>
The above HHH1(DD) is this UTM.
HHH1 will serve in this case, since it happens to not abort due to your coding errors.
It does not happen to not abort due to coding
errors. That is a reckless disregard for the truth.
The code has specified exactly why it need not
abort for several years now.
No, it's due to coding errors. You intended HHH1 to be a clone of HHH, with the same algorithm as
HHH, but at a different address.
You just screwed it up due to your inappropriate use of global variables. If you had coded things
correctly HHH(DD) and HHH1(DD) would both have (incorrectly) decided halts. I explained the gory
details of all this to you months/years ago.
Merely proving that you still fail to understand
that the fact that DD calls HHH(DD) and does not call
HHH1(DD) MAKES ALL THE DIFFERENCE IN THEIR BEHAVIOR.
It would be cleaner to make a function UTM() which just has the DebugStep loop and no abort logic.
Professor Sipser already agreed that the actual HHH/DD
must base its decision on the hypothetical HHH/DD
that never aborts, AKA your UTM.
Sipser would be ok with my UTM, simulating THE ORIGINAL DD, which calls THE ORIGINAL HHH.
The words that he agreed to
*simulated D would never stop running unless aborted*
Since this HHH DOES ABORT the HHH THAT DOES NOT ABORT
must be a different hypothetical HHH.
Simulating halt deciders must PREDICT WHAT THE BEHAVIOR
WOULD BE IF THEY DID NOT ABORT.
They cannot simply wait-and-see or they get stuck.
On 5/7/2025 4:20 PM, Mike Terry wrote:
On 07/05/2025 17:25, olcott wrote:
On 5/7/2025 10:44 AM, Mike Terry wrote:
On 07/05/2025 04:11, olcott wrote:
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact that it is not possible to
construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH >>>>>>>>>>>>> according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>>>>>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the two traces side by side
some time ago, and they were indeed IDENTICAL line for line up to the point where HHH
decided to discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the same up to the point where HHH
discontinued the simulation. How can it be "counter-factual"?
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
A call that returns and a call that cannot possibly
return *are not exactly the same thing*
You need to read what posters actually say. I said the traces were the same up to the point
where HHH stops simulating.
THAT IS COUNTER-FACTUAL.
HHH continues to emulate DD long after their paths diverge.
HHH1 only emulates DD once.
HHH emulates DD once and then emulates itself emulating DD.
I didn't say anything about calls that return or do not return "being the same thing" and none
of what you relates to whether what I said was correct.
Look, if you insist the traces are not the same up to the point where HHH stops simulating, show
the two traces and we'll just look and see! Simples.
HHH1(DD) emulates DD once.
HHH(DD) emulates DD once and then emulates itself emulating DD.
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD
[000021c6][0010386a][000021cb] e853f3ffff call 0000151e // call HHH1 >>> New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e
[0000213e][0011390e][00113912] 55 push ebp
[0000213f][0011390e][00113912] 8bec mov ebp,esp
[00002141][0011390a][00103916] 51 push ecx
[00002142][00113906][0000213e] 683e210000 push 0000213e // push DD
[00002147][00113902][0000214c] e8a2f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
Begin Local Halt Decider Simulation Execution Trace Stored at:15e346
[0000213e][0015e336][0015e33a] 55 push ebp
[0000213f][0015e336][0015e33a] 8bec mov ebp,esp
[00002141][0015e332][0014e33e] 51 push ecx
[00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD
[00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call HHH
New slave_stack at:198d66
[0000213e][001a8d5e][001a8d62] 55 push ebp
[0000213f][001a8d5e][001a8d62] 8bec mov ebp,esp
[00002141][001a8d5a][00198d66] 51 push ecx
[00002142][001a8d56][0000213e] 683e210000 push 0000213e
[00002147][001a8d52][0000214c] e8a2f4ffff call 000015ee
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[0000214c][0011390a][00103916] 83c404 add esp,+04
[0000214f][0011390a][00000000] 8945fc mov [ebp-04],eax
[00002152][0011390a][00000000] 837dfc00 cmp dword [ebp-04],+00
[00002156][0011390a][00000000] 7402 jz 0000215a
[0000215a][0011390a][00000000] 8b45fc mov eax,[ebp-04]
[0000215d][0011390e][00113912] 8be5 mov esp,ebp
[0000215f][00113912][000015d3] 5d pop ebp
[00002160][00113916][0003a980] c3 ret
[000021cb][00103872][00000000] 83c404 add esp,+04
[000021ce][0010386e][00000001] 50 push eax
[000021cf][0010386a][0000075f] 685f070000 push 0000075f
[000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 1
[000021d9][00103872][00000000] 83c408 add esp,+08
[000021dc][00103872][00000000] 33c0 xor eax,eax
[000021de][00103876][00000018] 5d pop ebp
[000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(400885) == 5983 Pages
Excellent - above we have the trace for HHH1, half of what we need. While we /could/ use that to
/deduce/ what the trace for HHH should be, we shouldn't have to resort to that. The clean way to
proceed is for you to now post the similar trace for main calling HHH, then we can compare them
with minimal editing...
Mike.
The two calls to HHH(DD) are in the part you ignored.
HHH1(DD) emulates DD that calls the emulated HHH(DD)
to emulate DD that calls HHH(DD) that emulates itself
emulating DD.
I marked these calls with comments.
HHH1(DD) emulates DD just once.
HHH(DD) emulates DD twice. 2 != 1.
On Wed, 07 May 2025 11:35:07 +0100, Richard Heathfield wrote:
On 07/05/2025 11:26, Fred. Zwarts wrote:
Op 07.mei.2025 om 03:39 schreef olcott:
<snip>
There must be an algorithm having a specified sequence of steps thatYour 'must' has no basis.
are applied to the input to derive the output.
Not only that, but he is literally begging the question - i.e. assuming
as true that which he hopes to prove. "All questions must be decidable,
therefore all questions are decidable."
Turing assumed the same thing: "All questions are decidable." But he
went on to demonstrate that if the assumption is true, it must be false
- a patent absurdity that shows that his original assumption was false.
Wrong. All *well-formed* questions are decidable; the question the halting problem asks is not *well-formed*; if is *ill-formed* as it is predicated
on a category (type) error.
/Flibble
On 5/7/2025 3:25 PM, joes wrote:
Am Tue, 06 May 2025 10:23:18 -0500 schrieb olcott:
On 5/6/2025 4:30 AM, Mikko wrote:
On 2025-05-05 19:27:18 +0000, olcott said:
On 5/5/2025 2:12 PM, dbush wrote:
On 5/5/2025 2:47 PM, olcott wrote:
On 5/5/2025 1:21 PM, dbush wrote:
On 5/5/2025 2:14 PM, olcott wrote:
On 5/5/2025 11:16 AM, dbush wrote:
On 5/5/2025 12:13 PM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
It is incorrectly defined when-so-ever it is not specified that aThat is not what I said.When BOTH Boolean RETURN VALUES are the wrong answer THEN THE >>>>>>>>> PROBLEM IS ILL-FORMED. Self-contradiction must be screened out as >>>>>>>>> semantically incorrect.The category (type) error manifests in all extant halting >>>>>>>>>>> problem proofs including Linz. It is impossible to prove >>>>>>>>>>> something which is ill- formed in the first place.When HHH computes the mapping from *its input* to the behavior >>>>>>>>>>>>> of DD emulated by HHH this includes HHH emulating itself >>>>>>>>>>>>> emulating DD. This matches the infinite recursion behavior >>>>>>>>>>>>> pattern.Which is a contradiction. Therefore the assumption that the >>>>>>>>>>>> above mapping is computable is proven false, as Linz and others >>>>>>>>>>>> have proved and as you have *explicitly* agreed is correct. >>>>>>>>>>>
Thus the Halting Problem's "impossible" input is correctly >>>>>>>>>>>>> determined to be non-halting.
All algorithms either halt or do not halt when executed directly. >>>>>>>>>> Therefore the problem is not ill formed.
In other words, you're claiming that there exists an algorithm, >>>>>>>> i.e. a fixed immutable sequence of instructions, that neither halts >>>>>>>> nor does not halt when executed directly.
Then there's no category error, and the halting function is well
defined. It's just that no algorithm can compute it.
It is insufficiently defined thus causing it to be incoherently
defined.
It is well defined. There are computations that halt and computations
that do not. Nothing else is in the scope of the halting problem.
specific sequence of steps must be applied to the input to derive the
output.
That DD() halts therefore I guess that DD correctly emulated by HHH must >>> halt too IS NOT A SPECIFIC SEQUENCE OF STEPS.
It is merely an incorrect guess.
Oh wow. As a simulator, HHH must produce the same behaviour as the direct
execution.
If you examine 100% of ALL of the details
you will find that is counter-factual.
On 5/7/2025 5:55 AM, Richard Damon wrote:
On 5/6/25 10:09 PM, olcott wrote:
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no >>>>>>>>>>> attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only >>>>>>>>>>>>> if) thei.e. it is found to map something other than the above function >>>>>>>>>>>> which is a contradiction.
mapping FROM INPUTS IS COMPUTED.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS
INCORRECT you
simply take that same quote from a computer science textbook >>>>>>>>>>> as the
infallible word-of-God.
Every function computed by a model of computation must apply aAll you are doing is showing that you don't understand proof by >>>>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>> No, YOU don't understand what Computer Science actually is talking >>>>>>>> about.
specific
sequence of steps that are specified by the model to the actual
finite
string input.
You are very confused. An algorithm or program computes a function. >>>>>>
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
Right, so HHH needs to apply the rules that it was designed with.
And that means it breaks the criteria that you say it needs to do to
get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
No, to be a correct emulator it needs to continue until it reaches the
end,
It can get the right answer if it emulates the input to the point that
it can show that a
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
Right, that UTM(D) would never halt.
*would never stop running unless aborted*
Is the hypothetical HHH/DD pair where HHH does not abort.
Nope, can't change DD, it is your hypothetical HHH, which has become
UTM, when given the ORIGINAL DD, which calls the ORIGINAL HHH, as that
code was part of the definition of DD.
HHH bases its decision on what the behavior of DD
would be if a hypothetical version of its own self
never aborted.
On 5/7/2025 5:58 AM, Richard Damon wrote:
On 5/6/25 10:00 PM, olcott wrote:
On 5/6/2025 5:49 PM, Richard Damon wrote:
On 5/6/25 2:05 PM, olcott wrote:
On 5/6/2025 5:59 AM, Richard Damon wrote:
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
Which starts with the assumption that an algorithm exists that >>>>>>>>>> performs the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that
computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed
directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
DO COMPUTE THAT THE INPUT IS NON-HALTING
IFF (if and only if) the mapping FROM INPUTS
IS COMPUTED.
i.e. it is found to map something other than the above
function which is a contradiction.
The above function VIOLATES COMPUTER SCIENCE.
You make no attempt to show how my claim
THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT
you simply take that same quote from a computer
science textbook as the infallible word-of-God.
All you are doing is showing that you don't understand proof by >>>>>>>> contradiction,
Not at all. The COMPUTER SCIENCE of your requirements IS WRONG!
No, YOU don't understand what Computer Science actually is talking >>>>>> about.
Every function computed by a model of computation
must apply a specific sequence of steps that are
specified by the model to the actual finite string
input.
Right, "Computed by a model of computation", that
HHH(DD) must emulate DD according to the rules
of the x86 language.
Right, which is doesn't do.
Remember, your HHH stop processing at a CALL HHH instruction.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
*input D* until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* // the actual input
Which calls the original H
*would never stop running unless aborted*
// A hypothetical HHH/DD pair where HHH and DD are
// exactly the same except that this HHH does not abort.
No, your hypothetical HHH (like your HHH1) paired with the originl DD
which uses the original HHH.
That is NOT what this means:
*simulated D would never stop running unless aborted*
All simulating halt deciders must
PREDICT WHAT THE BEHAVIOR WOULD BE
and thus cannot simply wait and see
what the behavior is.
If they don't analyze what
the behavior of the input WOULD BE if
they did not abort their simulation
they would get stuck and never halt.
Simulating halt decider must PREDICT BEHAVIOR.
On 5/7/2025 3:54 AM, Mikko wrote:
On 2025-05-06 18:05:15 +0000, olcott said:
That everyone here thinks that HHH can simply ignore
the rules of the x86 language and jump over the "call"
instruction to the "ret" instruction seems quite stupid
to me.
The halting problem does not prohibit such skip so in that sense
it is OK.
However, in order to correctly determine whether DD halts
it may need to know whether the called HHH returns and what it
returns if it does.
The call from DD emulated by HHH cannot possibly return.
The recursive emulation just keep getting deeper until
HHH correctly recognizes that DD would never stop running
in the hypothetical case that this HHH never aborted.
When discussing the situation we need not consider what happens
during the execution of HHH. We do know that HHH returns if it
really is a halt decider or any other decider.
The fully operational code has shown 100% of all of
the details of this for three years.
The call from DD correctly emulated by HHH to
HHH(DD) cannot possibly return. This makes the
self-contradictory part of DD unreachable.
We also know that
if it returns it either returns zero or someting else. The code
of DD shows that it halts if HHH(DD) returns zero and does not
halt fi HHH(DD) returns non-zero or does not return at all.
DD cannot possibly
*do the opposite of whatever value that HHH returns*
because this code is unreachable from DD correctly
emulated by HHH.
On 5/7/2025 1:27 PM, dbush wrote:
On 5/7/2025 2:24 PM, olcott wrote:
On 5/7/2025 5:58 AM, Richard Damon wrote:
On 5/6/25 10:00 PM, olcott wrote:
On 5/6/2025 5:49 PM, Richard Damon wrote:
On 5/6/25 2:05 PM, olcott wrote:
On 5/6/2025 5:59 AM, Richard Damon wrote:
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
Which starts with the assumption that an algorithm exists >>>>>>>>>>>> that performs the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>> instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>> executed directly
DO COMPUTE THAT THE INPUT IS NON-HALTING
IFF (if and only if) the mapping FROM INPUTS
IS COMPUTED.
i.e. it is found to map something other than the above >>>>>>>>>>>> function which is a contradiction.
The above function VIOLATES COMPUTER SCIENCE.
You make no attempt to show how my claim
THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT
you simply take that same quote from a computer
science textbook as the infallible word-of-God.
All you are doing is showing that you don't understand proof >>>>>>>>>> by contradiction,
Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>>>
No, YOU don't understand what Computer Science actually is
talking about.
Every function computed by a model of computation
must apply a specific sequence of steps that are
specified by the model to the actual finite string
input.
Right, "Computed by a model of computation", that
HHH(DD) must emulate DD according to the rules
of the x86 language.
Right, which is doesn't do.
Remember, your HHH stop processing at a CALL HHH instruction.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
*input D* until H correctly determines that its simulated D >>>>> *would never stop running unless aborted* then
*input D* // the actual input
Which calls the original H
*would never stop running unless aborted*
// A hypothetical HHH/DD pair where HHH and DD are
// exactly the same except that this HHH does not abort.
No, your hypothetical HHH (like your HHH1) paired with the originl
DD which uses the original HHH.
That is NOT what this means:
*simulated D would never stop running unless aborted*
All simulating halt deciders must
PREDICT WHAT THE BEHAVIOR WOULD BE
If the machine described by its input was executed directly, as per
the requirements of a halt decider:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
I have proved that everyone has been wrong about this
for ninety years. Ignoring my proof is not any rebuttal.
My proof is probably totally over-your-head.
On 5/7/2025 6:01 AM, Richard Damon wrote:
On 5/6/25 10:28 PM, olcott wrote:
On 5/6/2025 5:59 PM, Richard Damon wrote:
On 5/6/25 3:20 PM, olcott wrote:
On 5/6/2025 2:10 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 20:47 schreef olcott:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates
the contradiction.
Not at all. The contradiction arises from the fact that it is >>>>>>>>>> not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
That you do not understand it, does not mean that it has not been
provided to you. It has, many times. If you do not know that you
are wrong, you must be very stupid.
Everything besides a machine address by machine
address of DD emulated by HHH (according to the
rules of the x86 language) where the emulated
DD reaches its own "ret" instruction
In other words, if people don't agree with your fantasy that is just
in error, then "they" must be wrong.
No, it
*IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION*
No, YOU are a dishoneast dodge from the actual question
Most of my reviewers switch to rhetoric when they
know that they are wrong and still want to disagree.
Disagreement (not truth) is their highest priority.
Nope, that is just you projecting again.
You keep saying the DD emulated by HHH according
to the rules of the x86 language is wrong.
Right, because it stops wnen it should not.
You keep arguing that HHH is required to break these
rules to conform with the common misconception that HHH
is required to report on the direct execution of DD().
No, it needs to keep to them, which it doesn\'t.
Where did I say it must break the rules?
DD correctly simulated by HHH according to the rules
of the x86 language cannot possibly halt.
You and others say that DD emulated by HHH must halt
because the directly executed DD() halts.
This is only possible when DD emulated by HHH
breaks the rules of the x86 language.
For example when HHH reaches the "call" instruction
of DD it ignores this "call" instruction and jumps
directly to the "ret" instruction of DD.
I keep daring you to show the steps of DD emulated
by HHH where DD halts and you keep dodging because
you know that DD correctly emulated by HHH DOES NOT HALT.
What I don't understand is why you would risk your
immortal soul for the cheap thrill of playing childish
head games.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/7/2025 3:57 AM, Mikko wrote:
On 2025-05-06 15:36:00 +0000, olcott said:
On 5/6/2025 4:47 AM, Mikko wrote:
On 2025-05-05 19:54:55 +0000, olcott said:
On 5/5/2025 2:49 PM, dbush wrote:
On 5/5/2025 3:38 PM, olcott wrote:
On 5/5/2025 2:23 PM, Richard Heathfield wrote:
On 05/05/2025 20:20, olcott wrote:
Is "halts" the correct answer for H to return? NO
Is "does not halt" the correct answer for H to return? NO
Both Boolean return values are the wrong answer
Or to put it another way, the answer is undecidable, QED.
See? You got there in the end.
Is this sentence true or false: "What time is it?"
is also "undecidable" because it is not a proposition
having a truth value.
Is this sentence true or false: "This sentence is untrue."
is also "undecidable" because it is not a semantically sound
proposition having a truth value.
Can Carol correctly answer “no” to this (yes/no) question?
Both Yes and No are the wrong answer proving that
the question is incorrect when the context of who
is asked is understood to be a linguistically required
aspect of the full meaning of the question.
And "does algorthm X with input Y halt when executed directly" has >>>>>> a single well defined answer.
That is not even the actual question.
Does the finite string input DD to HHH specify
a computation that halts? No it does not.
That question is a category error. The halting question is not about
finite strings but about computations.
HHH must compute the mapping from its finite string
of x86 code input to the actual behavior that this
finite string input specifies.
No, that is not what the halting problem requires. The halting problem
requires that HHH must be given a finite string that tells what HHH
needs to know about DD in order to correctly predict whether DD halts
if it is directly executed.
And for the same reason
<sarcasm>
int sum(int x, int y) { return x + y; }
sum(3,2) must report on the sum of 5 + 6
and is not allowed to report on the sum of 3 + 2.
This is because Truth is a Democracy and the common
misconceptions cast more votes than correct analysis.
</sarcasm>
On 5/7/2025 3:24 PM, joes wrote:
Am Tue, 06 May 2025 13:40:16 -0500 schrieb olcott:
On 5/6/2025 10:53 AM, joes wrote:Then it is not the same HHH.
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:*would never stop running unless aborted*
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to
report on the direct execution of DD() and the input to HHH
specifies a different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence >>>>>> of steps as DD. HHH just answers about a different sequence of steps >>>>>> instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D >>>>> until H correctly determines that its simulated D *would never
stop running unless aborted* then
*input D* is the actual input *would never stop running unless
aborted* is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a
hypothetical version of D that calls a pure simulator.
refers to the same HHH that DD calls yet this hypothetical HHH does not
abort.
It is the exact same HHH/DD pair except that this
hypothetical HHH never aborts.
HHH does simulate itself correctly yet must create a separate processYou cannot possibly show the exact execution trace where DD is
correctly emulated by HHH and this emulated DD reaches past its own
machine address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can simulate >>>> DD/HHH.
context for each recursive emulation.
Each process context has its own stack and set of virtual registers.
No, HHH simulates only one program.
HHH correctly emulates DD and correctly emulates itself
emulating DD. This is two C functions and zero programs.
On 5/7/2025 10:44 AM, Mike Terry wrote:
On 07/05/2025 04:11, olcott wrote:
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact that it >>>>>>>>>>>> is not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that >>>>>>>> HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the
two traces side by side some time ago, and they were indeed
IDENTICAL line for line up to the point where HHH decided to
discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the same up
to the point where HHH discontinued the simulation. How can it be
"counter-factual"?
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
A call that returns and a call that cannot possibly
return *are not exactly the same thing*
You need to read what posters actually say. I said the traces were
the same up to the point where HHH stops simulating.
THAT IS COUNTER-FACTUAL.
HHH continues to emulate DD long after their paths diverge.
HHH1 only emulates DD once.
HHH emulates DD once and then emulates itself emulating DD.
I didn't say anything about calls that return or do not return "being
the same thing" and none of what you relates to whether what I said
was correct.
Look, if you insist the traces are not the same up to the point where
HHH stops simulating, show the two traces and we'll just look and see!
Simples.
HHH1(DD) emulates DD once.
HHH(DD) emulates DD once and then emulates itself emulating DD.
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD [000021c6][0010386a][000021cb] e853f3ffff call 0000151e // call HHH1 New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000213e][0011390e][00113912] 55 push ebp [0000213f][0011390e][00113912] 8bec mov ebp,esp [00002141][0011390a][00103916] 51 push ecx [00002142][00113906][0000213e] 683e210000 push 0000213e // push DD [00002147][00113902][0000214c] e8a2f4ffff call 000015ee // call HHH New slave_stack at:14e33e
Begin Local Halt Decider Simulation Execution Trace Stored at:15e346 [0000213e][0015e336][0015e33a] 55 push ebp [0000213f][0015e336][0015e33a] 8bec mov ebp,esp [00002141][0015e332][0014e33e] 51 push ecx [00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD [00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call HHH New slave_stack at:198d66
[0000213e][001a8d5e][001a8d62] 55 push ebp [0000213f][001a8d5e][001a8d62] 8bec mov ebp,esp [00002141][001a8d5a][00198d66] 51 push ecx [00002142][001a8d56][0000213e] 683e210000 push 0000213e [00002147][001a8d52][0000214c] e8a2f4ffff call 000015ee
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[0000214c][0011390a][00103916] 83c404 add esp,+04 [0000214f][0011390a][00000000] 8945fc mov [ebp-04],eax [00002152][0011390a][00000000] 837dfc00 cmp dword [ebp-04],+00 [00002156][0011390a][00000000] 7402 jz 0000215a [0000215a][0011390a][00000000] 8b45fc mov eax,[ebp-04] [0000215d][0011390e][00113912] 8be5 mov esp,ebp [0000215f][00113912][000015d3] 5d pop ebp [00002160][00113916][0003a980] c3 ret [000021cb][00103872][00000000] 83c404 add esp,+04 [000021ce][0010386e][00000001] 50 push eax [000021cf][0010386a][0000075f] 685f070000 push 0000075f [000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 1
[000021d9][00103872][00000000] 83c408 add esp,+08 [000021dc][00103872][00000000] 33c0 xor eax,eax [000021de][00103876][00000018] 5d pop ebp [000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(400885) == 5983 Pages
At this point, no need to be too formal, just a high level trace, e.g.
referencing C code rather than instruction addresses...
The directed graph of the x86 code leaves zero
room for incorrect interpretation.
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* refers to the actual HHH/DD pair
..which is not to be changed during hypothetical modifications to H
*would never stop running unless aborted*
refers to the hypothetical HHH/DD pair where
HHH and DDD are exactly the same except that
this hypothetical HHH does not abort the
simulation of its input.
No, that doesn't work in your x86utm because you mix up code (HHH)
and data (DD, which directly calls HHH). DD must be "exactly the
same" / including all its subroutines/,
Not at all. Professor Sipser agreed that the actual
HHH/DD must base its decision on the hypothetical
HHH/DD that never aborts its simulation.
Nonsense. He is taking it as read that the input is not changed.
What he agreed was that the actual HHH can base its decision on the
hypothetical HHH that never aborts its simulation, running against
*identical input* DD. Identical means has identical behaviour to
original DD, in particular it calls original HHH,
No it does not.
*simulated D would never stop running unless aborted*
refers to a hypothetical HHH that does not abort.
not some modified HHH or UTM.
Of course, Sipser would not understand how you have mangled the design
of your utmx86 environment. He would naturally take it that you were
correctly implementing basic features of the TM halting problem, like
the input data being totally distinct from the TM state table. So it
would simply never occur to him that in your world, changing the code
of HHH would have any effect on the data input DD, which explains why
he does not explicitly mention that.
yawn
*would never stop running unless aborted*
*would never stop running unless aborted*
*would never stop running unless aborted*
but DD calls HHH so HHH must be exactly the same, otherwise the
input has been changed which is NOT ALLOWED.
Intuitively it would seem that way until you examine
every single detail 100% completely.
To make this work you have to create a /new/ "HHH that does not
abort the simulation".
Professor Sipser already agreed that the actual HHH/DD
must base its decision on the hypothetical HHH/DD
that never aborts.
You are quite incapable of understanding what Sipser was agreeing to.
*simulated D would never stop running unless aborted*
doesn't really leave much subjective leeway of interpretation.
This can only mean the behavior of DD when a hypothetical
HHH that never aborts would replace the body of the actual HHH.
More generally you have a problem understanding what other people
believe and what they are communicating to you. I've suggested you
have some neural wiring issue, and for sure this would be tied in to
that somehow.
No it is all a matter of people not bothering to pay
enough attention because of their mental bias that
I must be wrong.
Regardless of that, you are trying to use Sipser's quote as an appeal
to authority, which you understand is a fallacy but think its ok to do
it anyway. [Even though you are quick to accuse other people of doing
that when it suits you.]
An appeal to a qualified authority is inductively sound.
Just stop mentioning Sipser's quote altogether! It is not helping
your case in any shape or form.
E.g. clone HHH to HHH_hypothetical then take out the abort logic
from HHH_hypothetical. From main() call HHH_hypothetical(DD). That >>>> way DD is unchanged as required.
The trace by UTM continued further, with DD returning some time
later.
The above HHH1(DD) is this UTM.
HHH1 will serve in this case, since it happens to not abort due to
your coding errors.
It does not happen to not abort due to coding
errors. That is a reckless disregard for the truth.
The code has specified exactly why it need not
abort for several years now.
No, it's due to coding errors. You intended HHH1 to be a clone of
HHH, with the same algorithm as HHH, but at a different address.
You just screwed it up due to your inappropriate use of global
variables. If you had coded things correctly HHH(DD) and HHH1(DD)
would both have (incorrectly) decided halts. I explained the gory
details of all this to you months/years ago.
Merely proving that you still fail to understand
that the fact that DD calls HHH(DD) and does not call
HHH1(DD) MAKES ALL THE DIFFERENCE IN THEIR BEHAVIOR.
It would be cleaner to make a function UTM() which just has the
DebugStep loop and no abort logic.
Professor Sipser already agreed that the actual HHH/DD
must base its decision on the hypothetical HHH/DD
that never aborts, AKA your UTM.
Sipser would be ok with my UTM, simulating THE ORIGINAL DD, which
calls THE ORIGINAL HHH.
The words that he agreed to
*simulated D would never stop running unless aborted*
Since this HHH DOES ABORT the HHH THAT DOES NOT ABORT
must be a different hypothetical HHH.
Simulating halt deciders must PREDICT WHAT THE BEHAVIOR
WOULD BE IF THEY DID NOT ABORT.
They cannot simply wait-and-see or they get stuck.
On 5/7/2025 5:06 PM, Mike Terry wrote:
On 07/05/2025 22:32, olcott wrote:
On 5/7/2025 4:20 PM, Mike Terry wrote:
On 07/05/2025 17:25, olcott wrote:
On 5/7/2025 10:44 AM, Mike Terry wrote:
On 07/05/2025 04:11, olcott wrote:
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote: >>>>>>>>>>>>>>>> On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact that it is not possible to
construct a universal decider.
Everyone here insists that functions computed >>>>>>>>>>>>>>>>> by models of computation can ignore inputs and >>>>>>>>>>>>>>>>> base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH >>>>>>>>>>>>>>> according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM. >>>>>>>>>>>>>>
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>>>>>>>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the two traces side by side
some time ago, and they were indeed IDENTICAL line for line up to the point where HHH
decided to discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the same up to the point where HHH
discontinued the simulation. How can it be "counter-factual"? >>>>>>>>
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
A call that returns and a call that cannot possibly
return *are not exactly the same thing*
You need to read what posters actually say. I said the traces were the same up to the point
where HHH stops simulating.
THAT IS COUNTER-FACTUAL.
HHH continues to emulate DD long after their paths diverge.
HHH1 only emulates DD once.
HHH emulates DD once and then emulates itself emulating DD.
I didn't say anything about calls that return or do not return "being the same thing" and
none of what you relates to whether what I said was correct.
Look, if you insist the traces are not the same up to the point where HHH stops simulating,
show the two traces and we'll just look and see! Simples.
HHH1(DD) emulates DD once.
HHH(DD) emulates DD once and then emulates itself emulating DD.
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD >>>>> [000021c6][0010386a][000021cb] e853f3ffff call 0000151e // call HHH1 >>>>> New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e >>>>> [0000213e][0011390e][00113912] 55 push ebp
[0000213f][0011390e][00113912] 8bec mov ebp,esp
[00002141][0011390a][00103916] 51 push ecx
[00002142][00113906][0000213e] 683e210000 push 0000213e // push DD >>>>> [00002147][00113902][0000214c] e8a2f4ffff call 000015ee // call HHH >>>>> New slave_stack at:14e33e
Begin Local Halt Decider Simulation Execution Trace Stored at:15e346 >>>>> [0000213e][0015e336][0015e33a] 55 push ebp
[0000213f][0015e336][0015e33a] 8bec mov ebp,esp
[00002141][0015e332][0014e33e] 51 push ecx
[00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD >>>>> [00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call HHH >>>>> New slave_stack at:198d66
[0000213e][001a8d5e][001a8d62] 55 push ebp
[0000213f][001a8d5e][001a8d62] 8bec mov ebp,esp
[00002141][001a8d5a][00198d66] 51 push ecx
[00002142][001a8d56][0000213e] 683e210000 push 0000213e
[00002147][001a8d52][0000214c] e8a2f4ffff call 000015ee
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[0000214c][0011390a][00103916] 83c404 add esp,+04
[0000214f][0011390a][00000000] 8945fc mov [ebp-04],eax
[00002152][0011390a][00000000] 837dfc00 cmp dword [ebp-04],+00 >>>>> [00002156][0011390a][00000000] 7402 jz 0000215a
[0000215a][0011390a][00000000] 8b45fc mov eax,[ebp-04]
[0000215d][0011390e][00113912] 8be5 mov esp,ebp
[0000215f][00113912][000015d3] 5d pop ebp
[00002160][00113916][0003a980] c3 ret
[000021cb][00103872][00000000] 83c404 add esp,+04
[000021ce][0010386e][00000001] 50 push eax
[000021cf][0010386a][0000075f] 685f070000 push 0000075f
[000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 1
[000021d9][00103872][00000000] 83c408 add esp,+08
[000021dc][00103872][00000000] 33c0 xor eax,eax
[000021de][00103876][00000018] 5d pop ebp
[000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(400885) == 5983 Pages
Excellent - above we have the trace for HHH1, half of what we need. While we /could/ use that to
/deduce/ what the trace for HHH should be, we shouldn't have to resort to that. The clean way
to proceed is for you to now post the similar trace for main calling HHH, then we can compare
them with minimal editing...
Mike.
The two calls to HHH(DD) are in the part you ignored.
HHH1(DD) emulates DD that calls the emulated HHH(DD)
to emulate DD that calls HHH(DD) that emulates itself
emulating DD.
I marked these calls with comments.
As I explained, it would be clearer if you just supply the requested trace. >>
Are you unable/unwilling to do that?
*This is the HHH(DD) trace*
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000213e][0011390e][00113912] 55 push ebp [0000213f][0011390e][00113912] 8bec mov ebp,esp [00002141][0011390a][00103916] 51 push ecx [00002142][00113906][0000213e] 683e210000 push 0000213e // push DD [00002147][00113902][0000214c] e8a2f4ffff call 000015ee // calls HHH
New slave_stack at:14e33e
[0000213e][0015e336][0015e33a] 55 push ebp [0000213f][0015e336][0015e33a] 8bec mov ebp,esp [00002141][0015e332][0014e33e] 51 push ecx [00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD [00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000021cb][00103872][00000000] 83c404 add esp,+04 [000021ce][0010386e][00000000] 50 push eax [000021cf][0010386a][0000075f] 685f070000 push 0000075f [000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 0
[000021d9][00103872][00000000] 83c408 add esp,+08 [000021dc][00103872][00000000] 33c0 xor eax,eax [000021de][00103876][00000018] 5d pop ebp [000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(11427) == 171 Pages
*Here is the HHH1(DD) trace again*
This inlcudes the HHH(DD) trace because DD calls HHH(DD)
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000213e][0011390e][00113912] 55 push ebp [0000213f][0011390e][00113912] 8bec mov ebp,esp [00002141][0011390a][00103916] 51 push ecx [00002142][00113906][0000213e] 683e210000 push 0000213e // push DD [00002147][00113902][0000214c] e8a2f4ffff call 000015ee // calls HHH
New slave_stack at:14e33e
[0000213e][0015e336][0015e33a] 55 push ebp [0000213f][0015e336][0015e33a] 8bec mov ebp,esp [00002141][0015e332][0014e33e] 51 push ecx [00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD [00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000021cb][00103872][00000000] 83c404 add esp,+04 [000021ce][0010386e][00000000] 50 push eax [000021cf][0010386a][0000075f] 685f070000 push 0000075f [000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 0
[000021d9][00103872][00000000] 83c408 add esp,+08 [000021dc][00103872][00000000] 33c0 xor eax,eax [000021de][00103876][00000018] 5d pop ebp [000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(11427) == 171 Pages
On 5/7/2025 1:18 AM, Richard Heathfield wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
<snip>
HHH and UTM emulate DD exactly the same up until the point that
HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the two
traces side by side some time ago, and they were indeed IDENTICAL
line for line up to the point where HHH decided to discontinue
simulating.
That is counter-factual.
People who can be bothered to check for themselves can check for
themselves.
People who (like me) can't be arsed to go through the palaver of
getting your code to work must instead decide who they think is more
credible - you or Mike.
No contest.
If you want people to believe you, you've got your work cut out.
Shooting emotionally from the hip (as you do) isn't as convincing as
explaining precisely, logically, and dispassionately why you're right
(as Mike does).
If I were to run a book right now on an independent investigation of
the point in the trace where the two traces diverge, I could offer
astronomical odds on your claim without any fear of losing a penny,
but no matter what odds I offered on Mike I would quickly have to
close the book on his claim or face bankruptcy.
It isn't just your logic that needs a lot off work; it's your
presentation, too. You come across as someone who /believes/ you're
right, but it's not enough to call down lightning on Mike the heretic;
Mike manages to keep calm because he /knows/ he's right. There's a
huge and important difference between the two.
There's also an important difference between claiming that Mike's
claim is counter-factual and /proving/ that his claim is counter-factual.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Any sufficiently competent C programmer can see that
when DD is correctly simulated by HHH that this
simulated DD cannot get past its call to HHH(DD).
The reason that I get angry is that everyone here
has denied that verified fact for three years.
Can it really be true that most people here don't
hardly have any clue about actual programming?
Mike says he's posted evidence in support of his claim. I haven't seen
it, but of the two of you I will unhesitatingly take his word for it
rather than yours. Have you posted a rebuttal? If not, why not?
The rebuttal is that
Even the simple code shown above proves that DD
correctly simulated by HHH cannot possibly reach its
own halt state.
I never take anyone's word, not even my doctor's word.
On 5/7/2025 4:48 AM, Mikko wrote:
On 2025-05-06 18:40:16 +0000, olcott said:
On 5/6/2025 10:53 AM, joes wrote:
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to
report
on the direct execution of DD() and the input to HHH specifies a >>>>>>> different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence >>>>>> of steps as DD. HHH just answers about a different sequence of steps >>>>>> instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D until
H correctly determines that its simulated D *would never stop
running unless aborted* then
*input D* is the actual input *would never stop running unless
aborted*
is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a
hypothetical version of D that calls a pure simulator.
*would never stop running unless aborted*
refers to the same HHH that DD calls yet
this hypothetical HHH does not abort.
You cannot possibly show the exact execution trace where DD is
correctly
emulated by HHH and this emulated DD reaches past its own machine
address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can simulate >>>> DD/HHH.
HHH does simulate itself correctly yet must create
No, it cannot simulate itself to the point where it returns.
HHH(DD) does return.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its *simulated D*
*would never stop running unless aborted* then
HHH only need simulate DD until it correctly determines
*simulated D would never stop running unless aborted*
This refers to a hypothetical HHH/DD pair where HHH never aborts.
On 5/7/2025 3:53 PM, dbush wrote:
On 5/7/2025 4:41 PM, olcott wrote:
On 5/7/2025 3:24 PM, joes wrote:
Am Tue, 06 May 2025 13:40:16 -0500 schrieb olcott:
On 5/6/2025 10:53 AM, joes wrote:Then it is not the same HHH.
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:*would never stop running unless aborted*
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to >>>>>>>>> report on the direct execution of DD() and the input to HHH
specifies a different sequence of steps.
No, it does not. The input is DD specifides exactly the same
sequence
of steps as DD. HHH just answers about a different sequence of >>>>>>>> steps
instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D *would >>>>>>> never
stop running unless aborted* then
*input D* is the actual input *would never stop running unless
aborted* is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a >>>>>> hypothetical version of D that calls a pure simulator.
refers to the same HHH that DD calls yet this hypothetical HHH does
not
abort.
It is the exact same HHH/DD pair except that this
hypothetical HHH never aborts.
HHH does simulate itself correctly yet must create a separate process >>>>> context for each recursive emulation.You cannot possibly show the exact execution trace where DD is
correctly emulated by HHH and this emulated DD reaches past its own >>>>>>> machine address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can
simulate
DD/HHH.
Each process context has its own stack and set of virtual registers.
No, HHH simulates only one program.
HHH correctly emulates DD
A lie, as you have admitted otherwise on the record:
AS I HAVE SAID HUNDREDS OF TIMES AND YOU DISHONESTLY IGNORE
Correct emulation is defined as DD is emulated by
HHH according to the rules of the x86 language.
On 5/7/2025 3:24 PM, joes wrote:
Am Tue, 06 May 2025 13:40:16 -0500 schrieb olcott:
On 5/6/2025 10:53 AM, joes wrote:Then it is not the same HHH.
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:*would never stop running unless aborted*
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to
report on the direct execution of DD() and the input to HHH
specifies a different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence >>>>>> of steps as DD. HHH just answers about a different sequence of steps >>>>>> instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D >>>>> until H correctly determines that its simulated D *would never
stop running unless aborted* then
*input D* is the actual input *would never stop running unless
aborted* is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a
hypothetical version of D that calls a pure simulator.
refers to the same HHH that DD calls yet this hypothetical HHH does not
abort.
It is the exact same HHH/DD pair except that this
hypothetical HHH never aborts.
HHH does simulate itself correctly yet must create a separate processYou cannot possibly show the exact execution trace where DD is
correctly emulated by HHH and this emulated DD reaches past its own
machine address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can simulate >>>> DD/HHH.
context for each recursive emulation.
Each process context has its own stack and set of virtual registers.
No, HHH simulates only one program.
HHH correctly emulates DD and correctly emulates itself
emulating DD. This is two C functions and zero programs.
On 5/7/2025 4:42 AM, Mikko wrote:
On 2025-05-06 15:29:59 +0000, olcott said:
On 5/6/2025 4:35 AM, Mikko wrote:
On 2025-05-05 17:37:20 +0000, olcott said:
On 5/5/2025 11:13 AM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>>>> halting problem proofs.
Which start with the assumption that the following mapping is
computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes >>>>>>> the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior >>>>>>>> of DD
emulated by HHH this includes HHH emulating itself emulating DD. >>>>>>>> This
matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly
determined
to be non-halting.
Which is a contradiction. Therefore the assumption that the above >>>>>>> mapping is computable is proven false, as Linz and others have
proved
and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem
proofs
including Linz. It is impossible to prove something which is ill- >>>>>> formed
in the first place.
/Flibble
The above example is category error because it asks
HHH(DD) to report on the direct execution of DD() and
the input to HHH specifies a different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence
of steps as DD. HHH just answers about a different sequence of steps
instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* is the actual input
*would never stop running unless aborted*
is the hypothetical H/D pair where H does not abort.
H is hypthetical. There is no actual decider in Sipeser's words. But
what is said about D is true about any actual input as there is no
restriction on D other than it is an input to H.
You cannot possibly show the exact execution trace
That's right. An execution trace is too long to make without tools
that I don't have. Just remenber that absence of evidence is not
evidence of absense.
The execution trace of DD correctly emulated by HHH
keeps repeating the first five instructions until
HHH correctly determines:
*simulated D would never stop running unless aborted*
In other words HHH predicts what the behavior of DD
*would be* if HHH was a UTM.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
On 5/7/2025 6:12 AM, Richard Damon wrote:
On 5/6/25 10:40 PM, olcott wrote:
On 5/6/2025 6:00 PM, Richard Damon wrote:
On 5/6/25 1:54 PM, olcott wrote:
On 5/6/2025 6:06 AM, Richard Damon wrote:
On 5/5/25 10:29 PM, olcott wrote:
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider >>>>>>>>>> of the
simulating kind.
Such input forms a category error which results in the halting >>>>>>>>>> problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that it >>>>>>>> refutes, and thus your talk about correctly emulated by HHH is >>>>>>>> just a lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the
representation of a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
Can't be, as the input needs to be about a program, which must, by >>>>>> the definition of a program, include all its algorithm.
Yes, there are steps that also occur in the termination analyzer,
but they have been effectively copied into the program the input
describes.
Note, nothing says that the representation of the program has to
be an assembly level description of it. It has to be a complete
description, that 100% defines the results the code will generate
(and if it will generate) but it doesn't need to be the exact
assembly code,
YOU even understand that, as you present the code as "C" code,
which isn't assembly.
What you forget is that the input program INCLUDES as its
definiton, all of the code it uses, and thus the call to the
decider it is built on includes that code into the decider, and
that is a FIXED and DETERMINDED version of the decider, the one
that THIS version of the input is designed to make wrong.
This doesn't change when you hypothosize a different decider
looking at THIS input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
Refers to a hypothetical HHH/DD pair of the same HHH that
DD calls except that this hypothetical HHH never aborts.
Right, but a correct simulation of D does halt,
How the Hell is breaking the rules specified
by the x86 language possibly correct?
Right, how is HHH correct to abort its emulation?
I could say that the sum of 5 + 7 is a dirty sock
according to the rules of random gibberish.
Yes, and you do, because most of what you say IS "random gibberish"
When I go by the rules of arithmetic I am proved
wrong.
But the problem is you don't do that, but think you are because you
don't know the rules.
DD <is> emulated by HHH according to the rules
of the x86 language that specify the HHH also
emulates itself emulating DD
No it isn't.
until HHH determines that for the hypothetical
HHH/DD pair where the hypothetical HHH never
aborts DD would never stop running.
Which isn't part of the rules.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
refers to the hypothetical HHH/DD pair where
HHH never aborts its simulation.
That second paragraph is a lie and a misquote.
I still have the original email.
Ben has already verified this.
This is an actual cut-and-paste of the words
*From Thursday, October 13, 2022 12:16 PM email*
If simulating halt decider H correctly simulates its input D until H correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.
In that email he requested that I surround that paragraph with
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
I also posted Date: Thu, 13 Oct 2022 11:46:22 -0500
[Michael Sipser of MIT validates the notion of a simulating halt decider]
that contains the exact same word-for-word paragraph https://al.howardknight.net/? STYPE=msgid&MSGI=%3Cti9fd0%241unl%241%40gioia.aioe.org%3E
Sorry, you are just makeing it obvious to all how stupid you are, and
that you consider lying a correct form of logic.
Professor Sipser said H could abort it simulation of D when it can
prove that the correct simulation of D (by whoever) would not halt.
Not quite.
When a hypothetical HHH/DD pair such that HHH never aborts
*simulated D would never stop running unless aborted*
That is the original (as it is the only) D.
If you only glance at the words before artificially
contriving a fake rebuttal it may seem that way.
Your problem is you think constants can be changed, and that things
that are the same can be different, and that things that are defined
different can be treated the same.
The correct way for simulating halt deciders to work
is to examine what would happen if it did not abort.
This requires the hypothetical HHH/DD pair (HHH never aborts)
that professor Sipser agreed to.
This is because your logic is built on fantasy and lies.
On 5/7/2025 9:46 PM, Richard Damon wrote:
On 5/7/25 12:25 PM, olcott wrote:
On 5/7/2025 10:44 AM, Mike Terry wrote:
On 07/05/2025 04:11, olcott wrote:
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact that it >>>>>>>>>>>>>> is not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH >>>>>>>>>>>>> according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>> [00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point >>>>>>>>>> that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of the >>>>>>>> two traces side by side some time ago, and they were indeed
IDENTICAL line for line up to the point where HHH decided to
discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the same up >>>>>> to the point where HHH discontinued the simulation. How can it be >>>>>> "counter-factual"?
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
A call that returns and a call that cannot possibly
return *are not exactly the same thing*
You need to read what posters actually say. I said the traces were
the same up to the point where HHH stops simulating.
THAT IS COUNTER-FACTUAL.
HHH continues to emulate DD long after their paths diverge.
HHH1 only emulates DD once.
HHH emulates DD once and then emulates itself emulating DD.
I didn't say anything about calls that return or do not return
"being the same thing" and none of what you relates to whether what
I said was correct.
Look, if you insist the traces are not the same up to the point
where HHH stops simulating, show the two traces and we'll just look
and see! Simples.
HHH1(DD) emulates DD once.
HHH(DD) emulates DD once and then emulates itself emulating DD.
machine stack stack machine assembly >>> address address data code language
======== ======== ======== ============== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD >>> [000021c6][0010386a][000021cb] e853f3ffff call 0000151e // call HHH1
New slave_stack at:103916
**ERROR**
Not a correct Emulaton of the call instruction,
You are just PROVING that you are nothing but a totally ignorant
pathological lying idiot that doesn't understand what they are talking
about.
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e >>> [0000213e][0011390e][00113912] 55 push ebp
[0000213f][0011390e][00113912] 8bec mov ebp,esp
[00002141][0011390a][00103916] 51 push ecx
[00002142][00113906][0000213e] 683e210000 push 0000213e // push DD >>> [00002147][00113902][0000214c] e8a2f4ffff call 000015ee // call HHH >>> New slave_stack at:14e33e
Begin Local Halt Decider Simulation Execution Trace Stored at:15e346 >>> [0000213e][0015e336][0015e33a] 55 push ebp
[0000213f][0015e336][0015e33a] 8bec mov ebp,esp
[00002141][0015e332][0014e33e] 51 push ecx
[00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD >>> [00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call HHH >>> New slave_stack at:198d66
[0000213e][001a8d5e][001a8d62] 55 push ebp
[0000213f][001a8d5e][001a8d62] 8bec mov ebp,esp
[00002141][001a8d5a][00198d66] 51 push ecx
[00002142][001a8d56][0000213e] 683e210000 push 0000213e
[00002147][001a8d52][0000214c] e8a2f4ffff call 000015ee
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[0000214c][0011390a][00103916] 83c404 add esp,+04
[0000214f][0011390a][00000000] 8945fc mov [ebp-04],eax
[00002152][0011390a][00000000] 837dfc00 cmp dword [ebp-04],+00 >>> [00002156][0011390a][00000000] 7402 jz 0000215a
[0000215a][0011390a][00000000] 8b45fc mov eax,[ebp-04]
[0000215d][0011390e][00113912] 8be5 mov esp,ebp
[0000215f][00113912][000015d3] 5d pop ebp
[00002160][00113916][0003a980] c3 ret
[000021cb][00103872][00000000] 83c404 add esp,+04
[000021ce][0010386e][00000001] 50 push eax
[000021cf][0010386a][0000075f] 685f070000 push 0000075f
[000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 1
[000021d9][00103872][00000000] 83c408 add esp,+08
[000021dc][00103872][00000000] 33c0 xor eax,eax
[000021de][00103876][00000018] 5d pop ebp
[000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(400885) == 5983 Pages
At this point, no need to be too formal, just a high level trace,
e.g. referencing C code rather than instruction addresses...
The directed graph of the x86 code leaves zero
room for incorrect interpretation.
Then why don't you follow it.
From 6.4.2 of the Intel manual on the x86 instruction set, under the
behavior of the call instruction, the last step is:
Begins execution of the called procedure.
Which your emulation didn't do, Your emulator need to show the
emulation of the function called.
That is 5983 Pages nitwit! No one here can freaking
handle 1/2 of one page even when they had three freaking
years to get it.
I HAVE TOLD YOU THIS HUNDREDS OF TIMES.
Is your ADD really that bad where you
can't remember something that you have
been told many hundreds of times?
We see that the behavior of DD <is> the behavior
specified by the input to HHH(DD) without needing
nearly 6000 pages.
On 5/7/2025 9:09 PM, Richard Damon wrote:
On 5/7/25 11:31 AM, olcott wrote:
On 5/7/2025 5:55 AM, Richard Damon wrote:
On 5/6/25 10:09 PM, olcott wrote:
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no >>>>>>>>>>>>> attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only >>>>>>>>>>>>>>> if) thei.e. it is found to map something other than the above >>>>>>>>>>>>>> function
mapping FROM INPUTS IS COMPUTED.
which is a contradiction.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS >>>>>>>>>>>>> INCORRECT you
simply take that same quote from a computer science
textbook as the
infallible word-of-God.
Every function computed by a model of computation must apply a >>>>>>>>> specificabout.All you are doing is showing that you don't understand proof by >>>>>>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>>>> No, YOU don't understand what Computer Science actually is >>>>>>>>>> talking
sequence of steps that are specified by the model to the actual >>>>>>>>> finite
string input.
You are very confused. An algorithm or program computes a function. >>>>>>>>
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function.
Right, so HHH needs to apply the rules that it was designed with.
And that means it breaks the criteria that you say it needs to do
to get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
No, to be a correct emulator it needs to continue until it reaches
the end,
It can get the right answer if it emulates the input to the point
that it can show that a
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
Right, that UTM(D) would never halt.
*would never stop running unless aborted*
Is the hypothetical HHH/DD pair where HHH does not abort.
Nope, can't change DD, it is your hypothetical HHH, which has become
UTM, when given the ORIGINAL DD, which calls the ORIGINAL HHH, as
that code was part of the definition of DD.
HHH bases its decision on what the behavior of DD
would be if a hypothetical version of its own self
never aborted.
In other words, it bases it decision on a LIE.
It bases its decision on exactly what Professor Sipser agreed to.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D
*specifies a non-halting sequence of configurations*.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*simulated D would never stop running unless aborted* then
*H can abort its simulation of D*
*D specifies a non-halting sequence of configurations*
One hypothetical HHH that never aborts and
another different HHH that does abort.
On 5/7/2025 10:00 PM, Mike Terry wrote:
On 08/05/2025 00:01, olcott wrote:
On 5/7/2025 5:06 PM, Mike Terry wrote:
On 07/05/2025 22:32, olcott wrote:
On 5/7/2025 4:20 PM, Mike Terry wrote:
On 07/05/2025 17:25, olcott wrote:
On 5/7/2025 10:44 AM, Mike Terry wrote:
On 07/05/2025 04:11, olcott wrote:
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote: >>>>>>>>>>>>>>>>>> On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact >>>>>>>>>>>>>>>>>> that it is not possible to construct a universal decider. >>>>>>>>>>>>>>>>>>
Everyone here insists that functions computed >>>>>>>>>>>>>>>>>>> by models of computation can ignore inputs and >>>>>>>>>>>>>>>>>>> base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH >>>>>>>>>>>>>>>>> according to the semantics of the x86 language? >>>>>>>>>>>>>>>>> *Only an execution trace will do*
The exact same steps for DD to be emulated by UTM. >>>>>>>>>>>>>>>>
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>>>> [00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD) >>>>>>>>>>>>>>> [00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the point >>>>>>>>>>>>>> that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison of >>>>>>>>>>>> the two traces side by side some time ago, and they were >>>>>>>>>>>> indeed IDENTICAL line for line up to the point where HHH >>>>>>>>>>>> decided to discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the >>>>>>>>>> same up to the point where HHH discontinued the simulation. >>>>>>>>>> How can it be "counter-factual"?
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.
A call that returns and a call that cannot possibly
return *are not exactly the same thing*
You need to read what posters actually say. I said the traces >>>>>>>> were the same up to the point where HHH stops simulating.
THAT IS COUNTER-FACTUAL.
HHH continues to emulate DD long after their paths diverge.
HHH1 only emulates DD once.
HHH emulates DD once and then emulates itself emulating DD.
I didn't say anything about calls that return or do not return >>>>>>>> "being the same thing" and none of what you relates to whether >>>>>>>> what I said was correct.
Look, if you insist the traces are not the same up to the point >>>>>>>> where HHH stops simulating, show the two traces and we'll just >>>>>>>> look and see! Simples.
HHH1(DD) emulates DD once.
HHH(DD) emulates DD once and then emulates itself emulating DD.
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== ============= >>>>>>> [000021be][00103872][00000000] 55 push ebp >>>>>>> [000021bf][00103872][00000000] 8bec mov ebp,esp >>>>>>> [000021c1][0010386e][0000213e] 683e210000 push 0000213e // >>>>>>> push DD
[000021c6][0010386a][000021cb] e853f3ffff call 0000151e // >>>>>>> call HHH1
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored
at:11391e
[0000213e][0011390e][00113912] 55 push ebp >>>>>>> [0000213f][0011390e][00113912] 8bec mov ebp,esp >>>>>>> [00002141][0011390a][00103916] 51 push ecx >>>>>>> [00002142][00113906][0000213e] 683e210000 push 0000213e // >>>>>>> push DD
[00002147][00113902][0000214c] e8a2f4ffff call 000015ee // >>>>>>> call HHH
New slave_stack at:14e33e
Begin Local Halt Decider Simulation Execution Trace Stored
at:15e346
[0000213e][0015e336][0015e33a] 55 push ebp >>>>>>> [0000213f][0015e336][0015e33a] 8bec mov ebp,esp >>>>>>> [00002141][0015e332][0014e33e] 51 push ecx >>>>>>> [00002142][0015e32e][0000213e] 683e210000 push 0000213e // >>>>>>> push DD
[00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // >>>>>>> call HHH
New slave_stack at:198d66
[0000213e][001a8d5e][001a8d62] 55 push ebp >>>>>>> [0000213f][001a8d5e][001a8d62] 8bec mov ebp,esp >>>>>>> [00002141][001a8d5a][00198d66] 51 push ecx >>>>>>> [00002142][001a8d56][0000213e] 683e210000 push 0000213e
[00002147][001a8d52][0000214c] e8a2f4ffff call 000015ee
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>
[0000214c][0011390a][00103916] 83c404 add esp,+04 >>>>>>> [0000214f][0011390a][00000000] 8945fc mov [ebp-04],eax >>>>>>> [00002152][0011390a][00000000] 837dfc00 cmp dword [ebp-04],+00
[00002156][0011390a][00000000] 7402 jz 0000215a >>>>>>> [0000215a][0011390a][00000000] 8b45fc mov eax,[ebp-04] >>>>>>> [0000215d][0011390e][00113912] 8be5 mov esp,ebp >>>>>>> [0000215f][00113912][000015d3] 5d pop ebp >>>>>>> [00002160][00113916][0003a980] c3 ret
[000021cb][00103872][00000000] 83c404 add esp,+04 >>>>>>> [000021ce][0010386e][00000001] 50 push eax >>>>>>> [000021cf][0010386a][0000075f] 685f070000 push 0000075f
[000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 1
[000021d9][00103872][00000000] 83c408 add esp,+08 >>>>>>> [000021dc][00103872][00000000] 33c0 xor eax,eax >>>>>>> [000021de][00103876][00000018] 5d pop ebp >>>>>>> [000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(400885) == 5983 Pages
Excellent - above we have the trace for HHH1, half of what we
need. While we /could/ use that to /deduce/ what the trace for HHH >>>>>> should be, we shouldn't have to resort to that. The clean way to >>>>>> proceed is for you to now post the similar trace for main calling
HHH, then we can compare them with minimal editing...
Mike.
The two calls to HHH(DD) are in the part you ignored.
HHH1(DD) emulates DD that calls the emulated HHH(DD)
to emulate DD that calls HHH(DD) that emulates itself
emulating DD.
I marked these calls with comments.
As I explained, it would be clearer if you just supply the requested
trace.
Are you unable/unwilling to do that?
*This is the HHH(DD) trace*
machine stack stack machine assembly >>> address address data code language
======== ======== ======== ============== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD >>> [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH >>> New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e >>> [0000213e][0011390e][00113912] 55 push ebp
[0000213f][0011390e][00113912] 8bec mov ebp,esp
[00002141][0011390a][00103916] 51 push ecx
[00002142][00113906][0000213e] 683e210000 push 0000213e // push DD >>> [00002147][00113902][0000214c] e8a2f4ffff call 000015ee // calls HHH
New slave_stack at:14e33e
[0000213e][0015e336][0015e33a] 55 push ebp
[0000213f][0015e336][0015e33a] 8bec mov ebp,esp
[00002141][0015e332][0014e33e] 51 push ecx
[00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD >>> [00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call HHH >>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000021cb][00103872][00000000] 83c404 add esp,+04
[000021ce][0010386e][00000000] 50 push eax
[000021cf][0010386a][0000075f] 685f070000 push 0000075f
[000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 0
[000021d9][00103872][00000000] 83c408 add esp,+08
[000021dc][00103872][00000000] 33c0 xor eax,eax
[000021de][00103876][00000018] 5d pop ebp
[000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(11427) == 171 Pages
*Here is the HHH1(DD) trace again*
This inlcudes the HHH(DD) trace because DD calls HHH(DD)
machine stack stack machine assembly >>> address address data code language
======== ======== ======== ============== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD >>> [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH >>> New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e >>> [0000213e][0011390e][00113912] 55 push ebp
[0000213f][0011390e][00113912] 8bec mov ebp,esp
[00002141][0011390a][00103916] 51 push ecx
[00002142][00113906][0000213e] 683e210000 push 0000213e // push DD >>> [00002147][00113902][0000214c] e8a2f4ffff call 000015ee // calls HHH
New slave_stack at:14e33e
[0000213e][0015e336][0015e33a] 55 push ebp
[0000213f][0015e336][0015e33a] 8bec mov ebp,esp
[00002141][0015e332][0014e33e] 51 push ecx
[00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD >>> [00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call HHH >>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000021cb][00103872][00000000] 83c404 add esp,+04
[000021ce][0010386e][00000000] 50 push eax
[000021cf][0010386a][0000075f] 685f070000 push 0000075f
[000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 0
[000021d9][00103872][00000000] 83c408 add esp,+08
[000021dc][00103872][00000000] 33c0 xor eax,eax
[000021de][00103876][00000018] 5d pop ebp
[000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(11427) == 171 Pages
Thanks for that.
Can you see from the very traces you've posted that what I and DBush
earlier said is exactly right? That makes nonsense of your claims that
what was said was "counter-factual".
It's all there in the traces. I'll be posting full details in a new
thread...
Regards,
Mike.
It is NOT true that the first difference in the behavior
is when HHH aborts its emulation of DD.
The difference in the behavior begins long before that.
It begins as soon as the the DD emulated by HHH1 calls
HHH(DD) and the DD emulated by HHH calls HHH(DD).
The first of these calls DOES return.
as proven by the execution trace.
The second of these calls cannot possibly return.
as proven by repeating sequence in the execution trace.
HHH1 never emulates itself emulating DD because the
call from DD to HHH(DD) returns.
HHH continues to emulate itself emulating DD proving
a different sequence than DD emulated by HHH1. The
call from the emulated DD to HHH(DD) cannot possibly
return.
This is really only a variation of the same idea
as infinite recursion between two functions. The
only difference here is that one of these functions
has the power to stop it.
This causes the other function to stop running yet
not halt because halting is reserved for reaching a
final halt state.
On 5/7/2025 9:21 PM, Richard Damon wrote:
On 5/7/25 11:48 AM, olcott wrote:
On 5/7/2025 3:54 AM, Mikko wrote:
On 2025-05-06 18:05:15 +0000, olcott said:
That everyone here thinks that HHH can simply ignore
the rules of the x86 language and jump over the "call"
instruction to the "ret" instruction seems quite stupid
to me.
The halting problem does not prohibit such skip so in that sense
it is OK.
However, in order to correctly determine whether DD halts
it may need to know whether the called HHH returns and what it
returns if it does.
The call from DD emulated by HHH cannot possibly return.
Only because HHH can't be a correct emulator.
Liar
On 5/7/2025 9:14 PM, Richard Damon wrote:
On 5/7/25 2:24 PM, olcott wrote:
On 5/7/2025 5:58 AM, Richard Damon wrote:
On 5/6/25 10:00 PM, olcott wrote:
On 5/6/2025 5:49 PM, Richard Damon wrote:
On 5/6/25 2:05 PM, olcott wrote:
On 5/6/2025 5:59 AM, Richard Damon wrote:
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
Which starts with the assumption that an algorithm exists >>>>>>>>>>>> that performs the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of >>>>>>>>>>>> instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that >>>>>>>>>>>> computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed >>>>>>>>>>>> directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when >>>>>>>>>>>> executed directly
DO COMPUTE THAT THE INPUT IS NON-HALTING
IFF (if and only if) the mapping FROM INPUTS
IS COMPUTED.
i.e. it is found to map something other than the above >>>>>>>>>>>> function which is a contradiction.
The above function VIOLATES COMPUTER SCIENCE.
You make no attempt to show how my claim
THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT
you simply take that same quote from a computer
science textbook as the infallible word-of-God.
All you are doing is showing that you don't understand proof >>>>>>>>>> by contradiction,
Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>>>
No, YOU don't understand what Computer Science actually is
talking about.
Every function computed by a model of computation
must apply a specific sequence of steps that are
specified by the model to the actual finite string
input.
Right, "Computed by a model of computation", that
HHH(DD) must emulate DD according to the rules
of the x86 language.
Right, which is doesn't do.
Remember, your HHH stop processing at a CALL HHH instruction.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
*input D* until H correctly determines that its simulated D >>>>> *would never stop running unless aborted* then
*input D* // the actual input
Which calls the original H
*would never stop running unless aborted*
// A hypothetical HHH/DD pair where HHH and DD are
// exactly the same except that this HHH does not abort.
No, your hypothetical HHH (like your HHH1) paired with the originl
DD which uses the original HHH.
That is NOT what this means:
*simulated D would never stop running unless aborted*
Right, CORRECTLY SIMULATED D would never stop running unless aborted,
as that is the only type of simulation that shows behavior.
And D is, and only is, the program that we started with as the input,
which calls the original H, and only that H.
Where do you ee
All simulating halt deciders must
PREDICT WHAT THE BEHAVIOR WOULD BE
and thus cannot simply wait and see
what the behavior is.
Right, to be correct, they need to do that, but they can't.
HHH does correctly predict that its input DD
*would never stop running unless aborted*
If they don't analyze what
the behavior of the input WOULD BE if
they did not abort their simulation
But that is what they must do to be correct.
they would get stuck and never halt.
Simulating halt decider must PREDICT BEHAVIOR.
Right, which is why they have problems, and are not correct.
HHH does correctly predict that its input DD
*would never stop running unless aborted*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Your logic is just demonstrating that you are admitting that you logic
insists that it is ok to lie about the correct answer and be wrong,
but still claim to be right.
HHH does correctly predict that its input DD
*would never stop running unless aborted*
THUS MEETING THE REQUIRED SPEC.
That concept is what has made you into the pathological liar you are.
You have erased the definition of truth from your mind, by convincing
yourself that it must be ok to lie so you can claim to do what is
actually impossible.
This is what makes you utterly stupid.
You are very intelligent you pretend that you
do not understand very simple things so that
you can play sadistic head games.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated (according to the rules of the C
programming language) by any HHH that can possibly
exist cannot possibly reach its own "return" instruction.
On 5/7/2025 9:28 PM, Richard Damon wrote:
On 5/7/25 11:27 AM, olcott wrote:
On 5/7/2025 6:01 AM, Richard Damon wrote:
On 5/6/25 10:28 PM, olcott wrote:
On 5/6/2025 5:59 PM, Richard Damon wrote:
On 5/6/25 3:20 PM, olcott wrote:
On 5/6/2025 2:10 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 20:47 schreef olcott:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact that it >>>>>>>>>>>> is not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH
according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
That you do not understand it, does not mean that it has not
been provided to you. It has, many times. If you do not know
that you are wrong, you must be very stupid.
Everything besides a machine address by machine
address of DD emulated by HHH (according to the
rules of the x86 language) where the emulated
DD reaches its own "ret" instruction
In other words, if people don't agree with your fantasy that is
just in error, then "they" must be wrong.
No, it
*IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION*
No, YOU are a dishoneast dodge from the actual question
Most of my reviewers switch to rhetoric when they
know that they are wrong and still want to disagree.
Disagreement (not truth) is their highest priority.
Nope, that is just you projecting again.
You keep saying the DD emulated by HHH according
to the rules of the x86 language is wrong.
Right, because it stops wnen it should not.
You keep arguing that HHH is required to break these
rules to conform with the common misconception that HHH
is required to report on the direct execution of DD().
No, it needs to keep to them, which it doesn\'t.
Where did I say it must break the rules?
DD correctly simulated by HHH according to the rules
of the x86 language cannot possibly halt.
Which is a non-sense statement, as HHH doesn't correctly simulate its
input DD by those rules, as you have demonstarted,
Liar
Maybe I should take you to court over this slander.
It is like you never heard of infinite recursion.
On 5/8/2025 12:22 AM, Richard Heathfield wrote:
On 08/05/2025 06:12, olcott wrote:
It is like you never heard of infinite recursion.
I'm sure he has.
On a computer, there's no such thing.
Oh, we can /describe/ such a thing:
foo(){foo();}
or, if you prefer:
void bar(void);foo(){bar();}bar(){foo();}
but it never gets more than a yard off the starting line before
it breaks. On systems where function calls are facilitated by
pushing return addresses onto a stack, the stack rapidly runs
out of space, and a good OS will trip it up before Bad Things
can happen.
If you think you have "an essentially infinite recursion
relationship" you're only fooling yourself, nobody else.
We are testing the basic elements of key algorithms
in the concrete model of computation of the x86 language,
we have no need to look at memory requirements. The C
functions are proxies for Turing Machines.
I hate tedious details.
I specific the gist of ideas
so that the rest can be easily inferred.
Is it over your head that introducing or removing the code to
abort makes the program fundamentally different?
On 5/7/2025 3:24 PM, joes wrote:
Am Tue, 06 May 2025 13:40:16 -0500 schrieb olcott:
On 5/6/2025 10:53 AM, joes wrote:Then it is not the same HHH.
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:*would never stop running unless aborted*
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to
report on the direct execution of DD() and the input to HHH
specifies a different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence >>>>>> of steps as DD. HHH just answers about a different sequence of steps >>>>>> instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D >>>>> until H correctly determines that its simulated D *would never
stop running unless aborted* then
*input D* is the actual input *would never stop running unless
aborted* is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a
hypothetical version of D that calls a pure simulator.
refers to the same HHH that DD calls yet this hypothetical HHH does not
abort.
It is the exact same HHH/DD pair except that this
hypothetical HHH never aborts.
On 5/7/2025 10:30 PM, Richard Damon wrote:
On 5/7/25 10:50 AM, olcott wrote:
On 5/7/2025 6:12 AM, Richard Damon wrote:
On 5/6/25 10:40 PM, olcott wrote:
On 5/6/2025 6:00 PM, Richard Damon wrote:
On 5/6/25 1:54 PM, olcott wrote:
On 5/6/2025 6:06 AM, Richard Damon wrote:
On 5/5/25 10:29 PM, olcott wrote:
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a >>>>>>>>>>>> decider of the
simulating kind.
Such input forms a category error which results in the >>>>>>>>>>>> halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes >>>>>>>>>>> all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that >>>>>>>>>> it refutes, and thus your talk about correctly emulated by HHH >>>>>>>>>> is just a lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the
representation of a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
Can't be, as the input needs to be about a program, which must, >>>>>>>> by the definition of a program, include all its algorithm.
Yes, there are steps that also occur in the termination
analyzer, but they have been effectively copied into the program >>>>>>>> the input describes.
Note, nothing says that the representation of the program has to >>>>>>>> be an assembly level description of it. It has to be a complete >>>>>>>> description, that 100% defines the results the code will
generate (and if it will generate) but it doesn't need to be the >>>>>>>> exact assembly code,
YOU even understand that, as you present the code as "C" code, >>>>>>>> which isn't assembly.
What you forget is that the input program INCLUDES as its
definiton, all of the code it uses, and thus the call to the
decider it is built on includes that code into the decider, and >>>>>>>> that is a FIXED and DETERMINDED version of the decider, the one >>>>>>>> that THIS version of the input is designed to make wrong.
This doesn't change when you hypothosize a different decider
looking at THIS input.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D >>>>>>> *would never stop running unless aborted* then
*would never stop running unless aborted*
Refers to a hypothetical HHH/DD pair of the same HHH that
DD calls except that this hypothetical HHH never aborts.
Right, but a correct simulation of D does halt,
How the Hell is breaking the rules specified
by the x86 language possibly correct?
Right, how is HHH correct to abort its emulation?
I could say that the sum of 5 + 7 is a dirty sock
according to the rules of random gibberish.
Yes, and you do, because most of what you say IS "random gibberish"
When I go by the rules of arithmetic I am proved
wrong.
But the problem is you don't do that, but think you are because you
don't know the rules.
DD <is> emulated by HHH according to the rules
of the x86 language that specify the HHH also
emulates itself emulating DD
No it isn't.
until HHH determines that for the hypothetical
HHH/DD pair where the hypothetical HHH never
aborts DD would never stop running.
Which isn't part of the rules.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
refers to the hypothetical HHH/DD pair where
HHH never aborts its simulation.
That second paragraph is a lie and a misquote.
I still have the original email.
Ben has already verified this.
This is an actual cut-and-paste of the words
*From Thursday, October 13, 2022 12:16 PM email*
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.
In that email he requested that I surround that paragraph with
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
I also posted Date: Thu, 13 Oct 2022 11:46:22 -0500
[Michael Sipser of MIT validates the notion of a simulating halt
decider]
that contains the exact same word-for-word paragraph
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3Cti9fd0%241unl%241%40gioia.aioe.org%3E
Which you "misquite" by trying to put meanings into the words that he
never means.
For instance. To Professor Sipser, H and D are Turing Machines,
The quote mentions no such thing.
which means they are Programs.
You just admitted that you HHH and DD aren't programs ("zero
programs") but C functions.
That means NOTHING he said applies to you case.
Sorry, you are just makeing it obvious to all how stupid you are,
and that you consider lying a correct form of logic.
Professor Sipser said H could abort it simulation of D when it can
prove that the correct simulation of D (by whoever) would not halt.
Not quite.
When a hypothetical HHH/DD pair such that HHH never aborts
*simulated D would never stop running unless aborted*
But the Hypothetical PROGRAM HHH is to be given the representation of
the ORIGNAL PROGRAM DD which uses the code of the original PROGRAM
HHH, whcih does abort.
You are being far too loose with your interpretation of meaning.
This means that the correct simulation that the Hypothetical HHH will
see the code of the original program HHH abort its emulation and
return 0to the outer code of DD and it will halt.
Therefore, the origianl HHH never had the "permission" to stop, which
it did,
That is the original (as it is the only) D.
If you only glance at the words before artificially
contriving a fake rebuttal it may seem that way.
Which I have,
The fact that you have admitted that you H and D are category errors
for the statement you presented to Professor Sipser just shows your
utter ignorance.
There are at least two view on the HP p-roofs.
(a) It is an incoherent mistake
(b) The impossible input is decided to be non-halting
Your problem is you think constants can be changed, and that things
that are the same can be different, and that things that are defined
different can be treated the same.
The correct way for simulating halt deciders to work
is to examine what would happen if it did not abort.
And the input is a full representation of the program that it is,
which for D include the code of the H it calls, and thus when H does
the hypothetical, that code doesn't change
HHH sees a repeating pattern in emulated DD that proves
this DD can never reach its own emulated final halt state.
On Wed, 07 May 2025 11:35:07 +0100, Richard Heathfield wrote:
On 07/05/2025 11:26, Fred. Zwarts wrote:
Op 07.mei.2025 om 03:39 schreef olcott:
<snip>
There must be an algorithm having a specified sequence of steps thatYour 'must' has no basis.
are applied to the input to derive the output.
Not only that, but he is literally begging the question - i.e. assuming
as true that which he hopes to prove. "All questions must be decidable,
therefore all questions are decidable."
Turing assumed the same thing: "All questions are decidable." But he
went on to demonstrate that if the assumption is true, it must be false
- a patent absurdity that shows that his original assumption was false.
Wrong. All *well-formed* questions are decidable; the question the halting problem asks is not *well-formed*; if is *ill-formed* as it is predicated
on a category (type) error.
On 5/7/2025 4:48 AM, Mikko wrote:
On 2025-05-06 18:40:16 +0000, olcott said:
On 5/6/2025 10:53 AM, joes wrote:
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to report >>>>>>> on the direct execution of DD() and the input to HHH specifies a >>>>>>> different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence >>>>>> of steps as DD. HHH just answers about a different sequence of steps >>>>>> instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D until
H correctly determines that its simulated D *would never stop
running unless aborted* then
*input D* is the actual input *would never stop running unless aborted* >>>>> is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a
hypothetical version of D that calls a pure simulator.
*would never stop running unless aborted*
refers to the same HHH that DD calls yet
this hypothetical HHH does not abort.
You cannot possibly show the exact execution trace where DD is correctly >>>>> emulated by HHH and this emulated DD reaches past its own machine
address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can simulate >>>> DD/HHH.
HHH does simulate itself correctly yet must create
No, it cannot simulate itself to the point where it returns.
HHH(DD) does return.
On 5/7/2025 10:48 PM, Richard Damon wrote:
On 5/7/25 11:15 PM, olcott wrote:Termination analyzers can be and have been applied to C functions.
On 5/7/2025 9:09 PM, Richard Damon wrote:
On 5/7/25 11:31 AM, olcott wrote:
On 5/7/2025 5:55 AM, Richard Damon wrote:
On 5/6/25 10:09 PM, olcott wrote:
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only if) thei.e. it is found to map something other than the above function
mapping FROM INPUTS IS COMPUTED.
which is a contradiction.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT you
simply take that same quote from a computer science textbook as the
infallible word-of-God.
Every function computed by a model of computation must apply a specificAll you are doing is showing that you don't understand proof by >>>>>>>>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>>>>>> No, YOU don't understand what Computer Science actually is talking >>>>>>>>>>>> about.
sequence of steps that are specified by the model to the actual finite
string input.
You are very confused. An algorithm or program computes a function. >>>>>>>>>>
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function. >>>>>>>>>
Right, so HHH needs to apply the rules that it was designed with. >>>>>>>>
And that means it breaks the criteria that you say it needs to do to >>>>>>>> get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
No, to be a correct emulator it needs to continue until it reaches the end,
It can get the right answer if it emulates the input to the point that >>>>>> it can show that a
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D >>>>>>> *would never stop running unless aborted* then
Right, that UTM(D) would never halt.
*would never stop running unless aborted*
Is the hypothetical HHH/DD pair where HHH does not abort.
Nope, can't change DD, it is your hypothetical HHH, which has become >>>>>> UTM, when given the ORIGINAL DD, which calls the ORIGINAL HHH, as that >>>>>> code was part of the definition of DD.
HHH bases its decision on what the behavior of DD
would be if a hypothetical version of its own self
never aborted.
In other words, it bases it decision on a LIE.
It bases its decision on exactly what Professor Sipser agreed to.
Nope
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D
*specifies a non-halting sequence of configurations*.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*simulated D would never stop running unless aborted* then
*H can abort its simulation of D*
*D specifies a non-halting sequence of configurations*
One hypothetical HHH that never aborts and
another different HHH that does abort.
But your Hypothetical HHH wasn't given the right input, because you
never had one since you have admitted that D isn't a program as
required and assumed by Professor Sipser.
On 5/7/2025 1:27 PM, dbush wrote:
On 5/7/2025 2:24 PM, olcott wrote:
On 5/7/2025 5:58 AM, Richard Damon wrote:
On 5/6/25 10:00 PM, olcott wrote:
On 5/6/2025 5:49 PM, Richard Damon wrote:
On 5/6/25 2:05 PM, olcott wrote:
On 5/6/2025 5:59 AM, Richard Damon wrote:
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
Which starts with the assumption that an algorithm exists that performs
the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
DO COMPUTE THAT THE INPUT IS NON-HALTING
IFF (if and only if) the mapping FROM INPUTS
IS COMPUTED.
i.e. it is found to map something other than the above function which
is a contradiction.
The above function VIOLATES COMPUTER SCIENCE.
You make no attempt to show how my claim
THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT
you simply take that same quote from a computer
science textbook as the infallible word-of-God.
All you are doing is showing that you don't understand proof by contradiction,
Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>>>
No, YOU don't understand what Computer Science actually is talking about.
Every function computed by a model of computation
must apply a specific sequence of steps that are
specified by the model to the actual finite string
input.
Right, "Computed by a model of computation", that
HHH(DD) must emulate DD according to the rules
of the x86 language.
Right, which is doesn't do.
Remember, your HHH stop processing at a CALL HHH instruction.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
*input D* until H correctly determines that its simulated D >>>>> *would never stop running unless aborted* then
*input D* // the actual input
Which calls the original H
*would never stop running unless aborted*
// A hypothetical HHH/DD pair where HHH and DD are
// exactly the same except that this HHH does not abort.
No, your hypothetical HHH (like your HHH1) paired with the originl DD >>>> which uses the original HHH.
That is NOT what this means:
*simulated D would never stop running unless aborted*
All simulating halt deciders must
PREDICT WHAT THE BEHAVIOR WOULD BE
If the machine described by its input was executed directly, as per the
requirements of a halt decider:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
I have proved that everyone has been wrong about this
for ninety years. Ignoring my proof is not any rebuttal.
My proof is probably totally over-your-head.
On 5/7/2025 4:42 AM, Mikko wrote:
On 2025-05-06 15:29:59 +0000, olcott said:
On 5/6/2025 4:35 AM, Mikko wrote:
On 2025-05-05 17:37:20 +0000, olcott said:
On 5/5/2025 11:13 AM, Mr Flibble wrote:
On Mon, 05 May 2025 11:58:50 -0400, dbush wrote:
On 5/5/2025 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>>>>>> simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes all of the >>>>>>>> halting problem proofs.
Which start with the assumption that the following mapping is computable
and that (in this case) HHH computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>>>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>> directly
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
The x86utm operating system includes fully operational HHH and DD. >>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to the behavior of DD >>>>>>>> emulated by HHH this includes HHH emulating itself emulating DD. This >>>>>>>> matches the infinite recursion behavior pattern.
Thus the Halting Problem's "impossible" input is correctly determined >>>>>>>> to be non-halting.
Which is a contradiction. Therefore the assumption that the above >>>>>>> mapping is computable is proven false, as Linz and others have proved >>>>>>> and as you have *explicitly* agreed is correct.
The category (type) error manifests in all extant halting problem proofs >>>>>> including Linz. It is impossible to prove something which is ill- formed
in the first place.
/Flibble
The above example is category error because it asks
HHH(DD) to report on the direct execution of DD() and
the input to HHH specifies a different sequence of steps.
No, it does not. The input is DD specifides exactly the same sequence
of steps as DD. HHH just answers about a different sequence of steps
instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*input D* is the actual input
*would never stop running unless aborted*
is the hypothetical H/D pair where H does not abort.
H is hypthetical. There is no actual decider in Sipeser's words. But
what is said about D is true about any actual input as there is no
restriction on D other than it is an input to H.
You cannot possibly show the exact execution trace
That's right. An execution trace is too long to make without tools
that I don't have. Just remenber that absence of evidence is not
evidence of absense.
The execution trace of DD correctly emulated by HHH
keeps repeating the first five instructions until
HHH correctly determines:
*simulated D would never stop running unless aborted*
In other words HHH predicts what the behavior of DD
*would be* if HHH was a UTM.
On 5/7/2025 3:24 PM, joes wrote:Will you accept this piece of paper that is the same as a dollar bill
Am Tue, 06 May 2025 13:40:16 -0500 schrieb olcott:
On 5/6/2025 10:53 AM, joes wrote:
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:
On 5/6/2025 4:35 AM, Mikko wrote:
It is the exact same HHH/DD pair except that this hypothetical HHH never aborts.Then it is not the same HHH.*would never stop running unless aborted*As agreed to below:No, it does not. The input is DD specifides exactly the same
sequence of steps as DD. HHH just answers about a different
sequence of steps instead of the the seqeunce specified by its
input.
*input D* is the actual input *would never stop running unless
aborted* is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a
hypothetical version of D that calls a pure simulator.
refers to the same HHH that DD calls yet this hypothetical HHH does
not abort.
On 5/7/2025 10:00 PM, Mike Terry wrote:Where do they diverge? How does HHH1 simulate the HHH called from DD
On 08/05/2025 00:01, olcott wrote:
On 5/7/2025 5:06 PM, Mike Terry wrote:
On 07/05/2025 22:32, olcott wrote:
On 5/7/2025 4:20 PM, Mike Terry wrote:
On 07/05/2025 17:25, olcott wrote:
On 5/7/2025 10:44 AM, Mike Terry wrote:
You need to read what posters actually say. I said the traces >>>>>>>> were the same up to the point where HHH stops simulating.
THAT IS COUNTER-FACTUAL.
HHH continues to emulate DD long after their paths diverge.
HHH1 only emulates DD once.
HHH emulates DD once and then emulates itself emulating DD.
I didn't say anything about calls that return or do not return >>>>>>>> "being the same thing" and none of what you relates to whether >>>>>>>> what I said was correct.HHH1(DD) emulates DD once.
Look, if you insist the traces are not the same up to the point >>>>>>>> where HHH stops simulating, show the two traces and we'll just >>>>>>>> look and see! Simples.
HHH(DD) emulates DD once and then emulates itself emulating DD.
It is NOT true that the first difference in the behavior is when HHH[identical traces]Excellent - above we have the trace for HHH1, half of what we need. >>>>>> While we /could/ use that to /deduce/ what the trace for HHH should >>>>>> be, we shouldn't have to resort to that. The clean way to proceed >>>>>> is for you to now post the similar trace for main calling HHH, then >>>>>> we can compare them with minimal editing...The two calls to HHH(DD) are in the part you ignored.
HHH1(DD) emulates DD that calls the emulated HHH(DD) to emulate DD
that calls HHH(DD) that emulates itself emulating DD.
I marked these calls with comments.
As I explained, it would be clearer if you just supply the requested
trace.
Are you unable/unwilling to do that?
Thanks for that.
Can you see from the very traces you've posted that what I and DBush
earlier said is exactly right? That makes nonsense of your claims that
what was said was "counter-factual".
It's all there in the traces. I'll be posting full details in a new
thread...
aborts its emulation of DD.
The difference in the behavior begins long before that. It begins as
soon as the the DD emulated by HHH1 calls HHH(DD) and the DD emulated by
HHH calls HHH(DD).
The first of these calls DOES return.
as proven by the execution trace.
The second of these calls cannot possibly return.
as proven by repeating sequence in the execution trace.
HHH1 never emulates itself emulating DD because the call from DD to
HHH(DD) returns.
HHH continues to emulate itself emulating DD proving a different
sequence than DD emulated by HHH1. The call from the emulated DD to
HHH(DD) cannot possibly return.
This is really only a variation of the same idea as infinite recursion between two functions. The only difference here is that one of these functions has the power to stop it.
This causes the other function to stop running yet not halt because
halting is reserved for reaching a final halt state.
On 5/7/2025 10:08 PM, Richard Damon wrote:Yes, this hypothetical HHH would not abort, but the actual HHH called
On 5/7/25 9:51 AM, olcott wrote:
On 5/7/2025 4:48 AM, Mikko wrote:
On 2025-05-06 18:40:16 +0000, olcott said:
On 5/6/2025 10:53 AM, joes wrote:
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:
On 5/6/2025 4:35 AM, Mikko wrote:
*would never stop running unless aborted*As agreed to below:No, it does not. The input is DD specifides exactly the same
sequence of steps as DD. HHH just answers about a different
sequence of steps instead of the the seqeunce specified by its >>>>>>>> input.
*input D* is the actual input *would never stop running unlessH should simulate its actual input D that calls the aborting H, not >>>>>> a hypothetical version of D that calls a pure simulator.
aborted*
is the hypothetical H/D pair where H does not abort.
refers to the same HHH that DD calls yet this hypothetical HHH does
not abort.
And what's wrong with that? HHH should let DD halt by itself.In other words HHH caught DD trying to cause itself to halt.HHH(DD) does return.No, it cannot simulate itself to the point where it returns.HHH does simulate itself correctly yet must createYou cannot possibly show the exact execution trace where DD isDuh, no simulator can simulate itself correctly. But HHH1 can
correctly emulated by HHH and this emulated DD reaches past its
own machine address [0000213c].
simulate DD/HHH.
Obviously you can't completely simulate a nonterminating input AND halt.No because that would make the termination analyzer fail to terminateHHH only need simulate DD until it correctly determines *simulated DRight, that a correct simulation of D would never stop running,
would never stop running unless aborted*
This refers to a hypothetical HHH/DD pair where HHH never aborts.
and that is not allowed dumbell bee.
If they, the simulator, didn't abort the unchanged input, i.e. that stillThat includes using the fact that H does what it does, and the input isIt is an inherent aspect of the nature of simulating termination
what it is.
And thus NOT the hypothetical HHH/DD pair, but the hypothetical HHH
looking at the actual DD which still calls the origianl HHH
analyzer is that they must always correctly predict what the behavior of their input would be IF THEY NEVER ABORTED. If they don't always do this
they will sometimes get stuck in non-termination.
Your HHH really is not a simulator. I want mine to produce the sameYou just don't understand what (correct) simulation means in the field,Everyone here seems to think they they get to stipulate what correct it, rather what it really is.
or what a program actually is.
On 5/7/2025 10:48 PM, Richard Damon wrote:
On 5/7/25 11:15 PM, olcott wrote:Termination analyzers can be and have been applied to C functions.
On 5/7/2025 9:09 PM, Richard Damon wrote:
On 5/7/25 11:31 AM, olcott wrote:
On 5/7/2025 5:55 AM, Richard Damon wrote:
On 5/6/25 10:09 PM, olcott wrote:
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no >>>>>>>>>>>>>>> attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and >>>>>>>>>>>>>>>>> only if) thei.e. it is found to map something other than the above >>>>>>>>>>>>>>>> function
mapping FROM INPUTS IS COMPUTED.
which is a contradiction.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS >>>>>>>>>>>>>>> INCORRECT you
simply take that same quote from a computer science >>>>>>>>>>>>>>> textbook as the
infallible word-of-God.
Every function computed by a model of computation must apply >>>>>>>>>>> a specificNo, YOU don't understand what Computer Science actually is >>>>>>>>>>>> talkingAll you are doing is showing that you don't understand >>>>>>>>>>>>>> proof byNot at all. The COMPUTER SCIENCE of your requirements IS >>>>>>>>>>>>> WRONG!
contradiction,
about.
sequence of steps that are specified by the model to the >>>>>>>>>>> actual finite
string input.
You are very confused. An algorithm or program computes a
function.
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function. >>>>>>>>>
Right, so HHH needs to apply the rules that it was designed with. >>>>>>>>
And that means it breaks the criteria that you say it needs to >>>>>>>> do to get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
No, to be a correct emulator it needs to continue until it reaches >>>>>> the end,
It can get the right answer if it emulates the input to the point
that it can show that a
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D >>>>>>> *would never stop running unless aborted* then
Right, that UTM(D) would never halt.
*would never stop running unless aborted*
Is the hypothetical HHH/DD pair where HHH does not abort.
Nope, can't change DD, it is your hypothetical HHH, which has
become UTM, when given the ORIGINAL DD, which calls the ORIGINAL
HHH, as that code was part of the definition of DD.
HHH bases its decision on what the behavior of DD
would be if a hypothetical version of its own self
never aborted.
In other words, it bases it decision on a LIE.
It bases its decision on exactly what Professor Sipser agreed to.
Nope
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D
*specifies a non-halting sequence of configurations*.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*simulated D would never stop running unless aborted* then
*H can abort its simulation of D*
*D specifies a non-halting sequence of configurations*
One hypothetical HHH that never aborts and
another different HHH that does abort.
But your Hypothetical HHH wasn't given the right input, because you
never had one since you have admitted that D isn't a program as
required and assumed by Professor Sipser.
To be correct, Hypothetical HHH is given real DD which uses the code
of real HHH and then, when it does its simulation it will see that
code of the real HHH abort its simulation
As soon as HHH correctly determines
*simulated D would never stop running unless aborted* then
It can see the same repeated state that we can all see.
*H can abort its simulation of D*
*D specifies a non-halting sequence of configurations*
On 5/7/2025 10:59 PM, Richard Damon wrote:
On 5/7/25 10:53 PM, olcott wrote:
On 5/7/2025 9:28 PM, Richard Damon wrote:
On 5/7/25 11:27 AM, olcott wrote:
On 5/7/2025 6:01 AM, Richard Damon wrote:
On 5/6/25 10:28 PM, olcott wrote:
On 5/6/2025 5:59 PM, Richard Damon wrote:
On 5/6/25 3:20 PM, olcott wrote:
On 5/6/2025 2:10 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 20:47 schreef olcott:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote:
On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact that it >>>>>>>>>>>>>> is not possible to construct a universal decider.
Everyone here insists that functions computed
by models of computation can ignore inputs and
base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH >>>>>>>>>>>>> according to the semantics of the x86 language?
*Only an execution trace will do*
The exact same steps for DD to be emulated by UTM.
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>> [00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics
that you know that you cannot provide because
you know that you are wrong.
That you do not understand it, does not mean that it has not >>>>>>>>>> been provided to you. It has, many times. If you do not know >>>>>>>>>> that you are wrong, you must be very stupid.
Everything besides a machine address by machine
address of DD emulated by HHH (according to the
rules of the x86 language) where the emulated
DD reaches its own "ret" instruction
In other words, if people don't agree with your fantasy that is >>>>>>>> just in error, then "they" must be wrong.
No, it
*IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION*
No, YOU are a dishoneast dodge from the actual question
Most of my reviewers switch to rhetoric when they
know that they are wrong and still want to disagree.
Disagreement (not truth) is their highest priority.
Nope, that is just you projecting again.
You keep saying the DD emulated by HHH according
to the rules of the x86 language is wrong.
Right, because it stops wnen it should not.
You keep arguing that HHH is required to break these
rules to conform with the common misconception that HHH
is required to report on the direct execution of DD().
No, it needs to keep to them, which it doesn\'t.
Where did I say it must break the rules?
DD correctly simulated by HHH according to the rules
of the x86 language cannot possibly halt.
Which is a non-sense statement, as HHH doesn't correctly simulate
its input DD by those rules, as you have demonstarted,
Liar
*THE* HHH is defined to abort it simulation.
Aborted simulations are, by definition, not correct simulation per the
x86 language.
Thus, you are a liar.
Maybe I should take you to court over this slander.
It would be libel dumb bunny and I have much more on
you than you have on me. The only errors that you
"know" of that I made are your own misconceptions.
After all, I can prove my point, as you HAVE stipulated what the code
for HHH is, and
can produce the actual definition of the x86 language,Not allowed to make any counterfeit x86 language.
and show how they disagree.
I have never ever gave a rat's ass what anyone thinks of me.
Doofuses are not my judge.
The one issue is showing damages, as your repuation is so bad, I would
need to find someone who believed you.
Beliefs are lies we tell ourselves.
Knowledge is the comprehension of the connections
between ideas.
On 5/7/2025 10:40 PM, Richard Damon wrote:
On 5/7/25 11:32 PM, olcott wrote:
On 5/7/2025 10:00 PM, Mike Terry wrote:
On 08/05/2025 00:01, olcott wrote:
On 5/7/2025 5:06 PM, Mike Terry wrote:
On 07/05/2025 22:32, olcott wrote:
On 5/7/2025 4:20 PM, Mike Terry wrote:
On 07/05/2025 17:25, olcott wrote:
On 5/7/2025 10:44 AM, Mike Terry wrote:
On 07/05/2025 04:11, olcott wrote:
On 5/6/2025 9:53 PM, Mike Terry wrote:
On 07/05/2025 00:11, olcott wrote:
On 5/6/2025 5:49 PM, Mike Terry wrote:
On 06/05/2025 21:25, olcott wrote:
On 5/6/2025 2:35 PM, dbush wrote:
On 5/6/2025 2:47 PM, olcott wrote:
On 5/6/2025 7:14 AM, dbush wrote:
On 5/6/2025 1:54 AM, olcott wrote:
On 5/6/2025 12:49 AM, Richard Heathfield wrote: >>>>>>>>>>>>>>>>>>>> On 06/05/2025 00:29, olcott wrote:
<snip>
It is the problem incorrect specification that creates >>>>>>>>>>>>>>>>>>>>> the contradiction.
Not at all. The contradiction arises from the fact >>>>>>>>>>>>>>>>>>>> that it is not possible to construct a universal >>>>>>>>>>>>>>>>>>>> decider.
Everyone here insists that functions computed >>>>>>>>>>>>>>>>>>>>> by models of computation can ignore inputs and >>>>>>>>>>>>>>>>>>>>> base their output on something else.
I don't think anyone's saying that.
Maybe you don't read so well.
What are the exact steps for DD to be emulated by HHH >>>>>>>>>>>>>>>>>>> according to the semantics of the x86 language? >>>>>>>>>>>>>>>>>>> *Only an execution trace will do*
The exact same steps for DD to be emulated by UTM. >>>>>>>>>>>>>>>>>>
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>>>>>> [00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD >>>>>>>>>>>>>>>>> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD) >>>>>>>>>>>>>>>>> [00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00 >>>>>>>>>>>>>>>>> [0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Machine address by machine address specifics >>>>>>>>>>>>>>>>> that you know that you cannot provide because >>>>>>>>>>>>>>>>> you know that you are wrong.
HHH and UTM emulate DD exactly the same up until the >>>>>>>>>>>>>>>> point that HHH aborts,
When you trace through the actual steps you
will see that this is counter-factual.
No, it is exactly right. Remember, I posted a comparison >>>>>>>>>>>>>> of the two traces side by side some time ago, and they >>>>>>>>>>>>>> were indeed IDENTICAL line for line up to the point where >>>>>>>>>>>>>> HHH decided to discontinue simulating.
That is counter-factual.
Dude! :/ I posted the comparison and the traces were the >>>>>>>>>>>> same up to the point where HHH discontinued the simulation. >>>>>>>>>>>> How can it be "counter-factual"?
HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return. >>>>>>>>>>>
A call that returns and a call that cannot possibly
return *are not exactly the same thing*
You need to read what posters actually say. I said the traces >>>>>>>>>> were the same up to the point where HHH stops simulating.
THAT IS COUNTER-FACTUAL.
HHH continues to emulate DD long after their paths diverge.
HHH1 only emulates DD once.
HHH emulates DD once and then emulates itself emulating DD.
I didn't say anything about calls that return or do not
return "being the same thing" and none of what you relates to >>>>>>>>>> whether what I said was correct.
Look, if you insist the traces are not the same up to the
point where HHH stops simulating, show the two traces and
we'll just look and see! Simples.
HHH1(DD) emulates DD once.
HHH(DD) emulates DD once and then emulates itself emulating DD. >>>>>>>>>
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== ============= >>>>>>>>> [000021be][00103872][00000000] 55 push ebp >>>>>>>>> [000021bf][00103872][00000000] 8bec mov ebp,esp >>>>>>>>> [000021c1][0010386e][0000213e] 683e210000 push 0000213e // >>>>>>>>> push DD
[000021c6][0010386a][000021cb] e853f3ffff call 0000151e // >>>>>>>>> call HHH1
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored >>>>>>>>> at:11391e
[0000213e][0011390e][00113912] 55 push ebp >>>>>>>>> [0000213f][0011390e][00113912] 8bec mov ebp,esp >>>>>>>>> [00002141][0011390a][00103916] 51 push ecx >>>>>>>>> [00002142][00113906][0000213e] 683e210000 push 0000213e // >>>>>>>>> push DD
[00002147][00113902][0000214c] e8a2f4ffff call 000015ee // >>>>>>>>> call HHH
New slave_stack at:14e33e
Begin Local Halt Decider Simulation Execution Trace Stored >>>>>>>>> at:15e346
[0000213e][0015e336][0015e33a] 55 push ebp >>>>>>>>> [0000213f][0015e336][0015e33a] 8bec mov ebp,esp >>>>>>>>> [00002141][0015e332][0014e33e] 51 push ecx >>>>>>>>> [00002142][0015e32e][0000213e] 683e210000 push 0000213e // >>>>>>>>> push DD
[00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // >>>>>>>>> call HHH
New slave_stack at:198d66
[0000213e][001a8d5e][001a8d62] 55 push ebp >>>>>>>>> [0000213f][001a8d5e][001a8d62] 8bec mov ebp,esp >>>>>>>>> [00002141][001a8d5a][00198d66] 51 push ecx >>>>>>>>> [00002142][001a8d56][0000213e] 683e210000 push 0000213e >>>>>>>>> [00002147][001a8d52][0000214c] e8a2f4ffff call 000015ee >>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>>
[0000214c][0011390a][00103916] 83c404 add esp,+04 >>>>>>>>> [0000214f][0011390a][00000000] 8945fc mov [ebp-04],eax
[00002152][0011390a][00000000] 837dfc00 cmp dword >>>>>>>>> [ebp-04],+00
[00002156][0011390a][00000000] 7402 jz 0000215a >>>>>>>>> [0000215a][0011390a][00000000] 8b45fc mov eax,[ebp-04]
[0000215d][0011390e][00113912] 8be5 mov esp,ebp >>>>>>>>> [0000215f][00113912][000015d3] 5d pop ebp >>>>>>>>> [00002160][00113916][0003a980] c3 ret >>>>>>>>> [000021cb][00103872][00000000] 83c404 add esp,+04 >>>>>>>>> [000021ce][0010386e][00000001] 50 push eax >>>>>>>>> [000021cf][0010386a][0000075f] 685f070000 push 0000075f >>>>>>>>> [000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e >>>>>>>>> Input_Halts = 1
[000021d9][00103872][00000000] 83c408 add esp,+08 >>>>>>>>> [000021dc][00103872][00000000] 33c0 xor eax,eax >>>>>>>>> [000021de][00103876][00000018] 5d pop ebp >>>>>>>>> [000021df][0010387a][00000000] c3 ret >>>>>>>>> Number of Instructions Executed(400885) == 5983 Pages
Excellent - above we have the trace for HHH1, half of what we
need. While we /could/ use that to /deduce/ what the trace for >>>>>>>> HHH should be, we shouldn't have to resort to that. The clean >>>>>>>> way to proceed is for you to now post the similar trace for main >>>>>>>> calling HHH, then we can compare them with minimal editing...
Mike.
The two calls to HHH(DD) are in the part you ignored.
HHH1(DD) emulates DD that calls the emulated HHH(DD)
to emulate DD that calls HHH(DD) that emulates itself
emulating DD.
I marked these calls with comments.
As I explained, it would be clearer if you just supply the
requested trace.
Are you unable/unwilling to do that?
*This is the HHH(DD) trace*
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD
[000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call >>>>> HHH
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e >>>>> [0000213e][0011390e][00113912] 55 push ebp
[0000213f][0011390e][00113912] 8bec mov ebp,esp
[00002141][0011390a][00103916] 51 push ecx
[00002142][00113906][0000213e] 683e210000 push 0000213e // push DD
[00002147][00113902][0000214c] e8a2f4ffff call 000015ee //
calls HHH
New slave_stack at:14e33e
[0000213e][0015e336][0015e33a] 55 push ebp
[0000213f][0015e336][0015e33a] 8bec mov ebp,esp
[00002141][0015e332][0014e33e] 51 push ecx
[00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD
[00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call >>>>> HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000021cb][00103872][00000000] 83c404 add esp,+04
[000021ce][0010386e][00000000] 50 push eax
[000021cf][0010386a][0000075f] 685f070000 push 0000075f
[000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 0
[000021d9][00103872][00000000] 83c408 add esp,+08
[000021dc][00103872][00000000] 33c0 xor eax,eax
[000021de][00103876][00000018] 5d pop ebp
[000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(11427) == 171 Pages
*Here is the HHH1(DD) trace again*
This inlcudes the HHH(DD) trace because DD calls HHH(DD)
machine stack stack machine assembly
address address data code language
======== ======== ======== ============== =============
[000021be][00103872][00000000] 55 push ebp
[000021bf][00103872][00000000] 8bec mov ebp,esp
[000021c1][0010386e][0000213e] 683e210000 push 0000213e // push DD
[000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call >>>>> HHH
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e >>>>> [0000213e][0011390e][00113912] 55 push ebp
[0000213f][0011390e][00113912] 8bec mov ebp,esp
[00002141][0011390a][00103916] 51 push ecx
[00002142][00113906][0000213e] 683e210000 push 0000213e // push DD
[00002147][00113902][0000214c] e8a2f4ffff call 000015ee //
calls HHH
New slave_stack at:14e33e
[0000213e][0015e336][0015e33a] 55 push ebp
[0000213f][0015e336][0015e33a] 8bec mov ebp,esp
[00002141][0015e332][0014e33e] 51 push ecx
[00002142][0015e32e][0000213e] 683e210000 push 0000213e // push DD
[00002147][0015e32a][0000214c] e8a2f4ffff call 000015ee // call >>>>> HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000021cb][00103872][00000000] 83c404 add esp,+04
[000021ce][0010386e][00000000] 50 push eax
[000021cf][0010386a][0000075f] 685f070000 push 0000075f
[000021d4][0010386a][0000075f] e8a5e5ffff call 0000077e
Input_Halts = 0
[000021d9][00103872][00000000] 83c408 add esp,+08
[000021dc][00103872][00000000] 33c0 xor eax,eax
[000021de][00103876][00000018] 5d pop ebp
[000021df][0010387a][00000000] c3 ret
Number of Instructions Executed(11427) == 171 Pages
Thanks for that.
Can you see from the very traces you've posted that what I and DBush
earlier said is exactly right? That makes nonsense of your claims
that what was said was "counter-factual".
It's all there in the traces. I'll be posting full details in a new
thread...
Regards,
Mike.
It is NOT true that the first difference in the behavior
is when HHH aborts its emulation of DD.
The difference in the behavior begins long before that.
It begins as soon as the the DD emulated by HHH1 calls
HHH(DD) and the DD emulated by HHH calls HHH(DD).
So, why didn't it show in the traces?
The first of these calls DOES return.
as proven by the execution trace.
The second of these calls cannot possibly return.
as proven by repeating sequence in the execution trace.
Nope.
Do you make blanket denials to hide the fact that you don't hardly
understand this stuff much at all?
Show how nope is true.
HHH1 never emulates itself emulating DD because the
call from DD to HHH(DD) returns.
So? It still correctly emulated every instruction of its input DD
And saw exactly the same sequence of instructions that HHH saw.
HHH continues to emulate itself emulating DD proving
a different sequence than DD emulated by HHH1. The
call from the emulated DD to HHH(DD) cannot possibly
return.
And where was the difference?
You say it can not return, but that isn't a true statement.
It has been true for three years and you still
don't understand the basic notions of a pair of
functions caught in otherwise)
slight variable of
a pair functions in an infinite recursion relationship
That only would be true if HHH wasn't the HHH that it is, which is
just a lie.
This is really only a variation of the same idea
as infinite recursion between two functions. The
only difference here is that one of these functions
has the power to stop it.
But the recursion isn't infinite, as this HHH was defined to stop it.
This causes the other function to stop running yet
not halt because halting is reserved for reaching a
final halt state.
In other words, your logic is based on things being allowed to assume
things are not what they are, but what they think they are.
Or, in simpler words, you logic is based on that it is ok to lie and
make false conclusions.
We can only assume this applies to ALL your logic, so you just
indicated that we can just assume everything you say is based on the
logic that the system is allowed to lie.
Sorry, that isn't how real logic works, so nothing you say actually
have valid meaning, as you have said that you may lie at any time you
think you want to.
You still don't understand the basic notion of a
pair of functions that are in an essentially
infinite recursion relationship except that one
of these functions can stop the other one.
It is like you never heard of infinite recursion.
On 5/8/2025 12:22 AM, Richard Heathfield wrote:
On 08/05/2025 06:12, olcott wrote:
It is like you never heard of infinite recursion.
I'm sure he has.
On a computer, there's no such thing.
Oh, we can /describe/ such a thing:
foo(){foo();}
or, if you prefer:
void bar(void);foo(){bar();}bar(){foo();}
but it never gets more than a yard off the starting line before it
breaks. On systems where function calls are facilitated by pushing
return addresses onto a stack, the stack rapidly runs out of space,
and a good OS will trip it up before Bad Things can happen.
If you think you have "an essentially infinite recursion relationship"
you're only fooling yourself, nobody else.
We are testing the basic elements of key algorithms
in the concrete model of computation of the x86 language,
we have no need to look at memory requirements. The C
functions are proxies for Turing Machines.
I hate tedious details. I specific the gist of ideas
so that the rest can be easily inferred.
On 5/7/2025 10:08 PM, Richard Damon wrote:
On 5/7/25 9:51 AM, olcott wrote:
On 5/7/2025 4:48 AM, Mikko wrote:
On 2025-05-06 18:40:16 +0000, olcott said:
On 5/6/2025 10:53 AM, joes wrote:
Am Tue, 06 May 2025 10:29:59 -0500 schrieb olcott:
On 5/6/2025 4:35 AM, Mikko wrote:As agreed to below:
On 2025-05-05 17:37:20 +0000, olcott said:
The above example is category error because it asks HHH(DD) to >>>>>>>>> report
on the direct execution of DD() and the input to HHH specifies a >>>>>>>>> different sequence of steps.
No, it does not. The input is DD specifides exactly the same
sequence
of steps as DD. HHH just answers about a different sequence of >>>>>>>> steps
instead of the the seqeunce specified by its input.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D until >>>>>>> H correctly determines that its simulated D *would never stop
running unless aborted* then
*input D* is the actual input *would never stop running unless
aborted*
is the hypothetical H/D pair where H does not abort.
H should simulate its actual input D that calls the aborting H, not a >>>>>> hypothetical version of D that calls a pure simulator.
*would never stop running unless aborted*
refers to the same HHH that DD calls yet
this hypothetical HHH does not abort.
You cannot possibly show the exact execution trace where DD is
correctly
emulated by HHH and this emulated DD reaches past its own machine >>>>>>> address [0000213c].
Duh, no simulator can simulate itself correctly. But HHH1 can
simulate
DD/HHH.
HHH does simulate itself correctly yet must create
No, it cannot simulate itself to the point where it returns.
HHH(DD) does return.
And thus so does the HHH(DD) that DD calls.
In other words HHH caught DD trying to cause itself to halt.
Right, that a correct simulation of D would never stop running,
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its *simulated D*
*would never stop running unless aborted* then
HHH only need simulate DD until it correctly determines
*simulated D would never stop running unless aborted*
This refers to a hypothetical HHH/DD pair where HHH never aborts.
No because that would make the termination analyzer
fail to terminate and that is not allowed dumbell bee.
That includes using the fact that H does what it does, and the input
is what it is.
And thus NOT the hypothetical HHH/DD pair, but the hypothetical HHH
looking at the actual DD which still calls the origianl HHH
It is an inherent aspect of the nature of simulating
termination analyzer is that they must always correctly
predict what the behavior of their input would be
IF THEY NEVER ABORTED. If they don't always do this
they will sometimes get stuck in non-termination.
You just don't understand what (correct) simulation means in the
field, or what a program actually is.
Everyone here seems to think they they get to stipulate
what correct it, rather what it really is.
And, your whole system has an improper intertwining of the TWO
programs that are mentioned (H and D).
They are essentially a pair of C functions that
would be in infinite recursion with each other
except that one of them has the power to stop it.
Please point out anywhere in the proof where he implies that H or D
are NOT actual complete programs, it is sort of a requirement as
Turing Machies always are complete, that is part of their beauty, you
can't make a non-computation/program Turing Machine.
Sorry, you really are showing that you are THAT Stupid.
On 5/7/2025 10:30 PM, Richard Damon wrote:
On 5/7/25 10:50 AM, olcott wrote:
On 5/7/2025 6:12 AM, Richard Damon wrote:
On 5/6/25 10:40 PM, olcott wrote:
On 5/6/2025 6:00 PM, Richard Damon wrote:
On 5/6/25 1:54 PM, olcott wrote:
On 5/6/2025 6:06 AM, Richard Damon wrote:
On 5/5/25 10:29 PM, olcott wrote:
On 5/5/2025 8:06 PM, Richard Damon wrote:
On 5/5/25 11:51 AM, olcott wrote:
On 5/5/2025 10:17 AM, Mr Flibble wrote:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a >>>>>>>>>>>> decider of the
simulating kind.
Such input forms a category error which results in the >>>>>>>>>>>> halting problem
being ill-formed as currently defined.
/Flibble
I prefer to look at it as a counter-example that refutes >>>>>>>>>>> all of the halting problem proofs.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Which isn't a program until you include the SPECIFIC HHH that >>>>>>>>>> it refutes, and thus your talk about correctly emulated by HHH >>>>>>>>>> is just a lie.
https://github.com/plolcott/x86utm
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
And *ITS INPUT*, for the HHH that answers 0, is the
representation of a program
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
Can't be, as the input needs to be about a program, which must, >>>>>>>> by the definition of a program, include all its algorithm.
Yes, there are steps that also occur in the termination
analyzer, but they have been effectively copied into the program >>>>>>>> the input describes.
Note, nothing says that the representation of the program has to >>>>>>>> be an assembly level description of it. It has to be a complete >>>>>>>> description, that 100% defines the results the code will
generate (and if it will generate) but it doesn't need to be the >>>>>>>> exact assembly code,
YOU even understand that, as you present the code as "C" code, >>>>>>>> which isn't assembly.
What you forget is that the input program INCLUDES as its
definiton, all of the code it uses, and thus the call to the
decider it is built on includes that code into the decider, and >>>>>>>> that is a FIXED and DETERMINDED version of the decider, the one >>>>>>>> that THIS version of the input is designed to make wrong.
This doesn't change when you hypothosize a different decider
looking at THIS input.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D >>>>>>> *would never stop running unless aborted* then
*would never stop running unless aborted*
Refers to a hypothetical HHH/DD pair of the same HHH that
DD calls except that this hypothetical HHH never aborts.
Right, but a correct simulation of D does halt,
How the Hell is breaking the rules specified
by the x86 language possibly correct?
Right, how is HHH correct to abort its emulation?
I could say that the sum of 5 + 7 is a dirty sock
according to the rules of random gibberish.
Yes, and you do, because most of what you say IS "random gibberish"
When I go by the rules of arithmetic I am proved
wrong.
But the problem is you don't do that, but think you are because you
don't know the rules.
DD <is> emulated by HHH according to the rules
of the x86 language that specify the HHH also
emulates itself emulating DD
No it isn't.
until HHH determines that for the hypothetical
HHH/DD pair where the hypothetical HHH never
aborts DD would never stop running.
Which isn't part of the rules.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
*would never stop running unless aborted*
refers to the hypothetical HHH/DD pair where
HHH never aborts its simulation.
That second paragraph is a lie and a misquote.
I still have the original email.
Ben has already verified this.
This is an actual cut-and-paste of the words
*From Thursday, October 13, 2022 12:16 PM email*
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.
In that email he requested that I surround that paragraph with
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
I also posted Date: Thu, 13 Oct 2022 11:46:22 -0500
[Michael Sipser of MIT validates the notion of a simulating halt
decider]
that contains the exact same word-for-word paragraph
https://al.howardknight.net/?
STYPE=msgid&MSGI=%3Cti9fd0%241unl%241%40gioia.aioe.org%3E
Which you "misquite" by trying to put meanings into the words that he
never means.
For instance. To Professor Sipser, H and D are Turing Machines,
The quote mentions no such thing.
which means they are Programs.
You just admitted that you HHH and DD aren't programs ("zero
programs") but C functions.
That means NOTHING he said applies to you case.
Sorry, you are just makeing it obvious to all how stupid you are,
and that you consider lying a correct form of logic.
Professor Sipser said H could abort it simulation of D when it can
prove that the correct simulation of D (by whoever) would not halt.
Not quite.
When a hypothetical HHH/DD pair such that HHH never aborts
*simulated D would never stop running unless aborted*
But the Hypothetical PROGRAM HHH is to be given the representation of
the ORIGNAL PROGRAM DD which uses the code of the original PROGRAM
HHH, whcih does abort.
You are being far too loose with your interpretation of meaning.
This means that the correct simulation that the Hypothetical HHH will
see the code of the original program HHH abort its emulation and
return 0to the outer code of DD and it will halt.
Therefore, the origianl HHH never had the "permission" to stop, which
it did,
That is the original (as it is the only) D.
If you only glance at the words before artificially
contriving a fake rebuttal it may seem that way.
Which I have,
The fact that you have admitted that you H and D are category errors
for the statement you presented to Professor Sipser just shows your
utter ignorance.
There are at least two view on the HP p-roofs.
(a) It is an incoherent mistake
(b) The impossible input is decided to be non-halting
Your problem is you think constants can be changed, and that things
that are the same can be different, and that things that are defined
different can be treated the same.
The correct way for simulating halt deciders to work
is to examine what would happen if it did not abort.
And the input is a full representation of the program that it is,
which for D include the code of the H it calls, and thus when H does
the hypothetical, that code doesn't change
HHH sees a repeating pattern in emulated DD that proves
this DD can never reach its own emulated final halt state.
This requires the hypothetical HHH/DD pair (HHH never aborts)
that professor Sipser agreed to.
Nope. because you changed DD becuase you didn't define DD to be a
program, and thus you violated the meaning of the words as he would
use them.
This is because your logic is built on fantasy and lies.
Nope, YOUR logic is based on fantasy and lies, as I have pointed out.
Do you see anywhere in his writing of this problem which even emplies
that DD doesn;'t need to be the representation of a complete program?
That is can "change" the code it runs based on the decider creating a
hypothetical version of itself?
Sorry, you are just proving yourself to be an ignorant pathological
liar that is too stupid to learn the meaning of the words he uses,
even when they are explained to him.
On 5/8/25 1:02 AM, olcott wrote:
On 5/7/2025 10:48 PM, Richard Damon wrote:
On 5/7/25 11:15 PM, olcott wrote:Termination analyzers can be and have been applied to C functions.
On 5/7/2025 9:09 PM, Richard Damon wrote:
On 5/7/25 11:31 AM, olcott wrote:
On 5/7/2025 5:55 AM, Richard Damon wrote:
On 5/6/25 10:09 PM, olcott wrote:
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only if) thei.e. it is found to map something other than the above function
mapping FROM INPUTS IS COMPUTED.
which is a contradiction.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT you
simply take that same quote from a computer science textbook as the
infallible word-of-God.
Every function computed by a model of computation must apply a specificabout.All you are doing is showing that you don't understand proof by >>>>>>>>>>>>>>> contradiction,Not at all. The COMPUTER SCIENCE of your requirements IS WRONG! >>>>>>>>>>>>> No, YOU don't understand what Computer Science actually is talking
sequence of steps that are specified by the model to the actual finite
string input.
You are very confused. An algorithm or program computes a function. >>>>>>>>>>>
Nothing computes a function unless it applies a specific
set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function. >>>>>>>>>>
Right, so HHH needs to apply the rules that it was designed with. >>>>>>>>>
And that means it breaks the criteria that you say it needs to do to >>>>>>>>> get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
No, to be a correct emulator it needs to continue until it reaches the end,
It can get the right answer if it emulates the input to the point that >>>>>>> it can show that a
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D >>>>>>>> *would never stop running unless aborted* then
Right, that UTM(D) would never halt.
*would never stop running unless aborted*
Is the hypothetical HHH/DD pair where HHH does not abort.
Nope, can't change DD, it is your hypothetical HHH, which has become >>>>>>> UTM, when given the ORIGINAL DD, which calls the ORIGINAL HHH, as that >>>>>>> code was part of the definition of DD.
HHH bases its decision on what the behavior of DD
would be if a hypothetical version of its own self
never aborted.
In other words, it bases it decision on a LIE.
It bases its decision on exactly what Professor Sipser agreed to.
Nope
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D
*specifies a non-halting sequence of configurations*.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
*simulated D would never stop running unless aborted* then
*H can abort its simulation of D*
*D specifies a non-halting sequence of configurations*
One hypothetical HHH that never aborts and
another different HHH that does abort.
But your Hypothetical HHH wasn't given the right input, because you
never had one since you have admitted that D isn't a program as
required and assumed by Professor Sipser.
But only C functions that represent PROGRAMS, i.e. that include all the
code they will use.
On 2025-05-08 10:49:40 +0000, Richard Damon said:
On 5/8/25 1:02 AM, olcott wrote:
On 5/7/2025 10:48 PM, Richard Damon wrote:
On 5/7/25 11:15 PM, olcott wrote:Termination analyzers can be and have been applied to C functions.
On 5/7/2025 9:09 PM, Richard Damon wrote:
On 5/7/25 11:31 AM, olcott wrote:
On 5/7/2025 5:55 AM, Richard Damon wrote:
On 5/6/25 10:09 PM, olcott wrote:
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make >>>>>>>>>>>>>>>>> no attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and >>>>>>>>>>>>>>>>>>> only if) thei.e. it is found to map something other than the above >>>>>>>>>>>>>>>>>> function
mapping FROM INPUTS IS COMPUTED.
which is a contradiction.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS >>>>>>>>>>>>>>>>> INCORRECT you
simply take that same quote from a computer science >>>>>>>>>>>>>>>>> textbook as the
infallible word-of-God.
Every function computed by a model of computation must >>>>>>>>>>>>> apply a specificNo, YOU don't understand what Computer Science actually is >>>>>>>>>>>>>> talkingAll you are doing is showing that you don't understand >>>>>>>>>>>>>>>> proof byNot at all. The COMPUTER SCIENCE of your requirements IS >>>>>>>>>>>>>>> WRONG!
contradiction,
about.
sequence of steps that are specified by the model to the >>>>>>>>>>>>> actual finite
string input.
You are very confused. An algorithm or program computes a >>>>>>>>>>>> function.
Nothing computes a function unless it applies a specific >>>>>>>>>>> set of rules to its actual input to derive its output.
Anything that ignores its input is not computing a function. >>>>>>>>>>>
Right, so HHH needs to apply the rules that it was designed with. >>>>>>>>>>
And that means it breaks the criteria that you say it needs to >>>>>>>>>> do to get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
No, to be a correct emulator it needs to continue until it
reaches the end,
It can get the right answer if it emulates the input to the
point that it can show that a
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its >>>>>>>>> input D until H correctly determines that its simulated D >>>>>>>>> *would never stop running unless aborted* then
Right, that UTM(D) would never halt.
*would never stop running unless aborted*
Is the hypothetical HHH/DD pair where HHH does not abort.
Nope, can't change DD, it is your hypothetical HHH, which has
become UTM, when given the ORIGINAL DD, which calls the ORIGINAL >>>>>>>> HHH, as that code was part of the definition of DD.
HHH bases its decision on what the behavior of DD
would be if a hypothetical version of its own self
never aborted.
In other words, it bases it decision on a LIE.
It bases its decision on exactly what Professor Sipser agreed to.
Nope
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D >>>>> *specifies a non-halting sequence of configurations*.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
*simulated D would never stop running unless aborted* then
*H can abort its simulation of D*
*D specifies a non-halting sequence of configurations*
One hypothetical HHH that never aborts and
another different HHH that does abort.
But your Hypothetical HHH wasn't given the right input, because you
never had one since you have admitted that D isn't a program as
required and assumed by Professor Sipser.
But only C functions that represent PROGRAMS, i.e. that include all
the code they will use.
A termination analyser could report that termination cannot be proven if
it detects that an undefined function is called or if it cannot determine that that function is never called. Detection of dead code is useful but
not in the scope of the primary purpose of terminatin analysis.
On 5/9/25 3:10 AM, Mikko wrote:
On 2025-05-08 10:49:40 +0000, Richard Damon said:
On 5/8/25 1:02 AM, olcott wrote:
On 5/7/2025 10:48 PM, Richard Damon wrote:
On 5/7/25 11:15 PM, olcott wrote:Termination analyzers can be and have been applied to C functions.
On 5/7/2025 9:09 PM, Richard Damon wrote:
On 5/7/25 11:31 AM, olcott wrote:
On 5/7/2025 5:55 AM, Richard Damon wrote:
On 5/6/25 10:09 PM, olcott wrote:
On 5/6/2025 5:52 PM, Richard Damon wrote:
On 5/6/25 4:37 PM, olcott wrote:
On 5/6/2025 3:22 PM, joes wrote:
Am Tue, 06 May 2025 13:05:15 -0500 schrieb olcott:
On 5/6/2025 5:59 AM, Richard Damon wrote:What does it violate?
On 5/5/25 10:18 PM, olcott wrote:
On 5/5/2025 8:59 PM, dbush wrote:
On 5/5/2025 8:57 PM, olcott wrote:
On 5/5/2025 7:49 PM, dbush wrote:
The above function VIOLATES COMPUTER SCIENCE. You make no attempt toDO COMPUTE THAT THE INPUT IS NON-HALTING IFF (if and only if) thei.e. it is found to map something other than the above function
mapping FROM INPUTS IS COMPUTED.
which is a contradiction.
show how my claim THAT IT VIOLATES COMPUTER SCIENCE IS INCORRECT you
simply take that same quote from a computer science textbook as the
infallible word-of-God.
Every function computed by a model of computation must apply a specificNo, YOU don't understand what Computer Science actually is talkingAll you are doing is showing that you don't understand proof byNot at all. The COMPUTER SCIENCE of your requirements IS WRONG!
contradiction,
about.
sequence of steps that are specified by the model to the actual finite
string input.
You are very confused. An algorithm or program computes a function.
Nothing computes a function unless it applies a specific >>>>>>>>>>>> set of rules to its actual input to derive its output. >>>>>>>>>>>> Anything that ignores its input is not computing a function. >>>>>>>>>>>>
Right, so HHH needs to apply the rules that it was designed with. >>>>>>>>>>>
And that means it breaks the criteria that you say it needs to do to
get the right answer,
And thus it gets the wrong answer.
It needs to emulate DD according to the rules of
the x86 language. This includes emulating itself
emulating DD until it recognizes that if it kept
doing this that DD would never halt.
No, to be a correct emulator it needs to continue until it reaches the end,
It can get the right answer if it emulates the input to the point that
it can show that a
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its >>>>>>>>>> input D until H correctly determines that its simulated D >>>>>>>>>> *would never stop running unless aborted* then
Right, that UTM(D) would never halt.
*would never stop running unless aborted*
Is the hypothetical HHH/DD pair where HHH does not abort.
Nope, can't change DD, it is your hypothetical HHH, which has become >>>>>>>>> UTM, when given the ORIGINAL DD, which calls the ORIGINAL HHH, as that
code was part of the definition of DD.
HHH bases its decision on what the behavior of DD
would be if a hypothetical version of its own self
never aborted.
In other words, it bases it decision on a LIE.
It bases its decision on exactly what Professor Sipser agreed to.
Nope
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D >>>>>> *would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D >>>>>> *specifies a non-halting sequence of configurations*.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>
*simulated D would never stop running unless aborted* then >>>>>> *H can abort its simulation of D*
*D specifies a non-halting sequence of configurations*
One hypothetical HHH that never aborts and
another different HHH that does abort.
But your Hypothetical HHH wasn't given the right input, because you
never had one since you have admitted that D isn't a program as
required and assumed by Professor Sipser.
But only C functions that represent PROGRAMS, i.e. that include all the
code they will use.
A termination analyser could report that termination cannot be proven if
it detects that an undefined function is called or if it cannot determine
that that function is never called. Detection of dead code is useful but
not in the scope of the primary purpose of terminatin analysis.
Yes, but then it hasn't answered the question with a yes/no answer.
The base specification for the problem doesn't allow that. The
practical specification that understands that problem, allows it.
The practical specification then allows an analyzer to be "correct"
even if it answer "I don't know" for every possible input.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 152:30:03 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,821 |