Discussion:
A third line of cancer treatment reversed the growth of the right paracaval lymph node
Add Reply
olcott
2025-02-05 03:38:16 UTC
Reply
Permalink
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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott
2025-02-06 18:26:16 UTC
Reply
Permalink
Post by 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.

When we add a little computer science to this then we
know that the input to HHH does not halt.

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);
}
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott
2025-02-08 05:53:49 UTC
Reply
Permalink
Post by olcott
Post by 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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott
2025-02-08 14:59:11 UTC
Reply
Permalink
Post by olcott
Post by olcott
Post by 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.
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);
}

The source-code of DD and HHH specifies that DD calls
HHH in recursive simulation making it impossible for DD
to terminate normally.

https://github.com/plolcott/x86utm/blob/master/Halt7.c
Disagreeing with source-code is not a smart thing to do.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott
2025-02-09 17:00:28 UTC
Reply
Permalink
Post by olcott
Post by olcott
Post by olcott
Post by olcott
Post by 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.
If you try to explain your view in terms of a line-by-line
execution trace of DD simulated by HHH everyone will see that
your claim has no actual basis what-so-ever and is merely
utterly baseless rhetoric totally bereft of any supporting
reasoning.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott
2025-02-16 03:33:45 UTC
Reply
Permalink
Post by olcott
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.
The execution trace only shows that HHH is unable
to complete its simulation, because HHH is unable
to simulate itself.
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.
So, in other words, Olcott denies verified facts. HHH
generates false negatives, as is verified in
               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.
It is a verified fact that main cannot possibly be
correctly simulated by HHH until its normal
termination.
Indeed, which proves that HHH is unable to simulate
itself correctly.
If this was true then you could point out exactly where
HHH is incorrect.
HHH is supposed to be a decider, i.e. halt and return the
correct value.
The directly executed HHH(DD) always halts and returns a
correct value as soon as it correctly determines that its
input cannot possibly terminate normally.
We were talking about HHH(HHH). If the outer HHH halts
according 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.
I am not going to ever talk about that.
Oh goody, you’re never getting anywhere if you reject corrections.
I reject infinite deflection away from the point. The absolute
single-mined focus point is that DD correctly simulated by HHH
cannot possible terminate normally.
That IS the point. DD does nothing else than call HHH.
Since there is a 5% chance that the treatment I will have next
month
will kill me and this treatment is my only good chance I will
totally ignore anything that diverges from the point.
Ok, I will wait a month then.
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.
All of the people that think it should map the behavior of a non-input
have always been wrong.
What is the non-input?
int main()
{
   DD();    // Is not an input to HHH
   HHH(DD)  // Is an input to HHH
{
The input is DD, and its behaviour is that it halts.
HHH’s simulation is not correct by definition.
What is the difference in the finite string that describes the first DD
and the finite string that describes the second DD?
The first instance of recursion is not exactly the same as subsequent
instances of the exact same sequence of recursive invocations.

It is the same with recursive simulations. When the second recursive
invocation has been aborted the first one terminates normally misleading
people into believing that the recursive chain terminates normally.
You do not show a definition if DD, but there can be only one DD, so
there is only one finite string which can have only one behaviour.
That is the behaviour HHH should decide about. If HHH changes the
behaviour of DD, then HHH is not a decider.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott
2025-02-17 14:06:22 UTC
Reply
Permalink
On 2/8/2025 3:57 AM, Fred. Zwarts
Op 08.feb.2025 om 06:53 schreef
On 2/7/2025 7:27 PM, Richard Damon
On 2/7/2025 5:56 PM, Richard
On 2/7/2025 6:20 AM, Richard
On 2/6/25 10:02 PM, olcott
On 2/6/2025 8:21 PM, Richard
On 2/6/25 5:18 PM, olcott
On 2/6/2025 1:51 PM,
On 2/6/25 1:26 PM, olcott
On 2/6/2025 10:52 AM,
Bonita Montero
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.
The execution trace only shows that HHH
is unable to
complete its simulation, because HHH is
unable to
simulate itself.
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.
So, in other words, Olcott denies verified
facts.
HHH generates false negatives, as is
verified in
              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.
It is a verified fact that main cannot
possibly be correctly
simulated by HHH until its normal termination.
Indeed, which proves that HHH is unable to
simulate itself
correctly.
If this was true then you could point out
exactly where HHH is
incorrect.
HHH is supposed to be a decider, i.e. halt and
return the
correct value.
The directly executed HHH(DD) always halts and
returns a correct
value as soon as it correctly determines that
its input cannot
possibly terminate normally.
We were talking about HHH(HHH). If the outer HHH
halts according
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.
I am not going to ever talk about that.
Oh goody, you’re never getting anywhere if you reject
corrections.
I reject infinite deflection away from the point. The
absolute
single-mined focus point is that DD correctly simulated
by HHH cannot
possible terminate normally.
That IS the point. DD does nothing else than call HHH.
Since there is a 5% chance that the treatment I will
have next month
will kill me and this treatment is my only good chance I
will totally
ignore anything that diverges from the point.
Ok, I will wait a month then.
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.
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.
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.
Olcott is again dreaming of a HHH that does not abort. Dreams
are no substitute for reasoning.
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.
Which does not change the fact that simulating HHH does not see
that the simulated HHH would also abort,
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.
Good.
However, Olcott fails to see that it is a failure of HHH to be unable to
simulate a halting program up to the end.
What most everyone fails to understand is that the inability to
accomplish the logically impossible is never any actual sort of failure.
In his citation he deleted my suggestion to change his simulator.
To the best of my knowledge any change would be erroneous.
Instead of aborting the simulation at the call to HHH, he could replace
this call with the correct return value of HHH
If you understand this code then you can see that this is is not what
the code itself specifies.

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

int main()
{
HHH(DD);
}

HHH[0] simulates DD[0]
that calls HHH[1] on its line 1 to simulate DD[1]
that calls HHH[2] on its line 1 to simulate DD[2]
that calls HHH[3] on its line 1 to simulate DD[3]...
(which he seems to know)
and then continue the simulation of DD. This avoids the recursion
introduced by the simulator.
We cannot simply ignore the call to HHH(DD) from DD
and replace this call with different code and construe
this as a correct simulation.

*Here is what you seem to be saying, HHH changes this code*
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

*To this code*
int DD()
{
return 1;
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
Loading...