On 2/7/25 8:12 PM, olcott wrote:
On 2/7/2025 5:56 PM, Richard Damon wrote:
On 2/7/25 11:26 AM, olcott wrote:
On 2/7/2025 6:20 AM, Richard Damon wrote:
On 2/6/25 10:02 PM, olcott wrote:
On 2/6/2025 8:21 PM, Richard Damon wrote:
On 2/6/25 5:18 PM, olcott wrote:
On 2/6/2025 1:51 PM, Richard Damon wrote:
On 2/6/25 1:26 PM, olcott wrote:
On 2/6/2025 10:52 AM, Bonita Montero wrote:
Am 05.02.2025 um 16:11 schrieb olcott:
On 2/5/2025 1:44 AM, Bonita Montero wrote:
Am 05.02.2025 um 04:38 schrieb olcott:
This treatment does not typically last very long and >>>>>>>>>>>>>> will be immediately followed by a riskier fourth line >>>>>>>>>>>>>> of treatment that has an initial success rate much higher >>>>>>>>>>>>>> than its non progression mortality rate.
Halting problem solved !
The halting problem proof input does specify non-halting >>>>>>>>>>>> behavior to its decider.
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
LOOOOOOOOL
Anyone that understands the C programming language
sufficiently well (thus not confused by the unreachable
"if" statement) correctly understands that DD simulated
by HHH cannot possibly reach its own return instruction.
And anyone that understand the halting problem knows that isn't >>>>>>>>> the question being asked. The quesiton you NEED to ask is will >>>>>>>>> the program described by the input halt when run?
Since you start off with the wrong question, you logic is just >>>>>>>>> faulty.
Everyone that thinks my question is incorrect is wrong.
It has always been a mathematical mapping from finite
strings to behaviors. That people do not comprehend this
shows the shallowness of the depth of the learned-by-rote
(lack of) understanding.
No, you are just incorreect as you don't know what you are
talking about.
Yes, it is a mapping of the string to the behavior, and that
mapping is DEFINED to be the halting behavior of the program the >>>>>>> string describes.
No this is incorrect. The input finite string specifies
(not merely describes) non halting behavior to its decider.
No, since the definition of "Halting Behavior" is the behavior of
the progran being run.
It may seem that way to people that have learned-by-rote
as their only basis. It is actually nothing like that.
No, that *IS* the definition.
A termination analyzer computes the mapping from finite
strings to the actual behavior that these finite strings
specify. That this is not dead obvious to everyone here
merely proves that learned-by-rote does not involve any
actual comprehension.
And the behavior the finite string specifies is the behavior of running
the program.
On 2/8/25 12:53 AM, olcott wrote:
On 2/7/2025 7:27 PM, Richard Damon wrote:
On 2/7/25 8:12 PM, olcott wrote:
On 2/7/2025 5:56 PM, Richard Damon wrote:
On 2/7/25 11:26 AM, olcott wrote:
On 2/7/2025 6:20 AM, Richard Damon wrote:
On 2/6/25 10:02 PM, olcott wrote:
On 2/6/2025 8:21 PM, Richard Damon wrote:
On 2/6/25 5:18 PM, olcott wrote:
On 2/6/2025 1:51 PM, Richard Damon wrote:
On 2/6/25 1:26 PM, olcott wrote:
On 2/6/2025 10:52 AM, Bonita Montero wrote:
Am 05.02.2025 um 16:11 schrieb olcott:
On 2/5/2025 1:44 AM, Bonita Montero wrote:
Am 05.02.2025 um 04:38 schrieb olcott:
This treatment does not typically last very long and >>>>>>>>>>>>>>>> will be immediately followed by a riskier fourth line >>>>>>>>>>>>>>>> of treatment that has an initial success rate much higher >>>>>>>>>>>>>>>> than its non progression mortality rate.
Halting problem solved !
The halting problem proof input does specify non-halting >>>>>>>>>>>>>> behavior to its decider.
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
LOOOOOOOOL
Anyone that understands the C programming language
sufficiently well (thus not confused by the unreachable >>>>>>>>>>>> "if" statement) correctly understands that DD simulated >>>>>>>>>>>> by HHH cannot possibly reach its own return instruction. >>>>>>>>>>>>
And anyone that understand the halting problem knows that >>>>>>>>>>> isn't the question being asked. The quesiton you NEED to ask >>>>>>>>>>> is will the program described by the input halt when run? >>>>>>>>>>>
Since you start off with the wrong question, you logic is >>>>>>>>>>> just faulty.
Everyone that thinks my question is incorrect is wrong.
It has always been a mathematical mapping from finite
strings to behaviors. That people do not comprehend this
shows the shallowness of the depth of the learned-by-rote
(lack of) understanding.
No, you are just incorreect as you don't know what you are
talking about.
Yes, it is a mapping of the string to the behavior, and that >>>>>>>>> mapping is DEFINED to be the halting behavior of the program >>>>>>>>> the string describes.
No this is incorrect. The input finite string specifies
(not merely describes) non halting behavior to its decider.
No, since the definition of "Halting Behavior" is the behavior of >>>>>>> the progran being run.
It may seem that way to people that have learned-by-rote
as their only basis. It is actually nothing like that.
No, that *IS* the definition.
A termination analyzer computes the mapping from finite
strings to the actual behavior that these finite strings
specify. That this is not dead obvious to everyone here
merely proves that learned-by-rote does not involve any
actual comprehension.
And the behavior the finite string specifies is the behavior of
running the program.
That is verifiably factually incorrect.
The running program has a different execution trace
than the behavior that DD specifies to HHH.
WHere do you get your definition.
Op 09.feb.2025 om 16:18 schreef olcott:
On 2/9/2025 2:13 AM, Fred. Zwarts wrote:
Op 09.feb.2025 om 07:10 schreef olcott:
On 2/8/2025 3:54 PM, Fred. Zwarts wrote:
Op 08.feb.2025 om 15:47 schreef olcott:
On 2/8/2025 3:57 AM, Fred. Zwarts wrote:
Op 08.feb.2025 om 06:53 schreef olcott:
On 2/7/2025 7:27 PM, Richard Damon wrote:
On 2/7/25 8:12 PM, olcott wrote:
On 2/7/2025 5:56 PM, Richard Damon wrote:
On 2/7/25 11:26 AM, olcott wrote:
On 2/7/2025 6:20 AM, Richard Damon wrote:
On 2/6/25 10:02 PM, olcott wrote:
On 2/6/2025 8:21 PM, Richard Damon wrote:
On 2/6/25 5:18 PM, olcott wrote:
On 2/6/2025 1:51 PM, Richard Damon wrote:
On 2/6/25 1:26 PM, olcott wrote:
On 2/6/2025 10:52 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>>> Am 05.02.2025 um 16:11 schrieb olcott:
On 2/5/2025 1:44 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>>>>> Am 05.02.2025 um 04:38 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>> This treatment does not typically last very long and >>>>>>>>>>>>>>>>>>>>>> will be immediately followed by a riskier fourth line >>>>>>>>>>>>>>>>>>>>>> of treatment that has an initial success rate much >>>>>>>>>>>>>>>>>>>>>> higher
than its non progression mortality rate. >>>>>>>>>>>>>>>>>>>>>>
Halting problem solved !
The halting problem proof input does specify non- >>>>>>>>>>>>>>>>>>>> halting
behavior to its decider.
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
LOOOOOOOOL
Anyone that understands the C programming language >>>>>>>>>>>>>>>>>> sufficiently well (thus not confused by the unreachable >>>>>>>>>>>>>>>>>> "if" statement) correctly understands that DD simulated >>>>>>>>>>>>>>>>>> by HHH cannot possibly reach its own return instruction. >>>>>>>>>>>>>>>>>>
And anyone that understand the halting problem knows >>>>>>>>>>>>>>>>> that isn't the question being asked. The quesiton you >>>>>>>>>>>>>>>>> NEED to ask is will the program described by the input >>>>>>>>>>>>>>>>> halt when run?
Since you start off with the wrong question, you logic >>>>>>>>>>>>>>>>> is just faulty.
Everyone that thinks my question is incorrect is wrong. >>>>>>>>>>>>>>>> It has always been a mathematical mapping from finite >>>>>>>>>>>>>>>> strings to behaviors. That people do not comprehend this >>>>>>>>>>>>>>>> shows the shallowness of the depth of the learned-by-rote >>>>>>>>>>>>>>>> (lack of) understanding.
No, you are just incorreect as you don't know what you >>>>>>>>>>>>>>> are talking about.
Yes, it is a mapping of the string to the behavior, and >>>>>>>>>>>>>>> that mapping is DEFINED to be the halting behavior of the >>>>>>>>>>>>>>> program the string describes.
No this is incorrect. The input finite string specifies >>>>>>>>>>>>>> (not merely describes) non halting behavior to its decider. >>>>>>>>>>>>>>
No, since the definition of "Halting Behavior" is the >>>>>>>>>>>>> behavior of the progran being run.
It may seem that way to people that have learned-by-rote >>>>>>>>>>>> as their only basis. It is actually nothing like that.
No, that *IS* the definition.
A termination analyzer computes the mapping from finite
strings to the actual behavior that these finite strings
specify. That this is not dead obvious to everyone here
merely proves that learned-by-rote does not involve any
actual comprehension.
And the behavior the finite string specifies is the behavior of >>>>>>>>> running the program.
That is verifiably factually incorrect.
The running program has a different execution trace
than the behavior that DD specifies to HHH.
If so, then it proves the failure of the simulation. The
simulation aborts too soon on unsound grounds, one cycle before >>>>>>> the normal termination of the program.
This proves that you simply don't have sufficient
understanding of the C programming language.
DD simulated by HHH cannot possibly terminate normally
is a verified fact.
Which proves that HHH fails to make a correct decision about DD's
halting behaviour. All other methods (direct execution, simulation
by a world class simulator, etc.) show that DD halts. But HHH fails >>>>> to see it. Everyone with sufficient understanding of programming
sees that HHH is not correctly programmed when it aborts one cycle
before the simulation would end normally.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
You lack the ability to do the execution trace
of HHH simulating DD calling HHH(DD) simulating DD...
The execution trace only shows that HHH is unable to complete its
simulation, because HHH is unable to simulate itself.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
The above code proves that HHH does simulate itself simulating DD.
That you can't understand this code proves that you lack the
technical basis to review my work.
It turns out that Olcott does not even understand this simple proof that
HHH produces false negatives. HHH is unable to simulate itself up to the normal termination.
Op 16.feb.2025 om 23:00 schreef olcott:
On 2/16/2025 2:16 PM, Fred. Zwarts wrote:
Op 16.feb.2025 om 13:58 schreef olcott:
On 2/16/2025 3:44 AM, Fred. Zwarts wrote:
Op 15.feb.2025 om 20:21 schreef olcott:
On 2/15/2025 2:06 AM, Fred. Zwarts wrote:
Op 14.feb.2025 om 22:18 schreef olcott:
On 2/14/2025 8:01 AM, Fred. Zwarts wrote:Which does not change the fact that simulating HHH does not see >>>>>>> that the simulated HHH would also abort,
Op 14.feb.2025 om 13:48 schreef olcott:
On 2/14/2025 3:53 AM, Fred. Zwarts wrote:Olcott is again dreaming of a HHH that does not abort. Dreams >>>>>>>>> are no substitute for reasoning.
Op 14.feb.2025 om 01:12 schreef olcott:
On 2/13/2025 8:47 AM, Fred. Zwarts wrote:If I close my eyes, so that I do not see the accident, I >>>>>>>>>>> cannot claim that the accident did not happen. That is the >>>>>>>>>>> reasoning of a 2 years old child.
Op 13.feb.2025 om 13:31 schreef olcott:
On 2/13/2025 3:16 AM, joes wrote:
Am Wed, 12 Feb 2025 22:18:32 -0600 schrieb olcott: >>>>>>>>>>>>>>>> On 2/11/2025 2:05 PM, joes wrote:
That IS the point. DD does nothing else than call HHH. >>>>>>>>>>>>>>>Am Tue, 11 Feb 2025 10:19:11 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>> On 2/11/2025 9:23 AM, joes wrote:
Am Mon, 10 Feb 2025 15:38:37 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>> On 2/10/2025 2:48 PM, joes wrote:
Am Mon, 10 Feb 2025 08:46:21 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>> On 2/10/2025 6:52 AM, joes wrote: >>>>>>>>>>>>>>>>>>>>>>> Am Mon, 10 Feb 2025 06:02:48 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>>> On 2/10/2025 5:16 AM, joes wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Am Sun, 09 Feb 2025 13:54:39 -0600 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2/9/2025 1:33 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> Op 09.feb.2025 om 20:04 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/9/2025 12:54 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Op 09.feb.2025 om 18:00 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/9/2025 10:50 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Op 09.feb.2025 om 16:18 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/9/2025 2:13 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Op 09.feb.2025 om 07:10 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/8/2025 3:54 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Op 08.feb.2025 om 15:47 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/8/2025 3:57 AM, Fred. Zwarts >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Op 08.feb.2025 om 06:53 schreef >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/7/2025 7:27 PM, Richard Damon >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/7/25 8:12 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/7/2025 5:56 PM, Richard >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/7/25 11:26 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/7/2025 6:20 AM, Richard >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/6/25 10:02 PM, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/6/2025 8:21 PM, Richard >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/6/25 5:18 PM, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/6/2025 1:51 PM, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/6/25 1:26 PM, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/6/2025 10:52 AM, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bonita Montero
I reject infinite deflection away from the point. The >>>>>>>>>>>>>>>> absoluteOh goody, you’re never getting anywhere if you reject >>>>>>>>>>>>>>>>> corrections.I am not going to ever talk about that.We were talking about HHH(HHH). If the outer HHH >>>>>>>>>>>>>>>>>>>>>>> halts accordingThe directly executed HHH(DD) always halts and >>>>>>>>>>>>>>>>>>>>>>>> returns a correctHHH is supposed to be a decider, i.e. halt and >>>>>>>>>>>>>>>>>>>>>>>>> return theIf this was true then you could point out >>>>>>>>>>>>>>>>>>>>>>>>>> exactly where HHH iscorrectly.It is a verified fact that main cannot >>>>>>>>>>>>>>>>>>>>>>>>>>>> possibly be correctlyHHH generates false negatives, as is >>>>>>>>>>>>>>>>>>>>>>>>>>>>> verified insimple proof that HHH produces false >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> negatives. HHH is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unable to simulate itself up to the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normal termination. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> So, in other words, Olcott denies verified >>>>>>>>>>>>>>>>>>>>>>>>>>>>> facts.The execution trace only shows that HHH >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is unable to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> complete its simulation, because HHH is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unable toWhich proves that HHH fails to make a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct
decision about DD's halting >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behaviour. All other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> methods (direct execution, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation by a world class >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator, etc.) show >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that DD halts. But HHH fails to see >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it. Everyone with >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sufficient understanding of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programming sees that HHH >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not correctly programmed when it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborts one cycle >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before the simulation would end >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> normally.
simulate itself. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It turns out that Olcott does not even >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand this
int main() { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> return HHH(main); >>>>>>>>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>>>>>>>> but he denies it.
He lacks the ability to accept simple >>>>>>>>>>>>>>>>>>>>>>>>>>>>> verified facts, which >>>>>>>>>>>>>>>>>>>>>>>>>>>>> he tries to hide with a lot of irrelevant >>>>>>>>>>>>>>>>>>>>>>>>>>>>> words.
simulated by HHH until its normal termination. >>>>>>>>>>>>>>>>>>>>>>>>>>> Indeed, which proves that HHH is unable to >>>>>>>>>>>>>>>>>>>>>>>>>>> simulate itself
incorrect.
correct value.
value as soon as it correctly determines that >>>>>>>>>>>>>>>>>>>>>>>> its input cannot
possibly terminate normally.
to spec, so does the inner, because it is the >>>>>>>>>>>>>>>>>>>>>>> same. Therefore it
can’t report „non-halting” and be correct. If the
inner HHH
doesn’t halt, it is not a decider.
single-mined focus point is that DD correctly simulated >>>>>>>>>>>>>>>> by HHH cannot
possible terminate normally.
Since there is a 5% chance that the treatment I will >>>>>>>>>>>>>>>> have next monthOk, I will wait a month then.
will kill me and this treatment is my only good chance I >>>>>>>>>>>>>>>> will totally
ignore anything that diverges from the point.
Anyone that knows the C language sufficiently well knows >>>>>>>>>>>>>> that DD correctly simulated by HHH cannot possibly >>>>>>>>>>>>>> terminate normally.
Indeed, which shows the limitation of HHH which makes that >>>>>>>>>>>>> it cannot properly decide about its input, because it must >>>>>>>>>>>>> abort the correct simulation before it sees that the >>>>>>>>>>>>> correct simulation terminates normally.
The correct simulation is only the one that it sees
by definition. it maps ITS INPUT TO THE BEHAVIOR OF THIS INPUT. >>>>>>>>>>>
HHH(DD) maps the finite string input of DD to the behavior >>>>>>>>>> that it specifies. This behavior does include DD repeatedly >>>>>>>>>> calling HHH(DD)
in recursive simulation that that cannot possibly terminate >>>>>>>>>> normally.
The simulating HHH aborts the simulation, closes its eyes and >>>>>>>>> does not see that the simulated HHH also aborts so that the >>>>>>>>> program terminates normally.
It is only your lack of technical competence that makes it seem >>>>>>>> that
(a) The simulated HHH aborts its simulation
after itself is no longer being simulated.
(b) Either the outermost HHH aborts its simulation
of none of them do.
The simulated HHH cannot possibly abort because it can't possibly
get to the point where it sees that it needs to abort because it
is aborted before it gets to this point.
Exactly! So the simulating HHH fails to reach the point where the
simulated HHH aborts and halts. The simulating misses in this way
relevant details of the program given in its input. That is the
reason why it fails. It is unable to see the whole input, because
it gets stuck in recursive simulation of itself.
This is all moot because the executed HHH recognizes this
pattern and correctly reports that its input cannot possibly
terminate normally.
It only reports that the simulation was aborted. Not more, not less.
That you do not understand the term: "terminates normally"
is far less than no rebuttal at all.
So we (Olcott and me) agree that HHH cannot possibly simulate up to the normal termination of the program described by the finite string.
However, Olcott fails to see that it is a failure of HHH to be unable to simulate a halting program up to the end.
In his citation he deleted my suggestion to change his simulator.
Instead of aborting the simulation at the call to HHH, he could replace
this call with the correct return value of HHH
(which he seems to know)
and then continue the simulation of DD. This avoids the recursion
introduced by the simulator.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,010 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 31:07:53 |
| Calls: | 13,187 |
| Calls today: | 1 |
| Files: | 186,574 |
| D/L today: |
199 files (49,090K bytes) |
| Messages: | 3,321,572 |