On 6/23/2021 5:01 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 6/22/21 10:15 PM, olcott wrote:
>>> On 6/22/2021 8:47 PM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>>>>> Ahhh. Good. Okay, well I am still wondering why, when I tell him to
>>>>> run his "halt decider" against an unknown, black box program created
>>>>> by somebody else... Well, he seems to get pissed off. Afaict, his
>>>>> decider only works on programs that he already knows are,
>>>>> decided. Cheating 101?  Or what? ;^o
>>>>
>>>> Well he flip-flops on this.  He keeps saying that he has a halt decider
>>>> (sometimes without realising that he's said it) but when this is pointed
>>>> out he claims he only cares about the one case -- the "hat" construction
>>>> given in so many proofs.
>>>>
>>>> That, alone, would be noteworthy because it's impossible.  Way back in
>>>> Dec 2018, he was waffling about a decider for one case (which is
>>>> trivial), when someone (I think it was Mike Terry) spotted that he was
>>>> actually claiming to have a TM H that gave the correct result for the
>>>> computation <[H^], [H^]> (my notation -- I'll explain it if you really
>>>> care about the details).  Once it was pointed out that everyone knows
>>>> this is impossible PO was delighted and wrote things like:
>>>>
>>>>    "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>    specs does not exist. I now have a fully encoded pair of Turing
>>>>    Machines H / Ĥ proving them wrong."
>>>>
>>>>    "I now have an actual H that decides actual halting for an actual (Ĥ,
>>>>    Ĥ) input pair.  I have to write the UTM to execute this code, that
>>>>    should not take very long.  The key thing is the H and Ĥ are 100%
>>>>    fully encoded as actual Turing machines."
>>>>
>>>>    "I am waiting to encode the UTM in C++ so that I can actually execute
>>>>    H on the input pair: (Ĥ, Ĥ). This should take a week or two. It is not
>>>>    a universal halt decider, yet it is exactly and precisely the Peter
>>>>    Linz H and Ĥ, with H actually deciding input pair: (Ĥ, Ĥ) on the basis
>>>>    of Ĥ actually deciding itself."
>>>>
>>>> I refer to this as the Big Lie because, of course, he never had any such
>>>> pair of TMs, but as you can see, it was getting one (impossible) case
>>>> right that was the jumping-off point for the last two an half years of
>>>> nonsense.
>>>
>>> Yes and of course when I make a C program that is computationally
>>> equivalent to the standard relation between the HP halt decider and its
>>> impossible input and show all of the steps of how this halt decider
>>> correctly decides this "known" to be impossible input that does not
>>> count at all because it is not 100% perfectly an actual TM.
>>
>> Except that it isn't because H^ doesn't make copies as it is supposed to
>> so you don't end up with a true equivalent. This lets you 'cheat' to
>> detect the recursion that doesn't really exist in the original
>> problem.
>
> This is obviously a problem in the formal sense, but it can be worked
> round in that there is a halting problem for C-like functions that use
> pointers as the "representation" and therefore the "hat" construction
> does not copy its input. It's just a bit fiddly to pin down the rules
> of what's allowed.
>
> The curious fact is that PO does not use this breaking of the rules to
> get the right answer. By using external state (as his "Halts" function
> apparently does) it's possible for Halts(Confound_Halts, Confound_Halts)
> to be correct about the halting of Confound_Halts(Confound_Halts).
>
> But that is not his plan. His plan is to write yards and yards of text
> to try to persuade someone, anyone, that the wrong answer is the right
> answer.
>

Which of these seems to be untrue and why?

Premise(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.

Premise(2) The simulation of the input to H(P,P) never halts without
being aborted is a verified fact on the basis of its x86 execution
trace. (shown below).

From the above true premises it necessarily follows that
simulating halt decider H correctly reports that its input: (P,P) never
halts.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 23 June 2021 at 11:57:06 UTC+1, Richard Damon wrote:
>> On 6/22/21 11:21 PM, olcott wrote:
>> > On 6/22/2021 10:00 PM, Richard Damon wrote:
>> >>
>> >>> Yes and of course when I make a C program that is computationally
>> >>> equivalent to the standard relation between the HP halt decider and its
>> >>> impossible input and show all of the steps of how this halt decider
>> >>> correctly decides this "known" to be impossible input that does not
>> >>> count at all because it is not 100% perfectly an actual TM.
>> >>
>> >> Except that it isn't because H^ doesn't make copies as it is supposed to
>> >> so you don't end up with a true equivalent.
>> >
>> > Others know that it is sufficiently equivalent.
>> There is no 'sufficiently' it only is or it isn't.
>>
>> Is 2.0001 sufficiently equivalent to 2? Its pretty close, but is it
>> equivalent.
>>
> PO's system uses x86 code instead of Turing machines. That enables him
> to detect when the halt decider is being called on a program including itself.
> That's not the root of the error (the halting problem also applies to x86
> programs) but it is the root of the confusion.
> PO obviously thinks that he has found a counter example to Linz's
> impossible H.

I find this hard to believe but I accept that there are minds out there
that I have little understanding of. Even so, how can anyone think they
have a decider M that is correct about <[M^],[M^]> if

a. M rejects <[M^],[M^]>, but
b. M^([M^]) halts?

It seems impossible to me that anyone can accept these facts and claim
to have "a counter example" to the proof's hat construction. Surely
even PO can see that such a TM is not correct? It think he know.
That's why he was, briefly, honest about redefining what "halting"
means. It was only after he realised that everyone would ignore him if
he was talking about some other notion of "halting" that he stopped
being clear about this redefinition.

Further, PO recently posted this:

| Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
| if M applied to wM halts, and
| | Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
| if M applied to wM does not halt

which is (roughly) Linz's notation for what H^, built from a correct H,
should do. I showed the last tiny step which is to set wM = <Ĥ> (so M
is Ĥ) to get

Ĥ.q0 <Ĥ> ⊢* Ĥ.qx <Ĥ> <Ĥ> ⊢* Ĥ.qy ⊢* ∞
if Ĥ applied to <Ĥ> halts, and

Ĥ.q0 <Ĥ> ⊢* Ĥ.qx <Ĥ> <Ĥ> ⊢* Ĥ.qn
if Ĥ applied to <Ĥ> does not halt

which, in words is, "Ĥ run (from state q0) on input <Ĥ> does not halt if
Ĥ applied to <Ĥ> halts", and "Ĥ run (from state q0) on input <Ĥ> halts
(in state qn) if Ĥ applied to <Ĥ> does not halt".

In reply, PO said he understood that, but then went on to say more
things as if anything, true or false, can alter the fact that the
assumption about H leads to a contradiction. Do you think he genuinely
believes that saying more things, even true things, can "undo" a
contradiction? That is a strange mind indeed.

--
Ben.

On 6/23/2021 11:00 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 23 June 2021 at 11:57:06 UTC+1, Richard Damon wrote:
>>> On 6/22/21 11:21 PM, olcott wrote:
>>>> On 6/22/2021 10:00 PM, Richard Damon wrote:
>>>>>
>>>>>> Yes and of course when I make a C program that is computationally
>>>>>> equivalent to the standard relation between the HP halt decider and its
>>>>>> impossible input and show all of the steps of how this halt decider
>>>>>> correctly decides this "known" to be impossible input that does not
>>>>>> count at all because it is not 100% perfectly an actual TM.
>>>>>
>>>>> Except that it isn't because H^ doesn't make copies as it is supposed to
>>>>> so you don't end up with a true equivalent.
>>>>
>>>> Others know that it is sufficiently equivalent.
>>> There is no 'sufficiently' it only is or it isn't.
>>>
>>> Is 2.0001 sufficiently equivalent to 2? Its pretty close, but is it
>>> equivalent.
>>>
>> PO's system uses x86 code instead of Turing machines. That enables him
>> to detect when the halt decider is being called on a program including itself.
>> That's not the root of the error (the halting problem also applies to x86
>> programs) but it is the root of the confusion.
>> PO obviously thinks that he has found a counter example to Linz's
>> impossible H.
>
> I find this hard to believe but I accept that there are minds out there
> that I have little understanding of. Even so, how can anyone think they
> have a decider M that is correct about <[M^],[M^]> if
>
> a. M rejects <[M^],[M^]>, but
> b. M^([M^]) halts?
>

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

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

Premise(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.

Premise(2) The simulation of the input to H(P,P) never halts without
being aborted is a verified fact on the basis of its x86 execution
trace. (shown below).

Conclusion (3) From the above true premises it necessarily follows that
simulating halt decider H correctly reports that its input: (P,P) never
halts.

When (1) is true and (2) is true and (1) & (2) logically entails that
(3) is true, nothing can possibly contradict that (3) is true.

Make sure you carefully ignore all those words because that is the only
way that any fake ruse of a rebuttal can continue.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> It seems impossible to me that anyone can accept these facts and claim
> to have "a counter example" to the proof's hat construction. Surely
> even PO can see that such a TM is not correct? It think he know.
> That's why he was, briefly, honest about redefining what "halting"
> means. It was only after he realised that everyone would ignore him if
> he was talking about some other notion of "halting" that he stopped
> being clear about this redefinition.
>
> Further, PO recently posted this:
>
> | Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> | if M applied to wM halts, and
> |
> | Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> | if M applied to wM does not halt
>
> which is (roughly) Linz's notation for what H^, built from a correct H,
> should do. I showed the last tiny step which is to set wM = <Ĥ> (so M
> is Ĥ) to get
>
> Ĥ.q0 <Ĥ> ⊢* Ĥ.qx <Ĥ> <Ĥ> ⊢* Ĥ.qy ⊢* ∞
> if Ĥ applied to <Ĥ> halts, and
>
> Ĥ.q0 <Ĥ> ⊢* Ĥ.qx <Ĥ> <Ĥ> ⊢* Ĥ.qn
> if Ĥ applied to <Ĥ> does not halt
>
> which, in words is, "Ĥ run (from state q0) on input <Ĥ> does not halt if
> Ĥ applied to <Ĥ> halts", and "Ĥ run (from state q0) on input <Ĥ> halts
> (in state qn) if Ĥ applied to <Ĥ> does not halt".
>
> In reply, PO said he understood that, but then went on to say more
> things as if anything, true or false, can alter the fact that the
> assumption about H leads to a contradiction. Do you think he genuinely
> believes that saying more things, even true things, can "undo" a
> contradiction? That is a strange mind indeed.
>

--
Copyright 2021 Pete Olcott

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

On 2021-06-22 13:17, olcott wrote:
> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>> On 2021-06-22 11:05, olcott wrote:
>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:

<snip>

> In the case of the simulation of P it is verified on the basis of the
> x86 execution trace of B, thus an established verified fact.

Except that an execution trace doesn't 'verify' anything. No one doubts
that your program decides that P(P) == 0. But unless the logic
underlying your program is actually correct, this result tells us
nothing. And you haven't provided any sort of proof that the logic
underlying your program is actually correct.

And it isn't correct. Most significantly, your trace skips over certain
portions of the P being simulated which completely invalidates its results.

<snip>

>>>> Option C never said anything about why it aborts the simulation.
>>>
>>> That is its horribly terrible error. To simply ignore the key most
>>> important halt deciding criteria is a terribly awful mistake.
>>
>> Clearly you have reading comprehension problems. The halting status of
>> the *simulator* has nothing to do with the halting status of its input
>> computation if the simulator is capable of aborting the simulation of
>> that input. That applies equally to your (C) and your (D). In either
>> case, the simulator can halt.
>>
>
> An intentional fallacy of equivocation error that very persistently
> tries to hide the correct halt deciding criteria.
>
> Key to refuting all the conventional HP undecidability proofs
>
> -- H MUST stop its simulation of P or P never halts

I'm not hiding anything. Whether the halt deciding criterion is correct
or not has no bearing on my claim, which is that once a simulation is
aborted the simulator can still halt. That's true of a simulator using a
'correct' criterion just as much as its true of one which simply aborts
its simulation at random.

André

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

On 6/23/2021 12:29 PM, André G. Isaak wrote:
> On 2021-06-22 13:17, olcott wrote:
>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>> On 2021-06-22 11:05, olcott wrote:
>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>
> <snip>
>
>> In the case of the simulation of P it is verified on the basis of the
>> x86 execution trace of B, thus an established verified fact.
>
> Except that an execution trace doesn't 'verify' anything. No one doubts
> that your program decides that P(P) == 0. But unless the logic
> underlying your program is actually correct, this result tells us
> nothing. And you haven't provided any sort of proof that the logic
> underlying your program is actually correct.
>

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

Sure I have. When we look as page 3 and 4 of the above paper it is very
easy to see that H does faithfully simulate the execution of P and that
P has no escape from infinite execution in its own code.

Premise(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.

Premise(2) The simulation of the input to H(P,P) never halts without
being aborted is a verified fact on the basis of its x86 execution
trace. (shown below).

Conclusion(3) From the above true premises it necessarily follows that
simulating halt decider H correctly reports that its input: (P,P) never
halts.

Only by very diligently making sure to not pay attention is it possible
to maintain the ruse of a fake rebuttal.

> And it isn't correct. Most significantly, your trace skips over certain
> portions of the P being simulated which completely invalidates its results.
>

The question is:

Does the simulation of P have to be aborted to prevent its infinite
execution?

As long as the answer to this question is [YES] then Premise(2) is
perfectly satisfied and your objection is utterly pointless.

As long as the answer to this question is [YES] then Premise(2) is
perfectly satisfied and your objection is utterly pointless.

As long as the answer to this question is [YES] then Premise(2) is
perfectly satisfied and your objection is utterly pointless.

As long as the answer to this question is [YES] then Premise(2) is
perfectly satisfied and your objection is utterly pointless.

> <snip>
>
>>>>> Option C never said anything about why it aborts the simulation.
>>>>
>>>> That is its horribly terrible error. To simply ignore the key most
>>>> important halt deciding criteria is a terribly awful mistake.
>>>
>>> Clearly you have reading comprehension problems. The halting status
>>> of the *simulator* has nothing to do with the halting status of its
>>> input computation if the simulator is capable of aborting the
>>> simulation of that input. That applies equally to your (C) and your
>>> (D). In either case, the simulator can halt.
>>>
>>
>> An intentional fallacy of equivocation error that very persistently
>> tries to hide the correct halt deciding criteria.
>>
>> Key to refuting all the conventional HP undecidability proofs
>>
>> -- H MUST stop its simulation of P or P never halts
>
> I'm not hiding anything. Whether the halt deciding criterion is correct
> or not has no bearing on my claim, which is that once a simulation is
> aborted the simulator can still halt. That's true of a simulator using a
> 'correct' criterion just as much as its true of one which simply aborts
> its simulation at random.
>
> André
>
>

--
Copyright 2021 Pete Olcott

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

bug report:
the fly just now flew into my mouth
i captured the body between my thumb and right forefinger
the body of evidence is in a secure container that
may be stored for a finite time period
hubble on youtube is great
you have all done well
the universe is large
some reasoning seems
very very stupid

--
Soap upon Ocean Snows upon Mountains ( cool hypothesis )
abcdefghijklmnopqrstuvw yz0
gods favorite number is three
gods favorite symbol is +
square of reason
11111110
11111101
11111011
11110111
11101111
11011111
10111111
01111111

On 2021-06-23 14:07, olcott wrote:
> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>> On 2021-06-22 13:17, olcott wrote:
>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>> On 2021-06-22 11:05, olcott wrote:
>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>
>> <snip>
>>
>>> In the case of the simulation of P it is verified on the basis of the
>>> x86 execution trace of B, thus an established verified fact.
>>
>> Except that an execution trace doesn't 'verify' anything. No one
>> doubts that your program decides that P(P) == 0. But unless the logic
>> underlying your program is actually correct, this result tells us
>> nothing. And you haven't provided any sort of proof that the logic
>> underlying your program is actually correct.
>>
>
> Halting problem undecidability and infinitely nested simulation
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> Sure I have. When we look as page 3 and 4 of the above paper it is very
> easy to see that H does faithfully simulate the execution of P and that
> P has no escape from infinite execution in its own code.

No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
simulating P(P), then P(P) can't call the main H -- it can only invoke a
copy of H *within the simulation*.

Second, even if we ignore the above, the decision criterion you use is
flawed because it completely ignores all conditional branches contained
within P's copy of H, and it's these conditional branches which prevent
P(P) from being an 'infinitely recursive' computation.

Once again, traces do not constitute proofs. If you want to be taken
seriously, you need to provide some actual *proof* that your algorithm
works.

> Premise(1) Every computation that never halts unless its simulation is
> aborted is a computation that never halts. This verified as true on the
> basis of the meaning of its words.
>
> Premise(2) The simulation of the input to H(P,P) never halts without
> being aborted is a verified fact on the basis of its x86 execution
> trace. (shown below).
>
> Conclusion(3) From the above true premises it necessarily follows that
> simulating halt decider H correctly reports that its input: (P,P) never
> halts.
>
> Only by very diligently making sure to not pay attention is it possible
> to maintain the ruse of a fake rebuttal.
>
>> And it isn't correct. Most significantly, your trace skips over
>> certain portions of the P being simulated which completely invalidates
>> its results.
>>
>
> The question is:
>
> Does the simulation of P have to be aborted to prevent its infinite
> execution?
>
> As long as the answer to this question is [YES] then Premise(2) is
> perfectly satisfied and your objection is utterly pointless.

You should cut it out with the asinine repetition.It just makes you look
like a three-year old.

And no, the objection is *not* pointless. You can't claim that there is
"no escape from infinite execution" when you ignore the conditional
statements which would allow P(P) to abort the simulation it is
conducting. Those are the conditional branches which provide that escape.

André

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

On 6/23/2021 6:13 PM, André G. Isaak wrote:
> On 2021-06-23 14:07, olcott wrote:
>> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>>> On 2021-06-22 13:17, olcott wrote:
>>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>>> On 2021-06-22 11:05, olcott wrote:
>>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>>
>>> <snip>
>>>
>>>> In the case of the simulation of P it is verified on the basis of
>>>> the x86 execution trace of B, thus an established verified fact.
>>>
>>> Except that an execution trace doesn't 'verify' anything. No one
>>> doubts that your program decides that P(P) == 0. But unless the logic
>>> underlying your program is actually correct, this result tells us
>>> nothing. And you haven't provided any sort of proof that the logic
>>> underlying your program is actually correct.
>>>
>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> Sure I have. When we look as page 3 and 4 of the above paper it is
>> very easy to see that H does faithfully simulate the execution of P
>> and that P has no escape from infinite execution in its own code.
>
> No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
> simulating P(P), then P(P) can't call the main H -- it can only invoke a
> copy of H *within the simulation*.
>

It is actually and quite factually not a copy.
I have had to say this hundreds of times now.

It is the same freaking machine language at the
same freaking machine language address.

> Second, even if we ignore the above, the decision criterion you use is
> flawed because it completely ignores all conditional branches contained
> within P's copy of H, and it's these conditional branches which prevent
> P(P) from being an 'infinitely recursive' computation.
>

Unless we keep the independent variable separate from the dependent
variable our analysis is incorrect.

The independent variable is the cause. Its value is independent of other
variables in your study.

The dependent variable is the effect. Its value depends on changes in
the independent variable.

https://www.scribbr.com/methodology/independent-and-dependent-variables/

When we are asking whether or not H must abort its simulation of P we
examine the simulation of P. We must not examine the behavior of H.

> Once again, traces do not constitute proofs. If you want to be taken
> seriously, you need to provide some actual *proof* that your algorithm
> works.

That my proof does not conform to academic conventions does not show
that it is not a proof. As long as I start with a set of premises that
can be verified as true and my conclusion logically follows from these
true premises then I definitely have a proof even if everyone in the
universe disagrees.

>> Premise(1) Every computation that never halts unless its simulation is
>> aborted is a computation that never halts. This verified as true on
>> the basis of the meaning of its words.
>>
>> Premise(2) The simulation of the input to H(P,P) never halts without
>> being aborted is a verified fact on the basis of its x86 execution
>> trace. (shown below).
>>
>> Conclusion(3) From the above true premises it necessarily follows that
>> simulating halt decider H correctly reports that its input: (P,P)
>> never halts.
>>
>> Only by very diligently making sure to not pay attention is it
>> possible to maintain the ruse of a fake rebuttal.
>>
>>> And it isn't correct. Most significantly, your trace skips over
>>> certain portions of the P being simulated which completely
>>> invalidates its results.
>>>
>>
>> The question is:
>>
>> Does the simulation of P have to be aborted to prevent its infinite
>> execution?
>>
>> As long as the answer to this question is [YES] then Premise(2) is
>> perfectly satisfied and your objection is utterly pointless.
>
> You should cut it out with the asinine repetition.It just makes you look
> like a three-year old.
>

If I don't get ridiculous with the repetition in a single reply then I
need twenty replies to make the same point because this point is
perpetually ignored. I usually don't repeat the same sentence five times
until after a key point has been ignored in several replies.

> And no, the objection is *not* pointless. You can't claim that there is
> "no escape from infinite execution" when you ignore the conditional
> statements which would allow P(P) to abort the simulation it is
> conducting. Those are the conditional branches which provide that escape.
>
> André
>

The question is whether or not H must abort its simulation of P.
The behavior of H is totally irrelevant to this question.

Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P

We ask what is the effect on the behavior of P? (dependent variable)

(1) P halts
(2) P never halts

The above answer applies to every possible encoding of any simulating
halt decoder H when applied to P or any computational equivalent to P
such as the Linz ⟨Ĥ⟩.

--
Copyright 2021 Pete Olcott

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

On 2021-06-23 18:01, olcott wrote:
> On 6/23/2021 6:13 PM, André G. Isaak wrote:
>> On 2021-06-23 14:07, olcott wrote:
>>> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>>>> On 2021-06-22 13:17, olcott wrote:
>>>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>>>> On 2021-06-22 11:05, olcott wrote:
>>>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>>>
>>>> <snip>
>>>>
>>>>> In the case of the simulation of P it is verified on the basis of
>>>>> the x86 execution trace of B, thus an established verified fact.
>>>>
>>>> Except that an execution trace doesn't 'verify' anything. No one
>>>> doubts that your program decides that P(P) == 0. But unless the
>>>> logic underlying your program is actually correct, this result tells
>>>> us nothing. And you haven't provided any sort of proof that the
>>>> logic underlying your program is actually correct.
>>>>
>>>
>>> Halting problem undecidability and infinitely nested simulation
>>>
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>> Sure I have. When we look as page 3 and 4 of the above paper it is
>>> very easy to see that H does faithfully simulate the execution of P
>>> and that P has no escape from infinite execution in its own code.
>>
>> No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
>> simulating P(P), then P(P) can't call the main H -- it can only invoke
>> a copy of H *within the simulation*.
>>
>
> It is actually and quite factually not a copy.
> I have had to say this hundreds of times now.

But if it isn't a copy, then your P isn't derived from your H in the
manner prescribed by the Linz proof. If you want to claim to have
provided a 'counterexample' to the 'standard proofs' then you need to
actually construct your P in the same manner that H_Hat is constructed
in those proofs.

> It is the same freaking machine language at the
> same freaking machine language address.

If P is calling H directly, then in what sense is P being 'simulated'?

>> Second, even if we ignore the above, the decision criterion you use is
>> flawed because it completely ignores all conditional branches
>> contained within P's copy of H, and it's these conditional branches
>> which prevent P(P) from being an 'infinitely recursive' computation.
>>
>
> Unless we keep the independent variable separate from the dependent
> variable our analysis is incorrect.
>
> The independent variable is the cause. Its value is independent of other
> variables in your study.
>
> The dependent variable is the effect. Its value depends on changes in
> the independent variable.
>
> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>
> When we are asking whether or not H must abort its simulation of P we
> examine the simulation of P. We must not examine the behavior of H.

This is simply wrong. You can ignore the code in the *decider*, but not
code inside the computation which the decider is simulating. The call to
H inside P is an integral part of the computation performed by P. You
can't ignore this anymore than you can ignore any other instructions
inside P.

André

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

On 6/23/21 8:01 PM, olcott wrote:
> On 6/23/2021 6:13 PM, André G. Isaak wrote:
>> On 2021-06-23 14:07, olcott wrote:
>>> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>>>> On 2021-06-22 13:17, olcott wrote:
>>>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>>>> On 2021-06-22 11:05, olcott wrote:
>>>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>>>
>>>> <snip>
>>>>
>>>>> In the case of the simulation of P it is verified on the basis of
>>>>> the x86 execution trace of B, thus an established verified fact.
>>>>
>>>> Except that an execution trace doesn't 'verify' anything. No one
>>>> doubts that your program decides that P(P) == 0. But unless the
>>>> logic underlying your program is actually correct, this result tells
>>>> us nothing. And you haven't provided any sort of proof that the
>>>> logic underlying your program is actually correct.
>>>>
>>>
>>> Halting problem undecidability and infinitely nested simulation
>>>
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>> Sure I have. When we look as page 3 and 4 of the above paper it is
>>> very easy to see that H does faithfully simulate the execution of P
>>> and that P has no escape from infinite execution in its own code.
>>
>> No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
>> simulating P(P), then P(P) can't call the main H -- it can only invoke
>> a copy of H *within the simulation*.
>>
>
> It is actually and quite factually not a copy.
> I have had to say this hundreds of times now.

It has to be a copy, as H^ isn't the machine H it needs to use a copy.
That is just how Turing Machines work. Turing Machine P has EVERYTHING
it needs as its algorithm in its own code, and EVERYTHING in will use as
its input on its Tape. That code and Tape is distinct from every other
code and tape in the mathematical universe (but their can be copies).
>
> It is the same freaking machine language at the
> same freaking machine language address.

But Linz didn't write his Theorem of x86 assembly language, he wrote it
for Turing Machines.

>
>> Second, even if we ignore the above, the decision criterion you use is
>> flawed because it completely ignores all conditional branches
>> contained within P's copy of H, and it's these conditional branches
>> which prevent P(P) from being an 'infinitely recursive' computation.
>>
>
> Unless we keep the independent variable separate from the dependent
> variable our analysis is incorrect.
>
> The independent variable is the cause. Its value is independent of other
> variables in your study.
>
> The dependent variable is the effect. Its value depends on changes in
> the independent variable.

So the independent variable is H. H is the CAUSE of all the behavior (P
is formed by a fixed algorithm form H). The dependent variable is the
halting behavior of P.

Looking at each possible H, we can see what it does to the P that is
built on it, and what that P actually does, and in EVERY case we find
that H is wrong.

>
> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>
> When we are asking whether or not H must abort its simulation of P we
> examine the simulation of P. We must not examine the behavior of H.

>
>> Once again, traces do not constitute proofs. If you want to be taken
>> seriously, you need to provide some actual *proof* that your algorithm
>> works.
>
> That my proof does not conform to academic conventions does not show
> that it is not a proof. As long as I start with a set of premises that
> can be verified as true and my conclusion logically follows from these
> true premises then I definitely have a proof even if everyone in the
> universe disagrees.
>

It doesn't conform to logical validity.

Yes, start with a set of premisis that are verified to be true, and then
use them within the bounds of their meaning.

Your Premise (1) has validity under one set of definitions of its term,
that is true, but you don't use it with those definitiosn, thus you
don't start with valid premises.

The key fact is that 'its simulation' refers to the specific instance of
the simulation we are looking at, and the need test can be done by
changing JUST THAT INSTANCE, and not other 'copies' of it running in
other instances.

Premise(2) attempts to validate Premise(1) but uses a DIFFERENT meaning
of the words, for which Premise(1) is not true under.

Thus, your logic has failed, and can with the audacity that you do it,
could even be called deciteful.

>>> Premise(1) Every computation that never halts unless its simulation
>>> is aborted is a computation that never halts. This verified as true
>>> on the basis of the meaning of its words.
>>>
>>> Premise(2) The simulation of the input to H(P,P) never halts without
>>> being aborted is a verified fact on the basis of its x86 execution
>>> trace. (shown below).
>>>
>>> Conclusion(3) From the above true premises it necessarily follows
>>> that simulating halt decider H correctly reports that its input:
>>> (P,P) never halts.
>>>
>>> Only by very diligently making sure to not pay attention is it
>>> possible to maintain the ruse of a fake rebuttal.
>>>
>>>> And it isn't correct. Most significantly, your trace skips over
>>>> certain portions of the P being simulated which completely
>>>> invalidates its results.
>>>>
>>>
>>> The question is:
>>>
>>> Does the simulation of P have to be aborted to prevent its infinite
>>> execution?
>>>
>>> As long as the answer to this question is [YES] then Premise(2) is
>>> perfectly satisfied and your objection is utterly pointless.
>>
>> You should cut it out with the asinine repetition.It just makes you
>> look like a three-year old.
>>
>
> If I don't get ridiculous with the repetition in a single reply then I
> need twenty replies to make the same point because this point is
> perpetually ignored. I usually don't repeat the same sentence five times
> until after a key point has been ignored in several replies.
>

Maybe you shouldn't ignore the points that others are making. The fact
is that you keep on insisting on things that just are not true, and for
which you don't even try to present a justification for but just keep
claiming that they are obviously true, when they aren't.

If the actually ARE obviously true, then you should be able to actually
prove this, but you don't even try. Your don't even look at the
rebuttals and even try to point out logica errors in them.

>> And no, the objection is *not* pointless. You can't claim that there
>> is "no escape from infinite execution" when you ignore the conditional
>> statements which would allow P(P) to abort the simulation it is
>> conducting. Those are the conditional branches which provide that escape.
>>
>> André
>>
>
> The question is whether or not H must abort its simulation of P.
> The behavior of H is totally irrelevant to this question.

NO. That is a root of your problem. The Question is does P halt when
given input I. THAT is the question, and the P that we look at is
dependent on your definition of H.

The question of does H need to abort P may be a useful question for
developing the algorithm of H, but it isn't the ultimate question that H
is supposed to be answering. It is just a step in the path to the answer.

>
> Of the two hypothetical possibilities: (independent variable)
> (1) H aborts the simulation of P
> (2) H never aborts the simulation of P
>
> We ask what is the effect on the behavior of P? (dependent variable)
>
> (1) P halts
> (2) P never halts
>
> The above answer applies to every possible encoding of any simulating
> halt decoder H when applied to P or any computational equivalent to P
> such as the Linz ⟨Ĥ⟩.
>

But remember, the behavior of P is the DEPENDENT variable, each answer
corresponds to a given H.

Yes, if H doesn't abort it's P, then that P is non-halting, but that H
doesn't answer either so it fails to be a decider.

Change the independent variable, and you get a DIFFFERNT P, so you can't
just assume the same result.

On 6/23/21 11:33 AM, olcott wrote:
> On 6/23/2021 7:25 AM, Malcolm McLean wrote:
>> On Wednesday, 23 June 2021 at 11:57:06 UTC+1, Richard Damon wrote:
>>> On 6/22/21 11:21 PM, olcott wrote:
>>>> On 6/22/2021 10:00 PM, Richard Damon wrote:
>>>>>
>>>>>> Yes and of course when I make a C program that is computationally
>>>>>> equivalent to the standard relation between the HP halt decider
>>>>>> and its
>>>>>> impossible input and show all of the steps of how this halt decider
>>>>>> correctly decides this "known" to be impossible input that does not
>>>>>> count at all because it is not 100% perfectly an actual TM.
>>>>>
>>>>> Except that it isn't because H^ doesn't make copies as it is
>>>>> supposed to
>>>>> so you don't end up with a true equivalent.
>>>>
>>>> Others know that it is sufficiently equivalent.
>>> There is no 'sufficiently' it only is or it isn't.
>>>
>>> Is 2.0001 sufficiently equivalent to 2? Its pretty close, but is it
>>> equivalent.
>>>
>> PO's system uses x86 code instead of Turing machines. That enables him
>> to detect when the halt decider is being called on a program including
>> itself.
>> That's not the root of the error (the halting problem also applies to x86
>> programs) but it is the root of the confusion.
>> PO obviously thinks that he has found a counter example to Linz's
>> impossible H.
>> Othewise he would be so insistent be so insistent about it. I suggest
>> that this
>> is because he's tied himself up in knots thinking about infinite
>> recursion
>> and what would have happened had his H been a pure simulator instead of
>> a simulator with an infinite recursion detector attached.
>>
> Which of these seems to be untrue and why?
>
> Premise(1) Every computation that never halts unless its simulation is
> aborted is a computation that never halts. This verified as true on the
> basis of the meaning of its words.

This is true when the 'halting' refers to the action of the specific
instance of the simulatior simulation the given computation, but not
other copies simulating other copies of the simulation.

>
> Premise(2) The simulation of the input to H(P,P) never halts without
> being aborted is a verified fact on the basis of its x86 execution
> trace. (shown below).

This shows that SOME copy of the simulator needs to abort SOME copy of
the computation, not any particular one. This is a different condition
with just similar words.

>
> From the above true premises it necessarily follows that
> simulating halt decider H correctly reports that its input: (P,P) never
> halts.

The two statements do NOT refer to the same 'property' of the machine,
so (2) does not establish the conditions of (1), thus it is an unsound
piece of logic.

>
> Halting problem undecidability and infinitely nested simulation
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>

On 6/23/21 8:25 AM, Malcolm McLean wrote:
> On Wednesday, 23 June 2021 at 11:57:06 UTC+1, Richard Damon wrote:
>> On 6/22/21 11:21 PM, olcott wrote:
>>> On 6/22/2021 10:00 PM, Richard Damon wrote:
>>>>
>>>>> Yes and of course when I make a C program that is computationally
>>>>> equivalent to the standard relation between the HP halt decider and its
>>>>> impossible input and show all of the steps of how this halt decider
>>>>> correctly decides this "known" to be impossible input that does not
>>>>> count at all because it is not 100% perfectly an actual TM.
>>>>
>>>> Except that it isn't because H^ doesn't make copies as it is supposed to
>>>> so you don't end up with a true equivalent.
>>>
>>> Others know that it is sufficiently equivalent.
>> There is no 'sufficiently' it only is or it isn't.
>>
>> Is 2.0001 sufficiently equivalent to 2? Its pretty close, but is it
>> equivalent.
>>
> PO's system uses x86 code instead of Turing machines. That enables him
> to detect when the halt decider is being called on a program including itself.
> That's not the root of the error (the halting problem also applies to x86
> programs) but it is the root of the confusion.
> PO obviously thinks that he has found a counter example to Linz's impossible H.
> Othewise he would be so insistent be so insistent about it. I suggest that this
> is because he's tied himself up in knots thinking about infinite recursion
> and what would have happened had his H been a pure simulator instead of
> a simulator with an infinite recursion detector attached.
>

Yes, there can be a version of the Halting Problem expressed for x86
code instead of Turing Machines. One fundamental problem is that since
x86 machines tend to have fixed finite memory, it is actually possible
to decide such a machine in finite time with another finite (but much
bigger) machine.

This means that to make a REAL equivalent of the Halting Problem you
need to be careful how you define everything so that this simple dodge
doesn't work. I suspect that by the time you do get it worded properly,
Peter's tricks become more obviously against the rules/definitions. My
guess is you need to be more explicit about how answer MUST be returned,
so his claims of not returing answers to parts of the infinite chain is
clearly not allowed.

He gets a lot of his tricks becuase the wording is based on Turing
Machines, and a lot of behavior of Turing Machines is just fixed by
their construction, and PO is just igoring that they have fundmantal
rules for how they behave.

Notice how when asked what a given behavior (like aborting the whole
chain) means to an actual Turing Machine version, and he just can't
answer, because the behavior just doesn't make sense for a Turing Machine.

On 6/23/2021 7:49 PM, André G. Isaak wrote:
> On 2021-06-23 18:01, olcott wrote:
>> On 6/23/2021 6:13 PM, André G. Isaak wrote:
>>> On 2021-06-23 14:07, olcott wrote:
>>>> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>>>>> On 2021-06-22 13:17, olcott wrote:
>>>>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>>>>> On 2021-06-22 11:05, olcott wrote:
>>>>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>> In the case of the simulation of P it is verified on the basis of
>>>>>> the x86 execution trace of B, thus an established verified fact.
>>>>>
>>>>> Except that an execution trace doesn't 'verify' anything. No one
>>>>> doubts that your program decides that P(P) == 0. But unless the
>>>>> logic underlying your program is actually correct, this result
>>>>> tells us nothing. And you haven't provided any sort of proof that
>>>>> the logic underlying your program is actually correct.
>>>>>
>>>>
>>>> Halting problem undecidability and infinitely nested simulation
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>> Sure I have. When we look as page 3 and 4 of the above paper it is
>>>> very easy to see that H does faithfully simulate the execution of P
>>>> and that P has no escape from infinite execution in its own code.
>>>
>>> No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
>>> simulating P(P), then P(P) can't call the main H -- it can only
>>> invoke a copy of H *within the simulation*.
>>>
>>
>> It is actually and quite factually not a copy.
>> I have had to say this hundreds of times now.
>
> But if it isn't a copy, then your P isn't derived from your H in the
> manner prescribed by the Linz proof. If you want to claim to have
> provided a 'counterexample' to the 'standard proofs' then you need to
> actually construct your P in the same manner that H_Hat is constructed
> in those proofs.
>
>> It is the same freaking machine language at the
>> same freaking machine language address.
>
> If P is calling H directly, then in what sense is P being 'simulated'?
>
>>> Second, even if we ignore the above, the decision criterion you use
>>> is flawed because it completely ignores all conditional branches
>>> contained within P's copy of H, and it's these conditional branches
>>> which prevent P(P) from being an 'infinitely recursive' computation.
>>>
>>
>> Unless we keep the independent variable separate from the dependent
>> variable our analysis is incorrect.
>>
>> The independent variable is the cause. Its value is independent of
>> other variables in your study.
>>
>> The dependent variable is the effect. Its value depends on changes in
>> the independent variable.
>>
>> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>>
>> When we are asking whether or not H must abort its simulation of P we
>> examine the simulation of P. We must not examine the behavior of H.
>
> This is simply wrong. You can ignore the code in the *decider*, but not
> code inside the computation which the decider is simulating. The call to
> H inside P is an integral part of the computation performed by P. You
> can't ignore this anymore than you can ignore any other instructions
> inside P.
>
> André
>

The independent variable is the cause. Its value is independent of other
variables in your study.

The dependent variable is the effect. Its value depends on changes in
the independent variable.

https://www.scribbr.com/methodology/independent-and-dependent-variables/

The question is whether or not H must abort its simulation of P.
The behavior of H is totally irrelevant to this question.

As I have proven below.
As I have proven below.
As I have proven below.
As I have proven below.

Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P

We ask what is the effect on the behavior of P? (dependent variable)

(1) P halts
(2) P never halts

It does not freaking matter at all what-ever-the-Hell H does except what
the behavior of P is under the above two hypothetical scenarios.

If the result of purely hypothetical H that never aborts its
simulation/execution of P would result in the infinite execution of P
then we know axiomatically that H decides that P never halts correctly.

Premise(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.

--
Copyright 2021 Pete Olcott

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

On Wednesday, 23 June 2021 at 17:00:57 UTC+1, Ben Bacarisse wrote:
>
> In reply, PO said he understood that, but then went on to say more
> things as if anything, true or false, can alter the fact that the
> assumption about H leads to a contradiction. Do you think he genuinely
> believes that saying more things, even true things, can "undo" a
> contradiction? That is a strange mind indeed.
>
We've had quite a bit of flip-flopping. We had a period when it was
acknowledged that Linz's proof was sound but he had a slightly
different property. Defining a slightly different property to halting
is not an inherently bad thing to do, it could be the starting point
of some significant work. But that's very hard to do, and you and I
pointed out that PO's different problem wasn't one of the "interesting"
ones. You needed to solve the original halting problem first to decide
it, for example.

So there might have been a row back from that when he realised that
the response would be "well that might be true but it doesn't get us
anywhere".

However I do think that he genuinely thinks that he's got something
significant. I'm not a mind reader, but a troll would have got bored by
now, whilst the posts go off at too many tangents to be a fraudster.
When you dry run his simulating halt decider on itself, it is confusing.
Take out the halt detector and it runs forever. Put the halt detector in,
and it detects non-halting behaviour (according to PO, no real reason
to disbelieve him). So surely it's got that right? But in fact simulate
one more step, and the halt detection in the simulated machine will
kick in and halt it.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 23 June 2021 at 17:00:57 UTC+1, Ben Bacarisse wrote:
>>
>> In reply, PO said he understood that, but then went on to say more
>> things as if anything, true or false, can alter the fact that the
>> assumption about H leads to a contradiction. Do you think he genuinely
>> believes that saying more things, even true things, can "undo" a
>> contradiction? That is a strange mind indeed.
>>
> We've had quite a bit of flip-flopping. We had a period when it was
> acknowledged that Linz's proof was sound but he had a slightly
> different property. Defining a slightly different property to halting
> is not an inherently bad thing to do, it could be the starting point
> of some significant work. But that's very hard to do, and you and I
> pointed out that PO's different problem wasn't one of the "interesting"
> ones. You needed to solve the original halting problem first to decide
> it, for example.
>
> So there might have been a row back from that when he realised that
> the response would be "well that might be true but it doesn't get us
> anywhere".
>
> However I do think that he genuinely thinks that he's got something
> significant. I'm not a mind reader, but a troll would have got bored by
> now, whilst the posts go off at too many tangents to be a fraudster.

I don't think he's a troll, and I don't think he's a fraudster, but the
changes in his claims suggest to me that he is aware of being wrong and
having to row-back the wildest ones. He certainly knows, but has not
admitted, that he never had "two actual Turing machines" "fully encoded"
back in Dec 2018, waiting only for a TM simulator to be able to run them
(he claimed that would take about a week). I don't think these
deceptions are fraudulent. I think his self-image can't cope with the
concept of being wrong.

> When you dry run his simulating halt decider on itself, it is confusing.
> Take out the halt detector and it runs forever. Put the halt detector in,
> and it detects non-halting behaviour (according to PO, no real reason
> to disbelieve him). So surely it's got that right?

I don't know what you mean. How do you run anything of his? We've
never even seen the key function.

> But in fact simulate
> one more step, and the halt detection in the simulated machine will
> kick in and halt it.

I don't see the value in discussing all these details, though others
clearly do. He's stated in various round-about ways that his "decider"
(the hidden code we will never see) is wrong as far as "conventional"
halting is concerned. There is zero dispute on the facts that the code
indicates false for a halting computation.

--
Ben.

On 6/23/21 11:03 PM, olcott wrote:
> On 6/23/2021 7:49 PM, André G. Isaak wrote:
>> On 2021-06-23 18:01, olcott wrote:
>>> On 6/23/2021 6:13 PM, André G. Isaak wrote:
>>>> On 2021-06-23 14:07, olcott wrote:
>>>>> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>>>>>> On 2021-06-22 13:17, olcott wrote:
>>>>>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>>>>>> On 2021-06-22 11:05, olcott wrote:
>>>>>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>> In the case of the simulation of P it is verified on the basis of
>>>>>>> the x86 execution trace of B, thus an established verified fact.
>>>>>>
>>>>>> Except that an execution trace doesn't 'verify' anything. No one
>>>>>> doubts that your program decides that P(P) == 0. But unless the
>>>>>> logic underlying your program is actually correct, this result
>>>>>> tells us nothing. And you haven't provided any sort of proof that
>>>>>> the logic underlying your program is actually correct.
>>>>>>
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>
>>>>>
>>>>> Sure I have. When we look as page 3 and 4 of the above paper it is
>>>>> very easy to see that H does faithfully simulate the execution of P
>>>>> and that P has no escape from infinite execution in its own code.
>>>>
>>>> No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
>>>> simulating P(P), then P(P) can't call the main H -- it can only
>>>> invoke a copy of H *within the simulation*.
>>>>
>>>
>>> It is actually and quite factually not a copy.
>>> I have had to say this hundreds of times now.
>>
>> But if it isn't a copy, then your P isn't derived from your H in the
>> manner prescribed by the Linz proof. If you want to claim to have
>> provided a 'counterexample' to the 'standard proofs' then you need to
>> actually construct your P in the same manner that H_Hat is constructed
>> in those proofs.
>>
>>> It is the same freaking machine language at the
>>> same freaking machine language address.
>>
>> If P is calling H directly, then in what sense is P being 'simulated'?
>>
>>>> Second, even if we ignore the above, the decision criterion you use
>>>> is flawed because it completely ignores all conditional branches
>>>> contained within P's copy of H, and it's these conditional branches
>>>> which prevent P(P) from being an 'infinitely recursive' computation.
>>>>
>>>
>>> Unless we keep the independent variable separate from the dependent
>>> variable our analysis is incorrect.
>>>
>>> The independent variable is the cause. Its value is independent of
>>> other variables in your study.
>>>
>>> The dependent variable is the effect. Its value depends on changes in
>>> the independent variable.
>>>
>>> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>>>
>>> When we are asking whether or not H must abort its simulation of P we
>>> examine the simulation of P. We must not examine the behavior of H.
>>
>> This is simply wrong. You can ignore the code in the *decider*, but
>> not code inside the computation which the decider is simulating. The
>> call to H inside P is an integral part of the computation performed by
>> P. You can't ignore this anymore than you can ignore any other
>> instructions inside P.
>>
>> André
>>
>
> The independent variable is the cause. Its value is independent of other
> variables in your study.
>
> The dependent variable is the effect. Its value depends on changes in
> the independent variable.
>
> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>
>
>
> The question is whether or not H must abort its simulation of P.
> The behavior of H is totally irrelevant to this question.

Is this ANOTHER field you are showing yourself ignorant of??

The fact that H has been setup as the independent variable means we are
only interested in how thing depend on it. If its behavior is irrelevent
to the answer, why did you make it the independent variable.

Maybe you don't understand what that means.

>
> As I have proven below.
> As I have proven below.
> As I have proven below.
> As I have proven below.

FALSE.
>
> Of the two hypothetical possibilities: (independent variable)
> (1) H aborts the simulation of P
> (2) H never aborts the simulation of P
>
> We ask what is the effect on the behavior of P? (dependent variable)
>
> (1) P halts
> (2) P never halts
>
> It does not freaking matter at all what-ever-the-Hell H does except what
> the behavior of P is under the above two hypothetical scenarios.
>

But P isn't a fixed Turing Machine, but a Turing Machine built based on
H, thus when you change H you have changed P.

> If the result of purely hypothetical H that never aborts its
> simulation/execution of P would result in the infinite execution of P
> then we know axiomatically that H decides that P never halts correctly.

Right, The P based on the never aborting H has infinite execution, but
that isn't the P we are looking at, we are looking at the P built on the
H that DOES know how to abort its simulation. That is a different P so
its behavior is irrelevant. You need to look at the behavior of the P
that is built with the decider you are claiming can overcome the Linz
pattern.

That is like studing white dogs to find out the properties of black cats.

>
> Premise(1) Every computation that never halts unless its simulation is
> aborted is a computation that never halts. This verified as true on the
> basis of the meaning of its words.
>
>

Maybe your problem is that you don't understand the fact that Linz's
'Hat' operation doesn't create a single machine that works for all
deciders, but is a template to make a machine that foils a particular
decider. Thus when you make arguments about various deciders you need to
watch out as to what you are actually arguing about.

On 6/24/2021 4:40 AM, Malcolm McLean wrote:
> On Wednesday, 23 June 2021 at 17:00:57 UTC+1, Ben Bacarisse wrote:
>>
>> In reply, PO said he understood that, but then went on to say more
>> things as if anything, true or false, can alter the fact that the
>> assumption about H leads to a contradiction. Do you think he genuinely
>> believes that saying more things, even true things, can "undo" a
>> contradiction? That is a strange mind indeed.
>>
> We've had quite a bit of flip-flopping. We had a period when it was
> acknowledged that Linz's proof was sound but he had a slightly
> different property.

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

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

That H(P,P) cannot return a correct halt status to P in the above
computation is well proven.

That H(P,P) ever needs to return to P at all in the above code is the
key false assumption that unravels the whole proof.

> Defining a slightly different property to halting
> is not an inherently bad thing to do, it could be the starting point
> of some significant work. But that's very hard to do, and you and I
> pointed out that PO's different problem wasn't one of the "interesting"
> ones. You needed to solve the original halting problem first to decide
> it, for example.
>
> So there might have been a row back from that when he realised that
> the response would be "well that might be true but it doesn't get us
> anywhere".
>
> However I do think that he genuinely thinks that he's got something
> significant. I'm not a mind reader, but a troll would have got bored by
> now, whilst the posts go off at too many tangents to be a fraudster.
> When you dry run his simulating halt decider on itself, it is confusing.
> Take out the halt detector and it runs forever. Put the halt detector in,
> and it detects non-halting behaviour (according to PO, no real reason
> to disbelieve him). So surely it's got that right?

> But in fact simulate
> one more step, and the halt detection in the simulated machine will
> kick in and halt it.
>

I had the false assumption myself for a couple of days a year or two
ago. H can wait any fixed number of recursions before aborting its
input. If H simply waits for a later recursion to abort its input then
its input is never aborted because the code to abort this input does not
exist.

Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On 6/24/2021 5:49 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 23 June 2021 at 17:00:57 UTC+1, Ben Bacarisse wrote:
>>>
>>> In reply, PO said he understood that, but then went on to say more
>>> things as if anything, true or false, can alter the fact that the
>>> assumption about H leads to a contradiction. Do you think he genuinely
>>> believes that saying more things, even true things, can "undo" a
>>> contradiction? That is a strange mind indeed.
>>>
>> We've had quite a bit of flip-flopping. We had a period when it was
>> acknowledged that Linz's proof was sound but he had a slightly
>> different property. Defining a slightly different property to halting
>> is not an inherently bad thing to do, it could be the starting point
>> of some significant work. But that's very hard to do, and you and I
>> pointed out that PO's different problem wasn't one of the "interesting"
>> ones. You needed to solve the original halting problem first to decide
>> it, for example.
>>
>> So there might have been a row back from that when he realised that
>> the response would be "well that might be true but it doesn't get us
>> anywhere".
>>
>> However I do think that he genuinely thinks that he's got something
>> significant. I'm not a mind reader, but a troll would have got bored by
>> now, whilst the posts go off at too many tangents to be a fraudster.
>
> I don't think he's a troll, and I don't think he's a fraudster, but the
> changes in his claims suggest to me that he is aware of being wrong and
> having to row-back the wildest ones.

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

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

That H(P,P) cannot return a correct halt status to P in the above
computation is well proven.

That H(P,P) ever needs to return to P at all in the above code is the
key false assumption that unravels the whole proof.

> He certainly knows, but has not
> admitted, that he never had "two actual Turing machines" "fully encoded"
> back in Dec 2018, waiting only for a TM simulator to be able to run them

Virtual machines that are "computationally equivalent" to a Turing
machines are sufficiently Turing machines.

> (he claimed that would take about a week). I don't think these
> deceptions are fraudulent. I think his self-image can't cope with the
> concept of being wrong.
>
>> When you dry run his simulating halt decider on itself, it is confusing.
>> Take out the halt detector and it runs forever. Put the halt detector in,
>> and it detects non-halting behaviour (according to PO, no real reason
>> to disbelieve him). So surely it's got that right?
>
> I don't know what you mean. How do you run anything of his? We've
> never even seen the key function.
>
>> But in fact simulate
>> one more step, and the halt detection in the simulated machine will
>> kick in and halt it.
>
> I don't see the value in discussing all these details, though others
> clearly do. He's stated in various round-about ways that his "decider"
> (the hidden code we will never see) is wrong as far as "conventional"
> halting is concerned. There is zero dispute on the facts that the code
> indicates false for a halting computation.
>

When a simulating halt decider decides that an actual infinite loop
would never halt and it stops this simulation of this infinite loop it
correctly reports that the input never halts, even though the input does
indeed halt.

The same reasoning applies to infinite recursion and infinitely nested
simulation.

You always dodge this challenge because you know that you will fail
You always dodge this challenge because you know that you will fail
You always dodge this challenge because you know that you will fail
You always dodge this challenge because you know that you will fail

Premise(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.

Premise(2) The simulation of the input to H(P,P) never halts without
being aborted is a verified fact on the basis of its x86 execution
trace. (pages 3-4 of the paper).

Conclusion(3) From the above true premises it necessarily follows that
simulating halt decider H correctly reports that its input: (P,P) never
halts.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On 6/24/2021 6:29 AM, Richard Damon wrote:
> On 6/23/21 11:03 PM, olcott wrote:
>> On 6/23/2021 7:49 PM, André G. Isaak wrote:
>>> On 2021-06-23 18:01, olcott wrote:
>>>> On 6/23/2021 6:13 PM, André G. Isaak wrote:
>>>>> On 2021-06-23 14:07, olcott wrote:
>>>>>> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>>>>>>> On 2021-06-22 13:17, olcott wrote:
>>>>>>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-06-22 11:05, olcott wrote:
>>>>>>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>> In the case of the simulation of P it is verified on the basis of
>>>>>>>> the x86 execution trace of B, thus an established verified fact.
>>>>>>>
>>>>>>> Except that an execution trace doesn't 'verify' anything. No one
>>>>>>> doubts that your program decides that P(P) == 0. But unless the
>>>>>>> logic underlying your program is actually correct, this result
>>>>>>> tells us nothing. And you haven't provided any sort of proof that
>>>>>>> the logic underlying your program is actually correct.
>>>>>>>
>>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>
>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>
>>>>>>
>>>>>> Sure I have. When we look as page 3 and 4 of the above paper it is
>>>>>> very easy to see that H does faithfully simulate the execution of P
>>>>>> and that P has no escape from infinite execution in its own code.
>>>>>
>>>>> No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
>>>>> simulating P(P), then P(P) can't call the main H -- it can only
>>>>> invoke a copy of H *within the simulation*.
>>>>>
>>>>
>>>> It is actually and quite factually not a copy.
>>>> I have had to say this hundreds of times now.
>>>
>>> But if it isn't a copy, then your P isn't derived from your H in the
>>> manner prescribed by the Linz proof. If you want to claim to have
>>> provided a 'counterexample' to the 'standard proofs' then you need to
>>> actually construct your P in the same manner that H_Hat is constructed
>>> in those proofs.
>>>
>>>> It is the same freaking machine language at the
>>>> same freaking machine language address.
>>>
>>> If P is calling H directly, then in what sense is P being 'simulated'?
>>>
>>>>> Second, even if we ignore the above, the decision criterion you use
>>>>> is flawed because it completely ignores all conditional branches
>>>>> contained within P's copy of H, and it's these conditional branches
>>>>> which prevent P(P) from being an 'infinitely recursive' computation.
>>>>>
>>>>
>>>> Unless we keep the independent variable separate from the dependent
>>>> variable our analysis is incorrect.
>>>>
>>>> The independent variable is the cause. Its value is independent of
>>>> other variables in your study.
>>>>
>>>> The dependent variable is the effect. Its value depends on changes in
>>>> the independent variable.
>>>>
>>>> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>>>>
>>>> When we are asking whether or not H must abort its simulation of P we
>>>> examine the simulation of P. We must not examine the behavior of H.
>>>
>>> This is simply wrong. You can ignore the code in the *decider*, but
>>> not code inside the computation which the decider is simulating. The
>>> call to H inside P is an integral part of the computation performed by
>>> P. You can't ignore this anymore than you can ignore any other
>>> instructions inside P.
>>>
>>> André
>>>
>>
>> The independent variable is the cause. Its value is independent of other
>> variables in your study.
>>
>> The dependent variable is the effect. Its value depends on changes in
>> the independent variable.
>>
>> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>>
>>
>>
>> The question is whether or not H must abort its simulation of P.
>> The behavior of H is totally irrelevant to this question.
>
> Is this ANOTHER field you are showing yourself ignorant of??
>
> The fact that H has been setup as the independent variable means we are
> only interested in how thing depend on it. If its behavior is irrelevent
> to the answer, why did you make it the independent variable.
>
> Maybe you don't understand what that means.
>
>>
>> As I have proven below.
>> As I have proven below.
>> As I have proven below.
>> As I have proven below.
>
> FALSE.
>>
>> Of the two hypothetical possibilities: (independent variable)
>> (1) H aborts the simulation of P
>> (2) H never aborts the simulation of P
>>
>> We ask what is the effect on the behavior of P? (dependent variable)
>>
>> (1) P halts
>> (2) P never halts
>>
>> It does not freaking matter at all what-ever-the-Hell H does except what
>> the behavior of P is under the above two hypothetical scenarios.
>>
>
> But P isn't a fixed Turing Machine, but a Turing Machine built based on
> H, thus when you change H you have changed P.
>
>
>> If the result of purely hypothetical H that never aborts its
>> simulation/execution of P would result in the infinite execution of P
>> then we know axiomatically that H decides that P never halts correctly.
>
> Right, The P based on the never aborting H has infinite execution, but
> that isn't the P we are looking at,

That hypothetical H/P proves beyond all possible doubt that the in the
actual H(P,P) the input to H never halts on the basis of this axiom:

Premise(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.

--
Copyright 2021 Pete Olcott

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

On Thursday, 24 June 2021 at 16:25:00 UTC+1, olcott wrote:
> On 6/24/2021 4:40 AM, Malcolm McLean wrote:
>
> That H(P,P) cannot return a correct halt status to P in the above
> computation is well proven.
>
> That H(P,P) ever needs to return to P at all in the above code is the
> key false assumption that unravels the whole proof.
>
H has to be a Turing machine.
>
> > But in fact simulate
> > one more step, and the halt detection in the simulated machine will
> > kick in and halt it.
> >
> I had the false assumption myself for a couple of days a year or two
> ago. H can wait any fixed number of recursions before aborting its
> input. If H simply waits for a later recursion to abort its input then
> its input is never aborted because the code to abort this input does not
> exist.
> Halting problem undecidability and infinitely nested simulation
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
It's not really recursion. It's nested simulation, which is similar to recursion,
but different from it in that control never passes to the child function.
Instead the child function is simulated, then simulated by a simulated function,
then simulated by a simulated simulated function and so on, with control
always remaining in the root function.

If H doesn't abort, then this goes on forever. However if it does abort, it always
aborts one step before the child would have performed the identical abort.
So you've kind of created your own paradox problem here. The abort / don't
abort decision is always wrong.

On 6/24/2021 10:47 AM, Malcolm McLean wrote:
> On Thursday, 24 June 2021 at 16:25:00 UTC+1, olcott wrote:
>> On 6/24/2021 4:40 AM, Malcolm McLean wrote:
>>
>> That H(P,P) cannot return a correct halt status to P in the above
>> computation is well proven.
>>
>> That H(P,P) ever needs to return to P at all in the above code is the
>> key false assumption that unravels the whole proof.
>>
> H has to be a Turing machine.

In the pseudo-code proofs H is always pseudo-code and never a Turing
machine. It is not true that H must be a Turing machine as long as the
H/P relationship is sufficiently equivalent to the H/⟨Ĥ⟩ the C/x86
version applied.

>>
>>> But in fact simulate
>>> one more step, and the halt detection in the simulated machine will
>>> kick in and halt it.
>>>
>> I had the false assumption myself for a couple of days a year or two
>> ago. H can wait any fixed number of recursions before aborting its
>> input. If H simply waits for a later recursion to abort its input then
>> its input is never aborted because the code to abort this input does not
>> exist.
>> Halting problem undecidability and infinitely nested simulation
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
> It's not really recursion. It's nested simulation, which is similar to recursion,
> but different from it in that control never passes to the child function.

It is sufficiently computationally equivalent.

> Instead the child function is simulated, then simulated by a simulated function,
> then simulated by a simulated simulated function and so on, with control
> always remaining in the root function.
>
> If H doesn't abort, then this goes on forever. However if it does abort, it always
> aborts one step before the child would have performed the identical abort.

This is not true. If we simply wait for the child to do it then it never
happens.

> So you've kind of created your own paradox problem here. The abort / don't
> abort decision is always wrong.
>

Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P

We ask what is the effect on the behavior of P? (dependent variable)

(1) P halts
(2) P never halts

If the result of purely hypothetical H that never aborts its
simulation/execution of P would result in the infinite execution of P
then we know axiomatically that H decides that P never halts correctly.

This is the axiom:
Premise(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.

--
Copyright 2021 Pete Olcott

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

On 2021-06-23 21:03, olcott wrote:
> On 6/23/2021 7:49 PM, André G. Isaak wrote:
>> On 2021-06-23 18:01, olcott wrote:
>>> On 6/23/2021 6:13 PM, André G. Isaak wrote:
>>>> On 2021-06-23 14:07, olcott wrote:
>>>>> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>>>>>> On 2021-06-22 13:17, olcott wrote:
>>>>>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>>>>>> On 2021-06-22 11:05, olcott wrote:
>>>>>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>> In the case of the simulation of P it is verified on the basis of
>>>>>>> the x86 execution trace of B, thus an established verified fact.
>>>>>>
>>>>>> Except that an execution trace doesn't 'verify' anything. No one
>>>>>> doubts that your program decides that P(P) == 0. But unless the
>>>>>> logic underlying your program is actually correct, this result
>>>>>> tells us nothing. And you haven't provided any sort of proof that
>>>>>> the logic underlying your program is actually correct.
>>>>>>
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>
>>>>>
>>>>> Sure I have. When we look as page 3 and 4 of the above paper it is
>>>>> very easy to see that H does faithfully simulate the execution of P
>>>>> and that P has no escape from infinite execution in its own code.
>>>>
>>>> No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
>>>> simulating P(P), then P(P) can't call the main H -- it can only
>>>> invoke a copy of H *within the simulation*.
>>>>
>>>
>>> It is actually and quite factually not a copy.
>>> I have had to say this hundreds of times now.
>>
>> But if it isn't a copy, then your P isn't derived from your H in the
>> manner prescribed by the Linz proof. If you want to claim to have
>> provided a 'counterexample' to the 'standard proofs' then you need to
>> actually construct your P in the same manner that H_Hat is constructed
>> in those proofs.
>>
>>> It is the same freaking machine language at the
>>> same freaking machine language address.
>>
>> If P is calling H directly, then in what sense is P being 'simulated'?
>>
>>>> Second, even if we ignore the above, the decision criterion you use
>>>> is flawed because it completely ignores all conditional branches
>>>> contained within P's copy of H, and it's these conditional branches
>>>> which prevent P(P) from being an 'infinitely recursive' computation.
>>>>
>>>
>>> Unless we keep the independent variable separate from the dependent
>>> variable our analysis is incorrect.
>>>
>>> The independent variable is the cause. Its value is independent of
>>> other variables in your study.
>>>
>>> The dependent variable is the effect. Its value depends on changes in
>>> the independent variable.
>>>
>>> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>>>
>>> When we are asking whether or not H must abort its simulation of P we
>>> examine the simulation of P. We must not examine the behavior of H.
>>
>> This is simply wrong. You can ignore the code in the *decider*, but
>> not code inside the computation which the decider is simulating. The
>> call to H inside P is an integral part of the computation performed by
>> P. You can't ignore this anymore than you can ignore any other
>> instructions inside P.
>>
>> André
>>
>
> The independent variable is the cause. Its value is independent of other
> variables in your study.
>
> The dependent variable is the effect. Its value depends on changes in
> the independent variable.
>
> https://www.scribbr.com/methodology/independent-and-dependent-variables/

Is there some reason you always insist on posting a webpage link to
explain really basic concepts? In the unlikely event that someone here
doesn't understand what this is they can always look it up themselves.

>
>
> The question is whether or not H must abort its simulation of P.
> The behavior of H is totally irrelevant to this question.
>
> As I have proven below.
> As I have proven below.
> As I have proven below.
> As I have proven below.
>
> Of the two hypothetical possibilities: (independent variable)
> (1) H aborts the simulation of P
> (2) H never aborts the simulation of P

> We ask what is the effect on the behavior of P? (dependent variable)
>
> (1) P halts

You are abusing terms here. A Turing Machine halts only when it reaches
one of its final states. If H aborts its simulation of P, then P does
*not* halt (regardless of whether it is a halting or non-halting
computation). Its simulation simply ends prematurely at which point H
halts.

> (2) P never halts
>
> It does not freaking matter at all what-ever-the-Hell H does except what
> the behavior of P is under the above two hypothetical scenarios.

P *is derived* from H, so the behaviour of P depends on the behaviour of
H. Therefore it *does* matter what H does.

Because of the above H and P are *interdependent* variables. If you want
to treat H as an independent variable, then you must insure that P
remains invariant, i.e. that the copy of H within P remains the same
regardless of any changes you make to the outermost H.

If the outermost H doesn't halt the simulation of P (i.e. if you disable
the ability of the outermost H to abort simulations, and *only* the
outermost H), then the copy of H inside P will abort the simulation of
its input, at which point P *will* halt.

> If the result of purely hypothetical H that never aborts its
> simulation/execution of P would result in the infinite execution of P
> then we know axiomatically that H decides that P never halts correctly.
>
> Premise(1) Every computation that never halts unless its simulation is
> aborted is a computation that never halts. This verified as true on the
> basis of the meaning of its words.

No, it isn't, because it is entirely unclear what 'its simulation'
refers to. No claim with such sloppy wording can be 'verified as true on
the basis of the meaning of its words.'

And in actual proofs, we show things to be true based on the fact that
they can be derived from axioms using accepted rules of inference, not
'on the basis of the meaning of [their] words'. What you're engaging in
is simply word-games.

André

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

On 6/24/2021 4:13 PM, André G. Isaak wrote:
> On 2021-06-23 21:03, olcott wrote:
>> On 6/23/2021 7:49 PM, André G. Isaak wrote:
>>> On 2021-06-23 18:01, olcott wrote:
>>>> On 6/23/2021 6:13 PM, André G. Isaak wrote:
>>>>> On 2021-06-23 14:07, olcott wrote:
>>>>>> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>>>>>>> On 2021-06-22 13:17, olcott wrote:
>>>>>>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-06-22 11:05, olcott wrote:
>>>>>>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>> In the case of the simulation of P it is verified on the basis
>>>>>>>> of the x86 execution trace of B, thus an established verified fact.
>>>>>>>
>>>>>>> Except that an execution trace doesn't 'verify' anything. No one
>>>>>>> doubts that your program decides that P(P) == 0. But unless the
>>>>>>> logic underlying your program is actually correct, this result
>>>>>>> tells us nothing. And you haven't provided any sort of proof that
>>>>>>> the logic underlying your program is actually correct.
>>>>>>>
>>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>
>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>
>>>>>>
>>>>>> Sure I have. When we look as page 3 and 4 of the above paper it is
>>>>>> very easy to see that H does faithfully simulate the execution of
>>>>>> P and that P has no escape from infinite execution in its own code.
>>>>>
>>>>> No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
>>>>> simulating P(P), then P(P) can't call the main H -- it can only
>>>>> invoke a copy of H *within the simulation*.
>>>>>
>>>>
>>>> It is actually and quite factually not a copy.
>>>> I have had to say this hundreds of times now.
>>>
>>> But if it isn't a copy, then your P isn't derived from your H in the
>>> manner prescribed by the Linz proof. If you want to claim to have
>>> provided a 'counterexample' to the 'standard proofs' then you need to
>>> actually construct your P in the same manner that H_Hat is
>>> constructed in those proofs.
>>>
>>>> It is the same freaking machine language at the
>>>> same freaking machine language address.
>>>
>>> If P is calling H directly, then in what sense is P being 'simulated'?
>>>
>>>>> Second, even if we ignore the above, the decision criterion you use
>>>>> is flawed because it completely ignores all conditional branches
>>>>> contained within P's copy of H, and it's these conditional branches
>>>>> which prevent P(P) from being an 'infinitely recursive' computation.
>>>>>
>>>>
>>>> Unless we keep the independent variable separate from the dependent
>>>> variable our analysis is incorrect.
>>>>
>>>> The independent variable is the cause. Its value is independent of
>>>> other variables in your study.
>>>>
>>>> The dependent variable is the effect. Its value depends on changes
>>>> in the independent variable.
>>>>
>>>> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>>>>
>>>>
>>>> When we are asking whether or not H must abort its simulation of P
>>>> we examine the simulation of P. We must not examine the behavior of H.
>>>
>>> This is simply wrong. You can ignore the code in the *decider*, but
>>> not code inside the computation which the decider is simulating. The
>>> call to H inside P is an integral part of the computation performed
>>> by P. You can't ignore this anymore than you can ignore any other
>>> instructions inside P.
>>>
>>> André
>>>
>>
>> The independent variable is the cause. Its value is independent of
>> other variables in your study.
>>
>> The dependent variable is the effect. Its value depends on changes in
>> the independent variable.
>>
>> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>
> Is there some reason you always insist on posting a webpage link to
> explain really basic concepts? In the unlikely event that someone here
> doesn't understand what this is they can always look it up themselves.
>
>>
>>
>> The question is whether or not H must abort its simulation of P.
>> The behavior of H is totally irrelevant to this question.
>>
>> As I have proven below.
>> As I have proven below.
>> As I have proven below.
>> As I have proven below.
>>
>> Of the two hypothetical possibilities: (independent variable)
>> (1) H aborts the simulation of P
>> (2) H never aborts the simulation of P
>
>> We ask what is the effect on the behavior of P? (dependent variable)
>>
>> (1) P halts
>
> You are abusing terms here. A Turing Machine halts only when it reaches
> one of its final states. If H aborts its simulation of P, then P does
> *not* halt (regardless of whether it is a halting or non-halting
> computation). Its simulation simply ends prematurely at which point H
> halts.
>
>> (2) P never halts
>>
>> It does not freaking matter at all what-ever-the-Hell H does except
>> what the behavior of P is under the above two hypothetical scenarios.
>
> P *is derived* from H, so the behaviour of P depends on the behaviour of
> H. Therefore it *does* matter what H does.
>
> Because of the above H and P are *interdependent* variables. If you want
> to treat H as an independent variable, then you must insure that P
> remains invariant, i.e. that the copy of H within P remains the same
> regardless of any changes you make to the outermost H.
>
> If the outermost H doesn't halt the simulation of P (i.e. if you disable
> the ability of the outermost H to abort simulations, and *only* the
> outermost H), then the copy of H inside P will abort the simulation of
> its input, at which point P *will* halt.
>

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

The question can be rephrased this way in the hypothetical case where
the H/P is replaced with an x86 emulator and the hypothetical case where
the halt decider embedded at Ĥ.qx is replaced with a UTM

we can know that the original P(P) and Ĥ(⟨Ĥ⟩) are correctly decided as
computations that never halt by a simulating halt decider if the above
computations never halt because a simulating halt acts only as a x86
emulator / UTM until after its input demonstrates an infinitely
repeating behavior pattern.

That people have difficulty comprehending the necessary truth of this
does not count as any rebuttal what-so-ever.

>> If the result of purely hypothetical H that never aborts its
>> simulation/execution of P would result in the infinite execution of P
>> then we know axiomatically that H decides that P never halts correctly.
>>
>> Premise(1) Every computation that never halts unless its simulation is
>> aborted is a computation that never halts. This verified as true on
>> the basis of the meaning of its words.
>
> No, it isn't, because it is entirely unclear what 'its simulation'
> refers to. No claim with such sloppy wording can be 'verified as true on
> the basis of the meaning of its words.'
>
> And in actual proofs, we show things to be true based on the fact that
> they can be derived from axioms using accepted rules of inference, not
> 'on the basis of the meaning of [their] words'. What you're engaging in
> is simply word-games.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 6/22/2021 5:45 PM, wij wrote:
> On Wednesday, 23 June 2021 at 06:57:58 UTC+8, Richard Damon wrote:
>> On 6/22/21 3:22 PM, Chris M. Thomasson wrote:
>>> On 6/21/2021 6:54 PM, Richard Damon wrote:
>>>>
>>>> Well, the problem is that Turing Machines CAN'T be black boxes. And the
>>>> definition of the Halting Problem is that the decider is given a full
>>>> description of the Turing Machine, which is basically like a full
>>>> listing of the program.
>>>
>>> Oh, sorry. I thought his x86 simulator would run an x86 program and
>>> determine if it would halt or not. My bad. The assembled program would
>>> have all the information he needs right? Or, would I have to give him
>>> source code... Humm, I don't know. Does he have an assembler?
>>>
>>> When I say "black box", I was basically referring to a program that
>>> somebody else assembled into an executable.
>>>
>>> His simulator, as-is, should be able to simulate any x86 program and
>>> determine if it halts or not... Sound Kosher?
>>>
>>>
>> The problem is that the term 'black box' tend to mean something that you
>> can't look inside of, which means that his simulator couldn't get at the
>> object code of it.
>>
>> A program that was a real black box would have its internals encrypted
>> and have test to make sure that it wasn't being 'spied' on before
>> decrypting itself. Of course, without support from the OS, or some
>> controlling program, things can't be perfect black boxes, just enough to
>> be a pain to look into.
>
> Black box program can be executed, like any app., by simulator or OS.
> The same as oracle can be used in TM, P can be a black box to H, black body
> in physics.
>

A valid x86 program should just run on his simulator. The simulator
would start getting instructions and executing them. The question is,
will the instruction stream halt, or not? I am guessing that his system
would spawn a simulator in a sandbox or something, with a target
program. The simulator fires up, initializes itself, and starts
executing the target program.

On 2021-06-24 15:40, olcott wrote:

<snip>

> The question can be rephrased this way in the hypothetical case where
> the H/P is replaced with an x86 emulator and the hypothetical case where
> the halt decider embedded at Ĥ.qx is replaced with a UTM

If you want to test your claim that the halt decider *MUST* terminate
its input, you change the behaviour of the halt decider so it can't
terminate its input. (Or, better yet, you just run P(P) directly without
making any changes at all -- your aversion to this option is truly
mystifying).

What you *CAN'T* do is change the behaviour of the input to the decider
which is what you are doing if you also change the H which is contained
inside P. By doing this, you change P(P) into an entirely different
computation.

You claim that H is an independent variable and P is a dependent
variable. If you change both P and H, then P is not an independent
variable. P and H are interdependent variables, which means any test you
perform is worthless.

> we can know that the original P(P) and Ĥ(⟨Ĥ⟩) are correctly decided as
> computations that never halt by a simulating halt decider if the above
> computations never halt because a simulating halt acts only as a x86
> emulator / UTM until after its input demonstrates an infinitely
> repeating behavior pattern.
>
> That people have difficulty comprehending the necessary truth of this
> does not count as any rebuttal what-so-ever.

People comprehend things just fine. They comprehend that to test you
claim we must change *only* the topmost H, not the copy of H embedded in P.

André

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