Re: H(D,D) cannot even be asked about the behavior of D(D) V2

Liste des GroupesRevenir à theory 
Sujet : Re: H(D,D) cannot even be asked about the behavior of D(D) V2
De : F.Zwarts (at) *nospam* HetNet.nl (Fred. Zwarts)
Groupes : comp.theory
Date : 17. Jun 2024, 16:13:30
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v4pgab$l7le$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla Thunderbird
Op 17.jun.2024 om 15:43 schreef olcott:
On 6/16/2024 4:06 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 6/16/2024 9:16 AM, joes wrote:
Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
On 6/16/2024 2:50 AM, Mikko wrote:
>
Whenever a decider is run it answers the question it is made to answer.
Not necessarily. Just because everyone falsely assumes that D correctly
simulated by H must have the same behavior as the directly executed D(D)
does not make this false assumption true.
>
You still need to explain how you can call a simulation that differs from
the behaviour of its input "correct".
>
Indeed, you do.
>
I have proven it many times and this proof is simply over
everyone's heads.
>
Nonsense!  How about, instead of "proving", actually explaining?  If a
simulation differs from its original, it's not a simulation; it's just a
random program.
>
When I ask what your C programming skill level is, this *is not* a
rhetorical question.
>
The question has nothing to do with C programming.
>
typedef void (*ptr)(); // pointer to void function
int H(ptr P, ptr I);
>
int D(int (*x)())
{
   int Halt_Status = H(x, x);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
Unless I make every single detail 100% explicit false
assumptions always slip though the cracks.
>
No.  Every single detail just obfuscates and hides the facts.  The
problem is you have been talking absurdities for so long you have
probably come to believe them.  Nobody else is fooled.
>
The ONLY way to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
programming language.
>
No, that's just a convenient means for obfuscation and expressing
strawmen.
>
There cannot possibly be any H that correctly emulates
the x86 machine code of D according to the semantics
of the x86 programming language such that the emulated
D ever reaches its own emulated final state at machine
address [00001f58].
>
Emulation, Simulation.  By definition a simulator does the same as what
it's simulating.  If it doesn't, it's not a simulator.  Everybody else
understands that.  Why don't you?
>
Are you saying above that simulators are impossible?  Everybody else has
understood for a long time that they're not sensible, here.  But
impossible?
>
[ .... ]
>
Once the above is understood (people quit denying verified facts).
>
You're lying again.  There are no verified facts in the above (which I
snipped).
>
thenn (then and only then) I can show how this applies to Turing
machines.
>
If you'd've simply stuck to turing machines all along, you could have
avoided a lot of the confusion you've got yourself into.  Why not start
talking about turing machines now?
>
 typedef void (*ptr)();
int H0(ptr P);
 void Infinite_Loop()
{
   HERE: goto HERE;
}
 void Infinite_Recursion()
{
   Infinite_Recursion();
}
 void DDD()
{
   H0(DDD);
}
 int main()
{
   H0(Infinite_Loop);
   H0(Infinite_Recursion);
   H0(DDD);
}
 Because people fail to understand that H0 must abort the
correct simulation of every input that would cause itself to
never terminate normally
That might be correct

and that this can be construed as  > non-halting criteria.
 
That is your misunderstanding. It is incorrect as non-halting criteria for the program. It is only an indication of the inability of H0 to simulate itself.

Date Sujet#  Auteur
10 Nov 24 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal