Re: The Halting Problem proofs have a fatal flaw [ Visual Studio c/c++ project ]

[olcott]

On 9/27/2022 6:00 AM, Richard Damon wrote:
> On 9/26/22 11:49 PM, olcott wrote:
>> On 9/26/2022 10:29 PM, Richard Damon wrote:
>>> On 9/26/22 11:04 PM, olcott wrote:
>>>> On 9/26/2022 9:58 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/26/22 10:41 PM, olcott wrote:
>>>>>> On 9/26/2022 9:23 PM, Richard Damon wrote:
>>>>>>> On 9/26/22 10:18 PM, olcott wrote:
>>>>>>>> On 9/26/2022 8:49 PM, Richard Damon wrote:
>>>>>>>>> On 9/26/22 9:26 PM, olcott wrote:
>>>>>>>>>> On 9/26/2022 8:15 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/26/22 8:58 PM, olcott wrote:
>>>>>>>>>>>> On 9/26/2022 7:36 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/26/22 8:25 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <non...@beez-waxes.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 2022-09-26, Lew Pitcher
>>>>>>>>>>>>>>>>>>>>>>> <lew.p...@digitalfreehold.ca>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to
>>>>>>>>>>>>>>>>>>>>>>>> discuss this
>>>>>>>>>>>>>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Because Olcott postings will push you out of
>>>>>>>>>>>>>>>>>>>>>>> visibility?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If people would give me a fair and honest review I
>>>>>>>>>>>>>>>>>>>>>> could quit
>>>>>>>>>>>>>>>>>>>>>> posting. You gave up on me before I could point
>>>>>>>>>>>>>>>>>>>>>> out the error with
>>>>>>>>>>>>>>>>>>>>>> the diagonalization argument that you relied on
>>>>>>>>>>>>>>>>>>>>>> for your rebuttal:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The diagonalization argument merely proves that no
>>>>>>>>>>>>>>>>>>>>>> value returned
>>>>>>>>>>>>>>>>>>>>>> to P from its call to H can possibly be correct.
>>>>>>>>>>>>>>>>>>>>>> This argument
>>>>>>>>>>>>>>>>>>>>>> totally ignores that the return value from H is
>>>>>>>>>>>>>>>>>>>>>> unreachable by its
>>>>>>>>>>>>>>>>>>>>>> simulated P caller when H is based on a simulating
>>>>>>>>>>>>>>>>>>>>>> halt decider.
>>>>>>>>>>>>>>>>>>>>>> This makes it impossible for P to do the opposite
>>>>>>>>>>>>>>>>>>>>>> of whatever H
>>>>>>>>>>>>>>>>>>>>>> decides.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>>>>>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>>>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>>>>>>>>>>>>> (c) Several halt deciders and their inputs
>>>>>>>>>>>>>>>>>>>>>> contained within Halt7.c
>>>>>>>>>>>>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You keep making the same mistake again and again. H
>>>>>>>>>>>>>>>>>>>>> IS NOT SUPPOSED
>>>>>>>>>>>>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Your H is recursive because P isn't recursive and yet
>>>>>>>>>>>>>>>>>>> you have to abort
>>>>>>>>>>>>>>>>>>> your infinite recursion: the recursion is caused by
>>>>>>>>>>>>>>>>>>> your H and not by
>>>>>>>>>>>>>>>>>>> P.  Nowhere in any halting problem proof does it
>>>>>>>>>>>>>>>>>>> state that the call to
>>>>>>>>>>>>>>>>>>> H by P is recursive in nature BECAUSE H IS NOT
>>>>>>>>>>>>>>>>>>> SUPPOSED TO EXECUTE P, H
>>>>>>>>>>>>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nowhere in any HP proof (besides mine) is the idea of
>>>>>>>>>>>>>>>>>> a simulating halt decider (SHD) ever thought all the
>>>>>>>>>>>>>>>>>> way through.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because the proof doesn't care at all how the decider
>>>>>>>>>>>>>>>>> got the answer,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because the definition of a UTM specifies that the
>>>>>>>>>>>>>>>>>> correct simulation of a machine description provides
>>>>>>>>>>>>>>>>>> the actual behavior of the underlying machine whenever
>>>>>>>>>>>>>>>>>> any simulating halt decider must abort its simulation
>>>>>>>>>>>>>>>>>> to prevent infinite simulation it is necessarily
>>>>>>>>>>>>>>>>>> correct to report that this input does not halt.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right, which means it CAN'T be a UTM, and thus *ITS*
>>>>>>>>>>>>>>>>> simulation does not define the "behavior of the input".
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The behavior of the correct simulation of the input is
>>>>>>>>>>>>>>>> its actual behavior. That H correctly predicts that its
>>>>>>>>>>>>>>>> correct simulation never stops running unless aborted
>>>>>>>>>>>>>>>> conclusively proves that this correctly simulated input
>>>>>>>>>>>>>>>> would never reach its own final state in 1 to ∞ steps of
>>>>>>>>>>>>>>>> correct simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But the behavior the halting problem is asking for is the
>>>>>>>>>>>>>>> behavior of the actual machine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Only within the context that no one ever bothered to think
>>>>>>>>>>>>>> the application of a simulating halt decider all the way
>>>>>>>>>>>>>> through.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, the DEFINITION of a Halt Decider is to decide on the
>>>>>>>>>>>>> behavior of the Actual Machine.
>>>>>>>>>>>>>
>>>>>>>>>>>> That definition is made obsolete by a simulating halt decider.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope, the definition IS the definition.
>>>>>>>>>>>
>>>>>>>>>>> You don't get to change it.
>>>>>>>>>>>
>>>>>>>>>> I created a new concept that makes earlier ideas about this
>>>>>>>>>> obsolete:
>>>>>>>>>>
>>>>>>>>>> Because the definition of a UTM specifies that the correct
>>>>>>>>>> simulation of a machine description provides the actual
>>>>>>>>>> behavior of the underlying machine whenever any simulating
>>>>>>>>>> halt decider must abort its simulation to prevent infinite
>>>>>>>>>> simulation it is necessarily correct to report that this input
>>>>>>>>>> does not halt.
>>>>>>>>>>
>>>>>>>>>> Because the above is verified as correct on the basis of the
>>>>>>>>>> meaning of its words it is irrefutable.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right, but H isn't a UTM, so its simulation doesn't matter.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Unless you can specify that material difference between the two,
>>>>>>>> that would seem to prove that you are technically incompetent.
>>>>>>>
>>>>>>> H doesn't correctly repoduce the behavior of a non-halting input.
>>>>>>>
>>>>>>> Thus, it isn't a UTM.
>>>>>>>
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩      // subscripts indicate unique finite
>>>>>> strings
>>>>>> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>
>>>>>> Then these steps would keep repeating: (unless their simulation is
>>>>>> aborted)
>>>>>
>>>>> Note, you say "unless their simulation is aborted" but your
>>>>> defiition of H DOES abort its simulation, thus this doesn't occur.
>>>>>
>>>>> FAIL.
>>>>>
>>>>>> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>
>>>>>> This exact same behavior occurs when we replace H with a UTM.
>>>>>>
>>>>>
>>>>> But since H ISN'T a UTM, you can't assume that it is.
>>>>>
>>>>
>>>> H is designed to predict the result of 1 to ∞ correctly simulated
>>>> steps, thus predict the behavior of a UTM simulation.
>>>>
>>> Except it doesn't do that.
>>>
>> H does correctly predict the actual behavior of 1 to ∞ simulated steps
>> of P.
>>
>
> Nope, since we have shown that if H(P,P) returns 0, then P(P) will Halt.
>

*That is false and you know it so you are a liar for the 500th time*
*You know that you are not referring to the behavior of an input to H*


Halt deciders only compute the mapping from their inputs to a accept or
reject state on the basis of the actual behavior of this input.

The correct simulation of 1 to ∞ steps of a machine description provides
the actual behavior of of 1 to ∞ steps of the underlying machine.

int Hx(ptr x, ptr y);

void Px(ptr x)
{
int Halt_Status = Hx(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

There are zero Px elements of infinite set of Hx/Px pairs such that the
correct simulation (of 1 to ∞ steps) or direct execution of Px by Hx
reaches the final state of Px and halts.

Some of the Hx elements correctly recognize a correct non-halting
behavior pattern proving that its Px never halts. These Hx elements
correctly abort their simulation and correctly return 0 for non-halting.

*This Hx/Px pair is named H/P and is fully operational*

Complete halt deciding system (Visual Studio Project)
(a) x86utm operating system
(b) complete x86 emulator adapted from libx86emu
(c) Several halt deciders and their inputs contained within Halt7.c
https://liarparadox.org/2022_09_07.zip

The recursive simulation non-halting behavior pattern is slightly
adapted from infinite recursion behavior pattern used to determine the
halt status of void Infinite_Recursion(u32 N).

Once the infinite recursion behavior pattern is understood to be correct
then the recursive simulation behavior pattern is also understood to be
correct. Both of these behavior patterns use the exact same non-halting
criteria.




--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[olcott]

Halt deciders only compute the mapping from their inputs to an accept or

reject state on the basis of the actual behavior of this input.

The correct simulation of 1 to ∞ steps of a machine description provides
the actual behavior of of 1 to ∞ steps of the underlying machine.

int Hx(ptr x, ptr y);

void Px(ptr x)
{
int Halt_Status = Hx(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

A simulating halt decider (SHD) continues to simulate its input until
the behavior of this input matches a non-halting behavior pattern or the
simulated input halts on its own.

There are zero Px elements of infinite set of Hx/Px pairs such that the
correct simulation (of 1 to ∞ steps) or direct execution of Px by Hx
reaches the final state of Px and halts.

Some of the Hx elements correctly recognize a correct non-halting
behavior pattern proving that its Px never halts. These Hx elements
correctly abort their simulation and correctly return 0 for non-halting.

*This Hx/Px pair is named H/P and is fully operational*

Complete halt deciding system (Visual Studio Project)
(a) x86utm operating system
(b) complete x86 emulator adapted from libx86emu
(c) Several halt deciders and their inputs contained within Halt7.c
https://liarparadox.org/2022_09_07.zip

The recursive simulation non-halting behavior pattern is slightly
adapted from infinite recursion behavior pattern used to determine the
halt status of void Infinite_Recursion(u32 N).

Once the infinite recursion behavior pattern is understood to be correct
then the recursive simulation behavior pattern is also understood to be
correct. Both of these behavior patterns use the exact same non-halting
criteria.

*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

[olcott]

On 9/28/2022 3:05 PM, Paul N wrote:
> On Wednesday, September 28, 2022 at 5:43:26 PM UTC+1, olcott wrote:
>> On 9/28/2022 11:32 AM, Mr Flibble wrote:
>>> On Tue, 27 Sep 2022 16:10:01 -0500
>>> olcott <non...@beez-waxes.com> wrote:
>>>
>>>> On 9/27/2022 3:36 PM, Mr Flibble wrote:

>>>>> On Tue, 27 Sep 2022 10:49:02 -0500
>>>>> olcott <polc...@gmail.com> wrote:
>>>>>
>>>>>> Halt deciders only compute the mapping from their inputs to an
>>>>>> accept or reject state on the basis of the actual behavior of this
>>>>>> input.
>>>>>

>>>>> And your decider doesn't do that so it isn't a halt decider, it is a
>>>>> recursive simulation decider. Real halt deciders return a decision
>>>>> to their caller in finite time.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> My code speaks for itself, thus conclusively proves that you don't
>>>> have a clue.
>>>
>>> Your code speaks for itself: it doesn't meet the functional
>>> requirements of a halt decider. You don't have a clue.
>>>
>>> /Flibble
>>>
>> You simply don't have the mental discipline to pay enough attention to
>> understand my rebuttals of your claims.
>>
>> Halt deciders must compute the mapping from their inputs to a final
>> accept or reject state on the basis of the actual behavior specified by
>> these inputs.
>
> Yes. You keep trying to pull a sleight-of-hand by saying that what counts is not the actual behaviour but what a correct simulation would do. This is not actually correct because P cannot be simulated properly. You then say that your simulation is correct, despite it giving the wrong answers. You justify that by claiming that no-one has found a flaw in it, despite several people pointing out the flaws numerous times, which you wave away by claiming, with no proof, that they are all wrong.
>

I HAVE ALREADY BEEN THOUGH THIS HUNDREDS OF TIMES
It is easily verified that the simulation is correct in that the
simulated x86 instructions exactly match what their x86 source-code
specifies.

Furthermore:

void Px(ptr x)
{
int Halt_Status = Hx(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", Hx(Px, Px));
}

There are zero elements of infinite set of Hx/Px pairs such that the
correct *partial or complete* simulation of Px by Hx reaches the final
state of Px and halts. This is also the case when Hx directly executes Px.

My reviewers simply are not bright enough to see this thus mistakenly
believe that I am wrong.

Complete halt deciding system (Visual Studio Project)
(a) x86utm operating system
(b) complete x86 emulator adapted from libx86emu
(c) Several halt deciders and their inputs contained within Halt7.c
https://liarparadox.org/2022_09_07.zip

[olcott]

On 9/29/2022 9:45 AM, Paul N wrote:

> On the contrary, you've told us numerous times that Px halts but Hx "correctly" predicts that it doesn't.

Sure and if I am "told" that squares are round I will take it the same
way. The things that clueless wonders tell me carry no weight.


> That is *not* a correct simulation. You are assuming that Hx is correct in assuming that it has got stuck in a loop, when you know full well that Hx has the machinery to get out of the loop, because you wrote it yourself.
>

H and P are C functions that I wrote. Hx/Px is an infinite set of
different definitions of Hx for the following Px.

>> Furthermore:
>>
>> void Px(ptr x)
>> {
>> int Halt_Status = Hx(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", Hx(Px, Px));
>> }
>

> Yes, it is clear that Px will do the opposite of what Hx "predicts" it will do.

>
>> There are zero elements of infinite set of Hx/Px pairs such that the
>> correct *partial or complete* simulation of Px by Hx reaches the final
>> state of Px and halts. This is also the case when Hx directly executes Px.
>

> Why do you keep saying this? There are no pairs where Hx correctly simulates Px.

No sense talking to you anymore because you lack the technical
competence to see that H does correctly emulate P using an x86
emulator. You don't even know C well enough to see that when Hx
correctly simulates 1 to ∞ steps of Px that Px never reaches its
own final state.

// H(Px,Px) directly executes Px that never halts.
//

int Hx(ptr x, ptr y)

{
x(y);
}

Since halt deciders only compute the mapping from their inputs
to an accept or reject state based on the actual behavior
specified by these inputs THE BEHAVIOR OF NON INPUTS IS IRRELEVANT
EVEN IF YOUR GROUP-THINK BUDDIES THINK THAT IT IS.

Groupthink is a phenomenon that occurs when a group of well-intentioned
people makes irrational or non-optimal decisions spurred by the urge to
conform or the belief that dissent is impossible. The problematic or
premature consensus that is characteristic of groupthink may be fueled
by a particular agenda—or it may be due to group members valuing harmony
and coherence above critical thought.
https://www.psychologytoday.com/us/basics/groupthink

[Charlie-Boo]

Are you trying to prove:

A. The Turing 1931 proof is wrong.
B. It's solvable.
C. All of the proofs are wrong.

If A then you need to show what specifically is wrong with it.
If B then you are inconsistent with the other proofs and need to show that all of them are wrong and how you avoided that mistake. Start with the Arithmetic Hierarchy proof - probably the simplest. The halting set is a recursively enumerable not recursive relation.
If C you have to prove all of them are wrong.

C-B

[Ben Bacarisse]

Charlie-Boo <shyma...@gmail.com> writes:

> Are you trying to prove:
>
> A. The Turing 1931 proof is wrong.

The paper you are thinking of is from 1936 and does not contain a proof
of what has come to be called the halting problem.

--
Ben.