On 8/25/2025 1:11 AM, Richard Heathfield wrote:
Here's my proof that DD halts.
HHH(DD) yields 0 (incorrect claim of non-halting).
DD yields 0 (incorrect claim of non-halting).
When the abort code is removed by a compile
time switch
Therefore HHH(DD)==0 is proven to be correct.
hen I remove the abort code that does not change
the sequence of instructions of DD correctly simulated
by HHH thus this change is of no consequence.
On 8/25/2025 10:17 AM, dbush wrote:How curious, since the abort code is assuredly not a NOP. Apparently
On 8/25/2025 11:13 AM, olcott wrote:
On 8/25/2025 1:11 AM, Richard Heathfield wrote:
On 25/08/2025 05:59, olcott wrote:
On 8/23/2025 11:44 PM, Richard Heathfield wrote:
On 23/08/2025 21:40, olcott wrote:
No it actually never halts.When we eliminate the static data then the fact that DD() never...and DD promptly halts. Odd, that.
halts proves that HHH(DD)==0.
This is where you like to say "tisn't", except that you spell it
"counter-factual".
But when /I/ say "tisn't", I back it up with verifiable acts.
Here's my proof that DD halts.
When the abort code is removed by a compile time
You change the input.
Changing the input is not allowed.
When I remove the abort code that does not change the sequence of instructions of DD correctly simulated by HHH thus this change is of no consequence.
If I were to append NOP instructions at the end of DD and run the
analysis again this too would change the input yet in a way that cannot possibly have any effect on the behavior of DD, thus cannot possibly
have any effect on the analysis of the behavior of DD.
On 8/25/2025 10:18 AM, Richard Heathfield wrote:
On 25/08/2025 16:13, olcott wrote:
Therefore HHH(DD)==0 is proven to be correct.
Great! But when HHH(DD) returns 0, DD halts.
When we disable the abort code then HHH never returns
proving that HHH(DD)==0 is correct.
On 8/25/2025 10:34 AM, joes wrote:I want my simulators not to turn abort code into a NOP.
Am Mon, 25 Aug 2025 10:25:59 -0500 schrieb olcott:
On 8/25/2025 10:17 AM, dbush wrote:
On 8/25/2025 11:13 AM, olcott wrote:
On 8/25/2025 1:11 AM, Richard Heathfield wrote:
On 25/08/2025 05:59, olcott wrote:
On 8/23/2025 11:44 PM, Richard Heathfield wrote:
On 23/08/2025 21:40, olcott wrote:
How curious, since the abort code is assuredly not a NOP. ApparentlyWhen the abort code is removed by a compile time
You change the input.
Changing the input is not allowed.
When I remove the abort code that does not change the sequence of
instructions of DD correctly simulated by HHH thus this change is of
no consequence.
If I were to append NOP instructions at the end of DD and run the
analysis again this too would change the input yet in a way that
cannot possibly have any effect on the behavior of DD, thus cannot
possibly have any effect on the analysis of the behavior of DD.
the input code does not correspond 1-1 to programs. You should pass an
additional parameter to disambiguate.
Changing the input in any way that does not change the sequence of instructions of DD correctly simulated by HHH has no consequence on the halting behavior of DD correctly simulated by HHH.
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
On 8/25/2025 10:59 AM, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer executing.
Counter-factual
computation that halts… “the Turing machine will halt
whenever it enters a final state” (Linz:1990:234)
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
A recursive function
that crashes due to a stack overflow doesn't halt in any
meaningful sense of the word.
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack overflow doesn't halt
in any meaningful sense of the word.
Doesn't exactly keep going, either.
But I hope you take the more general point that there's more ways to
stop a C function than to wait until it is "reaching a simulated
"return" statement final halt state in a finite number of steps".
On 8/25/2025 6:48 PM, André G. Isaak wrote:
On 2025-08-25 17:27, Richard Heathfield wrote:
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack overflow doesn't
halt in any meaningful sense of the word.
Doesn't exactly keep going, either.
No, but the halting problem really distinguishes between those
computations which reach completion in a finite number of steps and
those which continue indefinitely. Remember that the problem was
originally framed in terms of TMs, and TMs don't run inside an
operating system which can pull the rug out from under them in
response to an exception.
A unconditionally recursive function will ultimately stop running on
real hardware because the operating system will detect an exception,
but it doesn't run to completion. Given a system with unbounded
resources, it would continue forever.
André
Exactly !!!
So we must measure halting behavior on the basis of
reaching a final halt state or impossibly reaching a
final halt state like: *DD correctly simulated by HHH*
But I hope you take the more general point that there's more ways to
stop a C function than to wait until it is "reaching a simulated
"return" statement final halt state in a finite number of steps".
On 8/25/2025 6:27 PM, Richard Heathfield wrote:
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer
executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack overflow
doesn't halt in any meaningful sense of the word.
Doesn't exactly keep going, either.
But I hope you take the more general point that there's more
ways to stop a C function than to wait until it is "reaching a
simulated "return" statement final halt state in a finite
number of steps".
Yet we are using C functions only to model the
behavior of Turing machines. The only way for
a Turing machine to halt is to reach a final
halt state.
On 8/25/2025 6:27 PM, Richard Heathfield wrote:
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack overflow doesn't
halt in any meaningful sense of the word.
Doesn't exactly keep going, either.
But I hope you take the more general point that there's more ways to
stop a C function than to wait until it is "reaching a simulated
"return" statement final halt state in a finite number of steps".
Yet we are using C functions only to model the
behavior of Turing machines. The only way for
a Turing machine to halt is to reach a final
halt state.
On 8/25/2025 7:55 PM, Richard Heathfield wrote:
On 26/08/2025 01:31, olcott wrote:
On 8/25/2025 6:27 PM, Richard Heathfield wrote:
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer
executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack overflow
doesn't halt in any meaningful sense of the word.
Doesn't exactly keep going, either.
But I hope you take the more general point that there's more
ways to stop a C function than to wait until it is "reaching
a simulated "return" statement final halt state in a finite
number of steps".
Yet we are using C functions only to model the
behavior of Turing machines. The only way for
a Turing machine to halt is to reach a final
halt state.
Fair point, but then a DD Turing machine can't halt while HHH
is running a simulation of it, because while HHH is running a
simulation of it it's on hold waiting for HHH to report, and
you can't reach a final halt state while you're waiting for a
result from a subroutine. So it all comes down to what HHH
reports, and we all know how that ends.
No you have that incorrectly.
DD correctly simulated by HHH keeps DD and the
simulated HHH stuck in recursive emulation until
the executed HHH kills simultaneously kills all
simulations. A dead HHH does not report to a dead DD.
I invite you (and I suspect you won't bother, but one can but
try) to consider the distinction between the question "does DD
halt?" and the question "does my simulation tell me DD would
halt if I ran it in simulation?"
That is the wrong questions.
The actual question is:
What behavior does the actual input actually specify?
On 8/25/2025 7:55 PM, Richard Heathfield wrote:
On 26/08/2025 01:31, olcott wrote:
On 8/25/2025 6:27 PM, Richard Heathfield wrote:
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer executing. >>>>>>
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack overflow doesn't
halt in any meaningful sense of the word.
Doesn't exactly keep going, either.
But I hope you take the more general point that there's more ways to
stop a C function than to wait until it is "reaching a simulated
"return" statement final halt state in a finite number of steps".
Yet we are using C functions only to model the
behavior of Turing machines. The only way for
a Turing machine to halt is to reach a final
halt state.
Fair point, but then a DD Turing machine can't halt while HHH is
running a simulation of it, because while HHH is running a simulation
of it it's on hold waiting for HHH to report, and you can't reach a
final halt state while you're waiting for a result from a subroutine.
So it all comes down to what HHH reports, and we all know how that ends.
No you have that incorrectly.
DD correctly simulated by HHH keeps DD and the
simulated HHH stuck in recursive emulation until
the executed HHH kills simultaneously kills all
simulations. A dead HHH does not report to a dead DD.
I invite you (and I suspect you won't bother, but one can but try) to
consider the distinction between the question "does DD halt?" and the
question "does my simulation tell me DD would halt if I ran it in
simulation?"
That is the wrong questions.
The actual question is:
What behavior does the actual input actually specify?
This is correctly measured by DD correctly simulated
by HHH. This does specify non halting behavior.
Those two questions are not the same, and they appear to have very
different answers.
On 8/25/2025 8:35 PM, Richard Heathfield wrote:
On 26/08/2025 02:20, olcott wrote:
On 8/25/2025 7:55 PM, Richard Heathfield wrote:
On 26/08/2025 01:31, olcott wrote:
On 8/25/2025 6:27 PM, Richard Heathfield wrote:
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer
executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack overflow
doesn't halt in any meaningful sense of the word.
Doesn't exactly keep going, either.
But I hope you take the more general point that there's
more ways to stop a C function than to wait until it is
"reaching a simulated "return" statement final halt state
in a finite number of steps".
Yet we are using C functions only to model the
behavior of Turing machines. The only way for
a Turing machine to halt is to reach a final
halt state.
Fair point, but then a DD Turing machine can't halt while HHH
is running a simulation of it, because while HHH is running a
simulation of it it's on hold waiting for HHH to report, and
you can't reach a final halt state while you're waiting for a
result from a subroutine. So it all comes down to what HHH
reports, and we all know how that ends.
No you have that incorrectly.
DD correctly simulated by HHH keeps DD and the
simulated HHH stuck in recursive emulation until
the executed HHH kills simultaneously kills all
simulations. A dead HHH does not report to a dead DD.
No you have that incorrectly. I'm not talking about the
behaviour of DD correctly simulated by HHH. I'm talking about
DD's behaviour when it's running, i.e, when it's *not* being
simulated.
Then you are not talking about halt deciders
On 8/25/2025 9:08 PM, Richard Heathfield wrote:
On 26/08/2025 03:04, olcott wrote:
On 8/25/2025 8:35 PM, Richard Heathfield wrote:
On 26/08/2025 02:20, olcott wrote:
On 8/25/2025 7:55 PM, Richard Heathfield wrote:
On 26/08/2025 01:31, olcott wrote:
On 8/25/2025 6:27 PM, Richard Heathfield wrote:
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer
executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack
overflow doesn't halt in any meaningful sense of the word.
Doesn't exactly keep going, either.
But I hope you take the more general point that there's
more ways to stop a C function than to wait until it is
"reaching a simulated "return" statement final halt state
in a finite number of steps".
Yet we are using C functions only to model the
behavior of Turing machines. The only way for
a Turing machine to halt is to reach a final
halt state.
Fair point, but then a DD Turing machine can't halt while
HHH is running a simulation of it, because while HHH is
running a simulation of it it's on hold waiting for HHH to
report, and you can't reach a final halt state while you're
waiting for a result from a subroutine. So it all comes
down to what HHH reports, and we all know how that ends.
No you have that incorrectly.
DD correctly simulated by HHH keeps DD and the
simulated HHH stuck in recursive emulation until
the executed HHH kills simultaneously kills all
simulations. A dead HHH does not report to a dead DD.
No you have that incorrectly. I'm not talking about the
behaviour of DD correctly simulated by HHH. I'm talking about
DD's behaviour when it's running, i.e, when it's *not* being
simulated.
Then you are not talking about halt deciders
Correct. I'm talking about DD. Well done!
I am talking about DD simulated by HHH resulting
in the exact same non-halting behavior as
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H:
On 8/25/2025 10:42 PM, Richard Heathfield wrote:
DD simulated by HHH is of no interest to the Halting Problem.
The Halting Problem only wants to know whether DD halts.
It does not. It needs HHH to compute the mapping from its input
to the actual behavior actually specified by this input.
One way to do that is DD correctly simulated by HHH.
If you want to investigate its behaviour by simulation, *fine*,
but that simulation can only ever be descriptive, not
prescriptive. If your simulation fails to provide the answer
everybody else observes by direct execution, it's the
simulation that's wrong.
Just the opposite.
If the behavior of the simulated input
ever diverges from any other behavior it is the behavior of
the simulated input that counts.
On 8/25/2025 8:35 PM, Richard Heathfield wrote:
On 26/08/2025 02:20, olcott wrote:
On 8/25/2025 7:55 PM, Richard Heathfield wrote:
On 26/08/2025 01:31, olcott wrote:
On 8/25/2025 6:27 PM, Richard Heathfield wrote:
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer executing. >>>>>>>>
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack overflow doesn't >>>>>>> halt in any meaningful sense of the word.
Doesn't exactly keep going, either.
But I hope you take the more general point that there's more ways
to stop a C function than to wait until it is "reaching a
simulated "return" statement final halt state in a finite number
of steps".
Yet we are using C functions only to model the
behavior of Turing machines. The only way for
a Turing machine to halt is to reach a final
halt state.
Fair point, but then a DD Turing machine can't halt while HHH is
running a simulation of it, because while HHH is running a
simulation of it it's on hold waiting for HHH to report, and you
can't reach a final halt state while you're waiting for a result
from a subroutine. So it all comes down to what HHH reports, and we
all know how that ends.
No you have that incorrectly.
DD correctly simulated by HHH keeps DD and the
simulated HHH stuck in recursive emulation until
the executed HHH kills simultaneously kills all
simulations. A dead HHH does not report to a dead DD.
No you have that incorrectly. I'm not talking about the behaviour of
DD correctly simulated by HHH. I'm talking about DD's behaviour when
it's running, i.e, when it's *not* being simulated.
Then you are not talking about halt deciders
that can only report on the actual behavior that
their inputs actually specify.
On 8/25/2025 10:42 PM, Richard Heathfield wrote:
On 26/08/2025 04:13, olcott wrote:
On 8/25/2025 9:08 PM, Richard Heathfield wrote:
On 26/08/2025 03:04, olcott wrote:
On 8/25/2025 8:35 PM, Richard Heathfield wrote:
On 26/08/2025 02:20, olcott wrote:
On 8/25/2025 7:55 PM, Richard Heathfield wrote:
On 26/08/2025 01:31, olcott wrote:
On 8/25/2025 6:27 PM, Richard Heathfield wrote:
On 25/08/2025 21:57, André G. Isaak wrote:
On 2025-08-25 09:59, Richard Heathfield wrote:
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"No, it isn't.
statement final halt state in a finite number of steps. >>>>>>>>>>>>
Halting is defined as coming to a stop and so no longer >>>>>>>>>>>> executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
Here I'm going to have to side with Olcott.
Rather you than me.
A recursive function that crashes due to a stack overflow >>>>>>>>>>> doesn't halt in any meaningful sense of the word.
Doesn't exactly keep going, either.
But I hope you take the more general point that there's more >>>>>>>>>> ways to stop a C function than to wait until it is "reaching a >>>>>>>>>> simulated "return" statement final halt state in a finite
number of steps".
Yet we are using C functions only to model the
behavior of Turing machines. The only way for
a Turing machine to halt is to reach a final
halt state.
Fair point, but then a DD Turing machine can't halt while HHH is >>>>>>>> running a simulation of it, because while HHH is running a
simulation of it it's on hold waiting for HHH to report, and you >>>>>>>> can't reach a final halt state while you're waiting for a result >>>>>>>> from a subroutine. So it all comes down to what HHH reports, and >>>>>>>> we all know how that ends.
No you have that incorrectly.
DD correctly simulated by HHH keeps DD and the
simulated HHH stuck in recursive emulation until
the executed HHH kills simultaneously kills all
simulations. A dead HHH does not report to a dead DD.
No you have that incorrectly. I'm not talking about the behaviour
of DD correctly simulated by HHH. I'm talking about DD's behaviour >>>>>> when it's running, i.e, when it's *not* being simulated.
Then you are not talking about halt deciders
Correct. I'm talking about DD. Well done!
I am talking about DD simulated by HHH resulting
in the exact same non-halting behavior as
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H:
DD simulated by HHH is of no interest to the Halting Problem.
The Halting Problem only wants to know whether DD halts.
It does not. It needs HHH to compute the mapping from its input to the
actual behavior actually specified by this input. One way to do that
is DD correctly simulated by HHH.
If you want to investigate its behaviour by simulation, *fine*, but
that simulation can only ever be descriptive, not prescriptive. If
your simulation fails to provide the answer everybody else observes by
direct execution, it's the simulation that's wrong.
Just the opposite. If the behavior of the simulated input
ever diverges from any other behavior it is the behavior of
the simulated input that counts.
DD halts. If your "correct simulation" disagrees, your "correct
simulation" is incorrect.
On 25/08/2025 16:44, olcott wrote:
<snip>
Halting is defined as reaching a simulated "return"
statement final halt state in a finite number of steps.
No, it isn't.
Halting is defined as coming to a stop and so no longer executing.
Here are a few returnless examples:
abort(); /* halts */
assert(argc < 0); /* halts */
longjmp(mainenv, 42); /* may halt */
void foo(void)
{
foo(); /* halts when it smashes its stack */
}
kill(getpid(), SIGKILL); /* halts */
None of these (except maybe the long goto) reach a return statement, and none of them are simulated,
but they all halt.
On 8/26/2025 2:28 AM, Richard Heathfield wrote:
On 26/08/2025 05:25, olcott wrote:
On 8/25/2025 10:42 PM, Richard Heathfield wrote:
<snip>
DD simulated by HHH is of no interest to the Halting Problem.
The Halting Problem only wants to know whether DD halts.
It does not. It needs HHH to compute the mapping from its
input to the actual behavior actually specified by this input.
The actual behaviour specified by DD is to halt.
It is not the behavior specified by DD that matters.
It is the behavior of the input to HHH(DD) that matters.
One way to derive that actual behavior actually specified
by the input to HHH(DD) is DD emulated by HHH according
to the semantics of the x86 language. That DD cannot possibly
halt.
On 8/26/2025 2:28 AM, Richard Heathfield wrote:
On 26/08/2025 05:25, olcott wrote:
On 8/25/2025 10:42 PM, Richard Heathfield wrote:
<snip>
DD simulated by HHH is of no interest to the Halting Problem.
The Halting Problem only wants to know whether DD halts.
It does not. It needs HHH to compute the mapping from its input to
the actual behavior actually specified by this input.
The actual behaviour specified by DD is to halt.
It is not the behavior specified by DD that matters.
It is the behavior of the input to HHH(DD) that matters.
One way to derive that actual behavior actually specified
by the input to HHH(DD) is DD emulated by HHH according
to the semantics of the x86 language. That DD cannot possibly
halt.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 07:27:00 |
| Calls: | 10,388 |
| Calls today: | 3 |
| Files: | 14,061 |
| Messages: | 6,416,825 |
| Posted today: | 1 |