Re: A computable function that reports on the behavior of its actual self is not allowed

On 5/13/24 2:29 PM, olcott wrote:

On 5/12/2024 7:43 PM, Richard Damon wrote:

On 5/12/24 8:20 PM, olcott wrote:

On 5/12/2024 7:05 PM, Richard Damon wrote:

On 5/12/24 7:19 PM, olcott wrote:

On 5/12/2024 5:40 PM, Richard Damon wrote:

On 5/12/24 6:21 PM, olcott wrote:

On 5/12/2024 4:40 PM, Richard Damon wrote:

On 5/12/24 5:18 PM, olcott wrote:

On 5/12/2024 2:27 PM, olcott wrote:

Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the
corresponding output. https://en.wikipedia.org/wiki/Computable_function
>
A computable function that reports on the behavior of its actual
self (or reports on the behavior of its caller) is not allowed.
>
A decider must halt whereas simulating a pathological input
that would never halt unless aborted can only halt by aborting.
>
This causes the direct execution of this input after it has been aborted
to have different behavior than the simulated input that cannot possibly
stop running unless aborted.
>

>
*MORE PRECISE WORDING* (this may take a few more rewrites)
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
It is a verified fact that the directly executed Ĥ ⟨Ĥ⟩ cannot possibly
stop running unless simulating partial halt decider embedded_H aborts
its simulation of its input.

>
But since embedded_H implements a specific algorithm, either it will or it won't. "unless" is a meaningless word here, it implies a case that can't happen.
>
We can look at the two possible cases.
>
First, if embedded_H doesn't ever abort its simulation, then, as you have desceribed, THAT embedded_H creates a H^ that will never halt, but the H that was based on will also never abort its simulation (or you lied that embedded_H is the needed copy of H) and thus never answer and fail to be a decider.
>

>
It can answer without halting by transitioning to its own internal
non-final state of embedded_H.qn without ever reaching Ĥ.qn. Every
simulated instance of embedded_H would do this same thing and then
continue simulating its input.

So, you just don't understand how algorithms work, and how compuations are DEFINED.
>
>
If you want to try to define a new system of compuation that allows giving answer without the algorithm ending, but still allows all the composition operations that are included in computation theory, go ahead and try.
>
You then need to show that it is Turing Complete, which means that you can't outlaw any computation allowed in a Turing Machine, like H^.
>

>
In this case embedded_H <is> an actual UTM that has the extra
feature of examining all of the state transitions of its input
to see what we can all see that Ĥ ⟨Ĥ⟩ remains stuck in recursive
simulation.
>

>
And a UTM doesn't reveal its answer until it come to a final state, just like ALL Turing Machines or equivalent computation.
>

*Or we can get an actual partial halt decider as follows*
*Or we can get an actual partial halt decider as follows*
*Or we can get an actual partial halt decider as follows*
>
No decider is ever allowed to report on its own behavior thus embedded_H
as a simulating partial halt decider is NOT ALLOWED to report on the
direct execution of Ĥ ⟨Ĥ⟩ because this IS REPORTING ON ITS OWN BEHAVIOR.

>
WHO SAYS THIS?

>
A decider must compute the mapping from an input.
Its actual self cannot possibly be an input.

>
Sure it can, at least when converted to the form you give the input in.
>
A decide is tasked with computing an input to a function, that has been given to it in the form (perhaps) of a description. The FUNCTION being computed here is "Halting", and Halting take a machine and an input, and maps it to a binary value of Halting or Non-Halting.
>
A Halt Decider takes a description of that input, and nothing says that input description can't be the description of the decider itself.
>
If you want to use your arguement, NO decider can decide on any Turing Machine, because we can't give any Turing Machine as a input, only a description.
>

>
No decider takes an actual Turing machine as input thus
no decider can possibly take its actual self as input.

>
Algorithmic deciders frequent take their input in the form of a description, and a
>

>
(a) The behavior of the directly executed Ĥ ⟨Ĥ⟩ is after
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ has already aborted its simulation.

>
Right, and that is the behavior that H is supposed to report on.
>

>
(b) The behavior of the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
is before embedded_H has aborted its simulation.

>
Which just shows that embedded_H doesn't do a "Correct Simulation" per Computation Theory, so this simulation doesn't establish the actual behavior "of the input" which is the behavior of the machine described by it (since "inputs" don't HAVE behavior, only what they represent does).
>

>
(c) These two behaviors (a) and (b) ARE NOT THE SAME. (a) will stop
running on its own (b) will never stop running unless aborted.

>
But H isn't being asked about the simulation by H, but on the behavior of the program descrtibed by the input.
>

>
EVERYONE HAS ALWAYS BEEN WRONG ON THIS BESIDES PROFESSOR SIPSER
>
IT HAS NEVER EVER BEEN THE BEHAVIOR DESCRIBED BY THE INPUT
>
IT HAS ALWAYS ALWAYS BEEN THE BEHAVIOR SPECIFIED BY THIS INPUT

>
Read the question.
>
Does the machine described by the input halt.
>

 *THAT HAS NEVER BEEN THE CORRECT QUESTION*
*THE QUESTION HAS ALWAYS BEEN*
DOES THE MACHINE SPECIFIED BY THE INPUT HALT?

What is the difference between "Specified" and "Described"?

 

That is the "Behavior specified" by the input.
>
Yes, it isn't behavior described, but behavior specirfied by the machine described.
>

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 The machine specified by the input to embedded_H cannot
possibly stop running unless its simulation is aborted
by this embedded_H.
 

Nope, because the machine, when run, is not simulated by embedded_H, but is directly run.
You don't seem to understand that nature of reality and truth.
No one cares about the input simulated by embedded_H, since it is only a partial simulation. The problem always was about the actual behavior of the actual machine that H was deciding on.