Re: Who here understands that the last paragraph is Necessarily true? --- Self-Modifying Turing Machine

Liste des GroupesRevenir à theory 
Sujet : Re: Who here understands that the last paragraph is Necessarily true? --- Self-Modifying Turing Machine
De : mikko.levanto (at) *nospam* iki.fi (Mikko)
Groupes : comp.theory
Date : 20. Jul 2024, 11:01:00
Autres entêtes
Organisation : -
Message-ID : <v7fucc$3fh57$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
User-Agent : Unison/2.2
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.
--
Mikko

Date Sujet#  Auteur
10 Nov 24 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal