Sujet : Re: How to write a self-referencial TM?
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theoryDate : 21. May 2025, 12:11:07
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <a4848fa91965a14934134f104535438e94fd3402@i2pn2.org>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla Thunderbird
On 5/21/25 12:41 AM, olcott wrote:
On 5/19/2025 5:39 AM, Mikko wrote:
On 2025-05-16 15:40:29 +0000, olcott said:
>
On 5/16/2025 2:27 AM, Mikko wrote:
On 2025-05-15 16:47:49 +0000, olcott said:
>
On 5/15/2025 11:08 AM, Mike Terry wrote:
On 14/05/2025 18:53, wij wrote:
On Wed, 2025-05-14 at 12:24 -0500, olcott wrote:
On 5/14/2025 11:43 AM, wij wrote:
On Wed, 2025-05-14 at 09:51 -0500, olcott wrote:
On 5/14/2025 12:13 AM, wij wrote:
Q: Write a turing machine that performs D function (which calls itself):
>
void D() {
D();
}
>
Easy?
>
>
>
That is not a TM.
>
It is a C program that exists. Therefore, there must be a equivalent TM.
>
To make a TM that references itself the closest
thing is a UTM that simulates its own TM source-code.
>
How does a UTM simulate its own TM source-code?
>
>
You run a UTM that has its own source-code on its tape.
>
What is exactly the source-code on its tape?
>
>
Every UTM has some scheme which can be applied to a (TM & input tape) that is to be simulated. The scheme says how to turn the (TM + input tape) into a string of symbols that represent that computation.
>
So to answer your question, the "source-code on its tape" is the result of applying the UTM's particular scheme to the combination (UTM, input tape) that is to be simulated.
>
If you're looking for the exact string symbols, obviously you would need to specify the exact UTM being used, because every UTM will have a different answer to your question.
>
>
Mike.
>
These things cannot be investigated in great
depth because there is no fully encoded UTM in
any standard language.
>
Investigations do not need a standard language. For an investigation an
ad hoc language is good enough and usually better.
>
Until I made this concrete people kept assuming that
an input DD could be defined that actually does the
opposite of whatever value that its simulating termination
analyzer HHH returns.
>
That need not and should not be assumed. That can be constructively
proven.
>
Which doesn't matter to any investigation.
>
There are only two ways to try to define a DD
that actually does the opposition of whatever
value that is termination analyzer returns.
Neither of the work.
SUre they do.
int main()
{
DDD() // HHH called from DDD can know nothing of it caller.
}
So? When DDD calls HHH(DDD) its input gives it every thing it needs to be asked about HHH's inpyt.
Your problem is you just can't know the meaning of words, but keep on replacing them with your lies.
HHH can never be asked to answer about "its caller", only about the program represented by "its input", if that happens to be its caller, no problem, it is still being asked about its input.
The fact that the program represented by its input can be a program that uses it is part of what makes the problem tough, and in the case of DD, impossible, but it is a valid construction in Computation Theory.
So, all you are doing is proving your utter ignorance of what you are talking about, and that your native language is just lying.
| Date | Sujet | # | | Auteur |
| 8 Apr 26 | … | | | |
Haut de la page
Les messages affichés proviennent d'usenet.
NewsPortal