Re: HHH(DDD)==0 is correct

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:
>

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:
>

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
>

On 6/30/25 2:30 PM, Mr Flibble wrote:
>
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
>
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation.
>
Sorry, not being able to do something doesn't mean you get to redefine
it,
>
You ar4e just showing you are as stupid as he is.

>
No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.
>
/Flibble

>
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

>
Either "no" (encoded as 0) or "yes" (encoded as any other number) is the
wrong asnwer to the quesstion "does DDD specify a halting computation?".

>
That is *not* the actual question.

>
THe actual question is whatever someone asks.

 What is the area of a square circle with a radius of 2?
 

However, if the question is
not "does DDD specify a halting computation?" or the same about some
other computation then it is not in the scope of the halting problem
or the termination problem.
>

 The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

 HHH computes the mapping from its actual inputs to the
behavior specifies by these inputs by correctly simulating
them.

No it doesn't, as you "input" which you say doesn't include the code of HHH, can't be simulated.

 

HHH(DDD) is asked: Does your input specify a computation that halts?
DDD correctly simulated by HHH cannot possibly reach its own "return"
statement final halt state, so NO.

>

 int sum(int x, int y) { return x + y; }
sum(3,4) derives 7 only from its actual inputs.

Right, and for HHH(DDD) the input is the PROGRAM DDD, which must include the code for HHH, and for any HHH that returns an answer, the correct answer will be Halting (1).

 When we make a rule that sum(3,4) must derive
the sum of 5 + 6, then this requirement is wrong.

Right, so we don't, just as it is wrong to derive the answer about the correct simulation of DDD by looking at anything but THAT SPECIFIC DDD and its correct simulation, which also means we need to pass as "the input" all of the code that DDD uses, which included HHH.
Since DDD() will halt, the correct simulation of it will reach the final state (but your HHH can't do that) and thus the only correct answer that HHH can return is Halting (1)

 int main()
{
   DD(); // calls HHH(DD)
}
 Likewise for HHH(DD) to report on the behavior of its caller.

But it isn't being asked about "its caller", its being asked about DDD, which just happens to be its its caller.
The problem is you don't understand what a "program" actually is.

 

THat is the same question if the input specifies the computation as
DDD. If it does not then HHH(DDD) is irrelevant and either the user's
manual of HHH species another input for the purpose or HHH is not
relevant to the halting problem.
>

HHH1(DDD) is asked: Does your input specify a computation that halts?
DDD correctly simulated by HHH1 reaches its own "return" statement final halt state, so YES.

>
The user's manual of HHH1 apparently dpecifies different encoding rules.
>

 The full execution trace of the input to HHH1(DDD) is
different than The full execution trace of the input to HHH(DDD)
because DDD calls HHH in recursive simulation and does not
call HHH1 in recursive simulation.

But no actual instruction actually correctly simulated differs until HHH aborts its simulation.
WHen you look at the actual x86 simulation of all the code executed, this is what you see, as you yourself have proven with the very long traces.
When you abreviate them, to make your arguemnt, you LIE about what HHH does and "simplify" it behavior by ignoring the fact that it WILL abort is simulation, since that is what you have actually defined your HHH to do, and thus your "recursive" simulation is bounded, not infinite.
But of course, you are just too stupid to understand that.

 Claude.ai figured this out on its own
proving that it is smarter than ChatGPT
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
 

Because you LIE to it.
Sorry, it seems that you have lost contact with the idea that only actually true things are true, and not things that we want to be true.
You are worse then the climate deniers you claim to be fighting, at least they can point to actual raw evidence, and it becomes arguments over interpretation, you just claim stuff without any proof,
That puts you more in the class of a flat-earther.