On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> We can make an undecidable problem by simply phrasing a question such
>> that correct answers are impossible.
>
> But decision problems, of which the halting problem is one, are defined
> as those that always have correct yes/no answers. Such a problem is
> undecidable if the set of yes instances in not recursive.
>

Ĥ.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

So then exactly what is the proper terminology for the idea that the
halt decider embedded at Ĥ.qx cannot transition to a final state
corresponding to the actual halt status of Ĥ(⟨Ĥ⟩) (Ĥ applied to its own
Turing machine description as input)?

Of everyone here you may be the best one on terminological questions.

> Every instance of the halting problem has a correct yes/no answer. The
> correct answer is "yes" for all those instances that represent halting
> computations and "no" otherwise.
>
> You have refused to accept this simple statement about halting for more
> than a decade.
>

Let us now get the proper terminology untangled.

--
Copyright 2021 Pete Olcott

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

On 7/1/2021 4:25 PM, olcott wrote:
> On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> We can make an undecidable problem by simply phrasing a question such
>>> that correct answers are impossible.
>>
>> But decision problems, of which the halting problem is one, are defined
>> as those that always have correct yes/no answers.  Such a problem is
>> undecidable if the set of yes instances in not recursive.
>>
>
> Ĥ.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
>
> So then exactly what is the proper terminology for the idea that the
> halt decider embedded at Ĥ.qx cannot transition to a final state
> corresponding to the actual halt status of Ĥ(⟨Ĥ⟩) (Ĥ applied to its own
> Turing machine description as input)?
>
> Of everyone here you may be the best one on terminological questions.
>

When the entire set of possible {true, false} Boolean return values from
an (input / TM) pair provides an incorrect halting status

this is analogous to the entire set of polar {yes, no} answers for the
wife beating status of a specific person that has never been married.

In the first case both true, false} are the wrong return value from a
Boolean function and in the second case both {Yes, no} are the wrong
answer to a polar question.

>> Every instance of the halting problem has a correct yes/no answer.  The
>> correct answer is "yes" for all those instances that represent halting
>> computations and "no" otherwise.
>>
>> You have refused to accept this simple statement about halting for more
>> than a decade.
>>
>
> Let us now get the proper terminology untangled.
>

--
Copyright 2021 Pete Olcott

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

On 7/1/2021 6:24 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/1/2021 4:25 PM, olcott wrote:
>>> On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> We can make an undecidable problem by simply phrasing a question such
>>>>> that correct answers are impossible.
>>>>
>>>> But decision problems, of which the halting problem is one, are defined
>>>> as those that always have correct yes/no answers.  Such a problem is
>>>> undecidable if the set of yes instances in not recursive.
>
> <cut>
>> When the entire set of possible {true, false} Boolean return values
>> from an (input / TM) pair provides an incorrect halting status
>
> For every finite string, one of true or false is always the correct
> halting status for that string: true if the string represents a halting
> computation, false otherwise.
>
> Stop fighting this obvious fact and agree to it. You are not talking
> about the halting problem until you do.
>

Ĥ.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

In the Peter Linz proof it is commonly understood that neither the Ĥ.qy
(yes it halts) nor the Ĥ.qn (no it does not halt) are the correct halt
status that Ĥ can transition to when Ĥ is applied to ⟨Ĥ⟩ (its own Turing
machine description).

Because you have dodged this question so persistently over the years by
saying that there is a halt status for Ĥ applied to ⟨Ĥ⟩, when this is
clearly NOT the question that I am asking I must suppose that you simply
flat out don't know this answer.

Perhaps it is called an undecidable instance of a decision problem.

--
Copyright 2021 Pete Olcott

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

On 7/1/2021 8:52 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/1/2021 6:24 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/1/2021 4:25 PM, olcott wrote:
>>>>> On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> We can make an undecidable problem by simply phrasing a question such
>>>>>>> that correct answers are impossible.
>>>>>>
>>>>>> But decision problems, of which the halting problem is one, are defined
>>>>>> as those that always have correct yes/no answers.  Such a problem is
>>>>>> undecidable if the set of yes instances in not recursive.
>>> <cut>
>>>> When the entire set of possible {true, false} Boolean return values
>>>> from an (input / TM) pair provides an incorrect halting status
>>> For every finite string, one of true or false is always the correct
>>> halting status for that string: true if the string represents a halting
>>> computation, false otherwise.
>>> Stop fighting this obvious fact and agree to it. You are not talking
>>> about the halting problem until you do.
>>>
>>
>> Ĥ.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
>>
>> In the Peter Linz proof it is commonly understood that neither the
>> Ĥ.qy (yes it halts) nor the Ĥ.qn (no it does not halt) are the correct
>> halt status that Ĥ can transition to when Ĥ is applied to ⟨Ĥ⟩ (its own
>> Turing machine description).
>
> I accept that this is your misunderstanding, and it may even be a common
> misunderstanding, but it is not what the lines from Linz you keep
> quoting mean. It absolutely does not mean that there is an instance of
> the halting problem without a correct yes/no answer.
>
>> Because you have dodged this question so persistently over the years
>> by saying that there is a halt status for Ĥ applied to ⟨Ĥ⟩,
>
> No. I have never said this. H (as in Linz) does not exist, and neither
> does H^. There is no string [H^]. The question of whether a TM that
> does not exist halts when given a non-existent string as its input is
> too absurd take seriously.
>
> For every actual TM, X, there is a correct yes/no answer for all the
> halting problem instances involving X. For every TM for which we can
> form X^ (which is all of them if we slightly relax the construction) the
> same is also true. I.e. for every TM X, the instance <[X^],[X^]> has a
> correct yes/no answer because the computation X^([X^]) either halts or
> it does not halt. However, X does not give it.
>

What is the specific term-of-the-art for the category of the cases of
(TM X / Input I) such that X(I) cannot give the correct answer?

> This is why your Big Lie of Dec 2018 was considered interesting. You
> claimed to have an impossible TM pair, fully encoded. Now you simply
> claim to have a TM (or "equivalent") that gets the answer wrong. That
> possibility was never in doubt. No one is interested in a TM X that
> rejects <[X^],[X^]> despite X^([X^]) being a halting computation.

That I called the RASP equivalent of a TM is a TM is not a fascist Nazi
attempt to subvert Democracy by claiming that the election was stolen.

It is very disgraceful to the many millions of people that have been
murdered by the Nazis (the origin of the term "big lie") for you to use
this term in such a cavalier way.

>> when this is clearly NOT the question that I am asking I must suppose
>> that you simply flat out don't know this answer.
>
> Or you just don't understand what I (and others) have been telling you
> for years.
>

If this was true then "others" could point to at least one technical
mistake in my paper that shows that my sound deductive inference is
incorrect.

Halting problem undecidability and infinitely nested simulation

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

>> Perhaps it is called an undecidable instance of a decision problem.
>
> No it is not. It can only be an instance if H (and therefore H^ and
> [H^]) exists. Every instance of every decision problem has a correct
> yes/no answer. If not, it's not a decision problem. In particular,
> every instance of the halting problem has a correct yes/no answer: yes
> for the instances the represent halting computation and no for all the
> others.
>
> Curiously, the way you've tried to get out of the Big Lie of Dec 2018
> has not been to deny that there is a correct answer, but to declare that
> "no" is the correct answer for a halting computation. You could accept
> that every instance has a correct answer without actually damaging your
> current nonsensical claim in any way.
>

You have already agreed with the one axiom of my sound deductive inference.

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

Premise(1) (axiom) 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) (verified fact) 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.

--
Copyright 2021 Pete Olcott

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

On 7/1/2021 10:16 PM, Richard Damon wrote:
> On 7/1/21 10:10 AM, olcott wrote:
>> On 7/1/2021 4:51 AM, Malcolm McLean wrote:
>>> On Thursday, 1 July 2021 at 09:38:45 UTC+1, David Brown wrote:
>>>> On 30/06/2021 19:15, olcott wrote:
>>>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>>>> olcott wrote:
>>>>>>> Because my writing style is not in the ballpark of academic quality
>>>>>>> [...]
>>>>>>
>>>>>> Then fix it.
>>>>>>
>>>>>
>>>>> I didn't know where to begin on this except for asking for a computer
>>>>> science professor to coach me.
>>>>>
>>>> There is your answer - talk to a computer scientist at a university.
>>>> You need to /talk/ to someone, physically and directly. Posting stuff
>>>> on Usenet is not working for you.
>>>>
>>> No, that's asking for trouble.
>>>
>>
>> Since at this point I am obviously correct, why are people still
>> disagreeing?
>>
>
> Because you are the only one who think that you are correct. We know
> that you aren't and have proved it.
>

The only "proof" that you provided is that you fail to comprehend that
the first premise is verified as true on the basis of the meaning of its
words. Both Kaz and Ben have agreed that they do understand this.

You already agreed with the second premise and the conclusion logically
follows from the two premises.

What is left that could possibly be my error?

Premise(1) (axiom) 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) (verified fact) 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.

Halting problem undecidability and infinitely nested simulation

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

> Your arguemnts are NOT new, but are very similar to many seen over the
> decades. You may not see much of them, because failures tend not to get
> well published, and you seem to have rejected really looking at through
> introductory material that includes the history that shows where the
> problems were.
>

--
Copyright 2021 Pete Olcott

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

On 7/2/2021 5:28 AM, Andy Walker wrote:
> On 02/07/2021 07:58, David Brown wrote:
>> [...] But as I understand it, the whole point of the common
>> proof that halting is undecidable is that the assumption that the
>> function H is computable leads to the contradiction that Ĥ(Ĥ) is both
>> true and false, alternatively that it is neither true nor false.  And
>> since it must be either true /or/ false (as everything is finite here),
>> that cannot be the case.  Therefore H could not have been computable.
>
>     There is a danger of a confusion of notation in the above.  We
> have to distinguish the [Boolean] function H which is True if a given
> instance halts or False if it doesn't, from a computer [or TM], also
> called H, that [by hypothesis] computes that function.  The point then
> is that given [TM] H we can construct H_hat that H gets wrong, showing
> that no such TM exists.  [Other proofs are available.]
>
>> It seems to me that Olcott's argument is based on assuming H /is/ a real
>> computable function, then redefining halting to allow an option of
>> "neither halts nor does not halt" to remove the contradiction.  Then he
>> claims that this means the common proof of halting undecidability is
>> wrong.
>> Is that a fair summary?
>

No that is not even close.
Read my paper (linked below) to see what I mean:

>     You'd have to ask PO, but I don't think he'd accept that.  AIUI,
> he doesn't accept that any valid question is undecidable, so that the
> undecidable [in his eyes] instances prove that the question was invalid.
> He still doesn't accept that the H_hat instance is perfectly decidable,
> it's just that H gets the wrong answer.

No that is not even close.
Read my paper (linked below) to see what I mean:

> He doesn't accept Goedel's
> theorem for similar reasons, relating all such results to the Liar
> Paradox and other problems with self-reference.
>
>     Meanwhile, in the Real World, it is of course possible to make
> genuine progress by writing programs that correctly and usefully reply
> True, False or Don't Know to instances of the HP.  This makes more
> sense than "neither halts nor does not halt", but is too well-known
> and too obvious to be of interest to PO.  Or, perhaps, to this group.
>

I constantly update this paper to make my works more clear.
I just rewrote the abstract in response to this message.

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 7/2/2021 5:32 AM, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 02/07/2021 03:52, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/1/2021 6:24 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/1/2021 4:25 PM, olcott wrote:
>>>>>>> On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> We can make an undecidable problem by simply phrasing a question such
>>>>>>>>> that correct answers are impossible.
>>>>>>>>
>>>>>>>> But decision problems, of which the halting problem is one, are defined
>>>>>>>> as those that always have correct yes/no answers.  Such a problem is
>>>>>>>> undecidable if the set of yes instances in not recursive.
>>>>> <cut>
>>>>>> When the entire set of possible {true, false} Boolean return values
>>>>>> from an (input / TM) pair provides an incorrect halting status
>>>>> For every finite string, one of true or false is always the correct
>>>>> halting status for that string: true if the string represents a halting
>>>>> computation, false otherwise.
>>>>> Stop fighting this obvious fact and agree to it. You are not talking
>>>>> about the halting problem until you do.
>>>>>
>>>>
>>>> Ĥ.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
>>>>
>>>> In the Peter Linz proof it is commonly understood that neither the
>>>> Ĥ.qy (yes it halts) nor the Ĥ.qn (no it does not halt) are the correct
>>>> halt status that Ĥ can transition to when Ĥ is applied to ⟨Ĥ⟩ (its own
>>>> Turing machine description).
>>>
>>> I accept that this is your misunderstanding, and it may even be a common
>>> misunderstanding, but it is not what the lines from Linz you keep
>>> quoting mean. It absolutely does not mean that there is an instance of
>>> the halting problem without a correct yes/no answer.
>>>
>>>> Because you have dodged this question so persistently over the years
>>>> by saying that there is a halt status for Ĥ applied to ⟨Ĥ⟩,
>>>
>>> No. I have never said this. H (as in Linz) does not exist, and neither
>>> does H^. There is no string [H^]. The question of whether a TM that
>>> does not exist halts when given a non-existent string as its input is
>>> too absurd take seriously.
>>>
>> You know the details of these things better than I, and I am decades out
>> of practice. But as I understand it, the whole point of the common
>> proof that halting is undecidable is that the assumption that the
>> function H is computable leads to the contradiction that Ĥ(Ĥ) is both
>> true and false, alternatively that it is neither true nor false.
>
> It just leads to a contradiction. That's all. An assumption -- that
> there exists an H with H(s) = true if, and only if, s represents a
> halting computation -- is shown to be logically unsustainable.
>
> There is nothing to be both true and false here. There is no such H.
>

In other words you are claiming that the (TM X/Input I) pairs that have
no correct yes/no return value from X have no specific term-of-the-art.

>> And
>> since it must be either true /or/ false (as everything is finite here),
>> that cannot be the case. Therefore H could not have been computable.
>>
>> It seems to me that Olcott's argument is based on assuming H /is/ a real
>> computable function, then redefining halting to allow an option of
>> "neither halts nor does not halt" to remove the contradiction. Then he
>> claims that this means the common proof of halting undecidability is
>> wrong.
>
> This is indeed what's wrong. He starts out certain that a logically
> impossible TM exists. When that is shown to be contradictory he /has/
> to find some way out.

// 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);
}

It is quite nutty to say that when H determines that P is calling it in
infinitely nested simulation, aborts its simulation of P on this basis,
and then reports that P never halts has any contradiction what-so-ever.

Halting problem undecidability and infinitely nested simulation

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

> Accepting that he is wrong about his certain
> knowledge is not psychologically possible, so any other way out is
> preferable, even one as daft as declaring that X(<[X^],[X^]>) = false is
> the correct result for this one case, despite the fact that the string
> <[X^],[X^]> represents the halting computation X^([X^]).
>

The fact that you cannot point to any error in the above and still
insist that I am wrong really seems to indicate that you are flat out
dishonest.

The fact that most of your rebuttals utterly rely on rhetoric and
misdirection really seems to indicate that you are flat out dishonest.

>> Is that a fair summary?
>

Revelation 21:8 King James Version
.... and all liars, shall have their part in the lake which burneth with
fire and brimstone: which is the second death.

Personally I believe that the above is far too harsh.

> I don't like the first bit. It begs the question of what "it" is that
> is both true and false. A contradiction is just a contradiction.
>
> I much prefer the other proofs. No doubt this is one reason PO will
> never look at them.
>

--
Copyright 2021 Pete Olcott

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

On 7/2/2021 6:15 AM, Richard Damon wrote:
> On 7/1/21 11:27 PM, olcott wrote:
>> On 7/1/2021 10:16 PM, Richard Damon wrote:
>>> On 7/1/21 10:10 AM, olcott wrote:
>>>> On 7/1/2021 4:51 AM, Malcolm McLean wrote:
>>>>> On Thursday, 1 July 2021 at 09:38:45 UTC+1, David Brown wrote:
>>>>>> On 30/06/2021 19:15, olcott wrote:
>>>>>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>>>>>> olcott wrote:
>>>>>>>>> Because my writing style is not in the ballpark of academic quality
>>>>>>>>> [...]
>>>>>>>>
>>>>>>>> Then fix it.
>>>>>>>>
>>>>>>>
>>>>>>> I didn't know where to begin on this except for asking for a computer
>>>>>>> science professor to coach me.
>>>>>>>
>>>>>> There is your answer - talk to a computer scientist at a university.
>>>>>> You need to /talk/ to someone, physically and directly. Posting stuff
>>>>>> on Usenet is not working for you.
>>>>>>
>>>>> No, that's asking for trouble.
>>>>>
>>>>
>>>> Since at this point I am obviously correct, why are people still
>>>> disagreeing?
>>>>
>>>
>>> Because you are the only one who think that you are correct. We know
>>> that you aren't and have proved it.
>>>
>>
>> The only "proof" that you provided is that you fail to comprehend that
>> the first premise is verified as true on the basis of the meaning of its
>> words. Both Kaz and Ben have agreed that they do understand this.
>>
>> You already agreed with the second premise and the conclusion logically
>> follows from the two premises.
>>
>> What is left that could possibly be my error?
>>
>> Premise(1) (axiom) 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 statement is true for the correct definition of the words, that
> interpretation could be expressed as the Halting of P(I) is the same as
> the Halting of UTM(P,I). I.E, the ONLY simulator in view of the aborting
> is the top most simulator over the whole computation. THAT meaning comes
> out simply by the definition of a UTM.
>
>>
>> Premise(2) (verified fact) 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).
>
> WRONG. You trace is incorrect. If it was a trace of simulation of P(P),
> then we would see the simulation of the machibne H within P. We don't,
> therefore this is NOT the proper trace of the simulation.
>
> FAIL.

Since the question is whether or not H must abort the simulation of P on
the basis of the behavior of P it is utterly incorrect for H to examine
its own behavior. Maybe if I tell you this 150 more times it will start
to sink in and you will get it.

>
> You are applying in invalid transformation to your trace.
>
> You are also trying to now assert not that the FIRST H needs to abort,
> but that SOME H needs to abort and then try to make that satisfy that
> first premise, it doesn't.
>
>>
>> Conclusion(3) From the above true premises it necessarily follows that
>> simulating halt decider H correctly reports that its input: (P,P) never
>> halts.
>
> False Premise, Unsound logic.
>
> FAIL.
>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>>
>>
>>> Your arguemnts are NOT new, but are very similar to many seen over the
>>> decades. You may not see much of them, because failures tend not to get
>>> well published, and you seem to have rejected really looking at through
>>> introductory material that includes the history that shows where the
>>> problems were.
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

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

On 7/2/2021 1:58 AM, David Brown wrote:
> On 02/07/2021 03:52, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/1/2021 6:24 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/1/2021 4:25 PM, olcott wrote:
>>>>>> On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> We can make an undecidable problem by simply phrasing a question such
>>>>>>>> that correct answers are impossible.
>>>>>>>
>>>>>>> But decision problems, of which the halting problem is one, are defined
>>>>>>> as those that always have correct yes/no answers.  Such a problem is
>>>>>>> undecidable if the set of yes instances in not recursive.
>>>> <cut>
>>>>> When the entire set of possible {true, false} Boolean return values
>>>>> from an (input / TM) pair provides an incorrect halting status
>>>> For every finite string, one of true or false is always the correct
>>>> halting status for that string: true if the string represents a halting
>>>> computation, false otherwise.
>>>> Stop fighting this obvious fact and agree to it. You are not talking
>>>> about the halting problem until you do.
>>>>
>>>
>>> Ĥ.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
>>>
>>> In the Peter Linz proof it is commonly understood that neither the
>>> Ĥ.qy (yes it halts) nor the Ĥ.qn (no it does not halt) are the correct
>>> halt status that Ĥ can transition to when Ĥ is applied to ⟨Ĥ⟩ (its own
>>> Turing machine description).
>>
>> I accept that this is your misunderstanding, and it may even be a common
>> misunderstanding, but it is not what the lines from Linz you keep
>> quoting mean. It absolutely does not mean that there is an instance of
>> the halting problem without a correct yes/no answer.
>>
>>> Because you have dodged this question so persistently over the years
>>> by saying that there is a halt status for Ĥ applied to ⟨Ĥ⟩,
>>
>> No. I have never said this. H (as in Linz) does not exist, and neither
>> does H^. There is no string [H^]. The question of whether a TM that
>> does not exist halts when given a non-existent string as its input is
>> too absurd take seriously.
>>
> You know the details of these things better than I, and I am decades out
> of practice. But as I understand it, the whole point of the common
> proof that halting is undecidable is that the assumption that the
> function H is computable leads to the contradiction that Ĥ(Ĥ) is both
> true and false, alternatively that it is neither true nor false. And
> since it must be either true /or/ false (as everything is finite here),
> that cannot be the case. Therefore H could not have been computable.
>
> It seems to me that Olcott's argument is based on assuming H /is/ a real
> computable function, then redefining halting to allow an option of
> "neither halts nor does not halt" to remove the contradiction. Then he
> claims that this means the common proof of halting undecidability is wrong.
>
> Is that a fair summary?
>

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);
}

H determines that P is calling it in infinitely nested simulation, H
aborts its simulation of P on this basis, and then reports that P never
halts. This has no contradiction what-so-ever.

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 7/2/2021 2:16 AM, David Brown wrote:
> On 02/07/2021 05:12, Richard Damon wrote:
>> On 7/1/21 7:44 AM, Andy Walker wrote:
>>> On 01/07/2021 03:34, Richard Damon wrote:
>>>> On 6/30/21 1:15 PM, olcott wrote:
>>>>> The other issue doesn't seem to have much of an alternative. A key part
>>>>> of the problem that allowed the halting problem to continue to exist is
>>>>> that it was only analyzed using Turing machines.
>>>
>>>     There is no essential difference between TMs and real computers.
>>> The only actual difference is that a real computer allows for external
>>> connexions, such as people typing at a keyboard or clicking a mouse, or
>>> a clock interrupt, or a temperature sensor raising an alarm.
>>
>> This is TOTALLY wrong. There is a VERY different 'machinery' used in
>> Turing machines rather than a conventional computer.
>>
>> A Turing Machine is fundamentally a finite state machine tied as it only
>> input/output a tape reader/writer. For each instruction the state
>> machine combines the current state and the symbol at the current
>> location on the tape, and that what the next start will be, what
>> character the tape will be changed to be (or it stays the same) and if
>> and in what direction you move the tape.
>>
>> Your typical modern comupter is a stored program machine where you have
>> a set of registers, one of which is a program counter, for each step the
>> instruction at the location in memory (and possible some of the
>> following locations) is read, decoded, and executed. This instruction
>> will typically provide some manipulation of the registers, perhaps
>> reading other locations of memory for 'input' to an operation or storing
>> the contents of the operation into a location of memory.
>>
>> Note some of the big differences, the Turing Machine doesn't have
>> 'registers', all it has is one blob called the 'state' which is sort of
>> like the program counter, but rather than defaulting to incrementing,
>> every instruction has the capability of an N-way branch. The other big
>> difference is that The conventional computer has 'random' access, it can
>> just reach out to a fairly arbitray location in memory to get a value,
>> and tends to have some registers for short (or longer) term storage.
>>
>
>
> Sorry, but I don't think any of that is correct. The registers, the way
> the state is defined, the ability to modify code - none of that matters
> at all.
>
> You can make a Turing machine that simulates Turing machines. The
> "source" for the simulation will be on the tape, and the "host" Turing
> machine can happily change it under way. You can have a simulator that
> runs through all possible combinations of all possible Turing machines
> with all possible inputs - since everything involved is merely countably
> infinite. (Such a system won't halt, of course.)
>
> You can make a Turing machine that simulates a full modern computer, x86
> or otherwise, if you managed to specify it well enough.
>
>
> There are only two differences between a Turing machine and a modern
> computer. One is that the Turing machine tape is unlimited, while the
> computer is finite - and thus halting is decidable (but impractical) for
> all possible programs running on it.
>
> The other is that Turing machine computations get all their input in
> advance, while it is usual to add input underway in a computer. To
> simulate normal use of a computer, you'd have to include a list of all
> keystrokes, mouse movements, network packets, etc., as part of the input
> to the computation.
>
>
> Another way to realise this is to note that there are no computations
> that can be done on an x86 system or other "real" computer that could
> not also be done on a Turing machine, and vice versa. (The same applies
> to other computation models, such as quantum computers, cellular
> automata, the Unseen University's Hex, and any other computer you imagine.)
>
>
> Whether Olcott's x86 simulator is Turing complete or not is another
> matter, of course. But it certainly can't do anything that a Turing
> machine could not.
>

This is the model of computation that forms a bridge between the x86
language and Turing machines.

https://en.wikipedia.org/wiki/Random-access_stored-program_machine

I even figured out how a machine with relative addressing such as x64
RIP addressing could specify unlimited memory using 64-bit registers.

This is the best bridge between the TM architecture and the Intel
architecture because actual programs could be actually written in
exactly this architecture.

--
Copyright 2021 Pete Olcott

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

On 7/2/2021 10:07 AM, Peter wrote:
> olcott wrote:
>> On 7/2/2021 8:16 AM, Peter wrote:
>>> olcott wrote:
>>>> On 7/1/2021 5:05 PM, Peter wrote:
>>>>> olcott wrote:
>>>>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>>>>> olcott wrote:
>>>>>>>> Because my writing style is not in the ballpark of academic
>>>>>>>> quality [...]
>>>>>>>
>>>>>>> Then fix it.
>>>>>>>
>>>>>>
>>>>>> I didn't know where to begin
>>>>>
>>>>> If you have access to a university library, read journals.  Halmos
>>>>> wrote a paper called 'How to write mathematics' I don't know if
>>>>> it's relevant but someone reading this might.  If you've got time
>>>>> and money do a post graduate degree--
>>>>
>>>> I will literally be dead before then I have stage three cancer.
>>>>
>>>>> not only might you learn how to write mathematics (by imitation)
>>>>> you might also learn that your not as clever as you think you are.
>>>
>>> "you're" not "your".
>>>>
>>>> The easily verifiable fact that there have literally been zero
>>>> errors pointed out in my sound deductive inference in six months
>>>> provides very compelling evidence otherwise.
>>>
>>> Only you are making it impossible for you to become aware of your own
>>> limitations.
>>
>> My proof (sound deductive inference) is correct.
>> Software engineers can verify that it is correct.
>>
>
> But none have.

25 reviews per day by half a dozen reasonably competent reviewers could
not point to a single technical error in any aspect of the ideas
referenced in this paper at any time in the last six months.

Halting problem undecidability and infinitely nested simulation

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

That much of these reviews were entirely based on ad hominem personal
attacks and other forms of mere rhetoric would indicate that they were
biased. That not of them had any technical basis proves that they are
baseless.

--
Copyright 2021 Pete Olcott

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

On 7/2/2021 10:51 AM, Peter wrote:
> olcott wrote:
>> On 7/2/2021 10:07 AM, Peter wrote:
>>> olcott wrote:
>>>> On 7/2/2021 8:16 AM, Peter wrote:
>>>>> olcott wrote:
>>>>>> On 7/1/2021 5:05 PM, Peter wrote:
>>>>>>> olcott wrote:
>>>>>>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>>>>>>> olcott wrote:
>>>>>>>>>> Because my writing style is not in the ballpark of academic
>>>>>>>>>> quality [...]
>>>>>>>>>
>>>>>>>>> Then fix it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I didn't know where to begin
>>>>>>>
>>>>>>> If you have access to a university library, read journals.
>>>>>>> Halmos wrote a paper called 'How to write mathematics' I don't
>>>>>>> know if it's relevant but someone reading this might.  If you've
>>>>>>> got time and money do a post graduate degree--
>>>>>>
>>>>>> I will literally be dead before then I have stage three cancer.
>>>>>>
>>>>>>> not only might you learn how to write mathematics (by imitation)
>>>>>>> you might also learn that your not as clever as you think you are.
>>>>>
>>>>> "you're" not "your".
>>>>>>
>>>>>> The easily verifiable fact that there have literally been zero
>>>>>> errors pointed out in my sound deductive inference in six months
>>>>>> provides very compelling evidence otherwise.
>>>>>
>>>>> Only you are making it impossible for you to become aware of your
>>>>> own limitations.
>>>>
>>>> My proof (sound deductive inference) is correct.
>>>> Software engineers can verify that it is correct.
>>>>
>>>
>>> But none have.
>>
>> 25 reviews per day by half a dozen reasonably competent reviewers
>> could not point to a single technical error in any aspect of the ideas
>> referenced in this paper at any time in the last six months.
>
> You are out of touch with reality.  You claimed that software engineers
> can verify that your "proof" is correct, but what you have just claimed
> is that you have failed to accept any of the criticism you've had.  Do
> you see no difference between those two?

The strongest "proof" that I am incorrect is simply that people really
really don't believe that I am correct, can you see that this form of
"rebuttal" is utterly baseless?

If you think that anyone had a stronger rebuttal then please point to
the date-time stamp and I will show how it is incorrect.

All of the "rebuttals" that actually used reasoning were shown to be
incorrect. Kaz initially thought that H(P,P) did not specify a
computation because H was not a pure function of its inputs. When I
showed how H is a pure function of its inputs Kaz acquiesced.

>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> That much of these reviews were entirely based on ad hominem personal
>> attacks and other forms of mere rhetoric would indicate that they were
>> biased. That not of them had any technical basis proves that they are
>> baseless.
>>
>>
>>
>
>

--
Copyright 2021 Pete Olcott

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

On 7/2/2021 2:02 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/1/2021 8:52 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/1/2021 6:24 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/1/2021 4:25 PM, olcott wrote:
>>>>>>> On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> We can make an undecidable problem by simply phrasing a question such
>>>>>>>>> that correct answers are impossible.
>>>>>>>>
>>>>>>>> But decision problems, of which the halting problem is one, are defined
>>>>>>>> as those that always have correct yes/no answers.  Such a problem is
>>>>>>>> undecidable if the set of yes instances in not recursive.
>>>>> <cut>
>>>>>> When the entire set of possible {true, false} Boolean return values
>>>>>> from an (input / TM) pair provides an incorrect halting status
>>>>> For every finite string, one of true or false is always the correct
>>>>> halting status for that string: true if the string represents a halting
>>>>> computation, false otherwise.
>>>>> Stop fighting this obvious fact and agree to it. You are not talking
>>>>> about the halting problem until you do.
>>>>>
>>>>
>>>> Ĥ.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
>>>>
>>>> In the Peter Linz proof it is commonly understood that neither the
>>>> Ĥ.qy (yes it halts) nor the Ĥ.qn (no it does not halt) are the correct
>>>> halt status that Ĥ can transition to when Ĥ is applied to ⟨Ĥ⟩ (its own
>>>> Turing machine description).
>>> I accept that this is your misunderstanding, and it may even be a common
>>> misunderstanding, but it is not what the lines from Linz you keep
>>> quoting mean. It absolutely does not mean that there is an instance of
>>> the halting problem without a correct yes/no answer.
>>>
>>>> Because you have dodged this question so persistently over the years
>>>> by saying that there is a halt status for Ĥ applied to ⟨Ĥ⟩,
>>> No. I have never said this. H (as in Linz) does not exist, and neither
>>> does H^. There is no string [H^]. The question of whether a TM that
>>> does not exist halts when given a non-existent string as its input is
>>> too absurd take seriously.
>>> For every actual TM, X, there is a correct yes/no answer for all the
>>> halting problem instances involving X. For every TM for which we can
>>> form X^ (which is all of them if we slightly relax the construction) the
>>> same is also true. I.e. for every TM X, the instance <[X^],[X^]> has a
>>> correct yes/no answer because the computation X^([X^]) either halts or
>>> it does not halt. However, X does not give it.
>>
>> What is the specific term-of-the-art for the category of the cases of
>> (TM X / Input I) such that X(I) cannot give the correct answer?
>
> There is none because serious people don't attribute agency to TMs. If
> you ask instead what the term is for inputs I such that X(I) is not the
> correct answer, then these are just called the cases X gets wrong. You
> know that term as well as anyone.
>

So then we are back to my own pathological self-reference(olcott 2004).

>>> This is why your Big Lie of Dec 2018 was considered interesting. You
>>> claimed to have an impossible TM pair, fully encoded. Now you simply
>>> claim to have a TM (or "equivalent") that gets the answer wrong. That
>>> possibility was never in doubt. No one is interested in a TM X that
>>> rejects <[X^],[X^]> despite X^([X^]) being a halting computation.
>
>> It is very disgraceful to the many millions of people that have been
>> murdered by the Nazis (the origin of the term "big lie") for you to
>> use this term in such a cavalier way.
>
> You mean, presumably, disrespectful, but you are quite right. I never
> thought of that. Thank you for point it out. I'll call it your Grand
> Delusion and I'll also mention the dishonest subsequent cover-up. (I
> don't actually think you lied in Dec 2018. You lied afterwards when
> walking back the deluded claim you made.)
>

That the code that I claimed was RASP equivalent rather than an actual
Turing machine is the poetic license that I used when I understood that
it was equivalent to a Turing Machine yet had never yet heard the term
Turing equivalence.

At the point in time I knew that the generic idea of Turing equivalence
was correct yet had no idea that anyone else in the field understood this.

A fully encoded Turing machine is equivalent to a fully encoded RASP
machine which is equivalent to an x86 virtual machine which is
equivalent to the C source code of this x86 virtual machine.

When I pointed out that you already agreed with the one axiom of my
proof (sound deductive inference) and the second premise is easily
verified as an established fact, apparently all that is left to keep up
the ruse of your fake rebuttal is STUTTER.

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

Premise(1) (axiom) 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) (verified fact) 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).

When the simulator is determining whether or not it must abort the
simulation of its input based on the behavior of its input the simulator
must only examine the behavior of its input and must ignore its own
behavior.

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 7/2/2021 5:16 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> That the code that I claimed was RASP equivalent rather than an actual
>> Turing machine is the poetic license that I used when I understood
>> that it was equivalent to a Turing Machine yet had never yet heard the
>> term Turing equivalence.
>
> This is a lie. You said you had two actually turning machines, fully
> encoded, and you knew exactly what that meant when you wrote it.

Yes and I used poetic license because I knew that what I really had was
equivalent to two Turing machines yet did not know that the concept of
"equivalent to Turing machines" was known by anyone besides myself. All
that I have ever previously heard was the term "Turing complete". I had
never heard of anyone every saying "Turing equivalent".

None-the-less this is all moot now. The only reason that you bring it up
it to distract attention away from what I have now. I have shown how an
H and P in the proper halting problem relation <is> a decidable machine
/ input pair with fully operational C / x86 code.

That you cannot stay focused on this point and very persistently try to
distract attention way from this point is flatly dishonest.

If you utterly reverse course on this artificially contrived fake
rebuttal and do the best that you can to help me improve the quality of
my words I can give you some very significant credit for the success of
my work. I could probably call you and Kaz my most important reviewers
in the same way that the authors of academic papers give direct credit
to their top very few reviewers.

> I
> accept you were deluded at the time, but you are lying about the
> subsequent retraction of the claim.
>
> The last 30 months have included many ironies, but one of the most
> striking is that your supposed "solution" is trivial as a pair of actual
> Turing machines! All the months of rowing back the claim with piles of
> OS code, x86 simulation and endless "traces" are not needed. Given that
> you have decided that "reject" (or "no" or "false") is the correct
> answer for the specifically constructed "hat" case you should be able to
> produce the two actual Turing machines, fully encoded. I can!
>
> You argue that no one uses TMs because they are so impractical, but
> every students I have ever taught would be able to write X (and thus X^)
> such that X rejects on input <[X^],[X^]> despite X^ halting on input
> [X^]. Such an X (and therefore X^) is simple to write. Not that you
> could do it, of course, but it is trivial.
>
> All these months of walking back a claim that is, in the light of your
> definition of the correct answer, trivial. If you can't produce the two
> actual Turing machines that behave like this, shame on you.
>

--
Copyright 2021 Pete Olcott

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

On 7/2/2021 6:32 PM, Andy Walker wrote:
> On 02/07/2021 04:12, Richard Damon wrote:
> [I wrote:]
>>>      There is no essential difference between TMs and real computers.
>>> The only actual difference is that a real computer allows for external
>>> connexions, such as people typing at a keyboard or clicking a mouse, or
>>> a clock interrupt, or a temperature sensor raising an alarm.
>> This is TOTALLY wrong.
>
>     No it isn't.  It isn't even SLIGHTLY wrong, as long as your
> real computer is indeed a finite-state machine.  Cf David's reply,
> and see also below.
>
>>              There is a VERY different 'machinery' used in
>> Turing machines rather than a conventional computer.
>
>     The machinery is irrelevant.  What matters is that both a TM
> and a real computer can be described in terms of what happens at each
> CPU cycle [or near equivalent].  Whether this is described as a state
> transition or as some [typically] binary operation on some bits is a
> matter of taste rather than an essential difference.  There is a
> problem in modern computers if some operations complete [eg] in random
> orders or with ill-defined timings, but that's not exactly an advantage
> when discussing the theory, just yet another source of bugs and route
> for malware.
>
>> A Turing Machine is fundamentally a finite state machine tied as it only
>> input/output a tape reader/writer. [...]
>
>     Indeed.
>
>> Your typical modern comupter is a stored program machine where you have
>> a set of registers, one of which is a program counter, for each step the
>> instruction at the location in memory (and possible some of the
>> following locations) is read, decoded, and executed. This instruction
>> will typically provide some manipulation of the registers, perhaps
>> reading other locations of memory for 'input' to an operation or storing
>> the contents of the operation into a location of memory.
>
>     IOW, it's a FSM with the next state depending on the current
> state of the program counter, the registers, etc., etc.
>
>> Note some of the big differences, the Turing Machine doesn't have
>> 'registers', all it has is one blob called the 'state' which is sort of
>> like the program counter, but rather than defaulting to incrementing,
>> every instruction has the capability of an N-way branch. The other big
>> difference is that The conventional computer has 'random' access, it can
>> just reach out to a fairly arbitray location in memory to get a value,
>> and tends to have some registers for short (or longer) term storage.
>
>     Yes, and ...?  All of that is just a state transition.  Yes,
> for a practical modern computer the number of possible states is
> rather large, but that doesn't affect the theory.  How you describe
> the states and their transitions is a matter of taste and convenience,
> not an essential part of the mechanism.
>
>     [Perhaps also worth pointing out that a microcoded computer
> is effectively a relatively small FSM with a relatively large tape
> representing the computer storage, cf a UTM with a tape containing
> the description of the computer being emulated.]
>
> [...]
>> The problem is that when we try to break down A or B which aren't Turing
>> Machines, it is hard to prove that they don't 'hide' state that allows
>> them to give different results for what seems to be the same input.
>
>     My definitions of "A" and "B" were that "A" was a computer
> with all the expected features, such as arithmetic facilities [eg,
> inc floating point, perhaps vector instructions, pipelining, etc]
> whereas "B" was a computer with much more limited instructions, in
> which, eg, multiplication was implemented by repeated addition as
> a software subroutine rather than by hardware.  Note that there
> have been real computer ranges with such variations [esp, eg, with
> FP implemented in software, or with more or less powerful memory
> management instructions].  In the limit, "B" could be a computer
> with the power [only] to increment, decrement and test against
> zero [with an associated jump], yet still be as powerful, in
> terms of its abstract capabilities [tho' obviously not speed],
> as "A".  Whether an actual program running on "A" is "the same
> as" a program running on "B" is just another of life's insoluble
> problems [equivalent to the HP, in general].
>
>>                                     Yes,
>> if you set ALL of memory (including registers and external storage) to
>> be identical, you will get the same results, but it takes a very details
>> look at a routine that might be called several times to confirm that it
>> will always produce the same result for the same input. This is just
>> automatic with a Turing Machine, If the two spots use copies of the same
>> algorithm, and the tape that this algorithm uses is the same, the
>> results must be the same.
>
>     If you run the same TM with the same input tape twice, of
> course you should get the same results.  But again if you have two
> different TMs, deciding whether they are "equivalent" is another
> variation of the HP.
>
> [...]
>> The fact that he can't translate his logic into actual Turing Machines
>> is a strong proof that his concepts don't actually apply to this
>> particular set of problems.
>
>     I think that's a step too far.  Rather, he doesn't understand
> the relationship between TMs and real computers and languages.  Most
> of us here, perhaps all, would be perfectly happy if PO could show
> whatever-he-thinks-is-worth-showing as C programs, rather than as TMs
> or as some weird table of instructions.  But of course what that would
> actually show is that what he has is obvious and has been known from
> the earliest days of the formal theory of computation.
>

It seems to me that any expert software engineer that knows C and the
x86 language can very easily verify that my H / P are in the correct
halting problem relation and H does correctly decide that P does not halt.

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 7/2/2021 6:33 PM, Richard Damon wrote:
> On 7/2/21 10:26 AM, olcott wrote:
>> On 7/2/2021 6:15 AM, Richard Damon wrote:
>>> WRONG. You trace is incorrect. If it was a trace of simulation of P(P),
>>> then we would see the simulation of the machibne H within P. We don't,
>>> therefore this is NOT the proper trace of the simulation.
>>>
>>> FAIL.
>>
>>
>> Since the question is whether or not H must abort the simulation of P on
>> the basis of the behavior of P it is utterly incorrect for H to examine
>> its own behavior. Maybe if I tell you this 150 more times it will start
>> to sink in and you will get it.
>>
>
> No, since the REAL question is whether TURING MACHINE P(P) is halting or
> not, and TURING MACHINE P includes as part of itself that copy of H, the
> behavior of that H is part of the behavior of P, you MUST include it in
> your analysis.

Until the behavior of the input demonstrates an infinite execution
behavior pattern the behavior of H is a pure x86 emulator, thus cannot
possibly have any effect on the behavior of its input.

> Omitting it is like determining the maximum speed of a
> car by just looking at the tires and saying they're the only part that
> touches the road, so we can ignore the rest of the car.
>
> Remember the Theorem you are using is talking about actual Turing
> Machines, and you begin with the argument that as long as you deal with
> equivalents you are ok, well equivalents need to be, like the word says,
> equivalent, so the x86 equivalent to the Turing Machine P needs to
> include everything that was in the Turing Machine P, so its behavior
> needs to include all the behavior or H.
>
> FAIL.
>
> Now, if you are willing to abandon that your proof is about the actual
> Halting Problem of Computation theory, but is only the Olcott must abort
> problem, maybe you can make a point for that.
>

--
Copyright 2021 Pete Olcott

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