🧠 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.
✅ What’s True:
Running a simulation of a program—even partially—is meant to reflect its execution behavior.
Simulators, emulators, or analyzers aim to predict how a program would
behave if actually run.
⚠️ Where the Divergence Happens:
1. Simulation May Not Be Complete
Even if the simulator detects what it believes to be infinite recursion,
it:
- Has not observed it to infinity
- Has inferred it based on structure or partial behavior
2. Execution Is Definitive, Simulation Is Predictive
- Execution is actual: the program runs on hardware (real or virtual) and either halts or doesn’t.
- Simulation is analytic: a model tries to deduce the result without fully committing to it.
🔄 What SHDs Claim (Flibble/Olcott):
If the SHD halts its simulation due to detecting a provable infinite recursion, then that should be considered a correct determination of non- halting for the input program.
This leads to their argument:
- SHD's halting ≠ the program’s halting
- But SHD's halting due to detection of infinite recursion ⇒ program’s non-halting
🧩 The Problem:
In classical computability theory:
- You can’t always know that a structure will cause non-halting.
- Many programs appear recursive but halt (e.g., bounded recursion).
- There’s no general algorithm that can always correctly detect infinite recursion in all programs.
Thus:
Simulation that halts does not conclusively determine that the simulated program would or would not halt — unless the simulation is exhaustive and faithful, which isn't always possible.
✅ Conclusion:
Partial simulation provides strong hints but not definitive proof of
halting or non-halting — unless the analysis itself is provably sound and complete within a restricted system (e.g., total languages).
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.
✅ What’s True:
Running a simulation of a program—even partially—is meant to reflect its >> execution behavior.
Simulators, emulators, or analyzers aim to predict how a program would
behave if actually run.
⚠️ Where the Divergence Happens:
1. Simulation May Not Be Complete
Even if the simulator detects what it believes to be infinite recursion,
it:
- Has not observed it to infinity
- Has inferred it based on structure or partial behavior
2. Execution Is Definitive, Simulation Is Predictive
- Execution is actual: the program runs on hardware (real or virtual) and
either halts or doesn’t.
- Simulation is analytic: a model tries to deduce the result without
fully
committing to it.
🔄 What SHDs Claim (Flibble/Olcott):
If the SHD halts its simulation due to detecting a provable infinite
recursion, then that should be considered a correct determination of non-
halting for the input program.
This leads to their argument:
- SHD's halting ≠ the program’s halting
- But SHD's halting due to detection of infinite recursion ⇒ program’s >> non-halting
🧩 The Problem:
In classical computability theory:
- You can’t always know that a structure will cause non-halting.
- Many programs appear recursive but halt (e.g., bounded recursion).
- There’s no general algorithm that can always correctly detect infinite >> recursion in all programs.
Thus:
Simulation that halts does not conclusively determine that the simulated
program would or would not halt — unless the simulation is exhaustive and >> faithful, which isn't always possible.
✅ Conclusion:
Partial simulation provides strong hints but not definitive proof of
halting or non-halting — unless the analysis itself is provably sound and >> complete within a restricted system (e.g., total languages).
HHH never rejects any input unless it has proven:
*would never stop running unless aborted*
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.
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.
Whether it actually is depends on the quality of the
simulator. There is no exception for the case when the simulator
is called. If the behaviour in the simulation is different from
a real execution then the simulation is wrong.
A function that calls its own simulator specifies different
behavior than a function that does not call its own simulator.
One of the advantages of Turing machines is that there is no possibility
to call anything so the effect of calling the simulator need not be
considered.
The same issue occurs in the Linz proof, it is merely more
difficult to see. The correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩ cannot
possibly reach its own simulated final halt state ⟨Ĥ.qn⟩
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
On 5/30/2025 8:16 PM, Richard Damon wrote:
On 5/30/25 11:41 AM, olcott wrote:
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.
Nope. Where does it say that?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH must be aborted. // otherwise infinite recursion
DDD emulated by HHH1 need not be aborted.
Your problem is you don't understand that the only things you can
correctly simulate are PROGRAMS, which mean they include all of their
code, which is also expressed in the input given to the simulator.
Whether it actually is depends on the quality of the
simulator. There is no exception for the case when the simulator
is called. If the behaviour in the simulation is different from
a real execution then the simulation is wrong.
A function that calls its own simulator specifies different
behavior than a function that does not call its own simulator.
No it doesn't, as we can only be talking about programs, and programs
don't know who "their simulator" is, only what simulator they were
built to use.
One of the advantages of Turing machines is that there is no
possibility
to call anything so the effect of calling the simulator need not be
considered.
The same issue occurs in the Linz proof, it is merely more
difficult to see. The correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩ cannot
possibly reach its own simulated final halt state ⟨Ĥ.qn⟩
What "Issue"? Your problme is you don't understand what you are taling
about.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Why did the copy of H change to being called "embedded_H"?
I am using cleaner notational conventions.
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
Which then gets stop when the embedded_H invoked at the first
invocation of (b) doing step (c) decides to abort its emulation.
I have it emulate one more level before stopping.
It would stop at (e).
Of courese, if it never does, then H can nover do it either (since
they are DEFINED to be the exact same algorithm) and thus H failea to
be a decider.
You are just showing that your "logic" is based on LYING about what
you are doing, and that you are too stupid to understand the
requirements, and you don't care to learn them (or are just mentally
incapable).
Rejected as non-halting at (e) can't reach simulated ⟨Ĥ.qn⟩ state.
On 5/31/2025 7:39 AM, dbush wrote:
On 5/31/2025 2:41 AM, olcott wrote:
On 5/30/2025 8:16 PM, Richard Damon wrote:
On 5/30/25 11:41 AM, olcott wrote:
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.
Nope. Where does it say that?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH must be aborted. // otherwise infinite recursion >>> DDD emulated by HHH1 need not be aborted.
And the simulation performed by each of these is the same up to the
point that HHH aborts, as you have admitted on the record:
No moron they are not.
HHH performs one whole recursive emulation of DDD
than HHH1 ever does BEFORE HHH EVER ABORTS.
On 5/31/2025 2:38 PM, olcott wrote:
On 5/31/2025 11:59 AM, dbush wrote:
On 5/31/2025 12:48 PM, olcott wrote:
On 5/31/2025 7:39 AM, dbush wrote:
On 5/31/2025 2:41 AM, olcott wrote:
On 5/30/2025 8:16 PM, Richard Damon wrote:
On 5/30/25 11:41 AM, olcott wrote:
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.
Nope. Where does it say that?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH must be aborted. // otherwise infinite recursion >>>>>> DDD emulated by HHH1 need not be aborted.
And the simulation performed by each of these is the same up to the point that HHH aborts, as
you have admitted on the record:
No moron they are not.
HHH performs one whole recursive emulation of DDD
than HHH1 ever does BEFORE HHH EVER ABORTS.
Nope, if that was true you would have previously identified the divergence but failed to do so.
The code has proved that it is true for three years.
False.
That you are unable to see that the side by side code traces are exactly the same up the the point
that HHH aborts is not a rebuttal.
On 5/31/2025 5:27 PM, Mike Terry wrote:
On 31/05/2025 20:26, dbush wrote:
On 5/31/2025 2:38 PM, olcott wrote:
On 5/31/2025 11:59 AM, dbush wrote:
On 5/31/2025 12:48 PM, olcott wrote:
On 5/31/2025 7:39 AM, dbush wrote:
On 5/31/2025 2:41 AM, olcott wrote:
On 5/30/2025 8:16 PM, Richard Damon wrote:
On 5/30/25 11:41 AM, olcott wrote:
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.
Nope. Where does it say that?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH must be aborted. // otherwise infinite recursion
DDD emulated by HHH1 need not be aborted.
And the simulation performed by each of these is the same up to the point that HHH aborts, as
you have admitted on the record:
No moron they are not.
HHH performs one whole recursive emulation of DDD
than HHH1 ever does BEFORE HHH EVER ABORTS.
Nope, if that was true you would have previously identified the divergence but failed to do so.
The code has proved that it is true for three years.
False.
That you are unable to see that the side by side code traces are exactly the same up the the
point that HHH aborts is not a rebuttal.
Right. I've presented such comparisons for PO on multiple occasions, but it's like he looks at
the post, and simply can't see what it's saying - like there's a big hole in the post or
something. It brings to mind the Oliver Sacks book "The Man Who Mistook His Wife for a Hat".
Mike.
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
*It is only after this whole extra recursive emulation*
*divergence that HHH aborts its emulated DDD*
_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH
[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]
_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1
[000021b0] 83c404 add esp,+04
[000021b3] 33c0 xor eax,eax
[000021b5] 5d pop ebp
[000021b6] c3 ret
Size in bytes:(0020) [000021b6]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== ============= [000021a3][0010382d][00000000] 55 push ebp [000021a4][0010382d][00000000] 8bec mov ebp,esp [000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD [000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1
Begin Local Halt Decider Simulation Execution Trace Stored at:1138d9 [00002183][001138c9][001138cd] 55 push ebp [00002184][001138c9][001138cd] 8bec mov ebp,esp [00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9
Begin Local Halt Decider Simulation Execution Trace Stored at:15e301 [00002183][0015e2f1][0015e2f5] 55 push ebp [00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp [00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD [0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:198d21
[00002183][001a8d19][001a8d1d] 55 push ebp [00002184][001a8d19][001a8d1d] 8bec mov ebp,esp [00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002190][001138c9][001138cd] 83c404 add esp,+04 [00002193][001138cd][000015a8] 5d pop ebp [00002194][001138d1][0003a980] c3 ret [000021b0][0010382d][00000000] 83c404 add esp,+04 [000021b3][0010382d][00000000] 33c0 xor eax,eax [000021b5][00103831][00000018] 5d pop ebp [000021b6][00103835][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
On 5/31/2025 5:27 PM, Mike Terry wrote:
On 31/05/2025 20:26, dbush wrote:
On 5/31/2025 2:38 PM, olcott wrote:
On 5/31/2025 11:59 AM, dbush wrote:
On 5/31/2025 12:48 PM, olcott wrote:
On 5/31/2025 7:39 AM, dbush wrote:
On 5/31/2025 2:41 AM, olcott wrote:
On 5/30/2025 8:16 PM, Richard Damon wrote:
On 5/30/25 11:41 AM, olcott wrote:
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.
Nope. Where does it say that?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH must be aborted. // otherwise infinite >>>>>>>> recursion
DDD emulated by HHH1 need not be aborted.
And the simulation performed by each of these is the same up to
the point that HHH aborts, as you have admitted on the record:
No moron they are not.
HHH performs one whole recursive emulation of DDD
than HHH1 ever does BEFORE HHH EVER ABORTS.
Nope, if that was true you would have previously identified the
divergence but failed to do so.
The code has proved that it is true for three years.
False.
That you are unable to see that the side by side code traces are
exactly the same up the the point that HHH aborts is not a rebuttal.
Right. I've presented such comparisons for PO on multiple occasions,
but it's like he looks at the post, and simply can't see what it's
saying - like there's a big hole in the post or something. It brings
to mind the Oliver Sacks book "The Man Who Mistook His Wife for a Hat".
Mike.
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
*It is only after this whole extra recursive emulation*
*divergence that HHH aborts its emulated DDD*
_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH
[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]
_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1
[000021b0] 83c404 add esp,+04
[000021b3] 33c0 xor eax,eax
[000021b5] 5d pop ebp
[000021b6] c3 ret
Size in bytes:(0020) [000021b6]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== ============= [000021a3][0010382d][00000000] 55 push ebp [000021a4][0010382d][00000000] 8bec mov ebp,esp [000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD [000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1
Begin Local Halt Decider Simulation Execution Trace Stored at:1138d9 [00002183][001138c9][001138cd] 55 push ebp [00002184][001138c9][001138cd] 8bec mov ebp,esp [00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9
Begin Local Halt Decider Simulation Execution Trace Stored at:15e301 [00002183][0015e2f1][0015e2f5] 55 push ebp [00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp [00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD [0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:198d21
[00002183][001a8d19][001a8d1d] 55 push ebp [00002184][001a8d19][001a8d1d] 8bec mov ebp,esp [00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002190][001138c9][001138cd] 83c404 add esp,+04 [00002193][001138cd][000015a8] 5d pop ebp [00002194][001138d1][0003a980] c3 ret [000021b0][0010382d][00000000] 83c404 add esp,+04 [000021b3][0010382d][00000000] 33c0 xor eax,eax [000021b5][00103831][00000018] 5d pop ebp [000021b6][00103835][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
On 5/31/2025 5:27 PM, Mike Terry wrote:
On 31/05/2025 20:26, dbush wrote:
On 5/31/2025 2:38 PM, olcott wrote:
On 5/31/2025 11:59 AM, dbush wrote:
On 5/31/2025 12:48 PM, olcott wrote:
On 5/31/2025 7:39 AM, dbush wrote:
On 5/31/2025 2:41 AM, olcott wrote:
On 5/30/2025 8:16 PM, Richard Damon wrote:
On 5/30/25 11:41 AM, olcott wrote:
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.
Nope. Where does it say that?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH must be aborted. // otherwise infinite recursion
DDD emulated by HHH1 need not be aborted.
And the simulation performed by each of these is the same up to the point that HHH aborts,
as you have admitted on the record:
No moron they are not.
HHH performs one whole recursive emulation of DDD
than HHH1 ever does BEFORE HHH EVER ABORTS.
Nope, if that was true you would have previously identified the divergence but failed to do so.
The code has proved that it is true for three years.
False.
That you are unable to see that the side by side code traces are exactly the same up the the
point that HHH aborts is not a rebuttal.
Right. I've presented such comparisons for PO on multiple occasions, but it's like he looks at
the post, and simply can't see what it's saying - like there's a big hole in the post or
something. It brings to mind the Oliver Sacks book "The Man Who Mistook His Wife for a Hat".
Mike.
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh....
I've presented the two traces to you side by side on more than one occasion. Do you really have
no recollection of that? Your explanation of why we supposedly can't put them side by side is
literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. the simulation /performed/ by
HHH1] starts and ends. Also mark where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
*It is only after this whole extra recursive emulation*
*divergence that HHH aborts its emulated DDD*
_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH
[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]
_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1
[000021b0] 83c404 add esp,+04
[000021b3] 33c0 xor eax,eax
[000021b5] 5d pop ebp
[000021b6] c3 ret
Size in bytes:(0020) [000021b6]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== =============
[000021a3][0010382d][00000000] 55 push ebp
[000021a4][0010382d][00000000] 8bec mov ebp,esp
[000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD
[000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1
HHH1 begins its simulation of DDD.
Begin Local Halt Decider Simulation Execution Trace Stored at:1138d9 >>> [00002183][001138c9][001138cd] 55 push ebp
[00002184][001138c9][001138cd] 8bec mov ebp,esp
[00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9
HHH begins its simulation of DDD
Begin Local Halt Decider Simulation Execution Trace Stored at:15e301 >>> [00002183][0015e2f1][0015e2f5] 55 push ebp
[00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
HHH simulates itself simulating DDD
New slave_stack at:198d21
[00002183][001a8d19][001a8d1d] 55 push ebp
[00002184][001a8d19][001a8d1d] 8bec mov ebp,esp
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
HHH aborts its simulation of DDD.
HHH1 simulates the rest of its own DDD.
[00002190][001138c9][001138cd] 83c404 add esp,+04
[00002193][001138cd][000015a8] 5d pop ebp
[00002194][001138d1][0003a980] c3 ret
return to main()
[000021b0][0010382d][00000000] 83c404 add esp,+04
[000021b3][0010382d][00000000] 33c0 xor eax,eax
[000021b5][00103831][00000018] 5d pop ebp
[000021b6][00103835][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
On 5/31/2025 10:32 PM, Mike Terry wrote:
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
On 5/31/2025 5:27 PM, Mike Terry wrote:
On 31/05/2025 20:26, dbush wrote:
On 5/31/2025 2:38 PM, olcott wrote:Right. I've presented such comparisons for PO on multiple
On 5/31/2025 11:59 AM, dbush wrote:
On 5/31/2025 12:48 PM, olcott wrote:
On 5/31/2025 7:39 AM, dbush wrote:
On 5/31/2025 2:41 AM, olcott wrote:
On 5/30/2025 8:16 PM, Richard Damon wrote:
On 5/30/25 11:41 AM, olcott wrote:
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.
Nope. Where does it say that?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH must be aborted. // otherwise infinite >>>>>>>>>>>> recursion
DDD emulated by HHH1 need not be aborted.
And the simulation performed by each of these is the same up >>>>>>>>>>> to the point that HHH aborts, as you have admitted on the >>>>>>>>>>> record:
No moron they are not.
HHH performs one whole recursive emulation of DDD
than HHH1 ever does BEFORE HHH EVER ABORTS.
Nope, if that was true you would have previously identified the >>>>>>>>> divergence but failed to do so.
The code has proved that it is true for three years.
False.
That you are unable to see that the side by side code traces are >>>>>>> exactly the same up the the point that HHH aborts is not a rebuttal. >>>>>>
occasions, but it's like he looks at the post, and simply can't
see what it's saying - like there's a big hole in the post or
something. It brings to mind the Oliver Sacks book "The Man Who
Mistook His Wife for a Hat".
Mike.
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of the
same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh....
I've presented the two traces to you side by side on more than one
occasion. Do you really have no recollection of that? Your
explanation of why we supposedly can't put them side by side is
literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can explain
what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. the
simulation /performed/ by HHH1] starts and ends. Also mark where
you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see if
they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
*It is only after this whole extra recursive emulation*
*divergence that HHH aborts its emulated DDD*
_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH
[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]
_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1
[000021b0] 83c404 add esp,+04
[000021b3] 33c0 xor eax,eax
[000021b5] 5d pop ebp
[000021b6] c3 ret
Size in bytes:(0020) [000021b6]
machine stack stack machine assembly
address address data code language >>>>> ======== ======== ======== ========== =============
[000021a3][0010382d][00000000] 55 push ebp
[000021a4][0010382d][00000000] 8bec mov ebp,esp
[000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD
[000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1
HHH1 begins its simulation of DDD.
Right. Below I'm going to use notation [n] on occasions to make clear
which level of simulation is doing things. So e.g. HHH1[0] is HHH1
directly executed. HHH[1] is HHH simulated by HHH1 and so on.
DDD simulated by HHH1[0]
Begin Local Halt Decider Simulation Execution Trace Stored at:1138d9 >>>>> [00002183][001138c9][001138cd] 55 push ebp
[00002184][001138c9][001138cd] 8bec mov ebp,esp
[00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9
HHH begins its simulation of DDD
Right. The following are part of both HHH1[0]'s and HHH[1]'s
simulations...
No. This is DDD simulated by HHH[1]
Begin Local Halt Decider Simulation Execution Trace Stored at:15e301 >>>>> [00002183][0015e2f1][0015e2f5] 55 push ebp
[00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
HHH simulates itself simulating DDD
Right. The following are part of HHH1[0]'s and HHH[1]'s and HHH[2]'s
simulations...
No this is DDD simulated by HHH[2]
New slave_stack at:198d21
[00002183][001a8d19][001a8d1d] 55 push ebp
[00002184][001a8d19][001a8d1d] 8bec mov ebp,esp
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
HHH aborts its simulation of DDD.
HHH[1] aborts its simulation of DDD. This aborted
simulation includes HHH simulating itself simulating
DDD AKA HHH[2].
returns to its caller: DDD simulated by HHH1[0]
Right. HHH[1] has abandoned simulation [2] (and nested simulation [3]).
This is the end of HHH[1]'s simulation, but HHH1[0]'s simulation
continues...
HHH1 simulates the rest of its own DDD.
You mean the rest of HHH[1]'s DDD. (HHH[1] is still being simulated)
No this is HHH1[0] finishing its one and only simulation of DDD.
[00002190][001138c9][001138cd] 83c404 add esp,+04
[00002193][001138cd][000015a8] 5d pop ebp
[00002194][001138d1][0003a980] c3 ret
And this is where HHH1's simulation ends.
(Below is directly executed code...)
return to main()
[000021b0][0010382d][00000000] 83c404 add esp,+04
[000021b3][0010382d][00000000] 33c0 xor eax,eax
[000021b5][00103831][00000018] 5d pop ebp
[000021b6][00103835][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
So now, you need to collect up the trace entries which are part of
HHH1's simulation (and nested simulations), and HHH[1]'s simulation
(and nested simulations). That's just looking at where the respective
traces start and end above.
No all that you need to see is that HHH simulates DDD twice
(thus already diverging from DDD simulated by HHH1)
before HHH aborts its simulation of DDD.
Here, I can do that:
-------------- HHH1[0] simulation (+nested simulations) ----------------
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== =============
[00002183][001138c9][001138cd] 55 push ebp
[00002184][001138c9][001138cd] 8bec mov ebp,esp
[00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
[00002183][0015e2f1][0015e2f5] 55 push ebp
[00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
### hint: this is where HHH aborts, but HHH1 continues the simulation! :)
[00002183][001a8d19][001a8d1d] 55 push ebp
[00002184][001a8d19][001a8d1d] 8bec mov ebp,esp
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
[00002190][001138c9][001138cd] 83c404 add esp,+04
[00002193][001138cd][000015a8] 5d pop ebp
[00002194][001138d1][0003a980] c3 ret
[trace ended by DDD[1] returning normally]
-------------- HHH[1] simulation (+nested simulations) ----------------
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== =============
[00002183][0015e2f1][0015e2f5] 55 push ebp
[00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
[00002183][001a8d19][001a8d1d] 55 push ebp
[00002184][001a8d19][001a8d1d] 8bec mov ebp,esp
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
[trace ended by HHH[1] aborting]
So do you agree that those are the right entries? (They are just the
entries you identified above, between the beginning and ends of the
respective simulations.)
*I am not going to look at them*
HHH emulates DDD twice before it aborts thus
the abort is not the cause of the divergence.
The moment that HHH[2] begins emulating DDD
DDD emulated by HHH1 and DDD emulated by HHH diverge.
Now you will be in a position to do the side-by-side comparison you
said wasn't possible! You need to, um, put the two traces above side
by side!
OK, clearly we are not going to exactly match on stack addresses or
stack data, but these are not unique attributes of the computation, as
Allocate() will assign different storage addresses for each
simulation. What we want is for machine addresses, machine code and
assemply language to match or not UP TO THE POINT WHERE HHH[1] ABORTS.
Mike.
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.
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh....
I've presented the two traces to you side by side on more than one occasion. Do you really have
no recollection of that? Your explanation of why we supposedly can't put them side by side is
literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. the simulation /performed/ by
HHH1] starts and ends. Also mark where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
*It is only after this whole extra recursive emulation*
*divergence that HHH aborts its emulated DDD*
_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH
[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]
_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1
[000021b0] 83c404 add esp,+04
[000021b3] 33c0 xor eax,eax
[000021b5] 5d pop ebp
[000021b6] c3 ret
Size in bytes:(0020) [000021b6]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== =============
[000021a3][0010382d][00000000] 55 push ebp
[000021a4][0010382d][00000000] 8bec mov ebp,esp
[000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD
[000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1
HHH1 begins its simulation of DDD.
Right. Below I'm going to use notation [n] on occasions to make clear which level of simulation
is doing things. So e.g. HHH1[0] is HHH1 directly executed. HHH[1] is HHH simulated by HHH1 and
so on.
DDD simulated by HHH1[0]
Begin Local Halt Decider Simulation Execution Trace Stored at:1138d9 >>>>> [00002183][001138c9][001138cd] 55 push ebp
[00002184][001138c9][001138cd] 8bec mov ebp,esp
[00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9
HHH begins its simulation of DDD
Right. The following are part of both HHH1[0]'s and HHH[1]'s simulations... >>
No. This is DDD simulated by HHH[1]
Begin Local Halt Decider Simulation Execution Trace Stored at:15e301 >>>>> [00002183][0015e2f1][0015e2f5] 55 push ebp
[00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
HHH simulates itself simulating DDD
Right. The following are part of HHH1[0]'s and HHH[1]'s and HHH[2]'s simulations...
No this is DDD simulated by HHH[2]
New slave_stack at:198d21
[00002183][001a8d19][001a8d1d] 55 push ebp
[00002184][001a8d19][001a8d1d] 8bec mov ebp,esp
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
HHH aborts its simulation of DDD.
HHH[1] aborts its simulation of DDD. This aborted
simulation includes HHH simulating itself simulating
DDD AKA HHH[2].
returns to its caller: DDD simulated by HHH1[0]
Right. HHH[1] has abandoned simulation [2] (and nested simulation [3]).
This is the end of HHH[1]'s simulation, but HHH1[0]'s simulation continues...
HHH1 simulates the rest of its own DDD.
You mean the rest of HHH[1]'s DDD. (HHH[1] is still being simulated)
No this is HHH1[0] finishing its one and only simulation of DDD.
[00002190][001138c9][001138cd] 83c404 add esp,+04
[00002193][001138cd][000015a8] 5d pop ebp
[00002194][001138d1][0003a980] c3 ret
And this is where HHH1's simulation ends.
(Below is directly executed code...)
return to main()
[000021b0][0010382d][00000000] 83c404 add esp,+04
[000021b3][0010382d][00000000] 33c0 xor eax,eax
[000021b5][00103831][00000018] 5d pop ebp
[000021b6][00103835][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
So now, you need to collect up the trace entries which are part of HHH1's simulation (and nested
simulations), and HHH[1]'s simulation (and nested simulations). That's just looking at where the
respective traces start and end above.
No all that you need to see is that HHH simulates DDD twice
(thus already diverging from DDD simulated by HHH1)
before HHH aborts its simulation of DDD.
Here, I can do that:
-------------- HHH1[0] simulation (+nested simulations) ----------------
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== =============
[00002183][001138c9][001138cd] 55 push ebp
[00002184][001138c9][001138cd] 8bec mov ebp,esp
[00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
[00002183][0015e2f1][0015e2f5] 55 push ebp
[00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
### hint: this is where HHH aborts, but HHH1 continues the simulation! :)
[00002183][001a8d19][001a8d1d] 55 push ebp
[00002184][001a8d19][001a8d1d] 8bec mov ebp,esp
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
[00002190][001138c9][001138cd] 83c404 add esp,+04
[00002193][001138cd][000015a8] 5d pop ebp
[00002194][001138d1][0003a980] c3 ret
[trace ended by DDD[1] returning normally]
-------------- HHH[1] simulation (+nested simulations) ----------------
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== =============
[00002183][0015e2f1][0015e2f5] 55 push ebp
[00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
[00002183][001a8d19][001a8d1d] 55 push ebp
[00002184][001a8d19][001a8d1d] 8bec mov ebp,esp
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
[trace ended by HHH[1] aborting]
So do you agree that those are the right entries? (They are just the entries you identified
above, between the beginning and ends of the respective simulations.)
*I am not going to look at them*
HHH emulates DDD twice before it aborts thus
the abort is not the cause of the divergence.
The moment that HHH[2] begins emulating DDD
DDD emulated by HHH1 and DDD emulated by HHH diverge.
Now you will be in a position to do the side-by-side comparison you said wasn't possible! You
need to, um, put the two traces above side by side!
OK, clearly we are not going to exactly match on stack addresses or stack data, but these are not
unique attributes of the computation, as Allocate() will assign different storage addresses for
each simulation. What we want is for machine addresses, machine code and assemply language to
match or not UP TO THE POINT WHERE HHH[1] ABORTS.
Mike.
On 6/1/2025 10:42 AM, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of
the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh....
I've presented the two traces to you side by side on more than one >>>>>> occasion. Do you really have no recollection of that? Your
explanation of why we supposedly can't put them side by side is
literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can
explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e.
the simulation /performed/ by HHH1] starts and ends. Also mark
where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see
if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's
simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
HHH1(DDD) simulates one instance of DDD.
HHH(DDD) simulates DDD and simulates itself simulating DDD
and then aborts after it has already simulated DDD one more
time than HHH1 ever does.
Both of those would be valid ways of looking at things.
(a) is more in line with how you typically present traces, and in your
I merely show that actual trace that is actually produced
during the actual execution of HHH1(DDD).
code A's view of the simulations includes both B's and C's
instructions - it needs to be that way for your so-called "infinite
recursive emulation" test to make sense.
(b) is ok too, as long as consistency is maintained.
It is too confusing for me to refer to this as anything besides
the actual names.
The claim you are disputing is "HHH1's and HHH's simulation of DDD
exactly match up to the point where HHH aborts".
That is wrong. They exactly match up until HHH begins
to simulate itself simulating DDD. The abort is much later.
More generally, any two (partial) simulations of any program will
match, up to the earliest step where one of the simulations is aborted.
Factually incorrect.
You keep ignoring that DDD calls HHH(DDD) in recursive
simulation and DDD *does not* call HHH1(DDD) in recursive simulation.
Definition (b) is "weaker" than (a), in that if (a) is understood,
and the two simulations match under this definition, then it is
obvious that under definition (b) the simulations will still match,
because (b) is just some filtered version of (a).
So I'll pause here until you say which of (a) (b) you think
characterises simulations matching or not matching.
Mike.
I can't deal with (a) and (b) it makes the analysis
too complicated to be done reliably. All analysis
must be made as simple as possible, just like all
code must be made as simple as possible to eliminate
accidental complexity
https://en.wikipedia.org/wiki/No_Silver_Bullet
Taking the Mythical Man Month to heart increases
the quality of software development ten-fold.
Make everything as simple and self-explanatory as possible.
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*
On 6/1/2025 10:42 AM, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh....
I've presented the two traces to you side by side on more than one occasion. Do you really
have no recollection of that? Your explanation of why we supposedly can't put them side by
side is literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. the simulation /performed/ by
HHH1] starts and ends. Also mark where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
HHH1(DDD) simulates one instance of DDD.
HHH(DDD) simulates DDD and simulates itself simulating DDD
and then aborts after it has already simulated DDD one more
time than HHH1 ever does.
Both of those would be valid ways of looking at things.
(a) is more in line with how you typically present traces, and in your
I merely show that actual trace that is actually produced
during the actual execution of HHH1(DDD).
code A's view of the simulations includes both B's and C's instructions - it needs to be that way
for your so-called "infinite recursive emulation" test to make sense.
(b) is ok too, as long as consistency is maintained.
It is too confusing for me to refer to this as anything besides
the actual names.
The claim you are disputing is "HHH1's and HHH's simulation of DDD exactly match up to the point
where HHH aborts".
That is wrong. They exactly match up until HHH begins
to simulate itself simulating DDD. The abort is much later.
More generally, any two (partial) simulations of any program will match, up to the earliest step
where one of the simulations is aborted.
Factually incorrect.
You keep ignoring that DDD calls HHH(DDD) in recursive
simulation and DDD *does not* call HHH1(DDD) in recursive simulation.
Definition (b) is "weaker" than (a), in that if (a) is understood, and the two simulations match
under this definition, then it is obvious that under definition (b) the simulations will still
match, because (b) is just some filtered version of (a).
So I'll pause here until you say which of (a) (b) you think characterises simulations matching or
not matching.
Mike.
I can't deal with (a) and (b) it makes the analysis
too complicated to be done reliably. All analysis
must be made as simple as possible, just like all
code must be made as simple as possible to eliminate
accidental complexity
https://en.wikipedia.org/wiki/No_Silver_Bullet
Taking the Mythical Man Month to heart increases
the quality of software development ten-fold.
Make everything as simple and self-explanatory as possible.
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*
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.
On 6/1/2025 9:43 PM, Mike Terry wrote:
On 01/06/2025 17:23, olcott wrote:
On 6/1/2025 10:42 AM, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
Your response below basically says that you don't understand what
"simulation" is.
That's not at all surprising, but given this, you are in no position
to make assertions about whether two simulations are the same or not,
up to the point where one of them is aborted.
I'll probably go back up the thread to where I asked you questions,
and just give the answers myself for the record.
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of >>>>>>>> the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh.... >>>>>>>>
I've presented the two traces to you side by side on more than >>>>>>>> one occasion. Do you really have no recollection of that? Your >>>>>>>> explanation of why we supposedly can't put them side by side is >>>>>>>> literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can
explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. >>>>>>>> the simulation /performed/ by HHH1] starts and ends. Also mark >>>>>>>> where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see >>>>>>>> if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's
simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
HHH1(DDD) simulates one instance of DDD.
HHH(DDD) simulates DDD and simulates itself simulating DDD
and then aborts after it has already simulated DDD one more
time than HHH1 ever does.
HHH1(DDD) simulates one instance of DDD, then its nested simulations.
HHH(DDD) simulates one instance of DDD, then its nested simulations.
IT'S THE SAME, UP TO THE POINT WHERE DDD IS ABORTED, EXACTLY AS I
CLAIMED.
(1) HHH simulates DDD and then simulates itself simulating DDD.
(2) HHH1 never ever simulates itself.
These two are not the same.
As soon as HHH simulates the very first instruction of
itself the simulation of DDD by HHH1 and the simulation
of DDD by HHH diverges.
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.
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.
On 6/1/2025 8:15 PM, Richard Damon wrote:
On 6/1/25 12:23 PM, olcott wrote:
On 6/1/2025 10:42 AM, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of >>>>>>>> the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh.... >>>>>>>>
I've presented the two traces to you side by side on more than >>>>>>>> one occasion. Do you really have no recollection of that? Your >>>>>>>> explanation of why we supposedly can't put them side by side is >>>>>>>> literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can
explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. >>>>>>>> the simulation /performed/ by HHH1] starts and ends. Also mark >>>>>>>> where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see >>>>>>>> if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's
simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
HHH1(DDD) simulates one instance of DDD.
HHH(DDD) simulates DDD and simulates itself simulating DDD
and then aborts after it has already simulated DDD one more
time than HHH1 ever does.
Both of those would be valid ways of looking at things.
(a) is more in line with how you typically present traces, and in your
I merely show that actual trace that is actually produced
during the actual execution of HHH1(DDD).
code A's view of the simulations includes both B's and C's
instructions - it needs to be that way for your so-called "infinite
recursive emulation" test to make sense.
(b) is ok too, as long as consistency is maintained.
It is too confusing for me to refer to this as anything besides
the actual names.
The claim you are disputing is "HHH1's and HHH's simulation of DDD
exactly match up to the point where HHH aborts".
That is wrong. They exactly match up until HHH begins
to simulate itself simulating DDD. The abort is much later.
More generally, any two (partial) simulations of any program willFactually incorrect.
match, up to the earliest step where one of the simulations is aborted. >>>
You keep ignoring that DDD calls HHH(DDD) in recursive
simulation and DDD *does not* call HHH1(DDD) in recursive simulation.
Definition (b) is "weaker" than (a), in that if (a) is understood,
and the two simulations match under this definition, then it is
obvious that under definition (b) the simulations will still match,
because (b) is just some filtered version of (a).
So I'll pause here until you say which of (a) (b) you think
characterises simulations matching or not matching.
Mike.
I can't deal with (a) and (b) it makes the analysis
too complicated to be done reliably. All analysis
must be made as simple as possible, just like all
code must be made as simple as possible to eliminate
accidental complexity
https://en.wikipedia.org/wiki/No_Silver_Bullet
Taking the Mythical Man Month to heart increases
the quality of software development ten-fold.
Make everything as simple and self-explanatory as possible.
The problem isn't that it makes the analysis too complicated, it makes
your errors clear.
It is simpler to keep the existing names of HHH and HHH1
instead of translating back and forth between these names
and Mike's new names of (a) and (b).
(1) HHH simulates DDD and then simulates itself simulating DDD.
(2) HHH1 never ever simulates itself.
These two are not the same.
As soon as HHH simulates the very first instruction of
itself the simulation of DDD by HHH1 and the simulation
of DDD by HHH diverges.
OVER simplification to the point of being in error, is just the tool
of the liar, which shows what you are.
On 6/2/2025 6:13 AM, Richard Damon wrote:
On 6/1/25 11:32 PM, olcott wrote:
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.
But you mean infinitly recursive, or you have no evidence of non-halting.
That is not the way that the computer science works.
Can't possibly reach final halt state *is* non-halting.
On 6/1/2025 9:43 PM, Mike Terry wrote:
On 01/06/2025 17:23, olcott wrote:
On 6/1/2025 10:42 AM, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
Your response below basically says that you don't understand what "simulation" is.
That's not at all surprising, but given this, you are in no position to make assertions about
whether two simulations are the same or not, up to the point where one of them is aborted.
I'll probably go back up the thread to where I asked you questions, and just give the answers
myself for the record.
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh.... >>>>>>>>
I've presented the two traces to you side by side on more than one occasion. Do you really
have no recollection of that? Your explanation of why we supposedly can't put them side by
side is literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. the simulation /performed/
by HHH1] starts and ends. Also mark where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
HHH1(DDD) simulates one instance of DDD.
HHH(DDD) simulates DDD and simulates itself simulating DDD
and then aborts after it has already simulated DDD one more
time than HHH1 ever does.
HHH1(DDD) simulates one instance of DDD, then its nested simulations.
HHH(DDD) simulates one instance of DDD, then its nested simulations.
IT'S THE SAME, UP TO THE POINT WHERE DDD IS ABORTED, EXACTLY AS I CLAIMED. >>
(1) HHH simulates DDD and then simulates itself simulating DDD.
(2) HHH1 never ever simulates itself.
These two are not the same.
As soon as HHH simulates the very first instruction of
itself the simulation of DDD by HHH1 and the simulation
of DDD by HHH diverges.
On 6/2/2025 11:34 AM, Mike Terry wrote:
On 02/06/2025 04:16, olcott wrote:
On 6/1/2025 9:43 PM, Mike Terry wrote:
On 01/06/2025 17:23, olcott wrote:
On 6/1/2025 10:42 AM, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
Your response below basically says that you don't understand what "simulation" is.
That's not at all surprising, but given this, you are in no position to make assertions about
whether two simulations are the same or not, up to the point where one of them is aborted.
I'll probably go back up the thread to where I asked you questions, and just give the answers
myself for the record.
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1 >>>>>>>>>>> calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh.... >>>>>>>>>>
I've presented the two traces to you side by side on more than one occasion. Do you
really have no recollection of that? Your explanation of why we supposedly can't put them
side by side is literally gibberish!
From the trace shown below we can see that HHH simulates >>>>>>>>>>> DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. the simulation /performed/
by HHH1] starts and ends. Also mark where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
HHH1(DDD) simulates one instance of DDD.
HHH(DDD) simulates DDD and simulates itself simulating DDD
and then aborts after it has already simulated DDD one more
time than HHH1 ever does.
HHH1(DDD) simulates one instance of DDD, then its nested simulations.
HHH(DDD) simulates one instance of DDD, then its nested simulations.
IT'S THE SAME, UP TO THE POINT WHERE DDD IS ABORTED, EXACTLY AS I CLAIMED. >>>>
(1) HHH simulates DDD and then simulates itself simulating DDD.
(2) HHH1 never ever simulates itself.
These two are not the same.
They are sooo the same!
(1) HHH simulates DDD and then simulates HHH simulating DDD.
(2) HHH1 simulates DDD and then simulates HHH simulating DDD.
Dude, we are talking about the /simulations/, not the simulators.
Because the simulators do simulate other simulators we
cannot simply ignore this.
We much keep track of some
of the details.
HHH1(DDD) simulates DDD that calls a simulated HHH(DDD)
that simulates DDD and then simulates itself simulating DDD.
On 6/2/2025 2:00 AM, Fred. Zwarts wrote:
Op 02.jun.2025 om 05:16 schreef olcott:
On 6/1/2025 9:43 PM, Mike Terry wrote:Verifiable counterfactual.
On 01/06/2025 17:23, olcott wrote:
On 6/1/2025 10:42 AM, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
Your response below basically says that you don't understand what
"simulation" is.
That's not at all surprising, but given this, you are in no position
to make assertions about whether two simulations are the same or
not, up to the point where one of them is aborted.
I'll probably go back up the thread to where I asked you questions,
and just give the answers myself for the record.
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1 >>>>>>>>>>> calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part >>>>>>>>>> of the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh.... >>>>>>>>>>
I've presented the two traces to you side by side on more than >>>>>>>>>> one occasion. Do you really have no recollection of that? >>>>>>>>>> Your explanation of why we supposedly can't put them side by >>>>>>>>>> side is literally gibberish!
From the trace shown below we can see that HHH simulates >>>>>>>>>>> DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can >>>>>>>>>> explain what you're saying.
Mark on the trace below where you think HHH1's simulation
[i.e. the simulation /performed/ by HHH1] starts and ends. >>>>>>>>>> Also mark where you think HHH's simulation starts and ends. >>>>>>>>>>
Then to save me the trouble, try to put them side by side to >>>>>>>>>> see if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's
simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
HHH1(DDD) simulates one instance of DDD.
HHH(DDD) simulates DDD and simulates itself simulating DDD
and then aborts after it has already simulated DDD one more
time than HHH1 ever does.
HHH1(DDD) simulates one instance of DDD, then its nested simulations.
HHH(DDD) simulates one instance of DDD, then its nested simulations.
IT'S THE SAME, UP TO THE POINT WHERE DDD IS ABORTED, EXACTLY AS I
CLAIMED.
(1) HHH simulates DDD and then simulates itself simulating DDD.
(2) HHH1 never ever simulates itself.
These two are not the same.
As soon as HHH simulates the very first instruction of
itself the simulation of DDD by HHH1 and the simulation
of DDD by HHH diverges.
Show in the trace where the first instruction of HHH simulating itself
is different from the first instruction of HHH simulated by HHH1.
There is no such difference.
*You already just said the difference*
The first instruction of HHH simulating itself
simulating DDD has no corresponding HHH1 simulating
itself simulating DDD.
That you keep refusing to show this difference, is a strong indication
that you know that you are wrong.
I have shown the difference. I will make a new post
and show this difference more clearly.
On 6/2/2025 6:13 AM, Richard Damon wrote:
On 6/1/25 11:32 PM, olcott wrote:
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.
But you mean infinitly recursive, or you have no evidence of non-halting.
That is not the way that the computer science works.
Can't possibly reach final halt state *is* non-halting.
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh....
I've presented the two traces to you side by side on more than one occasion. Do you really
have no recollection of that? Your explanation of why we supposedly can't put them side by
side is literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. the simulation /performed/ by
HHH1] starts and ends. Also mark where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
Both of those would be valid ways of looking at things.
(a) is more in line with how you typically present traces, and in your code A's view of the
simulations includes both B's and C's instructions - it needs to be that way for your so-called
"infinite recursive emulation" test to make sense.
(b) is ok too, as long as consistency is maintained.
The claim you are disputing is "HHH1's and HHH's simulation of DDD exactly match up to the point
where HHH aborts". More generally, any two (partial) simulations of any program will match, up to
the earliest step where one of the simulations is aborted. Definition (b) is "weaker" than (a), in
that if (a) is understood, and the two simulations match under this definition, then it is obvious
that under definition (b) the simulations will still match, because (b) is just some filtered
version of (a).
So I'll pause here until you say which of (a) (b) you think characterises simulations matching or
not matching.
Mike.
Also posters thinking its
their /duty/ to keep the internet pure for the protection of young
children who might one day read PO's posts and be misled, possibly
leading to them failing their exams then in despair turning to drugs and
a life of crime - hehe, you know that's just a post-hoc excuse for your posting.
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of the >>>>> same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh....
I've presented the two traces to you side by side on more than one
occasion. Do you really have no recollection of that? Your
explanation of why we supposedly can't put them side by side is
literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can explain >>>>> what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. the
simulation /performed/ by HHH1] starts and ends. Also mark where you >>>>> think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see if
they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's
simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
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.
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or does not
reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
On 6/2/2025 10:23 AM, Fred. Zwarts wrote:
Op 02.jun.2025 om 16:36 schreef olcott:
On 6/2/2025 6:13 AM, Richard Damon wrote:
On 6/1/25 11:32 PM, olcott wrote:
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.
But you mean infinitly recursive, or you have no evidence of non-
halting.
That is not the way that the computer science works.
Can't possibly reach final halt state *is* non-halting.
No, a premature end of the simulation, does not say anything about the
halting property of the program being simulated.
As soon as HHH emulates itself emulating DDD
it can see that DDD cannot possibly reach its
own final halt state no matter how many steps
of DDD are correctly emulated.
On 6/2/2025 2:04 AM, Fred. Zwarts wrote:
Op 02.jun.2025 om 05:32 schreef olcott:
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.
Of course misleading words must be changed.
Your words suggest an infinite recursion, because they are followed by
the inability to reach the end.
Unlike most people here I do understand that not
possibly reaching a final halt state *is* non-halting behavior.
On 6/2/2025 9:58 PM, Mike Terry wrote:
On 01/06/2025 16:42, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of >>>>>>> the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh.... >>>>>>>
I've presented the two traces to you side by side on more than
one occasion. Do you really have no recollection of that? Your >>>>>>> explanation of why we supposedly can't put them side by side is
literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can
explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e.
the simulation /performed/ by HHH1] starts and ends. Also mark >>>>>>> where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see >>>>>>> if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's
simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
Both of those would be valid ways of looking at things.
(a) is more in line with how you typically present traces, and in
your code A's view of the simulations includes both B's and C's
instructions - it needs to be that way for your so-called "infinite
recursive emulation" test to make sense.
(b) is ok too, as long as consistency is maintained.
The claim you are disputing is "HHH1's and HHH's simulation of DDD
exactly match up to the point where HHH aborts". More generally, any
two (partial) simulations of any program will match, up to the
earliest step where one of the simulations is aborted. Definition
(b) is "weaker" than (a), in that if (a) is understood, and the two
simulations match under this definition, then it is obvious that
under definition (b) the simulations will still match, because (b) is
just some filtered version of (a).
So I'll pause here until you say which of (a) (b) you think
characterises simulations matching or not matching.
Mike.
PO's response elsewhere is to not engage in clarification, but instead
just repeat over and over his intuition that the simulations of DDD
performed by HHH1 and HHH are /substantially/ different, rather than
differing just in how long each simulates before aborting.
Each intuition PO puts forward is seen to be /idiotically/ false,
simply by looking at the traces that PO himself has supplied! So this
situation is like PO claiming HHH is correct to decide non-halting for
DDD, despite his own traces showing that DDD halts. In both cases PO
shows a total misunderstanding of basic concepts [halting/simulation
respectively], and show that his delusions are quite robust when it
comes to challenges based on logical reasoning. Even if presented
with /direct observations/ contradicting his position, PO can (will)
just invent new magical thinking that only he is smart enough to
understand, in order to somehow justify his busted intuitions.
So posters hoping to change PO's mind take note: you are utterly
wasting your time if that is your objective! Also posters thinking
its their /duty/ to keep the internet pure for the protection of young
children who might one day read PO's posts and be misled, possibly
leading to them failing their exams then in despair turning to drugs
and a life of crime - hehe, you know that's just a post-hoc excuse for
your posting. Not that there's anything inherently bad about
highlighting PO's mistakes, it's just that it's not /required/ and
when it gets out of control it will consume /vast/ amounts of posters
time.
<https://xkcd.com/386>
Of course, posters should post while they're having fun, but...
nothing new has been said for years, and people are posting the same
responses over and over and over and over and over... At some point,
surely that just becomes /boring/, surely.
----------------
Anyhow, for the record here are the side by side comparisons of PO's
HHH1's and HHH's simulations of DDD, using PO's own traces:
HHH1 Simulation of DD (HHH1 never aborts) HHH Simulation
of DD
==========================================
==========================================
S machine machine assembly S machine
machine assembly
D address code language D address
code language
= ======== ============== ============= = ======== >> ============== =============
### HHH1 simulates DDD ### HHH simulates DDD
[1][00002183] 55 push ebp [1][00002183]
55 push ebp
[1][00002184] 8bec mov ebp,esp [1][00002184]
8bec mov ebp,esp
[1][00002186] 6883210000 push 00002183 ; DDD [1][00002186]
6883210000 push 00002183 ; DDD
[1][0000218b] e833f4ffff call 000015c3 ; HHH [1][0000218b]
e833f4ffff call 000015c3 ; HHH
### HHH simulates DDD... ### HHH simulates
DDD...
[2][00002183] 55 push ebp [2][00002183]
55 push ebp
[2][00002184] 8bec mov ebp,esp [2][00002184]
8bec mov ebp,esp
[2][00002186] 6883210000 push 00002183 ; DDD [2][00002186]
6883210000 push 00002183 ; DDD
[2][0000218b] e833f4ffff call 000015c3 ; HHH [2][0000218b]
e833f4ffff call 000015c3 ; HHH
### HHH simulates DDD... ### OUTER HHH aborts
[3][00002183] 55 push ebp
[3][00002184] 8bec mov ebp,esp
[3][00002186] 6883210000 push 00002183 ; DDD
[3][0000218b] e833f4ffff call 000015c3 ; HHH
### HHH[1] aborts
### DDD[1] returns
[1][00002190] 83c404 add esp,+04
[1][00002193] 5d pop ebp
[1][00002194] c3 ret
[SD column is simulation depth]
These traces are merges of the instructions from all simulation
levels, and are filtered to just show DDD instructions, as that's what
PO normally presents. Traces match up to the point where (outer) HHH
aborts.
If we showed HHH instructions and subroutines, we would find
mismatches that are caused by PO's misuse of mutable static data, i.e.
his broken simulation implementation. Once those are fixed, the two
traces exactly match up again [but we are talking hundreds of pages,
so it is not that useful, beyond confirming that the (fixed)
simulation is working properly].
Mike.
How many times does HHH1(DDD) simulate itself simulating DDD?
How many times does HHH(DDD) simulate itself simulating DDD?
*Saying that you don't think it makes a difference dodges the question*
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*
On 6/2/2025 9:58 PM, Mike Terry wrote:
On 01/06/2025 16:42, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of >>>>>>> the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh.... >>>>>>>
I've presented the two traces to you side by side on more than
one occasion. Do you really have no recollection of that? Your >>>>>>> explanation of why we supposedly can't put them side by side is
literally gibberish!
From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can
explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e.
the simulation /performed/ by HHH1] starts and ends. Also mark >>>>>>> where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to see >>>>>>> if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's
simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
Both of those would be valid ways of looking at things.
(a) is more in line with how you typically present traces, and in
your code A's view of the simulations includes both B's and C's
instructions - it needs to be that way for your so-called "infinite
recursive emulation" test to make sense.
(b) is ok too, as long as consistency is maintained.
The claim you are disputing is "HHH1's and HHH's simulation of DDD
exactly match up to the point where HHH aborts". More generally, any
two (partial) simulations of any program will match, up to the
earliest step where one of the simulations is aborted. Definition
(b) is "weaker" than (a), in that if (a) is understood, and the two
simulations match under this definition, then it is obvious that
under definition (b) the simulations will still match, because (b) is
just some filtered version of (a).
So I'll pause here until you say which of (a) (b) you think
characterises simulations matching or not matching.
Mike.
PO's response elsewhere is to not engage in clarification, but instead
just repeat over and over his intuition that the simulations of DDD
performed by HHH1 and HHH are /substantially/ different, rather than
differing just in how long each simulates before aborting.
Each intuition PO puts forward is seen to be /idiotically/ false,
simply by looking at the traces that PO himself has supplied! So this
situation is like PO claiming HHH is correct to decide non-halting for
DDD, despite his own traces showing that DDD halts. In both cases PO
shows a total misunderstanding of basic concepts [halting/simulation
respectively], and show that his delusions are quite robust when it
comes to challenges based on logical reasoning. Even if presented
with /direct observations/ contradicting his position, PO can (will)
just invent new magical thinking that only he is smart enough to
understand, in order to somehow justify his busted intuitions.
So posters hoping to change PO's mind take note: you are utterly
wasting your time if that is your objective! Also posters thinking
its their /duty/ to keep the internet pure for the protection of young
children who might one day read PO's posts and be misled, possibly
leading to them failing their exams then in despair turning to drugs
and a life of crime - hehe, you know that's just a post-hoc excuse for
your posting. Not that there's anything inherently bad about
highlighting PO's mistakes, it's just that it's not /required/ and
when it gets out of control it will consume /vast/ amounts of posters
time.
<https://xkcd.com/386>
Of course, posters should post while they're having fun, but...
nothing new has been said for years, and people are posting the same
responses over and over and over and over and over... At some point,
surely that just becomes /boring/, surely.
----------------
Anyhow, for the record here are the side by side comparisons of PO's
HHH1's and HHH's simulations of DDD, using PO's own traces:
HHH1 Simulation of DD (HHH1 never aborts) HHH Simulation
of DD
==========================================
==========================================
S machine machine assembly S machine
machine assembly
D address code language D address
code language
= ======== ============== ============= = ======== >> ============== =============
### HHH1 simulates DDD ### HHH simulates DDD
[1][00002183] 55 push ebp [1][00002183]
55 push ebp
[1][00002184] 8bec mov ebp,esp [1][00002184]
8bec mov ebp,esp
[1][00002186] 6883210000 push 00002183 ; DDD [1][00002186]
6883210000 push 00002183 ; DDD
[1][0000218b] e833f4ffff call 000015c3 ; HHH [1][0000218b]
e833f4ffff call 000015c3 ; HHH
### HHH simulates DDD... ### HHH simulates
DDD...
[2][00002183] 55 push ebp [2][00002183]
55 push ebp
[2][00002184] 8bec mov ebp,esp [2][00002184]
8bec mov ebp,esp
[2][00002186] 6883210000 push 00002183 ; DDD [2][00002186]
6883210000 push 00002183 ; DDD
[2][0000218b] e833f4ffff call 000015c3 ; HHH [2][0000218b]
e833f4ffff call 000015c3 ; HHH
### HHH simulates DDD... ### OUTER HHH aborts
[3][00002183] 55 push ebp
[3][00002184] 8bec mov ebp,esp
[3][00002186] 6883210000 push 00002183 ; DDD
[3][0000218b] e833f4ffff call 000015c3 ; HHH
### HHH[1] aborts
### DDD[1] returns
[1][00002190] 83c404 add esp,+04
[1][00002193] 5d pop ebp
[1][00002194] c3 ret
[SD column is simulation depth]
These traces are merges of the instructions from all simulation
levels, and are filtered to just show DDD instructions, as that's what
PO normally presents. Traces match up to the point where (outer) HHH
aborts.
If we showed HHH instructions and subroutines, we would find
mismatches that are caused by PO's misuse of mutable static data, i.e.
his broken simulation implementation. Once those are fixed, the two
traces exactly match up again [but we are talking hundreds of pages,
so it is not that useful, beyond confirming that the (fixed)
simulation is working properly].
Mike.
How many times does HHH1(DDD) simulate itself simulating DDD?
How many times does HHH(DDD) simulate itself simulating DDD?
*Saying that you don't think it makes a difference dodges the question*
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*
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his position, PO can (will) just invent
new magical thinking that only he is smart enough to understand, in order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally. BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does).
On 6/2/2025 10:17 PM, André G. Isaak wrote:
On 2025-06-02 20:58, Mike Terry wrote:
Also posters thinking its their /duty/ to keep the internet pure for
the protection of young children who might one day read PO's posts
and be misled, possibly leading to them failing their exams then in
despair turning to drugs and a life of crime - hehe, you know that's
just a post-hoc excuse for your posting.
Also, it should be noted that now that Usenet is no longer archived,
What is your source of that?
I have archives going back 20 years.
On 6/3/2025 10:28 AM, André G. Isaak wrote:
On 2025-06-02 23:16, olcott wrote:
On 6/2/2025 10:17 PM, André G. Isaak wrote:
On 2025-06-02 20:58, Mike Terry wrote:
Also posters thinking its their /duty/ to keep the internet pure
for the protection of young children who might one day read PO's
posts and be misled, possibly leading to them failing their exams
then in despair turning to drugs and a life of crime - hehe, you
know that's just a post-hoc excuse for your posting.
Also, it should be noted that now that Usenet is no longer archived,
What is your source of that?
I have archives going back 20 years.
Google groups stopped archiving usenet last year. You can still search
for articles posted up to February 2024, but anything posted after
that is now purely ephemeral -- once it expires from your newsfeed its
gone.
André
I just got directly to an article that I wrote 21 years
ago without needing Google Groups.
On 6/3/2025 2:50 AM, Mikko wrote:
On 2025-06-02 15:55:00 +0000, olcott said:int main()
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:See right there you changed the words.
On 6/1/2025 6:30 AM, Mikko wrote:No it doesn't, as HHH is defined to abort and simulation after
On 2025-05-30 15:41:59 +0000, olcott said:void DDD()
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.
{
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*
finite time, and thus only does finite simulation.
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.
{
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?
On 6/3/2025 12:59 PM, wij wrote:
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his
position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in
order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even
though it looks like it does:
On 1/24/24 19:18, olcott wrote:
> The directly executed D(D) reaches a final state and exits
normally.
> BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED, >>>> > Thus meeting the correct non-halting criteria if any step of
> a computation must be aborted to prevent its infinite execution
> then this computation DOES NOT HALT (even if it looks like it
does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to the
multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is
why PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to
it. Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond
that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on
the planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this
path of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but
it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection)
Likewise ZFC was not about what is now called naive set theory.
ZFC found an error in the foundations of set theory and fixed it.
2. POOH is not reproducible (you are all addressing your own
imagination).
What the discussions appear to me is that people are learning the
Halting Problem themselves by
'teaching' olcott (I think few can really provide a valid HP proof,
even what a proof is).
On 6/3/2025 6:14 AM, Richard Damon wrote:
On 6/3/25 1:23 AM, olcott wrote:
On 6/2/2025 9:58 PM, Mike Terry wrote:
On 01/06/2025 16:42, Mike Terry wrote:
On 01/06/2025 05:01, olcott wrote:
On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]
On 01/06/2025 02:31, olcott wrote:
On 5/31/2025 7:44 PM, Mike Terry wrote:
On 01/06/2025 01:18, olcott wrote:
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.
Duh! The DDD simulated by HHH ALSO calls HHH(DDD) as a part of >>>>>>>>> the same simulation.
They BOTH call HHH(DDD) as part of the simulation. Duuuuuh.... >>>>>>>>>
I've presented the two traces to you side by side on more than >>>>>>>>> one occasion. Do you really have no recollection of that?
Your explanation of why we supposedly can't put them side by >>>>>>>>> side is literally gibberish!
From the trace shown below we can see that HHH simulates >>>>>>>>>> DDD one whole execution trace more than HHH1 does.
Really? That's not at all what I see - but perhaps you can >>>>>>>>> explain what you're saying.
Mark on the trace below where you think HHH1's simulation [i.e. >>>>>>>>> the simulation /performed/ by HHH1] starts and ends. Also mark >>>>>>>>> where you think HHH's simulation starts and ends.
Then to save me the trouble, try to put them side by side to >>>>>>>>> see if they match up...
Mike.
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
There is a terminology issue here to resolve.
If A simulates B and B simulates C, what should a "trace" of A's
simulation look like?
a) it includes both B's and C's instructions, interlaced.
b) it is just B's instructions.
Both of those would be valid ways of looking at things.
(a) is more in line with how you typically present traces, and in
your code A's view of the simulations includes both B's and C's
instructions - it needs to be that way for your so-called "infinite
recursive emulation" test to make sense.
(b) is ok too, as long as consistency is maintained.
The claim you are disputing is "HHH1's and HHH's simulation of DDD
exactly match up to the point where HHH aborts". More generally,
any two (partial) simulations of any program will match, up to the
earliest step where one of the simulations is aborted. Definition
(b) is "weaker" than (a), in that if (a) is understood, and the two
simulations match under this definition, then it is obvious that
under definition (b) the simulations will still match, because (b)
is just some filtered version of (a).
So I'll pause here until you say which of (a) (b) you think
characterises simulations matching or not matching.
Mike.
PO's response elsewhere is to not engage in clarification, but
instead just repeat over and over his intuition that the simulations
of DDD performed by HHH1 and HHH are /substantially/ different,
rather than differing just in how long each simulates before aborting. >>>>
Each intuition PO puts forward is seen to be /idiotically/ false,
simply by looking at the traces that PO himself has supplied! So
this situation is like PO claiming HHH is correct to decide non-
halting for DDD, despite his own traces showing that DDD halts. In
both cases PO shows a total misunderstanding of basic concepts
[halting/simulation respectively], and show that his delusions are
quite robust when it comes to challenges based on logical reasoning.
Even if presented with /direct observations/ contradicting his
position, PO can (will) just invent new magical thinking that only
he is smart enough to understand, in order to somehow justify his
busted intuitions.
So posters hoping to change PO's mind take note: you are utterly
wasting your time if that is your objective! Also posters thinking
its their /duty/ to keep the internet pure for the protection of
young children who might one day read PO's posts and be misled,
possibly leading to them failing their exams then in despair turning
to drugs and a life of crime - hehe, you know that's just a post-hoc
excuse for your posting. Not that there's anything inherently bad
about highlighting PO's mistakes, it's just that it's not /required/
and when it gets out of control it will consume /vast/ amounts of
posters time.
<https://xkcd.com/386>
Of course, posters should post while they're having fun, but...
nothing new has been said for years, and people are posting the same
responses over and over and over and over and over... At some
point, surely that just becomes /boring/, surely.
----------------
Anyhow, for the record here are the side by side comparisons of PO's
HHH1's and HHH's simulations of DDD, using PO's own traces:
HHH1 Simulation of DD (HHH1 never aborts) HHH Simulation
of DD
==========================================
==========================================
S machine machine assembly S machine
machine assembly
D address code language D address
code language
= ======== ============== ============= = ========
============== =============
### HHH1 simulates DDD ### HHH simulates DDD
[1][00002183] 55 push ebp [1][00002183]
55 push ebp
[1][00002184] 8bec mov ebp,esp [1][00002184]
8bec mov ebp,esp
[1][00002186] 6883210000 push 00002183 ; DDD [1][00002186]
6883210000 push 00002183 ; DDD
[1][0000218b] e833f4ffff call 000015c3 ; HHH [1][0000218b]
e833f4ffff call 000015c3 ; HHH
### HHH simulates DDD... ### HHH simulates
DDD...
[2][00002183] 55 push ebp [2][00002183]
55 push ebp
[2][00002184] 8bec mov ebp,esp [2][00002184]
8bec mov ebp,esp
[2][00002186] 6883210000 push 00002183 ; DDD [2][00002186]
6883210000 push 00002183 ; DDD
[2][0000218b] e833f4ffff call 000015c3 ; HHH [2][0000218b]
e833f4ffff call 000015c3 ; HHH
### HHH simulates DDD... ### OUTER HHH aborts
[3][00002183] 55 push ebp
[3][00002184] 8bec mov ebp,esp
[3][00002186] 6883210000 push 00002183 ; DDD
[3][0000218b] e833f4ffff call 000015c3 ; HHH
### HHH[1] aborts
### DDD[1] returns
[1][00002190] 83c404 add esp,+04
[1][00002193] 5d pop ebp
[1][00002194] c3 ret
[SD column is simulation depth]
These traces are merges of the instructions from all simulation
levels, and are filtered to just show DDD instructions, as that's
what PO normally presents. Traces match up to the point where
(outer) HHH aborts.
If we showed HHH instructions and subroutines, we would find
mismatches that are caused by PO's misuse of mutable static data,
i.e. his broken simulation implementation. Once those are fixed,
the two traces exactly match up again [but we are talking hundreds
of pages, so it is not that useful, beyond confirming that the
(fixed) simulation is working properly].
Mike.
How many times does HHH1(DDD) simulate itself simulating DDD?
How many times does HHH(DDD) simulate itself simulating DDD?
But "itself" isn't a valid condition in this case, and in fact, if
HHH1 ever decided to simulate itself when simulating DDD, it would be
wrong.
*Saying that you don't think it makes a difference dodges the question*
No, it shows your use of incorrect language to just blantently LIE.
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*
First, to even be categorically correct, DDD must be interpreted to
include the code of the HHH that it calls, otherwise your whole
argument is just a giant category error.
And then DDD DOES reach its final state, just not by the simulation
done by HHH. Since any HHH that returns an answer, as required,
doesn't do a complete simulation, the simulation by HHH is irrelevent
to the determination of the correct answer.
Since the actual execution, or the COMPLETE simulation of DDD by an
actual correct simulator shows its halt, wed just see that you claim
is wrong.
Your repeated use of this ERROR just proves that you are noting but a
ignorant liar that doesn't care, or understand, about truth, but that
you are so stuck in your lies that you recklessly ignore the truth.
int main()
{
DDD(); // The HHH(DDD) that this DDD calls is not accountable } // for the behavior of its caller.
On 6/3/2025 10:38 AM, Mike Terry wrote:
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his
position, PO can (will) just invent new magical thinking that only
he is smart enough to understand, in order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even
though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally. >>> > BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does).
Right - magical thinking.
Like I said until you pay enough attention it may seem
that way. I know that I am correct because I can see
all of the details of a semantic tautology.
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*
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or does not
reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly simulated by HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
But a simple check is just run DDD ahd see that it halts. That is
sufficient to determine the only correct answer.
On 6/3/2025 3:35 PM, dbush wrote:
On 6/3/2025 4:28 PM, olcott wrote:
On 6/3/2025 2:55 AM, Mikko wrote:
It proves nothing without a proof that DDD is correctly simulated by
HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
But you admitted on the record that it doesn't:
Facts override and supersede opinions dip shit.
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or does not
reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly simulated by HHH.
But a simple check is just run DDD ahd see that it halts. That is
sufficient to determine the only correct answer.
int main()
{
DDD(); // calls HHH(DDD)
}
In other words you are saying that HHH should report
on the behavior of its caller (that it cannot see)
instead of reporting on the behavior that its actual
input actually specifies.
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?
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or does not
reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly simulated by HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
On 6/3/2025 12:59 PM, wij wrote:
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:Right - magical thinking.
Even if presented with /direct observations/ contradicting his
position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in
order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though >>>> it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally. >>>> > BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does). >>>
PO simply cannot clearly think through what's going on, due to the
multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why
PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it.
Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond
that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the
planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path >>> of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but
it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection)
Likewise ZFC was not about what is now called naive set theory.
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:int main()
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:See right there you changed the words.
On 6/1/2025 6:30 AM, Mikko wrote:No it doesn't, as HHH is defined to abort and simulation after >>>>>>>> finite time, and thus only does finite simulation.
On 2025-05-30 15:41:59 +0000, olcott said:void DDD()
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.
{
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*
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.
{
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.
On 6/3/2025 7:45 AM, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his
position, PO can (will) just invent new magical thinking that only he
is smart enough to understand, in order to somehow justify his busted
intuitions.
My favorite is that the directly executed D(D) doesn't halt even
though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does).
If the second call of otherwise infinite recursion had
to be aborted to prevent actual infinite recursion then
this call always was non-halting even when it was forced
to stop running.
On 6/3/2025 8:48 PM, dbush wrote:
On 6/3/2025 4:57 PM, olcott wrote:
On 6/3/2025 3:35 PM, dbush wrote:
On 6/3/2025 4:28 PM, olcott wrote:
On 6/3/2025 2:55 AM, Mikko wrote:
It proves nothing without a proof that DDD is correctly simulated
by HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
But you admitted on the record that it doesn't:
Facts override and supersede opinions dip shit.
And it is a fact that you admitted on the record that DDD
Is a damned lie.
On 6/4/2025 4:13 AM, Fred. Zwarts wrote:
Op 03.jun.2025 om 21:53 schreef olcott:
On 6/3/2025 7:45 AM, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his
position, PO can (will) just invent new magical thinking that only
he is smart enough to understand, in order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even
though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally. >>>> > BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does). >>>
If the second call of otherwise infinite recursion had
to be aborted to prevent actual infinite recursion then
this call always was non-halting even when it was forced
to stop running.
But since there is no infinite recursion, no abort is needed.
*You just contradicted yourself*
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
On 6/4/2025 2:26 AM, Mikko wrote:
On 2025-06-03 20:25:51 +0000, olcott said:
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?
I don't set any requirements on HHH. I just note that if HHH does not
return a value that means "halts" it is not a halt decider and not
even a partial halt decider, because the direct execution of DDD has
been shown to halt.
If HHH(DDD) is supposed to report on the behavior
of the direct execution of DDD() then that entails
that HHH must report on the behavior of its caller.
This is not allowed even if it was possible.
On 6/5/2025 2:14 AM, Fred. Zwarts wrote:
Op 04.jun.2025 om 18:31 schreef olcott:
On 6/4/2025 4:13 AM, Fred. Zwarts wrote:There we see that HHH aborts after a finite recursion.
Op 03.jun.2025 om 21:53 schreef olcott:
On 6/3/2025 7:45 AM, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his
position, PO can (will) just invent new magical thinking that
only he is smart enough to understand, in order to somehow
justify his busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even
though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exitsnormally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED, >>>>>> > Thus meeting the correct non-halting criteria if any step ofdoes).
a computation must be aborted to prevent its infinite execution >>>>>> > then this computation DOES NOT HALT (even if it looks like it
If the second call of otherwise infinite recursion had
to be aborted to prevent actual infinite recursion then
this call always was non-halting even when it was forced
to stop running.
But since there is no infinite recursion, no abort is needed.
*You just contradicted yourself*
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
HHH is supposed to abort as soon as it detects that
the simulated input cannot possibly reach its own
simulated "return" instruction final state.
On 6/5/2025 2:19 AM, Fred. Zwarts wrote:
Op 04.jun.2025 om 18:03 schreef olcott:
On 6/4/2025 2:26 AM, Mikko wrote:
On 2025-06-03 20:25:51 +0000, olcott said:
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:Again you are trying a sraw man deception. RIchard Damon did not >>>>>>>> change
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. >>>>>>>>
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?
I don't set any requirements on HHH. I just note that if HHH does not
return a value that means "halts" it is not a halt decider and not
even a partial halt decider, because the direct execution of DDD has
been shown to halt.
If HHH(DDD) is supposed to report on the behavior
of the direct execution of DDD() then that entails
that HHH must report on the behavior of its caller.
This is not allowed even if it was possible.
The definition of a correct report is to report about the input. Not
about a hypothetical input.
DDD simulated by HHH cannot possibly reach its "return"
instruction final halt state. DDD simulated by HHH derives
that actual behavior that the input to HHH(DDD) actually
specifies.
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:Right - magical thinking.
Even if presented with /direct observations/ contradicting his
position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in >>>>>>> order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though >>>>>> it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally. >>>>>> > BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED, >>>>>> > Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution >>>>>> > then this computation DOES NOT HALT (even if it looks like it does). >>>>>
PO simply cannot clearly think through what's going on, due to the
multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why >>>>> PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it. >>>>> Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond
that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the >>>>> planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path >>>>> of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but >>>> it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection)
Likewise ZFC was not about what is now called naive set theory.
To a large extent it is. Both are intended to describe those sets that
were tought to be usefult to think about. But the naive set theory failed
because it is inconsistent. However, ZF excludes some sets that some
people want to consider, e.g., the universal set, Quine's atom. There is
no agreement whether do not satisfy the axiom of choice and its various
consequences should be included or excluded, so both ZF and ZFC are used.
Quine's atom is nonsense.
The set of all non-empty sets of non-set elements seems possible.
On 6/6/2025 3:29 AM, Fred. Zwarts wrote:
Op 05.jun.2025 om 17:50 schreef olcott:
On 6/5/2025 2:14 AM, Fred. Zwarts wrote:But HHH does not *detect* that. The abort is based on an *invalid
Op 04.jun.2025 om 18:31 schreef olcott:
On 6/4/2025 4:13 AM, Fred. Zwarts wrote:There we see that HHH aborts after a finite recursion.
Op 03.jun.2025 om 21:53 schreef olcott:
On 6/3/2025 7:45 AM, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his >>>>>>>>> position, PO can (will) just invent new magical thinking that >>>>>>>>> only he is smart enough to understand, in order to somehow
justify his busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even >>>>>>>> though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits >>>>>>>> normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED, >>>>>>>> > Thus meeting the correct non-halting criteria if any step of >>>>>>>> > a computation must be aborted to prevent its infinite execution >>>>>>>> > then this computation DOES NOT HALT (even if it looks like it >>>>>>>> does).
If the second call of otherwise infinite recursion had
to be aborted to prevent actual infinite recursion then
this call always was non-halting even when it was forced
to stop running.
But since there is no infinite recursion, no abort is needed.
*You just contradicted yourself*
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
HHH is supposed to abort as soon as it detects that
the simulated input cannot possibly reach its own
simulated "return" instruction final state.
assumption*, not on what HHH sees. HHH sees only the first few
recursive recursions of a finite recursion and misses the fact that
the next cycle if the simulated HHH will abort and halt.
You seem to remain unqualified to make this assessment
by continuing to fail to understand that because every
instance of HHH has the exact same machine code that
unless the outermost HHH aborts then none of them abort.
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:Quine's atom is nonsense.
On 6/3/2025 12:59 PM, wij wrote:
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his >>>>>>>>> position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in >>>>>>>>> order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though
it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED, >>>>>>>> > Thus meeting the correct non-halting criteria if any step of >>>>>>>> > a computation must be aborted to prevent its infinite execution >>>>>>>> > then this computation DOES NOT HALT (even if it looks like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to the >>>>>>> multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why >>>>>>> PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it. >>>>>>> Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond >>>>>>> that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the >>>>>>> planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path
of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but >>>>>> it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection)
Likewise ZFC was not about what is now called naive set theory.
To a large extent it is. Both are intended to describe those sets that >>>> were tought to be usefult to think about. But the naive set theory failed >>>> because it is inconsistent. However, ZF excludes some sets that some
people want to consider, e.g., the universal set, Quine's atom. There is >>>> no agreement whether do not satisfy the axiom of choice and its various >>>> consequences should be included or excluded, so both ZF and ZFC are used. >>>
No, it is not. It is a set that one can assume to exist or not to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms
It is the same as every person that is their own father.
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:Likewise ZFC was not about what is now called naive set theory.
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting >>>>>>>>>>> his position, PO can (will) just
invent
new magical thinking that only he is smart enough to
understand, in order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt >>>>>>>>>> even though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits >>>>>>>>>> normally.execution
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN >>>>>>>>>> ABORTED,
Thus meeting the correct non-halting criteria if any step of >>>>>>>>>> > a computation must be aborted to prevent its infinite
then this computation DOES NOT HALT (even if it looks like >>>>>>>>>> it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to >>>>>>>>> the multiple levels involved. In his
head they all become a mush of confustions, but the mystery
here is why PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not >>>>>>>>> up to it. Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes >>>>>>>>> beyond that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody >>>>>>>>> on the planet, and my ability to
eliminate extraneous complexity". How did PO ever start down >>>>>>>>> this path of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of
POOH, but it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection) >>>>>>>
To a large extent it is. Both are intended to describe those sets
that
were tought to be usefult to think about. But the naive set theory >>>>>> failed
because it is inconsistent. However, ZF excludes some sets that some >>>>>> people want to consider, e.g., the universal set, Quine's atom.
There is
no agreement whether do not satisfy the axiom of choice and its
various
consequences should be included or excluded, so both ZF and ZFC
are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not to
exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms
It is the same as every person that is their own father.
No, it is not the same. Being of ones own father is impossible because
of the say the material world works. Imaginary things like sets can be
imagined to work wichever way one wants to imagine, though a consitent
imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
They must be round thus cannot have four equal
length sides and they must have four equal
length sides thus not cannot be round.
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:https://en.wikipedia.org/wiki/Urelement#Quine_atoms
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:Likewise ZFC was not about what is now called naive set theory.
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his >>>>>>>>>>> position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in >>>>>>>>>>> order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though
it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED, >>>>>>>>>> > Thus meeting the correct non-halting criteria if any step of >>>>>>>>>> > a computation must be aborted to prevent its infinite execution >>>>>>>>>> > then this computation DOES NOT HALT (even if it looks like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to the >>>>>>>>> multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why
PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it.
Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond >>>>>>>>> that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the
planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path
of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but >>>>>>>> it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection) >>>>>>>
To a large extent it is. Both are intended to describe those sets that >>>>>> were tought to be usefult to think about. But the naive set theory failed
because it is inconsistent. However, ZF excludes some sets that some >>>>>> people want to consider, e.g., the universal set, Quine's atom. There is >>>>>> no agreement whether do not satisfy the axiom of choice and its various >>>>>> consequences should be included or excluded, so both ZF and ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not to exist. >>>
It is the same as every person that is their own father.
No, it is not the same. Being of ones own father is impossible because
of the say the material world works. Imaginary things like sets can be
imagined to work wichever way one wants to imagine, though a consitent
imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
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:int main()
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: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.
On 6/1/25 5:41 PM, olcott wrote:See right there you changed the words.
On 6/1/2025 6:30 AM, Mikko wrote:No it doesn't, as HHH is defined to abort and simulation after >>>>>>>>>> finite time, and thus only does finite simulation.
On 2025-05-30 15:41:59 +0000, olcott said:void DDD()
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. >>>>>>>>>>>>
{
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*
I said nothing about finite or infinite simulation.
You said that I am wrong about something that I didn't even say. >>>>>>>>
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.
{
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.
On 6/4/2025 2:26 AM, Mikko wrote:
On 2025-06-03 20:25:51 +0000, olcott said:
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?
I don't set any requirements on HHH. I just note that if HHH does not
return a value that means "halts" it is not a halt decider and not
even a partial halt decider, because the direct execution of DDD has
been shown to halt.
If HHH(DDD) is supposed to report on the behavior
of the direct execution of DDD() then that entails
that HHH must report on the behavior of its caller.
This is not allowed even if it was possible.
On 6/4/2025 2:32 AM, Mikko wrote:
On 2025-06-03 20:28:36 +0000, olcott said:
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:I have shown that proof too many times and people
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or does not >>>>>> reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly simulated by HHH. >>>
denied the very obvious verified facts of it.
You have never shown any proof of anything. But a verifiable and verified
fact is that DDD halts. An obvious conseqence of that fact is that every
report that means 'DDD does not halt' is wrong.
When I provide proof that you cannot understand
this does not mean that I did not provide proof.
On 6/8/2025 12:49 AM, Mikko wrote:
On 2025-06-04 16:27:48 +0000, olcott said:
On 6/4/2025 2:32 AM, Mikko wrote:
On 2025-06-03 20:28:36 +0000, olcott said:
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or does not >>>>>>>> reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly simulated
by HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
You have never shown any proof of anything. But a verifiable and
verified
fact is that DDD halts. An obvious conseqence of that fact is that
every
report that means 'DDD does not halt' is wrong.
When I provide proof that you cannot understand
this does not mean that I did not provide proof.
Yes, it does.
What I just said is a truism, tautology, self-evident truth.
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof... https://en.wikipedia.org/wiki/Self-evidence
To understand a proof does not require any skills other
than proof checking, which is a Turing computable function.
On 6/8/2025 12:20 AM, Mikko wrote:
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:To a large extent it is. Both are intended to describe those
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:Likewise ZFC was not about what is now called naive set theory. >>>>>>>>
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting >>>>>>>>>>>>> his position, PO can (will) just
invent
new magical thinking that only he is smart enough to >>>>>>>>>>>>> understand, in order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt >>>>>>>>>>>> even though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and >>>>>>>>>>>> exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN >>>>>>>>>>>> ABORTED,
Thus meeting the correct non-halting criteria if any step of >>>>>>>>>>>> > a computation must be aborted to prevent its infinite >>>>>>>>>>>> execution
then this computation DOES NOT HALT (even if it looks >>>>>>>>>>>> like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due >>>>>>>>>>> to the multiple levels involved. In his
head they all become a mush of confustions, but the mystery >>>>>>>>>>> here is why PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not >>>>>>>>>>> up to it. Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes >>>>>>>>>>> beyond that of everybody else, due to
my powers of unrivalved concentration equalled by almost >>>>>>>>>>> nobody on the planet, and my ability to
eliminate extraneous complexity". How did PO ever start down >>>>>>>>>>> this path of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of >>>>>>>>>> POOH, but it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection) >>>>>>>>>
sets that
were tought to be usefult to think about. But the naive set
theory failed
because it is inconsistent. However, ZF excludes some sets that >>>>>>>> some
people want to consider, e.g., the universal set, Quine's atom. >>>>>>>> There is
no agreement whether do not satisfy the axiom of choice and its >>>>>>>> various
consequences should be included or excluded, so both ZF and ZFC >>>>>>>> are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not to
exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms
It is the same as every person that is their own father.
No, it is not the same. Being of ones own father is impossible because >>>> of the say the material world works. Imaginary things like sets can be >>>> imagined to work wichever way one wants to imagine, though a consitent >>>> imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
One can, much like you can imagine the coherent set of properties of
an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
On 6/8/2025 12:44 AM, Mikko wrote:
On 2025-06-04 16:03:24 +0000, olcott said:
On 6/4/2025 2:26 AM, Mikko wrote:
On 2025-06-03 20:25:51 +0000, olcott said:
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:Again you are trying a sraw man deception. RIchard Damon did not >>>>>>>> change
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. >>>>>>>>
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?
I don't set any requirements on HHH. I just note that if HHH does not
return a value that means "halts" it is not a halt decider and not
even a partial halt decider, because the direct execution of DDD has
been shown to halt.
If HHH(DDD) is supposed to report on the behavior
of the direct execution of DDD()
dbush insists that it is required.
then that entails
that HHH must report on the behavior of its caller.>> This is not
allowed even if it was possible.
That prohibition is not in any relevant specification. The correctness
criterion is a comparison of the answer given by the decider cnadidate
to a complete execution of the computation.
On 6/8/2025 12:20 AM, Mikko wrote:
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:https://en.wikipedia.org/wiki/Urelement#Quine_atoms
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:To a large extent it is. Both are intended to describe those sets that >>>>>>>> were tought to be usefult to think about. But the naive set theory failed
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:Likewise ZFC was not about what is now called naive set theory. >>>>>>>>
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his >>>>>>>>>>>>> position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in
order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though
it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of >>>>>>>>>>>> > a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to the >>>>>>>>>>> multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why
PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it.
Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond >>>>>>>>>>> that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the
planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path
of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but
it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection) >>>>>>>>>
because it is inconsistent. However, ZF excludes some sets that some >>>>>>>> people want to consider, e.g., the universal set, Quine's atom. There is
no agreement whether do not satisfy the axiom of choice and its various
consequences should be included or excluded, so both ZF and ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not to exist. >>>>>
It is the same as every person that is their own father.
No, it is not the same. Being of ones own father is impossible because >>>> of the say the material world works. Imaginary things like sets can be >>>> imagined to work wichever way one wants to imagine, though a consitent >>>> imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
One can, much like you can imagine the coherent set of properties of
an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
On 6/8/2025 12:49 AM, Mikko wrote:
On 2025-06-04 16:27:48 +0000, olcott said:
On 6/4/2025 2:32 AM, Mikko wrote:
On 2025-06-03 20:28:36 +0000, olcott said:
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or does not >>>>>>>> reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly simulated by HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
You have never shown any proof of anything. But a verifiable and verified >>>> fact is that DDD halts. An obvious conseqence of that fact is that every >>>> report that means 'DDD does not halt' is wrong.
When I provide proof that you cannot understand
this does not mean that I did not provide proof.
Yes, it does.
What I just said is a truism, tautology, self-evident truth.
On 6/8/2025 12:44 AM, Mikko wrote:
On 2025-06-04 16:03:24 +0000, olcott said:
On 6/4/2025 2:26 AM, Mikko wrote:
On 2025-06-03 20:25:51 +0000, olcott said:
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:Again you are trying a sraw man deception. RIchard Damon did not change
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. >>>>>>>>
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?
I don't set any requirements on HHH. I just note that if HHH does not
return a value that means "halts" it is not a halt decider and not
even a partial halt decider, because the direct execution of DDD has
been shown to halt.
If HHH(DDD) is supposed to report on the behavior
of the direct execution of DDD()
dbush insists that it is required.
On 6/10/2025 2:25 AM, Mikko wrote:
On 2025-06-08 06:00:50 +0000, olcott said:
On 6/8/2025 12:49 AM, Mikko wrote:
On 2025-06-04 16:27:48 +0000, olcott said:
On 6/4/2025 2:32 AM, Mikko wrote:
On 2025-06-03 20:28:36 +0000, olcott said:
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or >>>>>>>>>> does not
reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly
simulated by HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
You have never shown any proof of anything. But a verifiable and
verified
fact is that DDD halts. An obvious conseqence of that fact is that >>>>>> every
report that means 'DDD does not halt' is wrong.
When I provide proof that you cannot understand
this does not mean that I did not provide proof.
Yes, it does.
What I just said is a truism, tautology, self-evident truth.
No, it is not. It was an attempt to deceive with a false ad hominem.
When self-evident truth are not understood they remain
self-evident. If you want to try to disagree with a
self-evident truth you must proceed through the statement
one point at a time and point out exactly how and why
this point seems to be incorrect.
Even the stupidest bot that ever existed: "Eliza"
could baselessly disagree. It could spit out disagreement
as boiler-plate English sentences that it does not understand.
On 6/10/2025 2:21 AM, Mikko wrote:
On 2025-06-08 05:57:27 +0000, olcott said:
On 6/8/2025 12:44 AM, Mikko wrote:
On 2025-06-04 16:03:24 +0000, olcott said:
On 6/4/2025 2:26 AM, Mikko wrote:
On 2025-06-03 20:25:51 +0000, olcott said:
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:You don't understand it correctly. Whether a computation is
On 2025-06-02 03:32:28 +0000, olcott said:
On 6/1/2025 8:19 PM, Richard Damon wrote:Again you are trying a sraw man deception. RIchard Damon did >>>>>>>>>> not change
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. >>>>>>>>>>
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. >>>>>>>>
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?
I don't set any requirements on HHH. I just note that if HHH does not >>>>>> return a value that means "halts" it is not a halt decider and not >>>>>> even a partial halt decider, because the direct execution of DDD has >>>>>> been shown to halt.
If HHH(DDD) is supposed to report on the behavior
of the direct execution of DDD()
dbush insists that it is required.
In news:10241b0$3rjen$1@dont-email.me dbush says "It is both allowed and
possible" but that does not matter much. More important is that that
prohibition is not present in typcial textbooks or original articles.
Yes and everyone knows that these textbooks are infallibly
all knowing. If we had one trillion years to improve our
understanding of computer science we would never discover
one tiny nuance of detail more than we currently know
because everyone knows that all computer science textbook
are infallibly all knowing.
int main()
{
DDD(); // calls HHH(DDD)
}
It is neither allowed nor possible for HHH to report
on the behavior of its caller on the basis of its actual
input.
It is not possible for this HHH to see any aspect of its
caller. This HHH has no idea that it is not called
from main().
On 6/10/2025 2:12 AM, Mikko wrote:
On 2025-06-08 05:38:26 +0000, olcott said:
On 6/8/2025 12:20 AM, Mikko wrote:
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:To a large extent it is. Both are intended to describe those >>>>>>>>>> sets that
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/
contradicting his position, PO can (will) just
invent
new magical thinking that only he is smart enough to >>>>>>>>>>>>>>> understand, in order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't >>>>>>>>>>>>>> halt even though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and >>>>>>>>>>>>>> exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN >>>>>>>>>>>>>> ABORTED,
Thus meeting the correct non-halting criteria if any >>>>>>>>>>>>>> step of
a computation must be aborted to prevent its infinite >>>>>>>>>>>>>> execution
then this computation DOES NOT HALT (even if it looks >>>>>>>>>>>>>> like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due >>>>>>>>>>>>> to the multiple levels involved. In his
head they all become a mush of confustions, but the mystery >>>>>>>>>>>>> here is why PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm >>>>>>>>>>>>> not up to it. Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this >>>>>>>>>>>>> goes beyond that of everybody else, due to
my powers of unrivalved concentration equalled by almost >>>>>>>>>>>>> nobody on the planet, and my ability to
eliminate extraneous complexity". How did PO ever start >>>>>>>>>>>>> down this path of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of >>>>>>>>>>>> POOH, but it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical
connection)
Likewise ZFC was not about what is now called naive set theory. >>>>>>>>>>
were tought to be usefult to think about. But the naive set >>>>>>>>>> theory failed
because it is inconsistent. However, ZF excludes some sets >>>>>>>>>> that some
people want to consider, e.g., the universal set, Quine's
atom. There is
no agreement whether do not satisfy the axiom of choice and >>>>>>>>>> its various
consequences should be included or excluded, so both ZF and >>>>>>>>>> ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not >>>>>>>> to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms
It is the same as every person that is their own father.
No, it is not the same. Being of ones own father is impossible
because
of the say the material world works. Imaginary things like sets
can be
imagined to work wichever way one wants to imagine, though a
consitent
imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
One can, much like you can imagine the coherent set of properties of
an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Depends on what exactly your "can" and "possibly" mean. Anyway, DDD does
reach its final state, so its wrong to say that it can't.
Why do people always have to be damned liars and change
my words and then dishonestly apply their rebuttal to
these changed words.
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
*DDD simulated by HHH specifies a non-halting sequence*
On 6/10/2025 2:12 AM, Mikko wrote:
On 2025-06-08 05:38:26 +0000, olcott said:
On 6/8/2025 12:20 AM, Mikko wrote:
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:To a large extent it is. Both are intended to describe those sets that
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote:Likewise ZFC was not about what is now called naive set theory. >>>>>>>>>>
On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his >>>>>>>>>>>>>>> position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in
order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though
it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of >>>>>>>>>>>>>> > a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to the
multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why
PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it.
Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond
that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the
planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path
of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but
it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection) >>>>>>>>>>>
were tought to be usefult to think about. But the naive set theory failed
because it is inconsistent. However, ZF excludes some sets that some >>>>>>>>>> people want to consider, e.g., the universal set, Quine's atom. There is
no agreement whether do not satisfy the axiom of choice and its various
consequences should be included or excluded, so both ZF and ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms
It is the same as every person that is their own father.
No, it is not the same. Being of ones own father is impossible because >>>>>> of the say the material world works. Imaginary things like sets can be >>>>>> imagined to work wichever way one wants to imagine, though a consitent >>>>>> imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
One can, much like you can imagine the coherent set of properties of
an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Depends on what exactly your "can" and "possibly" mean. Anyway, DDD does
reach its final state, so its wrong to say that it can't.
Why do people always have to be damned liars and change
my words and then dishonestly apply their rebuttal to
these changed words.
On 6/10/2025 2:25 AM, Mikko wrote:
On 2025-06-08 06:00:50 +0000, olcott said:
On 6/8/2025 12:49 AM, Mikko wrote:
On 2025-06-04 16:27:48 +0000, olcott said:
On 6/4/2025 2:32 AM, Mikko wrote:
On 2025-06-03 20:28:36 +0000, olcott said:
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or does not >>>>>>>>>> reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly simulated by HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
You have never shown any proof of anything. But a verifiable and verified
fact is that DDD halts. An obvious conseqence of that fact is that every >>>>>> report that means 'DDD does not halt' is wrong.
When I provide proof that you cannot understand
this does not mean that I did not provide proof.
Yes, it does.
What I just said is a truism, tautology, self-evident truth.
No, it is not. It was an attempt to deceive with a false ad hominem.
When self-evident truth are not understood they remain
self-evident.
On 6/11/2025 3:56 AM, Mikko wrote:
On 2025-06-10 16:51:49 +0000, olcott said:
On 6/10/2025 2:12 AM, Mikko wrote:
On 2025-06-08 05:38:26 +0000, olcott said:
On 6/8/2025 12:20 AM, Mikko wrote:
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote: >>>>>>>>>>>>>>> On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ >>>>>>>>>>>>>>>>> contradicting his position, PO can (will) just >>>>>>>>>>>>>>>>> invent
new magical thinking that only he is smart enough to >>>>>>>>>>>>>>>>> understand, in order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't >>>>>>>>>>>>>>>> halt even though it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and >>>>>>>>>>>>>>>> exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS >>>>>>>>>>>>>>>> BEEN ABORTED,
Thus meeting the correct non-halting criteria if any >>>>>>>>>>>>>>>> step of
a computation must be aborted to prevent its infinite >>>>>>>>>>>>>>>> execution
then this computation DOES NOT HALT (even if it looks >>>>>>>>>>>>>>>> like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, >>>>>>>>>>>>>>> due to the multiple levels involved. In his
head they all become a mush of confustions, but the >>>>>>>>>>>>>>> mystery here is why PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm >>>>>>>>>>>>>>> not up to it. Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this >>>>>>>>>>>>>>> goes beyond that of everybody else, due to
my powers of unrivalved concentration equalled by almost >>>>>>>>>>>>>>> nobody on the planet, and my ability to
eliminate extraneous complexity". How did PO ever start >>>>>>>>>>>>>>> down this path of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement >>>>>>>>>>>>>> of POOH, but it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical >>>>>>>>>>>>>> connection)
Likewise ZFC was not about what is now called naive set >>>>>>>>>>>>> theory.
To a large extent it is. Both are intended to describe those >>>>>>>>>>>> sets that
were tought to be usefult to think about. But the naive set >>>>>>>>>>>> theory failed
because it is inconsistent. However, ZF excludes some sets >>>>>>>>>>>> that some
people want to consider, e.g., the universal set, Quine's >>>>>>>>>>>> atom. There is
no agreement whether do not satisfy the axiom of choice and >>>>>>>>>>>> its various
consequences should be included or excluded, so both ZF and >>>>>>>>>>>> ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not >>>>>>>>>> to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms
It is the same as every person that is their own father.
No, it is not the same. Being of ones own father is impossible >>>>>>>> because
of the say the material world works. Imaginary things like sets >>>>>>>> can be
imagined to work wichever way one wants to imagine, though a
consitent
imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
One can, much like you can imagine the coherent set of properties of >>>>>> an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Depends on what exactly your "can" and "possibly" mean. Anyway, DDD
does
reach its final state, so its wrong to say that it can't.
Why do people always have to be damned liars and change
my words and then dishonestly apply their rebuttal to
these changed words.
If you don't tell why you do so why would anyone else?
I USE CUT-AND-PASTE MAKING SURE THAT
MY WORDS ARE PERFECTLY UNCHANGED.
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* because
this input specifies that HHH simulates itself simulating DDD.
*Every rebuttal to this changes the words*
On 6/11/2025 4:06 AM, Mikko wrote:
On 2025-06-10 17:12:24 +0000, olcott said:
On 6/10/2025 2:25 AM, Mikko wrote:
On 2025-06-08 06:00:50 +0000, olcott said:
On 6/8/2025 12:49 AM, Mikko wrote:
On 2025-06-04 16:27:48 +0000, olcott said:
On 6/4/2025 2:32 AM, Mikko wrote:
On 2025-06-03 20:28:36 +0000, olcott said:
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or >>>>>>>>>>>> does not
reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly
simulated by HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
You have never shown any proof of anything. But a verifiable and >>>>>>>> verified
fact is that DDD halts. An obvious conseqence of that fact is
that every
report that means 'DDD does not halt' is wrong.
When I provide proof that you cannot understand
this does not mean that I did not provide proof.
Yes, it does.
What I just said is a truism, tautology, self-evident truth.
No, it is not. It was an attempt to deceive with a false ad hominem.
When self-evident truth are not understood they remain
self-evident.
Likewise, what is not a self-evident truth does not become one
when falsely claimed to be a self-evindet truth.
For example, "what I don't understand is not a proof" is not self-
evident.
It depends on the additional information "I can understand proofs" that
you can't have.
If I show the steps of solving for X in an algebra
problem and you do not know as much as how to count
to five this does not mean that my proof is incorrect.
Likewse, "When I provide proof that you cannot understand this does not
mean that I did not provide proof" is not self-evident as it assumes
there are proofs that I cannot understand at least to the extent that I
can recognise them as proofs. But that assumption is not self-evident
and not true.
Most every rebuttal of my work changes the words that
I actually said and then rebuts these changed words.
Other rebuttals start with false assumptions. When I
correct these false assumptions my corrections are always
ignored and the same incorrect rebuttal is provided
endlessly again and again.
On 6/11/2025 12:14 PM, wij wrote:
On Wed, 2025-06-11 at 11:14 -0500, olcott wrote:
On 6/11/2025 10:58 AM, wij wrote:
On Wed, 2025-06-11 at 10:29 -0500, olcott wrote:
On 6/11/2025 10:11 AM, wij wrote:
On Wed, 2025-06-11 at 10:00 -0500, olcott wrote:
On 6/11/2025 9:45 AM, wij wrote:
On Wed, 2025-06-11 at 09:40 -0500, olcott wrote:
On 6/11/2025 9:36 AM, wij wrote:
On Wed, 2025-06-11 at 09:20 -0500, olcott wrote:
On 6/11/2025 3:56 AM, Mikko wrote:
On 2025-06-10 16:51:49 +0000, olcott said:
On 6/10/2025 2:12 AM, Mikko wrote:
On 2025-06-08 05:38:26 +0000, olcott said:Why do people always have to be damned liars and change >>>>>>>>>>>>> my words and then dishonestly apply their rebuttal to >>>>>>>>>>>>> these changed words.
On 6/8/2025 12:20 AM, Mikko wrote:
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:One can, much like you can imagine the coherent set of >>>>>>>>>>>>>>>> properties of
On 2025-06-06 16:17:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 6/6/2025 3:57 AM, Mikko wrote:No, it is not the same. Being of ones own father is >>>>>>>>>>>>>>>>>> impossible
On 2025-06-04 15:59:10 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>
On 6/3/2025 12:59 PM, wij wrote: >>>>>>>>>>>>>>>>>>>>>>>> On Tue, 2025-06-03 at 16:38 +0100, Mike Terry >>>>>>>>>>>>>>>>>>>>>>>> wrote:
On 03/06/2025 13:45, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 6/2/2025 10:58 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> Even if presented with /direct observations/ >>>>>>>>>>>>>>>>>>>>>>>>>>> contradicting his position, PO can (will) just >>>>>>>>>>>>>>>>>>>>>>>>>>> invent
new magical thinking that only he is smart >>>>>>>>>>>>>>>>>>>>>>>>>>> enough to
understand, in order to somehow justify his >>>>>>>>>>>>>>>>>>>>>>>>>>> busted intuitions.
My favorite is that the directly executed D(D) >>>>>>>>>>>>>>>>>>>>>>>>>> doesn't
halt even though it looks like it does: >>>>>>>>>>>>>>>>>>>>>>>>>>
On 1/24/24 19:18, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> > The directly executed D(D) reaches a >>>>>>>>>>>>>>>>>>>>>>>>>> final
state and
exits normally.
> BECAUSE ANOTHER ASPECT OF THE SAME >>>>>>>>>>>>>>>>>>>>>>>>>> COMPUTATION
HAS
BEEN ABORTED,
> Thus meeting the correct non-halting >>>>>>>>>>>>>>>>>>>>>>>>>> criteria
if any
step of
> a computation must be aborted to >>>>>>>>>>>>>>>>>>>>>>>>>> prevent its
infinite
execution
> then this computation DOES NOT HALT >>>>>>>>>>>>>>>>>>>>>>>>>> (even if it
looks
like it does).
Right - magical thinking.
PO simply cannot clearly think through what's >>>>>>>>>>>>>>>>>>>>>>>>> going on,
due to the multiple levels involved. In his >>>>>>>>>>>>>>>>>>>>>>>>> head they all become a mush of confustions, but >>>>>>>>>>>>>>>>>>>>>>>>> the
mystery here is why PO does not /realise/ that >>>>>>>>>>>>>>>>>>>>>>>>> he can't think his way through it? >>>>>>>>>>>>>>>>>>>>>>>>>
When I try something that's beyond me, I soon >>>>>>>>>>>>>>>>>>>>>>>>> realise
I'm
not up to it. Somehow PO tries, gets into >>>>>>>>>>>>>>>>>>>>>>>>> a total muddle, and concludes "My understanding >>>>>>>>>>>>>>>>>>>>>>>>> of this
goes beyond that of everybody else, due to >>>>>>>>>>>>>>>>>>>>>>>>> my powers of unrivalved concentration equalled >>>>>>>>>>>>>>>>>>>>>>>>> by almost
nobody on the planet, and my ability to >>>>>>>>>>>>>>>>>>>>>>>>> eliminate extraneous complexity". How did PO >>>>>>>>>>>>>>>>>>>>>>>>> ever start
down this path of delusions? Not that that >>>>>>>>>>>>>>>>>>>>>>>>> matters one iota... :)
Mike.
People seem to keep addressing the logic of the >>>>>>>>>>>>>>>>>>>>>>>> implement
of POOH, but it does not matter how >>>>>>>>>>>>>>>>>>>>>>>> H or D are implemented, because: >>>>>>>>>>>>>>>>>>>>>>>>
1. POOH is not about the Halting Problem (no >>>>>>>>>>>>>>>>>>>>>>>> logical
connection)
Likewise ZFC was not about what is now called >>>>>>>>>>>>>>>>>>>>>>> naive set
theory.
To a large extent it is. Both are intended to >>>>>>>>>>>>>>>>>>>>>> describe those
sets that
were tought to be usefult to think about. But the >>>>>>>>>>>>>>>>>>>>>> naive set
theory failed
because it is inconsistent. However, ZF excludes >>>>>>>>>>>>>>>>>>>>>> some sets
that some
people want to consider, e.g., the universal set, >>>>>>>>>>>>>>>>>>>>>> Quine's
atom. There is
no agreement whether do not satisfy the axiom of >>>>>>>>>>>>>>>>>>>>>> choice and
its various
consequences should be included or excluded, so >>>>>>>>>>>>>>>>>>>>>> both ZF and
ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to >>>>>>>>>>>>>>>>>>>> exist or not
to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms >>>>>>>>>>>>>>>>>>> It is the same as every person that is their own father. >>>>>>>>>>>>>>>>>>
because
of the say the material world works. Imaginary things >>>>>>>>>>>>>>>>>> like sets
can be
imagined to work wichever way one wants to imagine, >>>>>>>>>>>>>>>>>> though a
consitent
imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle. >>>>>>>>>>>>>>>>
an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT >>>>>>>>>>>>>>> HALTING*
Depends on what exactly your "can" and "possibly" mean. >>>>>>>>>>>>>> Anyway, DDD does
reach its final state, so its wrong to say that it can't. >>>>>>>>>>>>>
If you don't tell why you do so why would anyone else? >>>>>>>>>>>>
I USE CUT-AND-PASTE MAKING SURE THAT
MY WORDS ARE PERFECTLY UNCHANGED.
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* because >>>>>>>>>>> this input specifies that HHH simulates itself simulating DDD. >>>>>>>>>>>
*Every rebuttal to this changes the words*
Sounds perfect for me (but like others: you may have posted >>>>>>>>>> "1+2=3"
, or various tautology, as proof that your POOH is correct). >>>>>>>>>> No, all such are irrelevant.
HP asks for "THE H" that decide the halting property of its >>>>>>>>>> argument.
The input to HHH(DDD) specifies non-halting behavior.
int main()
{
DDD(); // calls HHH(DDD)
}
It is ridiculously stupid to require HHH(DDD)
to report on the behavior of the direct execution
of DDD() because this DDD() *IS ITS CALLER*
and not its input.
So, you are saying the Halting Problem is ridiculous?
Show how any function could report on the behavior
of its caller and your failure will prove that I am
correct.
No. You are right that not all functions can report on the behavior >>>>>> of its caller. But that is what the HP proof suggests.
No it does not suggest this.
Yes, it does, see latter.
The issue is that no one
ever bothered to specify ALL of the details of the HP
proof to see that a halt decider is required to report
on the behavior of its caller. That is why I resorted
to the C language that can show 100% of every single
detail.
You don't understand what the HP says.
The HP simply EQUIVALENTLY asks for such H that "H(D)==1 iff D()
halts".
Note that I say 'equivalently' is because it is too technical for
you to understand.
You are learning by rote. All the function form of HP are easier for
teaching purpose.
You are admitting the HP is correct, and provide POOH claiming the >>>>>> HP proof is incorrect!
That the HP proof requires a halt decider to report on
the behavior of its caller is flat out nuts proving
that this aspect of the HP proof is complete nonsense.
The HP simply EQUIVALENTLY asks for such H that "H(D)==1 iff D()
halts".
and no one bothered to notice that this
requires H to report on the behavior of its caller
void D()
{
H(D);
return;
}
int main()
{
D(); // calls H(D)
}
What D does is not H's concern.
H(D) is required to report on the behavior that
its input specifies.
Invoked H(D) simulates D that calls H(D)
that simulates D that calls H(D)
that simulates D that calls H(D)
that simulates D that calls H(D)
that simulates D that calls H(D)...
Yes, the D() above looks like a infinite recursive call.
Other people or you are seemingly pointing to D and talking something
else.
Yes all other people (especially Dennis Bush) are saying
that H(D) is required to report on the behavior of the
direct execution of D() never noticing that this stupidly
requires H(D) to report on the behavior of its caller.
On 6/11/2025 12:24 PM, wij wrote:
On Wed, 2025-06-11 at 12:18 -0500, olcott wrote:
On 6/11/2025 12:14 PM, wij wrote:
On Wed, 2025-06-11 at 11:14 -0500, olcott wrote:
On 6/11/2025 10:58 AM, wij wrote:
On Wed, 2025-06-11 at 10:29 -0500, olcott wrote:
On 6/11/2025 10:11 AM, wij wrote:
On Wed, 2025-06-11 at 10:00 -0500, olcott wrote:
On 6/11/2025 9:45 AM, wij wrote:
On Wed, 2025-06-11 at 09:40 -0500, olcott wrote:
On 6/11/2025 9:36 AM, wij wrote:
On Wed, 2025-06-11 at 09:20 -0500, olcott wrote:
On 6/11/2025 3:56 AM, Mikko wrote:
On 2025-06-10 16:51:49 +0000, olcott said:
On 6/10/2025 2:12 AM, Mikko wrote:
On 2025-06-08 05:38:26 +0000, olcott said:Why do people always have to be damned liars and change >>>>>>>>>>>>>>> my words and then dishonestly apply their rebuttal to >>>>>>>>>>>>>>> these changed words.
On 6/8/2025 12:20 AM, Mikko wrote:
On 2025-06-07 13:51:33 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 6/7/2025 3:13 AM, Mikko wrote:One can, much like you can imagine the coherent set of >>>>>>>>>>>>>>>>>> properties of
On 2025-06-06 16:17:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>
On 6/4/2025 2:19 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-06-03 20:00:51 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
On 6/3/2025 12:59 PM, wij wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 2025-06-03 at 16:38 +0100, Mike Terry >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
On 03/06/2025 13:45, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/2/2025 10:58 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Even if presented with /direct observations/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> contradicting his position, PO can (will) just >>>>>>>>>>>>>>>>>>>>>>>>>>>>> invent
new magical thinking that only he is smart >>>>>>>>>>>>>>>>>>>>>>>>>>>>> enough to
understand, in order to somehow justify his >>>>>>>>>>>>>>>>>>>>>>>>>>>>> busted intuitions.
My favorite is that the directly executed D(D) >>>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't
halt even though it looks like it does: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
On 1/24/24 19:18, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> > The directly executed D(D) reaches >>>>>>>>>>>>>>>>>>>>>>>>>>>> a final
state and
exits normally.
> BECAUSE ANOTHER ASPECT OF THE SAME >>>>>>>>>>>>>>>>>>>>>>>>>>>> COMPUTATION
HAS
BEEN ABORTED,
> Thus meeting the correct non-halting
criteria
if any
step of
> a computation must be aborted to >>>>>>>>>>>>>>>>>>>>>>>>>>>> prevent
its
infinite
execution
> then this computation DOES NOT HALT
(even
if it
looks
like it does).
Right - magical thinking. >>>>>>>>>>>>>>>>>>>>>>>>>>>
PO simply cannot clearly think through what's >>>>>>>>>>>>>>>>>>>>>>>>>>> going
on,
due to the multiple levels involved. In his >>>>>>>>>>>>>>>>>>>>>>>>>>> head they all become a mush of confustions, >>>>>>>>>>>>>>>>>>>>>>>>>>> but the
mystery here is why PO does not /realise/ that >>>>>>>>>>>>>>>>>>>>>>>>>>> he can't think his way through it? >>>>>>>>>>>>>>>>>>>>>>>>>>>
When I try something that's beyond me, I soon >>>>>>>>>>>>>>>>>>>>>>>>>>> realise
I'm
not up to it. Somehow PO tries, gets into >>>>>>>>>>>>>>>>>>>>>>>>>>> a total muddle, and concludes "My >>>>>>>>>>>>>>>>>>>>>>>>>>> understanding of
this
goes beyond that of everybody else, due to >>>>>>>>>>>>>>>>>>>>>>>>>>> my powers of unrivalved concentration >>>>>>>>>>>>>>>>>>>>>>>>>>> equalled by
almost
nobody on the planet, and my ability to >>>>>>>>>>>>>>>>>>>>>>>>>>> eliminate extraneous complexity". How did PO >>>>>>>>>>>>>>>>>>>>>>>>>>> ever
start
down this path of delusions? Not that that >>>>>>>>>>>>>>>>>>>>>>>>>>> matters one iota... :)
Mike.
People seem to keep addressing the logic of the >>>>>>>>>>>>>>>>>>>>>>>>>> implement
of POOH, but it does not matter how >>>>>>>>>>>>>>>>>>>>>>>>>> H or D are implemented, because: >>>>>>>>>>>>>>>>>>>>>>>>>>
1. POOH is not about the Halting Problem (no >>>>>>>>>>>>>>>>>>>>>>>>>> logical
connection)
Likewise ZFC was not about what is now called >>>>>>>>>>>>>>>>>>>>>>>>> naive set
theory.
To a large extent it is. Both are intended to >>>>>>>>>>>>>>>>>>>>>>>> describe
those
sets that
were tought to be usefult to think about. But >>>>>>>>>>>>>>>>>>>>>>>> the naive
set
theory failed
because it is inconsistent. However, ZF excludes >>>>>>>>>>>>>>>>>>>>>>>> some sets
that some
people want to consider, e.g., the universal >>>>>>>>>>>>>>>>>>>>>>>> set, Quine's
atom. There is
no agreement whether do not satisfy the axiom of >>>>>>>>>>>>>>>>>>>>>>>> choice
and
its various
consequences should be included or excluded, so >>>>>>>>>>>>>>>>>>>>>>>> both ZF
and
ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to >>>>>>>>>>>>>>>>>>>>>> exist or not
to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms >>>>>>>>>>>>>>>>>>>>> It is the same as every person that is their own >>>>>>>>>>>>>>>>>>>>> father.
No, it is not the same. Being of ones own father is >>>>>>>>>>>>>>>>>>>> impossible
because
of the say the material world works. Imaginary >>>>>>>>>>>>>>>>>>>> things like sets
can be
imagined to work wichever way one wants to imagine, >>>>>>>>>>>>>>>>>>>> though a
consitent
imagination is more useful.
If that was true then one could imagine the >>>>>>>>>>>>>>>>>>> coherent set of properties of a square circle. >>>>>>>>>>>>>>>>>>
an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT >>>>>>>>>>>>>>>>> HALTING*
Depends on what exactly your "can" and "possibly" mean. >>>>>>>>>>>>>>>> Anyway, DDD does
reach its final state, so its wrong to say that it can't. >>>>>>>>>>>>>>>
If you don't tell why you do so why would anyone else? >>>>>>>>>>>>>>
I USE CUT-AND-PASTE MAKING SURE THAT
MY WORDS ARE PERFECTLY UNCHANGED.
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* because >>>>>>>>>>>>> this input specifies that HHH simulates itself simulating DDD. >>>>>>>>>>>>>
*Every rebuttal to this changes the words*
Sounds perfect for me (but like others: you may have posted >>>>>>>>>>>> "1+2=3"
, or various tautology, as proof that your POOH is correct). >>>>>>>>>>>> No, all such are irrelevant.
HP asks for "THE H" that decide the halting property of its >>>>>>>>>>>> argument.
The input to HHH(DDD) specifies non-halting behavior.
int main()
{
DDD(); // calls HHH(DDD)
}
It is ridiculously stupid to require HHH(DDD)
to report on the behavior of the direct execution
of DDD() because this DDD() *IS ITS CALLER*
and not its input.
So, you are saying the Halting Problem is ridiculous?
Show how any function could report on the behavior
of its caller and your failure will prove that I am
correct.
No. You are right that not all functions can report on the behavior >>>>>>>> of its caller. But that is what the HP proof suggests.
No it does not suggest this.
Yes, it does, see latter.
The issue is that no one
ever bothered to specify ALL of the details of the HP
proof to see that a halt decider is required to report
on the behavior of its caller. That is why I resorted
to the C language that can show 100% of every single
detail.
You don't understand what the HP says.
The HP simply EQUIVALENTLY asks for such H that "H(D)==1 iff D()
halts".
Note that I say 'equivalently' is because it is too technical for
you to understand.
You are learning by rote. All the function form of HP are easier
for teaching purpose.
You are admitting the HP is correct, and provide POOH claiming the >>>>>>>> HP proof is incorrect!
That the HP proof requires a halt decider to report on
the behavior of its caller is flat out nuts proving
that this aspect of the HP proof is complete nonsense.
The HP simply EQUIVALENTLY asks for such H that "H(D)==1 iff D()
halts".
and no one bothered to notice that this
requires H to report on the behavior of its caller
void D()
{
H(D);
return;
}
int main()
{
D(); // calls H(D)
}
What D does is not H's concern.
H(D) is required to report on the behavior that
its input specifies.
Invoked H(D) simulates D that calls H(D)
that simulates D that calls H(D)
that simulates D that calls H(D)
that simulates D that calls H(D)
that simulates D that calls H(D)...
Yes, the D() above looks like a infinite recursive call.
Other people or you are seemingly pointing to D and talking
something else.
Yes all other people (especially Dennis Bush) are saying
that H(D) is required to report on the behavior of the
direct execution of D() never noticing that this stupidly
requires H(D) to report on the behavior of its caller.
If the H above means the H that the HP refers to. The H is required to
report its argument's behavior (ie. by H(D)). But NOT required by
simulation.
It turns out that no one ever noticed that simulating halt
deciders nullify the HP counter-example input in that this
input cannot possibly reach its contradictory part.
The HP does not care what D does (simply to say).
Everyone says that H(D) must re[port on the behavior of
the direct execution of D().
The HP only requires: H(D)==1 iff D() halts
int main()
{
D(); // calls H(D)
}
Which requires H(D) to report on the behavior of its
caller instead of reporting on the behavior that its
input actually specifies.
On 6/11/2025 4:57 PM, wij wrote:
On Wed, 2025-06-11 at 16:44 -0500, olcott wrote:
On 6/11/2025 4:23 PM, wij wrote:
On Wed, 2025-06-11 at 16:10 -0500, olcott wrote:
On 6/11/2025 3:59 PM, wij wrote:
On Wed, 2025-06-11 at 15:30 -0500, olcott wrote:
On 6/11/2025 2:45 PM, wij wrote:
On Wed, 2025-06-11 at 14:39 -0500, olcott wrote:
On 6/11/2025 2:31 PM, wij wrote:
On Wed, 2025-06-11 at 14:14 -0500, olcott wrote:
On 6/11/2025 1:25 PM, wij wrote:
On Wed, 2025-06-11 at 12:59 -0500, olcott wrote:
If the H above means the H that the HP refers to. The H is >>>>>>>>>>>>>> required to
Yes all other people (especially Dennis Bush) are saying >>>>>>>>>>>>>>> that H(D) is required to report on the behavior of the >>>>>>>>>>>>>>> direct execution of D() never noticing that this stupidly >>>>>>>>>>>>>>> requires H(D) to report on the behavior of its caller. >>>>>>>>>>>>>>
report its argument's behavior (ie. by H(D)). But NOT >>>>>>>>>>>>>> required by simulation.
It turns out that no one ever noticed that simulating halt >>>>>>>>>>>>> deciders nullify the HP counter-example input in that this >>>>>>>>>>>>> input cannot possibly reach its contradictory part.
The HP does not care what D does (simply to say).
Everyone says that H(D) must re[port on the behavior of >>>>>>>>>>>>> the direct execution of D().
That is what the HP asks.
The HP only requires: H(D)==1 iff D() halts
int main()
{
D(); // calls H(D)
}
Which requires H(D) to report on the behavior of its >>>>>>>>>>>>> caller instead of reporting on the behavior that its >>>>>>>>>>>>> input actually specifies.
That is no problem. H does not care what D does inside >>>>>>>>>>>> (simply to say).
The HP simply asks for a H that "H(D)==1 iff D() halts". >>>>>>>>>>>>
Which requires H to report on something that it cannot
possibly see.
On the contrary, what the HP proves is very useful.
I am not talking about the halting problem, I have always
been talking about the conventional halting problem proof.
THIS PROOF IS WRONG
When talking about proof, we say it is valid or not. By doing
so, we have
to unambiguously pose the problem and the derivation to the
conclusion.
The HP proof just did that.
It may seem that way if you pay less than 100%
complete attention.
The HP proof depends on an *INPUT* that does
the opposite of whatever value that H returns
and no such *INPUT* can possibly exist.
That is absolutely correct. No such *INPUT* (i.e. D) can possible
exit is because
the H inside D does not exist at all.
So, if the H is assumed to exist, then D will exist to make H
undecidable.
There is no *input* to any termination analyzer
that can do the opposite of whatever value that
this termination analyzer returns
Your reinterpretation of of HP case is wrong.
Your D or H is not the case mention in the HP proof.
There cannot possibly exist any D mine or
anyone else's that is encoded to do the opposite
of whatever value that H returns.
Why not? D and H are supposed to be TM (or C function).
If the D cannot do the opposite of whatever value that H returns, then
that D is not powerful enough to be a TM, not an interesting case.
Can you be your biological mother's biological father?
It is for this same reason that the function's caller
cannot simultaneously be its input.
On 6/11/2025 3:56 AM, Mikko wrote:
On 2025-06-10 16:51:49 +0000, olcott said:
On 6/10/2025 2:12 AM, Mikko wrote:
On 2025-06-08 05:38:26 +0000, olcott said:
On 6/8/2025 12:20 AM, Mikko wrote:
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:To a large extent it is. Both are intended to describe those sets that
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote: >>>>>>>>>>>>>>> On 03/06/2025 13:45, dbush wrote:Likewise ZFC was not about what is now called naive set theory. >>>>>>>>>>>>
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his
position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in
order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though
it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to the
multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why
PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it.
Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond
that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the
planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path
of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but
it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection) >>>>>>>>>>>>>
were tought to be usefult to think about. But the naive set theory failed
because it is inconsistent. However, ZF excludes some sets that some
people want to consider, e.g., the universal set, Quine's atom. There is
no agreement whether do not satisfy the axiom of choice and its various
consequences should be included or excluded, so both ZF and ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms
It is the same as every person that is their own father.
No, it is not the same. Being of ones own father is impossible because >>>>>>>> of the say the material world works. Imaginary things like sets can be >>>>>>>> imagined to work wichever way one wants to imagine, though a consitent >>>>>>>> imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
One can, much like you can imagine the coherent set of properties of >>>>>> an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Depends on what exactly your "can" and "possibly" mean. Anyway, DDD does >>>> reach its final state, so its wrong to say that it can't.
Why do people always have to be damned liars and change
my words and then dishonestly apply their rebuttal to
these changed words.
If you don't tell why you do so why would anyone else?
I USE CUT-AND-PASTE MAKING SURE THAT
MY WORDS ARE PERFECTLY UNCHANGED.
On 6/11/2025 4:06 AM, Mikko wrote:
On 2025-06-10 17:12:24 +0000, olcott said:
On 6/10/2025 2:25 AM, Mikko wrote:
On 2025-06-08 06:00:50 +0000, olcott said:
On 6/8/2025 12:49 AM, Mikko wrote:
On 2025-06-04 16:27:48 +0000, olcott said:
On 6/4/2025 2:32 AM, Mikko wrote:
On 2025-06-03 20:28:36 +0000, olcott said:
On 6/3/2025 2:55 AM, Mikko wrote:
On 2025-06-02 15:23:15 +0000, olcott said:
On 6/2/2025 1:56 AM, Mikko wrote:
On 2025-06-01 21:41:36 +0000, olcott said:
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*
It does not matter whether a particular simulation does or does not
reach its "return" instruction.
It completely matters. DDD correctly simulated by HHH
proves the exact behavior that the input to HHH(DDD)
actually specifies.
It proves nothing without a proof that DDD is correctly simulated by HHH.
I have shown that proof too many times and people
denied the very obvious verified facts of it.
You have never shown any proof of anything. But a verifiable and verified
fact is that DDD halts. An obvious conseqence of that fact is that every
report that means 'DDD does not halt' is wrong.
When I provide proof that you cannot understand
this does not mean that I did not provide proof.
Yes, it does.
What I just said is a truism, tautology, self-evident truth.
No, it is not. It was an attempt to deceive with a false ad hominem.
When self-evident truth are not understood they remain
self-evident.
Likewise, what is not a self-evident truth does not become one
when falsely claimed to be a self-evindet truth.
For example, "what I don't understand is not a proof" is not self-evident. >> It depends on the additional information "I can understand proofs" that
you can't have.
If I show the steps of solving for X in an algebra
problem and you do not know as much as how to count
to five this does not mean that my proof is incorrect.
Likewse, "When I provide proof that you cannot understand this does not
mean that I did not provide proof" is not self-evident as it assumes
there are proofs that I cannot understand at least to the extent that I
can recognise them as proofs. But that assumption is not self-evident
and not true.
Most every rebuttal of my work changes the words that
I actually said and then rebuts these changed words.
On 6/11/2025 7:03 PM, wij wrote:
On Wed, 2025-06-11 at 18:45 -0500, olcott wrote:
On 6/11/2025 6:25 PM, wij wrote:
On Wed, 2025-06-11 at 17:33 -0500, olcott wrote:
On 6/11/2025 4:57 PM, wij wrote:
On Wed, 2025-06-11 at 16:44 -0500, olcott wrote:
On 6/11/2025 4:23 PM, wij wrote:
On Wed, 2025-06-11 at 16:10 -0500, olcott wrote:
On 6/11/2025 3:59 PM, wij wrote:
On Wed, 2025-06-11 at 15:30 -0500, olcott wrote:
On 6/11/2025 2:45 PM, wij wrote:
On Wed, 2025-06-11 at 14:39 -0500, olcott wrote:
On 6/11/2025 2:31 PM, wij wrote:
On Wed, 2025-06-11 at 14:14 -0500, olcott wrote:
On 6/11/2025 1:25 PM, wij wrote:
On Wed, 2025-06-11 at 12:59 -0500, olcott wrote:
It turns out that no one ever noticed that simulating >>>>>>>>>>>>>>>>> halt deciders nullify the HP counter-example input in >>>>>>>>>>>>>>>>> that this input cannot possibly reach its contradictory >>>>>>>>>>>>>>>>> part.
Which requires H(D) to report on the behavior of its >>>>>>>>>>>>>>>>> caller instead of reporting on the behavior that its >>>>>>>>>>>>>>>>> input actually specifies.
There cannot possibly exist any D mine or anyone else's that isThere is no *input* to any termination analyzer that can do the >>>>>>>>> opposite of whatever value that this termination analyzer
returns
Your reinterpretation of of HP case is wrong.
Your D or H is not the case mention in the HP proof.
encoded to do the opposite of whatever value that H returns.
lol.Yes and we have the exact same issue with TM's it is merely more
difficult to see.
I am not going to get into that until after you totally understand
this at the C level. I am unwilling to talk about this endlessly in
circles.
No D that anyone in the universe can define can simultaneously be theD has to be able to perform exactly H's function (if D is a TM and ifI have to covered too. Unless you understand that D cannot be both an
H exists).
Otherwise, that D is not the counter-example mentioned in the HP
proof.
input to H and its caller there is no sense going there.
If it (D) cannot be both an input to H and its caller, that D is no
resemble of the counter-example mentioned in the HP proof. You made a
crippled D.
caller of a function and the input to the same function.
If you think that it can then provide such a D.
On 6/11/2025 7:34 PM, wij wrote:
On Wed, 2025-06-11 at 19:20 -0500, olcott wrote:
On 6/11/2025 7:03 PM, wij wrote:
On Wed, 2025-06-11 at 18:45 -0500, olcott wrote:
On 6/11/2025 6:25 PM, wij wrote:
On Wed, 2025-06-11 at 17:33 -0500, olcott wrote:
On 6/11/2025 4:57 PM, wij wrote:
On Wed, 2025-06-11 at 16:44 -0500, olcott wrote:
On 6/11/2025 4:23 PM, wij wrote:
On Wed, 2025-06-11 at 16:10 -0500, olcott wrote:
On 6/11/2025 3:59 PM, wij wrote:
On Wed, 2025-06-11 at 15:30 -0500, olcott wrote:
On 6/11/2025 2:45 PM, wij wrote:
On Wed, 2025-06-11 at 14:39 -0500, olcott wrote:
On 6/11/2025 2:31 PM, wij wrote:
On Wed, 2025-06-11 at 14:14 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 6/11/2025 1:25 PM, wij wrote:
On Wed, 2025-06-11 at 12:59 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>>>>
Yes all other people (especially Dennis Bush) are >>>>>>>>>>>>>>>>>>>>> sayingIf the H above means the H that the HP refers to. >>>>>>>>>>>>>>>>>>>> The H is
that H(D) is required to report on the behavior of the >>>>>>>>>>>>>>>>>>>>> direct execution of D() never noticing that this >>>>>>>>>>>>>>>>>>>>> stupidly
requires H(D) to report on the behavior of its caller. >>>>>>>>>>>>>>>>>>>>
required to
report its argument's behavior (ie. by H(D)). But >>>>>>>>>>>>>>>>>>>> NOT required by
simulation.
It turns out that no one ever noticed that simulating >>>>>>>>>>>>>>>>>>> halt
deciders nullify the HP counter-example input in that >>>>>>>>>>>>>>>>>>> this
input cannot possibly reach its contradictory part. >>>>>>>>>>>>>>>>>>>
The HP does not care what D does (simply to say). >>>>>>>>>>>>>>>>>>>>
Everyone says that H(D) must re[port on the behavior of >>>>>>>>>>>>>>>>>>> the direct execution of D().
That is what the HP asks.
The HP only requires: H(D)==1 iff D() halts >>>>>>>>>>>>>>>>>>>>
int main()
{
D(); // calls H(D) >>>>>>>>>>>>>>>>>>> }
Which requires H(D) to report on the behavior of its >>>>>>>>>>>>>>>>>>> caller instead of reporting on the behavior that its >>>>>>>>>>>>>>>>>>> input actually specifies.
That is no problem. H does not care what D does inside >>>>>>>>>>>>>>>>>> (simply to
say).
The HP simply asks for a H that "H(D)==1 iff D() halts". >>>>>>>>>>>>>>>>>>
Which requires H to report on something that it cannot >>>>>>>>>>>>>>>>> possibly see.
On the contrary, what the HP proves is very useful. >>>>>>>>>>>>>>>>
I am not talking about the halting problem, I have always >>>>>>>>>>>>>>> been talking about the conventional halting problem proof. >>>>>>>>>>>>>>> THIS PROOF IS WRONG
When talking about proof, we say it is valid or not. By >>>>>>>>>>>>>> doing so, we have
to unambiguously pose the problem and the derivation to >>>>>>>>>>>>>> the conclusion.
The HP proof just did that.
It may seem that way if you pay less than 100%
complete attention.
The HP proof depends on an *INPUT* that does
the opposite of whatever value that H returns
and no such *INPUT* can possibly exist.
That is absolutely correct. No such *INPUT* (i.e. D) can >>>>>>>>>>>> possible exit is because
the H inside D does not exist at all.
So, if the H is assumed to exist, then D will exist to make >>>>>>>>>>>> H undecidable.
There is no *input* to any termination analyzer
that can do the opposite of whatever value that
this termination analyzer returns
Your reinterpretation of of HP case is wrong.
Your D or H is not the case mention in the HP proof.
There cannot possibly exist any D mine or
anyone else's that is encoded to do the opposite
of whatever value that H returns.
Why not? D and H are supposed to be TM (or C function).
If the D cannot do the opposite of whatever value that H
returns, then
that D is not powerful enough to be a TM, not an interesting case. >>>>>>>>
Can you be your biological mother's biological father?
What is the same reason? What's the relationship of 1+1=2 relates
to HP?
It is for this same reason that the function's caller
cannot simultaneously be its input.
D and H belong to the same set of TM equivalent stuff.
Yes and we have the exact same issue with TM's it
is merely more difficult to see.
I am not going to get into that until after you totally
understand this at the C level. I am unwilling to talk
about this endlessly in circles.
The problem is that you don't know TM and C as 1-year CS student does. >>>> All the people here have problem to get the answer fits your level
of understanding.
D has to be able to perform exactly H's function (if D is a TM and >>>>>> if H exists).I have to covered too. Unless you understand that
Otherwise, that D is not the counter-example mentioned in the HP
proof.
D cannot be both an input to H and its caller there
is no sense going there.
If it (D) cannot be both an input to H and its caller, that D is no
resemble of
the counter-example mentioned in the HP proof. You made a crippled D.
No D that anyone in the universe can define
can simultaneously be the caller of a function
and the input to the same function.
Then, what does your example mean?
void D() {
H(D);
}
D cannot simultaneously be the caller of a function
and the input to the same function?
Are you refuting what you said?
If you don't understand the difference between object
instances of OOP classes and the classes themselves
then you might not understand.
int main()
{
D(); // calls H(D) and the parameter to this H(D)
} // is not the caller of this instance of H(D)
On 6/11/2025 8:23 PM, wij wrote:
On Wed, 2025-06-11 at 19:52 -0500, olcott wrote:
On 6/11/2025 7:34 PM, wij wrote:
On Wed, 2025-06-11 at 19:20 -0500, olcott wrote:
On 6/11/2025 7:03 PM, wij wrote:
On Wed, 2025-06-11 at 18:45 -0500, olcott wrote:
On 6/11/2025 6:25 PM, wij wrote:
On Wed, 2025-06-11 at 17:33 -0500, olcott wrote:
On 6/11/2025 4:57 PM, wij wrote:
On Wed, 2025-06-11 at 16:44 -0500, olcott wrote:
On 6/11/2025 4:23 PM, wij wrote:
On Wed, 2025-06-11 at 16:10 -0500, olcott wrote:
On 6/11/2025 3:59 PM, wij wrote:
On Wed, 2025-06-11 at 15:30 -0500, olcott wrote:
On 6/11/2025 2:45 PM, wij wrote:
On Wed, 2025-06-11 at 14:39 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 6/11/2025 2:31 PM, wij wrote:
On Wed, 2025-06-11 at 14:14 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>> On 6/11/2025 1:25 PM, wij wrote:
On Wed, 2025-06-11 at 12:59 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>
Yes all other people (especially Dennis Bush) are >>>>>>>>>>>>>>>>>>>>>>> saying
that H(D) is required to report on the behavior >>>>>>>>>>>>>>>>>>>>>>> of the
direct execution of D() never noticing that this >>>>>>>>>>>>>>>>>>>>>>> stupidly
requires H(D) to report on the behavior of its >>>>>>>>>>>>>>>>>>>>>>> caller.
If the H above means the H that the HP refers to. >>>>>>>>>>>>>>>>>>>>>> The H is
required to
report its argument's behavior (ie. by H(D)). But >>>>>>>>>>>>>>>>>>>>>> NOT required
by
simulation.
It turns out that no one ever noticed that >>>>>>>>>>>>>>>>>>>>> simulating halt
deciders nullify the HP counter-example input in >>>>>>>>>>>>>>>>>>>>> that this
input cannot possibly reach its contradictory part. >>>>>>>>>>>>>>>>>>>>>
The HP does not care what D does (simply to say). >>>>>>>>>>>>>>>>>>>>>>
Everyone says that H(D) must re[port on the >>>>>>>>>>>>>>>>>>>>> behavior of
the direct execution of D().
That is what the HP asks.
The HP only requires: H(D)==1 iff D() halts >>>>>>>>>>>>>>>>>>>>>>
int main()
{
D(); // calls H(D) >>>>>>>>>>>>>>>>>>>>> }
Which requires H(D) to report on the behavior of its >>>>>>>>>>>>>>>>>>>>> caller instead of reporting on the behavior that its >>>>>>>>>>>>>>>>>>>>> input actually specifies.
That is no problem. H does not care what D does >>>>>>>>>>>>>>>>>>>> inside (simply to
say).
The HP simply asks for a H that "H(D)==1 iff D() >>>>>>>>>>>>>>>>>>>> halts".
Which requires H to report on something that it >>>>>>>>>>>>>>>>>>> cannot possibly see.
On the contrary, what the HP proves is very useful. >>>>>>>>>>>>>>>>>>
I am not talking about the halting problem, I have always >>>>>>>>>>>>>>>>> been talking about the conventional halting problem proof. >>>>>>>>>>>>>>>>> THIS PROOF IS WRONG
When talking about proof, we say it is valid or not. By >>>>>>>>>>>>>>>> doing so, we have
to unambiguously pose the problem and the derivation to >>>>>>>>>>>>>>>> the conclusion.
The HP proof just did that.
It may seem that way if you pay less than 100%
complete attention.
The HP proof depends on an *INPUT* that does
the opposite of whatever value that H returns
and no such *INPUT* can possibly exist.
That is absolutely correct. No such *INPUT* (i.e. D) can >>>>>>>>>>>>>> possible exit is
because
the H inside D does not exist at all.
So, if the H is assumed to exist, then D will exist to >>>>>>>>>>>>>> make H undecidable.
There is no *input* to any termination analyzer
that can do the opposite of whatever value that
this termination analyzer returns
Your reinterpretation of of HP case is wrong.
Your D or H is not the case mention in the HP proof.
There cannot possibly exist any D mine or
anyone else's that is encoded to do the opposite
of whatever value that H returns.
Why not? D and H are supposed to be TM (or C function).
If the D cannot do the opposite of whatever value that H
returns, then
that D is not powerful enough to be a TM, not an interesting >>>>>>>>>> case.
Can you be your biological mother's biological father?
What is the same reason? What's the relationship of 1+1=2
relates to HP?
It is for this same reason that the function's caller
cannot simultaneously be its input.
D and H belong to the same set of TM equivalent stuff.
Yes and we have the exact same issue with TM's it
is merely more difficult to see.
I am not going to get into that until after you totally
understand this at the C level. I am unwilling to talk
about this endlessly in circles.
The problem is that you don't know TM and C as 1-year CS student
does.
All the people here have problem to get the answer fits your level >>>>>> of understanding.
D has to be able to perform exactly H's function (if D is a TM >>>>>>>> and if H exists).I have to covered too. Unless you understand that
Otherwise, that D is not the counter-example mentioned in the HP >>>>>>>> proof.
D cannot be both an input to H and its caller there
is no sense going there.
If it (D) cannot be both an input to H and its caller, that D is
no resemble of
the counter-example mentioned in the HP proof. You made a crippled D. >>>>>>
No D that anyone in the universe can define
can simultaneously be the caller of a function
and the input to the same function.
Then, what does your example mean?
void D() {
H(D);
}
D cannot simultaneously be the caller of a function
and the input to the same function?
Are you refuting what you said?
If you don't understand the difference between object
instances of OOP classes and the classes themselves
then you might not understand.
OK. its now OOP and C++'s class. Where are they?
Are you honest about what you said?
int main()
{
D(); // calls H(D) and the parameter to this H(D)
} // is not the caller of this instance of H(D)
Where is H? Are you talking about Halting Problem?
D() is my DDD() and H() is my HHH().
HHH is a termination analyzer.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
My DD() is the Halting Problem counter-example
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH(DD) correctly rejects its input.
On 6/12/2025 3:50 AM, joes wrote:I mean... yes, it is? Unless your execution environment allows assigning different things the same name, DDD refers to exactly one function at
Am Wed, 11 Jun 2025 19:20:30 -0500 schrieb olcott:
On 6/11/2025 7:03 PM, wij wrote:
On Wed, 2025-06-11 at 18:45 -0500, olcott wrote:
On 6/11/2025 6:25 PM, wij wrote:
On Wed, 2025-06-11 at 17:33 -0500, olcott wrote:
On 6/11/2025 4:57 PM, wij wrote:
On Wed, 2025-06-11 at 16:44 -0500, olcott wrote:
On 6/11/2025 4:23 PM, wij wrote:
On Wed, 2025-06-11 at 16:10 -0500, olcott wrote:
On 6/11/2025 3:59 PM, wij wrote:
On Wed, 2025-06-11 at 15:30 -0500, olcott wrote:
On 6/11/2025 2:45 PM, wij wrote:
On Wed, 2025-06-11 at 14:39 -0500, olcott wrote:
On 6/11/2025 2:31 PM, wij wrote:
On Wed, 2025-06-11 at 14:14 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 6/11/2025 1:25 PM, wij wrote:
On Wed, 2025-06-11 at 12:59 -0500, olcott wrote:
It turns out that no one ever noticed that simulating >>>>>>>>>>>>>>>>>>> halt deciders nullify the HP counter-example input in >>>>>>>>>>>>>>>>>>> that this input cannot possibly reach its >>>>>>>>>>>>>>>>>>> contradictory part.
DDD does reach that part; HHH doesn't. When HHH simulates DDD, DDD is
not running (on the processor), it is passive data executed by HHH.
Which requires H(D) to report on the behavior of its >>>>>>>>>>>>>>>>>>> caller instead of reporting on the behavior that its >>>>>>>>>>>>>>>>>>> input actually specifies.
What do you mean by "actually specifies"?
There cannot possibly exist any D mine or anyone else's that is >>>>>>>>> encoded to do the opposite of whatever value that H returns.
What does your DDD do? Do as HHH says?
lol.I am not going to get into that until after you totally understand
this at the C level. I am unwilling to talk about this endlessly in
circles.
No D that anyone in the universe can define can simultaneously be the
caller of a function and the input to the same function.
If you think that it can then provide such a D.
Oh, how you are wrong. It is an elementary part of CS that data can be
interpreted as code and code has a data representation.
int main()
{
DDD(); // calls HHH(DDD) its parameter is not its caller
}
On 6/12/2025 11:22 AM, joes wrote:Please clarify. Does "DDD" refer to two different programs?
Am Thu, 12 Jun 2025 10:46:48 -0500 schrieb olcott:
On 6/12/2025 3:50 AM, joes wrote:
Am Wed, 11 Jun 2025 19:20:30 -0500 schrieb olcott:
On 6/11/2025 7:03 PM, wij wrote:
On Wed, 2025-06-11 at 18:45 -0500, olcott wrote:
On 6/11/2025 6:25 PM, wij wrote:
On Wed, 2025-06-11 at 17:33 -0500, olcott wrote:
On 6/11/2025 4:57 PM, wij wrote:
On Wed, 2025-06-11 at 16:44 -0500, olcott wrote:
On 6/11/2025 4:23 PM, wij wrote:
On Wed, 2025-06-11 at 16:10 -0500, olcott wrote:
On 6/11/2025 3:59 PM, wij wrote:
On Wed, 2025-06-11 at 15:30 -0500, olcott wrote:
On 6/11/2025 2:45 PM, wij wrote:
On Wed, 2025-06-11 at 14:39 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 6/11/2025 2:31 PM, wij wrote:
On Wed, 2025-06-11 at 14:14 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>> On 6/11/2025 1:25 PM, wij wrote:
On Wed, 2025-06-11 at 12:59 -0500, olcott wrote:
possibly reach its contradictory part.
DDD does reach that part; HHH doesn't. When HHH simulates DDD, DDD is
not running (on the processor), it is passive data executed by HHH.
input actually specifies.
What do you mean by "actually specifies"?
There cannot possibly exist any D mine or anyone else's that >>>>>>>>>>> is encoded to do the opposite of whatever value that H
returns.
What does your DDD do? Do as HHH says?
No D that anyone in the universe can define can simultaneously be
the caller of a function and the input to the same function.
If you think that it can then provide such a D.
Oh, how you are wrong. It is an elementary part of CS that data can
be interpreted as code and code has a data representation.
int main()
{
DDD(); // calls HHH(DDD) its parameter is not its caller
}
I mean... yes, it is?
No you are wrong.
DDD correctly simulated by HHH cannot possibly reach its own simulated "return" statement final halt state.DDD doesn't reach anything, HHH does (or doesn't). By nature no simulator
--Unless your execution environment allows assigning different things the
same name, DDD refers to exactly one function at one address. Why don't
you say that you mean the specific invocation at this point in the call
stack?
And what about the rest of my reply above and what you snipped?
On 6/12/2025 3:10 AM, Mikko wrote:
Putting them to a web page would achieve the same with lesser effort.
A web-page is not a permanent archive.
On 6/12/2025 3:50 AM, joes wrote:
Am Wed, 11 Jun 2025 19:20:30 -0500 schrieb olcott:
On 6/11/2025 7:03 PM, wij wrote:
On Wed, 2025-06-11 at 18:45 -0500, olcott wrote:
On 6/11/2025 6:25 PM, wij wrote:
On Wed, 2025-06-11 at 17:33 -0500, olcott wrote:
On 6/11/2025 4:57 PM, wij wrote:
On Wed, 2025-06-11 at 16:44 -0500, olcott wrote:
On 6/11/2025 4:23 PM, wij wrote:
On Wed, 2025-06-11 at 16:10 -0500, olcott wrote:
On 6/11/2025 3:59 PM, wij wrote:
On Wed, 2025-06-11 at 15:30 -0500, olcott wrote:
On 6/11/2025 2:45 PM, wij wrote:
On Wed, 2025-06-11 at 14:39 -0500, olcott wrote:
On 6/11/2025 2:31 PM, wij wrote:
On Wed, 2025-06-11 at 14:14 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 6/11/2025 1:25 PM, wij wrote:
On Wed, 2025-06-11 at 12:59 -0500, olcott wrote:
It turns out that no one ever noticed that simulating >>>>>>>>>>>>>>>>>>> halt deciders nullify the HP counter-example input in >>>>>>>>>>>>>>>>>>> that this input cannot possibly reach its contradictory >>>>>>>>>>>>>>>>>>> part.
DDD does reach that part; HHH doesn't. When HHH simulates DDD, DDD is
not running (on the processor), it is passive data executed by HHH.
Which requires H(D) to report on the behavior of its >>>>>>>>>>>>>>>>>>> caller instead of reporting on the behavior that its >>>>>>>>>>>>>>>>>>> input actually specifies.
What do you mean by "actually specifies"?
There cannot possibly exist any D mine or anyone else's that is >>>>>>>>> encoded to do the opposite of whatever value that H returns.There is no *input* to any termination analyzer that can do the >>>>>>>>>>> opposite of whatever value that this termination analyzer >>>>>>>>>>> returns
Your reinterpretation of of HP case is wrong.
Your D or H is not the case mention in the HP proof.
What does your DDD do? Do as HHH says?
lol.Yes and we have the exact same issue with TM's it is merely more
difficult to see.
I am not going to get into that until after you totally understand
this at the C level. I am unwilling to talk about this endlessly in
circles.
No D that anyone in the universe can define can simultaneously be theD has to be able to perform exactly H's function (if D is a TM and if >>>>>> H exists).I have to covered too. Unless you understand that D cannot be both an >>>>> input to H and its caller there is no sense going there.
Otherwise, that D is not the counter-example mentioned in the HP
proof.
If it (D) cannot be both an input to H and its caller, that D is no
resemble of the counter-example mentioned in the HP proof. You made a
crippled D.
caller of a function and the input to the same function.
If you think that it can then provide such a D.
Oh, how you are wrong. It is an elementary part of CS that data can be
interpreted as code and code has a data representation.
int main()
{
DDD(); // calls HHH(DDD) its parameter is not its caller
}
On 6/12/2025 5:29 PM, André G. Isaak wrote:
On 2025-06-12 09:19, olcott wrote:
On 6/12/2025 3:10 AM, Mikko wrote:
Putting them to a web page would achieve the same with lesser effort.
A web-page is not a permanent archive.
It's more permanent than a Usenet post.
André
USENET posts are as permanent as their storage
by providers. GigaNews goes back to 2003. Some
archives go back much further.
Here is me in an archive from 2004
https://www.usenetarchives.com/view.php? id=comp.theory&mid=PFlnVkhjLjIyNzU5NCRHeDQuMjUxMTdAYmd0bnNjMDQtbmV3cy5vcHMud29ybGRuZXQuYXR0Lm5ldD4
On 6/12/2025 4:37 AM, Fred. Zwarts wrote:
Op 12.jun.2025 om 02:52 schreef olcott:void DDD()
The analyser should not decide about an instance, but about what is
If you don't understand the difference between object
instances of OOP classes and the classes themselves
then you might not understand.
int main()
{
D(); // calls H(D) and the parameter to this H(D)
} // is not the caller of this instance of H(D)
specified by the code.
{
HHH(DDD);
return;
}
The input to HHH(DDD) specifies a sequence of configurations
that cannot possibly reach their own "return" statement
final halt state.
That you are insufficiently competent to see this is proven
by the fact that you have no rebuttal anchored in correct
reasoning.
On 6/12/2025 3:10 AM, Mikko wrote:
On 2025-06-11 14:20:39 +0000, olcott said:
On 6/11/2025 3:56 AM, Mikko wrote:
On 2025-06-10 16:51:49 +0000, olcott said:
On 6/10/2025 2:12 AM, Mikko wrote:
On 2025-06-08 05:38:26 +0000, olcott said:
On 6/8/2025 12:20 AM, Mikko wrote:
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:To a large extent it is. Both are intended to describe those sets that
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote: >>>>>>>>>>>>>>>>> On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote:
Even if presented with /direct observations/ contradicting his
position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in
order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though
it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to the
multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why
PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it.
Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond
that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the
planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path
of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but
it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection)
Likewise ZFC was not about what is now called naive set theory. >>>>>>>>>>>>>>
were tought to be usefult to think about. But the naive set theory failed
because it is inconsistent. However, ZF excludes some sets that some
people want to consider, e.g., the universal set, Quine's atom. There is
no agreement whether do not satisfy the axiom of choice and its various
consequences should be included or excluded, so both ZF and ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms
It is the same as every person that is their own father.
No, it is not the same. Being of ones own father is impossible because
of the say the material world works. Imaginary things like sets can be
imagined to work wichever way one wants to imagine, though a consitent
imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
One can, much like you can imagine the coherent set of properties of >>>>>>>> an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Depends on what exactly your "can" and "possibly" mean. Anyway, DDD does >>>>>> reach its final state, so its wrong to say that it can't.
Why do people always have to be damned liars and change
my words and then dishonestly apply their rebuttal to
these changed words.
If you don't tell why you do so why would anyone else?
I USE CUT-AND-PASTE MAKING SURE THAT
MY WORDS ARE PERFECTLY UNCHANGED.
Putting them to a web page would achieve the same with lesser effort.
A web-page is not a permanent archive.
On 6/13/2025 6:53 AM, Mikko wrote:
Nothing is permanent. But you can (and to some extent do) maintan a web
page as long as you need it for usenet discussions.
I want people to be able to validate my work 50 years after I am dead.
A web-page will not work for this.
On 6/13/2025 4:11 AM, Fred. Zwarts wrote:
Op 12.jun.2025 om 17:51 schreef olcott:
On 6/12/2025 4:37 AM, Fred. Zwarts wrote:
Op 12.jun.2025 om 02:52 schreef olcott:void DDD()
The analyser should not decide about an instance, but about what is
If you don't understand the difference between object
instances of OOP classes and the classes themselves
then you might not understand.
int main()
{
D(); // calls H(D) and the parameter to this H(D)
} // is not the caller of this instance of H(D)
specified by the code.
{
HHH(DDD);
return;
}
The input to HHH(DDD) specifies a sequence of configurations
that cannot possibly reach their own "return" statement
final halt state.
The input is a pointer to code that includes the code to abort and halt.
I m not going to correct you on this again.
I will simply stop looking at anything that you say.
That HHH is not able to reach that part of the code is a failure of
HHH, not a property of the program specified in the input.
counter-factual and over-your-head.
It is a verified fact that unless the outermost HHH(DDD)
aborts its simulation of DDD then this simulated DDD, the
directly executed DDD() and the directly executed HHH()
would never stop running.
That you don't have enough technical skill to verify
this fact should cause you to have the position that
you don't know if this fact is verified. That you
take the position that I am wrong knowing that you
don't understand these things seems dishonest.
That HHH cannot reach it, does not change the specified code.
Within a correct execution trace unreachable code is
the same as non-existent code. That you don't know that
is merely a lack of sufficient technical competence on
your part.
The program aborts as world-class simulators en direct execution of
exactly the same input prove.
int main()
{
DDD(); // calls HHH(DDD) with a different instance of DDD
}
You say that I am wrong and cannot provide all of the details
That you are insufficiently competent to see this is proven
by the fact that you have no rebuttal anchored in correct
reasoning.
Ad hominem attacks only prove your lack of counter-arguments.
showing exactly how and why I am wrong does not count as a
rebuttal. It only counts as incorrect intuition.
You prove your ignorance by the lack of details that
you provide in your purely dogmatic assertions that I
am wrong.
void DDD()
{
HHH(DDD);
return;
}
The input to HHH(DDD) specifies non-halting behavior
in that DDD correctly simulated by HHH cannot possibly
reach its own "return" statement final halt state.
Only a correct simulation of the input to HHH(DDD) by
HHH derives the actual behavior specified by this input.
On 2025-06-13 09:36, olcott wrote:
On 6/13/2025 6:53 AM, Mikko wrote:
Nothing is permanent. But you can (and to some extent do) maintan a web
page as long as you need it for usenet discussions.
I want people to be able to validate my work 50 years after I am dead.
A web-page will not work for this.
Usenet is dying. Do you seriously think it will be around in 50 years?
On 6/13/2025 6:53 AM, Mikko wrote:
On 2025-06-12 15:19:58 +0000, olcott said:
On 6/12/2025 3:10 AM, Mikko wrote:
On 2025-06-11 14:20:39 +0000, olcott said:
On 6/11/2025 3:56 AM, Mikko wrote:
On 2025-06-10 16:51:49 +0000, olcott said:
On 6/10/2025 2:12 AM, Mikko wrote:
On 2025-06-08 05:38:26 +0000, olcott said:
On 6/8/2025 12:20 AM, Mikko wrote:Depends on what exactly your "can" and "possibly" mean. Anyway, DDD does
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:No, it is not the same. Being of ones own father is impossible because
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said:
On 6/3/2025 12:59 PM, wij wrote:
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote: >>>>>>>>>>>>>>>>>>> On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>> Even if presented with /direct observations/ contradicting his
position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in
order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though
it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to the
multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why
PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it.
Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond
that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the
planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path
of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but
it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection)
Likewise ZFC was not about what is now called naive set theory.
To a large extent it is. Both are intended to describe those sets that
were tought to be usefult to think about. But the naive set theory failed
because it is inconsistent. However, ZF excludes some sets that some
people want to consider, e.g., the universal set, Quine's atom. There is
no agreement whether do not satisfy the axiom of choice and its various
consequences should be included or excluded, so both ZF and ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms
It is the same as every person that is their own father. >>>>>>>>>>>>
of the say the material world works. Imaginary things like sets can be
imagined to work wichever way one wants to imagine, though a consitent
imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
One can, much like you can imagine the coherent set of properties of >>>>>>>>>> an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING* >>>>>>>>
reach its final state, so its wrong to say that it can't.
Why do people always have to be damned liars and change
my words and then dishonestly apply their rebuttal to
these changed words.
If you don't tell why you do so why would anyone else?
I USE CUT-AND-PASTE MAKING SURE THAT
MY WORDS ARE PERFECTLY UNCHANGED.
Putting them to a web page would achieve the same with lesser effort.
A web-page is not a permanent archive.
Nothing is permanent. But you can (and to some extent do) maintan a web
page as long as you need it for usenet discussions.
I want people to be able to validate my work 50 years after I am dead.
A web-page will not work for this.
On 6/14/2025 6:26 AM, Mikko wrote:
On 2025-06-13 17:59:23 +0000, André G. Isaak said:
On 2025-06-13 09:36, olcott wrote:
On 6/13/2025 6:53 AM, Mikko wrote:
Nothing is permanent. But you can (and to some extent do) maintan a web >>>>> page as long as you need it for usenet discussions.
I want people to be able to validate my work 50 years after I am dead. >>>> A web-page will not work for this.
Usenet is dying. Do you seriously think it will be around in 50 years?
Some of its contents might still be on some web page.
Storing every text message ever written seems
to take < 1.0 TB.
On 6/14/2025 6:25 AM, Mikko wrote:
On 2025-06-13 15:36:34 +0000, olcott said:
On 6/13/2025 6:53 AM, Mikko wrote:
On 2025-06-12 15:19:58 +0000, olcott said:
On 6/12/2025 3:10 AM, Mikko wrote:
On 2025-06-11 14:20:39 +0000, olcott said:A web-page is not a permanent archive.
On 6/11/2025 3:56 AM, Mikko wrote:
On 2025-06-10 16:51:49 +0000, olcott said:
On 6/10/2025 2:12 AM, Mikko wrote:
On 2025-06-08 05:38:26 +0000, olcott said:
On 6/8/2025 12:20 AM, Mikko wrote:Depends on what exactly your "can" and "possibly" mean. Anyway, DDD does
On 2025-06-07 13:51:33 +0000, olcott said:
On 6/7/2025 3:13 AM, Mikko wrote:
On 2025-06-06 16:17:48 +0000, olcott said:
On 6/6/2025 3:57 AM, Mikko wrote:No, it is not the same. Being of ones own father is impossible because
On 2025-06-04 15:59:10 +0000, olcott said:
On 6/4/2025 2:19 AM, Mikko wrote:
On 2025-06-03 20:00:51 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 6/3/2025 12:59 PM, wij wrote:
On Tue, 2025-06-03 at 16:38 +0100, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>> On 03/06/2025 13:45, dbush wrote:
On 6/2/2025 10:58 PM, Mike Terry wrote: >>>>>>>>>>>>>>>>>>>>>>> Even if presented with /direct observations/ contradicting his
position, PO can (will) just
invent
new magical thinking that only he is smart enough to understand, in
order to somehow justify his
busted intuitions.
My favorite is that the directly executed D(D) doesn't halt even though
it looks like it does:
On 1/24/24 19:18, olcott wrote:
The directly executed D(D) reaches a final state and exits normally.
BECAUSE ANOTHER ASPECT OF THE SAME COMPUTATION HAS BEEN ABORTED,
Thus meeting the correct non-halting criteria if any step of
a computation must be aborted to prevent its infinite execution
then this computation DOES NOT HALT (even if it looks like it does).
Right - magical thinking.
PO simply cannot clearly think through what's going on, due to the
multiple levels involved. In his
head they all become a mush of confustions, but the mystery here is why
PO does not /realise/ that
he can't think his way through it?
When I try something that's beyond me, I soon realise I'm not up to it.
Somehow PO tries, gets into
a total muddle, and concludes "My understanding of this goes beyond
that of everybody else, due to
my powers of unrivalved concentration equalled by almost nobody on the
planet, and my ability to
eliminate extraneous complexity". How did PO ever start down this path
of delusions? Not that that
matters one iota... :)
Mike.
People seem to keep addressing the logic of the implement of POOH, but
it does not matter how
H or D are implemented, because:
1. POOH is not about the Halting Problem (no logical connection)
Likewise ZFC was not about what is now called naive set theory.
To a large extent it is. Both are intended to describe those sets that
were tought to be usefult to think about. But the naive set theory failed
because it is inconsistent. However, ZF excludes some sets that some
people want to consider, e.g., the universal set, Quine's atom. There is
no agreement whether do not satisfy the axiom of choice and its various
consequences should be included or excluded, so both ZF and ZFC are used.
Quine's atom is nonsense.
No, it is not. It is a set that one can assume to exist or not to exist.
https://en.wikipedia.org/wiki/Urelement#Quine_atoms >>>>>>>>>>>>>>> It is the same as every person that is their own father. >>>>>>>>>>>>>>
of the say the material world works. Imaginary things like sets can be
imagined to work wichever way one wants to imagine, though a consitent
imagination is more useful.
If that was true then one could imagine the
coherent set of properties of a square circle.
One can, much like you can imagine the coherent set of properties of
an impossible decider.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING* >>>>>>>>>>
reach its final state, so its wrong to say that it can't.
Why do people always have to be damned liars and change
my words and then dishonestly apply their rebuttal to
these changed words.
If you don't tell why you do so why would anyone else?
I USE CUT-AND-PASTE MAKING SURE THAT
MY WORDS ARE PERFECTLY UNCHANGED.
Putting them to a web page would achieve the same with lesser effort. >>>>>
Nothing is permanent. But you can (and to some extent do) maintan a web >>>> page as long as you need it for usenet discussions.
I want people to be able to validate my work 50 years after I am dead.
A web-page will not work for this.
It is unlikely that anyone would read your postings even if they were
on some web page or a paper or a stone wall. Even if someone happens
to see some of your writings nobody will ever validate anything they
see there.
Everything that I said is a verified fact.
The only reason that others have not agreed
is dishonesty or the lack of sufficient technical competence.
If you want your work to be validated after your death you must first
publish it in a respectable journal in a way that sufficiently mny
later articles by other people will refer to it.
I can't do that unless it is validated before my death.
On 6/15/2025 4:46 AM, Mikko wrote:
On 2025-06-14 13:44:30 +0000, olcott said:
On 6/14/2025 6:26 AM, Mikko wrote:
On 2025-06-13 17:59:23 +0000, André G. Isaak said:
On 2025-06-13 09:36, olcott wrote:Some of its contents might still be on some web page.
On 6/13/2025 6:53 AM, Mikko wrote:
Nothing is permanent. But you can (and to some extent do) maintan >>>>>>> a web
page as long as you need it for usenet discussions.
I want people to be able to validate my work 50 years after I am
dead.
A web-page will not work for this.
Usenet is dying. Do you seriously think it will be around in 50 years? >>>>
Storing every text message ever written seems
to take < 1.0 TB.
Doesn't matter. Unlikely that anyone would even notice that you wanted
a validation of something.
Anyone with sufficient technical competence carefully
studying what I have said that is not so biased against
my position that they can actually pay complete attention
will understand that I am correct.
If this was not the case then there could be a correct
rebuttal to what I am saying now. Instead of any correct
rebuttal all that has been provided is persistently
false assumptions.
A termination analyzer / partial halt decider is
required to report on the behavior of the sequence
of state transitions that its input actually specifies.
It is not allowed to report on anything else.
On 6/15/2025 4:46 AM, Mikko wrote:
On 2025-06-14 13:44:30 +0000, olcott said:
On 6/14/2025 6:26 AM, Mikko wrote:
On 2025-06-13 17:59:23 +0000, André G. Isaak said:
On 2025-06-13 09:36, olcott wrote:Some of its contents might still be on some web page.
On 6/13/2025 6:53 AM, Mikko wrote:
Nothing is permanent. But you can (and to some extent do) maintan a web >>>>>>> page as long as you need it for usenet discussions.
I want people to be able to validate my work 50 years after I am dead. >>>>>> A web-page will not work for this.
Usenet is dying. Do you seriously think it will be around in 50 years? >>>>
Storing every text message ever written seems
to take < 1.0 TB.
Doesn't matter. Unlikely that anyone would even notice that you wanted
a validation of something.
Anyone with sufficient technical competence carefully
studying what I have said that is not so biased against
my position that they can actually pay complete attention
will understand that I am correct.
🧠 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 35:14:15 |
| Calls: | 10,392 |
| Calls today: | 3 |
| Files: | 14,064 |
| Messages: | 6,417,141 |