Re: Self-Modifying Turing Machine

From	joes <noreply@example.org>
Newsgroups	comp.theory
Subject	Re: Self-Modifying Turing Machine
Date	2024-07-20 13:24 +0000
Organization	i2pn2 (i2pn.org)
Message-ID	<2c58f962e8efae4d5358494672a22e02e90b4fbb@i2pn2.org> (permalink)
References	(17 earlier) <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>
Show all headers | View raw
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.
Back to comp.theory | Previous | Next — Previous in thread | Next in thread | Find similar
Thread

csiph-web