Re: Defining a correct halt decider

Liste des GroupesRevenir à c theory 
Sujet : Re: Defining a correct halt decider
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theory
Date : 04. Sep 2024, 03:16:46
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <1c88d03e09e0903ecf7620f999f183d3f0ac59e9@i2pn2.org>
References : 1 2 3 4 5
User-Agent : Mozilla Thunderbird
On 9/3/24 3:54 PM, olcott wrote:
On 9/3/2024 1:53 PM, joes wrote:
Am Tue, 03 Sep 2024 08:17:56 -0500 schrieb olcott:
On 9/3/2024 3:44 AM, Mikko wrote:
On 2024-09-02 16:06:11 +0000, olcott said:
>
A correct halt decider is a Turing machine T with one accept state and
one reject state such that:
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y eventually halts, the
execution of T eventually ends up in the accept state and then stops.
If T is executed with initial tape contents equal to an encoding of
Turing machine X and its initial tape contents Y, and execution of a
real machine X with initial tape contents Y does not eventually halt,
the execution of T eventually ends up in the reject state and then
stops.
Your "definition" fails to specify "encoding". There is no standard
encoding of Turing machines and tape contents.
>
That is why I made the isomorphic x86utm system.
By failing to have such a concrete system all kinds of false assumptions
cannot be refuted.
What would those assumptions be?
>
The behavior of DDD emulated by HHH** <is> different than the behavior
of the directly executed DDD** **according to the semantics of the x86
language
How can the same code have different semantics?
>
 The pathological relationship between DDD and HHH really
cannot be simply ignored as if it does not exist.
No, but it doesn't change the definition of behavior.
Sorry, you are just showing your ignorance.
Note, DDD is NOT "pathological" to HHH, as HHH can return a 1 and be correct.
It is just an Achilles heel to your form of algorithm.

 
HHH is required to report on the behavior tat its finite string input
specifies even when this requires HHH to emulate itself emulating DDD.
 > The input specifies an aborting HHH - which you don’t simulate.>
 void DDD()
{
   HHH(DDD);
   OutputString("This code is unreachable by DDD emulated by HHH");
}
But it can be reached by running DDD or completely emulationg it with HHH1.
The fact that HHH aborts before it gets there doesn't mean the program DDD doesn't get there.
Sorry, you are just proving your utter ignorance of what you are talking about.
The Behavior of DDD (that happens to be emulated by HHH) is NOT the same thing as the Emulation of DDD by HHH, you just don't know the meaning of the words you are using.

 
DDD never halts unless it reaches its own final halt state. The fact
that the executed HHH halts has nothing to do with this.
Other than that DDD calls HHH?
>
HHH is not allowed to report on the computation that itself is contained
within.
Then it is only partial, and doesn’t even solve the case it was built for.
>
 int sum(int x, int y);
sum(3,4) is not allowed to report on the sum of 5 + 6
for the same reason. HHH(DDD) cannot report on behavior
that it cannot see.
 HHH cannot correctly report on the AFTER-THE-FACT
behavior that it has aborted its simulation BEFORE-THE-FACT.
Which is HHH's fault for not looking far enough.
The behavior of DDD was defined as soon as the code was written even if it is NEVER actually run. It just isn't KNOWN until we run it or completely simulate it.
You are just still stuck in your confusion of truth and knowledge.
It is a FACT that the DDD that calls an HHH whose code will abort a simulation of this DDD will halt.
That might not be know until we run the program. The fact that HHH can't obtain this knowledge with the algorithm you gave it is on the programmer.

 
Except for the case of pathological self-reference the behavior of the
directly executed machine M is always the same as the correctly
simulated finite string ⟨M⟩.
 
That sure sounds like a mistake to me.
>
 THE EXECUTION TRACE HAS ALWAYS PROVED THAT I AM CORRECT
FOR THREE FREAKING YEARS all the way back when it was
P correctly emulated by D.
Nope, it proves you have been lying.

 I initially took disagreeing with this as despicable
lying bastards playing sadistic head games.
I called Ben this and that is why he is mad at me.
No, it just proves that YOU are the lying bastard.

 In retrospect it seems that people are so deeply indoctrinated
into the received view that when raw facts stare them right in
the face they honestly cannot see these facts.
Nope, it shows that YOU are so deeply indoctrinated by your own lies brainwashing you that you just refuse to look at the facts, because you have made yourself into an idiot.

 
That no one has noticed that they can differ does not create an axiom
where they are not allowed to differ.
 
They were never allowed, that was the definition.
>
 When you make a definition that "cows" <are> "airplanes"
gullible sheep will accept it as true.
And that is what you have done, and you are that sheep.

 When you make a definition that halt deciders compute the
mapping from their inputs to the behavior that these inputs
specify
Which is the behavior of the program the input describes, something that seem to be beyond you ability to understand though your brainwashing.

 and textbooks say things that seem to disagree with definition
then gullible sheep will agree with the textbooks.
What definition did they disagree with?
You don't get to redefine things try to show them disagreeing.
Your problem is you failed to actually learn the definitione

 
No one noticed that they differ only because everyone rejected the idea
of a simulating halt decider out-of-hand without review.
I think after 3 years that excuse has grown a bit stale.
>
 IT REMAINS A VERIFIED FACT THAT DDD EMULATED BY HHH CANNOT
POSSIBLY REACH ITS OWN FINAL HALT STATE, AND PEOPLE STILL
FREAKING LIE EVEN ABOUT THIS MAXIMALLY DUMBED DOWN VERSION:
HHH/DDD OF THIS:
Nope, YOU have proven the opposite, but you don't understand it.
The problem is you confuse the behavior of the program with the behavior of a partial simulation of it.

 // Original H/P
int P()
{
   int Halt_Status = H(P,P);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 For three freaking years the gullible sheep on this forum continue
to believe that the pathological relationship of the decider to its input does not change the behavior of this input
 *EVEN WHEN IT IS CONCLUSIVELY PROVED THAT IT DOES CHANGE THIS BEHAVIOR*
*EVEN WHEN IT IS CONCLUSIVELY PROVED THAT IT DOES CHANGE THIS BEHAVIOR*
*EVEN WHEN IT IS CONCLUSIVELY PROVED THAT IT DOES CHANGE THIS BEHAVIOR*
 
Nope, it has been conclusibely proved that it doesn't.
You have FAILED at your claim, in part, because you don't actually seem to understand what you are trying to claim.
Sorry, you are just proving yourself to be an ignorant pathological lying idiot.

Date Sujet#  Auteur
2 Sep 24 * Defining a correct halt decider41olcott
2 Sep 24 +- Re: Defining a correct halt decider1Richard Damon
3 Sep 24 `* Re: Defining a correct halt decider39Mikko
3 Sep 24  `* Re: Defining a correct halt decider38olcott
3 Sep 24   +* Re: Defining a correct halt decider10joes
3 Sep 24   i`* Re: Defining a correct halt decider9olcott
4 Sep 24   i +- Re: Defining a correct halt decider1Richard Damon
4 Sep 24   i +- Re: Defining a correct halt decider1joes
4 Sep 24   i +* Re: Defining a correct halt decider5Fred. Zwarts
4 Sep 24   i i`* Re: Defining a correct halt decider4olcott
5 Sep 24   i i +- Re: Defining a correct halt decider1Richard Damon
5 Sep 24   i i +- Re: Defining a correct halt decider1Richard Damon
5 Sep 24   i i `- Re: Defining a correct halt decider1Fred. Zwarts
12 Sep 24   i `- Re: Defining a correct halt decider1immibis
4 Sep 24   +- Re: Defining a correct halt decider1Richard Damon
4 Sep 24   +* Re: Defining a correct halt decider5Fred. Zwarts
4 Sep 24   i+* Re: Defining a correct halt decider3olcott
5 Sep 24   ii+- Re: Defining a correct halt decider1Richard Damon
5 Sep 24   ii`- Re: Defining a correct halt decider1Fred. Zwarts
6 Sep 24   i`- Re: Defining a correct halt decider1Mikko
5 Sep 24   `* Re: Defining a correct halt decider21Mikko
5 Sep 24    `* Re: Defining a correct halt decider20olcott
5 Sep 24     +* Re: Defining a correct halt decider4joes
5 Sep 24     i`* Re: Defining a correct halt decider3olcott
6 Sep 24     i +- Re: Defining a correct halt decider1Richard Damon
6 Sep 24     i `- Re: Defining a correct halt decider1Fred. Zwarts
6 Sep 24     +- Re: Defining a correct halt decider1Richard Damon
6 Sep 24     `* Re: Defining a correct halt decider14Mikko
6 Sep 24      `* Re: Defining a correct halt decider13olcott
7 Sep 24       +- Re: Defining a correct halt decider1Richard Damon
7 Sep 24       +* Re: Defining a correct halt decider7Mikko
7 Sep 24       i`* Re: Defining a correct halt decider6olcott
8 Sep 24       i +* Re: Defining a correct halt decider4Mikko
8 Sep 24       i i`* Re: Defining a correct halt decider3olcott
8 Sep 24       i i +- Re: Defining a correct halt decider1Mikko
8 Sep 24       i i `- Re: Defining a correct halt decider1Richard Damon
8 Sep 24       i `- Re: Defining a correct halt decider1Fred. Zwarts
7 Sep 24       `* Re: Defining a correct halt decider4Fred. Zwarts
7 Sep 24        `* Re: Defining a correct halt decider3olcott
7 Sep 24         +- Re: Defining a correct halt decider1Richard Damon
8 Sep 24         `- Re: Defining a correct halt decider1Fred. Zwarts

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal