Sujet : Re: Defining a correct halt decider
De : noreply (at) *nospam* example.org (joes)
Groupes : comp.theoryDate : 04. Sep 2024, 10:10:33
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <0ba58a910e75f101ed4c37d975cf89a5fe1b85d0@i2pn2.org>
References : 1 2 3 4 5
User-Agent : Pan/0.145 (Duplicitous mercenary valetism; d7e168a git.gnome.org/pan2)
Am Tue, 03 Sep 2024 14:54:56 -0500 schrieb olcott:
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:
>
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.
How is it ignored?
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");
}
I thought HHH returned „DDD doesn’t halt, so I aborted it”?
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.
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.
It has complete information, so it must do something wrong.
HHH cannot correctly report on the AFTER-THE-FACT behavior that it has
aborted its simulation BEFORE-THE-FACT.
Can you expand on this?
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.
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.
Understandable. Have you tried apologising?
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 halt deciders compute the mapping from
their inputs to the behavior that these inputs specify
and textbooks say things that seem to disagree with definition then
gullible sheep will agree with the textbooks.
I’d rather believe the textbooks than your definition.
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.
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
The input exists independently of its simulation.
*EVEN WHEN IT IS CONCLUSIVELY PROVED THAT IT DOES CHANGE THIS BEHAVIOR*
Empirical evidence can be flawed.
-- 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.