On 3/7/2024 5:32 AM, Ben Bacarisse wrote:
> Andy Walker <anw@cuboid.co.uk> writes:
>
>> On 05/03/2024 11:59, Ben Bacarisse wrote:
>>> I started this thread and now find myself with little time to talk about
>>> the replies. Sorry.
>>
>> Join the club!
>>
>>> I'm not exactly sure what your objection to the second form is.
>>
>> I don't have an "objection"; I merely think it's a little
>> harder for the non-mathematical student. That's a /little/, not a
>> /lottle/.
>>
>>> All of
>>> the forms require some conditional reasoning. For example, if TM#1 does
>>> not always halt then it's not a decider of anything and we can move on
>>> to TM#2.
>>
>> Yes, but we don't in general know whether TM#n always halts, never
>> halts or sometimes halts. At some level it doesn't matter, for the reasons
>> we all know. But we're left trying to explain to the student how and why
>> our ignorance doesn't matter. That's why it's slightly easier in some other
>> versions. If you claim that TM#123456 /is/ a HD, then you are already
>> [tho' you may not have realised it] claiming that it always halts, and so
>> the usual construction proves that it /isn't/ a HD, and your claim fails.
>> If you don't make the claim, then we don't know whether this TM halts on
>> particular inputs, in particular the "self-contradictory" input, and we
>> get into a bit of a conditional mess. Yes, it's all very easy for you
>> and me and Mike and ..., but we're not the target weak students.
>
> Well I see what you mean, but I don't think that ever came up a source
> of confusion, but it was, now, a long time ago.
>
>>> We don't have to *know* if it halts or not, all we need to
>>> know is that if it always does, then there is a constructable input for
>>> which the result of TM#1 does not match that of the halting function.
>>
>> "Please, Sir, how do we know whether it always does?"
>
> The students I taught seemed to have no problem with this sort of case
> analysis. But the "assume H does X" argument lead to lots of "but H1
> could be better" arguments.
>

H1(D,D) simulates D(D) that calls H(D,D) that rejects this
input because it would cause H itself to never halt.

This allows H1(D,D) to accept its input because it would
not cause H1 to never halt. H(D,D) aborts its simulation
of D(D) and H1(D,D) can see this so it need not abort its
simulation of D(D).

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

On 7/03/24 17:16, Ben Bacarisse wrote:
> immibis <news@immibis.com> writes:
>
>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>> The students I taught seemed to have no problem with this sort of case
>>> analysis. But the "assume H does X" argument lead to lots of "but H1
>>> could be better" arguments.
>>
>> They aren't satisfied with "we can do the exact same thing with H1 to prove
>> that H1 doesn't work either"?
>
> In the vast majority of cases, yes, but even then there is a logical
> problem with going down that route -- there is no H so there can't be an
> H1 that does better. Once this objection is properly examined, it turns
> out to be the argument I ended up preferring anyway. H isn't a halt
> decider, it's just any old TM and we show it can't be halt decider for
> one reason or another.
>

Unless your students are extremely pedantic... maybe they are... I don't
see what's illogical with:

"I think H is a halt decider."
"But it doesn't: see this proof."
"Oh. Well, even though H isn't a halt decider, how do we know there
isn't a program H1 which is a halt decider?"
"The proof would still work for H1, or H2, or any other program you
think is a halt decider."

On 3/7/24 7:27 AM, olcott wrote:
> On 3/7/2024 4:33 AM, Mikko wrote:
>> On 2024-03-07 00:24:43 +0000, olcott said:
>>
>>> If knowing its own machine description allows Olcott
>>> machines to decide halting on Turing Machine descriptions
>>> and TMs cannot do this then Church-Turing is refuted.
>>
>> If. There is no reason to think your machine can compute anything
>> that is not Truring computable.
>>
>
> No reason that you are aware of because you have
> not read all of the threads.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ can determine that it is being called in recursive
> simulation by simply comparing it own TMD to its input and
> finding a match.
>

But that doesn't let it COMPUTE a COMPUTATION that the Turing Machine can't.

The fact that you are adding a parameter to the decider changes what
computation it is computing.

You are just demonstrating how ignorant you are of the topic.

And your refusal to even try to learn what things mean just shows this
is a self-imposed ignorance, likely because you have gas-lit yourself
into beleiving your lies, and that it is dangerous to learn what might
actually be true.

WIth Olcott machines, you CAN'T write a machine OH(<M>, d) because your
structure automatically changes it to be the computation OH(<M>,d,<OH)

IF you can't write the actual signature of the computation, you would
need to prove that you algorithm doesn't use that extra information, but
you then say it is exactly that extra information is what lets you
"solve" the problem.

Note, using OH1(<H^>, <H^>, <OH1>) giving the right answer to say you
have solved the halting problem is incorrect, because it will fail for
an input H1^ which uses OH1(<H^>, <H1^>, <OH1>) (i.e calls OH1 instead
of OH).

Different parameters to an algorithm, even if you try to justify adding
them automagically, gives you different questions.

You are just showing your total ignorance of the rules of Computation
Theory, and that you are just a self-made ignorant pathological lying idiot.

On 3/7/2024 9:44 AM, immibis wrote:
> On 7/03/24 17:16, Ben Bacarisse wrote:
>> immibis <news@immibis.com> writes:
>>
>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>> The students I taught seemed to have no problem with this sort of case
>>>> analysis.  But the "assume H does X" argument lead to lots of "but H1
>>>> could be better" arguments.
>>>
>>> They aren't satisfied with "we can do the exact same thing with H1 to
>>> prove
>>> that H1 doesn't work either"?
>>
>> In the vast majority of cases, yes, but even then there is a logical
>> problem with going down that route -- there is no H so there can't be an
>> H1 that does better.  Once this objection is properly examined, it turns
>> out to be the argument I ended up preferring anyway.  H isn't a halt
>> decider, it's just any old TM and we show it can't be halt decider for
>> one reason or another.
>>
>
> Unless your students are extremely pedantic... maybe they are... I don't
> see what's illogical with:
>
> "I think H is a halt decider."
> "But it doesn't: see this proof."
> "Oh. Well, even though H isn't a halt decider, how do we know there
> isn't a program H1 which is a halt decider?"
> "The proof would still work for H1, or H2, or any other program you
> think is a halt decider."
The"misunderstanding" you sketch above isn't really about TM. Rather,
it's trouble with the implicit universal quantifier as in "for all H
that are TM".
--
Jeff Barnett

On 3/7/2024 10:44 AM, immibis wrote:
> On 7/03/24 17:16, Ben Bacarisse wrote:
>> immibis <news@immibis.com> writes:
>>
>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>> The students I taught seemed to have no problem with this sort of case
>>>> analysis.  But the "assume H does X" argument lead to lots of "but H1
>>>> could be better" arguments.
>>>
>>> They aren't satisfied with "we can do the exact same thing with H1 to
>>> prove
>>> that H1 doesn't work either"?
>>
>> In the vast majority of cases, yes, but even then there is a logical
>> problem with going down that route -- there is no H so there can't be an
>> H1 that does better.  Once this objection is properly examined, it turns
>> out to be the argument I ended up preferring anyway.  H isn't a halt
>> decider, it's just any old TM and we show it can't be halt decider for
>> one reason or another.
>>
>
> Unless your students are extremely pedantic... maybe they are... I don't
> see what's illogical with:
>
> "I think H is a halt decider."
> "But it doesn't: see this proof."
> "Oh. Well, even though H isn't a halt decider, how do we know there
> isn't a program H1 which is a halt decider?"
> "The proof would still work for H1, or H2, or any other program you
> think is a halt decider."
>
>

It is an easily verified fact that:
H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address 00001422
*different machine addresses is the reason for different return values*

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

On 3/7/24 10:30 AM, olcott wrote:
> On 3/7/2024 10:44 AM, immibis wrote:
>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>> immibis <news@immibis.com> writes:
>>>
>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>> The students I taught seemed to have no problem with this sort of case
>>>>> analysis.  But the "assume H does X" argument lead to lots of "but H1
>>>>> could be better" arguments.
>>>>
>>>> They aren't satisfied with "we can do the exact same thing with H1
>>>> to prove
>>>> that H1 doesn't work either"?
>>>
>>> In the vast majority of cases, yes, but even then there is a logical
>>> problem with going down that route -- there is no H so there can't be an
>>> H1 that does better.  Once this objection is properly examined, it turns
>>> out to be the argument I ended up preferring anyway.  H isn't a halt
>>> decider, it's just any old TM and we show it can't be halt decider for
>>> one reason or another.
>>>
>>
>> Unless your students are extremely pedantic... maybe they are... I
>> don't see what's illogical with:
>>
>> "I think H is a halt decider."
>> "But it doesn't: see this proof."
>> "Oh. Well, even though H isn't a halt decider, how do we know there
>> isn't a program H1 which is a halt decider?"
>> "The proof would still work for H1, or H2, or any other program you
>> think is a halt decider."
>>
>>
>
> It is an easily verified fact that:
> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address 00001422
> *different machine addresses is the reason for different return values*
>
>

Which proves that H1 and H are different computation and thus different
Turing Machines, so H1 getting the right answer doesn't "fix" H's
getting the wrong answer.

H1^ will confound H1, thus showing it isn't a halt decider either.

On 3/7/2024 12:46 PM, Richard Damon wrote:
> On 3/7/24 10:30 AM, olcott wrote:
>> On 3/7/2024 10:44 AM, immibis wrote:
>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>> immibis <news@immibis.com> writes:
>>>>
>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>> The students I taught seemed to have no problem with this sort of
>>>>>> case
>>>>>> analysis.  But the "assume H does X" argument lead to lots of "but H1
>>>>>> could be better" arguments.
>>>>>
>>>>> They aren't satisfied with "we can do the exact same thing with H1
>>>>> to prove
>>>>> that H1 doesn't work either"?
>>>>
>>>> In the vast majority of cases, yes, but even then there is a logical
>>>> problem with going down that route -- there is no H so there can't
>>>> be an
>>>> H1 that does better.  Once this objection is properly examined, it
>>>> turns
>>>> out to be the argument I ended up preferring anyway.  H isn't a halt
>>>> decider, it's just any old TM and we show it can't be halt decider for
>>>> one reason or another.
>>>>
>>>
>>> Unless your students are extremely pedantic... maybe they are... I
>>> don't see what's illogical with:
>>>
>>> "I think H is a halt decider."
>>> "But it doesn't: see this proof."
>>> "Oh. Well, even though H isn't a halt decider, how do we know there
>>> isn't a program H1 which is a halt decider?"
>>> "The proof would still work for H1, or H2, or any other program you
>>> think is a halt decider."
>>>
>>>
>>
>> It is an easily verified fact that:
>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address 00001422
>> *different machine addresses is the reason for different return values*
>>
>>
>
> Which proves that H1 and H are different computation and thus different
> Turing Machines, so H1 getting the right answer doesn't "fix" H's
> getting the wrong answer.
>

Good catch !!!

For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
its own TMD concatenated to this input to its Boolean result.

Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
concatenated to this input to its Boolean result.

thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
cannot.

> H1^ will confound H1, thus showing it isn't a halt decider either.

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

On 3/7/24 11:11 AM, olcott wrote:
> On 3/7/2024 12:46 PM, Richard Damon wrote:
>> On 3/7/24 10:30 AM, olcott wrote:
>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>> immibis <news@immibis.com> writes:
>>>>>
>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>> The students I taught seemed to have no problem with this sort of
>>>>>>> case
>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>> "but H1
>>>>>>> could be better" arguments.
>>>>>>
>>>>>> They aren't satisfied with "we can do the exact same thing with H1
>>>>>> to prove
>>>>>> that H1 doesn't work either"?
>>>>>
>>>>> In the vast majority of cases, yes, but even then there is a logical
>>>>> problem with going down that route -- there is no H so there can't
>>>>> be an
>>>>> H1 that does better.  Once this objection is properly examined, it
>>>>> turns
>>>>> out to be the argument I ended up preferring anyway.  H isn't a halt
>>>>> decider, it's just any old TM and we show it can't be halt decider for
>>>>> one reason or another.
>>>>>
>>>>
>>>> Unless your students are extremely pedantic... maybe they are... I
>>>> don't see what's illogical with:
>>>>
>>>> "I think H is a halt decider."
>>>> "But it doesn't: see this proof."
>>>> "Oh. Well, even though H isn't a halt decider, how do we know there
>>>> isn't a program H1 which is a halt decider?"
>>>> "The proof would still work for H1, or H2, or any other program you
>>>> think is a halt decider."
>>>>
>>>>
>>>
>>> It is an easily verified fact that:
>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>> 00001422
>>> *different machine addresses is the reason for different return values*
>>>
>>>
>>
>> Which proves that H1 and H are different computation and thus
>> different Turing Machines, so H1 getting the right answer doesn't
>> "fix" H's getting the wrong answer.
>>
>
> Good catch !!!
>
> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
> its own TMD concatenated to this input to its Boolean result.
>
> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
> concatenated to this input to its Boolean result.
>
> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
> cannot.

Which only indicates that either you built your H^ incorrectly, as H^.H
is supposed to do exactly the same thing as H itself, or if that is
impossible to do, that your modification to Turing Machine rules have
made your system not-Turing Complete, as you are admitting that the is a
Computation that could be made with Turing Machines (H^ from a given H)
that you can't make in Olcott-Machines.

>
>> H1^ will confound H1, thus showing it isn't a halt decider either.
>

On 3/7/2024 1:15 PM, Richard Damon wrote:
> On 3/7/24 11:11 AM, olcott wrote:
>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>> On 3/7/24 10:30 AM, olcott wrote:
>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>> immibis <news@immibis.com> writes:
>>>>>>
>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>> The students I taught seemed to have no problem with this sort
>>>>>>>> of case
>>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>>> "but H1
>>>>>>>> could be better" arguments.
>>>>>>>
>>>>>>> They aren't satisfied with "we can do the exact same thing with
>>>>>>> H1 to prove
>>>>>>> that H1 doesn't work either"?
>>>>>>
>>>>>> In the vast majority of cases, yes, but even then there is a logical
>>>>>> problem with going down that route -- there is no H so there can't
>>>>>> be an
>>>>>> H1 that does better.  Once this objection is properly examined, it
>>>>>> turns
>>>>>> out to be the argument I ended up preferring anyway.  H isn't a halt
>>>>>> decider, it's just any old TM and we show it can't be halt decider
>>>>>> for
>>>>>> one reason or another.
>>>>>>
>>>>>
>>>>> Unless your students are extremely pedantic... maybe they are... I
>>>>> don't see what's illogical with:
>>>>>
>>>>> "I think H is a halt decider."
>>>>> "But it doesn't: see this proof."
>>>>> "Oh. Well, even though H isn't a halt decider, how do we know there
>>>>> isn't a program H1 which is a halt decider?"
>>>>> "The proof would still work for H1, or H2, or any other program you
>>>>> think is a halt decider."
>>>>>
>>>>>
>>>>
>>>> It is an easily verified fact that:
>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>> 00001422
>>>> *different machine addresses is the reason for different return values*
>>>>
>>>>
>>>
>>> Which proves that H1 and H are different computation and thus
>>> different Turing Machines, so H1 getting the right answer doesn't
>>> "fix" H's getting the wrong answer.
>>>
>>
>> Good catch !!!
>>
>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>> its own TMD concatenated to this input to its Boolean result.
>>
>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>> concatenated to this input to its Boolean result.
>>
>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>> cannot.
>
> Which only indicates that either you built your H^ incorrectly, as H^.H
> is supposed to do exactly the same thing as H itself,

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
only if they have the same input.

When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.

> or if that is
> impossible to do, that your modification to Turing Machine rules have
> made your system not-Turing Complete, as you are admitting that the is a
> Computation that could be made with Turing Machines (H^ from a given H)
> that you can't make in Olcott-Machines.
>

You are not evaluating Turing Complete correctly. Olcott machines
exactly compute all of the same decision problems that Turing
machines compute when the Olcott machines ignore their own TMD.

In addition to this it seems that some decision problems that
Turing machines CANNOT compute can be computed by Olcott machines.

>>
>>> H1^ will confound H1, thus showing it isn't a halt decider either.
>>
>

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

On 3/7/24 11:37 AM, olcott wrote:
> On 3/7/2024 1:15 PM, Richard Damon wrote:
>> On 3/7/24 11:11 AM, olcott wrote:
>>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>>> On 3/7/24 10:30 AM, olcott wrote:
>>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>>> immibis <news@immibis.com> writes:
>>>>>>>
>>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>>> The students I taught seemed to have no problem with this sort
>>>>>>>>> of case
>>>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>>>> "but H1
>>>>>>>>> could be better" arguments.
>>>>>>>>
>>>>>>>> They aren't satisfied with "we can do the exact same thing with
>>>>>>>> H1 to prove
>>>>>>>> that H1 doesn't work either"?
>>>>>>>
>>>>>>> In the vast majority of cases, yes, but even then there is a logical
>>>>>>> problem with going down that route -- there is no H so there
>>>>>>> can't be an
>>>>>>> H1 that does better.  Once this objection is properly examined,
>>>>>>> it turns
>>>>>>> out to be the argument I ended up preferring anyway.  H isn't a halt
>>>>>>> decider, it's just any old TM and we show it can't be halt
>>>>>>> decider for
>>>>>>> one reason or another.
>>>>>>>
>>>>>>
>>>>>> Unless your students are extremely pedantic... maybe they are... I
>>>>>> don't see what's illogical with:
>>>>>>
>>>>>> "I think H is a halt decider."
>>>>>> "But it doesn't: see this proof."
>>>>>> "Oh. Well, even though H isn't a halt decider, how do we know
>>>>>> there isn't a program H1 which is a halt decider?"
>>>>>> "The proof would still work for H1, or H2, or any other program
>>>>>> you think is a halt decider."
>>>>>>
>>>>>>
>>>>>
>>>>> It is an easily verified fact that:
>>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>>> 00001422
>>>>> *different machine addresses is the reason for different return
>>>>> values*
>>>>>
>>>>>
>>>>
>>>> Which proves that H1 and H are different computation and thus
>>>> different Turing Machines, so H1 getting the right answer doesn't
>>>> "fix" H's getting the wrong answer.
>>>>
>>>
>>> Good catch !!!
>>>
>>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>>> its own TMD concatenated to this input to its Boolean result.
>>>
>>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>>> concatenated to this input to its Boolean result.
>>>
>>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> cannot.
>>
>> Which only indicates that either you built your H^ incorrectly, as
>> H^.H is supposed to do exactly the same thing as H itself,
>
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
> only if they have the same input.
>
> When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
> have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
> and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.

And a machone that depends on anythohng other than the description of
the input is provvably NOT a Halt Decider, so you are just admitting
that H isn't a Halt Decider, since for some values of description, it
gives the wrong answer.

>
>> or if that is impossible to do, that your modification to Turing
>> Machine rules have made your system not-Turing Complete, as you are
>> admitting that the is a Computation that could be made with Turing
>> Machines (H^ from a given H) that you can't make in Olcott-Machines.
>>
>
> You are not evaluating Turing Complete correctly. Olcott machines
> exactly compute all of the same decision problems that Turing
> machines compute when the Olcott machines ignore their own TMD.

Right, but if they don't then they can't be said to compute the mapping
that ignores that input.

So, since H doesn't ignore its extra input, it doesn't compute that
mapping called Halting, that isn't dependent on the machine deciding.

>
> In addition to this it seems that some decision problems that
> Turing machines CANNOT compute can be computed by Olcott machines.

Nope. you only think that because you don't understand what a
computation is, and you refuse to learn, making you just a stupid and
ignorant pathological lying idiot.

>
>>>
>>>> H1^ will confound H1, thus showing it isn't a halt decider either.
>>>
>>
>

On 3/7/2024 1:57 PM, Richard Damon wrote:
> On 3/7/24 11:37 AM, olcott wrote:
>> On 3/7/2024 1:15 PM, Richard Damon wrote:
>>> On 3/7/24 11:11 AM, olcott wrote:
>>>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>>>> On 3/7/24 10:30 AM, olcott wrote:
>>>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>>>> immibis <news@immibis.com> writes:
>>>>>>>>
>>>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>>>> The students I taught seemed to have no problem with this sort
>>>>>>>>>> of case
>>>>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>>>>> "but H1
>>>>>>>>>> could be better" arguments.
>>>>>>>>>
>>>>>>>>> They aren't satisfied with "we can do the exact same thing with
>>>>>>>>> H1 to prove
>>>>>>>>> that H1 doesn't work either"?
>>>>>>>>
>>>>>>>> In the vast majority of cases, yes, but even then there is a
>>>>>>>> logical
>>>>>>>> problem with going down that route -- there is no H so there
>>>>>>>> can't be an
>>>>>>>> H1 that does better.  Once this objection is properly examined,
>>>>>>>> it turns
>>>>>>>> out to be the argument I ended up preferring anyway.  H isn't a
>>>>>>>> halt
>>>>>>>> decider, it's just any old TM and we show it can't be halt
>>>>>>>> decider for
>>>>>>>> one reason or another.
>>>>>>>>
>>>>>>>
>>>>>>> Unless your students are extremely pedantic... maybe they are...
>>>>>>> I don't see what's illogical with:
>>>>>>>
>>>>>>> "I think H is a halt decider."
>>>>>>> "But it doesn't: see this proof."
>>>>>>> "Oh. Well, even though H isn't a halt decider, how do we know
>>>>>>> there isn't a program H1 which is a halt decider?"
>>>>>>> "The proof would still work for H1, or H2, or any other program
>>>>>>> you think is a halt decider."
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> It is an easily verified fact that:
>>>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>>>> 00001422
>>>>>> *different machine addresses is the reason for different return
>>>>>> values*
>>>>>>
>>>>>>
>>>>>
>>>>> Which proves that H1 and H are different computation and thus
>>>>> different Turing Machines, so H1 getting the right answer doesn't
>>>>> "fix" H's getting the wrong answer.
>>>>>
>>>>
>>>> Good catch !!!
>>>>
>>>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>>>> its own TMD concatenated to this input to its Boolean result.
>>>>
>>>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>>>> concatenated to this input to its Boolean result.
>>>>
>>>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>>>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> cannot.
>>>
>>> Which only indicates that either you built your H^ incorrectly, as
>>> H^.H is supposed to do exactly the same thing as H itself,
>>
>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
>> only if they have the same input.
>>
>> When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
>> have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>> and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.
>
> And a machone that depends on anythohng other than the description of
> the input is provvably NOT a Halt Decider,

When it correctly determines the actual halt status of an
actual input TMD+Finite_String then it correctly decided
this TMD+Finite_String.

No one can say that it gets the wrong answer when it
gets the right answer.

The most than anyone can say is that this answer may
not be Turing computable.

When an Olcott machine maps TMD+Finite_String+Own_TMD
to a Boolean value then this Olcott machine derives
its output as a pure function of its inputs.

> so you are just admitting
> that H isn't a Halt Decider, since for some values of description, it
> gives the wrong answer.
>
>>
>>> or if that is impossible to do, that your modification to Turing
>>> Machine rules have made your system not-Turing Complete, as you are
>>> admitting that the is a Computation that could be made with Turing
>>> Machines (H^ from a given H) that you can't make in Olcott-Machines.
>>>
>>
>> You are not evaluating Turing Complete correctly. Olcott machines
>> exactly compute all of the same decision problems that Turing
>> machines compute when the Olcott machines ignore their own TMD.
>
> Right, but if they don't then they can't be said to compute the mapping
> that ignores that input.
>
> So, since H doesn't ignore its extra input, it doesn't compute that
> mapping called Halting, that isn't dependent on the machine deciding.

The set of Olcott machines that compute the mapping from
their inputs (ignoring their own TMD) to an output is
exactly the same set as the set of Turing machines that
compute the mapping from their inputs to their own output.

This analysis proves that a subset of Olcott machines
compute the same set as the set of Turing machines.

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

On 3/7/24 12:18 PM, olcott wrote:
> On 3/7/2024 1:57 PM, Richard Damon wrote:
>> On 3/7/24 11:37 AM, olcott wrote:
>>> On 3/7/2024 1:15 PM, Richard Damon wrote:
>>>> On 3/7/24 11:11 AM, olcott wrote:
>>>>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>>>>> On 3/7/24 10:30 AM, olcott wrote:
>>>>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>>>>> immibis <news@immibis.com> writes:
>>>>>>>>>
>>>>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>>>>> The students I taught seemed to have no problem with this
>>>>>>>>>>> sort of case
>>>>>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>>>>>> "but H1
>>>>>>>>>>> could be better" arguments.
>>>>>>>>>>
>>>>>>>>>> They aren't satisfied with "we can do the exact same thing
>>>>>>>>>> with H1 to prove
>>>>>>>>>> that H1 doesn't work either"?
>>>>>>>>>
>>>>>>>>> In the vast majority of cases, yes, but even then there is a
>>>>>>>>> logical
>>>>>>>>> problem with going down that route -- there is no H so there
>>>>>>>>> can't be an
>>>>>>>>> H1 that does better.  Once this objection is properly examined,
>>>>>>>>> it turns
>>>>>>>>> out to be the argument I ended up preferring anyway.  H isn't a
>>>>>>>>> halt
>>>>>>>>> decider, it's just any old TM and we show it can't be halt
>>>>>>>>> decider for
>>>>>>>>> one reason or another.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Unless your students are extremely pedantic... maybe they are...
>>>>>>>> I don't see what's illogical with:
>>>>>>>>
>>>>>>>> "I think H is a halt decider."
>>>>>>>> "But it doesn't: see this proof."
>>>>>>>> "Oh. Well, even though H isn't a halt decider, how do we know
>>>>>>>> there isn't a program H1 which is a halt decider?"
>>>>>>>> "The proof would still work for H1, or H2, or any other program
>>>>>>>> you think is a halt decider."
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> It is an easily verified fact that:
>>>>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>>>>> 00001422
>>>>>>> *different machine addresses is the reason for different return
>>>>>>> values*
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Which proves that H1 and H are different computation and thus
>>>>>> different Turing Machines, so H1 getting the right answer doesn't
>>>>>> "fix" H's getting the wrong answer.
>>>>>>
>>>>>
>>>>> Good catch !!!
>>>>>
>>>>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>>>>> its own TMD concatenated to this input to its Boolean result.
>>>>>
>>>>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>>>>> concatenated to this input to its Boolean result.
>>>>>
>>>>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>>>>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> cannot.
>>>>
>>>> Which only indicates that either you built your H^ incorrectly, as
>>>> H^.H is supposed to do exactly the same thing as H itself,
>>>
>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> only if they have the same input.
>>>
>>> When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
>>> have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.
>>
>> And a machone that depends on anythohng other than the description of
>> the input is provvably NOT a Halt Decider,
>
> When it correctly determines the actual halt status of an
> actual input TMD+Finite_String then it correctly decided
> this TMD+Finite_String.

And the finite string needs to be EXACTLY the input given to that Turing
Machine that was Described.

>
> No one can say that it gets the wrong answer when it
> gets the right answer.

But if H, given the description of H^ applied to its description says it
doesn't halt, but when H^ is applied to its description it does, then it
was wrong.

If the copy of H inside H^ does give the exact same answer as H did,
then you built H^ wrong, and are lying, or if you can't, you just proved
you system is not Turing Complete, as there is a computation built with
Turing machines that you can not replicate.
>
> The most than anyone can say is that this answer may
> not be Turing computable.

And thus not Computable, as Turing Machine EXACTLY match the ACTUAL
definition of Computable.

>
> When an Olcott machine maps TMD+Finite_String+Own_TMD
> to a Boolean value then this Olcott machine derives
> its output as a pure function of its inputs.

But the WRONG function to be a Halt Decider.

You don't seem to understand that, because you are just too stupid to
understand what a Computation actually is, or what Requirment actually
means.

>
>> so you are just admitting that H isn't a Halt Decider, since for some
>> values of description, it gives the wrong answer.
>>
>>>
>>>> or if that is impossible to do, that your modification to Turing
>>>> Machine rules have made your system not-Turing Complete, as you are
>>>> admitting that the is a Computation that could be made with Turing
>>>> Machines (H^ from a given H) that you can't make in Olcott-Machines.
>>>>
>>>
>>> You are not evaluating Turing Complete correctly. Olcott machines
>>> exactly compute all of the same decision problems that Turing
>>> machines compute when the Olcott machines ignore their own TMD.
>>
>> Right, but if they don't then they can't be said to compute the
>> mapping that ignores that input.
>>
>> So, since H doesn't ignore its extra input, it doesn't compute that
>> mapping called Halting, that isn't dependent on the machine deciding.
>
> The set of Olcott machines that compute the mapping from
> their inputs (ignoring their own TMD) to an output is
> exactly the same set as the set of Turing machines that
> compute the mapping from their inputs to their own output.

Right, and since your Halt Decider isn't in that set.

>
> This analysis proves that a subset of Olcott machines
> compute the same set as the set of Turing machines.
>

But since H is just an Olcott machine, that is claimed to produce a
COmputation, then H^ can include a copy of it in its code to EXACTLY
repoduce its instructions, and the data on the tape that represents it
(remember, H^ know the description of H, so it can include that on the
tape itself).

Since the Master UTM can't tell when H^ transitions into its submachine
H to interfere with that behavior (it is just another set of states
within H^) then that H sub-machine will see EXACTLY the same input, even
the same description of itself, and thus MUST generate exactly the same
output as the actual H run from the master UTM.

The rules you defined do not allow for any limitation in the
manipulation of the Tape within a machine, so H^ can totally reproduce
the environment that the top level H sees, and thus gets the exact same
answer.

On 3/7/2024 2:59 PM, Richard Damon wrote:
> On 3/7/24 12:18 PM, olcott wrote:
>> On 3/7/2024 1:57 PM, Richard Damon wrote:
>>> On 3/7/24 11:37 AM, olcott wrote:
>>>> On 3/7/2024 1:15 PM, Richard Damon wrote:
>>>>> On 3/7/24 11:11 AM, olcott wrote:
>>>>>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>>>>>> On 3/7/24 10:30 AM, olcott wrote:
>>>>>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>>>>>> immibis <news@immibis.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>>>>>> The students I taught seemed to have no problem with this
>>>>>>>>>>>> sort of case
>>>>>>>>>>>> analysis.  But the "assume H does X" argument lead to lots
>>>>>>>>>>>> of "but H1
>>>>>>>>>>>> could be better" arguments.
>>>>>>>>>>>
>>>>>>>>>>> They aren't satisfied with "we can do the exact same thing
>>>>>>>>>>> with H1 to prove
>>>>>>>>>>> that H1 doesn't work either"?
>>>>>>>>>>
>>>>>>>>>> In the vast majority of cases, yes, but even then there is a
>>>>>>>>>> logical
>>>>>>>>>> problem with going down that route -- there is no H so there
>>>>>>>>>> can't be an
>>>>>>>>>> H1 that does better.  Once this objection is properly
>>>>>>>>>> examined, it turns
>>>>>>>>>> out to be the argument I ended up preferring anyway.  H isn't
>>>>>>>>>> a halt
>>>>>>>>>> decider, it's just any old TM and we show it can't be halt
>>>>>>>>>> decider for
>>>>>>>>>> one reason or another.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Unless your students are extremely pedantic... maybe they
>>>>>>>>> are... I don't see what's illogical with:
>>>>>>>>>
>>>>>>>>> "I think H is a halt decider."
>>>>>>>>> "But it doesn't: see this proof."
>>>>>>>>> "Oh. Well, even though H isn't a halt decider, how do we know
>>>>>>>>> there isn't a program H1 which is a halt decider?"
>>>>>>>>> "The proof would still work for H1, or H2, or any other program
>>>>>>>>> you think is a halt decider."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is an easily verified fact that:
>>>>>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>>>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>>>>>> 00001422
>>>>>>>> *different machine addresses is the reason for different return
>>>>>>>> values*
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Which proves that H1 and H are different computation and thus
>>>>>>> different Turing Machines, so H1 getting the right answer doesn't
>>>>>>> "fix" H's getting the wrong answer.
>>>>>>>
>>>>>>
>>>>>> Good catch !!!
>>>>>>
>>>>>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>>>>>> its own TMD concatenated to this input to its Boolean result.
>>>>>>
>>>>>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>>>>>> concatenated to this input to its Boolean result.
>>>>>>
>>>>>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>>>>>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> cannot.
>>>>>
>>>>> Which only indicates that either you built your H^ incorrectly, as
>>>>> H^.H is supposed to do exactly the same thing as H itself,
>>>>
>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> only if they have the same input.
>>>>
>>>> When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
>>>> have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.
>>>
>>> And a machone that depends on anythohng other than the description of
>>> the input is provvably NOT a Halt Decider,
>>
>> When it correctly determines the actual halt status of an
>> actual input TMD+Finite_String then it correctly decided
>> this TMD+Finite_String.
>
> And the finite string needs to be EXACTLY the input given to that Turing
> Machine that was Described.
>
>>
>> No one can say that it gets the wrong answer when it
>> gets the right answer.
>
>
> But if H, given the description of H^ applied to its description says it
> doesn't halt, but when H^ is applied to its description it does, then it
> was wrong.
>

New thread has all of the relevant details in one place
[We finally know exactly how H1(D,D) derives a different result than H(D,D)]
This make it much easier for people seeing this for the first time.

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

On 2024-03-07 15:27:21 +0000, olcott said:

> On 3/7/2024 4:33 AM, Mikko wrote:
>> On 2024-03-07 00:24:43 +0000, olcott said:
>>
>>> If knowing its own machine description allows Olcott
>>> machines to decide halting on Turing Machine descriptions
>>> and TMs cannot do this then Church-Turing is refuted.
>>
>> If. There is no reason to think your machine can compute anything
>> that is not Truring computable.
>>
>
> No reason that you are aware of because you have
> not read all of the threads.

There a too many messages, so it is impossible to read them all.
But none of the ones I have read so far has a pointer to to a
web page that present a reason to think that your macnines could
compute something that a Turing machine can't. For example, a
aproof that a Turing machine cannot simulate your machine would
be at least a step to that direction.

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt
>
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ can determine that it is being called in recursive
> simulation by simply comparing it own TMD to its input and
> finding a match.

--
Mikko

On 3/8/2024 5:16 AM, Mikko wrote:
> On 2024-03-07 15:27:21 +0000, olcott said:
>
>> On 3/7/2024 4:33 AM, Mikko wrote:
>>> On 2024-03-07 00:24:43 +0000, olcott said:
>>>
>>>> If knowing its own machine description allows Olcott
>>>> machines to decide halting on Turing Machine descriptions
>>>> and TMs cannot do this then Church-Turing is refuted.
>>>
>>> If. There is no reason to think your machine can compute anything
>>> that is not Truring computable.
>>>
>>
>> No reason that you are aware of because you have
>> not read all of the threads.
>
> There a too many messages, so it is impossible to read them all.
> But none of the ones I have read so far has a pointer to to a
> web page that present a reason to think that your macnines could
> compute something that a Turing machine can't. For example, a
> aproof that a Turing machine cannot simulate your machine would
> be at least a step to that direction.
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>
>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ can determine that it is being called in recursive
>> simulation by simply comparing it own TMD to its input and
>> finding a match.
>

*I keep summing up my latest position, here is the key part of it*
I am working on the computability of the halting problem
(the exact same TMD / input pairs) by a slightly augmented
notion of Turing machines as elaborated below:

Olcott machines are entirely comprised of a UTM + TMD and one
extra step that any UTM could perform, append the TMD to the
end of its own tape.

Olcott machines that ignore this extra input compute the exact
same set of functions that Turing machines compute.

Olcott machines can do something that no Turing machine can
possibly do correctly determine that they themselves are called
in recursive simulation

I have proved that a slight reconfiguration of Turing machines
defines a machine that is exactly a Turing machine except can
always correctly determine whether or not itself is called in
recursive simulation.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
copy of itself with a copy of its own input thus immediately
detects recursive simulation just like H(D,D).

H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> immediately detects that is NOT about to simulate a
copy of itself with a copy of its own input thus immediately
rejects recursive simulation just like H1(D,D).

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

On 3/1/2024 12:41 PM, Mike Terry wrote:
> On 01/03/2024 17:55, olcott wrote:
>> On 3/1/2024 11:42 AM, Mike Terry wrote:
>>> On 01/03/2024 06:14, olcott wrote:
>>>> On 2/29/2024 10:18 PM, Richard Damon wrote:
>>>>> On 2/29/24 10:42 PM, olcott wrote:
>>>>>> On 2/29/2024 8:28 PM, Richard Damon wrote:
>>>>>>> On 2/29/24 5:29 PM, olcott wrote:
>>>>>>>> On 2/29/2024 4:24 PM, wij wrote:
>>>>>>>>> On Thu, 2024-02-29 at 16:13 -0600, olcott wrote:
>>>>>>>>>> On 2/29/2024 4:06 PM, wij wrote:
>>>>>>>>>>> On Thu, 2024-02-29 at 15:59 -0600, olcott wrote:
>>>>>>>>>>>> On 2/29/2024 3:50 PM, wij wrote:
>>>>>>>>>>>>> On Thu, 2024-02-29 at 15:27 -0600, olcott wrote:
>>>>>>>>>>>>>> On 2/29/2024 3:15 PM, wij wrote:
>>>>>>>>>>>>>>> On Thu, 2024-02-29 at 15:07 -0600, olcott wrote:
>>>>>>>>>>>>>>>> On 2/29/2024 3:00 PM, wij wrote:
>>>>>>>>>>>>>>>>> On Thu, 2024-02-29 at 14:51 -0600, olcott wrote:
>>>>>>>>>>>>>>>>>> On 2/29/2024 2:48 PM, wij wrote:
>>>>>>>>>>>>>>>>>>> On Thu, 2024-02-29 at 13:46 -0600, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 2/29/2024 1:37 PM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>> On 2024-02-29 15:51:56 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ (in a separate memory space) merely
>>>>>>>>>>>>>>>>>>>>>> needs to report on
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A Turing machine is not in any memory space.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That no memory space is specified because Turing
>>>>>>>>>>>>>>>>>>>> machines
>>>>>>>>>>>>>>>>>>>> are imaginary fictions does not entail that they
>>>>>>>>>>>>>>>>>>>> have no
>>>>>>>>>>>>>>>>>>>> memory space. The actual memory space of actual Turing
>>>>>>>>>>>>>>>>>>>> machines is the human memory where these ideas are
>>>>>>>>>>>>>>>>>>>> located.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The entire notion of undecidability when it depends on
>>>>>>>>>>>>>>>>>>>> epistemological antinomies is incoherent.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> People that learn these things by rote never notice
>>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>> Philosophers that examine these things looking for
>>>>>>>>>>>>>>>>>>>> incoherence find it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ...14 Every epistemological antinomy can likewise be
>>>>>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>>>>> for a similar undecidability proof...(Gödel 1931:43)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So, do you agree what GUR says?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> People believes GUR. Why struggle so painfully,
>>>>>>>>>>>>>>>>>>> playing idiot everyday ?
>>>>>>>>>>>>>>>>>>> Give in, my friend.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Graphical User Robots?
>>>>>>>>>>>>>>>>>> The survival of the species depends on a correct
>>>>>>>>>>>>>>>>>> understanding of truth.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> People believes GUR are going to survive.
>>>>>>>>>>>>>>>>> People does not believe GUR are going to vanish.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What the Hell is GUR ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Selective memory?
>>>>>>>>>>>>>>> https://groups.google.com/g/comp.theory/c/_tbCYyMox9M/m/XgvkLGOQAwAJ
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Basically, GUR says that no one even your god can defy
>>>>>>>>>>>>>>> that HP is undecidable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I simplify that down to this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...14 Every epistemological antinomy can likewise be used for
>>>>>>>>>>>>>> a similar undecidability proof...(Gödel 1931:43)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The general notion of decision problem undecidability is
>>>>>>>>>>>>>> fundamentally
>>>>>>>>>>>>>> flawed in all of those cases where a decider is required
>>>>>>>>>>>>>> to correctly
>>>>>>>>>>>>>> answer a self-contradictory (thus incorrect) question.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When we account for this then epistemological antinomies
>>>>>>>>>>>>>> are always
>>>>>>>>>>>>>> excluded from the domain of every decision problem making
>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>> these decision problems decidable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems you try to change what the halting problem again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>> In computability theory, the halting problem is the problem
>>>>>>>>>>>>> of determining, from a description
>>>>>>>>>>>>> of
>>>>>>>>>>>>> an
>>>>>>>>>>>>> arbitrary computer program and an input, whether the
>>>>>>>>>>>>> program will finish running, or continue
>>>>>>>>>>>>> to
>>>>>>>>>>>>> run
>>>>>>>>>>>>> forever....
>>>>>>>>>>>>>
>>>>>>>>>>>>> This wiki definition had been shown many times. But, since
>>>>>>>>>>>>> your English is
>>>>>>>>>>>>> terrible, you often read it as something else (actually,
>>>>>>>>>>>>> deliberately
>>>>>>>>>>>>> interpreted it differently, so called 'lie')
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you want to refute Halting Problem, you must first
>>>>>>>>>>>>> understand what the
>>>>>>>>>>>>> problem is about, right? You never hit the target that
>>>>>>>>>>>>> every one can see, but POOP.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Note: My email was delivered strangely. It swapped to
>>>>>>>>>>> sci.logic !!!
>>>>>>>>>>>
>>>>>>>>>>>> If we have the decision problem that no one can answer this
>>>>>>>>>>>> question:
>>>>>>>>>>>> Is this sentence true or false: "What time is it?"
>>>>>>>>>>>
>>>>>>>>>>> This is not the halting problem.
>>>>>>>>>>>
>>>>>>>>>>>> Someone has to point out that there is something wrong with it.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is another problem (not the HP neither)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The halting problem is one of many problems that is
>>>>>>>>>> only "undecidable" because the notion of decidability
>>>>>>>>>> incorrectly requires a correct answer to a self-contradictory
>>>>>>>>>> (thus incorrect) question.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What is the 'correct answer' to all HP like problems ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The correct answer to all undecidable decision problems
>>>>>>>> that rely on self-contradictory input to determine
>>>>>>>> undecidability is to reject this input as outside of the
>>>>>>>> domain of any and all decision problems. This applies
>>>>>>>> to the Halting Problem and many others.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In other words, just define that some Turing Machines aren't
>>>>>>> actually Turing Machines, or aren't Turing Machines if they are
>>>>>>> given certain inputs.
>>>>>>>
>>>>>>
>>>>>> No not at all simply make a Turing Machine that does this:
>>>>>>
>>>>>> LP = "This sentence is not true."
>>>>>> Boolean True(English, LP)  is false
>>>>>> Boolean True(English, ~LP) is false
>>>>>
>>>>> In other words, you are admitting that you havve absolutly NO idea
>>>>> what a Turing Machine is, and what it can do.
>>>>>
>>>>
>>>> Not at all this is the high level architectural design of
>>>> a system that could be implemented as a Turing machine.
>>>>
>>>>> You don't even seem to understand what you need to do to program
>>>>> something.
>>>>
>>>> That is proven to be ridiculous by my fully operational code.
>>>> that created the x86utm operating system entirely out of an
>>>> excellent x86 emulator. It was very tricky to get HH to simulate
>>>> itself to an arbitrary recursive depth.
>>>
>>> BUT....  Your HH code is completely broken!
>>>
>>> It uses static variables like execution_trace shared across
>>> simulations.  The effect of this is that nested simulations see (and
>>> actively examine as part of their decision logic) trace entries from
>>> parent simulators.  A valid simulation cannot do that - your program
>>> logic is Wrong.
>>
>> (1) This is moot.
>> (2) A UTM can share a portion of its own tape with the machine that it
>> is simulating so that it can see this machines own internal data.
>>
>>> I thought you had claimed to have fixed that problem, and you
>>> certainly never corrected me when I mentioned that I thought you had
>>> fixed it in an earlier post.  It seems you never fixed it, SO IT'S
>>> STILL BROKEN.
>>>
>>
>> H is able to correctly determine that D is calling itself thus
>> no need for the UTM to share a portion of its own tape with
>> the machine that it is simulating.
>>
>>> What you did instead, it seems, was change from using HH to using H,
>>> the latter not requiring nested simulation to work as intended.  And
>>> yet you still throw out references to your "HH using nested
>>> simulation" and "arbitrary recursive depth" as though you had
>>> actually fixed it - very dishonest of you.
>>>
>>
>> Not the slightest little bit. The original H was renamed to HH.
>> Because a UTM actually can share a portion of its own tape with
>> the machine it is simulating HH may actually be the preferred version.
>
> Obviously a simulator has access to the internal state (tape contents
> etc.) of the simulated machine.  No problem there.
>
> What isn't allowed is the simulated machine altering its own behaviour
> by accessing data outside of its own state.  (I.e. accessing data from
> its parent simulators state.)
>
> While an "active-simulator" [my own term] is at liberty to combine
> straight simulation with add-on "enhancements" that extend the
> functionality of the simulated machine,

On 2024-05-10 18:16:37 +0000, olcott said:

> On 3/1/2024 12:41 PM, Mike Terry wrote:

>> Obviously a simulator has access to the internal state (tape contents
>> etc.) of the simulated machine.  No problem there.
>>
>> What isn't allowed is the simulated machine altering its own behaviour
>> by accessing data outside of its own state.  (I.e. accessing data from
>> its parent simulators state.)
>>
>> While an "active-simulator" [my own term] is at liberty to combine
>> straight simulation with add-on "enhancements" that extend the
>> functionality of the simulated machine, in doing so it would no
>> longer be a simulator in the sense you need it to be.  So you
>> mustn't do this!

In principle an incorrect simulation is permissible. However, to prove
that the result inferred from an incorrect simulation is correct may
be impossible.

> *You did not provide complete reasoning justifying this proclamation*
> *You did not provide complete reasoning justifying this proclamation*
> *You did not provide complete reasoning justifying this proclamation*

The provided reasoning is sufficient. You can continue reasoning from
that if you want more.

> Because the simulator must perform every detail of the simulation of
> the underlying machine it can watch every single state change of this
> underlying machine and this does not change the behavior of the
> simulated input AT ALL (relative to not watching the state changes).

Yes, that is a correct interpretation.

--
Mikko

On 5/11/2024 3:00 AM, Mikko wrote:
> On 2024-05-10 18:16:37 +0000, olcott said:
>
>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>
>>> Obviously a simulator has access to the internal state (tape contents
>>> etc.) of the simulated machine.  No problem there.
>>>
>>> What isn't allowed is the simulated machine altering its own
>>> behaviour by accessing data outside of its own state.  (I.e.
>>> accessing data from its parent simulators state.)
>>>
>>> While an "active-simulator" [my own term] is at liberty to combine
>>> straight simulation with add-on "enhancements" that extend the
>>> functionality of the simulated machine, in doing so it would no
>>> longer be a simulator in the sense you need it to be.  So you
>>> mustn't do this!
>
> In principle an incorrect simulation is permissible. However, to prove
> that the result inferred from an incorrect simulation is correct may
> be impossible.
>

Within the conventional terms-of-the-art of {termination analyzer}
and {simulator} an incorrect simulation is forbidden.

>> *You did not provide complete reasoning justifying this proclamation*
>> *You did not provide complete reasoning justifying this proclamation*
>> *You did not provide complete reasoning justifying this proclamation*
>
> The provided reasoning is sufficient. You can continue reasoning from
> that if you want more.
>

*He is SIMPLY WRONG and when he tries*
*to justify what he said he will fail*

Any pure x86 emulator or UTM can have the added functionality
of watching every state change of its simulated input without
changing the simulated steps of this input relative to an
unmodified x86 emulator or UTM.

*SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*

>> Because the simulator must perform every detail of the simulation of
>> the underlying machine it can watch every single state change of this
>> underlying machine and this does not change the behavior of the
>> simulated input AT ALL (relative to not watching the state changes).
>
> Yes, that is a correct interpretation.
>

OK Great!
So a simulating termination analyzer could watch the behavior of its
input and analyze this watched behavior and transition to a non-final
state that indicates non-halting and then go back and continue
simulating the non-halting input and it remains a simulator all along.

*This would not be a halt decider because all deciders must halt*
*It would be an unconventional termination analyzer*

*It does correctly report that its pathological input never halts*

*This method does work correctly on the H/D template*
*and the Ĥ applied to ⟨Ĥ⟩ template shown below*

00 int H(ptr x, ptr x) // ptr is pointer to int function
01 int D(ptr x)
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 H(D,D);
12 }

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

*Termination Analyzer H is Not Fooled by Pathological Input D*
https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

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

On 11/05/2024 17:06, olcott wrote:
> On 5/11/2024 3:00 AM, Mikko wrote:
>> On 2024-05-10 18:16:37 +0000, olcott said:
>>
>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>
>>>> Obviously a simulator has access to the internal state (tape contents etc.) of the simulated
>>>> machine.  No problem there.
>>>>
>>>> What isn't allowed is the simulated machine altering its own behaviour by accessing data outside
>>>> of its own state.  (I.e. accessing data from its parent simulators state.)
>>>>
>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>> straight simulation with add-on "enhancements" that extend the
>>>> functionality of the simulated machine, in doing so it would no
>>>> longer be a simulator in the sense you need it to be.  So you
>>>> mustn't do this!
>>
>> In principle an incorrect simulation is permissible. However, to prove
>> that the result inferred from an incorrect simulation is correct may
>> be impossible.
>>
>
> Within the conventional terms-of-the-art of {termination analyzer}
> and {simulator} an incorrect simulation is forbidden.
>
>>> *You did not provide complete reasoning justifying this proclamation*
>>> *You did not provide complete reasoning justifying this proclamation*
>>> *You did not provide complete reasoning justifying this proclamation*
>>
>> The provided reasoning is sufficient. You can continue reasoning from
>> that if you want more.
>>
>
> *He is SIMPLY WRONG and when he tries*
> *to justify what he said he will fail*
>
> Any pure x86 emulator or UTM can have the added functionality
> of watching every state change of its simulated input without
> changing the simulated steps of this input relative to an
> unmodified x86 emulator or UTM.
>
> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*

Idiot.

>
>>> Because the simulator must perform every detail of the simulation of
>>> the underlying machine it can watch every single state change of this
>>> underlying machine and this does not change the behavior of the
>>> simulated input AT ALL (relative to not watching the state changes).
>>
>> Yes, that is a correct interpretation.
>>
>
> OK Great!
> So a simulating termination analyzer could watch the behavior of its
> input and analyze this watched behavior and transition to a non-final
> state that indicates non-halting and then go back and continue
> simulating the non-halting input and it remains a simulator all along.
>
> *This would not be a halt decider because all deciders must halt*
> *It would be an unconventional termination analyzer*
>
> *It does correctly report that its pathological input never halts*
>
> *This method does work correctly on the H/D template*
> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>
> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
> 01 int D(ptr x)
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11   H(D,D);
> 12 }
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> *Termination Analyzer H is Not Fooled by Pathological Input D*
> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>
>

On 5/11/24 12:06 PM, olcott wrote:
> On 5/11/2024 3:00 AM, Mikko wrote:
>> On 2024-05-10 18:16:37 +0000, olcott said:
>>
>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>
>>>> Obviously a simulator has access to the internal state (tape
>>>> contents etc.) of the simulated machine.  No problem there.
>>>>
>>>> What isn't allowed is the simulated machine altering its own
>>>> behaviour by accessing data outside of its own state.  (I.e.
>>>> accessing data from its parent simulators state.)
>>>>
>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>> straight simulation with add-on "enhancements" that extend the
>>>> functionality of the simulated machine, in doing so it would no
>>>> longer be a simulator in the sense you need it to be.  So you
>>>> mustn't do this!
>>
>> In principle an incorrect simulation is permissible. However, to prove
>> that the result inferred from an incorrect simulation is correct may
>> be impossible.
>>
>
> Within the conventional terms-of-the-art of {termination analyzer}
> and {simulator} an incorrect simulation is forbidden.

From what definitions.

I would say that based on the definition of simulation that you imply
you are using (by the using of it to bridge from the behavior of the
program to the simlulation of the program) ALL your H that answer about
D have used an "incorrect" simulation.

>
>>> *You did not provide complete reasoning justifying this proclamation*
>>> *You did not provide complete reasoning justifying this proclamation*
>>> *You did not provide complete reasoning justifying this proclamation*
>>
>> The provided reasoning is sufficient. You can continue reasoning from
>> that if you want more.
>>
>
> *He is SIMPLY WRONG and when he tries*
> *to justify what he said he will fail*
>
> Any pure x86 emulator or UTM can have the added functionality
> of watching every state change of its simulated input without
> changing the simulated steps of this input relative to an
> unmodified x86 emulator or UTM.
>
> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>
>>> Because the simulator must perform every detail of the simulation of
>>> the underlying machine it can watch every single state change of this
>>> underlying machine and this does not change the behavior of the
>>> simulated input AT ALL (relative to not watching the state changes).
>>
>> Yes, that is a correct interpretation.
>>
>
> OK Great!
> So a simulating termination analyzer could watch the behavior of its
> input and analyze this watched behavior and transition to a non-final
> state that indicates non-halting and then go back and continue
> simulating the non-halting input and it remains a simulator all along.

HOw can you "return" the non-halting indication and then continue to run?

>
> *This would not be a halt decider because all deciders must halt*
> *It would be an unconventional termination analyzer*

It wouldn't be a program by the normal definitions of a program.

>
> *It does correctly report that its pathological input never halts*

Nope.

>
> *This method does work correctly on the H/D template*
> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>
> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
> 01 int D(ptr x)
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11   H(D,D);
> 12 }
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> *Termination Analyzer H is Not Fooled by Pathological Input D*
> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>

Nope, because the H you just described is not equivalent to a Turing
Machine.

On 5/11/2024 11:32 AM, Mike Terry wrote:
> On 11/05/2024 17:06, olcott wrote:
>> On 5/11/2024 3:00 AM, Mikko wrote:
>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>
>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>
>>>>> Obviously a simulator has access to the internal state (tape
>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>
>>>>> What isn't allowed is the simulated machine altering its own
>>>>> behaviour by accessing data outside of its own state.  (I.e.
>>>>> accessing data from its parent simulators state.)
>>>>>
>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>> straight simulation with add-on "enhancements" that extend the
>>>>> functionality of the simulated machine, in doing so it would no
>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>> mustn't do this!
>>>
>>> In principle an incorrect simulation is permissible. However, to prove
>>> that the result inferred from an incorrect simulation is correct may
>>> be impossible.
>>>
>>
>> Within the conventional terms-of-the-art of {termination analyzer}
>> and {simulator} an incorrect simulation is forbidden.
>>
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>
>>> The provided reasoning is sufficient. You can continue reasoning from
>>> that if you want more.
>>>
>>
>> *He is SIMPLY WRONG and when he tries*
>> *to justify what he said he will fail*
>>
>> Any pure x86 emulator or UTM can have the added functionality
>> of watching every state change of its simulated input without
>> changing the simulated steps of this input relative to an
>> unmodified x86 emulator or UTM.
>>
>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>
> Idiot.
>

Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
> While an "active-simulator" [my own term] is at liberty
> to combine straight simulation with add-on "enhancements"
> that extend the functionality of the simulated machine,
> in doing so it would no longer be a simulator in the sense
> you need it to be. So you mustn't do this!

When none of these add-on enhancements change behavior of the
simulated machine relative to a pure simulation of these same
inputs then the resulting machine remains a simulator even with
add-on enhancements.

Now that I have re-read what you said many times I noticed
nuances that I did not notice before.

*extend the functionality of the simulated machine*
does not refer to the simulator as I previously thought.

So it is my mistake. I apologize for mischaracterizing
what you said. This was unintentional.

>>
>>>> Because the simulator must perform every detail of the simulation of
>>>> the underlying machine it can watch every single state change of this
>>>> underlying machine and this does not change the behavior of the
>>>> simulated input AT ALL (relative to not watching the state changes).
>>>
>>> Yes, that is a correct interpretation.
>>>
>>
>> OK Great!
>> So a simulating termination analyzer could watch the behavior of its
>> input and analyze this watched behavior and transition to a non-final
>> state that indicates non-halting and then go back and continue
>> simulating the non-halting input and it remains a simulator all along.
>>
>> *This would not be a halt decider because all deciders must halt*
>> *It would be an unconventional termination analyzer*
>>
>> *It does correctly report that its pathological input never halts*
>>
>> *This method does work correctly on the H/D template*
>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>
>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>> 01 int D(ptr x)
>> 02 {
>> 03   int Halt_Status = H(x, x);
>> 04   if (Halt_Status)
>> 05     HERE: goto HERE;
>> 06   return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11   H(D,D);
>> 12 }
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>

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

On 5/11/2024 11:46 AM, Richard Damon wrote:
> On 5/11/24 12:06 PM, olcott wrote:
>> On 5/11/2024 3:00 AM, Mikko wrote:
>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>
>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>
>>>>> Obviously a simulator has access to the internal state (tape
>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>
>>>>> What isn't allowed is the simulated machine altering its own
>>>>> behaviour by accessing data outside of its own state.  (I.e.
>>>>> accessing data from its parent simulators state.)
>>>>>
>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>> straight simulation with add-on "enhancements" that extend the
>>>>> functionality of the simulated machine, in doing so it would no
>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>> mustn't do this!
>>>
>>> In principle an incorrect simulation is permissible. However, to prove
>>> that the result inferred from an incorrect simulation is correct may
>>> be impossible.
>>>
>>
>> Within the conventional terms-of-the-art of {termination analyzer}
>> and {simulator} an incorrect simulation is forbidden.
>
>
> From what definitions.
>
> I would say that based on the definition of simulation that you imply
> you are using (by the using of it to bridge from the behavior of the
> program to the simlulation of the program) ALL your H that answer about
> D have used an "incorrect" simulation.
>
>>
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>
>>> The provided reasoning is sufficient. You can continue reasoning from
>>> that if you want more.
>>>
>>
>> *He is SIMPLY WRONG and when he tries*
>> *to justify what he said he will fail*
>>
>> Any pure x86 emulator or UTM can have the added functionality
>> of watching every state change of its simulated input without
>> changing the simulated steps of this input relative to an
>> unmodified x86 emulator or UTM.
>>
>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>>
>>>> Because the simulator must perform every detail of the simulation of
>>>> the underlying machine it can watch every single state change of this
>>>> underlying machine and this does not change the behavior of the
>>>> simulated input AT ALL (relative to not watching the state changes).
>>>
>>> Yes, that is a correct interpretation.
>>>
>>
>> OK Great!
>> So a simulating termination analyzer could watch the behavior of its
>> input and analyze this watched behavior and transition to a non-final
>> state that indicates non-halting and then go back and continue
>> simulating the non-halting input and it remains a simulator all along.
>
> HOw can you "return" the non-halting indication and then continue to run?
>

D simulated by H could
(a) Watch all of the state changes of its input.
(b) Analyze these state changes.
(c) Correctly determine that its input would never halt.
(d) Continue to report that its input would never halt by
transitioning to a special non-final state indicating this.

All the while remaining a pure simulator with extra features.

>>
>> *This would not be a halt decider because all deciders must halt*
>> *It would be an unconventional termination analyzer*
>
> It wouldn't be a program by the normal definitions of a program.
>
>>
>> *It does correctly report that its pathological input never halts*
>
> Nope.
>
>>
>> *This method does work correctly on the H/D template*
>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>
>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>> 01 int D(ptr x)
>> 02 {
>> 03   int Halt_Status = H(x, x);
>> 04   if (Halt_Status)
>> 05     HERE: goto HERE;
>> 06   return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11   H(D,D);
>> 12 }
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>
>
> Nope, because the H you just described is not equivalent to a Turing
> Machine.

The exact same (a)(b)(c)(d) sequence of steps applies equally
to the Linz template:

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

embedded_H is not a halt decider or even a conventional
{termination analyzer}, it is an unconventional {termination analyzer}
that does correctly report the halt status of its pathological input.

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

On 5/11/2024 12:19 PM, olcott wrote:
> On 5/11/2024 11:46 AM, Richard Damon wrote:
>> On 5/11/24 12:06 PM, olcott wrote:
>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>
>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>
>>>>>> Obviously a simulator has access to the internal state (tape
>>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>>
>>>>>> What isn't allowed is the simulated machine altering its own
>>>>>> behaviour by accessing data outside of its own state.  (I.e.
>>>>>> accessing data from its parent simulators state.)
>>>>>>
>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>> mustn't do this!
>>>>
>>>> In principle an incorrect simulation is permissible. However, to prove
>>>> that the result inferred from an incorrect simulation is correct may
>>>> be impossible.
>>>>
>>>
>>> Within the conventional terms-of-the-art of {termination analyzer}
>>> and {simulator} an incorrect simulation is forbidden.
>>
>>
>>  From what definitions.
>>
>> I would say that based on the definition of simulation that you imply
>> you are using (by the using of it to bridge from the behavior of the
>> program to the simlulation of the program) ALL your H that answer
>> about D have used an "incorrect" simulation.
>>
>>>
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>
>>>> The provided reasoning is sufficient. You can continue reasoning from
>>>> that if you want more.
>>>>
>>>
>>> *He is SIMPLY WRONG and when he tries*
>>> *to justify what he said he will fail*
>>>
>>> Any pure x86 emulator or UTM can have the added functionality
>>> of watching every state change of its simulated input without
>>> changing the simulated steps of this input relative to an
>>> unmodified x86 emulator or UTM.
>>>
>>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>>>
>>>>> Because the simulator must perform every detail of the simulation of
>>>>> the underlying machine it can watch every single state change of this
>>>>> underlying machine and this does not change the behavior of the
>>>>> simulated input AT ALL (relative to not watching the state changes).
>>>>
>>>> Yes, that is a correct interpretation.
>>>>
>>>
>>> OK Great!
>>> So a simulating termination analyzer could watch the behavior of its
>>> input and analyze this watched behavior and transition to a non-final
>>> state that indicates non-halting and then go back and continue
>>> simulating the non-halting input and it remains a simulator all along.
>>
>> HOw can you "return" the non-halting indication and then continue to run?
>>
>
> D simulated by H could
> (a) Watch all of the state changes of its input.
> (b) Analyze these state changes.
> (c) Correctly determine that its input would never halt.
> (d) Continue to report that its input would never halt by
>     transitioning to a special non-final state indicating this.
>
> All the while remaining a pure simulator with extra features.
>
>>>
>>> *This would not be a halt decider because all deciders must halt*
>>> *It would be an unconventional termination analyzer*
>>
>> It wouldn't be a program by the normal definitions of a program.
>>
>>>
>>> *It does correctly report that its pathological input never halts*
>>
>> Nope.
>>
>>>
>>> *This method does work correctly on the H/D template*
>>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>>
>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>> 01 int D(ptr x)
>>> 02 {
>>> 03   int Halt_Status = H(x, x);
>>> 04   if (Halt_Status)
>>> 05     HERE: goto HERE;
>>> 06   return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11   H(D,D);
>>> 12 }
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>>
>>
>> Nope, because the H you just described is not equivalent to a Turing
>> Machine.
>
> The exact same (a)(b)(c)(d) sequence of steps applies equally
> to the Linz template:
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> embedded_H is not a halt decider or even a conventional
> {termination analyzer}, it is an unconventional {termination analyzer}
> that does correctly report the halt status of its pathological input.
>
>

It is also true that the behavior that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
is reporting on is the same behavior as Ĥ ⟨Ĥ⟩.

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

On 5/11/24 4:16 PM, olcott wrote:
> On 5/11/2024 12:19 PM, olcott wrote:
>> On 5/11/2024 11:46 AM, Richard Damon wrote:
>>> On 5/11/24 12:06 PM, olcott wrote:
>>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>>
>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>>
>>>>>>> Obviously a simulator has access to the internal state (tape
>>>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>>>
>>>>>>> What isn't allowed is the simulated machine altering its own
>>>>>>> behaviour by accessing data outside of its own state.  (I.e.
>>>>>>> accessing data from its parent simulators state.)
>>>>>>>
>>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>>> mustn't do this!
>>>>>
>>>>> In principle an incorrect simulation is permissible. However, to prove
>>>>> that the result inferred from an incorrect simulation is correct may
>>>>> be impossible.
>>>>>
>>>>
>>>> Within the conventional terms-of-the-art of {termination analyzer}
>>>> and {simulator} an incorrect simulation is forbidden.
>>>
>>>
>>>  From what definitions.
>>>
>>> I would say that based on the definition of simulation that you imply
>>> you are using (by the using of it to bridge from the behavior of the
>>> program to the simlulation of the program) ALL your H that answer
>>> about D have used an "incorrect" simulation.
>>>
>>>>
>>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>>
>>>>> The provided reasoning is sufficient. You can continue reasoning from
>>>>> that if you want more.
>>>>>
>>>>
>>>> *He is SIMPLY WRONG and when he tries*
>>>> *to justify what he said he will fail*
>>>>
>>>> Any pure x86 emulator or UTM can have the added functionality
>>>> of watching every state change of its simulated input without
>>>> changing the simulated steps of this input relative to an
>>>> unmodified x86 emulator or UTM.
>>>>
>>>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>>>>
>>>>>> Because the simulator must perform every detail of the simulation of
>>>>>> the underlying machine it can watch every single state change of this
>>>>>> underlying machine and this does not change the behavior of the
>>>>>> simulated input AT ALL (relative to not watching the state changes).
>>>>>
>>>>> Yes, that is a correct interpretation.
>>>>>
>>>>
>>>> OK Great!
>>>> So a simulating termination analyzer could watch the behavior of its
>>>> input and analyze this watched behavior and transition to a non-final
>>>> state that indicates non-halting and then go back and continue
>>>> simulating the non-halting input and it remains a simulator all along.
>>>
>>> HOw can you "return" the non-halting indication and then continue to
>>> run?
>>>
>>
>> D simulated by H could
>> (a) Watch all of the state changes of its input.
>> (b) Analyze these state changes.
>> (c) Correctly determine that its input would never halt.
>> (d) Continue to report that its input would never halt by
>>      transitioning to a special non-final state indicating this.
>>
>> All the while remaining a pure simulator with extra features.
>>
>>>>
>>>> *This would not be a halt decider because all deciders must halt*
>>>> *It would be an unconventional termination analyzer*
>>>
>>> It wouldn't be a program by the normal definitions of a program.
>>>
>>>>
>>>> *It does correctly report that its pathological input never halts*
>>>
>>> Nope.
>>>
>>>>
>>>> *This method does work correctly on the H/D template*
>>>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>>>
>>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>>> 01 int D(ptr x)
>>>> 02 {
>>>> 03   int Halt_Status = H(x, x);
>>>> 04   if (Halt_Status)
>>>> 05     HERE: goto HERE;
>>>> 06   return Halt_Status;
>>>> 07 }
>>>> 08
>>>> 09 int main()
>>>> 10 {
>>>> 11   H(D,D);
>>>> 12 }
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>>>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>>>
>>>
>>> Nope, because the H you just described is not equivalent to a Turing
>>> Machine.
>>
>> The exact same (a)(b)(c)(d) sequence of steps applies equally
>> to the Linz template:
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> embedded_H is not a halt decider or even a conventional
>> {termination analyzer}, it is an unconventional {termination analyzer}
>> that does correctly report the halt status of its pathological input.
>>
>>
>
> It is also true that the behavior that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> is reporting on is the same behavior as Ĥ ⟨Ĥ⟩.
>

But it gets that wrong answer.

Since H^ (H^) Halts, but embedded_H(H^,H^) says it doesn't

Thus, you admit your logic is broken.

Note, embedded_H can't use your answer but not halt, as Turing Machines
can't do that, so if you need that, your whole model is just
incompatible with the theory, and you need to explain how it works.

On 5/11/24 1:19 PM, olcott wrote:
> On 5/11/2024 11:46 AM, Richard Damon wrote:
>> On 5/11/24 12:06 PM, olcott wrote:
>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>
>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>
>>>>>> Obviously a simulator has access to the internal state (tape
>>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>>
>>>>>> What isn't allowed is the simulated machine altering its own
>>>>>> behaviour by accessing data outside of its own state.  (I.e.
>>>>>> accessing data from its parent simulators state.)
>>>>>>
>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>> mustn't do this!
>>>>
>>>> In principle an incorrect simulation is permissible. However, to prove
>>>> that the result inferred from an incorrect simulation is correct may
>>>> be impossible.
>>>>
>>>
>>> Within the conventional terms-of-the-art of {termination analyzer}
>>> and {simulator} an incorrect simulation is forbidden.
>>
>>
>>  From what definitions.
>>
>> I would say that based on the definition of simulation that you imply
>> you are using (by the using of it to bridge from the behavior of the
>> program to the simlulation of the program) ALL your H that answer
>> about D have used an "incorrect" simulation.
>>
>>>
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>
>>>> The provided reasoning is sufficient. You can continue reasoning from
>>>> that if you want more.
>>>>
>>>
>>> *He is SIMPLY WRONG and when he tries*
>>> *to justify what he said he will fail*
>>>
>>> Any pure x86 emulator or UTM can have the added functionality
>>> of watching every state change of its simulated input without
>>> changing the simulated steps of this input relative to an
>>> unmodified x86 emulator or UTM.
>>>
>>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>>>
>>>>> Because the simulator must perform every detail of the simulation of
>>>>> the underlying machine it can watch every single state change of this
>>>>> underlying machine and this does not change the behavior of the
>>>>> simulated input AT ALL (relative to not watching the state changes).
>>>>
>>>> Yes, that is a correct interpretation.
>>>>
>>>
>>> OK Great!
>>> So a simulating termination analyzer could watch the behavior of its
>>> input and analyze this watched behavior and transition to a non-final
>>> state that indicates non-halting and then go back and continue
>>> simulating the non-halting input and it remains a simulator all along.
>>
>> HOw can you "return" the non-halting indication and then continue to run?
>>
>
> D simulated by H could
> (a) Watch all of the state changes of its input.
> (b) Analyze these state changes.
> (c) Correctly determine that its input would never halt.
> (d) Continue to report that its input would never halt by
>     transitioning to a special non-final state indicating this.
>
> All the while remaining a pure simulator with extra features.

How does a program, per the definition in Computation Theory, report an
answer to its caller, and continue to do something.

Remember, you have DEFINED that this D must call H, which means that H
must return its answer to D. Going through a non-final state to answer
is inconsistant with your definition of H as RETURNING the answer.

Your definition is just self-inconstant, as is your logic.

You are trying to define a dog, that is also a 10 story office building.

>
>>>
>>> *This would not be a halt decider because all deciders must halt*
>>> *It would be an unconventional termination analyzer*
>>
>> It wouldn't be a program by the normal definitions of a program.
>>
>>>
>>> *It does correctly report that its pathological input never halts*
>>
>> Nope.
>>
>>>
>>> *This method does work correctly on the H/D template*
>>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>>
>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>> 01 int D(ptr x)
>>> 02 {
>>> 03   int Halt_Status = H(x, x);
>>> 04   if (Halt_Status)
>>> 05     HERE: goto HERE;
>>> 06   return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11   H(D,D);
>>> 12 }
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>>
>>
>> Nope, because the H you just described is not equivalent to a Turing
>> Machine.
>
> The exact same (a)(b)(c)(d) sequence of steps applies equally
> to the Linz template:

Nope. ANSWERING is BY DEFINITION a final state for that sub-machine.

So, you are just proving you don't understand what you are talking about.

*H* answers by going to *ITS* final states, qy or qn. Once we build H^,
THAT isn't defined to give an answer, only have behavior.

>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> embedded_H is not a halt decider or even a conventional
> {termination analyzer}, it is an unconventional {termination analyzer}
> that does correctly report the halt status of its pathological input.
>
>

Then H isn't a Halt Decider or Terminataion Analyzer and you are just
admitting to being a LIAR.

Remember, you claim that embeded_H is from the Linz style proof and thus
is an exact copy of your H so is the same sort of thing as it.