Re: That P(P) of main() halts does not contradict H(P,P)==0 [ Refuting Rice's Theorem ]

[olcott]

On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 9/7/2021 5:54 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/6/2021 8:57 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 9/6/2021 8:09 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/6/2021 7:40 PM, Ben Bacarisse wrote:
>>>
>>>>>>>>> TM at H^.qx is an "exact
>>>>>>>>> copy" of H. How can two TMs that are exact copies of each other make
>>>>>>>>> different transitions given the same input?
>>>>>>>>
>>>>>>>> That H1 calls H means that H1 can see what H does.
>>>>>>>> The H is called by H1 means that H does not even know that H1 exists.
>>>>>>>
>>>>>>> TMs don't call each other.
>>>>>>
>>>>>> That H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ creates a master slave relationship
>>>>>> between H and Ĥ.
>>>>>>
>>>>>> The master can see exactly what the slave is doing.
>>>>>>
>>>>>> The slave it totally unaware of the existence of the master.
>>>>>>
>>>>>> The master can change its behavior on the basis of what the slave does.
>>>>>>
>>>>>> The slave cannot change its behavior on the basis of what the master does.
>>>>>>
>>>>>> Thus the master slave relationship can and does cause an identical
>>>>>> function with the same input to have different behavior even if no one
>>>>>> ever noticed this before.
>>>>>
>>>>> Function? Have you been only pretending to be talking about Turing
>>>>> machines the whole time? If you were not being deceitful, your H (the
>>>>> TM) is wrong because
>>>>>
>>>>> H.q0 <H^><H^> |- H.qn
>>>>
>>>> No matter how much you ignore the fact that the master slave
>>>> relationship where H is the master of Ĥ causes different behavior:
>>>>
>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>
>>>> for two identical functions with the same input, this master slave
>>>> relationship still causes differing behavior.
>>>
>>> Functions? You used the notation of Turing machines. Were you being
>>> deceptive? I am perfectly prepared to accept that you are cheating in
>>> some way with your hidden C functions, but you can't cheat with TMs.
>>> What you said using the notation of TMs was wrong (about TMs) because
>>> identical state transition functions produce the same transitions when
>>> given identical input. So your recent admission that your H should
>>> accept the string <H^><H^> means that
>>>
>>> H^.qx <H^><H^> |- H^.qn
>>>
>>> shows your H is wrong -- on your own terms. The facts of the matter
>>> come from you.
>>>
>>> I can stop posting if you admit you have been disingenuously using the
>>> notation of TMs to talk about your dodgy C code. If you want to keep
>>> talking about TMs you need to admit you are wrong. Identical state
>>> transition functions with identical inputs always generate the same
>>> sequence of machine configurations.
>>
>> So in other words you have another shortcoming in your technical
>> knowledge this time it is directly in the field of computer science on
>> not in related fields such as software engineering.
>>
>> You seem to be unaware that the TM description being simulated by a
>> UTM has no access to see the internal steps of its simulator and yet
>> the UTM can directly see all of the steps of the TM description that
>> it is simulating.
>
> So you are talking about TMs after all? Please use the correct
> language. TMs don't have "functions" and don't make "calls".
>
> Identical state transition functions with identical inputs always
> generate the same sequence of machine configurations so, the often
> quoted property of your H^:
>
> H^.qx <H^><H^> |- H^.qn
>
> shows that your H is wrong.
>

int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}

if (H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ applied to ⟨Ĥ⟩)
OutputString("Pathological self-reference error!");


>> How are you going to weasel out of that one to protect your ego?
>
> I'm not sure what you think I'd want to weasel out of. I'd like you to
> address your primary mistake. You tell us that H should accept <H^><H^>
> and you tell us that the TM at H^.qx is an "exact copy" of H and you
> tell us that H^.qx <H^><H^> |- H^.qn. You tell us everything we need to
> know that you are wrong. The only thing missing is an apology from you
> for ignoring these helpful explanations for so long.
>


--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

[olcott]

On 9/7/2021 9:27 PM, Richard Damon wrote:
> On 9/7/21 10:18 PM, olcott wrote:
>> On 9/7/2021 8:55 PM, Richard Damon wrote:
>>> On 9/7/21 9:28 PM, olcott wrote:
>>>> On 9/7/2021 8:12 PM, Richard Damon wrote:
>>>>> On 9/7/21 9:08 PM, olcott wrote:

>>>>>>> You need to pay attention.  I can't help you if you just put your
>>>>>>> fingers in your ears and chant.
>>>>>>>
>>>>>>>>> ... You tell us that H should accept <H^><H^>

>>>>>>>>> and you tell us that the TM at H^.qx is an "exact copy" of H and
>>>>>>>>> you
>>>>>>>>> tell us that H^.qx <H^><H^> |- H^.qn.  You tell us everything we
>>>>>>>>> need to
>>>>>>>>> know that you are wrong.  The only thing missing is an apology
>>>>>>>>> from you
>>>>>>>>> for ignoring these helpful explanations for so long.
>>>>>>>

>>>>>>> Is there anything here you don't understand?  It's not hard.
>>>>>>> Identical
>>>>>>> state transition functions always generate the same computational
>>>>>>> steps
>>>>>>> when presented with the same input.
>>>>>>>
>>>>>>
>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>> // Strachey(1965) CPL translated to C
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>     if (H(x, x))
>>>>>>       HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> int main() { H1(P,P); } is examined
>>>>>>
>>>>>> When code of the x86 H1 and H is identical and their input is the same
>>>>>> yet their behavior is different then we know that something is up.
>>>>>>
>>>>>> When we examine actual fully operational code we can't simply assume
>>>>>> that we imagined the behavior incorrectly.
>>>>>>
>>>>>> That only leaves the code and the input. The input is the same 32-bit
>>>>>> integer, that only leaves the code.
>>>>>>
>>>>>> It turns out that the most plausible explanation is that the code
>>>>>> is not
>>>>>> the same. The master / slave relationship between H1/H and H/Ĥ is hard
>>>>>> coded into the full H1/H and H/Ĥ computations.
>>>>>>
>>>>>> The fact that:
>>>>>> H1 simulates P that simulates H(P,P)
>>>>>> H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ that simulates ⟨Ĥ⟩ ⟨Ĥ⟩ at Ĥ.qx
>>>>>>
>>>>>> hard codes the master / slave relationships between H1/H and H/Ĥ.
>>>>>>
>>>>>>
>>>>>
>>>>> Just means that the code does not code an actual Computation, but
>>>>> somewhere is using data that is NOT part of its formal input to make
>>>>> the
>>>>> decision.
>>>>>
>>>>
>>>> If the code is identical and the input is identical then the behavior
>>>> must be identical. If the code is not identical and the input is
>>>> identical then the behavior need not be identical.
>>>>
>>>> Different code with the same input can derive different results as a
>>>> pure function of this input.
>>>>
>>>
>>> So you admit that they have different code?
>>>
>>> I thought your claim was that H and H1 had identical code.
>>>
>>
>> int main() { H1(P,P); } specifies that H1 is in a master slave
>> relationship with H(P,P) even though H1 and H have identical code.
>>
>> The master / slave relationship specified in main() defines H1 as a
>> distinctly different computation than H.
>>
>> The exact same thing works in reverse.
>> int main() { H(P,P); } that simulates P the calls H1...
>
> If H1 and H have the same code and get the same input then they MUST
> behave the same. That is FUNDAMENTAL to how computers work.
>

int main() { H1(P,P); } simulates P that calls H(P,P)
makes H1(P,P) a different computation than H(P,P).

The functions H and H1 behave differently when invoked with inputs that
refer to themselves than when their inputs do not refer to themselves.

That explains the difference in the behavior of H1 and H.
This makes H1/H a distinctly different computation than H1/H1 or H/H.

// This also explains how this is a
// pathological self-reference decider
// that refutes Rice's Theorem
//

int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}

> To act different, they need some input that is different. (maybe this
> master / slave relationship).
>
> Since their formal inputs are the same, that means there is some other
> input that is not a formal input that makes a difference, and thus they
> fail to be a Computation, and thus not eligible to be a Decider.
>
> You have just voided you whole argument.
>
> H is admitted to not be a pure function of its defined inputs, thus not
> eligable to be a Halt Decider.
>
> FAIL.
>
> (You just keep digging yourself in deeper).
>
>>
>>> And H^ needs to have basically identical code to H embedded in it (the
>>> only difference is in a state we don't get to).
>>>
>>> If you are now admitting the actual code is different, that shows that
>>> your argument isn't valid any more.

[olcott]

On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 9/7/2021 7:42 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
>

>>>>> ... You tell us that H should accept <H^><H^>

>>>>> and you tell us that the TM at H^.qx is an "exact copy" of H and you
>>>>> tell us that H^.qx <H^><H^> |- H^.qn. You tell us everything we need to
>>>>> know that you are wrong. The only thing missing is an apology from you
>>>>> for ignoring these helpful explanations for so long.
>>>

>>> Is there anything here you don't understand? It's not hard. Identical
>>> state transition functions always generate the same computational steps
>>> when presented with the same input.
>>>
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> // Strachey(1965) CPL translated to C
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
>> int main() { H1(P,P); } is examined
>

> If your analogy does not match the facts I stated about TMs then it's
> wrong.

Identical code with identical inputs must derive identical results.

> Does it conform that H <H^><H^> and H^.qx <H^><H^> both
> transition to the corresponding rejecting states, H.qn and H^.qn? If
> so, a simple "thanks, Ben, I was wrong" would do. If not, throw the
> analogy away because it's misleading you.

>

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}

As I just explained to Richard my x86 halt decider / emulators behave
differently when their input refer to themselves than when their input
does not refer to themselves.

This is why H1(P,P) is a halt decider for its input and
H ⟨Ĥ⟩ ⟨Ĥ⟩ is a halt decider for its input.

// This also explains how this is a
// pathological self-reference decider
// that refutes Rice's Theorem
//

int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}

[olcott]

On 9/8/2021 1:14 AM, André G. Isaak wrote:
> On 2021-09-07 21:18, olcott wrote:
>> On 9/7/2021 10:09 PM, André G. Isaak wrote:

>>> On 2021-09-07 20:53, olcott wrote:
>>>
>>>> int main() { H1(P,P); } simulates P that calls H(P,P)
>>>> makes H1(P,P) a different computation than H(P,P).
>>>>
>>>> The functions H and H1 behave differently when invoked with inputs
>>>> that refer to themselves than when their inputs do not refer to
>>>> themselves.
>>>>
>>>> That explains the difference in the behavior of H1 and H.
>>>> This makes H1/H a distinctly different computation than H1/H1 or H/H.
>>>

>>> The problem here is that when dealing with actual computations (i.e.
>>> Turing Machines), nothing refers 'to itself'.
>>>
>>
>> Now Ĥ is a Turing machine, so that it will have
>> some description in Σ*, say ŵ. This string, in
>> addition to being the description of Ĥ can also
>> be used as input string. We can therefore legitimately
>> ask what would happen if Ĥ is applied to ŵ.
>> (its own Turing machine description)
>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>
>> I encode this more clearly as: Ĥ applied to ⟨Ĥ⟩
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>
>> Make sure that you refer to these notational conventions not the one
>> that Linz provides with the two start states and vagueness about which
>> inputs go where, and which states are which.
>
> I have no idea how the above is supposed to be a response to the point I
> was making. You claimed that your H and H1 behave different when their
> inputs refer to 'themselves'. I pointed out that when dealing with TMs,
> nothing 'refers to itself'. The above doesn't address this at all.
>

You said nothing refers to itself.
I showed you how Ĥ applied to ⟨Ĥ⟩ thus Ĥ refers to itself.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ sees that Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn

Ĥ.qx sees that its input ⟨Ĥ⟩ ⟨Ĥ⟩ is in an infinitely repeating cycle
that never halts unless Ĥ.qx aborts its simulation of this input ⟨Ĥ⟩ ⟨Ĥ⟩

> Linz's Ĥ takes as an input a complete description of a Turing Machine.
> Do you understand that a complete description is not a reference?
>
> A reference would be something that says 'a TM that behaves just like
> that one over there'
>
> A description gives a complete description of a the of state transitions
> which defines a TM. It doesn't 'point' to some other machine.
>
> If you give a TM as an input a description of a machine that happens to
> be identical to itself, that TM has absolutely no way of recognizing
> that the description it has been given describes itself, so how can this
> make a difference?
>

It need not know that the input is itself it only needs to tell that all
of the inputs are identical and none of them will ever halt unless their
simulation is aborted.

The exact same set of state transitions occurs every time that the
simulation of a machine begins until the next cycle when the simulation
of another copy begins.

The machine code of P and a P1 exact copy of P is identical even though
they are stored at different machine addresses because the x86 language
uses relative addressing.

> And if your H and your H1 are identical, then their *descriptions* will
> also be identical, so what you write above about H and H1 behaving
> differently when their input 'refers to themselves' is simply nonsensical.
>
> André
>

In the C/x86 model that uses H1/H
H1 behaves differently when it sees that another C function has aborted
its input so that H1 doesn't have to abort its input.

It doesn't have to an identical C function, it just can't be the same C
function. It is basically a case of someone else already did my work for
me so now that the work is done I don't have to do it.

The master UTM / halt decider H1 can see everything that it simulates:
(a) P begins
(b) P calls H(P,P)
(c) H returns to P
(d) P returns to main() where it was simulated by H1.

The master UTM / halt decider H can see everything that it simulates:
(a) P begins
(b) P calls H(P,P)
(c) P begins
(e) P calls H(P,P)
H(P,P) sees that it must abort its simulation of its input or its input
never halts.

[olcott]

On 9/8/2021 6:04 AM, Richard Damon wrote:

> No, there MUST be either a DIFFERNCE between the two programs, or the
> programs are not Computations of their defined inputs, but have so other
> input.

It is simply a matter of H1/H1 or H/H does not see anyone else doing the
work of aborting the simulation of its input so it must do this work.

The H1 of H1/H sees that its input halts.
The H1 of H1/H1 sees that its input never halts.

The H of H1/H sees that its input never halts.
The H of H/H sees that its input never halts.

Here is the H1/H scenario in complete detail:

The master UTM / halt decider H1 can see everything that it simulates:
(a) P begins
(b) P calls H(P,P)
(c) H returns to P
(d) P returns to main() where it was simulated by H1.

The master UTM / halt decider H can see everything that it simulates:
(a) P begins
(b) P calls H(P,P)
(c) P begins
(e) P calls H(P,P)

H(P,P) sees that it must abort its simulation of its input or its input
never halts.

[olcott]

On 9/8/2021 4:27 PM, André G. Isaak wrote:
> On 2021-09-08 14:41, olcott wrote:
>> On 9/8/2021 3:02 PM, André G. Isaak wrote:
>>> On 2021-09-08 13:33, olcott wrote:
>>>> On 9/8/2021 2:13 PM, olcott wrote:
>>>>> On 9/8/2021 1:58 PM, André G. Isaak wrote:
>>>>>> On 2021-09-08 12:12, olcott wrote:
>>>>>>> On 9/8/2021 12:59 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> But ⟨Ĥ⟩ ⟨Ĥ⟩ represents a *single* computation. It either halts
>>>>>>>> or it doesn't.
>>>>>>>>
>>>>>>>
>>>>>>> We could say the same thing about P(P), yet we can clearly see every
>>>>>>
>>>>>> Yes, we could and I did.
>>>>>>
>>>>>>> single step where H1(P,P) correctly reports that its input halts
>>>>>>> because H(P,P) correctly reports that its input never halts.
>>>>>>
>>>>>> H(P, P) *can't* correctly report that its input never halts
>>>>>> because P(P) does halt.
>>>>>>
>>>>>>> You can ignore this forever, yet that will not make a verifiable
>>>>>>> fact simply go away.
>>>>>>
>>>>>> You're ignoring the fact that it gets the answer wrong since you
>>>>>> are overlooking the actual definition of the halting problem.
>>>>>
>>>>> We can see that unless H(P,P) aborts the simulation of its input

>>>>> that its input never halts.
>>>

>>> You've said this many times but it is simply wrong. We know that P(P)
>>> is a halting computation.
>>>
>>>>> You can say that you don't see this only because you don't look at it.
>>>>> At this point after it has been brought up so many times you must
>>>>> simply be a God damned liar.
>>>>>
>>>>>
>>>>
>>>>
>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>> H(P,P)
>>>>
>>>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>>>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>>>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>>>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>>>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>>>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call
>>>> H(P,P)
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> The above code does match this infinite recursion pattern and the
>>>> infinite recursion pattern is correct therefore the input to H(P,P)
>>>> never halts even if an omniscient being disagrees.
>>>
>>> A trace shows *how* a particular program got to a particular answer.
>>> It in no way establishes that that answer is actually correct. Traces
>>> are not proofs. If you ever attempt to publish your work, no one is
>>> even going to be willing to look at a trace.
>>>
>>> The problem is that your 'infinite recursion pattern' doesn't work.
>>>
>>> And how can something be 'correct' if an omniscient being (taking the
>>> term literally) disagrees?
>>>
>>>> This infinite recursion detection criteria are met by the above
>>>> execution trace:
>>>> (a) P calls H twice in sequence from the same machine address.
>>>> (b) With the same parameters: (P,P) to H.
>>>> (c) With no conditional branch or indexed jump instructions in the
>>>> execution trace of P.
>>>> (d) We know that there are no return instructions in H because we
>>>> know that H is in pure simulation mode.
>>>
>>> As has been pointed out many times, your (d) is simply wrong. It
>>> cannot be justified in any way. And your (d) is why your H
>>> erroneously concludes that P(P) halts.
>>>
>>> But even if we ignore (d), you can't just pull some criteria out of
>>> your ass and claim that these criteria work without providing actual
>>> proof. I can think of numerous ways to construct a C routine which
>>> would meet conditions (a)-(c) but which would not be infinitely
>>> recursive.
>>>
>>
>> If X has no effect on Y until after Z then X can be ignored before Z.
>> X is a simulating halt decider
>> Y is its input program
>> Z When X makes its halt status decision.
>>
>> THIS IS A TRUISM THUS DISAGREEMENT IS ERROR
>> While H acts as a pure simulator of P(P) nothing that X does has any
>> effect on the behavior of P(P) therefore X can ignore its own behavior
>> while making its halt status decision.
>
> Declaring something to be a 'truism' doesn't magically make it true.
> That requires actual proof which you haven't given, whereas many people
> (myself included) have already explained at length why it is wrong.
>

It is impossibly incorrect.
Maybe this simplification is easy enough for you to understand:

If X cannot possibly have any effect on Y then there is never any reason
to study the effect of X on Y.

> It might sound plausible, but your sloppy use of the term 'its' destroys
> that plausibilty.
>
>> The only way to prove that the above infinite recursion detection
>> criteria are correct is to show that there are no counter-examples of
>> cases that meet the criteria and are not infinitely recursive.
>>
>> Once (a)(b)(c)(d) criteria have been met
>> not infinitely recursive is categorically impossible.
>
> As I said, I can think of numerous ways to write a C program which meets
> those requirements but which is not infinitely recursive.

Name at least one. That list has been the subject of numerous revisions
to make it as simple as possible.

> So clearly it
> isn't "categorically impossible". You should think about this rather
> harder. If you can't come up with counterexamples in a week or so maybe
> I'll provide some.

It has already been reviewed by two dozen reviewers, some of them
thought the same thing until they realized that they did not actually
pay attention to all the criteria.

>
> The crucial point is that just because *you* haven't thought of
> counterexamples doesn't mean there aren't any.

The only proof that it is true is a proof that no counter-examples can
possibly exist.

> You can't just declare
> something to be 'categorically impossible' unless you can actually
> *prove* this. You have note.
>
> And of course, even if these criteria worked they are completely
> worthless where actually TMs are concerned since TMs don't have machine
> addresses and can't call things.
>
>> This has been somewhat extensively reviewed.
>
> Which, again, doesn't make it true. It's not incumbent on others to make
> your case for you, and you make so many errors that people can't be
> bothered to point out all of them. People have been more focused on your
> patently false (d) rather than on the other three since that's the one
> which causes your H to get the wrong answer.
>
> André
>

The criteria for the actual Linz Ĥ are simply a little more difficult.

[olcott]

On 9/8/2021 5:20 PM, André G. Isaak wrote:

> On 2021-09-08 16:00, olcott wrote:
>> On 9/8/2021 4:27 PM, André G. Isaak wrote:
>>> On 2021-09-08 14:41, olcott wrote:
>
>>> Declaring something to be a 'truism' doesn't magically make it true.
>>> That requires actual proof which you haven't given, whereas many
>>> people (myself included) have already explained at length why it is
>>> wrong.
>>>
>>
>> It is impossibly incorrect.
>

> "impossibly incorrect" is not English. Illiterate buffoon makes you look
> like your continual (mis)use of this term.

>
>> Maybe this simplification is easy enough for you to understand:
>>
>> If X cannot possibly have any effect on Y then there is never any
>> reason to study the effect of X on Y.
>

> When H(P, P) is called, H cannot have an effect on P(P), but P(P) makes
> its own call to H(P, P). Your upper H *cannot* ignore this one because
> it is an entirely different process. It is *part* of the P(P) being
> evaluated by the upper H.
>
> This is patently obvious to everyone but you.

So go one and show the actual "patently obvious" error.
I am calling your bluff!

I know that no H in the entire recursive invocation chain has any effect
on the behavior of its input until after the outer-most H makes its halt
status decision.

I know that this outer-most H makes its halt status decision on the
basis that the behavior of its input has matched the infinite recursion
behavior pattern.

>
> Calling something a 'truism' when you haven't been able to convince even
> a single person of its truth is hardly warranted.

>
>>> It might sound plausible, but your sloppy use of the term 'its'
>>> destroys that plausibilty.
>>>
>>>> The only way to prove that the above infinite recursion detection
>>>> criteria are correct is to show that there are no counter-examples
>>>> of cases that meet the criteria and are not infinitely recursive.
>>>>
>>>> Once (a)(b)(c)(d) criteria have been met
>>>> not infinitely recursive is categorically impossible.
>>>
>>> As I said, I can think of numerous ways to write a C program which
>>> meets those requirements but which is not infinitely recursive.
>>
>> Name at least one. That list has been the subject of numerous
>> revisions to make it as simple as possible.
>

> I told you that I would, but that I would first give you a week or so to
> think about it further. Your approach has always been "this works for
> all the cases I considered, therefore it works in all cases" which is
> *not* valid logic. You should perhaps think of more cases. But of course
> it doesn't matter how many cases you consider, there will always be
> cases you haven't considered. That's why a proof can't simply consist of
> showing it works in some cases.
>

This has been under review for many months.
I am calling your bluff.

[olcott]

On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>>>>> No. That is obviously not true, except for some very rare languages
>>>>> that you probably don't know.
>>>>
>>>> At this point I would estimate that your technical competence is much
>>>> lower that I had assumed. I would ask you to provide a concrete
>>>> example and would estimate that you would dodge thus sufficiently
>>>> proving that your technical competence is very likely much lower that
>>>> I had assumed.
>>>
>>> As you know, whether I am right or not has nothing to do with either my
>>> competence or your opinion of it. TMs are not "code". Code can do IO,
>>> use static objects, examine its execution environment and so on. A lot
>>> of x86 code even has access to hardware-generated random numbers. You
>>> know this.
>>>
>>> If you want to talk code, stop using the notation for TM configurations.
>>> If you want to talk TMs, you will have to face the fact that you are
>>> wrong.
>>
>> So like I said you simply dodged supporting your obviously incorrect
>> rebuttal that identical code (sequences of state transitions) cannot
>> derive different results from the same input.
>
> Code is not a "sequence of state transitions", and TMs don't "derive
> results" (they accept, reject or fail to halt), but I don't want to get
> sucked into your bad wording.
>
> The state transition function of H and that at H^.qx are the same
> because one TM is an exact copy of the other (your words). The "inputs"
> (what you should call the tape) and the position of the tape head are
> also the same. The computations must evolve along exactly the same
> lines.
>

This would seem intuitive yet false.

If we look at it at the very high level of abstraction we can comprehend
that simulating halt decider H need not abort the simulation of its
input because the simulating halt decider at Ĥ.qx does abort the
simulation of its input.

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}

People that actually understand the C/x86 language will see that
simulating halt decider H1(P,P) need not abort the simulation of its
input because the execution trace of its input shows that its simulation
of P halts.

When we have two different halt deciders that must coordinate with each
other it was initially difficult to see the exact execution trace that
H1 and H used as their basis. I created a debug function that output
this full trace immediately before H1/H terminates.

H sees that its input never halts:
Output_Decoded_Instructions() [0025c7fd] size(336) capacity(240000)
[00001026][0025c7e9][0025c7ed] 55 push ebp
[00001027][0025c7e9][0025c7ed] 8bec mov ebp,esp // P begins
[00001029][0025c7e9][0025c7ed] 8b4508 mov eax,[ebp+08]
[0000102c][0025c7e5][00001026] 50 push eax
[0000102d][0025c7e5][00001026] 8b4d08 mov ecx,[ebp+08]
[00001030][0025c7e1][00001026] 51 push ecx
[00001031][0025c7dd][00001036] e8d0fdffff call 00000e06 // call H(P,P)
[00001026][002a7211][002a7215] 55 push ebp // P begins
[00001027][002a7211][002a7215] 8bec mov ebp,esp
[00001029][002a7211][002a7215] 8b4508 mov eax,[ebp+08]
[0000102c][002a720d][00001026] 50 push eax
[0000102d][002a720d][00001026] 8b4d08 mov ecx,[ebp+08]
[00001030][002a7209][00001026] 51 push ecx
[00001031][002a7205][00001036] e8d0fdffff call 00000e06 // call H(P,P)
END---Output_Decoded_Instructions(0025c7fd)


H1 simply sees that its simulated input halts:
Output_Decoded_Instructions() [00211dd5] size(288) capacity(240000)
[00001026][00211dc1][00211dc5] 55 push ebp // P begins
[00001027][00211dc1][00211dc5] 8bec mov ebp,esp
[00001029][00211dc1][00211dc5] 8b4508 mov eax,[ebp+08]
[0000102c][00211dbd][00001026] 50 push eax
[0000102d][00211dbd][00001026] 8b4d08 mov ecx,[ebp+08]
[00001030][00211db9][00001026] 51 push ecx
[00001031][00211db5][00001036] e8d0fdffff call 00000e06 // call H(P,P)
[00001036][00211dc1][00211dc5] 83c408 add esp,+08 // return to P
[00001039][00211dc1][00211dc5] 85c0 test eax,eax
[0000103b][00211dc1][00211dc5] 7402 jz 0000103f
[0000103f][00211dc5][00000cde] 5d pop ebp
[00001040][00211dc9][00001026] c3 ret // P halts
END---Output_Decoded_Instructions(00211dd5)


> Writing it out formally is unlikely to help because the argument needs a
> mapping between the states of H and H^ and I suspect that explaining
> that would either take months, or you'd declare it "extraneous" and
> refuse to even consider it. There's another way, but that involves a
> slight variation in the construction and you don't like such changes.
>
> There comes a point where no more clarity is available to you. If you
> don't know by now that the same transition function, operating on the
> same configuration can't result in transitions to different states, I
> don't think there is any hope that you ever will. I think you are
> doomed to be wrong and not know it, but if you think some more
> explanation might help, ask away.

[olcott]

On 9/8/2021 6:46 PM, Richard Damon wrote:
> On 9/8/21 2:12 PM, olcott wrote:
>> On 9/8/2021 12:59 PM, André G. Isaak wrote:
>>> On 2021-09-08 10:26, olcott wrote:
>>>> On 9/8/2021 9:48 AM, André G. Isaak wrote:

>>>>> I said that nothing can refer to itself *when dealing with Turing
>>>>> Machines*.

>>>>>
>>>>>> I showed you how Ĥ applied to ⟨Ĥ⟩ thus Ĥ refers to itself.
>>>>>

>>>>> You don't seem to be grasping my point. You are giving Ĥ a
>>>>> *description* of a Turing Machine. Descriptions don't refer to a
>>>>> Turing Machine, they describe a Turing Machine. When Ĥ is applied to
>>>>> (Ĥ), nothing refers to itself. Nothing refers to anything at all.
>>>>> You don't seem to grasp the distinction.
>>>>>
>>>>
>>>> The simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the simulated Ĥ.qx essentially refers to
>>>> itself.
>>>
>>> You don't seem to grasp what 'refer' means. ⟨Ĥ⟩ is a *description* of
>>> Ĥ. ⟨Ĥ⟩ doesn't "refer" to Ĥ.
>>>
>>>>> You've claimed that your H and H1 have identical code, but that H(P,
>>>>> P) and H1(P, P) will give different results because in the first
>>>>> case something refers to itself and in the latter it does not.
>>>>>
>>>>
>>>> Whether H and H1 have identical code is irrelevant. H1 can see that
>>>> its input halts and H can see that its input never halts.
>>>>
>>>>> I'm telling you that that claim is not coherently translatable into
>>>>> Turing Machines. AFAICT, your claim that H1(P, P) and H(P, P) return
>>>>> different results despite having identical code is based on H1 and H
>>>>> having different machine addresses. But Turing Machines don't *have*
>>>>> machine addresses and Turing Machines can't call other Turing Machines.
>>>>>
>>>>
>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ can see that its input halts and
>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ can see that its input never halts
>>>
>>> I have no idea what your use of the word 'see' means.

>>>
>>> But ⟨Ĥ⟩ ⟨Ĥ⟩ represents a *single* computation. It either halts or it
>>> doesn't.
>>>
>>
>> We could say the same thing about P(P), yet we can clearly see every

>> single step where H1(P,P) correctly reports that its input halts because
>> H(P,P) correctly reports that its input never halts.
>>
>

> So the description <P> <P> simultaneously describes a machine that both
> is correclly described as Halting and Non-Halt.
>
> That just PROVES that your logic is broken and has gone inconsistent.
>

The execution trace of the input to H1(P,P) conclusively proves that
this input definitely halts.

The execution trace of the input to H(P,P) called from H1(P,P)
conclusively proves that this input definitely never halts.

The following proves that the input definitely has the pathological
self-reference error (Olcott 2004)

int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}

The pathological self-reference error is the same error as the Liar
Paradox. The input to H1(P,P) does not refer to H1 so this is the
correct halt status value for P(P).


> This fully meets the definition on an inconsisten logic system as it has
> just 'proved' a statement and its negation.

>
>
>> You can ignore this forever, yet that will not make a verifiable fact
>> simply go away.
>

> Right, You system is now proven to be totally broken.
>

No it recognizes and corrects for the pathological self-reference
error(Olcott 2004) thus refutes Rice's Theorem and the halting Theorem
at the same time.

>>
>>> if H and Ĥ.qx "see" things differently, then one of them is correct
>>> and the other isn't.
>>>
>>
>> If you understood the x86 language well enough you could see that both
>> H1 and H are correct from their own frame-of-reference:
>
> IMPOSSIBLE
>
> Your MIND appears to be UNSOUND.

[olcott]

> Its a fact.

>
>> If we look at it at the very high level of abstraction we can
>> comprehend that simulating halt decider H need not abort the
>> simulation of its input because the simulating halt decider at Ĥ.qx
>> does abort the simulation of its input.
>

> The identical "machines" at H.q0 and H^.qx must perform exactly the same
> steps when presented with the same tape contents. H must transition to
> qn because H^.qx <H^><H^> does.
>

When one machine is called with an input that refers to its own machine
description and another machine is called with an input that does not
refer to its own machine description then the two computations are not
the same even if their machine descriptions may be otherwise identical.

I have empirical proof of this otherwise I may have not noticed this
myself. The execution trace that H derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows
that Ĥ.qx transitions to Ĥ.qn

The execution trace that Ĥ.qx derives of its input ⟨Ĥ⟩ ⟨Ĥ⟩ shows that
its input never halts.

As Richard aptly pointed out this shows that the system is inconsistent.
This particular inconsistency becomes a pathological self-reference
(Olcott 2004) decider refuting Rice's Theorem.

[olcott]

On 9/8/2021 10:29 PM, Richard Damon wrote:
> On 9/8/21 10:14 PM, olcott wrote:

>>> You are confused.  Of course the computations you describe are
>>> different.  H.q0 <H^><H^> and H^.q0 <H^> are indeed not the same but
>>> H.q0 <H^><H^> and H^.qx <H^><H^> are (with a minor difference you refuse
>>> to accept anyway).
>>>
>>
>> You can't understand that when H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ the execution trace
>> of this simulation shows that Ĥ.qx transitions to Ĥ.qn on input ⟨Ĥ⟩ ⟨Ĥ⟩
>> ???
>
> Right, and H^ going to H^.qn means that H^ halted, as that is a halting
> state of H^.
>
> THe fact that to H, that state indicated that it thinks its input is
> non-halting doesn't change the meaning of the state to H^.
>

No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many times.
No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many times.
No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many times.
No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many times.

Your insight that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn seems to indicate an
inconsistent system was helpful, yet untrue.

It is definitely an inconsistency, yet not because the system is
inconsistent.

int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}

The above decidability decider correctly rejects the input.


> Is THAT your confusion,
>
>>
>> In simpler terms you can't understand that a UTM can examine the
>> execution trace of its simulated TM?
>
> Yes, a UTM can examine it trace, but a real UTM won't stop until the
> machine it is simulating does, no matter how sure it is that it won't.
>
> The problem is when H uses this analysis, and uses the FALSE assumption
> that other copies of H will act only as UTM, and not switch out of that
> mode leter and also abort their simulation, that cause H to get the
> wrong answer.
>
> H (like you) used UNSOUND Logic, and got the wrong answer.

[olcott]

On 9/9/2021 12:16 AM, André G. Isaak wrote:
> On 2021-09-08 20:02, olcott wrote:
>> On 9/8/2021 8:21 PM, André G. Isaak wrote:

>>> On 2021-09-08 16:34, olcott wrote:
>>>> On 9/8/2021 5:20 PM, André G. Isaak wrote:
>>>>> On 2021-09-08 16:00, olcott wrote:
>>>>>> On 9/8/2021 4:27 PM, André G. Isaak wrote:
>>>>>>> On 2021-09-08 14:41, olcott wrote:
>>>>>
>>>>>>> Declaring something to be a 'truism' doesn't magically make it
>>>>>>> true. That requires actual proof which you haven't given, whereas
>>>>>>> many people (myself included) have already explained at length
>>>>>>> why it is wrong.
>>>>>>>
>>>>>>
>>>>>> It is impossibly incorrect.
>>>>>
>>>>> "impossibly incorrect" is not English. Illiterate buffoon makes you
>>>>> look like your continual (mis)use of this term.
>>>>>
>>>>>> Maybe this simplification is easy enough for you to understand:
>>>>>>
>>>>>> If X cannot possibly have any effect on Y then there is never any
>>>>>> reason to study the effect of X on Y.
>>>>>
>>>>> When H(P, P) is called, H cannot have an effect on P(P), but P(P)
>>>>> makes its own call to H(P, P). Your upper H *cannot* ignore this
>>>>> one because it is an entirely different process. It is *part* of
>>>>> the P(P) being evaluated by the upper H.
>>>>>
>>>>> This is patently obvious to everyone but you.
>>>>
>>>> So go one and show the actual "patently obvious" error.
>>>> I am calling your bluff!
>>>

>>> I just did. The H which is *evaluating* the input P(P) can't affect
>>> the behaviour of its input, but the second call to H *isn't*
>>> evaluating P(P), it is *part* of the computation performed by P(P)
>>> and that computation is critically dependent on what that H does. You
>>> can't just ignore it.
>>>
>>
>> None of the recursive invocations of H has any effect on the behavior
>> of its input until after the behavior of its input has matched the
>> INFINITE_LOOP or INFINITE_RECURSION behavior pattern.
>>
>> Every time that such a rebuttal is made I utterly refute it and my
>> refutation is simply ignored. Later on the same lame rebuttal (that
>> does not even bother to connect most of its ideas together) is
>> presented again.
>
> You've never 'utterly refuted' anything. You just keep reiterating your
> original position in response to clear evidence that your initial
> position is simply wrong.

The key evidence is my code and you can't see my code so you can't
truthfully say what my code does. Even though you can't truthfully say
this you dishonestly say what it does anyway.

> You keep using terms like 'its input' and 'its
> simulator' where 'its' rather sloppily refers to the wrong things. You
> really need to strike the word 'its' from your vocabulary altogether.
>

When H(P,P) is invoked none of its recursive invocations has any effect
on the halting behavior of P(P) until after a non-halting behavior
pattern has been matched.

Until a non-halting behavior pattern has been matched H merely simulates
its input and examines the execution trace of this simulation. Neither
of these things can possibly have any effect on the behavior of the input.

>>>> I know that no H in the entire recursive invocation chain has any
>>>> effect on the behavior of its input until after the outer-most H
>>>> makes its halt status decision.
>>>>
>>>> I know that this outer-most H makes its halt status decision on the
>>>> basis that the behavior of its input has matched the infinite
>>>> recursion behavior pattern.
>>>

>>> But your 'infinite recursion behaviour pattern' is flawed. In this
>>> particular instance precisely because of your (d).

>>>
>>>>>
>>>>> Calling something a 'truism' when you haven't been able to convince
>>>>> even a single person of its truth is hardly warranted.
>>>>>
>>>>>>> It might sound plausible, but your sloppy use of the term 'its'
>>>>>>> destroys that plausibilty.
>>>>>>>
>>>>>>>> The only way to prove that the above infinite recursion
>>>>>>>> detection criteria are correct is to show that there are no
>>>>>>>> counter-examples of cases that meet the criteria and are not
>>>>>>>> infinitely recursive.
>>>>>>>>
>>>>>>>> Once (a)(b)(c)(d) criteria have been met
>>>>>>>> not infinitely recursive is categorically impossible.
>>>>>>>
>>>>>>> As I said, I can think of numerous ways to write a C program
>>>>>>> which meets those requirements but which is not infinitely
>>>>>>> recursive.
>>>>>>
>>>>>> Name at least one. That list has been the subject of numerous
>>>>>> revisions to make it as simple as possible.
>>>>>
>>>>> I told you that I would, but that I would first give you a week or
>>>>> so to think about it further. Your approach has always been "this
>>>>> works for all the cases I considered, therefore it works in all
>>>>> cases" which is *not* valid logic. You should perhaps think of more
>>>>> cases. But of course it doesn't matter how many cases you consider,
>>>>> there will always be cases you haven't considered. That's why a
>>>>> proof can't simply consist of showing it works in some cases.
>>>>>
>>>>
>>>> This has been under review for many months.
>>>> I am calling your bluff.
>>>

>>> Your really that adverse to thinking on something for a week?
>>>
>>> Just to give you a few hints, though, your (a)-(c) make no mention of
>>> (among other things) cases where the routine manipulates the contents
>>> of the stack or the stack pointer, or cases where the routine
>>> involves self-modifying code. There's all sorts of creative ways to
>>> meet your criteria without being infinitely recursive using those.
>>>
>>
>> I am not convinced that this is a counter-example, yet it does seem
>> reasonably plausible. The current code does not do that so we can see
>> that the halt decider did decide correctly.
>
> Whether you are convinced or not isn't the issue. Since you claim it is
> 'reasonably plausible' you need to actually think it through. I assure
> you it is possible to create routines which meet your 'infinite
> recursion pattern' but which are not infinitely recursive using these
> strategies. Without actually showing that it is *impossible* to do so
> (which you can't because it isn't), claiming you don't find it
> convincing doesn't get you very far.
>
> Whether the current code does so or not isn't relevant since I was
> responding to your statement that once your criteria are met "not

> infinitely recursive is categorically impossible."
>

I concede that you may be right.

>> This only requires that the halt decider be made more elaborate, not
>> that the "impossible input" cannot be correctly decided.
>
> 'Must be made more elaborate' isn't worth much unless you can actually
> demonstrate that it is *possible* to make them more elaborate to the
> extent that they cover all cases. You can't.
>

It need not cover all cases. It only needs to cover the simplest
instance of the "impossible" case. It does that now. Human inspection of
the code (by honest people that know the x86 language) proves that it
never halts unless H aborts its simulation of this code.

>> I simply assume that all of the code is generated by the Microsoft C
>> compiler. x86utm can only read COFF object files.
>
> Relevance? The strategies for breaking your 'infinite recursion pattern'
> I offered are all possible using the Microsoft C compiler.
>
> André

[olcott]

On 9/9/2021 6:02 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 9/8/2021 8:54 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 9/8/2021 5:11 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/8/2021 11:49 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>

>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ can see that its input halts and
>>>>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ can see that its input never halts

>>>>>>>>>>> TMs don't 'see' anything.
>>>>>>>>>>
>>>>>>>>>> OK so in other words a TM always ignores all of its tape elements.
>>>>>>>>> No. And, frankly, that's a childish way to avoid the issue.
>>>>>>>>
>>>>>>>> Not as childish as you not being able to understand what it means when
>>>>>>>> a machine sees a sequence of data indicating an execution trace.
>>>>>>> Whatever one "sees", the other "sees". Two identical TMs (I referred to
>>>>>>> their state transition functions because there are other technical
>>>>>>> matters that are beyond you) when presented with the same data on the
>>>>>>> tape go through exactly the same transitions.
>>>>>>
>>>>>> So in other words you are saying that the simulated TM description Y
>>>>>> that UTM X is simulating can see all of the behavior of its simulator?
>>>>>
>>>>> At this point I don't think I can help any more. I can't think of any
>>>>> way of explaining it more clearly. In fact, I'm not at all sure you
>>>>> really don't understand -- it's such a simple point -- but I have to
>>>>> take your word for it. You are doomed to be wrong and not know it.
>>>>
>>>> The reason that H has different behavior than its input ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>
>>> No one disputes that. You really don't know what's going on. It's
>>> H.q0 <H^><H^> and H^.qx <H^><H^> that exhibit exactly the same
>>> behaviour. Specifically, both transition to the rejecting state qn.
>>>
>>>> When you make a mistake I show you how to understand that your mistake
>>>> is obvious. It is obvious that the simulated TM cannot see what its
>>>> UTM is doing. It is not so obvious that this provides the basis for H
>>>> and its simulated input to have different behavior.
>>>
>>> You are totally at sea. I don't see any hope of you [ever] understanding
>>> what's being said. Identical transition functions imply identical
>>> computations given identical inputs. You need to stop waffling and
>>> start paying attention.
>>
>> When you can't comprehend what I am saying instead of trying to
>> incorrectly point out any mistakes when there are none you switch from
>> reasoning to rhetoric.
>
> I switch from reasoning when I can't put the reasoning any clearer. My
> best effort at explaining why you are wrong is still there for everyone
> to see. My purpose is just be as clear as possible, and I don't think I
> can be any clearer now:
>
> H.q0 <H^><H^> and H^.qx <H^><H^> exhibit exactly the same behaviour
> since they share (isomorphic) state transition functions, and the tapes
> contains the same strings. Both transition to the rejecting state qn.
>

Although that would seem to be intuitively correct empirical proof shows
otherwise. This is easiest to understand in the C/x86 model.

Here it is in the Linz model:

H ⟨Ĥ⟩ ⟨Ĥ⟩ sees

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

∴ H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy

We can see that it actually does work that way by
the H1/P proxy for H/Ĥ

void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}

H(P,P) reports 0
H1(P,P) reports 1

>> Gullible fools are convinced by this never noticing that you are
>> merely hiding the fact that you have no actual correct rebuttal at
>> all.
>
> It's there for all to see.
>
> What is so striking, though, is the dramatic the change in your plan.
> You spent many, many months arguing (unsuccessfully) that for your x86
> code H(H_Hat, H_Hat) == false was the "correct" answer despite the fact
> that a trace showed H_Hat(H_Hat) halting. A lots of words were thrown
> about to justify the wrong answer from H. You had even "adjusted" the
> definition of halting. False was correct because of what H_Hat(H_hat)
> would do were it not actually "halted".
>

H(P,P) correctly reports that its input never halts.
H1(P,P) correctly reports that its input halts.

The difference between these two creates a decidability decider that
refutes Rice.

> So why are you not happy to agree that, in the TM model you appear to be
> talking about here, H rejects <H^><H^>? H rejecting <H^><H^> was, in
> the x86 world, the correct answer for a very long time. When did you
> change your mind, or did you only change your mind for TMs? Is false
> now the wrong return from H(H_Hat, H_Hat)?

[olcott]

On 9/9/2021 6:05 AM, Richard Damon wrote:
> On 9/9/21 12:10 AM, olcott wrote:
>> On 9/8/2021 10:50 PM, Richard Damon wrote:
>>> On 9/8/21 11:30 PM, olcott wrote:
>>>> On 9/8/2021 10:20 PM, Richard Damon wrote:
>>>>> On 9/8/21 10:33 PM, olcott wrote:
>>>>>> On 9/8/2021 8:32 PM, Richard Damon wrote:
>>>>>>> On 9/8/21 9:17 PM, olcott wrote:
>>>>>>>> On 9/8/2021 8:09 PM, André G. Isaak wrote:

>>>>>>>>> On 2021-09-08 18:01, olcott wrote:
>>>>>>>>>
>>>>>>>>>> The execution trace of the input to H1(P,P) conclusively proves
>>>>>>>>>> that
>>>>>>>>>> this input definitely halts.
>>>>>>>>>>
>>>>>>>>>> The execution trace of the input to H(P,P) called from H1(P,P)
>>>>>>>>>> conclusively proves that this input definitely never halts.
>>>>>>>>>

>>>>>>>>> No. The execution trace shows that your halt decider decides to
>>>>>>>>> abort
>>>>>>>>> the simulation. That's completely different from showing that this
>>>>>>>>> input 'definitely never halts'. Your grasp of what traces show is
>>>>>>>>> seriously lacking.
>>>>>>>>>
>>>>>>>>> Since P(P) either halts or it doesn't, it isn't possible for
>>>>>>>>> both of
>>>>>>>>> the above deciders to be correct. So how can they both
>>>>>>>>> 'conclusively
>>>>>>>>> prove' contradictory answers?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Richard said that such a system would be inconsistent.
>>>>>>>> I agree, this is a key new insight.
>>>>>>>
>>>>>>> Right, YOUR LOGIC SYSTEM has been shown to be inconsistent, likelyy
>>>>>>> because you have assumes a (or many) false statements as fact.
>>>>>>>
>>>>>>>>
>>>>>>>> Since the execution trace of the input to H1(P,P) conclusively
>>>>>>>> proves
>>>>>>>> that it halts and the execution trace of the input to H(P,P)
>>>>>>>> conclusively proves that it never halts we do have an inconsistent
>>>>>>>> system.
>>>>>>>
>>>>>>> Right, YOU LOGIC that says the two are correct is faulty and
>>>>>>> inconsistent.
>>>>>>>
>>>>>>>>
>>>>>>>> It is inconsistent on the basis of its input that has the
>>>>>>>> pathological
>>>>>>>> self-reference(Olcott 2004) error, which is detected by this code:
>>>>>>>>
>>>>>>>
>>>>>>> Nope.

>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>      if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>>>>>>>        OutputString("Pathological self-reference error!");
>>>>>>>> }
>>>>>>>>

>>>>>>>> Thus refuting Rice's theorem and the halting theorem. We accept the
>>>>>>>> H1(P,P) halt status as correct because P does not refer to H1.
>>>>>>>>
>>>>>>>
>>>>>>> Nope, FAIL.
>>>>>>>
>>>>>>
>>>>>> You never try to show how I am wrong you merely assert that you
>>>>>> believe
>>>>>> that I am wrong. If you cannot show my mistake that is for one of two
>>>>>> reasons:
>>>>>
>>>>> The criteria that you are claiming to decide on is Syntactic, not
>>>>> Symantec, and thus not under the domain of Rice's theorem.
>>>>>
>>>>
>>>> Ah great now that you committed to a position I can say that you are
>>>> wrong. An undecidability decider decides a semantic property.
>>>>
>>>>>>
>>>>>> (1) I made no mistake
>>>>>> (2) You don't understand these things very well
>>>>>
>>>>> You don't understand what you claim to be disproving.
>>>>>
>>>>>>
>>>>>> That the system derives an inconsistent result and each result is
>>>>>> confirmed to be correct means bad input.
>>>>>
>>>>> If a system is inconsistent, it isn't the 'inputs' that are bad (as in
>>>>> the inputs to the machines). The LOGIC SYSTEM is bad, and that shows
>>>>> that the 'axioms' used to build it (your 'truisms') are flawed.
>>>>>
>>>>
>>>> Since we can verify by the execution trace that H1(P,P)==1 is correct
>>>> and H(P,P)==0 is correct it is not the logical system.
>>>>
>>>> "This sentence is not true" has the same error and it is not the fault
>>>> of the logic system.
>>>
>>> So you thing that it is possible for the statement "H^(<H^>) is a
>>> Halting Computation" can both be True and False?
>>>
>>> The fact that you claim the execution traces prove it, just shows that
>>> the inconsitency runs deep in the system, and isn't just a small error
>>> at the end.
>>>
>>> Basically you are admitting that your system if fatally flawed, only you
>>> are smart enough to see it.

>>>
>>
>>
>> It is definitely an inconsistency, yet not because the system is
>> inconsistent.
>

> Your choices are either your logic system is inconsistent, or H is
> inconsistent in the value it produces, and thus you have LIED in calling
> it a Computation.
>
> That is your choices.

>
>>
>>  int main()
>>  {
>>     if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>       OutputString("Pathological self-reference error!");
>>  }
>>

>> The above decidability decider correctly rejects the input
>

> So? You have just created some criteria that you can show one example
> that it decides correctly. Doesn't mean that you actually shown anything.
>

The decidability decider proves that the input is bad because is has the
pathological self-reference(Olcott 2004) error.

The source of the inconsistency is bad data not incorrect formal system.
"This sentence is not true" is another example of this same bad data.

> Can you describe in WORDS that don't refer to the program what the
> condition you are deciding on actually is? Something that is Semantic in
> definition. Then we can see if your 'Universal Decidability Decider'
> actually works.
>

It is the pathological self-reference error:
(a) "This sentence is not true"
(b) "This sentence is unprovable"
(c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts


> SO far, it just sounds like you have defined this decider to decide what
> its output will be.
>
>>
>>
>>>>
>>>>> You don't even seem to know the basics of Logic systems.
>>>>>
>>>>>>
>>>>>> The only reason why people "believe" that the system is wrong is that
>>>>>> they very diligently make sure to not pay attention.
>>>>>
>>>>>
>>>>>>
>>>>>> The input to H cannot possibly ever halt unless H aborts its
>>>>>> simulation
>>>>>> of this input. This is an easily verified fact that everyone
>>>>>> (a) Dishonestly ignores
>>>>>> (b) Dishonestly rejects
>>>>>> (c) Intentionally fails to comprehend
>>>>>>
>>>>>
>>>>> But you just keep using the WRONG definition of Halting.
>>>>>
>>>>> The fact that H^ does Halt, for what ever reason, means it is a Halting
>>>>> Computation.
>>>>>
>>>>> Remember, to even talk abort any machine H^, you FIRST had to fix your
>>>>> definition of H, as it is based on it. Every time you mention changing
>>>>> H, everything you though you proved about H^ needs to be thrown out
>>>>> until you go back to that original H.
>>>>>
>>>>> THAT is part of the flaw of your logic, you mix different H^s and use
>>>>> them with the wrong Hs.

[olcott]

On 9/9/2021 10:05 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> It is the pathological self-reference error:

> ...

>> (c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
>

> (1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to say
> that an input (presumably a string) does or does not halt? The only
> reasonable answers show that you are wrong.
>

Since it is well established and repeated 12 times a day every day for
six months that H and Ĥ.qx are simulating halt deciders it is 100%
perfectly clear exactly what the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does not halts
means. You are being a total jackass when you pretend to forget that
after you have been told 10,000 times.

> (1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> (2) The only reasonable meaning for whether a string halts or not would
> be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting
> computation (because Ĥ(⟨Ĥ⟩) is a halting computation).
>

It would seem that way only if you very diligently make sure to not pay
attention to the execution trace of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, which can
only be 100% fully elaborated by its proxy computation H(P,P).

Perhaps your lack of understanding of the C/x86 H(P,P) computation
proves that our dialogue can never be fruitful thus no sense in continuing.

It is the case that H(P,P)==0 is correct
It is the case that H1((P,P)==1 is correct
It is the case the this is inconsistent.
It is the case that this inconsistency defines a decidability
decider that correctly rejects P on the basis that P has the
pathological self-reference(Olcott 2004) error.


> Your sentence actually has poor choices of words because, in addition to
> (1) and (2), "Ĥ halts" is also meaningless. Computations halt (or
> don't) not Turing machines.
>
> A note to other readers: the poor use of words is deliberate. 90% of
> PO's posting use vague undefined notions because saying things clearly
> just makes the mistakes too obvious. "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never
> halts" is a magic incantation, often repeated, that is never explained.
> When pushed, the answer is typically some crank non-explanation: "so you
> don't know what an input is?".

[André G. Isaak]

On 2021-09-09 07:34, olcott wrote:
> On 9/9/2021 12:16 AM, André G. Isaak wrote:
>> On 2021-09-08 20:02, olcott wrote:
>>> On 9/8/2021 8:21 PM, André G. Isaak wrote:
>>>> On 2021-09-08 16:34, olcott wrote:
>>>>> On 9/8/2021 5:20 PM, André G. Isaak wrote:
>>>>>> On 2021-09-08 16:00, olcott wrote:
>>>>>>> On 9/8/2021 4:27 PM, André G. Isaak wrote:
>>>>>>>> On 2021-09-08 14:41, olcott wrote:
>>>>>>

> The key evidence is my code and you can't see my code so you can't
> truthfully say what my code does. Even though you can't truthfully say
> this you dishonestly say what it does anyway.

I see. The "I have proof but its level 12 scientology and you're only
paid up for level 9" defence.

I'm sure that will go over well with actual journals. "The key evidence
is my code but you're not allowed to see it."

>> You keep using terms like 'its input' and 'its simulator' where 'its'
>> rather sloppily refers to the wrong things. You really need to strike
>> the word 'its' from your vocabulary altogether.
>>
>
> When H(P,P) is invoked none of its recursive invocations has any effect
> on the halting behavior of P(P) until after a non-halting behavior
> pattern has been matched.

Yet another 'its'.

> Until a non-halting behavior pattern has been matched H merely simulates
> its input and examines the execution trace of this simulation. Neither
> of these things can possibly have any effect on the behavior of the input.

But your halting pattern doesn't actually work.

Which is an acknowledgment that your criteria are not sound.

>>> This only requires that the halt decider be made more elaborate, not
>>> that the "impossible input" cannot be correctly decided.
>>
>> 'Must be made more elaborate' isn't worth much unless you can actually
>> demonstrate that it is *possible* to make them more elaborate to the
>> extent that they cover all cases. You can't.
>>
>
> It need not cover all cases. It only needs to cover the simplest
> instance of the "impossible" case. It does that now. Human inspection of
> the code (by honest people that know the x86 language) proves that it
> never halts unless H aborts its simulation of this code.

But your 'argument' for H(P, P)==0 being 'correct' rests on the claim
that your criteria are sound. They are not. It also rests on the
assumption that the actual answer isn't important which is a rather odd
position to take.

To get the "impossible" case right, you need H(P, P)==1.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

[olcott]

On 9/9/2021 4:08 PM, André G. Isaak wrote:
> On 2021-09-09 07:34, olcott wrote:
>> On 9/9/2021 12:16 AM, André G. Isaak wrote:
>>> On 2021-09-08 20:02, olcott wrote:
>>>> On 9/8/2021 8:21 PM, André G. Isaak wrote:
>>>>> On 2021-09-08 16:34, olcott wrote:
>>>>>> On 9/8/2021 5:20 PM, André G. Isaak wrote:
>>>>>>> On 2021-09-08 16:00, olcott wrote:
>>>>>>>> On 9/8/2021 4:27 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-09-08 14:41, olcott wrote:
>>>>>>>
>
>> The key evidence is my code and you can't see my code so you can't
>> truthfully say what my code does. Even though you can't truthfully say
>> this you dishonestly say what it does anyway.
>
> I see. The "I have proof but its level 12 scientology and you're only
> paid up for level 9" defence.
>
> I'm sure that will go over well with actual journals. "The key evidence
> is my code but you're not allowed to see it."
>
>>> You keep using terms like 'its input' and 'its simulator' where 'its'
>>> rather sloppily refers to the wrong things. You really need to strike
>>> the word 'its' from your vocabulary altogether.
>>>
>>
>> When H(P,P) is invoked none of its recursive invocations has any
>> effect on the halting behavior of P(P) until after a non-halting
>> behavior pattern has been matched.
>
> Yet another 'its'.

Should I have used thems instead?

>
>> Until a non-halting behavior pattern has been matched H merely
>> simulates its input and examines the execution trace of this
>> simulation. Neither of these things can possibly have any effect on
>> the behavior of the input.
>
> But your halting pattern doesn't actually work.

It is quite dishonest to say that something that works quite well for
its intended purpose does not work at all.

You know this is not the case and it is a damn lie for you to say
otherwise. Unsound means always wrong.

>
>>>> This only requires that the halt decider be made more elaborate, not
>>>> that the "impossible input" cannot be correctly decided.
>>>
>>> 'Must be made more elaborate' isn't worth much unless you can
>>> actually demonstrate that it is *possible* to make them more
>>> elaborate to the extent that they cover all cases. You can't.
>>>
>>
>> It need not cover all cases. It only needs to cover the simplest
>> instance of the "impossible" case. It does that now. Human inspection
>> of the code (by honest people that know the x86 language) proves that
>> it never halts unless H aborts its simulation of this code.
>
> But your 'argument' for H(P, P)==0 being 'correct' rests on the claim
> that your criteria are sound. They are not. It also rests on the
> assumption that the actual answer isn't important which is a rather odd
> position to take.
>

By human inpection we can that the exception to the rule is not met thus
the criteria did work correctly for its input. It really is quite
dishonest of you to say otherwise. Why lie?

> To get the "impossible" case right, you need H(P, P)==1.
>
> André
>


--

[olcott]

On 9/11/2021 6:41 PM, Richard Damon wrote:
> On 9/11/21 7:14 PM, olcott wrote:
>> On 9/11/2021 6:05 PM, Richard Damon wrote:
>>> On 9/11/21 6:53 PM, olcott wrote:
>>>
>>>> It is a verifiable fact that none of them do until after the halt status
>>>> decision is made thus eliminating the otherwise impossible feedback loop
>>>> where the input changes its behavior based on the behavior of the halt
>>>> decider.
>>>>
>>>
>>> If tempreral order of decision and action matter, decide that you will
>>> live, then put a pistol to your head and pull the trigger. Since you did
>>> that action after deciding otherwise it won't have any affect, right?
>>>
>>> That is your claim.
>>>
>>> The fact that H will at some point make the decision to abort its
>>> simulation and return non-halting, means that it does affect that
>>> machine that it is calling it, and that machine will halt.
>>>
>>
>> That topic is not under discussion.
>
> Why not?
>
>> We are only discussing whether or not H can ignore its own behavior when
>> it examines the execution trace of its input.
>
> Since H DOES abort it simulation and return the non-halting answer to P
> and that causes P to halt shows that the H simulating this machihne
> can't ignore that behavior.

I say H does not have any effect on the simulation of its input while H
remains in pure simulation mode.

Your fake "rebuttal" claims that I am wrong because H does have an
effect on its input when H is not in pure simulation mode.

Even fools can tell that is a dishonest move, and there are no fools in
this forum. Why foolishly lie?

A straw man (sometimes written as strawman) is a form of argument and an
informal fallacy of having the impression of refuting an argument,
whereas the real subject of the argument was not addressed or refuted,
but instead replaced with a false one.
https://en.wikipedia.org/wiki/Straw_man

[olcott]

On 9/12/2021 1:35 PM, Richard Damon wrote:
> On 9/12/21 2:00 PM, olcott wrote:
>> On 9/12/2021 12:51 PM, André G. Isaak wrote:
>>> On 2021-09-12 11:31, olcott wrote:
>>>> On 9/12/2021 12:20 PM, André G. Isaak wrote:
>>>>> On 2021-09-12 11:00, olcott wrote:
>>>>>> On 9/12/2021 10:47 AM, André G. Isaak wrote:
>>>>>>> On 2021-09-12 07:43, olcott wrote:
>>>>>>>
>>>>>>>> [I say that H does not have any effect on the behavior of its
>>>>>>>> input while H remains in pure simulation mode]
>>>>>>>>
>>>>>>>> Do you agree with the above statement: Yes or No.
>>>>>>>>
>>>>>>>> Your language is so equivocal that I can't make out whether you
>>>>>>>> agree with the above statement or not. We can move on to the next
>>>>>>>> half of the same point if you agree with the above statement.
>>>>>>>
>>>>>>> There's nothing remotely equivocal about Richard's language.
>>>>>>
>>>>>>
>>>>>> The boil it down to a Yes or No:
>>>>>>
>>>>>> [I say that H does not have any effect on the behavior of its input
>>>>>> while H remains in pure simulation mode]
>>>>>>
>>>>>> Do you agree with the above statement: Yes or No.
>>>>>>
>>>>>> Any reply besides Yes or No will be construed as a dishonest dodge.
>>>>>
>>>>> You can't demand a yes or no answer if the statement itself is
>>>>> ambiguous or poorly defined.
>>>>>
>>>>> Your statement can be construed as true for certain interpretations
>>>>> of that statement (one in which the terms used have *consistent*
>>>>> referents), but it is clear that you are *not* using that
>>>>> interpretation but another interpretation which is clearly false.
>>>>>
>>>>
>>>> OK then I will define pure simulation mode tautologically.
>>>> The simulation mode of a simulating halt decider is defined as the
>>>> mode such that the simulating halt decider only acts as a pure
>>>> simulator of its input that watches the execution trace of this input
>>>> and has no effect on the behavior of its input while it is in
>>>> simulation mode.
>>>
>>> And how does that fix anything? You're still abusing the referents in
>>> the above. (And btw you really need to come up with a better term than
>>> 'mode'. Computations don't have "modes.")
>>>
>>> Let's try to lay this out more clearly. You have a halt decider, A,
>>> which takes an input, B. In this example the halt decider A is H and
>>> the input B is P(P). While B is being simulated, it simulates another
>>> computation C with an input D. Once again in this case C equals H and
>>> D equals P(P).
>>>
>>
>> No. Simulating halt decider H which simulates its input P
>> calls simulating halt decider H which simulates its input P
>> calls simulating halt decider H which simulates its input P
>
> The key fact that you seem to miss is that each of those things called
> 'simulating halt decider H' are distinct instances of the execution of
> the algorithm of your Halt Decider, and properties that actually refer
> to a given instance, apply only to the one that the property applies to.
SUMMATION

The bottom line of all of this is that all of the conventional halting
problem counter examples can be recognized as infinitely recursive
simulation to every simulating halt decider.

This simulating halt decider must remain in pure simulation mode until
after it detects an infinite behavior pattern in the execution trace of
its input.

By doing this it bypasses the conventional feedback loop where the input
program behaves in the opposite way of whatever the simulating halt
decider decides.

This also allows it to ignore its own behavior in the execution trace
that it analyzes because a pure simulator cannot have any possible
effect on the behavior of its input.

This also provides an objective and unbiased measure of non-halting
behavior. Any input to a simulating halt decider that never halts unless
its simulation is aborted is an input that never halts.