Re: Who here is too stupid to know that DDD correctly simulated,by HHH cannot possibly reach its own return instruction?

On 8/2/24 11:12 PM, olcott wrote:

On 8/2/2024 7:11 PM, Richard Damon wrote:

On 8/2/24 7:29 PM, olcott wrote:
>
NOPE, I am just a fw steps ahead of you and can see where you are going, and close the doors in front of you, which is why you get so upset at me.
>
The flaws in your logic are so transparent, I can see many of your moves before you post them. Of course, the fact you keep on repeating them helps too.

 *If that was true you would not need to dodge the question*
 There are zero flaws in my logic that DDD correctly emulated
by HHH cannot possibly reach its own return instruction.
 void DDD()
{
   HHH(DDD);
   return;
}
 Any attempt by anyone to show flaws would make themselves
look ridiculously foolish, as if they flunked out of a CS
degree. You don't even have any CS degree, I just checked.
 

Nope, you make yourself look foolish by making your claims.
The answer to who is too stupid to know something is YOU, Peter Olcott.
Since it is clear you don't understand what it means to know something.
I will point out that you don't understand how a conversation works. Your question was clearly a retorical question, and those do not actually ask for the question to be answered. Asking a retorical question and then berateing people for not answering just shows that you are a petty person that doesn't understand how the Langugage works.
But, that has already been established.
That you claim you logic has no flaws just proves how utterly ignorant of what you are talking about.
Some of your clear flaws that you just don't seem to understand:
1) The input to a halt decider needs to be a *PROGRAM*, which is a complete description of the algorithm being used and the data it is being given. This means that the program "DDD" includes the contents of the subroutine "HHH"
2) Thus, to describe/represent DDD to HHH, that input must include the code of HHH, and not just DDD. Representations need to be complete, and not based on gathering information from outside the problem statement and inputs.
3) A correcrt emulation/simulaition of something exactly reproduces the FULL behavior of the things emulate/simulated. It is NOT the same thing as deciding on behavior. A correct emulatioin of an infinite loop runs forever, even though a correct decision can (and must) return an answer about what that program does.
4) As such, a given thing can not be BOTH a "Correct Emulator" of an input, and a "Halting Decider" for that input, as they have contradictory behavior for a non-halting input.
5) Correct ... Until ... is NOT correct, but changed to incorrect.
Example: A was on the CORRECT path UNTIL I made a wrong turn; means that I am now on the wrong path. That means correctly emulating untill ... when I abort my emulation, means it is NOT a correct emulator.
6) While it is possible to use PARTIAL emulation to determine the behavior of many programs, the program doing that partial emulation is not the correct emulation that shows the answer is correct.
7) Since the input is a program, and a program includes all the code that it uses, and since you setup has DDD calling the decider directly, you can not use logic that changes that decider, as that changes the input. The alternate version of the decider that you talk about, needs to be put somewhere else with a different name. This is the fault of how you cast your framework.
8) You have also shown that this doesn't work, as the second copy of HHH, namely HHH1 gives a different answer, thus showing either you don' know how to make a correct copy, or the fact that your HHH has a "hidden input" making it not a computation.
9) The fact that you ignore the behavior of the program represented by the input just proves that you don't understand the question you are supposed to be answering because that is LITERALLY the behavior that matter. It doesn't matter how many time you say it can't be, it is, and you are just proving yourself a liar to say it isn't.