Re: Turing Machine computable functions apply finite string transformations to inputs VERIFIED FACT

On 4/30/2025 11:57 PM, olcott wrote:

On 4/30/2025 9:01 PM, Keith Thompson wrote:

olcott <polcott333@gmail.com> writes:

On 4/30/2025 5:04 PM, Keith Thompson wrote:

olcott <polcott333@gmail.com> writes:

On 4/30/2025 2:46 PM, Keith Thompson wrote:

olcott <polcott333@gmail.com> writes:
[...]

Because you don't pay any attention at all
you did not bother to notice that I have never been
attacking the Halting Problem only the conventional
Halting Problem proof.

[...]
That's some interesting news, at least to me.
I was under the impression that you had explicitly claimed to have
solved the Halting Problem.  I don't read most of what you write,
and I don't remember all of what I've read, so my impression may
have been mistaken.
Now you're saying that you're only attacking the conventional proof.

>
That is ALL that I have been saying for several years.
Anyone can figure that out simply on the basis of
actually paying attention to my proof.
>
HHH(DD) does correctly report that the halting problem
proof's impossible input DOES NOT HALT SO THE PROOF
IS WRONG.

So your only claim is that the commonly known Halting Problem proof
is flawed.  (Others who have paid more attention might choose to
comment on that.)
Do you have anything to say about whether the Halting Problem
is solvable?  (You snipped this question in your previous response.)
>

>
The proof that the Halting Problem is not solvable
has been proven to be incorrect.
>
It turns out the the entire category of undecidable
decision problem instances is vacuous. The whole
notion of undecidability is merely a confused view.
>
It is easy to eliminate undecidability in formal
systems simply by only allowing semantic logical
entailment from a set of basic facts that have been
stipulated to be true.

>
That's nice.
>
Do you have anything to say about whether the Halting Problem
is solvable?  Refuting one proof doesn't address that question.
>

 After people acknowledge that I have correctly refuting
the conventional proof

You mean the proof where you admitted that the theorem it proves is correct, *multiple times*?
On 4/28/2025 2:47 PM, olcott wrote:
 > On 4/28/2025 11:54 AM, dbush wrote:
 >> And the halting function below is not a computable function:
 >>
 >
 > It is NEVER a computable function
 >
 >> Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
 >>
 >> A solution to the halting problem is an algorithm H that computes the following mapping:
 >>
 >> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
 >> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
On 3/14/2025 2:01 PM, dbush wrote:
 > On 3/14/2025 1:19 PM, olcott wrote:
 >> When we define the HP as having H return a value
 >> corresponding to the halting behavior of input D
 >> and input D can actually does the opposite of whatever
 >> value that H returns, then we have boxed ourselves
 >> in to a problem having no solution.
 >>
 >
 >
 > And that is EXACTLY what the halting problem is about: it is not
 > possible to construct an H where H(X,Y) reports whether X(Y) halts when
 > executed directly.
 >
 > A problem that you have now EXPLICITLY agreed is unsolvable.  So...
 >
 >
 > LET THE RECORD SHOW:
 >
 > That Peter Olcott has agreed that the halting problem, i.e. the problem
 > of constructing a H such that H(X,Y) reports if X(Y) halts when executed
 > directly, is in fact UNSOLVABLE and therefore the mapping is UNCOMPUTABLE.
 >
 >
 > Good luck trying to show you've refuted a proof that you've gone on
 > record as admitting is correct.
On 3/14/2025 1:19 PM, olcott wrote:
 > When we define the HP as having H return a value
 > corresponding to the halting behavior of input D
 > and input D can actually does the opposite of whatever
 > value that H returns, then we have boxed ourselves
 > in to a problem having no solution.
On 6/21/2024 1:22 PM, olcott wrote:
 > the logical impossibility of specifying a halt decider H
 > that correctly reports the halt status of input D that is
 > defined to do the opposite of whatever value that H reports.
 > Of course this is impossible.
On 7/4/2023 12:57 AM, olcott wrote:
 > If you frame the problem in that a halt decider must divide up finite
 > strings pairs into those that halt when directly executed and those that
 > do not, then no single program can do this.