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