Re: Bad faith and dishonesty

Op 28.mei.2025 om 20:38 schreef olcott:

On 5/28/2025 1:23 PM, Mr Flibble wrote:

On Mon, 26 May 2025 21:22:55 -0500, olcott wrote:
>

On 5/26/2025 9:09 PM, Richard Damon wrote:

On 5/26/25 6:05 PM, olcott wrote:

On 5/26/2025 3:44 PM, Richard Damon wrote:

On 5/26/25 11:29 AM, olcott wrote:

On 5/26/2025 5:04 AM, Mikko wrote:

On 2025-05-25 14:36:26 +0000, olcott said:
>

On 5/25/2025 1:21 AM, Mikko wrote:

On 2025-05-24 01:20:18 +0000, Mr Flibble said:
>

So much bad faith and dishonesty shown in this forum that myself
and Peter Olcott have to fight against.

>
Everything here seems to be dishonesty and protests against
dishonesty.
If you could remove all dishonesty the protests woud stop, too,
and nothing would be left.

>
_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]
>
Then acknowledge that DDD simulated by HHH according to the rules
of the x86 language cannot possibly reach its own "ret"
instruction final halt state.

>
I have never claimed that your HHH can simulate DDD to from the
beginning to end.
>
>

I am asking you to affirm that I am correct about this point.
DDD simulated by HHH according to the rules of the x86 language
cannot possibly reach its own "ret" instruction final halt state,
thus is correctly rejected as non-halting.
>
>

But you have to affirm first that HHH *IS* a program that does that,
and can't be "changed" to some other program, and that DDD is
"completed" to contain that same code.
>
Of course, once you define that HHH is such a program,

>
Unless HHH(DDD) aborts its emulation of DDD then DDD() and HHH() never
stop running proving that the input to HHH(DDD) SPECIFIES
NON-TERMINATING BEHAVIOR THAT MUST BE ABORTED.
>
>

But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that
DDD() will halt.
>
>

*Termination analyzers PREDICT behavior dip-shit* It is a tautology that
every input that must be aborted to prevent the infinite simulation of
this input DOES SPECIFY NON-HALTING BEHAVIOR.

>
Olcott is claiming:
>

“My SHD detects that the program (e.g., `DDD()`) has an *infinite

recursion structure* and therefore halts early with a decision: non-
halting.”
>
This would mean:
>
* SHD *does not simulate* the entire execution.
* Instead, it performs **analysis** (akin to symbolic execution, static
control flow, or syntactic pattern detection).
* It concludes **before execution completes** that the input program will
never halt.
>
This now resembles modern **termination analyzers** used in:
>
* Formal methods (e.g., Coq, Agda)
* CompCert (verified C compiler)
* Model checking and static analysis tools
>
---
>
### 🔍 What This Means
>
1. **SHD becomes a partial analyzer.**
>
    * It is no longer a classical halt decider (which must be total).
    * It becomes a **sound** (never wrongly claims halting) but
**incomplete** (may fail to decide in some cases) analyzer.
>
2. **Detection ≠ Simulation**
>
    * Damon’s original critique presumes SHD reaches a contradiction
through simulation.
    * But if SHD performs structural detection of recursive constructs
(e.g., unguarded self-calls), it’s operating at the **language or AST
level**, not the runtime level.
>
3. **Olcott's Argument Gets Stronger**
>
    * If SHD statically proves a path leads to infinite recursion, then
halting early is valid.
    * This kind of structural non-termination detection is used in many
safe languages and compilers.
>
---
>
### ⚖️ Remaining Limitations
>
However, the halting problem in its classical sense is **not about some
programs** — it is about **all** programs:
>

There exists no algorithm that, for every program $P$ and input $x$,

decides whether $P(x)$ halts.
>
Olcott’s SHD does **not** refute this proof, because:
>
* SHD avoids the contradiction **by not accepting certain inputs** (i.e.,
pathological ones like `DDD()`).
* This is not a **refutation**, but a **domain restriction** — similar to
how total languages avoid undecidability by design.
>
---
>
### ✅ Summary
>
| Topic            | Classical View                       | Olcott’s
SHD                                |
| ---------------- | ------------------------------------ |
------------------------------------------- |
| Simulation       | Required to define behavior          | Avoided via
structural detection            |
| Decider behavior | Total — must decide for all programs | Partial — only
works on analyzable inputs   |
| DDD self-call    | Causes contradiction in proof        | Detected as
infinite by SHD, then rejected  |
| Result           | Proof of undecidability holds        | SHD reframes
the problem, doesn't refute it |
>
---
>
### 🧩 Final Assessment
>

**If Olcott’s SHD uses static analysis to detect infinite recursion**,

it behaves like modern verification tools and total language analyzers —
which are **sound** but **incomplete**.
>
That’s valid and **useful** — but it does **not refute the Halting Problem
proof**. It sidesteps the contradiction **by changing the semantics** of
what inputs are allowed and how decisions are made.
>
So, Olcott’s SHD is **not wrong**, but its scope is misunderstood: it’s a
*partial, structural halting predictor*, not a general refutation of
undecidability.

 My only aim is to show that the conventional halting
problem proof is wrong.
 When HHH is required to report on the behavior that
its input actually specifies then the counter-example
input to the Halting Problem proofs is correctly
rejected as non-halting.
 When HHH is required to report on behavior
OTHER THAN THE BEHAVIOR THAT ITS INPUT ACTUAL SPECIFIES
then the requirement is incorrect.

And nobody requires otherwise. But the input to HHH is a pointer to DDD. The code of DDD has addresses, e.g. in the call instruction. In this way HHH has access to DDD and all function called by it directly or indirectly. This includes the code that aborts and halts the program.
That is what the input specifies. But HHH has a bug so that it does not see the full specification. That does in no way change the specification of a halting program. Only HHH does not see it, because it is blind for it.
So, the requirement is correct, but HHH is unable to fulfil it.