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

Groups > comp.theory > #49383 > unrolled thread

on "infinitely recursive" and "recursive"

Back to article view | Back to comp.theory

Contents

  on "infinitely recursive" and "recursive" Mr Flibble <flibble@reddwarf.jmc> - 2022-05-01 13:37 +0100
    Re: on "infinitely recursive" and "recursive" Ben <ben.usenet@bsb.me.uk> - 2022-05-01 15:39 +0100
      Re: on "infinitely recursive" and "recursive" polcott <polcott2@gmail.com> - 2022-05-01 11:05 -0500
        Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-01 13:14 -0400
        Re: on "infinitely recursive" and "recursive" Ben <ben.usenet@bsb.me.uk> - 2022-05-02 00:50 +0100
      Re: on "infinitely recursive" and "recursive" Mr Flibble <flibble@reddwarf.jmc> - 2022-05-01 17:17 +0100
        Re: on "infinitely recursive" and "recursive" Ben <ben.usenet@bsb.me.uk> - 2022-05-02 00:44 +0100
          Re: on "infinitely recursive" and "recursive" Mr Flibble <flibble@reddwarf.jmc> - 2022-05-02 01:26 +0100
            Re: on "infinitely recursive" and "recursive" André G. Isaak <agisaak@gm.invalid> - 2022-05-01 18:29 -0600
              Re: on "infinitely recursive" and "recursive" Mr Flibble <flibble@reddwarf.jmc> - 2022-05-02 01:31 +0100
            Re: on "infinitely recursive" and "recursive" Ben <ben.usenet@bsb.me.uk> - 2022-05-02 01:49 +0100
    Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-01 13:08 -0400
      Re: on "infinitely recursive" and "recursive" olcott <polcott2@gmail.com> - 2022-05-01 12:23 -0500
        Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-01 14:04 -0400
      Re: on "infinitely recursive" and "recursive" André G. Isaak <agisaak@gm.invalid> - 2022-05-01 11:30 -0600
        Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-01 14:10 -0400
        Re: on "infinitely recursive" and "recursive" olcott <NoOne@NoWhere.com> - 2022-05-01 13:33 -0500
          Re: on "infinitely recursive" and "recursive" André G. Isaak <agisaak@gm.invalid> - 2022-05-01 12:43 -0600
            Re: on "infinitely recursive" and "recursive" olcott <NoOne@NoWhere.com> - 2022-05-01 14:05 -0500
              Re: on "infinitely recursive" and "recursive" André G. Isaak <agisaak@gm.invalid> - 2022-05-01 13:19 -0600
                Re: on "infinitely recursive" and "recursive" olcott <NoOne@NoWhere.com> - 2022-05-01 14:24 -0500
                  Re: on "infinitely recursive" and "recursive" André G. Isaak <agisaak@gm.invalid> - 2022-05-01 13:35 -0600
                    Re: on "infinitely recursive" and "recursive" olcott <NoOne@NoWhere.com> - 2022-05-01 14:43 -0500
                      Re: on "infinitely recursive" and "recursive" André G. Isaak <agisaak@gm.invalid> - 2022-05-01 13:45 -0600
                        Re: on "infinitely recursive" and "recursive" olcott <NoOne@NoWhere.com> - 2022-05-01 14:56 -0500
                      Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-01 15:49 -0400
                  Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-01 15:43 -0400
              Re: on "infinitely recursive" and "recursive" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-01 12:21 -0700
                Re: on "infinitely recursive" and "recursive" olcott <NoOne@NoWhere.com> - 2022-05-01 14:27 -0500
                  Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-01 15:52 -0400
                Re: on "infinitely recursive" and "recursive" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-05-01 14:10 -0700
                  Re: on "infinitely recursive" and "recursive" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-02 02:53 -0700
                    Re: on "infinitely recursive" and "recursive" olcott <polcott2@gmail.com> - 2022-05-02 08:31 -0500
                      Re: on "infinitely recursive" and "recursive" Ben <ben.usenet@bsb.me.uk> - 2022-05-02 15:46 +0100
                      Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-02 18:43 -0400
              Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-01 15:27 -0400
          Re: on "infinitely recursive" and "recursive" Richard Damon <Richard@Damon-Family.org> - 2022-05-01 15:13 -0400

Page 2 of 2 — ← Prev page 1 [2]

#49431

On 5/1/2022 2:19 PM, André G. Isaak wrote:
> On 2022-05-01 13:05, olcott wrote:
>> On 5/1/2022 1:43 PM, André G. Isaak wrote:
>>> On 2022-05-01 12:33, olcott wrote:
>>>> On 5/1/2022 12:30 PM, André G. Isaak wrote:
>>>>> On 2022-05-01 11:08, Richard Damon wrote:
>>>>>> On 5/1/22 8:37 AM, Mr Flibble wrote:
>>>>>>> Recursive definitions are fine, infinitely recursive definitions 
>>>>>>> (such
>>>>>>> as The Halting Problem) are INVALID.
>>>>>>>
>>>>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> And the Halting Problem isn't recursive at all, so it can't be 
>>>>>> infinity recursive. NOTHING in the definition refers to itself.
>>>>>>
>>>>>> The counter example is, in a way, "recursive", but that recursion 
>>>>>> can only become infinite if the proposed Halt Decider turns out to 
>>>>>> fail to be a Halt Decider.
>>>>>
>>>>> Actually, even the counterexample is not recursive. It only becomes 
>>>>> recursive (or recursive-like) if one assumes that H bases its 
>>>>> answer on the simulation of its input. And the proof certainly does 
>>>>> not require that to be the case.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Since the definition of H is wide open and can be anything at all 
>>>> that meets the spec, if any of these definitions make the 
>>>> "impossible" input decidable then this refutes the proofs.
>>>
>>> But the spec is as follows:
>>>
>>> Hq0 <M> w ⊢* Hqy iff M applied to w halts
>>>            ⊢* Hqn otherwise
>>>
>>> Yours fails to meet this spec.
>>>
>>> André
>>>
>>
>> You keep insisting that H must be a mind reader and base it decision 
>> on something other than its input parameters when you already know 
>> that all deciders compute the mapping from their inputs to their own 
>> final state.
> 
> Even if your view that TM's can only answer about their inputs were 
> true, the spec is what the spec is. Not every spec can be met.
> 

I am saying that deciders are defined to compute the mapping from their 
input parameters to their own accept or reject state, thus any 
"specification" that contradicts this is fundamentally 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]

#49435

On 2022-05-01 13:24, olcott wrote:
> On 5/1/2022 2:19 PM, André G. Isaak wrote:
>> On 2022-05-01 13:05, olcott wrote:
>>> On 5/1/2022 1:43 PM, André G. Isaak wrote:
>>>> On 2022-05-01 12:33, olcott wrote:
>>>>> On 5/1/2022 12:30 PM, André G. Isaak wrote:
>>>>>> On 2022-05-01 11:08, Richard Damon wrote:
>>>>>>> On 5/1/22 8:37 AM, Mr Flibble wrote:
>>>>>>>> Recursive definitions are fine, infinitely recursive definitions 
>>>>>>>> (such
>>>>>>>> as The Halting Problem) are INVALID.
>>>>>>>>
>>>>>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> And the Halting Problem isn't recursive at all, so it can't be 
>>>>>>> infinity recursive. NOTHING in the definition refers to itself.
>>>>>>>
>>>>>>> The counter example is, in a way, "recursive", but that recursion 
>>>>>>> can only become infinite if the proposed Halt Decider turns out 
>>>>>>> to fail to be a Halt Decider.
>>>>>>
>>>>>> Actually, even the counterexample is not recursive. It only 
>>>>>> becomes recursive (or recursive-like) if one assumes that H bases 
>>>>>> its answer on the simulation of its input. And the proof certainly 
>>>>>> does not require that to be the case.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Since the definition of H is wide open and can be anything at all 
>>>>> that meets the spec, if any of these definitions make the 
>>>>> "impossible" input decidable then this refutes the proofs.
>>>>
>>>> But the spec is as follows:
>>>>
>>>> Hq0 <M> w ⊢* Hqy iff M applied to w halts
>>>>            ⊢* Hqn otherwise
>>>>
>>>> Yours fails to meet this spec.
>>>>
>>>> André
>>>>
>>>
>>> You keep insisting that H must be a mind reader and base it decision 
>>> on something other than its input parameters when you already know 
>>> that all deciders compute the mapping from their inputs to their own 
>>> final state.
>>
>> Even if your view that TM's can only answer about their inputs were 
>> true, the spec is what the spec is. Not every spec can be met.
>>
> 
> I am saying that deciders are defined to compute the mapping from their 
> input parameters to their own accept or reject state, thus any 
> "specification" that contradicts this is fundamentally incorrect.

Specifications can't be 'correct' or 'incorrect'. They can be doable or 
non-doable.

Since you claim to be a software engineer, consider the following:

Someone hires you to write some program. They tell you what the program 
must do and what they ask for is simply not possible for a computer 
program to do (for example, they want you to solve an NP-hard problem in 
linear time).

Would you:

(a) Tell them that the specification is simply not doable

or

(b) Invest thousands of man-hours in writing a program that does 
something not exactly like the spec on the assumption that they will pay 
you for this after you explain to them that their specification was 
incorrect and that therefore this must be what they actually wanted?

The spec is what you WANT the Turing Machine to do. It may or may not be 
possible, but if it isn't possible that doesn't change what it was you 
wanted it to do.

André

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

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

#49436

On 5/1/2022 2:35 PM, André G. Isaak wrote:
> On 2022-05-01 13:24, olcott wrote:
>> On 5/1/2022 2:19 PM, André G. Isaak wrote:
>>> On 2022-05-01 13:05, olcott wrote:
>>>> On 5/1/2022 1:43 PM, André G. Isaak wrote:
>>>>> On 2022-05-01 12:33, olcott wrote:
>>>>>> On 5/1/2022 12:30 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-01 11:08, Richard Damon wrote:
>>>>>>>> On 5/1/22 8:37 AM, Mr Flibble wrote:
>>>>>>>>> Recursive definitions are fine, infinitely recursive 
>>>>>>>>> definitions (such
>>>>>>>>> as The Halting Problem) are INVALID.
>>>>>>>>>
>>>>>>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> And the Halting Problem isn't recursive at all, so it can't be 
>>>>>>>> infinity recursive. NOTHING in the definition refers to itself.
>>>>>>>>
>>>>>>>> The counter example is, in a way, "recursive", but that 
>>>>>>>> recursion can only become infinite if the proposed Halt Decider 
>>>>>>>> turns out to fail to be a Halt Decider.
>>>>>>>
>>>>>>> Actually, even the counterexample is not recursive. It only 
>>>>>>> becomes recursive (or recursive-like) if one assumes that H bases 
>>>>>>> its answer on the simulation of its input. And the proof 
>>>>>>> certainly does not require that to be the case.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Since the definition of H is wide open and can be anything at all 
>>>>>> that meets the spec, if any of these definitions make the 
>>>>>> "impossible" input decidable then this refutes the proofs.
>>>>>
>>>>> But the spec is as follows:
>>>>>
>>>>> Hq0 <M> w ⊢* Hqy iff M applied to w halts
>>>>>            ⊢* Hqn otherwise
>>>>>
>>>>> Yours fails to meet this spec.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> You keep insisting that H must be a mind reader and base it decision 
>>>> on something other than its input parameters when you already know 
>>>> that all deciders compute the mapping from their inputs to their own 
>>>> final state.
>>>
>>> Even if your view that TM's can only answer about their inputs were 
>>> true, the spec is what the spec is. Not every spec can be met.
>>>
>>
>> I am saying that deciders are defined to compute the mapping from 
>> their input parameters to their own accept or reject state, thus any 
>> "specification" that contradicts this is fundamentally incorrect.
> 
> Specifications can't be 'correct' or 'incorrect'. They can be doable or 
> non-doable.
> 

If a spec says that cats are dogs or a decider computes the mapping from 
non-inputs its contradict the definition of cat, dog, decider, thus 
disagrees with established facts.

Anything that disagrees with established facts is always necessarily 
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]

#49439

On 2022-05-01 13:43, olcott wrote:

>> Specifications can't be 'correct' or 'incorrect'. They can be doable 
>> or non-doable.
>>
> 
> If a spec says that cats are dogs or a decider computes the mapping from 
> non-inputs its contradict the definition of cat, dog, decider, thus 
> disagrees with established facts.
> 
> Anything that disagrees with established facts is always necessarily 
> incorrect.


And, as usual, you snipped all of the material which came afterwards 
which addressed your misconception. Why not actually answer the 
hypothetical I asked?

André


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

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

#49444

On 5/1/2022 2:45 PM, André G. Isaak wrote:
> On 2022-05-01 13:43, olcott wrote:
> 
>>> Specifications can't be 'correct' or 'incorrect'. They can be doable 
>>> or non-doable.
>>>
>>
>> If a spec says that cats are dogs or a decider computes the mapping 
>> from non-inputs its contradict the definition of cat, dog, decider, 
>> thus disagrees with established facts.
>>
>> Anything that disagrees with established facts is always necessarily 
>> incorrect.
> 
> 
> And, as usual, you snipped all of the material which came afterwards 
> which addressed your misconception. Why not actually answer the 
> hypothetical I asked?
> 
> André
> 
> 

The point is that anything that contradicts established facts is always 
necessarily incorrect. When the halting problem specifies that the halt 
decider must make its decision on the basis of non-inputs it contradicts 
established facts (the definition of a decider) and is therefore WRONG.



-- 
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]

#49441

On 5/1/22 3:43 PM, olcott wrote:
> On 5/1/2022 2:35 PM, André G. Isaak wrote:
>> On 2022-05-01 13:24, olcott wrote:
>>> On 5/1/2022 2:19 PM, André G. Isaak wrote:
>>>> On 2022-05-01 13:05, olcott wrote:
>>>>> On 5/1/2022 1:43 PM, André G. Isaak wrote:
>>>>>> On 2022-05-01 12:33, olcott wrote:
>>>>>>> On 5/1/2022 12:30 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-01 11:08, Richard Damon wrote:
>>>>>>>>> On 5/1/22 8:37 AM, Mr Flibble wrote:
>>>>>>>>>> Recursive definitions are fine, infinitely recursive 
>>>>>>>>>> definitions (such
>>>>>>>>>> as The Halting Problem) are INVALID.
>>>>>>>>>>
>>>>>>>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And the Halting Problem isn't recursive at all, so it can't be 
>>>>>>>>> infinity recursive. NOTHING in the definition refers to itself.
>>>>>>>>>
>>>>>>>>> The counter example is, in a way, "recursive", but that 
>>>>>>>>> recursion can only become infinite if the proposed Halt Decider 
>>>>>>>>> turns out to fail to be a Halt Decider.
>>>>>>>>
>>>>>>>> Actually, even the counterexample is not recursive. It only 
>>>>>>>> becomes recursive (or recursive-like) if one assumes that H 
>>>>>>>> bases its answer on the simulation of its input. And the proof 
>>>>>>>> certainly does not require that to be the case.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Since the definition of H is wide open and can be anything at all 
>>>>>>> that meets the spec, if any of these definitions make the 
>>>>>>> "impossible" input decidable then this refutes the proofs.
>>>>>>
>>>>>> But the spec is as follows:
>>>>>>
>>>>>> Hq0 <M> w ⊢* Hqy iff M applied to w halts
>>>>>>            ⊢* Hqn otherwise
>>>>>>
>>>>>> Yours fails to meet this spec.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> You keep insisting that H must be a mind reader and base it 
>>>>> decision on something other than its input parameters when you 
>>>>> already know that all deciders compute the mapping from their 
>>>>> inputs to their own final state.
>>>>
>>>> Even if your view that TM's can only answer about their inputs were 
>>>> true, the spec is what the spec is. Not every spec can be met.
>>>>
>>>
>>> I am saying that deciders are defined to compute the mapping from 
>>> their input parameters to their own accept or reject state, thus any 
>>> "specification" that contradicts this is fundamentally incorrect.
>>
>> Specifications can't be 'correct' or 'incorrect'. They can be doable 
>> or non-doable.
>>
> 
> If a spec says that cats are dogs or a decider computes the mapping from 
> non-inputs its contradict the definition of cat, dog, decider, thus 
> disagrees with established facts.
> 
> Anything that disagrees with established facts is always necessarily 
> incorrect.
> 
> 

No, if someone contracts you to deliver a Cat that is a Dog, then you 
need to deliver them a Cat that is a Dog, or just refuse the contract. 
If you deliver a Cat that isn't a Dog, or a Dog that isn't a Cat, you 
haven't met the terms of the contract. Saying the contract is 
"illogical" doesn't mean that you get to change it. You need to either 
accept it or reject it.

If Halting requires deciding on something that can't be given as an 
input, then that just proves that you can't decide Halting with a Turing 
Machine (or equivalent computation), thus PROVING the theory, not 
refuting it.

The Problem is the Problem. The claim is that the Problem can't be 
solved under the rules. If you say the only way to solve the problem is 
to change the rules, that is AGREEING with the claim.

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

#49437

On 5/1/22 3:24 PM, olcott wrote:
> On 5/1/2022 2:19 PM, André G. Isaak wrote:
>> On 2022-05-01 13:05, olcott wrote:
>>> On 5/1/2022 1:43 PM, André G. Isaak wrote:
>>>> On 2022-05-01 12:33, olcott wrote:
>>>>> On 5/1/2022 12:30 PM, André G. Isaak wrote:
>>>>>> On 2022-05-01 11:08, Richard Damon wrote:
>>>>>>> On 5/1/22 8:37 AM, Mr Flibble wrote:
>>>>>>>> Recursive definitions are fine, infinitely recursive definitions 
>>>>>>>> (such
>>>>>>>> as The Halting Problem) are INVALID.
>>>>>>>>
>>>>>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> And the Halting Problem isn't recursive at all, so it can't be 
>>>>>>> infinity recursive. NOTHING in the definition refers to itself.
>>>>>>>
>>>>>>> The counter example is, in a way, "recursive", but that recursion 
>>>>>>> can only become infinite if the proposed Halt Decider turns out 
>>>>>>> to fail to be a Halt Decider.
>>>>>>
>>>>>> Actually, even the counterexample is not recursive. It only 
>>>>>> becomes recursive (or recursive-like) if one assumes that H bases 
>>>>>> its answer on the simulation of its input. And the proof certainly 
>>>>>> does not require that to be the case.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Since the definition of H is wide open and can be anything at all 
>>>>> that meets the spec, if any of these definitions make the 
>>>>> "impossible" input decidable then this refutes the proofs.
>>>>
>>>> But the spec is as follows:
>>>>
>>>> Hq0 <M> w ⊢* Hqy iff M applied to w halts
>>>>            ⊢* Hqn otherwise
>>>>
>>>> Yours fails to meet this spec.
>>>>
>>>> André
>>>>
>>>
>>> You keep insisting that H must be a mind reader and base it decision 
>>> on something other than its input parameters when you already know 
>>> that all deciders compute the mapping from their inputs to their own 
>>> final state.
>>
>> Even if your view that TM's can only answer about their inputs were 
>> true, the spec is what the spec is. Not every spec can be met.
>>
> 
> I am saying that deciders are defined to compute the mapping from their 
> input parameters to their own accept or reject state, thus any 
> "specification" that contradicts this is fundamentally incorrect.
> 
>

But an X Decider is defined to say that the mapping it computes must 
match the property X.

Thus a Halt Decider must match the Halting Property which is defined 
based on the compuation the input repesents.

If you are saying we can't define a representation to allow that, that 
is sufficient to say that there can not be any Halt Deciders (defined as 
ones that get all inputs correctly).

You don't get to escape that requirement.

Your H is, by your claim a "Decider", but since the input doesn't 
actually match the required representation for a Halting Decider, it 
isn't one, but just your Poop Decider.

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

#49429

On Sunday, 1 May 2022 at 20:05:17 UTC+1, olcott wrote:
> On 5/1/2022 1:43 PM, André G. Isaak wrote: 
> > On 2022-05-01 12:33, olcott wrote: 
> >> On 5/1/2022 12:30 PM, André G. Isaak wrote: 
> >>> On 2022-05-01 11:08, Richard Damon wrote: 
> >>>> On 5/1/22 8:37 AM, Mr Flibble wrote: 
> >>>>> Recursive definitions are fine, infinitely recursive definitions (such 
> >>>>> as The Halting Problem) are INVALID. 
> >>>>> 
> >>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS. 
> >>>>> 
> >>>>> /Flibble 
> >>>>> 
> >>>> 
> >>>> And the Halting Problem isn't recursive at all, so it can't be 
> >>>> infinity recursive. NOTHING in the definition refers to itself. 
> >>>> 
> >>>> The counter example is, in a way, "recursive", but that recursion 
> >>>> can only become infinite if the proposed Halt Decider turns out to 
> >>>> fail to be a Halt Decider. 
> >>> 
> >>> Actually, even the counterexample is not recursive. It only becomes 
> >>> recursive (or recursive-like) if one assumes that H bases its answer 
> >>> on the simulation of its input. And the proof certainly does not 
> >>> require that to be the case. 
> >>> 
> >>> André 
> >>> 
> >> 
> >> Since the definition of H is wide open and can be anything at all that 
> >> meets the spec, if any of these definitions make the "impossible" 
> >> input decidable then this refutes the proofs. 
> > 
> > But the spec is as follows: 
> > 
> > Hq0 <M> w ⊢* Hqy iff M applied to w halts 
> >           ⊢* Hqn otherwise 
> > 
> > Yours fails to meet this spec. 
> > 
> > André 
> >
> You keep insisting that H must be a mind reader and base it decision on 
> something other than its input parameters when you already know that all 
> deciders compute the mapping from their inputs to their own final state. 
> 
> Thus you gleefully contradict facts that you accept as true. Anyone that 
> contradicts facts that they know are true is a liar by definition.
> 
You must understand that if P(P) haltd ansd H(P,P) reports "non-halting",
anyone is going to say that you don't have a counterexample to Linz.

Now I appreciate that you have fairly consistently said that whilst
P(P) halts, "the input to H  is non-halting". But I don't think anyone has 
a handle on that. It just seems to be nonsense, but it must mean something.
The best I can guess is that the simulating Halt decider H reports 
P(P) as "non-halting" and you have decided that H is correct. So its
simulation and halt decision is by definition not wrong.


I

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

#49433

On 5/1/2022 2:21 PM, Malcolm McLean wrote:
> On Sunday, 1 May 2022 at 20:05:17 UTC+1, olcott wrote:
>> On 5/1/2022 1:43 PM, André G. Isaak wrote:
>>> On 2022-05-01 12:33, olcott wrote:
>>>> On 5/1/2022 12:30 PM, André G. Isaak wrote:
>>>>> On 2022-05-01 11:08, Richard Damon wrote:
>>>>>> On 5/1/22 8:37 AM, Mr Flibble wrote:
>>>>>>> Recursive definitions are fine, infinitely recursive definitions (such
>>>>>>> as The Halting Problem) are INVALID.
>>>>>>>
>>>>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> And the Halting Problem isn't recursive at all, so it can't be
>>>>>> infinity recursive. NOTHING in the definition refers to itself.
>>>>>>
>>>>>> The counter example is, in a way, "recursive", but that recursion
>>>>>> can only become infinite if the proposed Halt Decider turns out to
>>>>>> fail to be a Halt Decider.
>>>>>
>>>>> Actually, even the counterexample is not recursive. It only becomes
>>>>> recursive (or recursive-like) if one assumes that H bases its answer
>>>>> on the simulation of its input. And the proof certainly does not
>>>>> require that to be the case.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Since the definition of H is wide open and can be anything at all that
>>>> meets the spec, if any of these definitions make the "impossible"
>>>> input decidable then this refutes the proofs.
>>>
>>> But the spec is as follows:
>>>
>>> Hq0 <M> w ⊢* Hqy iff M applied to w halts
>>>            ⊢* Hqn otherwise
>>>
>>> Yours fails to meet this spec.
>>>
>>> André
>>>
>> You keep insisting that H must be a mind reader and base it decision on
>> something other than its input parameters when you already know that all
>> deciders compute the mapping from their inputs to their own final state.
>>
>> Thus you gleefully contradict facts that you accept as true. Anyone that
>> contradicts facts that they know are true is a liar by definition.
>>
> You must understand that if P(P) haltd ansd H(P,P) reports "non-halting",
> anyone is going to say that you don't have a counterexample to Linz.
> 
> Now I appreciate that you have fairly consistently said that whilst
> P(P) halts, "the input to H  is non-halting". But I don't think anyone has
> a handle on that. It just seems to be nonsense, but it must mean something.
> The best I can guess is that the simulating Halt decider H reports
> P(P) as "non-halting" and you have decided that H is correct. So its
> simulation and halt decision is by definition not wrong.

I am saying that deciders are defined to compute the mapping from their 
input parameters to their own accept or reject state, thus any 
"specification" that contradicts this is fundamentally incorrect.

H(P,P) does compute the mapping from its input parameters to its own 
final reject state correctly.


-- 
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]

#49442

On 5/1/22 3:27 PM, olcott wrote:
> On 5/1/2022 2:21 PM, Malcolm McLean wrote:
>> On Sunday, 1 May 2022 at 20:05:17 UTC+1, olcott wrote:
>>> On 5/1/2022 1:43 PM, André G. Isaak wrote:
>>>> On 2022-05-01 12:33, olcott wrote:
>>>>> On 5/1/2022 12:30 PM, André G. Isaak wrote:
>>>>>> On 2022-05-01 11:08, Richard Damon wrote:
>>>>>>> On 5/1/22 8:37 AM, Mr Flibble wrote:
>>>>>>>> Recursive definitions are fine, infinitely recursive definitions 
>>>>>>>> (such
>>>>>>>> as The Halting Problem) are INVALID.
>>>>>>>>
>>>>>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> And the Halting Problem isn't recursive at all, so it can't be
>>>>>>> infinity recursive. NOTHING in the definition refers to itself.
>>>>>>>
>>>>>>> The counter example is, in a way, "recursive", but that recursion
>>>>>>> can only become infinite if the proposed Halt Decider turns out to
>>>>>>> fail to be a Halt Decider.
>>>>>>
>>>>>> Actually, even the counterexample is not recursive. It only becomes
>>>>>> recursive (or recursive-like) if one assumes that H bases its answer
>>>>>> on the simulation of its input. And the proof certainly does not
>>>>>> require that to be the case.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Since the definition of H is wide open and can be anything at all that
>>>>> meets the spec, if any of these definitions make the "impossible"
>>>>> input decidable then this refutes the proofs.
>>>>
>>>> But the spec is as follows:
>>>>
>>>> Hq0 <M> w ⊢* Hqy iff M applied to w halts
>>>>            ⊢* Hqn otherwise
>>>>
>>>> Yours fails to meet this spec.
>>>>
>>>> André
>>>>
>>> You keep insisting that H must be a mind reader and base it decision on
>>> something other than its input parameters when you already know that all
>>> deciders compute the mapping from their inputs to their own final state.
>>>
>>> Thus you gleefully contradict facts that you accept as true. Anyone that
>>> contradicts facts that they know are true is a liar by definition.
>>>
>> You must understand that if P(P) haltd ansd H(P,P) reports "non-halting",
>> anyone is going to say that you don't have a counterexample to Linz.
>>
>> Now I appreciate that you have fairly consistently said that whilst
>> P(P) halts, "the input to H  is non-halting". But I don't think anyone 
>> has
>> a handle on that. It just seems to be nonsense, but it must mean 
>> something.
>> The best I can guess is that the simulating Halt decider H reports
>> P(P) as "non-halting" and you have decided that H is correct. So its
>> simulation and halt decision is by definition not wrong.
> 
> I am saying that deciders are defined to compute the mapping from their 
> input parameters to their own accept or reject state, thus any 
> "specification" that contradicts this is fundamentally incorrect.
> 
> H(P,P) does compute the mapping from its input parameters to its own 
> final reject state correctly.
> 
> 

It computes "A" Mapping, not "THE" Mapping, as THE mapping is defined by 
the computation that the input represents, which you say it can't be 
reposisible for, which just says it has rejected being a Halting 
Decider, and is just some poop Decider.

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

#49452

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Sunday, 1 May 2022 at 20:05:17 UTC+1, olcott wrote:
[...]
> You must understand that if P(P) haltd ansd H(P,P) reports "non-halting",
> anyone is going to say that you don't have a counterexample to Linz.
>
> Now I appreciate that you have fairly consistently said that whilst
> P(P) halts, "the input to H  is non-halting". But I don't think anyone has 
> a handle on that. It just seems to be nonsense, but it must mean something.

Why would you assume that?

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#49494

On Sunday, 1 May 2022 at 22:10:48 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes: 
> > On Sunday, 1 May 2022 at 20:05:17 UTC+1, olcott wrote:
> [...]
> > You must understand that if P(P) haltd ansd H(P,P) reports "non-halting", 
> > anyone is going to say that you don't have a counterexample to Linz. 
> > 
> > Now I appreciate that you have fairly consistently said that whilst 
> > P(P) halts, "the input to H is non-halting". But I don't think anyone has 
> > a handle on that. It just seems to be nonsense, but it must mean something.
> Why would you assume that? 
> 
Because PO has so explictly said that P(P) and "the input to H(P,P)" is not
the same thing, and H(P,P) correctly returns "non-halting". 

Ben has tried to pin him down on what needs to be passed to H() to tell if
P(P) halts or not, but to no avail. We have heard the claim that P() behaves
differently when invoked from H(), but in the normal run of things, you'd
expect someone who believes that to arrange things so that P(P) and
H(P,P) are consistent.

So it's all rather odd, it's been persisted in for a very long time, and I
for one don't quite have access to the thinking.

PO might believe that he's created a system in which H_Hat cannot be represented.
Some months ago, there was a lot of talk along the lines of H_Hat being the "liar's 
paradox". However he hasn't actually said that in as many words.

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

#49499

On 5/2/2022 4:53 AM, Malcolm McLean wrote:
> On Sunday, 1 May 2022 at 22:10:48 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> On Sunday, 1 May 2022 at 20:05:17 UTC+1, olcott wrote:
>> [...]
>>> You must understand that if P(P) haltd ansd H(P,P) reports "non-halting",
>>> anyone is going to say that you don't have a counterexample to Linz.
>>>
>>> Now I appreciate that you have fairly consistently said that whilst
>>> P(P) halts, "the input to H is non-halting". But I don't think anyone has
>>> a handle on that. It just seems to be nonsense, but it must mean something.
>> Why would you assume that?
>>
> Because PO has so explictly said that P(P) and "the input to H(P,P)" is not
> the same thing, and H(P,P) correctly returns "non-halting".
> 
> Ben has tried to pin him down on what needs to be passed to H() to tell if
> P(P) halts or not, but to no avail. 

I have answered this many hundreds of times and every single time all of 
my words are totally ignored. This is ridiculously stupid.

When P(P) is executed its execution trace proves that it reaches its own 
final state and halts.

When the input to H(P,P) is correctly simulated its execution trace 
proves that it NEVER reaches its own final state and NEVER halts.

> We have heard the claim that P() behaves
> differently when invoked from H(), but in the normal run of things, you'd
> expect someone who believes that to arrange things so that P(P) and
> H(P,P) are consistent.
> 

Sure and this same way one could arrange that cats are a kind of dog.
P(P) has the actual execution trace that it has. The correctly simulated 
input to H(P,P) has the actual execution trace that it has. This can 
only be arranged differently by some bald faced lie.

> So it's all rather odd, it's been persisted in for a very long time, and I
> for one don't quite have access to the thinking.
> 
> PO might believe that he's created a system in which H_Hat cannot be represented.
> Some months ago, there was a lot of talk along the lines of H_Hat being the "liar's
> paradox". However he hasn't actually said that in as many words.

All deciders compute the mapping from their inputs to their own accept 
or reject state. Since this is a basic fact then those that say a 
decider must compute the mapping from anything other than its input are 
directly contradicting basic facts, thus impossibly correct.


-- 
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]

#49503

olcott <polcott2@gmail.com> writes:

> On 5/2/2022 4:53 AM, Malcolm McLean wrote:

>> Because PO has so explictly said that P(P) and "the input to H(P,P)" is not
>> the same thing, and H(P,P) correctly returns "non-halting".
>> Ben has tried to pin him down on what needs to be passed to H() to tell if
>> P(P) halts or not, but to no avail. 
>
> I have answered this many hundreds of times and every single time all
> of my words are totally ignored. This is ridiculously stupid.

Not once have you answered this key question.  You have avoided it,
posted silly analogies, been sarcastic and employed many other way to
dodge it but you have never addressed it honestly.  Why?  Because you
can't.  You can't say there is no pair of pointers that can be passed to
H so that H will tell us about the halting of P(P), because H should be
able to tell us that.  You can say the pair of pointer is P and P
because you told us that P(P) halts but H(P,P)==false.  All you can do
is say something that sounds vaguely related to keep people talking to
you (which is, after all, the only real goal you have).

> When P(P) is executed its execution trace proves that it reaches its
> own final state and halts.

But H can not tell us that, can it?  There is not pair of pointers that
can be passed to H so that H will tell us that P(P) halts.

> When the input to H(P,P) is correctly simulated its execution trace
> proves that it NEVER reaches its own final state and NEVER halts.

An irrelevant fact (if it is indeed a fact).  Both P(P) and a simulation
of P(P) halt.  H, if it were to meet the spec, would be able to tell us
that.  It can't.

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

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

#49525

On 5/2/22 9:31 AM, olcott wrote:
> On 5/2/2022 4:53 AM, Malcolm McLean wrote:
>> On Sunday, 1 May 2022 at 22:10:48 UTC+1, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>> On Sunday, 1 May 2022 at 20:05:17 UTC+1, olcott wrote:
>>> [...]
>>>> You must understand that if P(P) haltd ansd H(P,P) reports 
>>>> "non-halting",
>>>> anyone is going to say that you don't have a counterexample to Linz.
>>>>
>>>> Now I appreciate that you have fairly consistently said that whilst
>>>> P(P) halts, "the input to H is non-halting". But I don't think 
>>>> anyone has
>>>> a handle on that. It just seems to be nonsense, but it must mean 
>>>> something.
>>> Why would you assume that?
>>>
>> Because PO has so explictly said that P(P) and "the input to H(P,P)" 
>> is not
>> the same thing, and H(P,P) correctly returns "non-halting".
>>
>> Ben has tried to pin him down on what needs to be passed to H() to 
>> tell if
>> P(P) halts or not, but to no avail. 
> 
> I have answered this many hundreds of times and every single time all of 
> my words are totally ignored. This is ridiculously stupid.
> 
> When P(P) is executed its execution trace proves that it reaches its own 
> final state and halts.
> 
> When the input to H(P,P) is correctly simulated its execution trace 
> proves that it NEVER reaches its own final state and NEVER halts.

No, the fact that your simulation of H(P,P) just shows that either H is 
NOT a computation or that the simulation is incorrect.

Until you can show a Turing Machine that meets your claim of acting 
differently when embedded and run independently, when both are given the 
exact same input tape, you are just proven to be lying.

Of course, you can't show that machine, because you can't even write a 
simple even number detector.

> 
>> We have heard the claim that P() behaves
>> differently when invoked from H(), but in the normal run of things, you'd
>> expect someone who believes that to arrange things so that P(P) and
>> H(P,P) are consistent.
>>
> 
> Sure and this same way one could arrange that cats are a kind of dog.
> P(P) has the actual execution trace that it has. The correctly simulated 
> input to H(P,P) has the actual execution trace that it has. This can 
> only be arranged differently by some bald faced lie.

Nope, false analogy.

> 
>> So it's all rather odd, it's been persisted in for a very long time, 
>> and I
>> for one don't quite have access to the thinking.
>>
>> PO might believe that he's created a system in which H_Hat cannot be 
>> represented.
>> Some months ago, there was a lot of talk along the lines of H_Hat 
>> being the "liar's
>> paradox". However he hasn't actually said that in as many words.
> 
> All deciders compute the mapping from their inputs to their own accept 
> or reject state. Since this is a basic fact then those that say a 
> decider must compute the mapping from anything other than its input are 
> directly contradicting basic facts, thus impossibly correct.
> 
> 

And all X deciders need to decide the property X. Since the Halting 
Property is a Property of the Computation described by the input, and 
since H doesn't actually answer that (because you say it can't) it isn't 
actually a Halt Decider (maybe just a POOP Decider), and your claim just 
verifys that Halt Deciders can't exist.

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

#49432

On 5/1/22 3:05 PM, olcott wrote:
> On 5/1/2022 1:43 PM, André G. Isaak wrote:
>> On 2022-05-01 12:33, olcott wrote:
>>> On 5/1/2022 12:30 PM, André G. Isaak wrote:
>>>> On 2022-05-01 11:08, Richard Damon wrote:
>>>>> On 5/1/22 8:37 AM, Mr Flibble wrote:
>>>>>> Recursive definitions are fine, infinitely recursive definitions 
>>>>>> (such
>>>>>> as The Halting Problem) are INVALID.
>>>>>>
>>>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> And the Halting Problem isn't recursive at all, so it can't be 
>>>>> infinity recursive. NOTHING in the definition refers to itself.
>>>>>
>>>>> The counter example is, in a way, "recursive", but that recursion 
>>>>> can only become infinite if the proposed Halt Decider turns out to 
>>>>> fail to be a Halt Decider.
>>>>
>>>> Actually, even the counterexample is not recursive. It only becomes 
>>>> recursive (or recursive-like) if one assumes that H bases its answer 
>>>> on the simulation of its input. And the proof certainly does not 
>>>> require that to be the case.
>>>>
>>>> André
>>>>
>>>
>>> Since the definition of H is wide open and can be anything at all 
>>> that meets the spec, if any of these definitions make the 
>>> "impossible" input decidable then this refutes the proofs.
>>
>> But the spec is as follows:
>>
>> Hq0 <M> w ⊢* Hqy iff M applied to w halts
>>            ⊢* Hqn otherwise
>>
>> Yours fails to meet this spec.
>>
>> André
>>
> 
> You keep insisting that H must be a mind reader and base it decision on 
> something other than its input parameters when you already know that all 
> deciders compute the mapping from their inputs to their own final state.
> 
> Thus you gleefully contradict facts that you accept as true. Anyone that 
> contradicts facts that they know are true is a liar by definition.
> 

We don't demand that it be a mind reader, only that it gives the right 
answer.

If the input paramateres don't represent what is needed to give the 
answer, the the inputs were formed incorrectly and you need to define 
better what you need done to the input to let you give the right answer.

As has been asked, how DO you ask about the comutation H^ applied to the 
representation of H^ (where the representation needed by H^ is the same 
repesentation needed for H to decide this question).

If we can't ask the question, then H just plain fails to be the needed 
decider.

Note, that the "traditional" method of converting a machine description 
to a finite string for input to another Turing Machine is to define some 
UTM that performs the computation.

Thus we get the equivalent definiton, that

H x y -> Hqy iff UTM x y Halts  and -> Hqn iff UTM x y will never Halt.

Note, UTM is an ACTUAL UTM, and thus it will NEVER abort its simulation 
but continue to the end or run forever.

H doesn't need to actually use that UTM, but could be based on it, but 
if so, and it modifies that UTM to abort, then the test is still done on 
the UNMODIFIED UTM that will never abort.

And yes, this does mean that H might be though of as needing to "mind 
read" something it can do, but that just means the problem is shown to 
be impossible.

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

#49426

On 5/1/22 2:33 PM, olcott wrote:
> On 5/1/2022 12:30 PM, André G. Isaak wrote:
>> On 2022-05-01 11:08, Richard Damon wrote:
>>> On 5/1/22 8:37 AM, Mr Flibble wrote:
>>>> Recursive definitions are fine, infinitely recursive definitions (such
>>>> as The Halting Problem) are INVALID.
>>>>
>>>> RECURSIVE and INFINITELY RECURSIVE are TWO DIFFERENT THINGS.
>>>>
>>>> /Flibble
>>>>
>>>
>>> And the Halting Problem isn't recursive at all, so it can't be 
>>> infinity recursive. NOTHING in the definition refers to itself.
>>>
>>> The counter example is, in a way, "recursive", but that recursion can 
>>> only become infinite if the proposed Halt Decider turns out to fail 
>>> to be a Halt Decider.
>>
>> Actually, even the counterexample is not recursive. It only becomes 
>> recursive (or recursive-like) if one assumes that H bases its answer 
>> on the simulation of its input. And the proof certainly does not 
>> require that to be the case.
>>
>> André
>>
> 
> Since the definition of H is wide open and can be anything at all that 
> meets the spec, if any of these definitions make the "impossible" input 
> decidable then this refutes the proofs.
> 

But it does need to meet the requirements as stated and can't say that 
because the way I want to solve the problem leads to an "infinite 
recursion" which is impossible, I get the change the requirements.

H needs to return the answer for what the computation H^ applied to the 
representation of H^ will do, when that H^ is based on the H and calls 
it in the way to ask H what it thinks H^ applied to the representation 
of H^ does and then does the opposite.

If you can't ask H about the computation H^ applied to the 
representaiton of H^, then H just fails to meet the requirements.

Since you say <H^> <H^> isn't the way to ask it, you need to define how 
you do ask it, and then build your H^ on that method and show you get 
the correct answer.

Since H^ asks the exact same question, and then does the opposite, and 
all copies of a computation give the same answer for the same input, H 
is stuck in always being wrong of failing to meet some requriement.

Until you can show that you can build a Turing Machine that gives a 
different answer when asked as a sole machine compared to what it does 
as an Turing Machine embedded in another Turing Machine even when given 
the exact same tape in the two cases, you "proof" doesn't work.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.theory

csiph-web