On 2025-05-12 02:53:36 +0000, olcott said:
...

On 5/11/2025 10:30 PM, olcott wrote:

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

...

There cannot possibly exist an x86 emulator at machine
address 000015d2 that emulates one or more instructions
of DDD according to the rules of the x86 language such
that the correctly emulated DDD reaches its own "ret"
instruction final halt state.

Nothing in the above code says that there is not an emulator
there that does exacatly that. It may skip the emulation of
some or all of its own instructions as those are not
instructionos of DDD.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-12 15:16:05 +0000, olcott said:

On 5/12/2025 3:53 AM, Mikko wrote:

On 2025-05-11 13:21:31 +0000, Mr Flibble said:

Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in >>> the Halting Problem
===========================================================================================


Summary
-------
Flibble argues that the Halting Problem's undecidability proof is built on >>> a category (type) error: it assumes a program and its own representation >>> (as a finite string) are interchangeable. This assumption fails under
simulating deciders, revealing a type distinction through behavioral
divergence. As such, all deciders must respect this boundary, and
diagonalization becomes ill-formed. This reframing dissolves the paradox >>> by making the Halting Problem itself an ill-posed question.

1. Operational Evidence of Type Distinction
-------------------------------------------
- When a program (e.g., `DD()`) is passed to a simulating halt decider
(`HHH`), it leads to infinite recursion.
- This behavior differs from direct execution (e.g., a crash due to a
stack overflow).
- This divergence shows that the program (as code) and its representation >>> (as data) are operationally distinct.
- Therefore, treating them as the same "type" (as Turing's proof does)
leads to inconsistency.

2. Generalization to All Deciders
---------------------------------
- If simulation reveals this type mismatch, then no valid decider can rely >>> on conflating program and representation.
- Diagonalization (e.g., defining D(x) = if H(x,x) then loop else halt)
necessarily crosses the type boundary.
- The contradiction in the Halting Problem arises from this type error,
not from inherent undecidability.
- Hence, the Halting Problem is ill-defined for self-referential input.

3. Comparisons to Other Formal Systems
--------------------------------------
- In type-theoretic systems (like Coq or Agda), such self-reference is
disallowed:
  - Programs must be well-typed.
  - Self-referential constructs like `H(x, x)` are unrepresentable if they >>> would lead to paradox.
- In category theory, morphisms must respect domain/codomain boundaries: >>>   - Reflexive constructions require stratification to avoid logical
inconsistency.

4. Conclusion
-------------
- The Halting Problem depends on self-reference and diagonalization.
- If these constructs are blocked due to type/category errors, the proof >>> breaks down.
- Thus, the Halting Problem isn’t undecidable—it’s malformed when it >>> crosses type boundaries.
- This is not a refutation of Turing, but a reformulation of the problem >>> under more disciplined typing rules.

This model mirrors how Russell’s Paradox was avoided in modern logic: not >>> by solving the contradiction, but by redefining the terms that made the
contradiction possible.

The halting problem has very simple types: the input is two strings
and the output is a bit. The same input can be given to a UTM, so
the input type of the halting problem is the input type of a UTM.
There is no divergence of behaviour: a UTM has only one behaviour for
each input and no other UTM needs be considered.

That ignores a key fact

None of the several facts and other claims mentioned below is identifed
as a key fact.

_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]

One or more instructions of the above function
are correctly emulated by different instances of
pure x86 emulators at machine address 000015d2.

None of them is completely emulated.

None of these correctly emulated DDD instances halts.

The (correctly or othewise or not at all) emulated DDD
halts but HHH does not emulate the halting of DDD.

It is stupidly incorrect to simply assume that the
pathological relationship between HHH and DDD does
not change the behavior of DDD when it is proven
that is does change the behavior.

The pathologial relationship is there either alweys or
never. The relationship does not change. Therefore its
consequences, if any, don't change, either.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-12 15:22:27 +0000, olcott said:

On 5/11/2025 9:48 AM, Mr Flibble wrote:

On Sun, 11 May 2025 15:44:44 +0100, Richard Heathfield wrote:

On 11/05/2025 14:21, Mr Flibble wrote:

This reframing dissolves the paradox by making the Halting Problem
itself an ill-posed question.

"P is a syntactically correct program in some well-defined
Turing-complete language. Does P stop when it is applied to this data
X?" is a meaningful and well-formed question. It's not a Carrollian
question like Olcott's "what time is it, yes or no?" It has a sensible
answer. Either P stops for X, or it doesn't.

It's a question that can in many (but not all) cases be answered quickly >>> and easily enough (and correctly) by humans, often requiring no more
than a brief glimpse. (I say 'not all' only because it is not beyond the >>> wit of mankind to trump up extraordinarily complicated and deliberately
obfuscated code that might easily defeat a programmer's casual glance.)

Some simple examples in K&R C:

main(){}

main(){for(;;);}

main(){puts("Hello");}

#include <stdio.h>
main(){long c=0;int ch; while((ch = getchar()) !=
EOF)++c;printf("%ld\n", c);} /* input: the complete works of Shakespeare >>> */

Any competent C programmer can solve these at a glance - Halts, Loops,
Halts, Halts, in that order - so why shouldn't a programmer be able to?

The Halting Problem asks a more complicated question. ``Is it possible
to write a program that answers the above question for arbitrary P and
arbitrary X?"

Again, the question is meaningful and well-formed. It's syntactically
and grammatically adequate, and anyone claiming not to know what it
means is laying themselves open to a charge of disingenuousness. The
only difficult part is the answer, but there's nothing
self-contradictory or self-referential or paradoxical about the
question.

It is insufficient for the question to be syntactically correct, it needs
to be SEMANTICALLY correct too.

/Flibble

A very important point.
Prolog detects that the Liar Paradox is semantically
incorrect because it specifies the same infinite
recursion as the Halting Problem proofs.

No, it does not. Prolog never says "semantically incorrect". A program
written in Prolog may say so but not a Prolog compiler or an execution environment.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)