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

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

 Because DDD() cannot be an input to HHH its behavior
cannot not contradict HHH(DDD)==0.

But that isn't what the question is asking.
In fact, if you call HHH(DDD()) as a halt decider, it just needs to always return 1, as if you get to the call, it halts. It just fails to be a decider.
Your

 HHH is *ONLY* wrong when it reports on behavior other
than DDD simulated by HHH according to the semantics
of the C programming language.
 

Which is just you admitting that you are woriking on a strawman, because that isn't what a halting decider is supposed to do.
It needs to report on the behavior of the CORRECT simulation of the input per the semantics of the language used to encode it. (Not the simulation done by it).
If HNH(DDD) returns 0, then that correct simulation will halt, and HHH is just wrong.
Your problem is you just don't understand what you are talking about, and beleive your own fantastic lies.
And, by your statement, you are just admitting that you have been lying about working on the halting problem, as you don't understand what the words actually mean.