On 7/7/2021 4:52 PM, Chris M. Thomasson wrote:
> On 7/7/2021 5:18 AM, Bonita Montero wrote:
>> According to your posting-frequency you're manic.
>
> Yeah, he sure seems to be suffering from some sort of mania, from time
> to time. Humm...
>
>
>> But post only to comp.arch; this is the only appropriate NG.
>> You don't have any C/C++-specific issues and your thoguhts
>> aren't related to AI either.
>

With every few posts my words become increasingly more clear and
undeniably correct. This only happens because of the feedback that I get
for these posts.

If you were Edison on the verge of invented the light bulb you would
probably continue with great vigor until you were done.

My words were clear enough to be understood as correct for months now,
by any expert software engineer highly skilled in C and x86 that was
highly motivated to understand what I am saying.

People that really really want me to be wrong will never acknowledge
that I am correct no matter how clear my words become. That seems to be
most everyone here.

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/7/2021 5:41 PM, wij wrote:
> On Thursday, 8 July 2021 at 06:05:45 UTC+8, olcott wrote:
>> On 7/7/2021 4:52 PM, Chris M. Thomasson wrote:
>>> On 7/7/2021 5:18 AM, Bonita Montero wrote:
>>>> According to your posting-frequency you're manic.
>>>
>>> Yeah, he sure seems to be suffering from some sort of mania, from time
>>> to time. Humm...
>>>
>>>
>>>> But post only to comp.arch; this is the only appropriate NG.
>>>> You don't have any C/C++-specific issues and your thoguhts
>>>> aren't related to AI either.
>>>
>> With every few posts my words become increasingly more clear and
>> undeniably correct. This only happens because of the feedback that I get
>> for these posts.
>>
>> If you were Edison on the verge of invented the light bulb you would
>> probably continue with great vigor until you were done.
>>
>> My words were clear enough to be understood as correct for months now,
>> by any expert software engineer highly skilled in C and x86 that was
>> highly motivated to understand what I am saying.
>>
>> People that really really want me to be wrong will never acknowledge
>> that I am correct no matter how clear my words become. That seems to be
>> most everyone here.
>>
>> 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
>
> I (and many) do wish you are right. But you don't have real proof, that is the fact.
>

I do have sound deductive inference which is a kind of proof.
Mike Terry incorrectly rejected what I have entirely on the basis that
it did not fit the pattern of a mathematical proof.

Premise(1) (Axiom) When the pure simulation of the machine description
⟨P⟩ of a machine P on its input I never halts we know that P(I) never
halts. This can be rephrased as every computation that never halts
unless its simulation is aborted is a computation that never halts.

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.

When the simulator determines whether or not it must abort the
simulation of its input based on the behavior of its input the simulator
only acts as an x86 emulator thus has no effect on the behavior of its
input. This allows the simulator to always ignore its own behavior. H
simply screens out its own address range when making its halt status
decision.

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/7/2021 7:26 PM, Richard Damon wrote:
> On 7/7/21 10:47 AM, olcott wrote:
>> On 7/7/2021 5:46 AM, Ben Bacarisse wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 7/5/21 7:15 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>
>>>>>> Because the above computation must be aborted at some point or it
>>>>>> never halts the above computation is a non-halting computation.
>>>>>
>>>>> It is a halting computation because it halts.  The fact that P(P) halts
>>>>> is not in dispute.
>>>>>
>>>>> Nor is it a matter of dispute that your POOH decider, H, returns H(P,P)
>>>>> == 0 and so P(P) is a non-POOH computation.  The only dispute is that
>>>>> you think someone might be interested in the POOH problem.
>>>>>
>>>>> (For obvious reasons, you resist giving the property you claim H is
>>>>> deciding a proper name.  I'm not entirely sold on "PO Other Halting"
>>>>> but
>>>>> you won't suggest a better alternative.)
>>>>>
>>>>
>>>> I think the name is wrong, his machines don't REALLY deal with Halting,
>>>> so it isn't other Halting, it really should be called Peter Olcott's
>>>> Other Problem.
>>>
>>> Good point.  It's because, in the original description, the halting of
>>> one computation was reported as the halting of another that I went with
>>> that name, but it does, as you say, suggest the wrong meaning for
>>> other.  Your name is better, but I don't want to confuse anyone by
>>> changing.  Maybe PO can choose which he prefers?
>>>
>>
>> H acts as a pure x86 simulator until its input demonstrates non-halting
>> behavior. It is common knowledge that when-so-ever the pure simulation
>> of the machine description of a machine never halts on its input that
>> this logically entails that this machine never halts on its input. This
>> proves that H uses the same halting criteria as the halting problem.
>>
>> Because H acts as a pure simulator of its input until after it makes its
>> halt status decision we know that the behavior of H cannot possibly have
>> any effect on the behavior of P thus the behavior of H can be totally
>> ignored in any halt status decision.
>>
>>
>
> But, as you just admitted, H ISN'T a pure simulator, because is WILL at
> some point possible abort its simulation.
>
> When H abort its simulation, it affect the path of exection of the
> machine that called it,

I am only repeating this a ridiculous number of times because your
mental deficiency requires things to be repeated hundreds of times
before you notice them for the first time:

The behavior of H has no effect on the halt status decision
of H(P,P) because H remains a pure simulator of its input until
after the halt status decision has been made.

The behavior of H has no effect on the halt status decision
of H(P,P) because H remains a pure simulator of its input until
after the halt status decision has been made.

The behavior of H has no effect on the halt status decision
of H(P,P) because H remains a pure simulator of its input until
after the halt status decision has been made.

The behavior of H has no effect on the halt status decision
of H(P,P) because H remains a pure simulator of its input until
after the halt status decision has been made.

The behavior of H has no effect on the halt status decision
of H(P,P) because H remains a pure simulator of its input until
after the halt status decision has been made.

--
Copyright 2021 Pete Olcott

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

On 7/7/2021 7:18 PM, Richard Damon wrote:
> On 7/7/21 5:49 PM, olcott wrote:
>
>> As long as I show how the conventional halting problem counter-example
>> template is correctly decided as non-halting I have refuted these
>> proofs. You are one of two people in this forum that does not understand
>> that.
>>
>
> Except that you haven't proved any such thing, as given an H that does
> abort the Linz H^ template, it is trivial to show that H^ does halt.
>
> PERIOD.
>
> DEFINITION.
>
> END OF ARGUMENT.
>

We know that every black cat is a cat that is black even if this black
cat barks.

[Axiom] When the pure simulation of the machine description ⟨P⟩ of a
machine P on its input I never halts we know that P(I) never halts.

Every input that never halts while the simulating halt decider remains a
pure simulator is an input that never halts.

--
Copyright 2021 Pete Olcott

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

On 7/7/2021 7:17 PM, Richard Damon wrote:
> On 7/7/21 3:51 PM, olcott wrote:
>>
>> No non-halting input can avoid being analyzed by the global (partial)
>> halt decider. Only programs that are input parameters to the local
>> (partial) halt decider H are analyzed by H.
>
> Then you are working in a non-Turing Complete computational environment,
> and thus NONE of your proofs matter, because you don't have REAL Turing
> Machines.

So if the the halt decider is a Universal Turing machine (UTM) that
simulates the execution of its inputs as the basis for its halting
decision then this is not based on a real Turing machine?

Is sounds to me like you are trying to say that some black cats are not
cats that are black.

--
Copyright 2021 Pete Olcott

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

On 7/7/2021 8:45 PM, Richard Damon wrote:
> On 7/7/21 9:24 PM, olcott wrote:
>> On 7/7/2021 7:18 PM, Richard Damon wrote:
>>> On 7/7/21 5:49 PM, olcott wrote:
>>>
>>>> As long as I show how the conventional halting problem counter-example
>>>> template is correctly decided as non-halting I have refuted these
>>>> proofs. You are one of two people in this forum that does not understand
>>>> that.
>>>>
>>>
>>> Except that you haven't proved any such thing, as given an H that does
>>> abort the Linz H^ template, it is trivial to show that H^ does halt.
>>>
>>> PERIOD.
>>>
>>> DEFINITION.
>>>
>>> END OF ARGUMENT.
>>>
>>
>> We know that every black cat is a cat that is black even if this black
>> cat barks.
>
> STRAW MAN.
>>
>> [Axiom] When the pure simulation of the machine description ⟨P⟩ of a
>> machine P on its input I never halts we know that P(I) never halts.
>>
>> Every input that never halts while the simulating halt decider remains a
>> pure simulator is an input that never halts.
>>
>
> But a decider that eventually halts a simulation is NOT a simulator that
> NEVER halts. It doesn't matter that it waits until after it has made its
> decision, the problem is it hasn't waited until after the simulator it
> is simulating has made its decision, and THAT is what really counts.
>

I thought this same thing for three days until I figured out that unless
the current halt decider aborts its input that no halt decider ever will
abort its input.

--
Copyright 2021 Pete Olcott

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

On 7/8/2021 5:56 AM, Richard Damon wrote:
> On 7/7/21 11:03 PM, olcott wrote:
>
>> The behavior of H has no effect on the halt status decision
>> of H(P,P) because H remains a pure simulator of its input until
>> after the halt status decision has been made.
>>
>
> Maybe it doesn't affect the decision that H makes, but it should, as it
> does affect the behavior of P.
>

A pure simulator has no effect on the behavior of its input thus no
effect on its own halt status decision. Only after the simulating halt
decider has already made its halt status decision does it switch to
modes and abort the simulation of its input.

> Can be clearly shown. Create one H that always returns 0, another that
> always return 1
>
> Compare.
>
> Obviously, H affect the behavior of P.
>
> PERIOD.
>
> Obviously your logic is wrong.
>
> Now, maybe the behavior of H doesn't affect what H decides, but then
> THAT is the source of the problem, it should.
>

Pathological self-reference is an error that must be removed.
When studying the effect of an independent variable on a dependent
variable the results are tainted when the dependent variable has any
feedback loop to the independent variable.

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

While H is studying the behavior of P if H has any effect on the
behavior of P the results are tainted.

--
Copyright 2021 Pete Olcott

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

On 7/8/2021 6:02 AM, Richard Damon wrote:
> On 7/7/21 11:04 PM, olcott wrote:
>> On 7/7/2021 9:51 PM, Richard Damon wrote:
>
>>> Because The Halting Problem proof is based on a machine that that can be
>>> given ANY Turing Machine, If you environment happens to disallow certain
>>> machines, and that machine happens to be the machine H^, then you proof
>>> isn't valid.It is quite possible to write a Turing Equivalent machine to
>>> halt decide many different sorts of non-Turing complete systems, so you
>>> aren't really proving anything new.
>>>
>>
>> Where the Hell did you get the idea that this machine disallows any input?
>>
>>
>
> Sine your system does not proper execute any machine that it thinks in
> an infinite behavior,

H does not execute any machines that never halt until they halt because
they never halt.

> These machines don't exist as proper Turing Machines.
>

There is nothing improper about them.

> Particularly since it gets some machines (like H^(H^)) wring.
>
> H^(H^) is EASILY proved to be halting for your H from fundamental
> principles, thus your system is broken.
>

The global halt decider would abort H(⟨Ĥ⟩, ⟨Ĥ⟩) its input before its
input ever reached either final state.

H and the embedded halt decider are both designed to abort their input
as soon as they detect that the pure simulation of their input would
never halt. A global halt decider is always one step ahead of any input.
A local halt decider is sometimes one step behind its input.

The issue of a computation halting even though the halt decider decides
that it never halts is an issue of timing.

The halt decider is only required to get its inputs correctly. If the
later part of a non-halting computation is presented to the halt decider
it does what it is supposed to do and aborts this input.

It can't do anything with the earlier part because the earlier part was
not submitted as input. A global halt decider eliminates this issue.

--
Copyright 2021 Pete Olcott

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

On 7/8/2021 11:07 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> We can know that my halt deciding criteria is the same as the halting
>> problem halt deciding...
>
> We can know it isn't because you said it isn't:
>
> "This maps to every element of the conventional halting problem set of
> non-halting computations *and a few more*." (emphasis mine)
>

My earlier statement is corrected below:

[Axiom] When the pure simulation of the machine description ⟨P⟩ of a
machine P on its input I never halts we know that P(I) never halts.

The second half of above criteria is the same criteria that the
conventional halting problem proofs use. It is known to be
computationally equivalent to the first half.

When we apply the first half of that criteria to the set of halting
computations using a simulating halt decider it decides that they halt.

When we apply the first half of that criteria to the set of non-halting
computations using a simulating halt decider it decides that they do not
halt.

When we apply the first half of that criteria to the set of halting
problem proof counter-example templates using a simulating halt decider
it decides that they do not halt.

--
Copyright 2021 Pete Olcott

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

On 7/8/2021 5:52 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/8/2021 11:07 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> We can know that my halt deciding criteria is the same as the halting
>>>> problem halt deciding...
>>> We can know it isn't because you said it isn't:
>>> "This maps to every element of the conventional halting problem set of
>>> non-halting computations *and a few more*." (emphasis mine)
>>
>> My earlier statement is corrected below:
>
> So right up until a few days ago you knew your "adapted" criterion
> defined different accept and reject set to the halting problem and you
> were just pretending they were the same.
>

The words have continually gotten clearer in my mind.

[Halt Deciding Axiom] When the pure simulation of the machine
description ⟨P⟩ of a machine P on its input I never halts we know that
P(I) never halts. Every input that never halts while the simulating halt
decider remains a pure simulator is an input that never halts.

A non-halting input is an input that would never halt without
interference by the simulating halt decider. If the halt decider merely
watches what the input program does and can see that it will never halt,
then it can stop simulating this input and report that it never halts.

The key thing here is that the pathological self-reference(olcott 2004)
is eliminated from the halting problem when the simulating halt decider
simply watches what its input does without any interference
what-so-ever. When the simulating halt decider does this then it can
ignore its own behavior in its halt status analysis, thus eliminating
the confounding feedback loop.

Halting Problem Final Conclusion
Peter Olcott Sep 5, 2004, 11:21:57 AM

The Liar Paradox can be shown to be nothing more than
a incorrectly formed statement because of its pathological
self-reference. The Halting Problem can only exist because
of this same sort of pathological self-reference.
https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

> But now the two criteria (yours and halting) really do define exactly
> the same sets, yes? So we can just forget about all your fiddly
> definitions using simulations and waffle and use the usual criterion,
> yes? I'd really like a non-waffle answer to this. If your halting is
> now what the world means by halting you need to say so.
>
> So rather than being right about the POOH problem you are just wrong
> about halting, right? Do you now, after more than 20 years, accept that
> every input to the halting problem has a correct yes/no answer and that
> yes is the correct answer only for those inputs that represent halting
> computations, and no is the correct answer for the rest?
>
> (Expecting a direct answer to any of these questions is the triumph of
> hope over experience.)
>

--
Copyright 2021 Pete Olcott

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

On 7/8/2021 8:48 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/8/2021 5:52 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/8/2021 11:07 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> We can know that my halt deciding criteria is the same as the halting
>>>>>> problem halt deciding...
>>>>> We can know it isn't because you said it isn't:
>>>>> "This maps to every element of the conventional halting problem set of
>>>>> non-halting computations *and a few more*." (emphasis mine)
>>>>
>>>> My earlier statement is corrected below:
>>> So right up until a few days ago you knew your "adapted" criterion
>>> defined different accept and reject set to the halting problem and you
>>> were just pretending they were the same.
>>
>> The words have continually gotten clearer in my mind.
>
> So you have not changed the meaning, only clarified the expression. The
> two criteria, yours and halting, do define different accept/reject sets
> as you said explicitly in the quote I posted.
>

[Halt Deciding Axiom] When the pure simulation of the machine
description ⟨P⟩ of a machine P on its input I never halts we know that
P(I) never halts. This is a conventional axiom.

When the simulating halt decider has detected that the pure simulation
of its input ⟨P⟩ never halts on its input I it has detected an instance
an input that never halts according to the above purely conventional axiom.

> So which of your statements is the one you want to stand by?
>
> "We can know that my halt deciding criteria is the same as the halting
> problem"
>
> or
>
> "This maps to every element of the conventional halting problem set of
> non-halting computations and a few more."
>
> It should be obvious to others why this is the fence you are sitting on.
> Is it comfy?
>
The first one. When we apply the conventional halt deciding criteria to
the halting problem counter-example templates using a simulating halt
decider, the simulating halt decider can correctly decide halting on
these inputs because it can totally ignore its own behavior while it
acts as a pure simulator, thus eliminating the pathological
self-reference(Olcott 2004) from the halting problem.

comp.theory Peter Olcott Sep 5, 2004, 11:21:57 AM
[Halting Problem Final Conclusion]
The Liar Paradox can be shown to be nothing more than
a incorrectly formed statement because of its pathological
self-reference. The Halting Problem can only exist because
of this same sort of pathological self-reference.
https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

17 years later I am finally getting around to finishing this.

You have been talking to me far longer than anyone else, since 2006:

[Re: A Possible "solution" to the Halting Problem]
On 10/17/2006 7:03 PM, Ben Bacarisse wrote:
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:

--
Copyright 2021 Pete Olcott

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

On 7/8/2021 9:21 PM, olcott wrote:
> On 7/8/2021 8:48 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/8/2021 5:52 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/8/2021 11:07 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> We can know that my halt deciding criteria is the same as the
>>>>>>> halting
>>>>>>> problem halt deciding...
>>>>>> We can know it isn't because you said it isn't:
>>>>>>      "This maps to every element of the conventional halting
>>>>>> problem set of
>>>>>>      non-halting computations *and a few more*."  (emphasis mine)
>>>>>
>>>>> My earlier statement is corrected below:
>>>> So right up until a few days ago you knew your "adapted" criterion
>>>> defined different accept and reject set to the halting problem and you
>>>> were just pretending they were the same.
>>>
>>> The words have continually gotten clearer in my mind.
>>
>> So you have not changed the meaning, only clarified the expression.  The
>> two criteria, yours and halting, do define different accept/reject sets
>> as you said explicitly in the quote I posted.
>>
>
> [Halt Deciding Axiom] When the pure simulation of the machine
> description ⟨P⟩ of a machine P on its input I never halts we know that
> P(I) never halts. This is a conventional axiom.
>
> When the simulating halt decider has detected that the pure simulation
> of its input ⟨P⟩ never halts on its input I it has detected an instance
> an input that never halts according to the above purely conventional axiom.
>
>> So which of your statements is the one you want to stand by?
>>
>>    "We can know that my halt deciding criteria is the same as the halting
>>    problem"
>>
>> or
>>
>>    "This maps to every element of the conventional halting problem set of
>>    non-halting computations and a few more."
>>
>> It should be obvious to others why this is the fence you are sitting on.
>> Is it comfy?
>>
> The first one. When we apply the conventional halt deciding criteria to
> the halting problem counter-example templates using a simulating halt
> decider, the simulating halt decider can correctly decide halting on
> these inputs because it can totally ignore its own behavior while it
> acts as a pure simulator, thus eliminating the pathological
> self-reference(Olcott 2004) from the halting problem.
>
> comp.theory Peter Olcott  Sep 5, 2004, 11:21:57 AM
> [Halting Problem Final Conclusion]
> The Liar Paradox can be shown to be nothing more than
> a incorrectly formed statement because of its pathological
> self-reference. The Halting Problem can only exist because
> of this same sort of pathological self-reference.
> https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ
>
> 17 years later I am finally getting around to finishing this.
>
> You have been talking to me far longer than anyone else, since 2006:
>
> [Re: A Possible "solution" to the Halting Problem]
> On 10/17/2006 7:03 PM, Ben Bacarisse wrote:
> > "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>
>

To eliminate the pathological self-reference(Olcott 2004) from the
halting problem such that there is no feedback loop between what the
halt decider decides and how the input behaves the simulating halt
decider simply watches what the input does without interfering at all.

As soon as the simulating halt decider determines that the simulation of
the input on its input would never halt (the conventional definition of
non-halting) it aborts the simulation of its inputs and reports that its
input does not halt.

--
Copyright 2021 Pete Olcott

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

On 7/8/2021 10:39 PM, Richard Damon wrote:
> On 7/8/21 8:46 AM, olcott wrote:
>> On 7/8/2021 5:56 AM, Richard Damon wrote:
>>> On 7/7/21 11:03 PM, olcott wrote:
>>>
>>>> The behavior of H has no effect on the halt status decision
>>>> of H(P,P) because H remains a pure simulator of its input until
>>>> after the halt status decision has been made.
>>>>
>>>
>>> Maybe it doesn't affect the decision that H makes, but it should, as it
>>> does affect the behavior of P.
>>>
>>
>> A pure simulator has no effect on the behavior of its input thus no
>> effect on its own halt status decision. Only after the simulating halt
>> decider has already made its halt status decision does it switch to
>> modes and abort the simulation of its input.
>
> Except the copy of H you are simulating WILL affect the program that
> called it that you are also simulating, so you need to simulate it until
> it makes its decision. You keep on conflating the simulator with the
> program it is simulting.
>

The behavior of the simulating halt decider cannot possibly have any
effect on its halt status decision because it always makes sure to
ignore every machine address of its own address range while it is making
its halt status decision.

Every invocation of H in the nested simulation chain can totally ignore
the behavior of every H while every invocation of H is only acting as a
pure simulator.

To eliminate the pathological self-reference(Olcott 2004) from the
halting problem such that there is no feedback loop between what the
halt decider decides and how the input behaves the simulating halt
decider simply watches what the input does without interfering at all.

If the simulating halt decider's behavior cannot possibly have any
effect on the behavior of its input then its input cannot possibly do
the opposite of whatever the halt decider decides thus eliminating the
halting problem paradox.

>>
>>> Can be clearly shown. Create one H that always returns 0, another that
>>> always return 1
>>>
>>> Compare.
>>>
>>> Obviously, H affect the behavior of P.
>>>
>>> PERIOD.
>>>
>>> Obviously your logic is wrong.
>>>
>>> Now, maybe the behavior of H doesn't affect what H decides, but then
>>> THAT is the source of the problem, it should.
>>>
>>
>> Pathological self-reference is an error that must be removed.
>> When studying the effect of an independent variable on a dependent
>> variable the results are tainted when the dependent variable has any
>> feedback loop to the independent variable.
>
> WHY? What is wrong with self reference? You seem to have your variables
> backwards. The algorithm of H is your independent variable, and there is
> no feedback loop that changes that algorithm. By varing that you see
> what answers H gives and what P does. Neither of these feedback to
> change your alogirthm of H except as you work to try to 'optimize' the
> answer to be more right.
>
>>
>> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>>
>> While H is studying the behavior of P if H has any effect on the
>> behavior of P the results are tainted.
>>
>
> But P is BY DEFINITION a function of H if you use the Linz construction,
> so that means you have chosen a wrong method.
>

--
Copyright 2021 Pete Olcott

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

On 7/9/2021 6:30 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/8/2021 8:48 PM, Ben Bacarisse wrote:
>
>>> So which of your statements is the one you want to stand by?
>>>
>>> "We can know that my halt deciding criteria is the same as the halting
>>> problem"
>>> or
>>> "This maps to every element of the conventional halting problem set of
>>> non-halting computations and a few more."
>>>
>>> It should be obvious to others why this is the fence you are sitting on.
>>> Is it comfy?
>>>
>> The first one.
>
> Thank you. Your directness make me hopeful that you'll be clear about
> some other things... How long have you though that "and a few more" was
> correct? I.e. how long have you been arguing for a position you now
> concede is mistaken? Months? Years? Decades?
>

I have only been trying to specifically define the set that are involved
for a few days. comp.theory gets all of my newest material before I put
it in my paper.

> You have refused to accept the definition of the halting problem for
> decades. Do you now accept that every string has a correct yes/no
> answer as far as halting is concerned, and that "yes" is the correct
> answer for those strings that represent halting computations and "no" is
> the correct answer for all the others?
>

The question: What Boolean value can H return to P representing the
correct halt status of P(P) in this computation has no correct answer:

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

You always consistently twist these words to say something else entirely
knowing full well that you twist these words.

In the same way that the Liar Paradox contradicts its own truth value
the halting problem counter-example templates contradict the return
value of some programs that would otherwise be halt deciders.

The Liar Paradox and the halting problem counter example templates have
the exact same pathological self-reference(Olcott 2004) error.

comp.theory Peter Olcott Sep 5, 2004, 11:21:57 AM
[Halting Problem Final Conclusion]
The Liar Paradox can be shown to be nothing more than
a incorrectly formed statement because of its pathological
self-reference. The Halting Problem can only exist because
of this same sort of pathological self-reference.
https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

> And since we now know that your "halt deciding criteria is the same as
> the halting problem" we can ditch all the waffle about simulation. It's
> just halting as conventionally defined.
>

[Halt Deciding Axiom] When the pure simulation of the machine
description ⟨P⟩ of a machine P on its input I never halts we know that
P(I) never halts.

No we cannot. In order to remove the pathological feedback loop such
that P does the opposite of whatever H decides H simply acts as a pure
simulator of P thus having no effect what-so-ever on the behavior of P
until after its halt status decision has been made.

H then aborts its simulation of P before ever returning any value to P
because every function called in infinite recursion or infinitely nested
simulation never returns to this caller.

> Your favourite book, and your favourite quoted lines from it, make it
> quite clear that halting computations like P(P) need to be accepted not
> rejected. P(P) halts, but H(P,P) == 0 which is wrong. So what have you
> now after all this time except a huge mistake?
>

Because the pure simulation of P(P) never halts this proves that P(P)
meets the conventional definition of a computation that never halts.

--
Copyright 2021 Pete Olcott

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

On 7/9/2021 4:53 AM, Richard Damon wrote:
> On 7/9/21 12:27 AM, olcott wrote:
>> On 7/8/2021 11:05 PM, Richard Damon wrote:
>>> On 7/8/21 9:29 AM, olcott wrote:
>>>> On 7/8/2021 6:02 AM, Richard Damon wrote:
>>>>> On 7/7/21 11:04 PM, olcott wrote:
>>>>>> On 7/7/2021 9:51 PM, Richard Damon wrote:
>>>>>
>>>>>>> Because The Halting Problem proof is based on a machine that that
>>>>>>> can be
>>>>>>> given ANY Turing Machine, If you environment happens to disallow
>>>>>>> certain
>>>>>>> machines, and that machine happens to be the machine H^, then you
>>>>>>> proof
>>>>>>> isn't valid.It is quite possible to write a Turing Equivalent
>>>>>>> machine to
>>>>>>> halt decide many different sorts of non-Turing complete systems,
>>>>>>> so you
>>>>>>> aren't really proving anything new.
>>>>>>>
>>>>>>
>>>>>> Where the Hell did you get the idea that this machine disallows any
>>>>>> input?
>>>>>>
>>>>>>
>>>>>
>>>>> Sine your system does not proper execute any machine that it thinks in
>>>>> an infinite behavior,
>>>>
>>>> H does not execute any machines that never halt until they halt because
>>>> they never halt.
>>>>
>>>>> These machines don't exist as proper Turing Machines.
>>>>>
>>>>
>>>> There is nothing improper about them.
>>>>
>>>>> Particularly since it gets some machines (like H^(H^)) wring.
>>>>>
>>>>> H^(H^) is EASILY proved to be halting for your H from fundamental
>>>>> principles, thus your system is broken.
>>>>>
>>>>
>>>> The global halt decider would abort H(⟨Ĥ⟩, ⟨Ĥ⟩) its input before its
>>>> input ever reached either final state.
>>>
>>> And thus your system can not be used to figure out if H is correct or
>>> not, because it stops the machine before the answer is REALLY proven.
>>>
>>>>
>>>> H and the embedded halt decider are both designed to abort their input
>>>> as soon as they detect that the pure simulation of their input would
>>>> never halt. A global halt decider is always one step ahead of any input.
>>>> A local halt decider is sometimes one step behind its input.
>>>>
>>>> The issue of a computation halting even though the halt decider decides
>>>> that it never halts is an issue of timing.
>>>>
>>>> The halt decider is only required to get its inputs correctly. If the
>>>> later part of a non-halting computation is presented to the halt decider
>>>> it does what it is supposed to do and aborts this input.
>>>>
>>>> It can't do anything with the earlier part because the earlier part was
>>>> not submitted as input. A global halt decider eliminates this issue.
>>>>
>>>
>>> Right, The global decider says that a machine that WOULD come to a HALT
>>> if let run, gets aborted and not allowed to finish, thus it is WRONG, as
>>> the computation is REALLY HALTING, because if given enough (but still a
>>> finite number) of step, it would halt.
>>>
>>
>> I can discard the global halt deicider again.
>>
> It has ALWAYS been a failure, because it immediately make your system
> unsuitable for your proof.
>
> Removing it doesn't make your statement right, but at least you start
> with something you can talk about being able to run Turing Machine
> Equivalents.
>
> Without the Global Halt Decider, we can talk about what P(P) actually
> does, which is a required part of the proof, since that is what the
> question is about.
>

[Halt Deciding Axiom] When the pure simulation of the machine
description ⟨P⟩ of a machine P on its input I never halts we know that
P(I) never halts.

Because the pure simulation of P(P) never halts this proves that P(P)
meets the conventional definition of a computation that never halts.

--
Copyright 2021 Pete Olcott

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

On Fri, 9 Jul 2021 08:59:51 -0500
olcott <NoOne@NoWhere.com> wrote:
> [Halt Deciding Axiom] When the pure simulation of the machine
> description ⟨P⟩ of a machine P on its input I never halts we know
> that P(I) never halts.
>
> No we cannot. In order to remove the pathological feedback loop such
> that P does the opposite of whatever H decides H simply acts as a
> pure simulator of P thus having no effect what-so-ever on the
> behavior of P until after its halt status decision has been made.

Except your decider can only handle trivial uninteresting cases: if you
wish to make progress on this then prove your decider works with a
non-trivial case which includes branching logic predicated on arbitrary
program input that is unknown a priori to the simulation starting; but
before you even do that prove your decider works with a non-trivial
case with branching logic predicated on arbitrary program input that
*is* known a priori.

I also note that you repeatedly refuse to address my point regarding how
x86 mov instructions can read/write from/to memory mapped I/O
rather than RAM so the result of the mov instruction cannot be known a
priori. The halting program concerns computing devices and a computing
device which cannot do I/O is next to useless, much like your decider
(until you actually prove otherwise which I have a feeling is never
going to happen as you appear to be stuck in a loop).

/Flibble

On 7/9/2021 12:06 PM, Mr Flibble wrote:
> On Fri, 9 Jul 2021 08:59:51 -0500
> olcott <NoOne@NoWhere.com> wrote:
>> [Halt Deciding Axiom] When the pure simulation of the machine
>> description ⟨P⟩ of a machine P on its input I never halts we know
>> that P(I) never halts.
>>
>> No we cannot. In order to remove the pathological feedback loop such
>> that P does the opposite of whatever H decides H simply acts as a
>> pure simulator of P thus having no effect what-so-ever on the
>> behavior of P until after its halt status decision has been made.
>
> Except your decider can only handle trivial uninteresting cases: if you
> wish to make progress on this then prove your decider works with a
> non-trivial case which includes branching logic predicated on arbitrary
> program input that is unknown a priori to the simulation starting; but
> before you even do that prove your decider works with a non-trivial
> case with branching logic predicated on arbitrary program input that
> *is* known a priori.
>

You continue to prove to everyone that actually knows these things that
you are an ignoramus on this subject.

That H correctly decides that all of the standard counter-examples
templates never halt eliminates the entire basis of all of the
conventional halting problem undecidability proofs.

> I also note that you repeatedly refuse to address my point regarding how
> x86 mov instructions can read/write from/to memory mapped I/O
> rather than RAM so the result of the mov instruction cannot be known a
> priori. The halting program concerns computing devices and a computing
> device which cannot do I/O is next to useless, much like your decider
> (until you actually prove otherwise which I have a feeling is never
> going to happen as you appear to be stuck in a loop).
>
> /Flibble
>

--
Copyright 2021 Pete Olcott

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

On Fri, 9 Jul 2021 12:47:12 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/9/2021 12:06 PM, Mr Flibble wrote:
> > On Fri, 9 Jul 2021 08:59:51 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >> [Halt Deciding Axiom] When the pure simulation of the machine
> >> description ⟨P⟩ of a machine P on its input I never halts we know
> >> that P(I) never halts.
> >>
> >> No we cannot. In order to remove the pathological feedback loop
> >> such that P does the opposite of whatever H decides H simply acts
> >> as a pure simulator of P thus having no effect what-so-ever on the
> >> behavior of P until after its halt status decision has been made.
> >
> > Except your decider can only handle trivial uninteresting cases: if
> > you wish to make progress on this then prove your decider works
> > with a non-trivial case which includes branching logic predicated
> > on arbitrary program input that is unknown a priori to the
> > simulation starting; but before you even do that prove your decider
> > works with a non-trivial case with branching logic predicated on
> > arbitrary program input that *is* known a priori.
> >
>
> You continue to prove to everyone that actually knows these things
> that you are an ignoramus on this subject.
>
> That H correctly decides that all of the standard counter-examples
> templates never halt eliminates the entire basis of all of the
> conventional halting problem undecidability proofs.
>
> > I also note that you repeatedly refuse to address my point
> > regarding how x86 mov instructions can read/write from/to memory
> > mapped I/O rather than RAM so the result of the mov instruction
> > cannot be known a priori. The halting program concerns computing
> > devices and a computing device which cannot do I/O is next to
> > useless, much like your decider (until you actually prove otherwise
> > which I have a feeling is never going to happen as you appear to be
> > stuck in a loop).
> >
> > /Flibble
> >
>
>

I continue to note that you repeatedly refuse to address my point
regarding how x86 mov instructions can read/write from/to memory mapped
I/O rather than RAM so the result of the mov instruction cannot be
known a priori. The halting program concerns computing devices and a
computing device which cannot do I/O is next to useless, much like your
decider (until you actually prove otherwise which I have a feeling is
never going to happen as you appear to be stuck in a loop).

/Flibble

On 7/9/2021 2:16 PM, Mr Flibble wrote:
> On Fri, 9 Jul 2021 12:47:12 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/9/2021 12:06 PM, Mr Flibble wrote:
>>> On Fri, 9 Jul 2021 08:59:51 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>> [Halt Deciding Axiom] When the pure simulation of the machine
>>>> description ⟨P⟩ of a machine P on its input I never halts we know
>>>> that P(I) never halts.
>>>>
>>>> No we cannot. In order to remove the pathological feedback loop
>>>> such that P does the opposite of whatever H decides H simply acts
>>>> as a pure simulator of P thus having no effect what-so-ever on the
>>>> behavior of P until after its halt status decision has been made.
>>>
>>> Except your decider can only handle trivial uninteresting cases: if
>>> you wish to make progress on this then prove your decider works
>>> with a non-trivial case which includes branching logic predicated
>>> on arbitrary program input that is unknown a priori to the
>>> simulation starting; but before you even do that prove your decider
>>> works with a non-trivial case with branching logic predicated on
>>> arbitrary program input that *is* known a priori.
>>>
>>
>> You continue to prove to everyone that actually knows these things
>> that you are an ignoramus on this subject.
>>
>> That H correctly decides that all of the standard counter-examples
>> templates never halt eliminates the entire basis of all of the
>> conventional halting problem undecidability proofs.
>>
>>> I also note that you repeatedly refuse to address my point
>>> regarding how x86 mov instructions can read/write from/to memory
>>> mapped I/O rather than RAM so the result of the mov instruction
>>> cannot be known a priori. The halting program concerns computing
>>> devices and a computing device which cannot do I/O is next to
>>> useless, much like your decider (until you actually prove otherwise
>>> which I have a feeling is never going to happen as you appear to be
>>> stuck in a loop).
>>>
>>> /Flibble
>>>
>>
>>
>
> I continue to note that you repeatedly refuse to address my point
> regarding how x86 mov instructions can read/write from/to memory mapped
> I/O rather than RAM so the result of the mov instruction cannot be
> known a priori. The halting program concerns computing devices and a
> computing device which cannot do I/O is next to useless, much like your
> decider (until you actually prove otherwise which I have a feeling is
> never going to happen as you appear to be stuck in a loop).
>
> /Flibble
>

You are the only one that believes that your points have any relevance.
That you believe that data movement instructions have anything to do
with control flow proves that your points have no relevance.

--
Copyright 2021 Pete Olcott

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

On Fri, 9 Jul 2021 14:24:33 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/9/2021 2:16 PM, Mr Flibble wrote:
> > On Fri, 9 Jul 2021 12:47:12 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/9/2021 12:06 PM, Mr Flibble wrote:
> >>> On Fri, 9 Jul 2021 08:59:51 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>> [Halt Deciding Axiom] When the pure simulation of the machine
> >>>> description ⟨P⟩ of a machine P on its input I never halts we know
> >>>> that P(I) never halts.
> >>>>
> >>>> No we cannot. In order to remove the pathological feedback loop
> >>>> such that P does the opposite of whatever H decides H simply acts
> >>>> as a pure simulator of P thus having no effect what-so-ever on
> >>>> the behavior of P until after its halt status decision has been
> >>>> made.
> >>>
> >>> Except your decider can only handle trivial uninteresting cases:
> >>> if you wish to make progress on this then prove your decider works
> >>> with a non-trivial case which includes branching logic predicated
> >>> on arbitrary program input that is unknown a priori to the
> >>> simulation starting; but before you even do that prove your
> >>> decider works with a non-trivial case with branching logic
> >>> predicated on arbitrary program input that *is* known a priori.
> >>>
> >>
> >> You continue to prove to everyone that actually knows these things
> >> that you are an ignoramus on this subject.
> >>
> >> That H correctly decides that all of the standard counter-examples
> >> templates never halt eliminates the entire basis of all of the
> >> conventional halting problem undecidability proofs.
> >>
> >>> I also note that you repeatedly refuse to address my point
> >>> regarding how x86 mov instructions can read/write from/to memory
> >>> mapped I/O rather than RAM so the result of the mov instruction
> >>> cannot be known a priori. The halting program concerns computing
> >>> devices and a computing device which cannot do I/O is next to
> >>> useless, much like your decider (until you actually prove
> >>> otherwise which I have a feeling is never going to happen as you
> >>> appear to be stuck in a loop).
> >>>
> >>> /Flibble
> >>>
> >>
> >>
> >
> > I continue to note that you repeatedly refuse to address my point
> > regarding how x86 mov instructions can read/write from/to memory
> > mapped I/O rather than RAM so the result of the mov instruction
> > cannot be known a priori. The halting program concerns computing
> > devices and a computing device which cannot do I/O is next to
> > useless, much like your decider (until you actually prove otherwise
> > which I have a feeling is never going to happen as you appear to be
> > stuck in a loop).
> >
> > /Flibble
> >
>
> You are the only one that believes that your points have any
> relevance. That you believe that data movement instructions have
> anything to do with control flow proves that your points have no
> relevance.
You literally have no clue about what you are talking about,
whatsoever. This explains everything.

/Flibble

On 7/9/2021 4:08 PM, Mr Flibble wrote:
> On Fri, 9 Jul 2021 14:24:33 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/9/2021 2:16 PM, Mr Flibble wrote:
>>> On Fri, 9 Jul 2021 12:47:12 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/9/2021 12:06 PM, Mr Flibble wrote:
>>>>> On Fri, 9 Jul 2021 08:59:51 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>> [Halt Deciding Axiom] When the pure simulation of the machine
>>>>>> description ⟨P⟩ of a machine P on its input I never halts we know
>>>>>> that P(I) never halts.
>>>>>>
>>>>>> No we cannot. In order to remove the pathological feedback loop
>>>>>> such that P does the opposite of whatever H decides H simply acts
>>>>>> as a pure simulator of P thus having no effect what-so-ever on
>>>>>> the behavior of P until after its halt status decision has been
>>>>>> made.
>>>>>
>>>>> Except your decider can only handle trivial uninteresting cases:
>>>>> if you wish to make progress on this then prove your decider works
>>>>> with a non-trivial case which includes branching logic predicated
>>>>> on arbitrary program input that is unknown a priori to the
>>>>> simulation starting; but before you even do that prove your
>>>>> decider works with a non-trivial case with branching logic
>>>>> predicated on arbitrary program input that *is* known a priori.
>>>>>
>>>>
>>>> You continue to prove to everyone that actually knows these things
>>>> that you are an ignoramus on this subject.
>>>>
>>>> That H correctly decides that all of the standard counter-examples
>>>> templates never halt eliminates the entire basis of all of the
>>>> conventional halting problem undecidability proofs.
>>>>
>>>>> I also note that you repeatedly refuse to address my point
>>>>> regarding how x86 mov instructions can read/write from/to memory
>>>>> mapped I/O rather than RAM so the result of the mov instruction
>>>>> cannot be known a priori. The halting program concerns computing
>>>>> devices and a computing device which cannot do I/O is next to
>>>>> useless, much like your decider (until you actually prove
>>>>> otherwise which I have a feeling is never going to happen as you
>>>>> appear to be stuck in a loop).
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>>
>>>
>>> I continue to note that you repeatedly refuse to address my point
>>> regarding how x86 mov instructions can read/write from/to memory
>>> mapped I/O rather than RAM so the result of the mov instruction
>>> cannot be known a priori. The halting program concerns computing
>>> devices and a computing device which cannot do I/O is next to
>>> useless, much like your decider (until you actually prove otherwise
>>> which I have a feeling is never going to happen as you appear to be
>>> stuck in a loop).
>>>
>>> /Flibble
>>>
>>
>> You are the only one that believes that your points have any
>> relevance. That you believe that data movement instructions have
>> anything to do with control flow proves that your points have no
>> relevance.
>
> You literally have no clue about what you are talking about,
> whatsoever. This explains everything.
>
> /Flibble
>

*Make sure that you read all of this especially the last line*

halt (p, i)
{ if ( program p halts on input i )
return true ; // p halts
else
return false ; // p doesn’t halt
} Fig. 1. Pseudocode of the Halting Function

Strachey’s Impossible Program Strachey proposed a program
based on the result of an assumed halting function [2].
The way Strachey’s construction and other similar constructions
are used to show the impossibility of a decideable halting
function is quite similar to Turing’s original disproof.
But the relevant difference we want to emphasize is that
they do not explicitly assume an infinite number of possible
machines (programs) or input data, because they directly use
reductio ad absurdum to prove that both, Strachey’s construction
and the universal halting function cannot exist.

strachey ( p )
{ if ( halt (p, p) == true )
L1 : goto L1 ; // loop forever
else
return;
}

Fig. 2. Strachey’s Impossible Program

The impossibility of Strachey’s construction given in Figure 2 becomes
obvious if one tries to apply the halting function as follows:

halt(strachey, strachey)

Since in this case strachey() itself calls halt(strachey, strachey),
it is required that the direct call of halt() and the nested call
provide the same result. However, this leads to a contradiction,
whatever result halt() returns. Within this disproof there seems
to be no indication why not it could be even applied to finite-state
systems having a concrete upper bound of state space.

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.1468&rep=rep1&type=pdf

--
Copyright 2021 Pete Olcott

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

On 7/9/2021 4:59 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/9/2021 6:30 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/8/2021 8:48 PM, Ben Bacarisse wrote:
>>>
>>>>> So which of your statements is the one you want to stand by?
>>>>>
>>>>> "We can know that my halt deciding criteria is the same as the halting
>>>>> problem"
>>>>> or
>>>>> "This maps to every element of the conventional halting problem set of
>>>>> non-halting computations and a few more."
>>>>>
>>>>> It should be obvious to others why this is the fence you are sitting on.
>>>>> Is it comfy?
>>>>>
>>>> The first one.
>>> Thank you. Your directness make me hopeful that you'll be clear about
>>> some other things... How long have you though that "and a few more" was
>>> correct? I.e. how long have you been arguing for a position you now
>>> concede is mistaken? Months? Years? Decades?
>>
>> I have only been trying to specifically define the set that are
>> involved for a few days.
>
> I wrote something about this but deleted it since it turns out, further
> down, you are still sitting on the fence.
>
>>> You have refused to accept the definition of the halting problem for
>>> decades. Do you now accept that every string has a correct yes/no
>>> answer as far as halting is concerned, and that "yes" is the correct
>>> answer for those strings that represent halting computations and "no" is
>>> the correct answer for all the others?
>>
>> The question: What Boolean value can H return to P representing the
>> correct halt status of P(P) in this computation has no correct answer:
>
> You seem to think that because every H gets at least one case wrong (the
> one designed to confound it) that this means that there is no correct
> answer to every halting instance. That is wrong, and until you realise
> that, you are not going to make any progress.
>
> For any two-argument Boolean function H, there is a corresponding
> function hat(H). The computation hat(H)(hat(H)) either halts or it does
> not, so that computation has a correct answer as to its halting. The
> fact that no H gives the right answer for its own personal Nemesis,
> hat(H)(hat(H)), does not mean there isn't one in every single case.
>
> We even know what it is for your H (despite the fact that you a
> studiously hiding the code), because you have stated, and posted a trace
> showing, what actually happens! P (your current name for the 'hat'
> version of H) halts when passed P. This is why H(P,P) == 0 is wrong.
>
>> // 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);
>> }
>>
>> You always consistently twist these words to say something else
>> entirely knowing full well that you twist these words.
>
> You are correctly explaining that H is wrong about P(P). How can it be
> put any more simply?

The reason that H cannot return the correct halt status to P is that
this TM / input pair was intentionally modeled on the basis of the liar
paradox.

The liar paradox is not a truth bearer because it is self-contradictory.
Any expression of formal or natural language that is not a truth bearer
has no associated Boolean value.

The halting problem counter-example (prior to my insights) had no
associated Boolean value specifically because most of the details are
always unspecified.

When we ask the specific question: What correct value of {true, false}
can H correctly return to P that indicates the actual halt status of P?

(The answer is restricted to Boolean, the answer of "neither" is not
allowed).

This 100% specific question <is> as I have always said exactly the same
type mismatch error as asking the question: What time is it (yes or no)?

> How is that twisting your words? Surely you don't
> deny that, since P(P) halts, there is a correct answer as to whether
> P(P) halts or not?
>
> The halting problem is about deciding if a computation -- some code and
> some input -- halts or not. For a halt decider, H, to be correct
>
> H(P,I) != 0 if and only if P(I) halts and
> H(P,I) != 1 if and only if P(I) does not halt.
>
> In particular, the facts that H(P,P) == 0 and P(P) halts (facts you
> don't deny) show that H is not a halt decider. I know you never claimed
> it was (except by accident), but you do claim it is right about P(P).
> It is not.
>
> I think you consider my refusal to anthropomorphise code as "twisting
> your words". If you rephrased it in terms of the programmer, I'd just
> agree. Given bool H(code P, data I) {...}, what code can a programmer
> write in the brackets so that H(P,P) is correct? Answer: none. There
> is no code that can "get round" the construction of P from H.
>
>>> And since we now know that your "halt deciding criteria is the same as
>>> the halting problem" we can ditch all the waffle about simulation. It's
>>> just halting as conventionally defined.
>
>> No we cannot.
>
> Nonsense. Despite apparently being clear that your "and a few more" was
> wrong, you are sticking by it. H(P,I) == 0 is "correct" when P(I) does
> not halt, and for a few more cases (like P(P) which halts).
>

int main() { P(P); } does not count as halting even though its stops
running in the same way that Infinite_loop() does not count as halting
when the simulator aborts its simulation.

When H simply simulates its input and never interferes with the behavior
of its input H can screen out its own address range from the execution
trace that it examines as the basis for its halt status decision.

The set of halting computations halt on their own without interference.

The set of not halting computations do not halt on their own without
interference.

> If your waffle "halting" definition is the same as halting, there would
> be no need for it at all. Your apparently clear answer above ("the
> first one") is either a lie or the result of some deep self-deception on
> your part.
>
>> In order to remove the pathological feedback loop such that P does the
>> opposite of whatever H decides H simply acts as a pure simulator of P
>> thus having no effect what-so-ever on the behavior of P until after
>> its halt status decision has been made.
>>
>> H then aborts its simulation of P before ever returning any value to P
>> because every function called in infinite recursion or infinitely
>> nested simulation never returns to this caller.
>
> P(P) halts. H(P,P) == 0 is wrong when P(P) halts. Whatever all your
> guff really means, it is not the same as halting. You are not
> addressing the halting problem.
>
>>> Your favourite book, and your favourite quoted lines from it, make it
>>> quite clear that halting computations like P(P) need to be accepted not
>>> rejected. P(P) halts, but H(P,P) == 0 which is wrong. So what have you
>>> now after all this time except a huge mistake?
>>
>> Because the pure simulation of P(P) never halts this proves that P(P)
>> meets the conventional definition of a computation that never halts.
>
> P(P) halts. It does not meet the conventional definition of a
> computation that never halts. Your words are nonsense of the first
> order.
>

--
Copyright 2021 Pete Olcott

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

On 7/9/2021 6:23 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
> Please stop putting back irrelevant groups. You are not a tom cat.
> There is not need to spray everywhere.
>
>> On 7/9/2021 4:59 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/9/2021 6:30 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/8/2021 8:48 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> So which of your statements is the one you want to stand by?
>>>>>>>
>>>>>>> "We can know that my halt deciding criteria is the same as the halting
>>>>>>> problem"
>>>>>>> or
>>>>>>> "This maps to every element of the conventional halting problem set of
>>>>>>> non-halting computations and a few more."
>>>>>>>
>>>>>>> It should be obvious to others why this is the fence you are sitting on.
>>>>>>> Is it comfy?
>>>>>>>
>>>>>> The first one.
>>>>> Thank you. Your directness make me hopeful that you'll be clear about
>>>>> some other things... How long have you though that "and a few more" was
>>>>> correct? I.e. how long have you been arguing for a position you now
>>>>> concede is mistaken? Months? Years? Decades?
>>>>
>>>> I have only been trying to specifically define the set that are
>>>> involved for a few days.
>>> I wrote something about this but deleted it since it turns out, further
>>> down, you are still sitting on the fence.
>>>
>>>>> You have refused to accept the definition of the halting problem for
>>>>> decades. Do you now accept that every string has a correct yes/no
>>>>> answer as far as halting is concerned, and that "yes" is the correct
>>>>> answer for those strings that represent halting computations and "no" is
>>>>> the correct answer for all the others?
>>>>
>>>> The question: What Boolean value can H return to P representing the
>>>> correct halt status of P(P) in this computation has no correct answer:
>>> You seem to think that because every H gets at least one case wrong (the
>>> one designed to confound it) that this means that there is no correct
>>> answer to every halting instance. That is wrong, and until you realise
>>> that, you are not going to make any progress.
>>> For any two-argument Boolean function H, there is a corresponding
>>> function hat(H). The computation hat(H)(hat(H)) either halts or it does
>>> not, so that computation has a correct answer as to its halting. The
>>> fact that no H gives the right answer for its own personal Nemesis,
>>> hat(H)(hat(H)), does not mean there isn't one in every single case.
>>> We even know what it is for your H (despite the fact that you a
>>> studiously hiding the code), because you have stated, and posted a trace
>>> showing, what actually happens! P (your current name for the 'hat'
>>> version of H) halts when passed P. This is why H(P,P) == 0 is wrong.
>>>
>>>> // 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);
>>>> }
>>>>
>>>> You always consistently twist these words to say something else
>>>> entirely knowing full well that you twist these words.
>>> You are correctly explaining that H is wrong about P(P). How can it be
>>> put any more simply?
>>
>> The reason that H cannot return the correct halt status to P is that
>> this TM / input pair was intentionally modeled on the basis of the
>> liar paradox.
>
> At least you agree, then that H(P,P) is wrong since P(P) halts. Good.
>
>> The halting problem counter-example (prior to my insights) had no
>> associated Boolean value specifically because most of the details are
>> always unspecified.
>
> Flat-out wrong. P(P) halts. The correct associated Boolean value is
> true. If you write some other H', the resulting hat(H')(hat(H'))
> computation might not halt so the correct associated Boolean value would
> be false. There is always a correct associated Boolean value describing
> the halting of every computation, despite the fact that there is no
> function that gets the corresponding 'hat' case right.
>
>> When we ask the specific question: What correct value of {true, false}
>> can H correctly return to P that indicates the actual halt status of
>> P?
>>
>> (The answer is restricted to Boolean, the answer of "neither" is not allowed).
>>
>> This 100% specific question <is> as I have always said exactly the
>> same type mismatch error as asking the question: What time is it (yes
>> or no)?
>
> But your 100% specific question is not an instance of the halting
> problem. It's a related question about what is possible in code, and we
> know the answer -- no code can decide halting. It's odd that your
> defence includes such a robust argument that the halting theorem is
> correct.
>
> That every bit of code, no matter how simple or how subtle, is wrong
> about some inputs is just a statement of the halting theorem. That all
> inputs have a correct yes/no answer is just a statement of fact.
>
>>> How is that twisting your words? Surely you don't
>>> deny that, since P(P) halts, there is a correct answer as to whether
>>> P(P) halts or not?
>>> The halting problem is about deciding if a computation -- some code and
>>> some input -- halts or not. For a halt decider, H, to be correct
>>> H(P,I) != 0 if and only if P(I) halts and
>>> H(P,I) != 1 if and only if P(I) does not halt.
>>> In particular, the facts that H(P,P) == 0 and P(P) halts (facts you
>>> don't deny) show that H is not a halt decider. I know you never claimed
>>> it was (except by accident), but you do claim it is right about P(P).
>>> It is not.
>>> I think you consider my refusal to anthropomorphise code as "twisting
>>> your words". If you rephrased it in terms of the programmer, I'd just
>>> agree. Given bool H(code P, data I) {...}, what code can a programmer
>>> write in the brackets so that H(P,P) is correct? Answer: none. There
>>> is no code that can "get round" the construction of P from H.
>>>
>>>>> And since we now know that your "halt deciding criteria is the same as
>>>>> the halting problem" we can ditch all the waffle about simulation. It's
>>>>> just halting as conventionally defined.
>>>
>>>> No we cannot.
>>> Nonsense. Despite apparently being clear that your "and a few more"
>>> was wrong, you are sticking by it. H(P,I) == 0 is "correct" when
>>> P(I) does not halt, and for a few more cases (like P(P) which halts).
>>
>> int main() { P(P); } does not count as halting even though its stops
>> running in the same way that Infinite_loop() does not count as halting
>> when the simulator aborts its simulation.
>
> P(P) halts. If you don't "count" all halting computations as halting
> you are talking nonsense.
>

A computation that stops running because it has been aborted is as
Richard put it suspended, and not halted.

> Remember, you have relinquished your right to make up a definition of
> what halting is. You've been clear that you intend "halting" to refer
> to the conventional meaning of the term as used in the halting problem.
> If you are unsure about what counts, you need to ask experts what counts
> as halting. And when people like me tell you what counts, you have to
> suck it up. Halting is not a mysterious concept.
>

When-so-ever the pure simulation of an input on its input never halts
then this input never halts.

When-so-ever any input to H never halts while H remains a pure simulator
then we know this input never halts.

On 7/9/2021 7:13 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/9/2021 6:23 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>> Please stop putting back irrelevant groups. You are not a tom cat.
>>> There is not need to spray everywhere.
>
> Please take note. There is no need to be rude as well as wrong.
>
>>>> On 7/9/2021 4:59 PM, Ben Bacarisse wrote:
>
>>>>> ... Despite apparently being clear that your "and a few more"
>>>>> was wrong, you are sticking by it. H(P,I) == 0 is "correct" when
>>>>> P(I) does not halt, and for a few more cases (like P(P) which halts).
>>>>
>>>> int main() { P(P); } does not count as halting even though its stops
>>>> running in the same way that Infinite_loop() does not count as halting
>>>> when the simulator aborts its simulation.
>>>
>>> P(P) halts. If you don't "count" all halting computations as halting
>>> you are talking nonsense.
>>
>> A computation that stops running because it has been aborted is as
>> Richard put it suspended, and not halted.
>
> I see you don't want to discuss any of the above so I've cut it all and
> I'll keep my replies short. No point in writing explanations just for
> you to ignore.
>
> P(P) halts. It counts. You don't get to say that some halting does not
> count (until you go back to admitting that you are not talking about the
> halting problem when you can make up any old dross you like).
>
>>> Remember, you have relinquished your right to make up a definition of
>>> what halting is. You've been clear that you intend "halting" to refer
>>> to the conventional meaning of the term as used in the halting problem.
>>> If you are unsure about what counts, you need to ask experts what counts
>>> as halting. And when people like me tell you what counts, you have to
>>> suck it up. Halting is not a mysterious concept.
>>
>> When-so-ever the pure simulation of an input on its input never halts
>> then this input never halts.
>>
>> When-so-ever any input to H never halts while H remains a pure
>> simulator then we know this input never halts.
>
> You have stated your intention that whatever waffle you write about
> simulation, you intend it to capture exactly the same meaning as
> conventional halting. Until you go back to being honest, and admit you
> are not talking about the halting problem as the world understands it, I
> can safely ignore all of your clumsy attempts at a definition because
> they are supposed to mean what everyone else means by halting.
>
>> int main() { P(P); } never halts while H remains a pure simulator.
>
> For some H to be correct
>
> H(P,I) != 0 if and only if P(I) halts and
> H(P,I) != 1 if and only if P(I) does not halt.
>
> If H is a pure simulator it will not meet this specification. But your
> H is not a pure simulator. It is simply wrong about P(P). It is wrong
> based in fact you have reported: that H(P,P) == 0 and that P(P) halts.
> Whatever H you come up with, it will be wrong about some inputs. That's
> what an impossible program is.
>

Simulating halt decider H is only answering the question:
Would the input halt on its input if H never stopped simulating it?

An answer of "no" universally means that the input never halts.

An answer of "yes" universally means that the input halts.

[Halt Deciding Axiom] When the pure simulation of the machine
description ⟨P⟩ of a machine P on its input I never halts we know that
P(I) never halts.

--
Copyright 2021 Pete Olcott

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

On 7/9/2021 11:59 AM, Real Troll wrote:
> On 09/07/2021 14:59, olcott wrote:
>>
>> comp.theory gets all of my newest material before I put it in my paper.
>
> That's very good idea if not a wonderful idea. We are all reading your
> theory on that newsgroup so there is no point in duplicating anything on
> to C or C++ because it irritates everybody (especially those that have
> still not kill-filed you) on those newsgroups and the theory has nothing
> to do with C or C++. I'm sure you understand this.
>
> You're a potential price winner of some kind so don't throw it away by
> becoming a common troll.
>
> Good luck.
>

One of my best reviewers [Kaz Kylheku] came from comp.lang.c and would
have never reviewed my work unless he saw it in comp.lang.c

--
Copyright 2021 Pete Olcott

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