Sujet : Re: embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ computes the mapping from its input to Ĥ.qn --- black swan
De : polcott333 (at) *nospam* gmail.com (olcott)
Groupes : comp.theoryDate : 01. Aug 2024, 14:54:43
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v8g0ij$25l0a$7@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
User-Agent : Mozilla Thunderbird
On 8/1/2024 7:17 AM, joes wrote:
Am Thu, 01 Aug 2024 06:49:13 -0500 schrieb olcott:
On 8/1/2024 2:44 AM, Mikko wrote:
On 2024-07-31 17:27:33 +0000, olcott said:
On 7/31/2024 2:32 AM, Mikko wrote:
On 2024-07-30 14:16:20 +0000, olcott said:
On 7/30/2024 1:37 AM, Mikko wrote:
On 2024-07-29 16:16:13 +0000, olcott said:
On 7/28/2024 3:02 AM, Mikko wrote:
On 2024-07-27 14:08:10 +0000, olcott said:
On 7/27/2024 2:21 AM, Mikko wrote:
On 2024-07-26 14:08:11 +0000, olcott said:
When we compute the mapping from the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
to the behavior specified by this input we know that embedded_H is
correct to transition to Ĥ.qn.
>
The meaning of "correct" in this context is that if the transition
of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn is correct if H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions
to H.qn but incorrect otherwise.
>
No you are wrong.
Which dictionary (or other authority) disagrees?
>
The common knowledge that a decider computes the mapping from its
input finite string...
This is almost always the same as the direct execution of the machine
represented by this finite string.
Not "almost". Otherwise it is doing something different.
*That has always been a false assumption*
This is a case of the problem of induction.
At a point in time no one ever saw a black
swan so they were presumed to not exist.
https://en.wikipedia.org/wiki/Black_swan_theoryThe case of an emulating termination analyzer that
analyzes an input that calls itself is the black
swan of halt deciders.
The 100% concrete (nothing left to the imagination) proof
of the execution trace of DDD correctly emulated by HHH
according to the semantics of the x86 language conclusively
proves otherwise to all experts of the x86 language.
None of above indicates any disagreement by any authority.
Everyone (even Linz) has the wrong headed idea that a halt decider must
report on the behavior of the computation that itself is contained
within. This has always been wrong.
Dude. The halting problem /specifically/ asks about a machine simulating
itself.
Yet no one ever bothered to carefully examine the execution
trace that a simulating halt decider derives because everyone
consistently rejected simulation out-of-hand without review.
A halt decider must always report on the behavior that its finite string
specifies. This is different only when an input invokes its own decider.
Um, no? Then it is making a mistake.
The correct execution trace has proved otherwise for three
years. For three solid years everyone presumed that they
had the authority to disagree with the semantics of the x86
language.
The one rare exception is shown above where Ĥ ⟨Ĥ⟩ halts and the input
to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its own final state of
⟨Ĥ.qn⟩ when embedded_H acts as if it was a UTM.
H is not an UTM, though.
When we hypothesize that embedded_H acts exactly the same
as a UTM until it detects the non-halting behavior of
its correct simulation of its input then embedded_H <is>
a UTM up until this point. Even if embedded_H can never
see this non-halting behavior we ourselves can see that
Ĥ ⟨Ĥ⟩ never halts. If we can see it then embedded_H can
see it.
That is not supported by any anuthority.
>
The authority says *given an input of the function domain it*
*can return the corresponding output*
Which authority? Not that that would be a valid argument.
In other words all deciders compute the mapping from their input (finite
string) to an accept or reject state.
This means that they do not compute the mapping of the executing process
of themselves.
They do, if those happen to coincide.
I am the first person in the world that noticed these two could be
different. Everyone that has disagreed with me is disagreeing with the
semantics of the x86 language.
What are the semantics that you disagree about?
Everyone that says int main() { DDD(); }
must have the same behavior as DDD correctly emulated by HHH
is disagreeing with the semantics of the x86 language.
I have found the black swan. I show people this black swan
and they still believe that black swans do not exist.
-- Copyright 2024 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer
DDD correctly emulated by HHH is correctly rejected as non-halting V2
Re: DDD correctly emulated by HHH is correctly rejected as non-halting V2
