Re: A state transition diagram proves ... GOOD PROGRESS

Liste des GroupesRevenir à s logic 
Sujet : Re: A state transition diagram proves ... GOOD PROGRESS
De : noreply (at) *nospam* example.org (joes)
Groupes : comp.theory sci.logic
Date : 18. Oct 2024, 18:00:38
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <0280e32ff3acd1fff59f9637f14bf309150878b4@i2pn2.org>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Pan/0.145 (Duplicitous mercenary valetism; d7e168a git.gnome.org/pan2)
Am Fri, 18 Oct 2024 11:39:52 -0500 schrieb olcott:
On 10/18/2024 9:41 AM, joes wrote:
Am Fri, 18 Oct 2024 09:10:04 -0500 schrieb olcott:
On 10/18/2024 6:17 AM, Richard Damon wrote:
On 10/17/24 11:47 PM, olcott wrote:
On 10/17/2024 10:27 PM, Richard Damon wrote:
On 10/17/24 9:47 PM, olcott wrote:
On 10/17/2024 8:13 PM, Richard Damon wrote:
On 10/17/24 7:31 PM, olcott wrote:
 
When DDD is correctly emulated by HHH according to the semantics
of the x86 language DDD cannot possibly reach its own machine
address [00002183] no matter what HHH does.
+-->[00002172]-->[00002173]-->[00002175]-->[0000217a]--+
 
Except that 0000217a doesn't go to 00002172, but to 000015d2
 
The Emulating HHH sees those addresses at its begining and then never
again.
Then the HHH that it is emulating will see those addresses, but not
the outer one that is doing that emulation of HHH.
And so on.
Which HHH do you think EVER gets back to 00002172?
What instruction do you think that it emulates that would tell it to
do so?
At best the trace is:
00002172 00002173 00002175 0000217a conditional emulation of 00002172
conditional emulation of 00002173 conditional emulation of 00002175
conditional emulation of 0000217a CE of CE of 00002172 ...
OK great this is finally good progress.
The more interesting part is HHH simulating itself, specifically the
if(Root) check on line 502.
That has nothing to do with any aspect of the emulation until HHH has
correctly emulated itself emulating DDD.
What? That is part of HHH, not DDD.

and if HHH decides to abort its emulation, it also should know that
every level of condition emulation it say will also do the same
thing,
If I understand his words correctly Mike has already disagreed with
this.
He hasn't.

Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
  > Obviously a simulator has access to the internal state (tape
  > contents etc.) of the simulated machine. No problem there.
This seems to indicate that the Turing machine UTM version of HHH can
somehow see each of the state transitions of the DDD resulting from
emulating its own Turing machine description emulating DDD.
Of course. It needs to, in order to simulate it. Strictly speaking it
has no idea of its simulation of a simulation two levels down, only of
the immediate simulation; the rest is just part of whatever program the
simulated simulator is simulating, which happens to be itself.
 From the concrete execution trace of DDD emulated by HHH
according to the semantics of the x86 language people with sufficient
technical competence can see that the halt status criteria that
professor Sipser agreed to has been met.

     If emulating termination analyzer HHH emulates its input DDD
     until HHH determines that
     its emulated DDD would never stop running unless aborted ...
But it would.

*Joes can't seem to understand this*
Only the outer-most HHH meets its abort criteria first, thus unless it
aborts as soon as it meets this criteria none of them will ever abort.
This is very simple to understand. Almost as simple as: even if only
the outermost HHH didn't abort, it would still halt,
Yet that is based on the factually incorrect assumption that every
instance of HHH does not use the exact same machine code.
Same as the outer HHH returning that the inner ones wouldn't.

since it is simulating a halting program: the nested version will
abort.
and thus the call HHH at 0000217a will be returned from, > and HHH
has no idea what will happen after that, so it KNOWS it is ignorant
of the answer.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

Date Sujet#  Auteur
18 Oct 24 * Re: A state transition diagram proves ... GOOD PROGRESS21olcott
18 Oct 24 +* Re: A state transition diagram proves ... GOOD PROGRESS7joes
18 Oct 24 i`* Re: A state transition diagram proves ... GOOD PROGRESS6olcott
18 Oct 24 i +- Re: A state transition diagram proves ... GOOD PROGRESS --- I only wanted to cross post this key break through once.1olcott
18 Oct 24 i +- Re: A state transition diagram proves ... GOOD PROGRESS1joes
19 Oct 24 i `* Re: A state transition diagram proves ... GOOD PROGRESS3Richard Damon
19 Oct 24 i  `* Re: A state transition diagram proves ... GOOD PROGRESS2olcott
19 Oct 24 i   `- Re: A state transition diagram proves ... GOOD PROGRESS1Richard Damon
19 Oct 24 `* Re: A state transition diagram proves ... GOOD PROGRESS13Richard Damon
19 Oct 24  `* THREE DIFFERENT QUESTIONS12olcott
19 Oct 24   `* Re: THREE DIFFERENT QUESTIONS11Richard Damon
20 Oct 24    `* Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L10olcott
21 Oct 24     `* Re: Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L9Richard Damon
21 Oct 24      `* Re: Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L8olcott
21 Oct 24       +* Re: Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L6Mikko
21 Oct 24       i`* Re: Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L5olcott
21 Oct 24       i `* Re: Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L4Richard Damon
22 Oct 24       i  `* Re: Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L3olcott
22 Oct 24       i   +- Re: Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L1Richard Damon
22 Oct 24       i   `- Re: Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L1Mikko
21 Oct 24       `- Re: Deriving X from the finite set of FooBar preserving operations --- membership algorithm for X in L1Richard Damon

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal