On 09/08/2025 21:46, olcott wrote:
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
You get the wrong numbers out. It don't get much more flawed than that.
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1.
Those are your only two possible results: it stops, or it doesn't. If
you get the wrong one, your emulation is broken.
Ah so you are dishonest. That is what I expected.
WHAT?
On 09/08/2025 22:22, olcott wrote:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
You get the wrong numbers out. It don't get much more flawed than
that.
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1.
Those are your only two possible results: it stops, or it doesn't.
If you get the wrong one, your emulation is broken.
Ah so you are dishonest. That is what I expected.
WHAT?
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line
knowing that each time HHH is called it creates a
separate process context to emulate an instance of
DD and then emulate an instance of itself emulating
DD when DD calls HHH(DD).
Within this you must show exactly how the original
emulated DD reaches past its own machine address of
[0000216b].
Why?
Haven't you already done it?
you will have proved that emulation is a flawed technique,
On 09/08/2025 23:38, olcott wrote:
Until you bother to put in the effort to understand
that the behavior of DD correctly simulated by HHH
is different than the behavior of the directly executed
DD() you will not be able to begin to understand the
next step of my proof.
Since your prerequisite is manifestly absurd, I don't see anyone understanding your proof any time soon.
On 8/9/2025 7:25 PM, olcott wrote:>>
Until it stops simulating the behavior of the
simulated input is identical to that simulated
by a UTM because Ĥ.embedded_H is based on a UTM.
And because it stops its simulation is non definitive.
That you refuse to understand the
*recursive simulation non-halting behavior pattern*
makes all of your rebuttals baseless.
That the pattern exists in the halting program DDD means it is not a non-halting pattern.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't the
real issue; if anything it's a distraction. The real issue is what
happens after HHH has made its decision and returned.
Disclaimer: I do not fully understand olcott's arguments, and I
have not analyzed his code.
olcott seems to be claiming that his simulator performs correct
simulations, while simultaneously acknowledging that it does not.
He might have a less obviously invalid argument if he stopped
claiming that his "simulator" is really a perfect simulator, or
used a different word than "simulator" to describe it. He also
makes arguments based on how C code should behave, when he's clearly
writing code that goes beyond what the C standard guarantees; these
arguments would be more nearly valid if he acknowledged that he's
not writing valid C, and defined the characteristics of the C-like
language he's using.
Imagine that you want to create an algorithm that, given a
representation of any procedure/input pair as input, correctly
determines whether the argument represents a halting algorithm
or not. This is obviously easy enough to do in limited cases: `printf("hello\n");` halts, and `while (1){}` doesn't. But you
want to make that determination for all possible inputs. And you
think that the proofs that this is impossible are incorrect.
A correct algorithm cannot work by correctly simulating its input
algorithm to completion. A halt decider must halt and give a correct
result. Correct simulation of a non-halting procedure does not halt.
But an algorithm that performs partial simulation of its input
might conceivably do the job. Suppose you can *start* simulating
the input. If that simulation halts in fewer than some specified
number of steps, you're done. If it doesn't, then maybe the
algorithm can perform some analysis on its input and on how the
simulation has proceeded so far, and reliably determine that the
procedure with the given input will or will not eventually halt.
(This is precisely what has been proven to be impossible.)
This is doable for a subset of inputs: those that halt after some
small number of steps, and those like `while (1){}` whose non-halting
is sufficiently obvious by inspection. One can *imagine* extending
the latter to cover all inputs.
Is this what olcott is trying to do?
If you assert that the simulated procedure can have only a finite
number of states, you can run the simulation for a number of steps
equal to the number of states, and determine whether any state has
repeated (impractical if the number of states is, say, 2**524288
for a system whose current state is represented in 64 kilo-octets
of storage). But the halting problem isn't about finite systems.
On 11/08/2025 00:28, Richard Heathfield wrote:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't the
real issue; if anything it's a distraction. The real issue is what
happens after HHH has made its decision and returned.
Right. In terms of a concrete bug, PO's "infinite recursive emulation" test is what leads directly to HHH's incorrect halting decision.
So
this is the bug. Fixes include completely deleting the test, or alternatively replacing it with something that only matches /infinite/ recursive emulation. [Not sure whether that could even be achieved in
any useful fashion?! For sure PO isn't going to do it.]
The effect of all such fixes would be the same - fixed HHH will not
detect any non-halting patterns in its new DD, and so neither HHH nor DD will ever halt. This is no use for PO, but is what all (partial)SHDs inevitably end up doing when analysing their 'impossible input'. The
fixed test might correctly detect non-halting in other inputs, so could
be worthwhile, but not when it comes to analysing DD.
At least it would mean fixed HHH matches the code description PO keeps quoting and asking about! If a claimed PSHD /does/ match a halting/non- halting pattern when analysing its impossible input, as with PO's HHH,
that indicates a bug.
Mike.
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input youCite your sources.
describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a
certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 163:54:46 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
9,181 files (2,736M bytes) |
| Messages: | 2,411,516 |