XPost: comp.theory, sci.logic, sci.math

On 1/17/2022 6:38 PM, Richard Damon wrote:

On 1/17/22 3:11 PM, olcott wrote:

On 1/16/2022 10:58 PM, Richard Damon wrote:

On 1/16/22 11:43 PM, olcott wrote:

On 1/16/2022 10:35 PM, Richard Damon wrote:

On 1/16/22 11:20 PM, olcott wrote:

On 1/16/2022 10:13 PM, Richard Damon wrote:

On 1/16/22 11:00 PM, olcott wrote:

On 1/16/2022 9:48 PM, Richard Damon wrote:

On 1/16/22 10:26 PM, olcott wrote:

On 1/16/2022 9:01 PM, Richard Damon wrote:

On 1/16/22 9:54 PM, olcott wrote:

On 1/16/2022 6:46 PM, Richard Damon wrote:

On 1/16/22 7:16 PM, olcott wrote:

On 1/16/2022 6:12 PM, Richard Damon wrote:

On 1/16/22 6:57 PM, olcott wrote:

On 1/16/2022 5:47 PM, Richard Damon wrote:

On 1/16/22 6:09 PM, olcott wrote:

On 1/16/2022 5:00 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 1/16/22 5:25 PM, olcott wrote:

On 1/16/2022 4:15 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 1/16/22 4:39 PM, olcott wrote:

On 1/16/2022 2:55 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 1/16/22 3:26 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Most people that try to form a rebuttal >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of my halting problem proof refutation >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lack sufficient basic understanding of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the computer science involved. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

The primary reason for this short-coming >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is that none of the textbook >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> explanations of the halting problem are >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sufficiently precise. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

No, your understanding is not sufficient >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the task.

Every decider computes the mapping from >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its input(s) to an accept or reject state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
A halt decider H computes the mapping >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from a P/I finite string pair >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (where P is a machine description) to an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H must compute this mapping on the basis >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the actual behavior that P/I specifies. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

AND, that mapping MUST match the ACTUAL >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the computation it is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deciding on.

The most definite way to determine N >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> steps of the behavior that P/I actually >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies is to perform a pure >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of N steps of P/I. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The copy of H at Ĥ.qx referred to as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H must compute >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩
to Ĥ.qy or Ĥ.qn. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It must do this on the basis of the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actual behavior specified by these inputs. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
The actual behavior specified by these >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inputs is the behavior of the pure >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of N steps of ⟨Ĥ⟩ applied to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ until: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state or
(b) embedded_H recognizes that simulated >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ would never reach its final state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

WRONG. The actual behavior specifie by >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these inputs is the behavior of the pure >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation until it completes, or forever >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if it never halts. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

That is correct. In those cases where the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input specifies an infinite sequence of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations a halt decider either: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
(a) Recognizes that this sequence would >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reach its final state in any finite >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of steps
and aborts its simulation of this input >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and transitions to its reject state. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) Fails to be a decider at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
computation that halts … the Turing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine will halt whenever it enters a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state. (Linz:1990:234) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
According to Linz any sequence of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations that would never reach its >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state in any finite number of steps >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is a non halting sequence. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Except that as has been shown, if H aborts >>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation and returns non-halting, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> then BY CONSTRUCTION, H^ will halt. Thus, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> there exists no finite sequence of states >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that correctly prove that H^ will not halt. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
For ANY finite number of states that H >>>>>>>>>>>>>>>>>>>>>>>>>>>>> might simulate the computation of   H^ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> <H^>, and abort it and return Non-Halting, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> there exists another finite but larger >>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of states that H^ <H^> will halt in. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>

You are confusing yourself with your own >>>>>>>>>>>>>>>>>>>>>>>>>>>> double talk.

If when embedded_H makes its decision the >>>>>>>>>>>>>>>>>>>>>>>>>>>> pure simulation of its own input cannot >>>>>>>>>>>>>>>>>>>>>>>>>>>> possibly reach any final state of this input >>>>>>>>>>>>>>>>>>>>>>>>>>>> in any finite number of steps then >>>>>>>>>>>>>>>>>>>>>>>>>>>> embedded_H is necessarily correct to abort >>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation of this input and transition >>>>>>>>>>>>>>>>>>>>>>>>>>>> to Ĥ.qn.

Once embedded_H has made this decision >>>>>>>>>>>>>>>>>>>>>>>>>>>> subsequent evaluation is cut off because Ĥ >>>>>>>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ has stopped running. >>>>>>>>>>>>>>>>>>>>>>>>>>>

WRONG.

H^ applied to <H^> can NEVER stop running >>>>>>>>>>>>>>>>>>>>>>>>>>> until it hits its final state. >>>>>>>>>>>>>>>>>>>>>>>>>>>
THAT IS THE DEFINITION OF HALTING/Non-Halting. >>>>>>>>>>>>>>>>>>>>>>>>>>>
The fact that H  (aka embedded_H) has aborted >>>>>>>>>>>>>>>>>>>>>>>>>>> it simulation of this string does NOT affect >>>>>>>>>>>>>>>>>>>>>>>>>>> the actual behavior of the string as the >>>>>>>>>>>>>>>>>>>>>>>>>>> behavior is based on what a REAL UTM does >>>>>>>>>>>>>>>>>>>>>>>>>>> with it, not your 'fake' UTM that aborts. >>>>>>>>>>>>>>>>>>>>>>>>>>>

You already understand that if the simulating >>>>>>>>>>>>>>>>>>>>>>>>>> halt decider embedded_H never stopped >>>>>>>>>>>>>>>>>>>>>>>>>> simulating its input that its input would >>>>>>>>>>>>>>>>>>>>>>>>>> never reach its final state. >>>>>>>>>>>>>>>>>>>>>>>>>

Right IF the simulating Halt Decider never >>>>>>>>>>>>>>>>>>>>>>>>> stopped simulating, then H^ would never halt, >>>>>>>>>>>>>>>>>>>>>>>>> but that is only true IF H never aborts. >>>>>>>>>>>>>>>>>>>>>>>>>
There is no 'unless' here, either H does or it >>>>>>>>>>>>>>>>>>>>>>>>> doesn't abort its simulation. If H doesn't >>>>>>>>>>>>>>>>>>>>>>>>> abort, then H^ in non-halting. >>>>>>>>>>>>>>>>>>>>>>>>>

You already understand that when a simulated >>>>>>>>>>>>>>>>>>>>>>>>>> input can never reach its final state that >>>>>>>>>>>>>>>>>>>>>>>>>> this input specifies a sequence of >>>>>>>>>>>>>>>>>>>>>>>>>> configurations that never halts. >>>>>>>>>>>>>>>>>>>>>>>>>>

Right, if the simulate input WHEN SIMULTED BY A >>>>>>>>>>>>>>>>>>>>>>>>> NON-ABORTING UTM, can never reach its final >>>>>>>>>>>>>>>>>>>>>>>>> state, ths input specifies a sequnce of >>>>>>>>>>>>>>>>>>>>>>>>> configuration that never halts. >>>>>>>>>>>>>>>>>>>>>>>>>
If H aborts its simulation, then you no longer >>>>>>>>>>>>>>>>>>>>>>>>> have any 'proof' that the input doesn't halt, >>>>>>>>>>>>>>>>>>>>>>>>> and your proof was based on an H that never >>>>>>>>>>>>>>>>>>>>>>>>> aborted its simulation, so it isn't applicable >>>>>>>>>>>>>>>>>>>>>>>>> here.

You don't seem to be able to put these two >>>>>>>>>>>>>>>>>>>>>>>>>> ideas together.

Because you are making incompatible assumptions. >>>>>>>>>>>>>>>>>>>>>>>>

If the simulated input to embedded_H cannot >>>>>>>>>>>>>>>>>>>>>>>> possibly ever reach its final state then this >>>>>>>>>>>>>>>>>>>>>>>> conclusively proves that this input meets the >>>>>>>>>>>>>>>>>>>>>>>> Linz definition of a sequence of configuration >>>>>>>>>>>>>>>>>>>>>>>> that does not halt.

WRONG. That applies only IF you define your H to >>>>>>>>>>>>>>>>>>>>>>> actually BE a UTM, and yes, if H IS a UTM, then >>>>>>>>>>>>>>>>>>>>>>> H^ is non-halting, but H also doesn't answer, so >>>>>>>>>>>>>>>>>>>>>>> fails to be a correct decider.

So, your system only meets the requirements for a >>>>>>>>>>>>>>>>>>>>>>> configuration that does not halt if H doesn't >>>>>>>>>>>>>>>>>>>>>>> abort its simulation.

Because the simulated input to embedded_H cannot >>>>>>>>>>>>>>>>>>>>>> possibly ever reach its final state whether or not >>>>>>>>>>>>>>>>>>>>>> embedded_H aborts its simulation then we know that >>>>>>>>>>>>>>>>>>>>>> this input meet the Linz definition of a sequence >>>>>>>>>>>>>>>>>>>>>> of configurations that does not halt. >>>>>>>>>>>>>>>>>>>>>

NO, WE DON'T.

It only meet the requirement if H doesn't abort. >>>>>>>>>>>>>>>>>>>>>
The fact that an aborted simulation doesn't reach >>>>>>>>>>>>>>>>>>>>> its final state does NOT say that the input would >>>>>>>>>>>>>>>>>>>>> never reach a final state if it was simulated farther. >>>>>>>>>>>>>>>>>>>>>
So, yes, you have proven that if you H is defined >>>>>>>>>>>>>>>>>>>>> as a simulator that never aborts its simulation, >>>>>>>>>>>>>>>>>>>>> then H^ will be a non-halting computation and the >>>>>>>>>>>>>>>>>>>>> correct answer for a Halting Decider would be >>>>>>>>>>>>>>>>>>>>> non-halting, but by the conditions you just imposed >>>>>>>>>>>>>>>>>>>>> on H to prove that, H can not give that answer. >>>>>>>>>>>>>>>>>>>>> Once you remove the constraint on H that it never >>>>>>>>>>>>>>>>>>>>> aborts its simulation, then your proof for the new >>>>>>>>>>>>>>>>>>>>> H^ that is created from this new H becomes invalid >>>>>>>>>>>>>>>>>>>>> and doesn't actually prove anything like what you >>>>>>>>>>>>>>>>>>>>> want. At best it proves that H can never actually >>>>>>>>>>>>>>>>>>>>> prove that H^ is halting (not that it isn't >>>>>>>>>>>>>>>>>>>>> halting, just that H can't actually prove it). >>>>>>>>>>>>>>>>>>>>>

If halting was defined as "does not keep running >>>>>>>>>>>>>>>>>>>>>> forever" then you would be right as soon as >>>>>>>>>>>>>>>>>>>>>> embedded_H aborts its simulation then its input >>>>>>>>>>>>>>>>>>>>>> halts. Because this is not the way that halting is >>>>>>>>>>>>>>>>>>>>>> defined you are wrong.

WRONG. Linz definition refers to the ACTUAL running >>>>>>>>>>>>>>>>>>>>> of the machine, not its simulation by a partial >>>>>>>>>>>>>>>>>>>>> simulator.

Just because H has aborted its simulation does NOT >>>>>>>>>>>>>>>>>>>>> mean that if the input was actually simulated by a >>>>>>>>>>>>>>>>>>>>> UTM it would not reach that final state. >>>>>>>>>>>>>>>>>>>>>

The fact that the input to embedded_H demonstrates >>>>>>>>>>>>>>>>>>>> an infinitely repeating pattern that can be >>>>>>>>>>>>>>>>>>>> recognized by embedded_H as infinitely repeating is >>>>>>>>>>>>>>>>>>>> what provides embedded_H with its "never reaches its >>>>>>>>>>>>>>>>>>>> final state" halt status criterion measure. >>>>>>>>>>>>>>>>>>>

But if H 'recognizes' it as an infinitely repeating >>>>>>>>>>>>>>>>>>> pattern and goes to H.Qn then the input it is looking >>>>>>>>>>>>>>>>>>> at is KNOWN to Halt,

Not at all.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>

If and ONLY if H <H^> <H^> says Non-Halting. >>>>>>>>>>>>>>>>>

The computation that embedded_H is a part of halts. >>>>>>>>>>>>>>>>>> The computation specified by the simulated input is >>>>>>>>>>>>>>>>>> aborted before it ever gets past Ĥ.qx thus never >>>>>>>>>>>>>>>>>> reaches its own final state thus (according to Linz) >>>>>>>>>>>>>>>>>> never halts.

WRONG. Do you mean part of 'H'? (there is not 'halts' >>>>>>>>>>>>>>>>> that you have currently defined as a Turing Machine) >>>>>>>>>>>>>>>>>
Remember, your requirement on H was H wM w -> H.Qn iff >>>>>>>>>>>>>>>>> M w never Halts (and -> H.Qy iff M w Halts). >>>>>>>>>>>>>>>>>
This wasn't if the partial simulation of wM w never >>>>>>>>>>>>>>>>> reached a final state, but if the ACTUAL machine M >>>>>>>>>>>>>>>>> applied to w does.

The issue is that the test of H^ <H^> Halting or not is >>>>>>>>>>>>>>>>> NOT based on the processing that H does on it, but what >>>>>>>>>>>>>>>>> it does as an independent entity, either what >>>>>>>>>>>>>>>>> UTM(<H^>,<H^>) does or what H^ <H^> does.

In both of these cases, that top level H^ being >>>>>>>>>>>>>>>>> processed is NOT 'aborted' by H (maybe what you call >>>>>>>>>>>>>>>>> halts) and it will continue on till it reaches that >>>>>>>>>>>>>>>>> same H^.Qn and Halt, and thus show that H^ <H^> is a >>>>>>>>>>>>>>>>> halting computation.

Your probably next claim that H can't be responsible >>>>>>>>>>>>>>>>> for the actual machine because it wasn't the input >>>>>>>>>>>>>>>>> isn't correct, it can't use the actual machine to do >>>>>>>>>>>>>>>>> its computation, but it IS responsible for the behavior >>>>>>>>>>>>>>>>> of that machine if it wants to claim to compute the >>>>>>>>>>>>>>>>> Halting Function which IS dependent on that actual >>>>>>>>>>>>>>>>> machine, for which it just gets a representation of. >>>>>>>>>>>>>>>>>

embedded_H computes the mapping from its input finite >>>>>>>>>>>>>>>> strings ⟨Ĥ⟩ ⟨Ĥ⟩ to   Ĥ.qy or Ĥ.qn based on what the
behavior of this input would if embedded_H would >>>>>>>>>>>>>>>> continue to simulate this input forever.

Which is incorrect the way you do it, It needs to >>>>>>>>>>>>>>> determine what the input would do based on the copy of H >>>>>>>>>>>>>>> embedded in H^ doing what all copies of H will do. >>>>>>>>>>>>>>> PERIOD. ASSUMING that the copy of H embedded in H^ will >>>>>>>>>>>>>>> continue simulating forever just makes an ASS out of U, >>>>>>>>>>>>>>> because that is NOT what it will do.

None of the copies of embedded_H do anything besides >>>>>>>>>>>>>> simulate their input until the outermost copy recognizes >>>>>>>>>>>>>> the infinitely repeating pattern.

But what would they do AFTER that? Won't they also abort >>>>>>>>>>>>> their own simulation?

When embedded_H recognizes that its input matches an
infinite behavior pattern it immediately stops simulating >>>>>>>>>>>> this input thus terminating the entire call chain.

Not the part of the chain that is CALLING it.

You simply don't know enough computer science to understand >>>>>>>>>> that your objection is totally irrelevant.

embedded_H is only accountable for computing the mapping from >>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy and Ĥ.qn.

Everything else in the universe it totally irrelevant to the >>>>>>>>>> correctness of the halt status decision of embedded_H.

No, it is accountable to compute the RIGHT answer per the
specifications. I mentioned this previously, and you have just >>>>>>>>> ignored this error of yours.

If you aren't using the official Halting Problem Specifications >>>>>>>>> then you are just talking about POOP.

The Official Halting Problem Specifications say that H applied >>>>>>>>> to input wM w needs to answer Halting (by going to H.Qy) for H >>>>>>>>> applied to wM w if and only if M applied to w will Halt in some >>>>>>>>> finite time and to answer Non-Halting (by going to H.Qn) if M >>>>>>>>> applied to w will NEVER Halt.

Since H^ w is designed so it will Halt if H w w goes to H.Qn >>>>>>>>> and to loop forever if H w w goes to H.Qy, then we have that if >>>>>>>>> H <H^> <H^> goes to H.Qn as you claim, then H^ <H^> will by
construction Halt, and thus H failed to meet its requriements, >>>>>>>>> since it said Non-Halting for a computation that clearly Halted. >>>>>>>>>

embedded_H is only accountable for computing the mapping of its >>>>>>>> inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn because all deciders are only
accountable for mapping their inputs to an accept or reject state. >>>>>>>>
When you object to this you are forgetting that all halt
deciders must be deciders.

But you are WRONG in your interpretation. DO you have a source to >>>>>>> back your meaning up.

H is accountable for computing the mapping of (wM, w) to match
the Halting property of M applied to w. The EXACT machine and
input and the EXACT behavior.

All halt deciders are deciders and are only accountable for
mapping their inputs to an accept or reject state. If you can't
understand this there is no sense proceeding further.

So, you don't understand that a decider needs to CORRECTLY compute
the function it is deciding?

Does that mean I can just make my halt decider always decide
non-halting and claim it is correct? That seems the logical
conclusion of your statment.

FAIL.

H <H^> <H^> means to answer on the behavior of H^ <H^>, which
just happens to also match UTM <H^> <H^> but that behaves exactly >>>>>>> the same.

Yes, it is only 'accountable' for the input it was given, but
that is the input string <H^> <H^>, and it is accountable for
generating the RIGHT answer based on the definition of the
mapping it is claiming to compute, which is that Halting Property >>>>>>> of H^ applied to <H^>,

No this is flatly incorrect. If this was the case then embedded_H
would be reporting the halt status of itself.

But it sort of needs to. It NEEDS to be able to report the halt
status of a computation that uses a copy of itself. THAT IS THE
REQUIREMENT.

It only reports on the halt status of its direct inputs.
If this input specifies an infinitely nested simulation chain
then the whole chain will be broken when the outermost invocation
is aborted.

You must have something strange defined then.

H's (and embedded_H's) 'direct' input is <H^> <H^> which represents
the computation H^ applied to <H^>, which as pointed out if H <H^>
<H^> says non-halting will Halt.

Since, if H <H^> <H^> -> H.Qn, we have that H^ <H^> will Halt, and
you have even admitted this in the past, and the correct answer for
the input (<H^>,<H^>) must match the behavior of H^ <H^>,

No, not at all this is false. embedded_H is only accountable for
computing the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn based on the actual
behavior that its input specifies.

Which is the behavior of H^ applied to <H^> if H claims to be a Halting Decider.

embedded_H at Ĥ.qx IS NOT DECIDING WHETHER OR NOT ITS ACTUAL SELF HALTS.

Right, it is deciding if the computation specified by its input halts,
and that is H^ applied to <H^>, which DOES halt if H <H^> <H^> -> H.Qn

embedded_H is deciding whether or not its simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩
can possibly ever reach its final state.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)