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

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 */

Mr Flibble <flibble@reddwarf.jmc> writes:

> On Sun, 01 May 2022 15:39:35 +0100
> Ben <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>> > Recursive definitions are fine, infinitely recursive definitions
>> > (such as The Halting Problem) are INVALID.
>>
>> (1) The halting problem is not an infinitely recursive definition.
>>
>> (2) Infinitely recursive definitions are often fine. For example, the
>> list of Fibonacci numbers:
>>
>> fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
>
> FOR FUCKS SAKE, HOW STUPID ARE YOU? THAT IS A RECURSIVE DEFINITION NOT
> AN *INFINITELY* RECURSIVE DEFINITION AS IT TERMINATES.

Look again. What is the terminating condition? There is none.

--
Ben.

polcott <polcott2@gmail.com> writes:

> On 5/1/2022 9:39 AM, Ben wrote:
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>>> Recursive definitions are fine, infinitely recursive definitions (such
>>> as The Halting Problem) are INVALID.
>> (1) The halting problem is not an infinitely recursive definition.
>> (2) Infinitely recursive definitions are often fine. For example, the
>> list of Fibonacci numbers:
>
> This type is never fine:

So you agree that some are valid? How are E and the specification of P
coming along?

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

On Mon, 02 May 2022 00:44:56 +0100
Ben <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc> writes:
>
> > On Sun, 01 May 2022 15:39:35 +0100
> > Ben <ben.usenet@bsb.me.uk> wrote:
> >
> >> Mr Flibble <flibble@reddwarf.jmc> writes:
> >>
> >> > Recursive definitions are fine, infinitely recursive definitions
> >> > (such as The Halting Problem) are INVALID.
> >>
> >> (1) The halting problem is not an infinitely recursive definition.
> >>
> >> (2) Infinitely recursive definitions are often fine. For example,
> >> the list of Fibonacci numbers:
> >>
> >> fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
> >
> > FOR FUCKS SAKE, HOW STUPID ARE YOU? THAT IS A RECURSIVE DEFINITION
> > NOT AN *INFINITELY* RECURSIVE DEFINITION AS IT TERMINATES.
>
> Look again. What is the terminating condition? There is none.
>

It doesn't terminate because it is effectively an unbounded generator
however it will always terminate UPON USE (thunk evaluation) and this
usage is different to the infinitely recursive halting
problem definition which does not terminate. There is no category error
here but there is a category error in the halting problem definition.

/Flibble

On 2022-05-01 18:26, Mr Flibble wrote:
> On Mon, 02 May 2022 00:44:56 +0100
> Ben <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>>> On Sun, 01 May 2022 15:39:35 +0100
>>> Ben <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>>
>>>>> Recursive definitions are fine, infinitely recursive definitions
>>>>> (such as The Halting Problem) are INVALID.
>>>>
>>>> (1) The halting problem is not an infinitely recursive definition.
>>>>
>>>> (2) Infinitely recursive definitions are often fine. For example,
>>>> the list of Fibonacci numbers:
>>>>
>>>> fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
>>>
>>> FOR FUCKS SAKE, HOW STUPID ARE YOU? THAT IS A RECURSIVE DEFINITION
>>> NOT AN *INFINITELY* RECURSIVE DEFINITION AS IT TERMINATES.
>>
>> Look again. What is the terminating condition? There is none.
>>
>
> It doesn't terminate because it is effectively an unbounded generator
> however it will always terminate UPON USE (thunk evaluation) and this

Do you actual have any familiarity with Haskell?

André

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

On Sun, 1 May 2022 18:29:50 -0600
André G. Isaak <agisaak@gm.invalid> wrote:

> On 2022-05-01 18:26, Mr Flibble wrote:
> > On Mon, 02 May 2022 00:44:56 +0100
> > Ben <ben.usenet@bsb.me.uk> wrote:
> >
> >> Mr Flibble <flibble@reddwarf.jmc> writes:
> >>
> >>> On Sun, 01 May 2022 15:39:35 +0100
> >>> Ben <ben.usenet@bsb.me.uk> wrote:
> >>>
> >>>> Mr Flibble <flibble@reddwarf.jmc> writes:
> >>>>
> >>>>> Recursive definitions are fine, infinitely recursive definitions
> >>>>> (such as The Halting Problem) are INVALID.
> >>>>
> >>>> (1) The halting problem is not an infinitely recursive
> >>>> definition.
> >>>>
> >>>> (2) Infinitely recursive definitions are often fine. For
> >>>> example, the list of Fibonacci numbers:
> >>>>
> >>>> fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
> >>>
> >>> FOR FUCKS SAKE, HOW STUPID ARE YOU? THAT IS A RECURSIVE DEFINITION
> >>> NOT AN *INFINITELY* RECURSIVE DEFINITION AS IT TERMINATES.
> >>
> >> Look again. What is the terminating condition? There is none.
> >>
> >
> > It doesn't terminate because it is effectively an unbounded
> > generator however it will always terminate UPON USE (thunk
> > evaluation) and this
>
> Do you actual have any familiarity with Haskell?

Not today and not tomorrow but soon.

/Flibble

Mr Flibble <flibble@reddwarf.jmc> writes:

> On Mon, 02 May 2022 00:44:56 +0100
> Ben <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>> > On Sun, 01 May 2022 15:39:35 +0100
>> > Ben <ben.usenet@bsb.me.uk> wrote:
>> >
>> >> Mr Flibble <flibble@reddwarf.jmc> writes:
>> >>
>> >> > Recursive definitions are fine, infinitely recursive definitions
>> >> > (such as The Halting Problem) are INVALID.
>> >>
>> >> (1) The halting problem is not an infinitely recursive definition.
>> >>
>> >> (2) Infinitely recursive definitions are often fine. For example,
>> >> the list of Fibonacci numbers:
>> >>
>> >> fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
>> >
>> > FOR FUCKS SAKE, HOW STUPID ARE YOU? THAT IS A RECURSIVE DEFINITION
>> > NOT AN *INFINITELY* RECURSIVE DEFINITION AS IT TERMINATES.
>>
>> Look again. What is the terminating condition? There is none.
>
> It doesn't terminate because it is effectively an unbounded generator
> however it will always terminate UPON USE

(1) The definition either is or it not infinitely recursive. The use
does not alter that.

(2) Not all uses of this definition terminate.

> (thunk evaluation) and this
> usage is different to the infinitely recursive halting
> problem definition which does not terminate.

The haling problem definition is not recursive.

> There is no category error here but there is a category error in the
> halting problem definition.

There is no "category error" in the halting problem definition.

--
Ben.

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.

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

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)

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.