Re: How do simulating termination analyzers work? ---Truth Maker Maximalism FULL_TRACE

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

Am Fri, 04 Jul 2025 07:34:39 -0500 schrieb olcott:

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

On 2025-07-03 22:11:45 +0000, olcott said:

On 7/2/2025 1:53 AM, Mikko wrote:

On 2025-07-01 11:46:11 +0000, olcott said:

 

It is relevant to the halting problem because no input to a halt
decider can possibly do the opposite of whatever its halt decider
decides.

Only because it is not simulated.
 

Although it is called a description that term is inaccurate.
It leads people to believe that 98% of exactly what it does is close
enough. That DD() *DOES NOT DO* what DD correctly simulated by HHH
does is a key detail *THAT ALWAYS ESCAPES THEM*

What HHH correctly or otherwise simulates is merely an implementation
detail.

It is a detail that defines a partial halt decider that makes the "do
the opposite" code unreachable.

Sounds like a bug.
 

What matters is the beahviour DD specifies.

The behavior that an input specifies is only correctly measured by
correctly simulating this input.

No, what code does when executed. Nobody cares what any random simulator
does, especially when it is known that no simulator can simulate past
a call to itself.

This proves that HHH does simulate itself simulating DDD
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
We can know that HHH does emulate itself emulating
DDD because the first instruction of HHH [00001606]
is reached once when invoked in main() (page 38)
and again (page 47) after DDD simulated by HHH calls
HHH(DDD) [000021de] (page 45).

That would make all programs the same when you prefix
them with that call.
 

It is actually has 100% of all of the details that the machine code of
DD has. The input to HHH(DD) *SPECIFIES*
100% of every detail of the exactly behavior *OF THIS INPUT*

In particular, it specifies whether the direct execution of DD halts or
not.

Partial halt deciders only compute the mapping from their inputs to the
actual behavior that this input actually specifies.

Which HHH doesn't do.
 

A halt decider cannot compute the mapping from its own caller or its own
self. That is just not the way that computation fundamentally works.

Nor does it need to, it gets the code of its caller and itself as input.
 

  Other aspects of the behaivour are not relevant
(but are specified anyway).

 

DDD simulated by HHH according to the actual semantics of the C
programming language GETS STUCK IN RECURSIVE SIMULATION.

That is why simulation alone does not solve the halting problem.

I have never been trying to solve the halting problem.

Oh goodie.
 

That requires a computer program that is omniscient.

Calculating the parity of a number also does.
 

All that I have done is refute the conventional halting problem proof
technique. Once this is accepted as correct I will move on to the next
best proof after that.

Which one is that? And what is your goal if not refuting the halting
theorem?
 

To conquer each proof of the HP one at a time.
The reason that I am doing this is that people
have a fundamentally incorrect understanding
about how truth itself actually works.
Because of these misconceptions there has been no
objective way to divide truth from well crafted lies.
This is causing the rise of the fourth Reich and
the destruction of the planet through climate change.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer