Re: HHH(DDD)==0 is correct

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

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:

>

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

 

If. But here it confuses that with not being able to simulate past the
recursive call.
>

 It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that makes up the PROGRAM, which must include the code of *THE* HHH, or you can't "correctly simulate" the call instruction.
SIn

 If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.
 

But it can, as the call goes into HHH, and you then just simulate the code of HHH.
The problem is that you HHH just always gives up and just returns 0, and thus that is the behavior of *THE* HHH that exists.
If you instead create a different DDD from the different THE HHH that never aborts, then you are correct, that actually correct simulation will never reach the end, but continue forever. Your problem is that this is a DIFFERENT DDD, as to "correctly simulate" the input of DDD, that input *MUST* include the code for HHH, or you are just admitting that you are lying about correctly simulating that input.

int main()
{
   DDD();  // Calls HHH(DDD) which is not accountable
}         // for the behavior of its caller

But *IS* accoutable for the behavior of the input, which happens, in this case, to be the caller.
Yes, in:
void foo() {
    HHH(DDD);
loop: goto loop;
}
int main()
{
    foo();
}
HHH isn't responsible for the non-halting behavior of its caller, but is responsible for the halting behavior of DDD, which does halt because HHH returns and answer.
You just don't understand what the meaning of the terms you are using are.

 

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?

DDD halts.
>

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.

 

*when executed directly, which is what should be simulated. HHH can't.
>

 HHH1(DDD) has the same behavior as the directly executed DDD()

No, DDD doesn't return an answer, HHH1 returns the value 1.
Those are DIFFERENT behavior.
Yes, they both halt, and HHH1 does correctly simulate its input, and the fact that you admit that HHH1 is able to simulate the input means that it MUST include the code of HHH, or else it couldn't do that.

 

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.

 

Uh, the traces both show a call to HHH.
>

 *This one page analysis by Clause.ai sum its up nicely*
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
 

Which begins with your lie, so you are just showing your stupidity.
Sorry, perhaps you should be brought up on charges for the contributing to the mistraining of an AI.