Am Sat, 20 Jul 2024 08:03:50 -0500 schrieb olcott:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

On 7/19/2024 2:49 AM, Mikko wrote:

On 2024-07-17 13:22:09 +0000, olcott said:

On 7/17/2024 2:32 AM, Mikko wrote:

On 2024-07-16 14:04:18 +0000, olcott said:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non
termination of simulating termination analyzer HHH >>>>>>>>>>>>>> necessarily specifies non-halting behavior or it would >>>>>>>>>>>>>> never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in >>>>>>>>>>>>> your argument because you have misdefined what the input is. >>>>>>>>>>>>>

_DDD()
[00002163] 55         push ebp      ; housekeeping [00002164]
8bec       mov ebp,esp   ; housekeeping [00002166] 6863210000
push 00002163 ; push DDD [0000216b] e853f4ffff call 000015c3 >>>>>>>>>>>> ; call HHH(DDD)
[00002170] 83c404     add esp,+04 [00002173] 5d         pop
ebp [00002174] c3         ret Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite string of >>>>>>>>>>>> bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is >>>>>>>>>>> not a string of bytes, but an address (00002163). This points >>>>>>>>>>> to the starting of the code of DDD. But a simulation needs a >>>>>>>>>>> program, not a function calling undefined other functions. >>>>>>>>>>> Therefore, all functions called by DDD (such as HHH) are >>>>>>>>>>> included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

You are talking about the behavior specified by that finite >>>>>>>>>> string. When you say that a finite string *is not* a finite >>>>>>>>>> string you are disagreeing with the law of identity.

Every rebuttal to my work disagrees with one tautology of
another.
It is the fact that DDD calls HHH(DDD) in recursive emulation >>>>>>>>>> that makes it impossible for DDD correctly emulated by HHH to >>>>>>>>>> halt.

Everyone disagrees with this entirely on the basis of the
strawman deception (damned lie) that some other DDD somewhere >>>>>>>>>> else has different behavior.

*They disagree with the following*

In other words the fact that the directly executed DDD halts >>>>>>>>> because the HHH(DDD) that it calls has already aborted its
simulation proves these these two different instances of DDD are >>>>>>>>> in different process states.

BUT must have the same behavior.

The state of needing to abort the input changes after it has >>>>>>>>> already been aborted is the same as the state of being hungry >>>>>>>>> changes after you have had something to eat.

Can't. Since programs are unchanging, their properties can not >>>>>>>> change.

*WRONG* https://en.wikipedia.org/wiki/Self-modifying_code

Your complier cannot produce self-modifying code.

My compiler can accept assembly language that can derive
self-modifying code.

Using non-standard extensions of the language may indeed permit that
unless the program is loaded to a read-only memory. The compiler is
designed so that ordinary programs can be loaded to read-only memory.
Some operating systems prevent programs from modifying themselves as
if the program were in a read-only memory, and typical compilers
compile so that the program can be run under such operating systems.

The bottom line is that an actual TM can modify its own code while it
is running when it has access to its own TM description and it is only
simulated by a UTM. In this case it can modify itself so that its
input is no longer contradictory.

An actual Turing machine cannot change itself. A machine that can
change itself is not a Turing machine.

If you are interested in self-modifying machines you may want to study
LOTOS.

When a Self-Modifying Turing Machine can change itself to become any
other Turing Machine then it can eliminate the pathological
relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is simulated by a
UTM and has access to itself on the UTM tape.
This same idea can be implemented as an emulated x86 program that knows
its own machine address. Self-modifying code is not a new idea. Applying
this to TMs is a new idea.

This is your first mention of selfmodification.

Everyone here is acting like unconventional new ideas are impossible
because they are unconventional and new.

No, but you can't transfer conventional knowledge unchanged.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

On 7/20/24 9:40 AM, olcott wrote:

On 7/20/2024 8:24 AM, joes wrote:

Am Sat, 20 Jul 2024 08:03:50 -0500 schrieb olcott:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

When a Self-Modifying Turing Machine can change itself to become any >>>>> other Turing Machine then it can eliminate the pathological
relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is simulated by a
UTM and has access to itself on the UTM tape.
This same idea can be implemented as an emulated x86 program that knows
its own machine address. Self-modifying code is not a new idea. Applying >>> this to TMs is a new idea.

This is your first mention of selfmodification.

*No eight years ago was mu first mention* August 2016 https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example

(1) Every TM / input pair either halts or fails to halt.
(2) There exists a TM halt decider for every TM / input pair.
(3) A SMTM can become any element of the set of TMs.
(4) Therefore a SMTM can become a halt decider for any TM input pair.

A self modifying TM is merely a TM description of a machine that is
simulated by a UTM such that this TM description has access to its
location on the UTM tape.

It is isomorphic to an x86 program that knows its own machine
address within its x86 emulator.

Everyone here is acting like unconventional new ideas are impossible
because they are unconventional and new.

No, but you can't transfer conventional knowledge unchanged.

WHich is just bad logic from someone who doesn't understand what he is
talking about.

You show your error by making a clear "type error" in your logic. You
say a "self modifying TM is ... a TM description", but TMs are NOT their description (as you point out in your deceptive claim that a TM can not
take a TM as an input).

ALL "self-modifying" programs can be converted to an equivalent version
that doesn't use self-modification.

Also, yout (2) just shows your ignorance of the problem. OF COURSE we
can find a TM that gives the correct answer about a specific TM/input
given. We just need to choose between the machine that answers Halting
always or non-halting always. The problem is to find ONE program that
givens the answer for ALL input.

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