Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply

Liste des GroupesRevenir à theory 
Sujet : Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theory sci.logic
Date : 22. Jun 2024, 16:53:30
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <v56oha$onl4$9@i2pn2.org>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
On 6/22/24 10:41 AM, joes wrote:
Am Sat, 22 Jun 2024 08:11:25 -0500 schrieb olcott:
On 6/22/2024 4:27 AM, Fred. Zwarts wrote:
Op 21.jun.2024 om 15:01 schreef olcott:
On 6/21/2024 2:44 AM, Fred. Zwarts wrote:
Op 20.jun.2024 om 16:12 schreef olcott:
On 6/20/2024 3:09 AM, Fred. Zwarts wrote:
Op 20.jun.2024 om 02:00 schreef olcott:
 
The question which instruction is incorrectly simulated already shows
your error. The error is not that an instruction is simulated
incorrectly, but that some instruction are not simulated at all.
Why is that already over your head?
It is a verified fact that the behavior that finite string DDD presents
to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that
this call DOES NOT RETURN.
Why are you changing the topic here?
 
It is a verified fact that the behavior that finite string DDD presents
to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) that
this call DOES RETURN.
 DDD by itself always specifies the same behaviour. A better phrasing would
be that the different H's execute it differently; so at least one of them
must be wrong.
Actually, that is part of his problem. He doesn't pin down the behavior of DDD, as it depends on the behavior of HH0, which he won't pin down, as he things that can be variable depending on what he wants.
This is where the non-sense of "an infinite set of decider-input pairs" comes form, which just means he has left the logic of normal programming theory.
For us to ask a decider about an input program, it needs to be A PROGRAM, which means that DDD needs to be tied to a SPECIFIC HH0 with specific behavior.
This means that when he talks about "NO HH0 can ..." it is just double talk that means "HH0 doesn't. ...", since at that point HH0 must be a single defined machine, and DDD fixed to using that single defined machine.
Which is also why his description of the input is incorrect, you can't just list the x86 code of DDD, as it, by reference, includes all the code of HH0, which by his other publications comes out to about 33 pages of code, and even that has some routines stubbed out.
So, he fundamentally is confusing what he is talking about, not knowing what a "program" actually is, and what we can ask a Halting decider to decide on.

 
I don't get why people here insist on lying about verified facts.
They are not true, let alone proven.
 

Date Sujet#  Auteur
10 Nov 24 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal