Re: My reviewers think that halt deciders must report on the behavior of their caller

On 7/6/2025 12:00 PM, Richard Damon wrote:

On 7/6/25 11:19 AM, olcott wrote:

On 7/6/2025 6:50 AM, Richard Damon wrote:

On 7/6/25 12:34 AM, olcott wrote:

On 7/5/2025 10:02 PM, Richard Damon wrote:

On 7/5/25 10:43 PM, olcott wrote:

On 7/5/2025 7:44 PM, Richard Damon wrote:

On 7/5/25 12:26 PM, olcott wrote:

On 7/5/2025 8:14 AM, Richard Damon wrote:

On 7/4/25 6:11 PM, olcott wrote:

On 7/4/2025 3:53 PM, Richard Damon wrote:

On 7/4/25 4:43 PM, olcott wrote:

On 6/3/2025 10:02 PM, dbush wrote:

On 6/3/2025 10:58 PM, olcott wrote:

On 6/3/2025 9:46 PM, dbush wrote:

On 6/3/2025 10:34 PM, olcott wrote:

On 6/3/2025 9:12 PM, dbush wrote:

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

>
Yes there is no algorithm that does that

>
Excellent!
>
Let The Record Show
>
That Peter Olcott
>
Has *EXPLICITLY* admitted
>
That no algorithm H exists that meets the above requirements, which is precisely the theorem that the halting problem proofs prove.

>
In the exact same way that there is no set of all set
that contain themselves. ZFC did not solve Russell's
Paradox as much as it showed that Russell's Paradox
was anchored in an incoherent foundation, now called
naive set theory.

>
Which arose because the axioms of naive set theory created a contradiction.
>

>
Likewise with halt deciders that are required to report
on the behavior of directly executed Turing machines.

>
And what is the CONTRADICTION?
>
The result is just some things are not computable.
>

>
The result is that there cannot possibly be
an *ACTUAL INPUT* that does the opposite of
whatever its partial halt decider decides
thus the HP proof fails before it begins.
>

>
Sure there is.
>

>
In order to have an honest dialogue you must pay
100% complete attention to every single word.
>
You can't just erase one of the words that I said
and then form a rebuttal on that basis.
>
Directly executed Turing machines have always been
outside of the domain of every Turing machine based
decider.
>
>

>
Nope.
>
Your refusal to providee a source is your admission that you are just a liar.
>
Remember, The DEFINITION of a Halt Deicder is that it is to be a decider that decides if the program represented by its input will halt when run.
>

>
It has never been the program represented by its input
it has always been the behavior specified by its input.
This is the key mistake that no one noticed in 90 years.

>
Really?
>
In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever.
>
Sounds like the program and its representation.
>

>
With pathological self-reference the directly
executed machine will not have the same
behavior as the correctly simulated machine
specification.

>
Sure it does.
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
*EVERY BOT FIGURES THIS OUT ON ITS OWN*

 No, it just isn't smart enough to detect that you lied in your premise.
 

There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.

 And there is no way for HHH to correctly simulate its input and return an answer
 

You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
What the F is wrong with you?
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer