From Newsgroup: comp.ai.philosophy

On 8/9/2025 4:12 PM, Richard Heathfield wrote:

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?

_DD()
[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].

*If you don't know how to do this that is OK*
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 8/21/2025 10:44 AM, Kaz Kylheku wrote:

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 you
describe,

Cite your sources.
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".)

I know that. You taught me that.

I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.

*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

*When Ĥ.embedded_H is based on a UTM*

*Repeats until aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

If Ĥ.embedded_H cannot possibly see the repeating
state then we know something we never knew before:
that Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn would be correct.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2