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

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

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.