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."
>
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*
>
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.
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.
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.
*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.
>
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.
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?
*Maybe you never had any idea what any of those words mean*
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)
to the actual behavior that this input specifies
not any damn thing else.
>
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.
_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]
When DDD is correctly emulated by HHH the ultimate
measure of the correctness of this emulation is the
semantics of the x86 language.
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.
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().
>
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*
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.
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.
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.
By doing this we capture the essence of 5266 pages of
execution trace in about one half of one page of text.
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.
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.
That puts you more in the class of a flat-earther.
-- Copyright 2025 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer
Re: ChatGPT agrees that HHH refutes the standard halting problem proof method
Re: ChatGPT agrees that HHH refutes the standard halting problem proof method