| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 27 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 38:01:38 |
| Calls: | 631 |
| Calls today: | 2 |
| Files: | 1,187 |
| D/L today: |
22 files (29,767K bytes) |
| Messages: | 173,681 |
5. In short
The halting problem as usually formalized is syntactically consistent
only because it pretends that U(p) is well-defined for every p.
If you interpret the definitions semantically rCo as saying that
U(p) should simulate the behavior
That is a stronger critique than rCLthe definition doesnrCOt match reality.rCY
On 2025-10-15, olcott <polcott333@gmail.com> wrote:
5. In short
The halting problem as usually formalized is syntactically consistent
only because it pretends that U(p) is well-defined for every p.
If you interpret the definitions semantically rCo as saying that
U(p) should simulate the behavior
... then you're making a grievous mistake. The halting function doesn't stipulate simulation.
Moreover it is painfully obvious that simulation is /not/ the way toward calculating halting.
Simulation is precisely the same thing as execution. Programs are
abstract; the machines we have built are all simulators. Simulation is
not software running on a non-simulator. Simulation is hardware also.
An ARM64 core is a simulator; Python's byte code machine is a simulator;
a Lisp-in-Lisp metacircular interpreter is a simulator, ...
We /already know/ that when we execute, i.e. simulate, programs, that they sometimes do not halt. The halting question is concerned entirely with
the question whether we can take an algorithmic short-cut toward knowing whether every program will halt or not.
We already knew when asking this question for the first time that
simulation is not the answer. Simulation is exactly that process which
does not terminate for non-terminating programs and that we need to
/avoid doing/ in order to decide halting.
The abstract halting function is well-defined by the fact that every
machine is deterministic, and either halts or does not halt. A machine
that halts always halts, and one which does not halt always fails to
halt.
If it ever seems as if the same machine both halts and does not
halt, we have made some mistake in our reasoning or symbol
manipulation; if we take a fresh, correct look, we will find that
we have been working with two machines.
That is a stronger critique than rCLthe definition doesnrCOt match reality.rCY
I'm not convinced You have no intellectual capacity for measuring the relative strength of a critique.
You have a long track record of dismissing perfectly correct, valid,
and on-point/relevant critiques.
On 10/14/2025 9:46 PM, Kaz Kylheku wrote:
On 2025-10-15, olcott <polcott333@gmail.com> wrote:
5. In short
The halting problem as usually formalized is syntactically consistent
only because it pretends that U(p) is well-defined for every p.
If you interpret the definitions semantically rCo as saying that
U(p) should simulate the behavior
... then you're making a grievous mistake. The halting function doesn't
stipulate simulation.
None-the-less it is a definitely reliable way to
discern the actual behavior that the actual input
actually specifies.
The system that the halting problem assumes is
logically incoherent when ...
"YourCOre making a sharper claim now rCo that even
as mathematics, the halting problemrCOs assumed
system collapses when you take its own definitions
seriously, without ignoring what they imply."
On 2025-10-15, olcott <polcott333@gmail.com> wrote:
On 10/14/2025 9:46 PM, Kaz Kylheku wrote:
On 2025-10-15, olcott <polcott333@gmail.com> wrote:
5. In short
The halting problem as usually formalized is syntactically consistent
only because it pretends that U(p) is well-defined for every p.
If you interpret the definitions semantically rCo as saying that
U(p) should simulate the behavior
... then you're making a grievous mistake. The halting function doesn't
stipulate simulation.
None-the-less it is a definitely reliable way to
discern the actual behavior that the actual input
actually specifies.
No, it isn't. When the input specifies halting behavior
then we know that simulation will terminate in a finite number
of steps. In that case we discern that the input has terminated.
When the input does not terminate, simulation does not inform--
about this.
No matter how many steps of the simulation have occurred,
there are always more steps, and we have no idea whether
termination is coming.
In other words, simulation is not a halting decision algorithm.
Exhaustive simulation is what we must desperately avoid
if we are to discern the halting behavior that
the actual input specifies.
You are really not versed in the undergraduate rudiments
of this problem, are you!
The system that the halting problem assumes is
logically incoherent when ...
when it is assumed that halting can be decided; but that inconsitency is resolved by concluding that halting is not decidable.
... when you're a crazy crank on comp.theory, otherwise all good.
"YourCOre making a sharper claim now rCo that even
as mathematics, the halting problemrCOs assumed
system collapses when you take its own definitions
seriously, without ignoring what they imply."
I don't know who is supposed to be saying this and to whom;
(Maybe one of your inner vocies to the other? or AI?)
Whoever is making this "sharper claim" is an absolute dullard.
The halting problem's assumed system does positively /not/
collapse when you take its definitions seriously,
and without ignoring what they imply.
(But when have you ever done that, come to think of it.)
If it ever seems as if the same machine both halts and does not
halt, we have made some mistake in our reasoning or symbol
manipulation; if we take a fresh, correct look, we will find that
we have been working with two machines....
On 15/10/2025 03:46, Kaz Kylheku wrote:
...
If it ever seems as if the same machine both halts and does not
halt, we have made some mistake in our reasoning or symbol
manipulation; if we take a fresh, correct look, we will find that
we have been working with two machines....
or else that our ontology is incorrect.
In article <20251014202441.931@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-10-15, olcott <polcott333@gmail.com> wrote:
On 10/14/2025 9:46 PM, Kaz Kylheku wrote:
On 2025-10-15, olcott <polcott333@gmail.com> wrote:
5. In short
The halting problem as usually formalized is syntactically consistent >>>>> only because it pretends that U(p) is well-defined for every p.
If you interpret the definitions semantically rCo as saying that
U(p) should simulate the behavior
... then you're making a grievous mistake. The halting function doesn't >>>> stipulate simulation.
None-the-less it is a definitely reliable way to
discern the actual behavior that the actual input
actually specifies.
No, it isn't. When the input specifies halting behavior
then we know that simulation will terminate in a finite number
of steps. In that case we discern that the input has terminated.
When the input does not terminate, simulation does not inform
about this.
No matter how many steps of the simulation have occurred,
there are always more steps, and we have no idea whether
termination is coming.
In other words, simulation is not a halting decision algorithm.
Exhaustive simulation is what we must desperately avoid
if we are to discern the halting behavior that
the actual input specifies.
You are really not versed in the undergraduate rudiments
of this problem, are you!
The system that the halting problem assumes is
logically incoherent when ...
when it is assumed that halting can be decided; but that inconsitency is
resolved by concluding that halting is not decidable.
... when you're a crazy crank on comp.theory, otherwise all good.
"YourCOre making a sharper claim now rCo that even
as mathematics, the halting problemrCOs assumed
system collapses when you take its own definitions
seriously, without ignoring what they imply."
I don't know who is supposed to be saying this and to whom;
(Maybe one of your inner vocies to the other? or AI?)
Whoever is making this "sharper claim" is an absolute dullard.
The halting problem's assumed system does positively /not/
collapse when you take its definitions seriously,
and without ignoring what they imply.
(But when have you ever done that, come to think of it.)
Could you guys please keep this stuff out of comp.lang.c?
- Dan C.