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

On 5/10/2025 11:26 PM, Mr Flibble wrote:

On Sat, 10 May 2025 23:21:50 -0500, olcott wrote:
 

On 5/10/2025 11:09 PM, Mr Flibble wrote:

On Sat, 10 May 2025 23:05:17 -0500, olcott wrote:
>

On 5/10/2025 10:45 PM, Mr Flibble wrote:

On Sat, 10 May 2025 22:16:21 -0500, olcott wrote:
>

On 5/10/2025 10:11 PM, Mr Flibble wrote:

On Sat, 10 May 2025 22:00:26 -0500, olcott wrote:
>

On 5/10/2025 9: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

>
This made no difference difference until my simulating termination
analyzer discovered they they don't always have the same behavior
as was merely presumed for 90 years.
>
A halt decider was "defined" to report on the behavior of the
direct execution of the input ONLY because no one knew that it
could possibly be different behavior than what the input finite
string specifies.
>
Everyone here takes this false assumption as the infallible word
of God.
A textbook says it therefore it must be infallible.

>
Yes, the reason why these two different categories cause a category
error is because of the self-referential dependency between them,
which manifests as infinite recursion in your simulating halt
decider case.
>
/Flibble

>
Yes exactly !!!
It is great that some people are not so indoctrinated by dogma that
they can actually think for themselves and not merely follow the
herd.

>
Not sure about following the herd: I do have a computer science
degree (BSc (Hons)) but I don't recall us covering the halting
problem in any lectures although to be fair I skipped quite a few
lectures to write a MUD, learning C in the process.
>
/Flibble

>
The Halting Problem was only covered in the comp theory course that is
no longer offered. I learned C back when K & R was the official
standard. Been doing mostly C++ for the last 25 years.

>
Been doing mostly C++ for the last 33 years.
>
/Flibble

>
I love it. I use it as C with classes.
I never needed anything besides this and the standard template library.
I use std::vector for every array. Never had to deal with the tedium of
memory management in my life.

 For dynamic arrays there is std::vector and std::inplace_vector (C++26)
and for fixed-size arrays there is std::array.
 /Flibble

std::vector and std::sort and std::string is
about all that I ever needed. C with classes
makes code enormously more maintainable with
good OOP design.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer