Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.theory > #50238 > unrolled thread

Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2)

Back to article view | Back to comp.theory

Contents

  Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-11 13:07 -0500
    Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-11 20:11 +0100
      Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-11 19:23 -0500
        Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-11 21:02 -0400
        Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 18:31 +0100
          Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 12:43 -0500
        Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 18:43 +0100
          Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 12:45 -0500
            Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 18:47 +0100
              Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 12:51 -0500
                Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 19:00 +0100
                  Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 13:06 -0500
                    Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 19:13 +0100
                    Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 21:12 +0100
                      Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 15:18 -0500
                        Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 23:58 +0100
                          Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 18:28 -0500
                            Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-13 01:40 +0100
                              Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 20:32 -0500
                                Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 21:48 -0400
                                Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-13 13:38 +0100
                            Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 20:56 -0400
                        Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 19:09 -0400
                    Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 18:50 -0400
                Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 18:46 -0400
            Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 18:45 -0400
    Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-11 19:41 -0400
    Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 01:17 +0100
      Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-11 19:29 -0500
        Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-11 20:52 -0400
        Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 02:10 +0100
          Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-11 21:29 -0500
            Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-11 23:02 -0400
            Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 23:54 +0100
              Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 18:21 -0500
                Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 00:24 +0100
                  Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 18:42 -0500
                Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-13 01:35 +0100
                  Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-12 20:25 -0500
                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-12 21:41 -0400
                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 12:05 +0100
                      Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 12:01 -0500
                        Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 20:06 +0100
                          Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 14:24 -0500
                            Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 16:11 -0400
                              Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 15:22 -0500
                                Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-13 13:26 -0700
                                  Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 15:38 -0500
                                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 21:44 +0100
                                Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] wij <wyniijj2@gmail.com> - 2022-05-13 13:27 -0700
                                Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 17:22 -0400
                                  Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 16:48 -0500
                                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 18:04 -0400
                                      Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 17:06 -0500
                                        Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 19:07 -0400
                                          Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 18:09 -0500
                                            Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 19:20 -0400
                                              Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 18:26 -0500
                                                Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 20:04 -0400
                                                  Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 19:20 -0500
                                                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 20:41 -0400
                                                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] André G. Isaak <agisaak@gm.invalid> - 2022-05-13 19:03 -0600
                                                      Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 21:21 -0400
                                                      Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 22:37 -0500
                            Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 23:46 +0100
                              Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 17:57 -0500
                                Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 19:09 -0400
                                  Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 18:18 -0500
                                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 20:09 -0400
                                Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 01:03 +0100
                                  Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 19:11 -0500
                                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 01:18 +0100
                                      Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 19:22 -0500
                                        Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 01:28 +0100
                                Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-14 11:45 +0300
                                  Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-14 04:28 -0500
                                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-14 15:55 +0300
                                      Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-14 08:53 -0500
                                        Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-15 12:05 +0300
                    Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-13 16:11 +0300
                      Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 11:15 -0500
                        Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-14 11:26 +0300
                Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 21:03 -0400
    Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mikko <mikko.levanto@iki.fi> - 2022-05-13 16:02 +0300
    Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) wij <wyniijj2@gmail.com> - 2022-05-13 12:21 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#50362

olcott <NoOne@NoWhere.com> writes:

> On 5/12/2022 7:40 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> 
>>> On 5/12/2022 5:58 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 5/12/2022 3:12 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> The halting criteria has been adapted so that
>>>>>>
>>>>>> H is no longer a halt decider.
>>>> <cut various errors>
>>>>
>>>>> My only point is that the input to embedded_H does specifies
>>>>> infinitely nested simulation contradicting Flibble's claim that it
>>>>> does not, thus my H(P,P) is equivalent to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>> You made lots of point.  Many of them wrong.  I pointed out some of the
>>>> errors.
>>>> But since you are now unashamedly admitting to using an adapted
>>>> criterion for halting, is there any point in carrying on?
>>>
>>> I proved that the criteria for halting is objectively incorrect.
>> It can't be incorrect.  It's a definition.  And it's based on the most
>> natural notion: is the sequence of TM configurations finite or not.
>
> It is an objectively verifiable fact that the sequence of
> configurations specified by the input to H(P,P) is not the same as the
> one specified by P(P).

Who cares?  Only you.  You accept, now, that you can't write a D that
does what everyone but you wants: D(X,Y) == true if and only if X(Y)
halts and false otherwise.

You are done with halting now because you are not making any claims to
have anything to say about what the world calls halting.

> When you have two definitions in computer science that directly
> contradict each other what do you do? Toss out at least one of them.

No.  Whatever your H is deciding might be interesting.  I don't think
so, but there's no reason to toss it out just because it does not decide
halting.

-- 
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

[toc] | [prev] | [next] | [standalone]

#50335

On 5/12/22 7:28 PM, olcott wrote:
> On 5/12/2022 5:58 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/12/2022 3:12 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The halting criteria has been adapted so that
>>>>
>>>> H is no longer a halt decider.
>>
>> <cut various errors>
>>
>>> My only point is that the input to embedded_H does specifies
>>> infinitely nested simulation contradicting Flibble's claim that it
>>> does not, thus my H(P,P) is equivalent to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> You made lots of point.  Many of them wrong.  I pointed out some of the
>> errors.
>>
>> But since you are now unashamedly admitting to using an adapted
>> criterion for halting, is there any point in carrying on?
>>
> 
> I proved that the criteria for halting is objectively incorrect.
> It requires a decider to base its decision on a non-input thus directly 
> contradicting the definition of a decider thus making the requirement 
> itself incorrect.

No, you proved that the halting function is not computable, which is 
exactly the claim of the Halting Theorem that you are trying to disprove.

That an actual algorithmic H can't correctly handle the problem is 
exactly what the Halting Problem is about.

Note, MOST deciders are working on problems that aren't directly stated 
by their literal inputs, but by something the input represents, not is.

ANY time a Turing Machine is being asked a problem about math, is one 
such case as the tape is a string of symbols, not "numbers". Yes, it is 
a representation of the numbers, but it is JUST a representation of the 
number, not the number itself.

By your logic, it is impossible to ask a Turing Machine if a "Number" is 
even, only if the number of symbols on a tape is even or the string of 
symbols on the tape is a representation of an even number.

This is EXACTLY the same as asking if the reprentation on the tape 
represents a Halting Computation.

> 
> My H conclusively proves that it does correctly compute the mapping from 
> its input finite strings to its own reject state on the basis of the 
> actual behavior specified by these finite strings.
> 

But the mapping isn't that defined by the Halting problem, so it doesn't 
say anything about that mapping.


You seem to be thinking of the Halting Problem as an exam question given 
by a teacher to their students, a mere theoretical concept to just try 
to solve.

You don't understand that the criteria of the Halting Problem has actual 
utility, and came about out of basic problems trying to decide if 
certain things are "solvable". Changing the critera means you aren't 
actually asking the question that needs to be answered, so is a 
worthless result.

[toc] | [prev] | [next] | [standalone]

#50312

On 5/12/22 4:18 PM, olcott wrote:
> On 5/12/2022 3:12 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The halting criteria has been adapted so that
>>
>> H is no longer a halt decider.
>>
>>> it applies to a
>>> simulating halt decider (SHD).
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>> final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
>>
>> This not Linz's Ĥ.  Linz's H leads to a contradiction because of how H
>> and the "hat" construction are defined.  Using a different "hat"
>> construction, and an "adapted" halt criterion, means you are not
>> addressing Linz's (or anyone's) proof.  Why do you think anyone will
>> take any claims about your bogus seriously?
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>> own final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
>>
>> A halt decider would have this simple behaviour:
>>
>>    J ⟨M⟩ s ⊢* J.qy  if M applied to s halts, and
>>    J ⟨M⟩ s ⊢* J.qn  if M applied to s does not halt.
>>
>> (I've changed the name because you are abusing H and Ĥ to refer to TMs
>> that do not meet Linz's specifications.)
>>
>> Which, with the correct "hat" construction applied, results in
>>
>>    Ĵ.q0 ⟨Ĵ⟩ ⊢* J ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* J.qy ⊢* oo   if J applied to ⟨Ĵ⟩ ⟨Ĵ⟩ 
>> halts, and
>>    Ĵ.q0 ⟨Ĵ⟩ ⊢* J ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* J.qn       if J applied to ⟨Ĵ⟩ ⟨Ĵ⟩ does 
>> not halt
>>
>> which, as Linz says, is clearly nonsense.  No TM can behave as Ĵ was
>> assumed to behave.
>>
>> I bring this up only for the benefit of anyone who is still interested
>> in how the proof works.  You stopped talking about the halting problem
>> and it's proofs some while ago, having failed to persuade anyone that
>> the wrong answer is the right one.
>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>
>> Bit of a nerve to cite Linz when you are ignoring his specification and
>> his proof!
>>
> 
> My only point is that the input to embedded_H does specifies infinitely 
> nested simulation contradicting Flibble's claim that it does not, thus 
> my H(P,P) is equivalent to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
> 

The input to embedded_H only specifies infinitely nested simulations if 
H is designed to NEVER abort its simulation of this input, and if this 
is true, then H will not return an answer to H <H^> <H^> because it too 
will get stuck in the same infinite nested simulation loop.

[toc] | [prev] | [next] | [standalone]

#50307

On 5/12/22 2:06 PM, olcott wrote:
> On 5/12/2022 1:00 PM, Mr Flibble wrote:
>> On Thu, 12 May 2022 12:51:27 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 5/12/2022 12:47 PM, Mr Flibble wrote:
>>>> On Thu, 12 May 2022 12:45:15 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 5/12/2022 12:43 PM, Mr Flibble wrote:
>>>>>> On Wed, 11 May 2022 19:23:45 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 5/11/2022 2:11 PM, Mr Flibble wrote:
>>>>>>>> On Wed, 11 May 2022 13:07:16 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
>>>>>>>>> proofs ]
>>>>>>>>>
>>>>>>>>> The x86utm operating system was created so that every detail of
>>>>>>>>> the conventional halting problem counter example could be fully
>>>>>>>>> specified in C/x86.
>>>>>>>>>
>>>>>>>>>         In computability theory, the halting problem is the
>>>>>>>>>         problem of determining, from a description of an
>>>>>>>>>         arbitrary computer program and an input, whether the
>>>>>>>>>         program will finish running, or continue to run
>>>>>>>>> forever...
>>>>>>>>>
>>>>>>>>>         For any program f that might determine if programs halt,
>>>>>>>>>         a "pathological" program g, called with some input, can
>>>>>>>>>         pass its own source and its input to f and then
>>>>>>>>> specifically do the opposite of what f predicts g will do. No f
>>>>>>>>> can exist that handles this case.
>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>
>>>>>>>>> This exact same relationship of f(g,g) was created as H(P,P),
>>>>>>>>> shown below.
>>>>>>>>>
>>>>>>>>> This is the overview of the method for proving that this
>>>>>>>>> analysis is correct:
>>>>>>>>> (a) Verify that the execution trace of P by H is correct by
>>>>>>>>> comparing this execution trace to the ax86 source-code of P.
>>>>>>>>>
>>>>>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>>>>>
>>>>>>>>> This proof can only be understood only by those having
>>>>>>>>> sufficient technical competence in:
>>>>>>>>> (a) software engineering (recognizing infinite recursion in C
>>>>>>>>> and x86 code) (b) the x86 programming language
>>>>>>>>> (c) the C programming language and
>>>>>>>>> (d) the details of how C is translated into x86 by the
>>>>>>>>> Microsoft C compilers.
>>>>>>>>>
>>>>>>>>> #include <stdint.h>
>>>>>>>>> #define u32 uint32_t
>>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>>        if (H(x, x))
>>>>>>>>>          HERE: goto HERE;
>>>>>>>>>        return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>        Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00001352](01)  55              push ebp
>>>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>> [00001358](01)  50              push eax
>>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>> [0000135c](01)  51              push ecx
>>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>>>> [0000136c](01)  c3              ret
>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>
>>>>>>>>> _main()
>>>>>>>>> [00001372](01)  55              push ebp
>>>>>>>>> [00001373](02)  8bec            mov ebp,esp
>>>>>>>>> [00001375](05)  6852130000      push 00001352 // push P
>>>>>>>>> [0000137a](05)  6852130000      push 00001352 // push P
>>>>>>>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>>>>>>>> [00001384](03)  83c408          add esp,+08
>>>>>>>>> [00001387](01)  50              push eax
>>>>>>>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts
>>>>>>>>> = " [0000138d](05)  e8e0f0ffff      call 00000472 // call
>>>>>>>>> Output [00001392](03)  83c408          add esp,+08
>>>>>>>>> [00001395](02)  33c0            xor eax,eax
>>>>>>>>> [00001397](01)  5d              pop ebp
>>>>>>>>> [00001398](01)  c3              ret
>>>>>>>>> Size in bytes:(0039) [00001398]
>>>>>>>>>
>>>>>>>>>          machine   stack     stack     machine    assembly
>>>>>>>>>          address   address   data      code       language
>>>>>>>>>          ========  ========  ========  =========  =============
>>>>>>>>> ...[00001372][0010229e][00000000] 55         push ebp
>>>>>>>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>>>>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 //
>>>>>>>>> push P ...[0000137a][00102296][00001352] 6852130000 push
>>>>>>>>> 00001352 // push P ...[0000137f][00102292][00001384] e81efeffff
>>>>>>>>> call 000011a2 // call H
>>>>>>>>>
>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>> at:212352 ...[00001352][0021233e][00212342] 55         push ebp
>>>>>>>>>      // enter P ...[00001353][0021233e][00212342] 8bec       mov
>>>>>>>>> ebp,esp ...[00001355][0021233e][00212342] 8b4508     mov
>>>>>>>>> eax,[ebp+08] ...[00001358][0021233a][00001352] 50         push
>>>>>>>>> eax // push P ...[00001359][0021233a][00001352] 8b4d08     mov
>>>>>>>>> ecx,[ebp+08] ...[0000135c][00212336][00001352] 51         push
>>>>>>>>> ecx // push P ...[0000135d][00212332][00001362] e840feffff call
>>>>>>>>> 000011a2 // call H ...[00001352][0025cd66][0025cd6a] 55
>>>>>>>>> push ebp      // enter P ...[00001353][0025cd66][0025cd6a] 8bec
>>>>>>>>>       mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508
>>>>>>>>> mov eax,[ebp+08] ...[00001358][0025cd62][00001352] 50
>>>>>>>>> push eax // push P ...[00001359][0025cd62][00001352] 8b4d08
>>>>>>>>>   mov ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51
>>>>>>>>> push ecx // push P ...[0000135d][0025cd5a][00001362]
>>>>>>>>> e840feffff call 000011a2 // call H Local Halt Decider:
>>>>>>>>> Infinite Recursion Detected Simulation Stopped
>>>>>>>>>
>>>>>>>>> H sees that P is calling the same function from the same
>>>>>>>>> machine address with identical parameters, twice in sequence.
>>>>>>>>> This is the infinite recursion (infinitely nested simulation)
>>>>>>>>> non-halting behavior pattern.
>>>>>>>>>
>>>>>>>>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>>>>>>>>> ...[00001387][0010229a][00000000] 50         push eax
>>>>>>>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>>>>>>>>> "Input_Halts ="
>>>>>>>>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 //
>>>>>>>>> call Output Input_Halts = 0
>>>>>>>>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>>>>>>>>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>>>>>>>>> ...[00001397][001022a2][00100000] 5d         pop ebp
>>>>>>>>> ...[00001398][001022a6][00000004] c3         ret
>>>>>>>>> Number of Instructions Executed(15892) lines = 237 pages
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>> (V5)
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5 
>>>>>>>>>
>>>>>>>>
>>>>>>>> Your simulation approach is erroneous as there is no infinite
>>>>>>>> recursion; the key to understanding this is by realizing the
>>>>>>>> implication of the words "pass its own source" in the
>>>>>>>> following:
>>>>>>>
>>>>>>>
>>>>>>> YOU IGNORED THIS PART
>>>>>>>
>>>>>>> This proof can only be understood only by those having sufficient
>>>>>>> technical competence in:
>>>>>>> (a) software engineering - recognizing infinite recursion in
>>>>>>> C/x86 (b) the x86 programming language
>>>>>>> (c) the C programming language and
>>>>>>> (d) the details of how C is translated into x86 by the Microsoft
>>>>>>> C compilers.
>>>>>>
>>>>>> (a) I have been a software developer/engineer since 1993 and am
>>>>>> able to recognize infinite recursion and additionally, and more
>>>>>> importantly, a lack of infinite recursion.
>>>>>
>>>>> This has been disproven in that you did not see this:
>>>>>    >>>> H sees that P is calling the same function from the same
>>>>>    >>>> machine address with identical parameters, twice in
>>>>>    >>>> sequence. This is the infinite recursion (infinitely nested
>>>>>    >>>> simulation) non-halting behavior pattern.
>>>> I am not talking about your braindead simulation, I am talking about
>>>> the halting problem proofs you are trying to refute: THEY DO NOT
>>>> HAVE AN INFINITE RECURSION.
>>>>
>>>> /Flibble
>>>
>>> My proofs prove that they do.
>>> That you fail to comprehend this is no rebuttal at all.
>> Only your simulation contains an infinite recursion due to a category
>> error ON YOUR PART. Your category error is proof that your
>> simulation-based proof is in error.
>>
>> /Flibble
>>
> 
>  > PO's idea is to have a simulator with an infinite cycle detector.
>  > You would achieve this by modifying a UTM, so describing it as
>  > a "modified UTM", or "acts like a UTM until it detects an infinite
>  > cycle", is reasonable. And such a machine is a fairly powerful
>  > halt decider. Even if the infinite cycle detector isn't very
>  > sophisticated, it will still catch a large subset of non-halting
>  > machines.
> 
> The following simplifies the syntax for the definition of the Linz 
> Turing machine Ĥ.
> There is no need for the infinite loop after H.qy because it is never 
> reached. The halting criteria has been adapted so that it applies to a 
> simulating halt decider (SHD).
> 
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final 
> state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
> 
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own 
> final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
> 
> Then these steps would keep repeating: (unless their simulation is aborted)
> Ĥ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⟩...
> 
> Since we can see that the simulated input: ⟨Ĥ0⟩ to H would never reach 
> its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ we know that it is non-halting.
> 
> Linz, Peter 1990. An Introduction to Formal Languages and Automata. 
> Lexington/Toronto: D. C. Heath and Company. (317-320)
> 
> 
> 

Key words, "Unless their simulation is aborted", which, since H has been 
show to actually abort the simulation, means that DOES happen, so H has 
no proof that it was CORRECT to abort the simulation.

H can say that if it was programmed to NEVER abort, then it WOULD HAVE 
BEEN correct to abort, but it didn't, so would have failed.

Once H is programmed to abort, it no longer has proof that it is correct 
to do so.

You make the error of confounding the two possible versions of H, so 
your reasoning is incorrect. H needs to decide on the copy of H that 
actually exists, not the 'theoretical' alternative that might have, but 
doesn't exist.

[toc] | [prev] | [next] | [standalone]

#50306

On 5/12/22 1:51 PM, olcott wrote:
> On 5/12/2022 12:47 PM, Mr Flibble wrote:
>> On Thu, 12 May 2022 12:45:15 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 5/12/2022 12:43 PM, Mr Flibble wrote:
>>>> On Wed, 11 May 2022 19:23:45 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 5/11/2022 2:11 PM, Mr Flibble wrote:
>>>>>> On Wed, 11 May 2022 13:07:16 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
>>>>>>> proofs ]
>>>>>>>
>>>>>>> The x86utm operating system was created so that every detail of
>>>>>>> the conventional halting problem counter example could be fully
>>>>>>> specified in C/x86.
>>>>>>>
>>>>>>>        In computability theory, the halting problem is the
>>>>>>>        problem of determining, from a description of an
>>>>>>>        arbitrary computer program and an input, whether the
>>>>>>>        program will finish running, or continue to run forever...
>>>>>>>
>>>>>>>        For any program f that might determine if programs halt,
>>>>>>>        a "pathological" program g, called with some input, can
>>>>>>>        pass its own source and its input to f and then
>>>>>>> specifically do the opposite of what f predicts g will do. No f
>>>>>>> can exist that handles this case.
>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> This exact same relationship of f(g,g) was created as H(P,P),
>>>>>>> shown below.
>>>>>>>
>>>>>>> This is the overview of the method for proving that this analysis
>>>>>>> is correct:
>>>>>>> (a) Verify that the execution trace of P by H is correct by
>>>>>>> comparing this execution trace to the ax86 source-code of P.
>>>>>>>
>>>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>>>
>>>>>>> This proof can only be understood only by those having sufficient
>>>>>>> technical competence in:
>>>>>>> (a) software engineering (recognizing infinite recursion in C and
>>>>>>> x86 code) (b) the x86 programming language
>>>>>>> (c) the C programming language and
>>>>>>> (d) the details of how C is translated into x86 by the Microsoft
>>>>>>> C compilers.
>>>>>>>
>>>>>>> #include <stdint.h>
>>>>>>> #define u32 uint32_t
>>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>       if (H(x, x))
>>>>>>>         HERE: goto HERE;
>>>>>>>       return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>       Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [00001352](01)  55              push ebp
>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>> [00001358](01)  50              push eax
>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>> [0000135c](01)  51              push ecx
>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>> [0000136c](01)  c3              ret
>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>
>>>>>>> _main()
>>>>>>> [00001372](01)  55              push ebp
>>>>>>> [00001373](02)  8bec            mov ebp,esp
>>>>>>> [00001375](05)  6852130000      push 00001352 // push P
>>>>>>> [0000137a](05)  6852130000      push 00001352 // push P
>>>>>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>>>>>> [00001384](03)  83c408          add esp,+08
>>>>>>> [00001387](01)  50              push eax
>>>>>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>>>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>>>>>> [00001392](03)  83c408          add esp,+08
>>>>>>> [00001395](02)  33c0            xor eax,eax
>>>>>>> [00001397](01)  5d              pop ebp
>>>>>>> [00001398](01)  c3              ret
>>>>>>> Size in bytes:(0039) [00001398]
>>>>>>>
>>>>>>>         machine   stack     stack     machine    assembly
>>>>>>>         address   address   data      code       language
>>>>>>>         ========  ========  ========  =========  =============
>>>>>>> ...[00001372][0010229e][00000000] 55         push ebp
>>>>>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 //
>>>>>>> push P ...[0000137a][00102296][00001352] 6852130000 push
>>>>>>> 00001352 // push P ...[0000137f][00102292][00001384] e81efeffff
>>>>>>> call 000011a2 // call H
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>> at:212352 ...[00001352][0021233e][00212342] 55         push ebp
>>>>>>>     // enter P ...[00001353][0021233e][00212342] 8bec       mov
>>>>>>> ebp,esp ...[00001355][0021233e][00212342] 8b4508     mov
>>>>>>> eax,[ebp+08] ...[00001358][0021233a][00001352] 50         push
>>>>>>> eax // push P ...[00001359][0021233a][00001352] 8b4d08     mov
>>>>>>> ecx,[ebp+08] ...[0000135c][00212336][00001352] 51         push
>>>>>>> ecx // push P ...[0000135d][00212332][00001362] e840feffff call
>>>>>>> 000011a2 // call H ...[00001352][0025cd66][0025cd6a] 55
>>>>>>> push ebp      // enter P ...[00001353][0025cd66][0025cd6a] 8bec
>>>>>>>      mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508     mov
>>>>>>> eax,[ebp+08] ...[00001358][0025cd62][00001352] 50         push
>>>>>>> eax // push P ...[00001359][0025cd62][00001352] 8b4d08     mov
>>>>>>> ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51         push
>>>>>>> ecx // push P ...[0000135d][0025cd5a][00001362] e840feffff call
>>>>>>> 000011a2 // call H Local Halt Decider: Infinite Recursion
>>>>>>> Detected Simulation Stopped
>>>>>>>
>>>>>>> H sees that P is calling the same function from the same machine
>>>>>>> address with identical parameters, twice in sequence. This is the
>>>>>>> infinite recursion (infinitely nested simulation) non-halting
>>>>>>> behavior pattern.
>>>>>>>
>>>>>>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>>>>>>> ...[00001387][0010229a][00000000] 50         push eax
>>>>>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>>>>>>> "Input_Halts ="
>>>>>>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 //
>>>>>>> call Output Input_Halts = 0
>>>>>>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>>>>>>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>>>>>>> ...[00001397][001022a2][00100000] 5d         pop ebp
>>>>>>> ...[00001398][001022a6][00000004] c3         ret
>>>>>>> Number of Instructions Executed(15892) lines = 237 pages
>>>>>>>
>>>>>>>
>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>> (V5)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5 
>>>>>>>
>>>>>>
>>>>>> Your simulation approach is erroneous as there is no infinite
>>>>>> recursion; the key to understanding this is by realizing the
>>>>>> implication of the words "pass its own source" in the following:
>>>>>
>>>>>
>>>>> YOU IGNORED THIS PART
>>>>>
>>>>> This proof can only be understood only by those having sufficient
>>>>> technical competence in:
>>>>> (a) software engineering - recognizing infinite recursion in C/x86
>>>>> (b) the x86 programming language
>>>>> (c) the C programming language and
>>>>> (d) the details of how C is translated into x86 by the Microsoft C
>>>>> compilers.
>>>>
>>>> (a) I have been a software developer/engineer since 1993 and am
>>>> able to recognize infinite recursion and additionally, and more
>>>> importantly, a lack of infinite recursion.
>>>
>>> This has been disproven in that you did not see this:
>>>
>>>   >>>> H sees that P is calling the same function from the same machine
>>>   >>>> address with identical parameters, twice in sequence. This is
>>>   >>>> the infinite recursion (infinitely nested simulation)
>>>   >>>> non-halting behavior pattern.
>> I am not talking about your braindead simulation, I am talking about
>> the halting problem proofs you are trying to refute: THEY DO NOT HAVE
>> AN INFINITE RECURSION.
>>
>> /Flibble
>>
> 
> My proofs prove that they do.
> That you fail to comprehend this is no rebuttal at all.
> 
You proofs are incorrect, and unsound, just as YOU are.

[toc] | [prev] | [next] | [standalone]

#50305

On 5/12/22 1:45 PM, olcott wrote:
> On 5/12/2022 12:43 PM, Mr Flibble wrote:
>> On Wed, 11 May 2022 19:23:45 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 5/11/2022 2:11 PM, Mr Flibble wrote:
>>>> On Wed, 11 May 2022 13:07:16 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
>>>>> proofs ]
>>>>>
>>>>> The x86utm operating system was created so that every detail of the
>>>>> conventional halting problem counter example could be fully
>>>>> specified in C/x86.
>>>>>
>>>>>       In computability theory, the halting problem is the
>>>>>       problem of determining, from a description of an
>>>>>       arbitrary computer program and an input, whether the
>>>>>       program will finish running, or continue to run forever...
>>>>>
>>>>>       For any program f that might determine if programs halt,
>>>>>       a "pathological" program g, called with some input, can
>>>>>       pass its own source and its input to f and then specifically
>>>>>       do the opposite of what f predicts g will do. No f can exist
>>>>>       that handles this case.
>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> This exact same relationship of f(g,g) was created as H(P,P), shown
>>>>> below.
>>>>>
>>>>> This is the overview of the method for proving that this analysis
>>>>> is correct:
>>>>> (a) Verify that the execution trace of P by H is correct by
>>>>> comparing this execution trace to the ax86 source-code of P.
>>>>>
>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>
>>>>> This proof can only be understood only by those having sufficient
>>>>> technical competence in:
>>>>> (a) software engineering (recognizing infinite recursion in C and
>>>>> x86 code) (b) the x86 programming language
>>>>> (c) the C programming language and
>>>>> (d) the details of how C is translated into x86 by the Microsoft C
>>>>> compilers.
>>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>      if (H(x, x))
>>>>>        HERE: goto HERE;
>>>>>      return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>      Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01)  55              push ebp
>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001358](01)  50              push eax
>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [0000135c](01)  51              push ecx
>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>> [00001362](03)  83c408          add esp,+08
>>>>> [00001365](02)  85c0            test eax,eax
>>>>> [00001367](02)  7402            jz 0000136b
>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>> [0000136b](01)  5d              pop ebp
>>>>> [0000136c](01)  c3              ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> _main()
>>>>> [00001372](01)  55              push ebp
>>>>> [00001373](02)  8bec            mov ebp,esp
>>>>> [00001375](05)  6852130000      push 00001352 // push P
>>>>> [0000137a](05)  6852130000      push 00001352 // push P
>>>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>>>> [00001384](03)  83c408          add esp,+08
>>>>> [00001387](01)  50              push eax
>>>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>>>> [00001392](03)  83c408          add esp,+08
>>>>> [00001395](02)  33c0            xor eax,eax
>>>>> [00001397](01)  5d              pop ebp
>>>>> [00001398](01)  c3              ret
>>>>> Size in bytes:(0039) [00001398]
>>>>>
>>>>>        machine   stack     stack     machine    assembly
>>>>>        address   address   data      code       language
>>>>>        ========  ========  ========  =========  =============
>>>>> ...[00001372][0010229e][00000000] 55         push ebp
>>>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push
>>>>> P ...[0000137a][00102296][00001352] 6852130000 push 00001352 //
>>>>> push P ...[0000137f][00102292][00001384] e81efeffff call 000011a2
>>>>> // call H
>>>>>
>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>> at:212352 ...[00001352][0021233e][00212342] 55         push ebp
>>>>>    // enter P ...[00001353][0021233e][00212342] 8bec       mov
>>>>> ebp,esp ...[00001355][0021233e][00212342] 8b4508     mov
>>>>> eax,[ebp+08] ...[00001358][0021233a][00001352] 50         push eax
>>>>>       // push P ...[00001359][0021233a][00001352] 8b4d08     mov
>>>>> ecx,[ebp+08] ...[0000135c][00212336][00001352] 51         push ecx
>>>>>       // push P ...[0000135d][00212332][00001362] e840feffff call
>>>>> 000011a2 // call H ...[00001352][0025cd66][0025cd6a] 55
>>>>> push ebp      // enter P ...[00001353][0025cd66][0025cd6a] 8bec
>>>>>     mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508     mov
>>>>> eax,[ebp+08] ...[00001358][0025cd62][00001352] 50         push eax
>>>>>       // push P ...[00001359][0025cd62][00001352] 8b4d08     mov
>>>>> ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51         push ecx
>>>>>       // push P ...[0000135d][0025cd5a][00001362] e840feffff call
>>>>> 000011a2 // call H Local Halt Decider: Infinite Recursion Detected
>>>>> Simulation Stopped
>>>>>
>>>>> H sees that P is calling the same function from the same machine
>>>>> address with identical parameters, twice in sequence. This is the
>>>>> infinite recursion (infinitely nested simulation) non-halting
>>>>> behavior pattern.
>>>>>
>>>>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>>>>> ...[00001387][0010229a][00000000] 50         push eax
>>>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>>>>> "Input_Halts ="
>>>>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call
>>>>> Output Input_Halts = 0
>>>>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>>>>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>>>>> ...[00001397][001022a2][00100000] 5d         pop ebp
>>>>> ...[00001398][001022a6][00000004] c3         ret
>>>>> Number of Instructions Executed(15892) lines = 237 pages
>>>>>
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation
>>>>> (V5)
>>>>>
>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5 
>>>>>
>>>>
>>>> Your simulation approach is erroneous as there is no infinite
>>>> recursion; the key to understanding this is by realizing the
>>>> implication of the words "pass its own source" in the following:
>>>
>>>
>>> YOU IGNORED THIS PART
>>>
>>> This proof can only be understood only by those having sufficient
>>> technical competence in:
>>> (a) software engineering - recognizing infinite recursion in C/x86
>>> (b) the x86 programming language
>>> (c) the C programming language and
>>> (d) the details of how C is translated into x86 by the Microsoft C
>>> compilers.
>>
>> (a) I have been a software developer/engineer since 1993 and am able to
>> recognize infinite recursion and additionally, and more importantly, a
>> lack of infinite recursion.
> 
> This has been disproven in that you did not see this:
> 
>  >>>> H sees that P is calling the same function from the same machine
>  >>>> address with identical parameters, twice in sequence. This is the
>  >>>> infinite recursion (infinitely nested simulation) non-halting
>  >>>> behavior pattern.


Except this pattern you are matching is flawed. The normal (and correct) 
rule requires that no conditional be in the loop, and since H IS 
conditional in its execution of P, you do not match a CORRECT infinite 
recursion pattern. (That or H isn't conditional, at which point it NEVER 
aborts, not even the top level copy, and thus fails to answer).

All you have "proven" is your own ignorance of the topic.

> 
> 
> 
>> (b) I have been familiar with x86 assembly since before 1993
>> (c) I understand and have competence in both C and C++ (having used the
>> latter since 1993)
>> (d) I have written a compiler, have you?
>>
>> /Flibble
>>
> 
> 

[toc] | [prev] | [next] | [standalone]

#50253

On 5/11/22 2:07 PM, olcott wrote:
> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
> 
> The x86utm operating system was created so that every detail of the 
> conventional halting problem counter example could be fully specified in 
> C/x86.
> 
>     In computability theory, the halting problem is the
>     problem of determining, from a description of an
>     arbitrary computer program and an input, whether the
>     program will finish running, or continue to run forever...
> 
>     For any program f that might determine if programs halt,
>     a "pathological" program g, called with some input, can
>     pass its own source and its input to f and then specifically
>     do the opposite of what f predicts g will do. No f can exist
>     that handles this case. https://en.wikipedia.org/wiki/Halting_problem
> 
> This exact same relationship of f(g,g) was created as H(P,P), shown below.
> 
> This is the overview of the method for proving that this analysis is 
> correct:
> (a) Verify that the execution trace of P by H is correct by comparing 
> this execution trace to the ax86 source-code of P.

Except that this fails!!

The x86 code shows that P calls H.

The simulation doesn't but seems to act like a call to H is just a call 
to P.

Even if you edit out the 'setup' code in H, unless H just calls P (and 
not simulates it) the trace is incorrect, but should be showing H 
actually simulating P.

> 
> (b) Verify that this execution trace shows that P is stuck in infinitely 
> nested simulation (a non-halting behavior).

Since the trace is incorrect, the logic is UNSOUND.

> 
> This proof can only be understood only by those having sufficient 
> technical competence in:
> (a) software engineering (recognizing infinite recursion in C and x86 code)
> (b) the x86 programming language
> (c) the C programming language and
> (d) the details of how C is translated into x86 by the Microsoft C 
> compilers.

Which you seem to lack, as you seem to think that a call to H is a call 
to P.

FAIL.

> 
> #include <stdint.h>
> #define u32 uint32_t
> 
> void P(u32 x)
> {
>    if (H(x, x))
>      HERE: goto HERE;
>    return;
> }
> 
> int main()
> {
>    Output("Input_Halts = ", H((u32)P, (u32)P));
> }
> 
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
> 
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efeffff      call 000011a2 // call H
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
> 
>      machine   stack     stack     machine    assembly
>      address   address   data      code       language
>      ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
> 
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

Error begins here.

> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> 
> H sees that P is calling the same function from the same machine address 
> with identical parameters, twice in sequence. This is the infinite 
> recursion (infinitely nested simulation) non-halting behavior pattern.

Nope, logic is ignoring the behavior of H.

> 
> ...[00001384][0010229e][00000000] 83c408     add esp,+08
> ...[00001387][0010229a][00000000] 50         push eax
> ...[00001388][00102296][00000423] 6823040000 push 00000423 // 
> "Input_Halts = "
> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408     add esp,+08
> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
> ...[00001397][001022a2][00100000] 5d         pop ebp
> ...[00001398][001022a6][00000004] c3         ret
> Number of Instructions Executed(15892) lines = 237 pages
> 
> 
> Halting problem undecidability and infinitely nested simulation (V5)
> 
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5 
> 
> 

[toc] | [prev] | [next] | [standalone]

#50256

olcott <NoOne@NoWhere.com> writes:

> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

There are no arguments that can be passed to H so that H can correctly
report on the halting of the function call P(P).  H falls at the first
hurdle: being able to decide the halting of specific function calls.

-- 
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

[toc] | [prev] | [next] | [standalone]

#50259

On 5/11/2022 7:17 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
> 
> There are no arguments that can be passed to H so that H can correctly
> report on the halting of the function call P(P).  H falls at the first
> hurdle: being able to decide the halting of specific function calls.
> 

A halt decider must only correctly report on the halt status of its 
inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.

The HP proof tries to show an input that H gets wrong.
The proof no longer works on my H.



-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#50261

On 5/11/22 8:29 PM, olcott wrote:
> On 5/11/2022 7:17 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
>>
>> There are no arguments that can be passed to H so that H can correctly
>> report on the halting of the function call P(P).  H falls at the first
>> hurdle: being able to decide the halting of specific function calls.
>>
> 
> A halt decider must only correctly report on the halt status of its 
> inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.
> 
> The HP proof tries to show an input that H gets wrong.
> The proof no longer works on my H.
> 

Nope, a Halt Decider must report the Halting Status of the Machine the 
input represents.

Thus P,P is ALWAYS the same computation for a Halting Decider.

The fact that your H and H1 give different answer just proves that they 
aren't Halt Deciders.


Rmebmer xxx decider(foo) needs to give the mapping of xxx(foo) based on 
the definition of xxx.

Halting(P,P) is defined as the halting of the computation P(P).

Thus anything that claims to be a Halting decider need to give the 
answer of Halting(P,P) for H(P,P)

If you claim this isn't possbile because it isn't an input, just proves 
that you can't make a Halting Decider.

This is like if we want to make an 'even decider' as a Turing Machine, 
we can't give a Turing Machine an actual 'Number' but some 
representation of a number.

In the same way the Halt Decider isn't given an ACTUAL program, but a 
representation of it. (and it needs to be a representation of the ENTIRE 
program, or it isn't decidable).

[toc] | [prev] | [next] | [standalone]

#50265

olcott <NoOne@NoWhere.com> writes:

> On 5/11/2022 7:17 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> 
>>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
>> There are no arguments that can be passed to H so that H can correctly
>> report on the halting of the function call P(P).  H falls at the first
>> hurdle: being able to decide the halting of specific function calls.
>
> A halt decider must only correctly report on the halt status of its
> inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.

The "inputs" to H are two pointers.  They have no halt status.  What
H(X,Y) must correctly report on is the halting or otherwise of the
function call X(Y).  Your H does not do the job it is supposed to do.

> The HP proof tries to show an input that H gets wrong.
> The proof no longer works on my H.

You are correct that the proof does not apply to your H.  The proof is
about supposed halt deciders D such that D(X,Y) == true if and only if
X(Y) halts and false otherwise.  Your H is not such a function -- you
can make it do what you like.

-- 
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

[toc] | [prev] | [next] | [standalone]

#50270

On 5/11/2022 8:10 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> On 5/11/2022 7:17 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
>>> There are no arguments that can be passed to H so that H can correctly
>>> report on the halting of the function call P(P).  H falls at the first
>>> hurdle: being able to decide the halting of specific function calls.
>>
>> A halt decider must only correctly report on the halt status of its
>> inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.
> 
> The "inputs" to H are two pointers.  They have no halt status. 

This is such a nutty thing to say when you already know that strings are 
always passed in C as char* pointers.

I am passing strings of machine code as pointers, this is the normal 
correct way to do this.

> What
> H(X,Y) must correctly report on is the halting or otherwise of the
> function call X(Y).  Your H does not do the job it is supposed to do.
> 

int sim(int N, int M)
{
   return (N+M);
}

It turns out that this requirement is the same as requiring that 
sum(3,4) must report on sum(5,6), thus making the requirement itself 
incorrect.

The correct way of viewing the HP proof (and it is often stated this 
way) is that there exists some inputs such that H cannot correctly 
report their halt status.

>> The HP proof tries to show an input that H gets wrong.
>> The proof no longer works on my H.
> 
> You are correct that the proof does not apply to your H.  The proof is
> about supposed halt deciders D such that D(X,Y) == true if and only if
> X(Y) halts and false otherwise.  

That is an incoherent requirement for some cases, thus incorrect for 
these cases.

That incoherent requirement is based on the false assumption that the 
behavior that the input to H(P,P) specifies is the always that exact 
same behavior as P(P).

No one ever noticed that there are rare exceptions where this is not true.

> Your H is not such a function -- you
> can make it do what you like.
> 


-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#50273

On 5/11/22 10:29 PM, olcott wrote:
> On 5/11/2022 8:10 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/11/2022 7:17 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem 
>>>>> proofs ]
>>>> There are no arguments that can be passed to H so that H can correctly
>>>> report on the halting of the function call P(P).  H falls at the first
>>>> hurdle: being able to decide the halting of specific function calls.
>>>
>>> A halt decider must only correctly report on the halt status of its
>>> inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.
>>
>> The "inputs" to H are two pointers.  They have no halt status. 
> 
> This is such a nutty thing to say when you already know that strings are 
> always passed in C as char* pointers.
> 
> I am passing strings of machine code as pointers, this is the normal 
> correct way to do this.

But you violate the "bounds" of that string when you follow the call H 
instruction.



> 
>> What
>> H(X,Y) must correctly report on is the halting or otherwise of the
>> function call X(Y).  Your H does not do the job it is supposed to do.
>>
> 
> int sim(int N, int M)
> {
>    return (N+M);
> }
> 
> It turns out that this requirement is the same as requiring that 
> sum(3,4) must report on sum(5,6), thus making the requirement itself 
> incorrect.

Nope. UNSOUND Logic.

Sum is DEFINED to return the sum of the numbers given as its input.

H,(P,P) if it is a Halt Decider, is DEFINED to return and indication 
about whether P(P) will Halt, read the DEFINITION.

If you disagree with the definition, you have a problem, because you 
aren't allowed to change it, and still work on that same problem.


> 
> The correct way of viewing the HP proof (and it is often stated this 
> way) is that there exists some inputs such that H cannot correctly 
> report their halt status.

Yes, which mean that NO H exist that can correctly report the correct 
answer for ALL inputs.


> 
>>> The HP proof tries to show an input that H gets wrong.
>>> The proof no longer works on my H.
>>
>> You are correct that the proof does not apply to your H.  The proof is
>> about supposed halt deciders D such that D(X,Y) == true if and only if
>> X(Y) halts and false otherwise. 
> 
> That is an incoherent requirement for some cases, thus incorrect for 
> these cases.

No such thing as a incorrect requirement. Requirements ARE requirements.

What you actually mean is that some requirements are intrinsicly not 
obtainable,

> 
> That incoherent requirement is based on the false assumption that the 
> behavior that the input to H(P,P) specifies is the always that exact 
> same behavior as P(P).

Nope. You have the problem backwards.

xxx Deciders START with a defined mapping, and need to define how to 
present that to the code to decide it.

Halting is about a Turing Machine and an Input to that machine.

A Halt Decider needs to define how to provide a computable 
representation fpr that machine and input and have an algorithm to give 
the right answer.

If there are machines/inputs that can't be properly expresses, that just 
shows that the mapping is not computable, and no such decider exists.

IF we can't ask your H if P(P) will halt, then H fails to be a Halting 
Decider,

> 
> No one ever noticed that there are rare exceptions where this is not true.

Nope, there are no exceptions, you just don't understand what an xxx 
decider is.

> 
>> Your H is not such a function -- you
>> can make it do what you like.
>>
> 
> 

[toc] | [prev] | [next] | [standalone]

#50309

olcott <NoOne@NoWhere.com> writes:

> On 5/11/2022 8:10 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> 
>>> On 5/11/2022 7:17 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
>>>> There are no arguments that can be passed to H so that H can correctly
>>>> report on the halting of the function call P(P).  H falls at the first
>>>> hurdle: being able to decide the halting of specific function calls.
>>>
>>> A halt decider must only correctly report on the halt status of its
>>> inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.
>>
>> The "inputs" to H are two pointers.  They have no halt status. 
>
> This is such a nutty thing to say when you already know that strings
> are always passed in C as char* pointers.

No pair of pointers has a halt status -- a fact I think you are aware of
since you appear to using this silly mantra to hide your key problem: H
gives the wrong answer as far as everyone but you is concerned.

In the context of H, what has a halt status is a function call.  What H
should report is the whether calling the first pointer with the second
as its argument would or would not halt.

Your vague language about the "halt status of its inputs" is
deliberately designed to hide the truth: that H is not doing what it
should because H(P,P) == false even though P(P) halts.

> I am passing strings of machine code as pointers, this is the normal
> correct way to do this.

Maybe you are deliberately misusing the term string in order to draw the
argument way from the main problem: the "inputs" to H don't have a halt
status being simply data.  What H should report is the whether calling
the first pointer with the second as its argument would or would not
halt.  That's why H(P,P) == false is wrong.  P(P) halts.

>> What
>> H(X,Y) must correctly report on is the halting or otherwise of the
>> function call X(Y).  Your H does not do the job it is supposed to do.
>> 
>
> int sum(int N, int M)
> {
>   return (N+M);
> }
>
> It turns out that this requirement is the same as requiring that
> sum(3,4) must report on sum(5,6), thus making the requirement itself
> incorrect.

It does not "turn out" like that.  Your new mantra -- that H reports in
the "halt status of its inputs" -- is just waffle to hide the plain fact
that H(P,P) == false is wrong because P(P) halts.

> The correct way of viewing the HP proof (and it is often stated this
> way) is that there exists some inputs such that H cannot correctly
> report their halt status.

That's not the correct view of the proof.  That's exactly the incorrect
view that got you into trouble, and gets students into trouble everytime
this material is taught badly.  Unfortunately I agree that it's a common
explanation, but that is no excuse.  After 18 years you really should
know what the proof is saying.

> That incoherent requirement is based on the false assumption that the
> behavior that the input to H(P,P) specifies is the always that exact
> same behavior as P(P).

At least you accept that H can't do what the world wants it to.
Apparently you H does something no on cares about: determining the "halt
status if its inputs" which you are now crystal clear about is not the
same as the halt status of P(P).

What amazes me is how seriously you've lost track of what matters.  Are
you not interested in the fact -- one you appear now to accept -- that
no function D(X,Y) can determine the halting of the function call X(Y)?
After all, as a programmer, you must know that's what you care about.
Even if your delusion is so profound that you are convinced that the
halting problems is about something else, you must see that this "other
halting problem", the one the world cares about is, unfortunately,
undecidable?

Since you are clear that no function can do what the world wants, what
else have you got to say?  Can persuade anyone to care about what your H
is actually deciding?  Not me.

-- 
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

[toc] | [prev] | [next] | [standalone]

#50316

On 5/12/2022 5:54 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> On 5/11/2022 8:10 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 5/11/2022 7:17 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
>>>>> There are no arguments that can be passed to H so that H can correctly
>>>>> report on the halting of the function call P(P).  H falls at the first
>>>>> hurdle: being able to decide the halting of specific function calls.
>>>>
>>>> A halt decider must only correctly report on the halt status of its
>>>> inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.
>>>
>>> The "inputs" to H are two pointers.  They have no halt status.
>>
>> This is such a nutty thing to say when you already know that strings
>> are always passed in C as char* pointers.
> 
> No pair of pointers has a halt status -- a fact I think you are aware of
> since you appear to using this silly mantra to hide your key problem: H
> gives the wrong answer as far as everyone but you is concerned.
> 
> In the context of H, what has a halt status is a function call.  What H
> should report is the whether calling the first pointer with the second
> as its argument would or would not halt.
> 
> Your vague language about the "halt status of its inputs" is
> deliberately designed to hide the truth: that H is not doing what it
> should because H(P,P) == false even though P(P) halts.
> 

Being a learned-by-rote by-the-book person anything that goes against 
the book must be wrong because the book establishes the conventional 
view. This view is generally locked into academia by groupthink.
https://www.psychologytoday.com/us/basics/groupthink

It is objectively incorrect to say that a halt decider must base its 
halt decision on anything other than the actual behavior actually 
specified by its actual input such as H(P,P) reporting on P(P).

It is also objectively incorrect to assume that actual behavior actually 
specified by the actual input to a halt decider will always be identical 
to the direct execution of the corresponding computation. This was 
previously unknown before my research.

This is where the faulty requirement came from.


-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#50320

On Thu, 12 May 2022 18:21:18 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/12/2022 5:54 PM, Ben wrote:
> > olcott <NoOne@NoWhere.com> writes:
> >   
> >> On 5/11/2022 8:10 PM, Ben wrote:  
> >>> olcott <NoOne@NoWhere.com> writes:
> >>>  
> >>>> On 5/11/2022 7:17 PM, Ben wrote:  
> >>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>  
> >>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
> >>>>>> proofs ]  
> >>>>> There are no arguments that can be passed to H so that H can
> >>>>> correctly report on the halting of the function call P(P).  H
> >>>>> falls at the first hurdle: being able to decide the halting of
> >>>>> specific function calls.  
> >>>>
> >>>> A halt decider must only correctly report on the halt status of
> >>>> its inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.  
> >>>
> >>> The "inputs" to H are two pointers.  They have no halt status.  
> >>
> >> This is such a nutty thing to say when you already know that
> >> strings are always passed in C as char* pointers.  
> > 
> > No pair of pointers has a halt status -- a fact I think you are
> > aware of since you appear to using this silly mantra to hide your
> > key problem: H gives the wrong answer as far as everyone but you is
> > concerned.
> > 
> > In the context of H, what has a halt status is a function call.
> > What H should report is the whether calling the first pointer with
> > the second as its argument would or would not halt.
> > 
> > Your vague language about the "halt status of its inputs" is
> > deliberately designed to hide the truth: that H is not doing what it
> > should because H(P,P) == false even though P(P) halts.
> >   
> 
> Being a learned-by-rote by-the-book person anything that goes against 
> the book must be wrong because the book establishes the conventional 
> view. This view is generally locked into academia by groupthink.
> https://www.psychologytoday.com/us/basics/groupthink

You have a nerve, mate, being a Christian by-the-book (Bible) person
you also hold those negative traits. Christianity is the largest
groupthink of them all.

/Flibble

[toc] | [prev] | [next] | [standalone]

#50325

On 5/12/2022 6:24 PM, Mr Flibble wrote:
> On Thu, 12 May 2022 18:21:18 -0500
> olcott <NoOne@NoWhere.com> wrote:
> 
>> On 5/12/2022 5:54 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>    
>>>> On 5/11/2022 8:10 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>   
>>>>>> On 5/11/2022 7:17 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>   
>>>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
>>>>>>>> proofs ]
>>>>>>> There are no arguments that can be passed to H so that H can
>>>>>>> correctly report on the halting of the function call P(P).  H
>>>>>>> falls at the first hurdle: being able to decide the halting of
>>>>>>> specific function calls.
>>>>>>
>>>>>> A halt decider must only correctly report on the halt status of
>>>>>> its inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.
>>>>>
>>>>> The "inputs" to H are two pointers.  They have no halt status.
>>>>
>>>> This is such a nutty thing to say when you already know that
>>>> strings are always passed in C as char* pointers.
>>>
>>> No pair of pointers has a halt status -- a fact I think you are
>>> aware of since you appear to using this silly mantra to hide your
>>> key problem: H gives the wrong answer as far as everyone but you is
>>> concerned.
>>>
>>> In the context of H, what has a halt status is a function call.
>>> What H should report is the whether calling the first pointer with
>>> the second as its argument would or would not halt.
>>>
>>> Your vague language about the "halt status of its inputs" is
>>> deliberately designed to hide the truth: that H is not doing what it
>>> should because H(P,P) == false even though P(P) halts.
>>>    
>>
>> Being a learned-by-rote by-the-book person anything that goes against
>> the book must be wrong because the book establishes the conventional
>> view. This view is generally locked into academia by groupthink.
>> https://www.psychologytoday.com/us/basics/groupthink
> 
> You have a nerve, mate, being a Christian by-the-book (Bible) person

Not me. I believe that God intentionally put lots of bullshit in the 
bible so that people could learn actual spiritual discernment.

> you also hold those negative traits. Christianity is the largest
> groupthink of them all.
> 
> /Flibble
> 

I am much more ruggedly individualist than anyone else that you have 
ever even heard of.

I always hypothesize that everything that anyone has ever told me is 
possibly incorrect until after I conclusively prove otherwise.


-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#50332

olcott <NoOne@NoWhere.com> writes:

> On 5/12/2022 5:54 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> 
>>> On 5/11/2022 8:10 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 5/11/2022 7:17 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
>>>>>> There are no arguments that can be passed to H so that H can correctly
>>>>>> report on the halting of the function call P(P).  H falls at the first
>>>>>> hurdle: being able to decide the halting of specific function calls.
>>>>>
>>>>> A halt decider must only correctly report on the halt status of its
>>>>> inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.
>>>>
>>>> The "inputs" to H are two pointers.  They have no halt status.
>>>
>>> This is such a nutty thing to say when you already know that strings
>>> are always passed in C as char* pointers.
>> No pair of pointers has a halt status -- a fact I think you are aware of
>> since you appear to using this silly mantra to hide your key problem: H
>> gives the wrong answer as far as everyone but you is concerned.
>> In the context of H, what has a halt status is a function call.  What H
>> should report is the whether calling the first pointer with the second
>> as its argument would or would not halt.
>> Your vague language about the "halt status of its inputs" is
>> deliberately designed to hide the truth: that H is not doing what it
>> should because H(P,P) == false even though P(P) halts.
>
> Being a learned-by-rote by-the-book person anything that goes against
> the book must be wrong because the book establishes the conventional
> view. This view is generally locked into academia by groupthink.
> https://www.psychologytoday.com/us/basics/groupthink

Being an ignorant-of-the-subject person, you don't know what you are
talking about.

> It is objectively incorrect to say that a halt decider must base its
> halt decision on anything other than the actual behavior actually
> specified by its actual input such as H(P,P) reporting on P(P).

You have entered the twilight zone.  What is objectively correct is
based on the definition of the problem.  If there are no "inputs" to H
that specify the call P(P) then H is useless.  But at least you accept
that H can't report on P(P) correctly.  You used to simply pretend that
the wrong answer was the right one.

I am stunned that you don't see that you can't avoid the problem.  What
everyone wants -- a function D(X,Y) to determine if X(Y) would or would
not halt -- is not possible and you are admitting that fact as if it's
of no interest to you.  You are wrong about why there is no such D, but
you agree that the problem can't be solved.

> It is also objectively incorrect to assume that actual behavior
> actually specified by the actual input to a halt decider will always
> be identical to the direct execution of the corresponding
> computation.

One way or another, we only care about the useful one.  What the "actual
behavior actually specified by the actual input" is of no interest to
us if it does correspond the "direct execution of the corresponding
computation".  We want something that tells up about direct function
calls.

> This was previously unknown before my research.

Don't be so pompous!  Your new mantra is just a ruse to draw attention
away from the fact that you clearly accept that what everyone else has
been talking about can't be done.

-- 
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

[toc] | [prev] | [next] | [standalone]

#50340 — Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ]

On 5/12/2022 7:35 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> On 5/12/2022 5:54 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 5/11/2022 8:10 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 5/11/2022 7:17 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
>>>>>>> There are no arguments that can be passed to H so that H can correctly
>>>>>>> report on the halting of the function call P(P).  H falls at the first
>>>>>>> hurdle: being able to decide the halting of specific function calls.
>>>>>>
>>>>>> A halt decider must only correctly report on the halt status of its
>>>>>> inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.
>>>>>
>>>>> The "inputs" to H are two pointers.  They have no halt status.
>>>>
>>>> This is such a nutty thing to say when you already know that strings
>>>> are always passed in C as char* pointers.
>>> No pair of pointers has a halt status -- a fact I think you are aware of
>>> since you appear to using this silly mantra to hide your key problem: H
>>> gives the wrong answer as far as everyone but you is concerned.
>>> In the context of H, what has a halt status is a function call.  What H
>>> should report is the whether calling the first pointer with the second
>>> as its argument would or would not halt.
>>> Your vague language about the "halt status of its inputs" is
>>> deliberately designed to hide the truth: that H is not doing what it
>>> should because H(P,P) == false even though P(P) halts.
>>
>> Being a learned-by-rote by-the-book person anything that goes against
>> the book must be wrong because the book establishes the conventional
>> view. This view is generally locked into academia by groupthink.
>> https://www.psychologytoday.com/us/basics/groupthink
> 
> Being an ignorant-of-the-subject person, you don't know what you are
> talking about.
> 
>> It is objectively incorrect to say that a halt decider must base its
>> halt decision on anything other than the actual behavior actually
>> specified by its actual input such as H(P,P) reporting on P(P).
> 
> You have entered the twilight zone.  What is objectively correct is
> based on the definition of the problem.  

All of my studies of Gödel 1931, Tarski 1936, the HP and the Liar 
Paradox have been concrete proxies for my study of the philosophical 
foundation of analytical truth.

I examine these things as they fit into the whole grande scheme of the 
nature of truth itself.

It turns out that all "undecidable" problems are only "undecidable" 
because they have very well hidden incoherence.

Taking a form such as this: Provide a natural number N such that N > 7 
and N < 3, the answer must be a natural number.

When the definition of the halting problem directly contradicts the 
definition of a computer science decider, then the definition of the 
halting problem is proven to be incorrect.



-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#50346 — Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ]

On 5/12/22 9:25 PM, olcott wrote:
> On 5/12/2022 7:35 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/12/2022 5:54 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 5/11/2022 8:10 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 5/11/2022 7:17 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem 
>>>>>>>>> proofs ]
>>>>>>>> There are no arguments that can be passed to H so that H can 
>>>>>>>> correctly
>>>>>>>> report on the halting of the function call P(P).  H falls at the 
>>>>>>>> first
>>>>>>>> hurdle: being able to decide the halting of specific function 
>>>>>>>> calls.
>>>>>>>
>>>>>>> A halt decider must only correctly report on the halt status of its
>>>>>>> inputs. H(P,P)==0 and H1(P,P)==1 both do that correctly.
>>>>>>
>>>>>> The "inputs" to H are two pointers.  They have no halt status.
>>>>>
>>>>> This is such a nutty thing to say when you already know that strings
>>>>> are always passed in C as char* pointers.
>>>> No pair of pointers has a halt status -- a fact I think you are 
>>>> aware of
>>>> since you appear to using this silly mantra to hide your key problem: H
>>>> gives the wrong answer as far as everyone but you is concerned.
>>>> In the context of H, what has a halt status is a function call.  What H
>>>> should report is the whether calling the first pointer with the second
>>>> as its argument would or would not halt.
>>>> Your vague language about the "halt status of its inputs" is
>>>> deliberately designed to hide the truth: that H is not doing what it
>>>> should because H(P,P) == false even though P(P) halts.
>>>
>>> Being a learned-by-rote by-the-book person anything that goes against
>>> the book must be wrong because the book establishes the conventional
>>> view. This view is generally locked into academia by groupthink.
>>> https://www.psychologytoday.com/us/basics/groupthink
>>
>> Being an ignorant-of-the-subject person, you don't know what you are
>> talking about.
>>
>>> It is objectively incorrect to say that a halt decider must base its
>>> halt decision on anything other than the actual behavior actually
>>> specified by its actual input such as H(P,P) reporting on P(P).
>>
>> You have entered the twilight zone.  What is objectively correct is
>> based on the definition of the problem. 
> 
> All of my studies of Gödel 1931, Tarski 1936, the HP and the Liar 
> Paradox have been concrete proxies for my study of the philosophical 
> foundation of analytical truth.
> 
> I examine these things as they fit into the whole grande scheme of the 
> nature of truth itself.
> 
> It turns out that all "undecidable" problems are only "undecidable" 
> because they have very well hidden incoherence.
> 
> Taking a form such as this: Provide a natural number N such that N > 7 
> and N < 3, the answer must be a natural number.
> 
> When the definition of the halting problem directly contradicts the 
> definition of a computer science decider, then the definition of the 
> halting problem is proven to be incorrect.
> 
> 
> 

Nope, the problems do NOT state such an impossibility.

For example, machine M appied to inut w WILL Halt or Not, so its Halting 
property is a Truth Bearer, and thus, the Definition of the Halting 
Problem is NOT "incorrect"

The issue is that no "Computation" can always be able to determine this 
property, because we are able to make a machine that can confound any 
other machine that is trying to do that determination.

This doesn't make the problem contradictory, just uncomptable.

Only by adding a rule that the only things are provable can be true, do 
you run into the contradiction, which is what proves that such a rule is 
incorrect, at least in any logic system capable of describing such 
computations.

All you have proved is that you don't understand this level of subtlty 
in logic, that different fields can work under somewhat different "rules".

Some system, which limit the compexity of what operations you can 
perform on statements, can include rules like for a statement to be a 
truthbearer, it needs to be provable or refutable. While others, because 
they allow for higher order logical operations, lose the ability for 
constraints like that.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.theory

csiph-web