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

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

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?
 

It seems you don't understand those words.
I don't say that the decider needs to simulate the input to completion, but that it needs to be able to actually PROVE that if this exact input WAS given to a correct simultor (which won't be itself, since it isn't doing the complete simulation) will run for an unbounded number of steps.
The "behavior" of the input isn't a subjective property, that is dependent on something about the decider, but is an objective property that is only a function of the input (which includes what HHH that given DDD was paired with).
Your confusion with the TRUTH of what that (perhaps just hypothetical) correct simulation does, with the KNOWLEDGE that the decider got by its (partial) simulation just shows you stupidity.
The fact that you keep on working with self-contradictory equivocations on what "the input" means just shows the level of your deceit (or stupidity).
If "the input" that represents DDD doesn't include the code for HHH, then it is just impossible to simulate it past the call instruction.
If "the input" that represents DDD does include the code for HHH, then that input defines the only HHH that exists with this DDD, and thus when you talk about different HHHs looking at "the input" you are lying, as they are each looking at DIFFERENT inputs.
Thus, your whole argument is just based on LYING because you just don't understand (and actively refuse to understand) the meaning of basics like what a program is, what halting is, what a "correct simulation" is, or even what "the input" means.
Sorru, you are just proving how ignorant you are.