On 4/26/24 11:02 PM, olcott wrote:
On 4/26/2024 9:18 PM, Richard Damon wrote:
On 4/26/24 9:43 PM, olcott wrote:
On 4/26/2024 7:26 PM, Richard Damon wrote:
On 4/26/24 8:02 PM, olcott wrote:
On 4/26/2024 12:05 PM, olcott wrote:
On 4/26/2024 11:19 AM, Richard Damon wrote:
On 4/26/24 11:34 AM, olcott wrote:
On 4/26/2024 3:32 AM, Mikko wrote:
On 2024-04-25 14:15:20 +0000, olcott said:
01 int D(ptr x) // ptr is pointer to int function
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 D(D);
12 }
>
That H(D,D) must report on the behavior of its caller is the
one that is incorrect.
>
What H(D,D) must report is independet of what procedure (if any)
calls it.
>
>
Thus when H(D,D) correctly reports that its input D(D) cannot possibly
reach its own line 6 and halt no matter what H does then H can abort its
input and report that its input D(D) does not halt.
>
But since the program D(D) DOES reach its own line 6 when run, because H aborts its simulation and return 0 (since that is what you say this H will do), your statement is PROVEN TO BE A LIE, and you "logic" just a collection of contradictions.
>
>
D simulated by H cannot possibly reach its own line 06 thus when we do
not use the strawman deception to refer to a different D then we know
that D simulated by H never halts.
>
>
The fact that the D(D) executed in main does halt is none of H's
business because H is not allowed to report on the behavior of its
caller.
>
>
In other words, H doesn't need to report on the Behavior of the Program described by its input because it isn't actually a Halt Decider, because you are just a LIAR.
>
>
>
Anyone knowing the theory of computation knows that H is not allowed to
report on the behavior of its caller.
>
In computability theory and computational complexity theory, an
undecidable problem is a decision problem for which it is proved to be
impossible to construct an algorithm that always leads to a correct yes-
or-no answer. https://en.wikipedia.org/wiki/Undecidable_problem
>
The behavior of the simulated D(D) before H aborts its simulation is
different than the behavior of the executed D(D) after H has aborted
its simulation.
>
Every time that a simulated input would never stop running unless
aborted the simulating termination analyzer must abort this simulation
to prevent its own infinite execution.
>
H(D,D) is a case of this H1(D,D) is not a case of this even though
the only difference between H and H1 is that D calls H and D does
not call H1.
>
D simulated by H would never stop running unless aborted and cannot
possibly reach its own line 06 and halt no matter what H does.
>
Thus whenever we do not use the strawman deception to refer to a
different D we know that D simulated by H specifies a non-halting
sequence of configurations to H.
>
>
*This might be a more succinct way of summing that up*
When you understand that D simulated by H cannot possibly reach past its own line 03 (thus cannot possibly halt) no matter what H does and
>
But since H does whatever H does, if H aborts and returns 0, the the direct execution of D, which is what actually matters, DOES get to that point.
>
>
That is another much less useful way to make a universally correct
termination analyzer:
>
int H(ptr x, ptr y)
{
printf("The input program does whatever it does!\n");
return 777; // code for it does what it does
}
>
But that doesn't make H answer the question.
>
I guess you don't understand what I am saying.
>
You said "no matter what H does", but that is a MEANINGLESS statement, because H will do what H is programmed to do, so we don't need to look at other behavior, but just the behavior that H ac
>
>
It can be verified through ordinary software engineering that D(D)
simulated H cannot possibly reach past its own line 03.
>
>
Yes, but that is just a lying RED HERRING, as the question isn't about what H's simulation of the input does, but what the program the input actually represents does when run.
>
YOu are just effectively admitting that you are nothing but a stupid liar that doesn't know what he is talking about.
>
>
It can be verified through computer science that this means that D(D) simulated H by never reaches its own final state and halts whether
H aborts its simulation or not.
>
Which, since this H DOES abort its simulation is trying to introduce a red herring.
>
D(D) simulated by H never halts
D(D) simulated by H never halts
D(D) simulated by H never halts
D(D) simulated by H never halts
D(D) simulated by H never halts
STRAWMAN
The question is does the conputation described by the input halt.
It does.
So, H is wrong.
Its simulation only doesn't reach a final state because it aborts it too soon.
*I say that cats purr and you say no you are wrong dogs do bark*
Well, sincd the question was about the DOG, you are just showing you are answering the wrong question.
And seem to be too stupid to realize what you are doing.
D(D) simulated by H has different behavior than D(D) simulated
by H1 even though the ONLY difference between H and H1 is that
D calls H and D does not call H.
Only because H doesn't "Correctly simulate" the input.
>
This means that D(D) simulated by H unequivocally DOES NOT HALT!
>
Nope, prove you to be a stupid liar.
>
D(D) simulated by H never halts
D(D) simulated by H1 halts
D(D) simulated by H never halts
D(D) simulated by H1 halts
D(D) simulated by H never halts
D(D) simulated by H1 halts
Which shows that H1 correctly simulates its input and H doesn't so H gets the wrong answer.
And that you are so stupid you don't understand the meaning of the words you are using.
Since an aborted simulationm tells you NOTHING about the actual behavior of the program being simulated, and your actual H does abort, then it is just a LIE to represent the behavior of a DIFFERENT PROGRAM that you DEzCEPTIVELY call H that doesn't abort as having ANYTHING to do
>
D simulated by H never reaches past its own line 03
whether H aborts its simulation or not AND YOU KNOW THIS!!!
But THIS H does abort its simulation, so it is wrong.
AND YOU KNOW THIS.
The fact that the TEMPLATE shows all H's are wrong for the input based on the template for thm shows that the problem is uncomputable.
And you are too dumb to understand that.
You seem to not understand what a "Program" actually is.
>
Universally everyone wants to use the strawman deception at this
point and refer to something else besides D(D) simulated by H.
Even these people might agree that D(D) simulated by H DOES NOT HALT.
>
But D(D) simulated by H IS THE STRAWMAN as the question is about the execution of the actual program describe by the input (which needs to FULLY describe the input, and thus includes the H it calls).
>
It may seem that way because 99% believe that yet prior to
Pythagoras 100% of the people "knew" the Earth was flat.
RED HERRING.
Shows how stupid you were.
YOU are the one beliving your own lies.
You are just PROVING you are just a totally ignorant pathological lying idiot to think you can just change the question and get away with it
>
>
>
>
you understand that it is incorrect for H to report on the behavior of its caller: void main() { D(D); } then this necessitates
>
But it MUST report on the program described to it, which is a call to D(D), and it doesn't matter if that is what calls H.
>
So, your claim is just a STUPID LIE.
>
Yes, you can't ask "What is the behavior of the program that called you?"
>
>
Ah so you know the computer science of this, that is great!
>
Right, but that isn't the quest
>
>
But you CAN ask what is the behavior of M(d) even if M(d) happens to call you.
>
So you don't totally understand the computer science of this.
>
So, how does the input "D,D" mean "The program that called you"?
>
Go ahead, explain that.
>
You can't. because you know it is a DAMN LIE.
>
The execution trace of D(D) simulated by H1 is the same as
the execution trace of int main() { D(D); }
The execution trace of D(D) simulated by H is NOT the same
as The execution trace of D(D) simulated by H1 because the
behavior of the simulated D(D) before H has aborted its
simulation is different than behavior of the simulated D(D)
after H has aborted its simulation.
Nope, there is no diffference in the trace up to the point of the abort, which is when H simulates the call to H AND THEN STOPS.
This has been proven to you and you ignore the evidence, JUST LIKE THE ELECTION DENIERS YOU TRY TO PUT DOWN.
>
It is always flat out incorrect for any computable function to
ever report on the behavior of its caller or even the behavior
of itself. The theory of computation DOES NOT ALLOW THAT!
>
REFERENCE?
>
Computable functions are the formalized analogue of the intuitive notion
of algorithms, in the sense that a function is computable if there
exists an algorithm that can do the job of the function, i.e. given an
input of the function domain it can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
So, where does this say that H can't report on the behavior of a function that it is given a description of just because that function happens to call H?
You just don't know what the words you are using mean.
D has a definite algorithm, based on the definite algorithm of the H that you finally declare to be the "Correct Halt Decider"
As such, its description, which describes that FULL algorithm, is in the domain for the Halting Function, and thus is a legal input to give to H.
H must compute that mapping of the behavior of D(D) simulated
by H BEFORE H HAS ABORTED THIS SIMULATION.
Nope, where did it say that?
H, to be a "Halt Decider" must compute the results of the "Halting Function" for the compuation described by its input, which is the behavior of the actual program D(D) which Halts since H(D,D) returns 0 (as you claim to be correct).
Thus H(D,D) returning FALSE did not return the correct answer which would be TRUE, so H is just incorrect.
All you are doing is PROVING you are just a stupid liar that doesn't know a thing about what he is talking about, or how logic actually works.
You have been asked this before, so repeating the claim without a source is an admission that you don't have one and are just admitting it is a deceptive lie to throw the arguement off track.
>
Everyone that is really paying super close attention and really
really understands computable functions already knows this.
So, why couldn't you find a source that says it?
No one else ever spend 20,000 hours going over this material again and
again and again to see these details. I myself just came up with this
(in retrospect) obvious insight only in my 19th year of working on this.
You mean you WASTED 20,000 hours to "invent" a totally bogus fabrication that just shows how stupid you actually are.
>
H(D,D) has different behavior than H1(D,D) even though the only
difference between H and H1 is that D calls H and does not call H1.
>
>
DIFFERENT PROGRAMS ARE DIFFERENT
>
D(D) simulated by H has different behavior than D(D) simulated
by H1 even though the ONLY difference between H and H1 is that
D calls H and D does not call H.
Nope. You are just admitting that H doesn't correctly simulate the input, and that you don't even understand the meaning of the word "correct"
The execution trace of D(D) simulated by H1 is the same as
the execution trace of int main() { D(D); }
Which defines the meaning of a "Correct Simulation"
The execution trace of D(D) simulated by H is NOT the same
as The execution trace of D(D) simulated by H1 because the
behavior of the simulated D(D) before H has aborted its
simulation is different than behavior of the simulated D(D)
after H has aborted its simulation.
What instruction actually simulated came out differently?
Remember, the simulation of the Call instruction needs to simulate the program that is reached by that call instruction.
Original Linz Turing Machine H
H.q0 ⟨M⟩ w ⊢* H.qy // M applied to w halts
H.q0 ⟨M⟩ w ⊢* Hqn // M applied to w does not halt
>
Linz Turing Machine Ĥ
Ĥ.q0 ⟨M⟩ ⊢* embedded_H ⟨M⟩ ⟨M⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨M⟩ ⊢* embedded_H ⟨M⟩ ⟨M⟩ ⊢* Ĥ.qn
>
This exact same reasoning applies to
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ relative to Linz H ⟨Ĥ⟩ ⟨Ĥ⟩
>
Right, embedded_H, to meet the requirements, must go to H^.qy if H^(M) will halt.
embedded_H will also do exactly the same thing as H for the same inputs since they are copies of the exact same algorithm
>
Since H (H^) (H^) goes to Qn (by your claim of correctly saying non-halting) then H^.q0 (H^) => embedded_H (H^) (H^) => H^.qn also and we see that H^ (H^) will halt, and thus embedded_H TO BE CORRECT needed to have gone to H^.qy, but didn't, so embedded_H is wrong, and thus H is wrong.
>
And Peter Olcott is proved to be too dumb to understand that a wrong answer is not correct.
>
Which also makes him a pathological liar.
>
>
>
You are just proving you total lack of understand of the nature of the problem.
>
>
You can't show any error in my actual reasoning the best that
you can show is the conventional wisdom arrives at different
conclusions through different assumptions.
>
Sure I have, many times and you ignore it because you are too stupid and lack the understanding of the fundamenals.
>
The fundamentals that you refer to are simply a different set of
assumptions. I do know these assumptions and I do understand them.
I also understand their philosophical foundational error.
Nope. "Computation Thoery" is a WELL DEFINED FORMAL LOGIC SYSTEM.
There are no "assumptions" about the rules of it.
You are just prov9ng you don't understand what a Formal Logic system actually is, and why you have wasted 20 years of your life on your stupid mistakes working on thing you don't actually understand.
>
>
H can abort its simulation of D and correctly report that D specifies a non-halting sequence of configurations.
>
>
Nope, it CAN'T correctly say that a program that will halt when run is none halting.
>
>
If D simulated by H is unequivocally non-halting and we are
only reporting on the behavior of D simulated by H then I am
definitely correct.
>
WRONG QUESTION so a STRAWMAN.
Within my assumptions (that you believe to be incorrect)
I AM CORRECT.
And since you "assumptions" don't match the definitions of the formal system you claim to be working in (liely because you never bothered to learn them) you ARE INCORRECT.
Your idea that a "Halt Decider" can decide based on its own partial simulation, including looking at behavior of not-its-input (because it looks at D calling an H that isn't the H that it was defined to call) is just invalid.
>
If H is actually required to report on the behavior of its
caller then I am incorrect.
>
H is required to report on the behavior of the program whose description it was given (agree or admit you are just a liar).
>
You simply changed the subject.
If my assumptions are wrong yet my conclusion does correctly
follow from these incorrect assumptions then my conclusion is
correct within these incorrect assumptions.
So, are you admitting that you believe that lies are valid and that it is ok to use unsound logic to claim something correct?
Glad you are putting that out in the open.
That the program happens to call this decider is irrelevent.
> Thus, H *IS* actually required to report on the behavior of a program
that calls it, so you ARE incorrect.
>
No one that is really good at computer science would agreed to that.
Of course they would, at least an one that has actually studied "Computation Theoru" which is where the question (and thus the definition to use) come from.
Note, the thing you seem to be confusing is that there is no possible input that you can give to H that means, answer about whatever program happens to be calling this instance of H.
>
Those words are not very clear.
H is NOT ALLOWED to report on the behavior of the program that calls it
the same way that int sum(int x, int y) { return x + y; } when called
with sum(2,3) IS NOT ALLOWED TO REPORT THE SUM OF 4 + 5.
RED HERRING, and a flat out LIE.
sum(2,3) must answer about the sum of 2 and 3
in the same way, H(D,D) must answer about D(D), the program that its input describe.
YOU are the one doing the equivalent of sum(2,3) returning 4+5 as you are making H(D,D) return the behavior of D'(D') instead of D(D).
So, YOU ARE ADMITTING YOU ARE WRONG>
The fact that D calls H DOES CHANGE THE BEHAVIOR OF D(D)
simulated by H relative to THE BEHAVIOR OF D(D) simulated by H1.
Nope.
You can ignore that into perpetuity yet the facts remain the same.
Yep, you are wrong for all eternity.
My guess is Satan will sit you down to a chalk board and have you simulate by hand every possible version of H to try and find that one that gives the "right" answer.
Undecidability based on epistemological antinomies V2
Re: Undecidability based on epistemological antinomies V2