Re: HHH(DDD)==0 is correct

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

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.
>

 Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
 "ZFC avoids this paradox by using axioms that restrict set formation."

And what does that distraction have to do with halting problem?
I guess you are admitting that you don't have an answer.
And not, "ZFC" doesn't "redefine" how sets are defined, but starts anew, and creates a brand new set theory from scratch.

 

>
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.
>

 I have always told you that
HHH simulates DDD that calls HHH(DDD)
then HHH simulates itself simulating DDD
*You must have no idea what those words mean*

How does it "simulate its input" when it simulates things that aren't part of the input.
That is just a violation of the definitions, showing you don't understand how definitions work.
Your world is just build on lies and equivocations (which are a form of lying). Your "input" both contains and does not contain the code for HHH.
It does not contain it so all version of DDD are the same.
It does contain it so the you can simulate the input.
That is just showing that you "langauge" is just based on lying.

 

>

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,

 No this has never been the case as I have told you hundreds
and hundreds of times. The input to HHH has always been a
pointer to the machine code of DDD in a single block of memory
that includes all of Halt7.obj.

If your total input is just the address, then you can't emulate *ANY* of the code of DDD, as it isn't part of the input.
Just because it is in memory that the decider can access, doesn't make it part of "the input"

 What you are referring to as a program never has been
an actual program that begins in main(). What you have
been referring to as a program is the machine code of
DDD and the machine code of everything that DDD calls.
That has always been there in the single block of memory
of Hlat7.obj.

"Programs" in computation theory don't need to begin with "main".
( guess your problem is you just don't understand what you are talking about.

 

 which must include the code for HHH, and for any HHH that returns an answer, the correct answer will be Halting (1).
>

 The actual execution trace of DDD correctly simulated
by HHH is different than the actual execution trace of
DDD correctly simulated by HHH1.

Then it isn't "correct".
You can't show the first instruction, actually correctly simulate, that difffered between HHH and HHN1, because it doesn't exist.
Note, HHH by trying to do a "high level" simulation of the call to HHH, does it wrong, as it is based on the LIE that the HHH that DDD calls will not return as it gets stuck in infinite recursion, becuase it ignores that HHH *WILL* abort its simulation at the point that it does.

 *I am shocked that Mike cannot see this*
To me this seems like a guy with a computer
science degree that never heard of recursion.

The problem is your claim is just a lie, but YOU have brainwashed ans gaslight yourself to the point you can't see your problem.

 

>
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.
>

 and everything that HHH calls as I have been telling
you many many times and you keep forgetting from one
post to the next.

And thus *ALL* of memory is part of the "input" as you consider it accesable from the input.
Thus, *THE* HHH is defined by the code of HHH in that memory, and that HHH aborts and returns.

 What the F did you think that I mean by HHH simulates
DDD and then simulates itself simulating DDD if itself
is inaccessible to HHH?

That you are just a liar that claimes things that are not?
You keep on switching back and forth between what is in the input, because either answer proves your logic wrong.

 *Maybe you never had any idea what any of those words mean*

Sure I do, you just don't and keep equivocating on what you mean by them.

 

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)
>

 A partial halt decider must compute the mapping
*FROM ITS ACTUAL INPUT* (not one damn thing else)
*FROM ITS ACTUAL INPUT* (not one damn thing else)
*FROM ITS ACTUAL INPUT* (not one damn thing else)

And, if DD is based on the proof program, that means that HHH(DD) must mean that "the input" refers to the program DD when actually run.

 to the actual behavior that this input specifies
not any damn thing else.

Right, and that "actual behavior" is defined by the execution of the program with that code, which means that *ALL* the code, including that of the HHH that it calls, is part of "the input", and thus HHH is FIXED to be *THE* HHH and your hypothetical HHH which changes that memory isn't looking at the same input.

 

>
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.
>

 When functions are computed by Turing Machines directly
executed Turing machines are not in the domain.

Sure they are, via representations.
Just like numbers.

 _DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

Which isn't a simulatable input. PERIOD.

 When DDD is correctly emulated by HHH the ultimate
measure of the correctness of this emulation is the
semantics of the x86 language.

Right, which says that the above is NOT something that can be emulated as an input, it needs the addition of the code of HHH and everything it uses.

 I don't understand why I ever had to say that more
than once if my reviewers are engaging in an honest
dialogue so I concluded that my reviewers are dishonest.

Because you don't actually mean what you say, but are just lying,
The correct emualtion of the DDD above, fixed by including the HHH that you say is the one that exists, HALTS.
Thus HHH, saying it doesn't is just wrong.
PERIOD.
And your lying doesn't change that.

 

The problem is you don't understand what a "program" actually is.
>

 Termination analyzers are applied to C functions that
are not programs that always begin their execution in main().

Sure, but they are only applied to C functions that include all the code they refer to, or the answer is stated based on the actual behaivor of the unspecified code.

 

>

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.
>

 *That has always been counter-factual*

So, what one is it?

 When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).
 The difference is when
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.

And what instruction was the difference?

 HHH doesn't actually abort its simulation of DDD until
after has simulated many hundreds of simulated instructions
later. HHH simulates itself simulating DDD until DDD calls
HHH(DDD) again.

And what differed in that list from what HHH1 saw?
After all,
HHH is simulating HHH simulating DDD, and
HHH1 is simulating HHH simulating DDD
Since HHH simulating DDD always does the same thing, no instruciton differed.

 

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.
>

 We only need to understand that when HHH simulates DDD
and this DDD calls HHH(DDD) that the outer HHH is
simulating itself simulated DDD.

Which doesn't affect any of the instructions being simulated.

 By doing this we capture the essence of 5266 pages of
execution trace in about one half of one page of text.

And we see that no difference occured.

 

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.
>

 When you can't even point out any actual mistake
then your claim that I am intentionally telling
lies is quite nutty.

But I have.
You claim that a difference occured in the traces.
I say there wasn't.
You can't show where the difference in the traces actually occured.
That two traces are identical, is just a fact, and other than showing that the match (to the point of the aborting) is the proof in itself.
If you want to say they differ, you need to be able to point out the difference.

 

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,
>

 https://www.researchgate.net/ publication/336568434_Severe_anthropogenic_climate_change_proven_entirely_with_verifiable_facts
 My paper proves that even billion dollar disinformation teams
cannot possibly explain away the 98 PPM spike in atmospheric
CO2 in the last 70 years. The next fastest 98 PPM spike in the
last 800,000 years took 7537 years, 126-fold slower.

Which doesn't *PROVE* your claim, you just make it.
The problem is that natural science isn't subject to "logical proof" as it always comes down to interpretation of measurements, and not derivation from axioms.
This just shows you have no idea of what you are talking about, becuase you don't really understand how truth, logic, and arguements work.
You fail by trying to use philosophical "logic" in formal systems, where it doesn't apply, and try to use what you think of as "formal logic" in a context where your need to you clear arguement, and accept that "proof" isn't a thing.

 

That puts you more in the class of a flat-earther.