On 7/4/23 5:52 PM, olcott wrote:
> On 7/4/2023 8:27 AM, Richard Damon wrote:
>> On 7/4/23 12:57 AM, olcott wrote:
>>> On 7/3/2023 11:06 PM, Richard Damon wrote:
>>>> On 7/3/23 11:56 PM, olcott wrote:
>>>>> On 7/3/2023 10:22 PM, Richard Damon wrote:
>>>>>> On 7/3/23 10:20 PM, olcott wrote:
>>>>>>> On 7/3/2023 4:55 PM, Richard Damon wrote:
>>>>>>>> On 7/3/23 5:34 PM, olcott wrote:
>>>>>>>>> On 7/3/2023 4:17 PM, Richard Damon wrote:
>>>>>>>>>> On 7/3/23 4:22 PM, olcott wrote:
>>>>>>>>>>> On 7/3/2023 2:58 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/3/23 2:48 PM, olcott wrote:
>>>>>>>>>>>>> On 7/3/2023 1:25 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/3/23 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/3/2023 11:26 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 7/3/23 12:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/3/2023 11:01 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 7/3/23 11:56 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 7/3/23 10:45 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/3/2023 9:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 7/3/2023 8:14 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decidability decider mode determines that D
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself this enables a batch file to invoke
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the directly executed D(D). H1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is identical to H except for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the pathological relationship to H.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> And does an input D that uses this FULL
>>>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since H(D,D) will (apparently) determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the input is pathological, and thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>> defer to H1(D,D), then when we actually run
>>>>>>>>>>>>>>>>>>>>>>>>>>>> D, appearently it will get that same answer
>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H1 and do the opposite of it, and thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H1 will be wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Remember, the "Pathological" program is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> built on a copy of the ACTUAL program that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> you ask to decide on it, including ALL of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "tricks", including things like this
>>>>>>>>>>>>>>>>>>>>>>>>>>>> "batch processing".
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You seem to be assuming that there is some
>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider -
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Input structure, but there isn't, at least
>>>>>>>>>>>>>>>>>>>>>>>>>>>> not one that can affect the answer of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I spent 12 hours a day for the last 10 days
>>>>>>>>>>>>>>>>>>>>>>>>>>> getting the copy the input
>>>>>>>>>>>>>>>>>>>>>>>>>>> working. When H(D,D) (in decidability decider
>>>>>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
>>>>>>>>>>>>>>>>>>>>>>>>>>> input is in the well defined set of
>>>>>>>>>>>>>>>>>>>>>>>>>>> pathological inputs it returns 0
>>>>>>>>>>>>>>>>>>>>>>>>>>> indicating that its input is undecidable. The
>>>>>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
>>>>>>>>>>>>>>>>>>>>>>>>>>> then knows to invoke H1(D,D) to correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>> report that D(D) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> This solution does seem to work correctly on
>>>>>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in
>>>>>>>>>>>>>>>>>>>>>>>>>>> every textbook.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> So, did you make your "conventional proof"
>>>>>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL
>>>>>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file"
>>>>>>>>>>>>>>>>>>>>>>>>>> not the C funciton H), or are you just
>>>>>>>>>>>>>>>>>>>>>>>>>> admitting that you wasted 120 hours looking at
>>>>>>>>>>>>>>>>>>>>>>>>>> the wrong thing because you have made yourself
>>>>>>>>>>>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you
>>>>>>>>>>>>>>>>>>>>>>>>>> don't understand what you are trying to do.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> New_D copies its input and simulates its input
>>>>>>>>>>>>>>>>>>>>>>>>> with its input.
>>>>>>>>>>>>>>>>>>>>>>>>> It never sees New_H.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Why not? Since New_H is the thing that is
>>>>>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D
>>>>>>>>>>>>>>>>>>>>>>>> needs to be built on it.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> New_H is embedded within New_D (as its middle
>>>>>>>>>>>>>>>>>>>>>>> states) just the
>>>>>>>>>>>>>>>>>>>>>>> way it is supposed to be. The question is: Does
>>>>>>>>>>>>>>>>>>>>>>> New_H(New_H) halt?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The only difference at the source code level is:
>>>>>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param.
>>>>>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So, how is New_H a halt decider then?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> typo
>>>>>>>>>>>>>>>>>>>>> The only difference at the source code level is:
>>>>>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param.
>>>>>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state.
>>>>>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is
>>>>>>>>>>>>>>>>>>>>> exactly New_H
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But New_D needs to call New_H,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Not in the Peter Linz proof:
>>>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In the Linz proof a copy of H is directly embedded
>>>>>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
>>>>>>>>>>>>>>>>>>> The original H remains unchanged.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The halting problem is about undecidable inputs, it
>>>>>>>>>>>>>>>>>>> is not about
>>>>>>>>>>>>>>>>>>> inserting bugs into a halt decider to make it cease
>>>>>>>>>>>>>>>>>>> to function.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, and in Linz, H is the decider that is claimed
>>>>>>>>>>>>>>>>>> to give the right answer.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That isn't 'H' in your system, but the script that
>>>>>>>>>>>>>>>>>> decides whether to use H or H1.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your error is in calling the wrong thing 'H'
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are just showing you are lying by using the wrong
>>>>>>>>>>>>>>>>>> name for things.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are using double-talk in a lame attempt to show that
>>>>>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of
>>>>>>>>>>>>>>>>> Linz Ĥ.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So you agree with the Theorem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No 'Linz H' can exist that correctly decides the halt
>>>>>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That is EXACTLY the consequence of the Halting Theorem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please show an ACTUAL 'Linz H' that correctly gets the
>>>>>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on
>>>>>>>>>>>>>>>> changing H and trying to use the old Ĥ which just fails
>>>>>>>>>>>>>>>> to meet the requirement of the proof, likely because you
>>>>>>>>>>>>>>>> just don't understand the theory involved.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It took me two years to figure out a clean way to copy
>>>>>>>>>>>>>>> the input to
>>>>>>>>>>>>>>> Linz_H_Hat and not have the system crash. Relative to
>>>>>>>>>>>>>>> Linz_H_Hat
>>>>>>>>>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, you are admitting that you actually can't do what is
>>>>>>>>>>>>>> required?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Copying the input should be trivial,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The relative addressing of the x86 language causes all
>>>>>>>>>>>>> function
>>>>>>>>>>>>> calls to call the wrong address.
>>>>>>>>>>>>
>>>>>>>>>>>> Only because you aren't interpreting the input properly, but
>>>>>>>>>>>> in a non-Turing Complete manner.
>>>>>>>>>>>>
>>>>>>>>>>>> As I said, the input description should be a chunck of code
>>>>>>>>>>>> in a virtual address space with a header that tells where
>>>>>>>>>>>> that code is supposed to be considered to be located at.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> as the input should be a representation that packages a
>>>>>>>>>>>>>> full program in its own virtual environment, so a simple
>>>>>>>>>>>>>> bit by bit copy to empty ram will work. Your problem is
>>>>>>>>>>>>>> that you don't put the input into its own virtual address
>>>>>>>>>>>>>> space, so you have pathological interactions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Linz_H_Hat must be built on the exact code base that is
>>>>>>>>>>>>>> deciding on it, in this case H, since you just said it
>>>>>>>>>>>>>> isn't, your proof is invalid.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Linz_Hat <is> Linz_H that takes one param  and copies it
>>>>>>>>>>>>> instead of
>>>>>>>>>>>>> two params and has an infinite loop at its accept state.
>>>>>>>>>>>>
>>>>>>>>>>>> So, Two things that are different are exactly the same?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It exactly matches the Linz spec.
>>>>>>>>>>>
>>>>>>>>>>>> You don't seem to understand what you are doing.
>>>>>>>>>>>>
>>>>>>>>>>>> Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
>>>>>>>>>>>> behavior. That behavior is a function of its input, but
>>>>>>>>>>>> hasn't been assigned any "meaning".
>>>>>>>>>>>>
>>>>>>>>>>>> Linz_H is a Turing Machine (if it actually can exist) that
>>>>>>>>>>>> has a defined meaning/requirement for its final states.
>>>>>>>>>>>> Linz_H, to meet its requirements, MUST go to Qy if the input
>>>>>>>>>>>> represents a Halting Computation, and MUST go to Qn if the
>>>>>>>>>>>> input represents a non-halting computation.
>>>>>>>>>>>>
>>>>>>>>>>>> Since Linz_H has actual requirements, a claimed
>>>>>>>>>>>> implementation of it can be checked to see if it actually
>>>>>>>>>>>> meets the requirements, and perhaps we can determine if it
>>>>>>>>>>>> is possible to meet them.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't
>>>>>>>>>>>>>> generate any truth values, only behavior. You are just
>>>>>>>>>>>>>> showing that you don't understand the basics of the
>>>>>>>>>>>>>> requirements, and seem to think that "close" is good
>>>>>>>>>>>>>> enough for proofs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Linz_H_Hat(Linz_H_Hat) returns 0.
>>>>>>>>>>>>>
>>>>>>>>>>>> > Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn,
>>>>>>>>>>>> which has NO
>>>>>>>>>>>> defined meaning for Linz_H_Hat as it isn't defined to be a
>>>>>>>>>>>> decider.
>>>>>>>>>>>
>>>>>>>>>>> Linz_H and Linz_H_Hat are C functions.
>>>>>>>>>>> Linz:H and Linz:Ĥ are Turing machines.
>>>>>>>>>>
>>>>>>>>>> So, inventing new terminology without introduction, thus
>>>>>>>>>> showing you are being intentionally deceptive.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Linz_H and Linz:H are both directly embedded within a copy of
>>>>>>>>>>> Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
>>>>>>>>>>> to Ĥ.qn still means not halting.
>>>>>>>>>>
>>>>>>>>>> No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so
>>>>>>>>>> there return value has no meaning.
>>>>>>>>>>
>>>>>>>>>> Ĥ has no meaning, so it can't be "incorrect" or contradicted.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This allows Linz_H and Linz:H correctly report on the actual
>>>>>>>>>>> behavior of their input.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, since BOTH have an input that when run will HALT, and both
>>>>>>>>>> report that it will not, both are just wrong.
>>>>>>>>>>
>>>>>>>>>> Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly"
>>>>>>>>>> return 0,
>>>>>>>>> *I never said that you are confused*
>>>>>>>>
>>>>>>>> You always claim that your H by its various names is "Correct"
>>>>>>>> to return 0 as the input is non-halting because its "correct
>>>>>>>> simulation" will never reach a final state.
>>>>>>>>
>>>>>>>> I think your brain is turning into mush, or is your pathology
>>>>>>>> overloading and trying to reverse the argument.
>>>>>>>>
>>>>>>>>> Linz_H_Hat(Linz_H_Hat) returns 0 permitting
>>>>>>>>> Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
>>>>>>>>>
>>>>>>>>
>>>>>>>> But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means
>>>>>>>> Halting,
>>>>>>>
>>>>>>> Linz_H_Hat has its own embedded_H that returns 0.
>>>>>>> Linz_H_Hat has no access to Linz_H, only to its own embedded copy.
>>>>>>
>>>>>> But embedded_H is an identical copy to Linz_H, so if embedded_H
>>>>>> returns 0, so does Lin
>>>>>>
>>>>>>> Linz_H simply simulates Linz_H_Hat until it terminates.
>>>>>>
>>>>>> Then so must embedded_H, since it is an identical copy, and as you
>>>>>> have shown before, if H is defined that way, the H_Hat will never
>>>>>> halt, and thus H, since for this case you said it doesn't abort,
>>>>>> will also never halt and fail to be a decider.
>>>>>>
>>>>>
>>>>> We have gone through this many hundreds of times.
>>>>> It is the exact same H(D,D) versus H1(D,D) thing.
>>>>>
>>>>> Linz_H_Hat now has a pathological relationship to itself
>>>>> this frees Linz_H from such a pathological relationship.
>>>>> So Linz_H becomes H1, and Linz_H_Hat becomes H.
>>>>
>>>> Nope, just shows you are not working in a Turing Equivalent system,
>>>> and thus NOTHING you say matters.
>>>>
>>>
>>> You can make such claims with bluster finding a source that actually
>>> supports them is a whole different matter.
>>
>> No, you are just showing that you believe Russell's Teapot actually
>> exists. YOU are the one making claims, so YOU are the one that needs
>> to make a actual proof of correctness, and show the error in the
>> counter claims.
>>
>
> If you believe that I am incorrect you need much more than your own
> presumption as a basis for an actual rebuttal. You might not have
> much more than this mere presumption.

I have given MANY details that you have not even tried to refute.

YOU are the one with the burden of Proof.

The Ultimate proof you are wrong is that H, which you claim to be a
correct Halt decider, will return 0 when called as H(D,D), but D(D)
Halts, as you admit, which is contrary to the requirements of a Halt
Decider.

Thus, you claim is just a LIE.

>
>> It is a PROVEN fact that two computation machines with the exact same
>> algorithm and the exact same input will always produce the same result.
>>
>> You are claiming differently, WITHOUT PROOF, so you are shown to be a
>> LIAR.
>>
>
> H1(D,D) and H(D,D) have different execution traces because D calls H and
> D does not call H1. A not very bright software engineer could understand
> this.

Then they aren't the same algorithm, and can't be considered the same
machine.

PERIOD.

You are caught in your lie.

When you try to show where the traces differ, it shows that the machines
are NOT exact copies of the same algorthm that uses only its defined
inputs to control itself.

Therefore, H1 is a DIFFERENT machine the H, so it giving the correct
answer is irrelevent, and you claims are shown to be a LIE.

>
>> Either H and H1 are claimed to be the same machine, or they are not.
>> If they are the same machine, they need to give the same answer, or
>> they are not, and thus H1 getting the right answer to the H^ built on
>> H doesn't matter.
>>
>>
>>> It is the case that when embedded_H is a simulating termination analyzer
>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
>>> normally and must have its simulation aborted.
>>
>> So?
>>
>>>
>>> It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
>>> have its simulation terminated.
>>
>> Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus
>> showing that you hav just been LYING for decades.
>
> It is a simple execution trace that even a bright high school student
> can understand now that I have shown it at the C source code level.

Which shows that your claims are a lie, as shown above.

>
>>>
>>>>>
>>>>>> Now, since you are claiming that the embedded_H and Linz_H are
>>>>>> IDENTICAL machines, but the also produce DIFFERENT results when
>>>>>> given identical inputs, you have just proven that you are a LIAR.
>>>>>
>>>>> *So you are back to rejecting verified facts out-of-hand*
>>>>> It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
>>>>> 1 and the only difference is that H1 does not have a pathological
>>>>> relationship to H and it is otherwise identical to H.
>>>>>
>>>>
>>>> Since youy refuse to provide the verification fact about where the
>>>> paths of H(D,D) and D(D) differ, you don't HAVE a "verified fact".
>>>>
>>>
>>> The source code and execution trace have been available for a year.
>>> I have explained this many times the problem seems to be that you simply
>>> don't believe the facts. You say that a simulation is incorrect yet
>>> cannot point to the instruction that was simulated incorrectly only
>>> because the simulation is actually correct.
>>
>> No, YOU LIE. The "Call H" instruction has been simulated incorrectly
>> (or not simulated at all an false presumptions about what it does used).
>>
>>>
>>>> You are just proving that you are just a LIAR and an IDIOT.
>>>>
>>>> What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
>>>> DEFINITION WRONG and you claim tha tit is right is a verified LIE.
>>>>
>>>
>>> It depends on how you frame the problem.
>>> If you frame the problem in that a halt decider must divide up finite
>>> strings pairs into those that halt when directly executed and those that
>>> do not, then no single program can do this. A pair of programs might do
>>> this.
>>
>> So, you agree with the Halting Theorem, as that it is the precise
>> problem being asked about.
>>
>>>
>>> If you frame the problem in that a halt decider must divide up finite
>>> stings into those that must have their simulation aborted to prevent
>>> their infinite execution, then from H's point of view D does not halt.
>>
>>
>> So, you are admitting to using a Strawman, and nothing you say applies
>> to the ACTUAL Halting Problem.
>>
>> You have maybe shown that POOP might be decidable, it at least can't
>> use the simple pathological example to show it, but POOP isn't about
>> Halting but partial simulation, so who cares about it.
>>
>> This shows your mental instability as we don't care about what H sees,
>> which is just something of its imagination, we care about the reality
>> of what D actually does. Just like we care about what is ACTUALLY
>> true, verses what you think must be true without actually trying to
>> prove it logically.
>
> It turns out that Linz_H(Linz_H_Hat, Linz_H_Hat) == 1
> because Linz_H_Hat(Linz_H_Hat) == 0

?? Linz_H isn't defined to "call" Linz_H_Hat, in fact it CAN'T because
Linz_H_Hat doesn't exist when Linz_H is defined. it might "Simulate" or
"Debug Step" the description it gets. Also Linz_H_Hat doesn't actually
returh anything of meaning, as has been previously told to you.

Also, if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, then so must the
embedded_H(Linz_H_Hat, Linz_H_Hat) that Linz_H_Hat uses, or it is proven
that you claim that you built Linz_H_Hat per the requirements is a LIE.

Linz_H_Hat is DEFINED to use a computationally equivalent copy of Linz_H
within it, and as such that copy must return the same value for the same
inputs. That you embedded_H doesn't just proves you failed to perform
this step correctly.

And you traces just confirm this fact, there will either be a differing
effect instruction/data in embedded_H or it uses a value not part of its
input (like its PC address), thus invalidating your claims.

Remember, you are claiming Turing Equivalence to the Turing Machine
description, so you need to be an ACTUAL equivalent, and

>
> This translates into Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
> transitions to Linz:H.qy because Linz:Ĥ applied to ⟨Ĥ⟩
> transitions to Linz:Ĥ.qn

But Linz:Ĥ uses its copy of embedded_H (Ĥ) (Ĥ) which will behave
IDENTIALLY to Linz:H (Ĥ) (Ĥ) which by your claim above goes to Qy, so
Linz:Ĥ will go to Qy and then on to the infinite loop, so Linz:H going
to Qy is incorrect.

>
> So I have overcome the issue of H(D,D) reporting non-halting and
> the directly executed D(D) then halting in two different ways:
>
> (1) Linz_H(Linz_H_Hat, Linz_H_Hat) reports halting and
> Linz_H_Hat(Linz_H_Hat) halts.

But only because you didn't build Ĥ correctly, and thus you are caught
in your LIE.

>
> (2) With the three value return of H(D,D) H only reports halting
> when its directly executed input actually halts and seems to
> defeat Rice by separately reporting all conventional halting
> problem proof pathological inputs.
>
>

Nope. You have just shown that you whole proof is built on LIES and your
own ignorance.

The claims you make just prove you don't understand the words you are
sayimg.