Re: Halting Problem: How my refutation differs to Peter Olcott's

On 5/10/25 10:51 PM, Mr Flibble wrote:

On Sat, 10 May 2025 21:49:41 -0400, Richard Damon wrote:
 

On 5/10/25 9:18 PM, Mr Flibble wrote:

On Sat, 10 May 2025 21:07:34 -0400, Richard Damon wrote:
>

On 5/10/25 9:00 PM, olcott wrote:

On 5/10/2025 6:56 PM, Mr Flibble wrote:

On Sat, 10 May 2025 18:40:53 -0400, Richard Damon wrote:
>

On 5/10/25 4:38 PM, Mr Flibble wrote:

How my refutation differs to Peter's:
>
* Peter refutes the halting problem based on pathological input
manifesting in a simulating halt decider as infinite recursion,
this being treated as non-halting.
* Flibble refutes the halting problem based on patholgical input
manifesting as decider/input self-referencial conflation,
resulting in the contradiction at the heart of the halting problem
being a category (type) error, i.e. ill-formed.
>
These two refutations are related but not exactly the same.
>
/Flibble

>
And the problem is that you use incorrect categories.
>
The decider needs to be of the category "Program".
>
The input also needs to be of the category "Program", but provided
via a representation. The act of representation lets us convert
items of category Program to the category of Finite String which
can be an input.

>
Those two categories you have identified are different hence the
category error.
>
>

That is correct. A running program and an input finite string ARE NOT
THE SAME.

>
But there is a direct relationship between the two.
>
>
>

The "Pathological Input" *IS* a Program, built by the simple rules
of composition that are allowed in the system.

>
Such composition is invalid.
>
>

Richard is trying to get away with saying that a finite string THAT
IS NOT A RUNNING PROGRAM <IS> A RUNNING PROGRAM
>
>

But they are related to each other,

>
Even if there is some perceived relationship between the two different
categories it doesn't mean there still isn't a category error.

>
So, what is the error, since the input *IS* the finite string that was
built by the program representation operation, and thus *IS* what an
input needs to be.
>
>

Why relationship doesn’t rescue the mistake:
>
* Shared context ≠ shared type.
– A pupil and a teacher are clearly related (one teaches, one learns),
but the question “Who is taller, the lesson?” commits a category error
because a lesson isn’t the kind of thing that has height, regardless of
its pedagogical ties to people.

>
Which doesn't apply here, and you are just indicationg you don't
understand what a representation is.
>
The input is a finite string that represents a program.

 A program and a finite string representing a program are different
categories ergo we have a category error.
 /Flibble

And we never mixed them up!
The Decider *WAS* given a Finite String (that was the representation of a Program) as required, and the Representation was of a Program, as required, as the specifications were about the Program the Finite String Represented.
And a Program can legally be made by composition of Programs.