| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 50:06:44 |
| Calls: | 583 |
| Files: | 1,138 |
| Messages: | 111,306 |
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 3:12 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 1:58 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
When the abort code is disabled HHH(DD) never returns and that's why DD >>>>> never stops running. DD never even gets to execute the logic that
"behaves opposite" to HHH(DD)'s verdict.
Finally you are paying attention to this.
The fact that HHH(DD) never returns due to runaway recursion shows that >>>>> HHH isn't a universal decider.
*Yes it does show this in this case*
HHH never even aimed to be a universal decider
it only aimed on reporting on the behavior of
DD correctly simulated by HHH.
To do that, you first have to blow the fuse that
pins down the DD which is to be tested. And /then/
call HHH(DD).
For instance:
int main()
{
(void) HHH(DD); // warm up the decider; discard the result
// DD is now the non-halting one; no more changes take place
if (HHH(DD)) {
...
} else {
...
}
}
I don't understand what you are saying.
I will guess that the first HHH(DD) initializes
the static data on the basis that HHH tests this
data to see if it has been initialized.
This HHH(DD) returns zero, right? It tweaks the static data and then
begins simulating the procedural entry point DD.
It then detects the
runaway behavior and aborrts the simulation, returning 0.
Isn't that right?
Then the second HHH(DD) already has its static data
initialized and see this. That would be an easy fix.
Would it be an easy fix in such a way that it keeps your previous
test cases working?
Without any fix, this second HHH(DD) thinks it is the the simulated one
which must not perform the abort check.
Because HHH(DD) never stops running that does
prove that HHH(DD)==0 would be correct if HHH
could return.
That's like saying is_prime(4) would be correct if only 4 would be 1
smaller than it is.
There is no "would" in math, only "is" or "is not".
Hey, you know, Escher's Waterfall would be a perpetual motion machine,
if only the illusion could jump out of the picture.
On the other hand if the original HHH determined
its halt status for DD by examining the relationship
between DD and HHH it could correctly return 0
without static data.
How can you distinguish "original HHH" from "derived HHH"
without static data? You can make it a parameter.
But then you are making it crystal clear that there
are two deciders.
On 26/08/2025 07:14, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 3:12 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 1:58 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
When the abort code is disabled HHH(DD) never returns and that's
why DD
never stops running.-a DD never even gets to execute the logic that >>>>>> "behaves opposite" to HHH(DD)'s verdict.
Finally you are paying attention to this.
The fact that HHH(DD) never returns due to runaway recursion shows >>>>>> that
HHH isn't a universal decider.
*Yes it does show this in this case*
HHH never even aimed to be a universal decider
it only aimed on reporting on the behavior of
DD correctly simulated by HHH.
To do that, you first have to blow the fuse that
pins down the DD which is to be tested. And /then/
call HHH(DD).
For instance:
-a-a-a int main()
-a-a-a {
-a-a-a-a-a (void) HHH(DD); // warm up the decider; discard the result
-a-a-a-a-a // DD is now the non-halting one; no more changes take place >>>>
-a-a-a-a-a if (HHH(DD)) {
-a-a-a-a-a-a-a-a ...
-a-a-a-a-a } else {
-a-a-a-a-a-a-a-a ...
-a-a-a-a-a }
-a-a-a }
I don't understand what you are saying.
I will guess that the first HHH(DD) initializes
the static data on the basis that HHH tests this
data to see if it has been initialized.
This HHH(DD) returns zero, right? It tweaks the static data and then
begins simulating the procedural entry point DD.
Correct
It then detects the
runaway behavior and aborrts the simulation, returning 0.
Isn't that right?
It doesn't "detect runaway behaviour".-a It matches PO's so-called
"Infinite Recursive Emulation" pattern in its collected trace data, and then, yes, it returns 0.
Then the second HHH(DD) already has its static data
initialized and see this. That would be an easy fix.
Would it be an easy fix in such a way that it keeps your previous
test cases working?
What PO needs to do is keep whatever tests he needs in HHH, along with collecting whatever (trace) data is needed to support those tests, but
do exactly the same collection and testing in each emulation level of HHH:
[SL0]-a HHH(DD)
[SL0]-a ..emulates DD()..
[SL1]-a-a-a DD()
[SL1]-a-a-a ..calls HHH(DD)
[SL1]-a-a-a-a-a HHH(DD)-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // e.g. this HHH [SL1]
[SL1]-a-a-a-a-a ..emulates DD()..-a-a-a-a-a-a-a-a // needs to capture trace data
[SL2]-a-a-a-a-a-a-a DD()-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // for this <=== emulation [SL2]
[SL2]-a-a-a-a-a-a-a ..calls HHH(DD)-a-a-a-a-a-a-a-a // and nested sub-emulations
[SL3,4,5...]
[SL2]-a-a-a-a-a-a-a-a-a HHH(DD)-a-a-a-a-a-a-a-a-a-a-a-a-a-a // but obviously NOT for [SL0] or
[SL1]
[SL2]-a-a-a-a-a-a-a-a-a ..emulates DD()..
[SL3]-a-a-a-a-a-a-a-a-a-a-a DD()
[SL3]-a-a-a-a-a-a-a-a-a-a-a ..calls HHH(DD)
[SL3]-a-a-a-a-a-a-a-a-a-a-a-a-a HHH(DD)
[SL3]-a-a-a-a-a-a-a-a-a-a-a-a-a ..emulates DD()..
HHH /at every emulation level n/ needs to do the same:
--a emulate DD() [SLn+1]
--a collect trace entries from [SLn+1, SLn+2, SLn+3,...]
-a-a into its /own/ local trace table.-a [NOT into a global trace table owned by HHH [SL0]
--a analyse that local trace for abort patterns in [SLn+1, SLn+2, SLn+3,...]
-a-a and watch for [SLn+1] halting "naturally"
--a return 0 or 1 according to above analysis
What's so confusing about that?-a HHH [SLn] is emulating [SLn+1]
instruction by instruction and has complete access to [SLn+1] state, including what instructions are being emulated, and all the memory space
of [SLn+1] (which happens to be its own memory space) including
[SLn+1]'s current stack position and so on.-a Basically, anything [SLn+1]
is doing, HHH [SLn] can see.-a That includes if [SLn+1] itself emulates a nested [SLn+2] emulation, and so on.
[If you're not familiar with PO's emulation, code in HHH emulates a
single instruction in the emulation it's performing by calling a
"primitive op" DebugStep() which is actually implemented in x86utm
code.-a When HHH [SLn+1] performs a DebugStep() the code used is "call <DebugStep notional address>", having previously pushed required
arguments onto its stack.-a All apparent to HHH [SLn]. ]
But PO just can't work it out.-a I thought recently he might have had
some kind of breakthrough, but all the talk of spinning up extra runs of HHH(DD) to "warm up the static data" is crazy (ISTM...).
PO has (I believe) never /wanted/ to make inner HHH emulations
Without any fix, this second HHH(DD) thinks it is the the simulated one
which must not perform the abort check.
different.-a He just didn't know how to implement it properly, and it
came out that way.
I think its reasonable to say PO never thought his way through what he needed his code to do, in order to support his proof refutation goals.
I think he started coding and just added more bits whenever something
didn't do what he expected.-a I think now he's become even more entangled
in a fog of objections from various posters, and has totally lost track
of where he's going.-a He's just tinkering around the edges trying to
keep posters happy, without understanding /why/ they are objecting.
Because HHH(DD) never stops running that does
prove that HHH(DD)==0 would be correct if HHH
could return.
That's like saying is_prime(4) would be correct if only 4 would be 1
smaller than it is.
There is no "would" in math, only "is" or "is not".
Hey, you know, Escher's Waterfall would be a perpetual motion machine, >>>> if only the illusion could jump out of the picture.
On the other hand if the original HHH determined
its halt status for DD by examining the relationship
between DD and HHH it could correctly return 0
without static data.
How can you distinguish "original HHH" from "derived HHH"
without static data? You can make it a parameter.
I don't believe PO would want to distinguish levels of HHH, if he could
work out how to track his nested emulations /properly/, without the
global trace table!
Recently PO has been posting that if he eliminates the global data HHH
will never halt.-a That suggests he's thinking posters are suggesting he just delete the global data variable!-a But then his code will have a compiler error, so he must delete all the code that used that global
data, i.e. all his abort tests!-a Well Duh!-a If he deletes the abort
tests of course HHH never halts.-a Does he really think that was being suggested?
What was suggested was rewriting the tests to /work properly/, e.g. make
the trace table local to HHH.-a I doubt you would take long to get a
design along those lines working.
But then you are making it crystal clear that there
are two deciders.
Right - two deciders is getting silly!-a PO wants one decider, coded correctly so each emulation level behaves identically (as emulations must...).
[..snip remainder..]
Mike.
On 8/26/2025 7:17 PM, Mike Terry wrote:
On 26/08/2025 07:14, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 3:12 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 1:58 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
When the abort code is disabled HHH(DD) never returns and that's >>>>>>> why DD
never stops running.-a DD never even gets to execute the logic that >>>>>>> "behaves opposite" to HHH(DD)'s verdict.
Finally you are paying attention to this.
The fact that HHH(DD) never returns due to runaway recursion
shows that
HHH isn't a universal decider.
*Yes it does show this in this case*
HHH never even aimed to be a universal decider
it only aimed on reporting on the behavior of
DD correctly simulated by HHH.
To do that, you first have to blow the fuse that
pins down the DD which is to be tested. And /then/
call HHH(DD).
For instance:
-a-a-a int main()
-a-a-a {
-a-a-a-a-a (void) HHH(DD); // warm up the decider; discard the result >>>>>
-a-a-a-a-a // DD is now the non-halting one; no more changes take place >>>>>
-a-a-a-a-a if (HHH(DD)) {
-a-a-a-a-a-a-a-a ...
-a-a-a-a-a } else {
-a-a-a-a-a-a-a-a ...
-a-a-a-a-a }
-a-a-a }
I don't understand what you are saying.
I will guess that the first HHH(DD) initializes
the static data on the basis that HHH tests this
data to see if it has been initialized.
This HHH(DD) returns zero, right? It tweaks the static data and then
begins simulating the procedural entry point DD.
Correct
It then detects the
runaway behavior and aborrts the simulation, returning 0.
Isn't that right?
It doesn't "detect runaway behaviour".-a It matches PO's so-called
"Infinite Recursive Emulation" pattern in its collected trace data,
and then, yes, it returns 0.
Which I conclusively prove is runaway behavior
when I disable the abort and DD() never stops running.
Then the second HHH(DD) already has its static data
initialized and see this. That would be an easy fix.
Would it be an easy fix in such a way that it keeps your previous
test cases working?
What PO needs to do is keep whatever tests he needs in HHH, along with
collecting whatever (trace) data is needed to support those tests, but
do exactly the same collection and testing in each emulation level of
HHH:
[SL0]-a HHH(DD)
[SL0]-a ..emulates DD()..
[SL1]-a-a-a DD()
[SL1]-a-a-a ..calls HHH(DD)
[SL1]-a-a-a-a-a HHH(DD)-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // e.g. this HHH [SL1]
[SL1]-a-a-a-a-a ..emulates DD()..-a-a-a-a-a-a-a-a // needs to capture trace data
[SL2]-a-a-a-a-a-a-a DD()-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // for this <=== emulation [SL2]
[SL2]-a-a-a-a-a-a-a ..calls HHH(DD)-a-a-a-a-a-a-a-a // and nested sub-emulations
[SL3,4,5...]
[SL2]-a-a-a-a-a-a-a-a-a HHH(DD)-a-a-a-a-a-a-a-a-a-a-a-a-a-a // but obviously NOT for [SL0] or
[SL1]
[SL2]-a-a-a-a-a-a-a-a-a ..emulates DD()..
[SL3]-a-a-a-a-a-a-a-a-a-a-a DD()
[SL3]-a-a-a-a-a-a-a-a-a-a-a ..calls HHH(DD)
[SL3]-a-a-a-a-a-a-a-a-a-a-a-a-a HHH(DD)
[SL3]-a-a-a-a-a-a-a-a-a-a-a-a-a ..emulates DD()..
HHH /at every emulation level n/ needs to do the same:
--a emulate DD() [SLn+1]
--a collect trace entries from [SLn+1, SLn+2, SLn+3,...]
-a-a-a into its /own/ local trace table.-a [NOT into a global trace table >> owned by HHH [SL0]
--a analyse that local trace for abort patterns in [SLn+1, SLn+2,
SLn+3,...]
-a-a-a and watch for [SLn+1] halting "naturally"
--a return 0 or 1 according to above analysis
What's so confusing about that?-a HHH [SLn] is emulating [SLn+1]
instruction by instruction and has complete access to [SLn+1] state,
including what instructions are being emulated, and all the memory
space of [SLn+1] (which happens to be its own memory space) including
[SLn+1]'s current stack position and so on.-a Basically, anything
[SLn+1] is doing, HHH [SLn] can see.-a That includes if [SLn+1] itself
emulates a nested [SLn+2] emulation, and so on.
[If you're not familiar with PO's emulation, code in HHH emulates a
single instruction in the emulation it's performing by calling a
"primitive op" DebugStep() which is actually implemented in x86utm
code.-a When HHH [SLn+1] performs a DebugStep() the code used is "call
<DebugStep notional address>", having previously pushed required
arguments onto its stack.-a All apparent to HHH [SLn]. ]
If HHH could even know the address of DebugStep()
then it could know its own address and there is
no need for more than one simulation. As soon as
HHH sees DD calling itself its abort criteria is met.
But PO just can't work it out.-a I thought recently he might have had
some kind of breakthrough, but all the talk of spinning up extra runs
of HHH(DD) to "warm up the static data" is crazy (ISTM...).
That seems to be Kaz's idea.
I may have gotten his wrong.
PO has (I believe) never /wanted/ to make inner HHH emulations
Without any fix, this second HHH(DD) thinks it is the the simulated one
which must not perform the abort check.
different.-a He just didn't know how to implement it properly, and it
came out that way.
The key thing is that unless we allocate the
execution_trace data once it gets erased at
every invocation.
I think its reasonable to say PO never thought his way through what he
needed his code to do, in order to support his proof refutation goals.
I have all that totally down pat for at least three years.
Making HHH a pure function of its inputs is the last step.
I think he started coding and just added more bits whenever something
didn't do what he expected.-a I think now he's become even more
entangled in a fog of objections from various posters, and has totally
lost track of where he's going.-a He's just tinkering around the edges
trying to keep posters happy, without understanding /why/ they are
objecting.
It has never been anything like this.
Its all exactly the same as my original design
of at least three years ago. I have changed the
test data to make it easier to understand.
I changed to DDD() because people didn't seem
to understand the execution trace of DD correctly
simulated by HHH. It seems to have turned out to
be the case that they just don't understand
execution traces at all.
Because HHH(DD) never stops running that does
prove that HHH(DD)==0 would be correct if HHH
could return.
That's like saying is_prime(4) would be correct if only 4 would be 1 >>>>> smaller than it is.
There is no "would" in math, only "is" or "is not".
Hey, you know, Escher's Waterfall would be a perpetual motion machine, >>>>> if only the illusion could jump out of the picture.
On the other hand if the original HHH determined
its halt status for DD by examining the relationship
between DD and HHH it could correctly return 0
without static data.
How can you distinguish "original HHH" from "derived HHH"
without static data? You can make it a parameter.
I don't believe PO would want to distinguish levels of HHH, if he
could work out how to track his nested emulations /properly/, without
the global trace table!
All that I need is for one HHH to see the whole
execution trace of all of the levels of DD. I
have that now. Or the whole other method only
requires HHH to know its own machine address.
Recently PO has been posting that if he eliminates the global data HHH
will never halt.-a That suggests he's thinking posters are suggesting
he just delete the global data variable!-a But then his code will have
a compiler error, so he must delete all the code that used that global
data, i.e. all his abort tests!-a Well Duh!-a If he deletes the abort
tests of course HHH never halts.-a Does he really think that was being
suggested?
Disabling the abort has the same practical consequence
as eliminating the trace data. It conclusively proves
that DD() doesn't really halt because it never stops
running.
What was suggested was rewriting the tests to /work properly/, e.g.
make the trace table local to HHH.-a I doubt you would take long to get
a design along those lines working.
HHH needs to either see two complete traces of
DD where it sees the same function called twice
in sequence or it needs to know its own machine
address. Then it sees DD calling itself.
But then you are making it crystal clear that there
are two deciders.
Right - two deciders is getting silly!-a PO wants one decider, coded
correctly so each emulation level behaves identically (as emulations
must...).
Each emulation level has always behaved identically.
It is only HHH seeing these execution traces that changes.
[..snip remainder..]
Mike.
But PO just can't work it out. I thought recently he might have had some kind of breakthrough, but
all the talk of spinning up extra runs of HHH(DD) to "warm up the static data" is crazy (ISTM...).
On 2025-08-27, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
But PO just can't work it out. I thought recently he might have had some kind of breakthrough, but
all the talk of spinning up extra runs of HHH(DD) to "warm up the static data" is crazy (ISTM...).
The extra run was my idea. and the "warm up" terminology mine; I
borrowed that from the area of pseudo-random number generators.
Some pseudo-random number geenerators do not begin generating
sequences with good properties until they are called a bunch of times,
to scramble them (throwing away the results). This is called warm-up.
My purpose behind the warm-up was to get the machinery to blow its fuse,
so then after that the functions no longer cheat. Burning fuses
creates heat, so why not use that term.
PO latched onto it as some new paradigm for doing something unclearly specified.
A top-level call to HHH(DD) might return 0, but if we call that and
discard the result:
(void) HHH(DD); // burn the fuse
if (HHH(DD) == 0) // ... real test
After burning the fuse, things don't go well any more. Unexpectedly, PO
had some "eureka" out of this.
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
On 8/27/2025 7:29 PM, Chris M. Thomasson wrote:
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
Out-Of-Memory error probably not
a blown stack because each recursive
emulation gets a new 64K stack.
On 8/27/2025 6:24 PM, olcott wrote:
On 8/27/2025 7:29 PM, Chris M. Thomasson wrote:
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
Out-Of-Memory error probably not
a blown stack because each recursive
emulation gets a new 64K stack.
So are you trying to say that an out of memory condition means the
program under your test will always halt, or always never halt? ;^)
On 8/27/2025 8:32 PM, Chris M. Thomasson wrote:
On 8/27/2025 6:24 PM, olcott wrote:
On 8/27/2025 7:29 PM, Chris M. Thomasson wrote:
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
Out-Of-Memory error probably not
a blown stack because each recursive
emulation gets a new 64K stack.
So are you trying to say that an out of memory condition means the
program under your test will always halt, or always never halt? ;^)
As someone here pointed out (I think it was Mike) a
blown stack is a non-halting condition because my
C code is intended to model Turing machine behavior.
Thus when DD correctly simulated by HHH hits a blown
stack this proves that DD does not halt.
On 8/27/2025 8:32 PM, Chris M. Thomasson wrote:
On 8/27/2025 6:24 PM, olcott wrote:
On 8/27/2025 7:29 PM, Chris M. Thomasson wrote:
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
Out-Of-Memory error probably not
a blown stack because each recursive
emulation gets a new 64K stack.
So are you trying to say that an out of memory condition means the
program under your test will always halt, or always never halt? ;^)
As someone here pointed out (I think it was Mike) a
blown stack is a non-halting condition because my
C code is intended to model Turing machine behavior.
Thus when DD correctly simulated by HHH hits a blown
stack this proves that DD does not halt.
On 2025-08-27 20:06, olcott wrote:
On 8/27/2025 8:32 PM, Chris M. Thomasson wrote:
On 8/27/2025 6:24 PM, olcott wrote:
On 8/27/2025 7:29 PM, Chris M. Thomasson wrote:
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
Out-Of-Memory error probably not
a blown stack because each recursive
emulation gets a new 64K stack.
So are you trying to say that an out of memory condition means the
program under your test will always halt, or always never halt? ;^)
As someone here pointed out (I think it was Mike) a
blown stack is a non-halting condition because my
C code is intended to model Turing machine behavior.
Thus when DD correctly simulated by HHH hits a blown
stack this proves that DD does not halt.
No. It tells you that if DD halts, it requires a machine with a larger stack.
Andr|-
On 8/27/2025 9:31 PM, Andr|- G. Isaak wrote:
On 2025-08-27 20:06, olcott wrote:
On 8/27/2025 8:32 PM, Chris M. Thomasson wrote:
On 8/27/2025 6:24 PM, olcott wrote:
On 8/27/2025 7:29 PM, Chris M. Thomasson wrote:
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
Out-Of-Memory error probably not
a blown stack because each recursive
emulation gets a new 64K stack.
So are you trying to say that an out of memory condition means the
program under your test will always halt, or always never halt? ;^)
As someone here pointed out (I think it was Mike) a
blown stack is a non-halting condition because my
C code is intended to model Turing machine behavior.
Thus when DD correctly simulated by HHH hits a blown
stack this proves that DD does not halt.
No. It tells you that if DD halts, it requires a machine with a larger
stack.
Andr|-
The reason that that stack is blown in non-terming behavior
[Complete proof that the input to HHH(DD)==0 --- The HP proof is wrong]