Re: Simulation vs. Execution in the Halting Problem

On 2025-06-04 16:20:56 +0000, olcott said:

On 6/4/2025 2:28 AM, Mikko wrote:

On 2025-06-03 21:00:20 +0000, olcott said:
 

On 6/3/2025 3:47 PM, Mr Flibble wrote:

On Tue, 03 Jun 2025 15:25:51 -0500, olcott wrote:
 

On 6/3/2025 2:50 AM, Mikko wrote:

On 2025-06-02 15:55:00 +0000, olcott said:
 

On 6/2/2025 2:02 AM, Mikko wrote:

On 2025-06-02 03:32:28 +0000, olcott said:
 

On 6/1/2025 8:19 PM, Richard Damon wrote:

On 6/1/25 5:41 PM, olcott wrote:

On 6/1/2025 6:30 AM, Mikko wrote:

On 2025-05-30 15:41:59 +0000, olcott said:
 

On 5/30/2025 3:45 AM, Mikko wrote:

On 2025-05-29 18:10:39 +0000, olcott said:
 

On 5/29/2025 12:34 PM, Mr Flibble wrote:

 🧠 Simulation vs. Execution in the Halting Problem
 In the classical framework of computation theory (Turing
machines),
simulation is not equivalent to execution, though they can
approximate one another.

 To the best of my knowledge a simulated input always has the
exact same behavior as the directly executed input unless this
simulated input calls its own simulator.

 The simulation of the behaviour should be equivalent to the
real behaviour.

 That is the same as saying a function with infinite recursion
must have the same behavior as a function without infinite
recursion.

 A function does not have a behaviour. A function has a value for
every argument in its domain.
 A function is not recursive. A definition of a function can be
recursive. There may be another way to define the same function
without recursion.
 A definition of a function may use infinite recursion if it is
also defined how that infinite recursion defines a value.
 Anyway, from the meaning of "simulation" follows that a
simulation of a behaviour is (at least in some sense) similar to
the real behaviour. Otherwise no simulation has happened.
 

void DDD()
{
   HHH(DDD);
   return;
}
 The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its *simulated
"return" instruction final halt state*
 *Every rebuttal to this changes the words*
 

No it doesn't, as HHH is defined to abort and simulation after
finite time, and thus only does finite simulation.
 

See right there you changed the words.
I said nothing about finite or infinite simulation.
You said that I am wrong about something that I didn't even say.

 Again you are trying a sraw man deception. RIchard Damon did not
change your words, he only wrote his own. He did not claim that you
said anything about "finite" or "infinite" but that you should
understand the difference.

 Unlike most people here I do understand that not possibly reaching a
final halt state *is* non-halting behavior.

 You don't understand it correctly. Whether a computation is halting is
a feature of the computation, not a particular exectuion of that
coputation.
A halting computation is a halting computation even if its execution is
discontinued before reaching the final halt state.
 

int main()
{
DDD(); // Do you understand that the HHH(DDD) that this DDD
}        // calls is only accountable for the behavior of its
// input, and thus NOT accountable for the behavior // of its
caller?

 We have been over this before.
 This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
 

 I know that, you know that:
80 other people don't know that.
All the textbooks don't know that.
 All the textbooks expect HHH to report on the
behavior of its caller.

 Can you quote even one textbook saying "HHH shall report on the behaviour
of its caller" ?

 Textbooks require halt deciders to report on the
behavior of the direct execution of their input.

Not really. There is no significant difference between a "direct" execution
and any other execution. The question whether the computation has an end
is the same anyway, and so is the answer.
--
Mikko