Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: Self-Modifying Turing Machine
Date: Sat, 20 Jul 2024 13:24:17 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <2c58f962e8efae4d5358494672a22e02e90b4fbb@i2pn2.org>
References: <v6un9t$3nufp$1@dont-email.me> <v7013v$2ccv$1@dont-email.me>
	<v70nt7$61d8$6@dont-email.me>
	<58fc6559638120b31e128fe97b5e955248afe218@i2pn2.org>
	<v71mjh$bp3i$1@dont-email.me>
	<1173a460ee95e0ca82c08abecdefc80ba86646ac@i2pn2.org>
	<v71okl$bvm2$1@dont-email.me>
	<5f6daf68f1b4ffac854d239282bc811b5b806659@i2pn2.org>
	<v71ttb$crk4$1@dont-email.me>
	<60e7a93cb8cec0afb68b3e40a0e82e9d63fa8e2a@i2pn2.org>
	<v721po$h4kr$1@dont-email.me> <v73td3$qkp2$6@dont-email.me>
	<v73tvs$qpi9$1@dont-email.me> <v74n81$13bn1$1@dont-email.me>
	<fafa57d75cf800c930c76530acd72148c77fff87@i2pn2.org>
	<v75ul2$19j7l$5@dont-email.me> <v77s2f$1o4oh$1@dont-email.me>
	<v78gi1$1rc43$6@dont-email.me> <v7d5r0$2t5hr$1@dont-email.me>
	<v7dsit$30pvh$4@dont-email.me> <v7fucc$3fh57$1@dont-email.me>
	<v7gcjm$3hlc2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 20 Jul 2024 13:24:17 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3943878"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 7465
Lines: 125

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.