| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 27 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 35:49:10 |
| Calls: | 631 |
| Calls today: | 2 |
| Files: | 1,187 |
| D/L today: |
22 files (29,767K bytes) |
| Messages: | 172,999 |
On 10/7/2025 3:49 AM, Mikko wrote:
On 2025-10-07 00:18:52 +0000, olcott said:
On 10/6/2025 4:11 AM, Mikko wrote:
On 2025-10-05 13:51:53 +0000, olcott said:
On 10/5/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-10-05, olcott <polcott333@gmail.com> wrote:
It is unreasonable to construe any logical
impossibility as an actual limitation.
That could practically be your motto.
A birthday case is limited in that it cannot land an
airliner. An actual hamburger patty is also limited
in that it cannot get elected to the US senate.
Both birthday cakes and hamburger patties are much more limited
that that. In paticular, we want that they are edible.
Yes and Turing machines do not have psychic
ability to report on behaviors that they cannot
see. The best that they can do is an execution
trace of the behavior that the input specifies
that sometimes includes the input calling its
own decider in recursive simulation.
Turns out that the best they can do is enouth to construct
a universal Turing machine but not enough to construct a
halt decider.
If you want to find out how much Bill weighs
you will not get this by weigh his little sister.
You will only get this by weighing Bill.
If you want to find out if an input finite string
specifies the semantic property of halting you must
test this actual input finite string.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its
simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least.
He's simply not interested.
He just wants to be assured that his baloney has convinced everybody,
and he'll keep on spewing it until he gets that assurance.
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its
simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not interested.
He just wants to be assured that his baloney has convinced everybody,
and he'll keep on spewing it until he gets that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
Skipping steps is nothing but stupid.
On 2025-10-07 14:32:35 +0000, olcott said:
On 10/7/2025 3:49 AM, Mikko wrote:
On 2025-10-07 00:18:52 +0000, olcott said:
On 10/6/2025 4:11 AM, Mikko wrote:
On 2025-10-05 13:51:53 +0000, olcott said:
On 10/5/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-10-05, olcott <polcott333@gmail.com> wrote:
It is unreasonable to construe any logical
impossibility as an actual limitation.
That could practically be your motto.
A birthday case is limited in that it cannot land an
airliner. An actual hamburger patty is also limited
in that it cannot get elected to the US senate.
Both birthday cakes and hamburger patties are much more limited
that that. In paticular, we want that they are edible.
Yes and Turing machines do not have psychic
ability to report on behaviors that they cannot
see. The best that they can do is an execution
trace of the behavior that the input specifies
that sometimes includes the input calling its
own decider in recursive simulation.
Turns out that the best they can do is enouth to construct
a universal Turing machine but not enough to construct a
halt decider.
If you want to find out how much Bill weighs
you will not get this by weigh his little sister.
You will only get this by weighing Bill.
Or something that is known to weight the same as Bill,
or something whose weight has a known ratio to Bill's
weight.
If you want to find out if an input finite string
specifies the semantic property of halting you must
test this actual input finite string.
Or something that is known to have some determinable feature if
and only if the string asked about has the semantic property of
halting.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Above, unlike the original, does not define or require or claim
anuthing. Besides, the original does not say "unless aborted".
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its
simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has
convinced everybody, and he'll keep on spewing it until he gets that
assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern
that HHH recognizes as non-halting.
Skipping steps is nothing but stupid.
Its clever if done correctly.
On 10/8/2025 5:02 AM, Mikko wrote:Doesn't exist because the fixed immutable code known as HHH aborts and therefore doesn't correctly simulate the fixed immutable code known as DD.
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its
simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has
convinced everybody, and he'll keep on spewing it until he gets that
assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern
that HHH recognizes as non-halting.
DD correctly simulated by HHH
On 10/9/2025 12:02 AM, olcott wrote:
On 10/8/2025 5:02 AM, Mikko wrote:Doesn't exist because the fixed immutable code known as HHH aborts and therefore doesn't correctly simulate the fixed immutable code known as DD.
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its >>>>>>> simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has
convinced everybody, and he'll keep on spewing it until he gets
that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern
that HHH recognizes as non-halting.
DD correctly simulated by HHH
On 10/8/2025 4:52 AM, Mikko wrote:
On 2025-10-07 14:32:35 +0000, olcott said:
On 10/7/2025 3:49 AM, Mikko wrote:
On 2025-10-07 00:18:52 +0000, olcott said:
On 10/6/2025 4:11 AM, Mikko wrote:
On 2025-10-05 13:51:53 +0000, olcott said:
On 10/5/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-10-05, olcott <polcott333@gmail.com> wrote:
It is unreasonable to construe any logical
impossibility as an actual limitation.
That could practically be your motto.
A birthday case is limited in that it cannot land an
airliner. An actual hamburger patty is also limited
in that it cannot get elected to the US senate.
Both birthday cakes and hamburger patties are much more limited
that that. In paticular, we want that they are edible.
Yes and Turing machines do not have psychic
ability to report on behaviors that they cannot
see. The best that they can do is an execution
trace of the behavior that the input specifies
that sometimes includes the input calling its
own decider in recursive simulation.
Turns out that the best they can do is enouth to construct
a universal Turing machine but not enough to construct a
halt decider.
If you want to find out how much Bill weighs
you will not get this by weigh his little sister.
You will only get this by weighing Bill.
Or something that is known to weight the same as Bill,
or something whose weight has a known ratio to Bill's
weight.
If you want to find out if an input finite string
specifies the semantic property of halting you must
test this actual input finite string.
Or something that is known to have some determinable feature if
and only if the string asked about has the semantic property of
halting.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Above, unlike the original, does not define or require or claim
anuthing. Besides, the original does not say "unless aborted".
The above is the Linz proof construed with my
unique idea of a simulating halt decider. I assume
that you know what a simulating halt decider is by now.
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its
simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not interested. >>>> He just wants to be assured that his baloney has convinced everybody, >>>> and he'll keep on spewing it until he gets that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern
that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
On 10/7/2025 4:00 AM, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
On 10/6/2025 4:27 AM, Mikko wrote:
On 2025-10-05 12:40:19 +0000, olcott said:
On 10/4/2025 11:34 AM, Kaz Kylheku wrote:
On 2025-10-04, olcott <polcott333@gmail.com> wrote:
All Turing machine deciders only compute the mapping
from their finite string inputs to an accept state or reject
state on the basis that this input finite string specifies a
semantic or syntactic property.
And that is what is incomputable. It's possible for the finite
string input to specify a diagonal case that is wrongly decided.
When the finite string input specifies a diagonal case
the "do the opposite" code becomes unreachable.
That depends on the decider candidate.
When the decider candidate is a simulating halt decider
then its simulated input cannot possibly ever reach the
do the opposite code.
It can, if the simulator can detect what part of the simulated program
is the simulator itself and skip the simulation of that code.
It seems to be the case that a function
cannot know its own machine address and
still be Turing computable otherwise HHH
would know that DD is specifying recursive
emulation as soon as DD calls HHH(DD).
The code
of the simulator itself is already known so there is no need to simulate
it.
The non-halting behavior of DD() is based on
recursive simulation this needs to be verified.
On 10/8/2025 11:05 PM, dbush wrote:
On 10/9/2025 12:02 AM, olcott wrote:
On 10/8/2025 5:02 AM, Mikko wrote:Doesn't exist because the fixed immutable code known as HHH aborts and
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its >>>>>>>> simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has
convinced everybody, and he'll keep on spewing it until he gets
that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern
that HHH recognizes as non-halting.
DD correctly simulated by HHH
therefore doesn't correctly simulate the fixed immutable code known as
DD.
When you play troll I hardly glance at any of your posts.
On 10/9/2025 12:09 AM, olcott wrote:
On 10/8/2025 11:05 PM, dbush wrote:
On 10/9/2025 12:02 AM, olcott wrote:
On 10/8/2025 5:02 AM, Mikko wrote:Doesn't exist because the fixed immutable code known as HHH aborts
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then >>>>>>>>> its simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has
convinced everybody, and he'll keep on spewing it until he gets >>>>>>> that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern >>>>> that HHH recognizes as non-halting.
DD correctly simulated by HHH
and therefore doesn't correctly simulate the fixed immutable code
known as DD.
When you play troll I hardly glance at any of your posts.
That you don't understand that HHH does not correctly simulate DD
because it aborts is not my mistake.
On 10/9/2025 5:45 AM, dbush wrote:
On 10/9/2025 12:09 AM, olcott wrote:
On 10/8/2025 11:05 PM, dbush wrote:
On 10/9/2025 12:02 AM, olcott wrote:
On 10/8/2025 5:02 AM, Mikko wrote:Doesn't exist because the fixed immutable code known as HHH aborts
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then >>>>>>>>>> its simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is >>>>>>>>> already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has
convinced everybody, and he'll keep on spewing it until he gets >>>>>>>> that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern >>>>>> that HHH recognizes as non-halting.
DD correctly simulated by HHH
and therefore doesn't correctly simulate the fixed immutable code
known as DD.
When you play troll I hardly glance at any of your posts.
That you don't understand that HHH does not correctly simulate DD
because it aborts is not my mistake.
It is not my lack of understanding.
It is verified fact that unless HHH aborts
that HHH never stops running.
On 10/9/2025 5:45 AM, dbush wrote:
On 10/9/2025 12:09 AM, olcott wrote:
On 10/8/2025 11:05 PM, dbush wrote:
On 10/9/2025 12:02 AM, olcott wrote:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
Doesn't exist because the fixed immutable code known as HHH abortsDD correctly simulated by HHHWhen the decider candidate is a simulating halt decider then >>>>>>>>>> its simulated input cannot possibly ever reach the do the
opposite code.
It can, if the simulator can detect what part of the simulated >>>>>>>>> program is the simulator itself and skip the simulation of that >>>>>>>>> code. The code of the simulator itself is already known so there >>>>>>>>> is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has
convinced everybody, and he'll keep on spewing it until he gets >>>>>>>> that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD would never stop
running unless aborted
That hever happens if DD halts or never exhibits a behaviour
pattern that HHH recognizes as non-halting.
and therefore doesn't correctly simulate the fixed immutable code
known as DD.
That you don't understand that HHH does not correctly simulate DD
because it aborts is not my mistake.
It is not my lack of understanding.
It is verified fact that unless HHH aborts that HHH never stops running.
Am Thu, 09 Oct 2025 08:00:32 -0500 schrieb olcott:
On 10/9/2025 5:45 AM, dbush wrote:
On 10/9/2025 12:09 AM, olcott wrote:
On 10/8/2025 11:05 PM, dbush wrote:
On 10/9/2025 12:02 AM, olcott wrote:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
Doesn't exist because the fixed immutable code known as HHH abortsDD correctly simulated by HHHWhen the decider candidate is a simulating halt decider then >>>>>>>>>>> its simulated input cannot possibly ever reach the do the >>>>>>>>>>> opposite code.
It can, if the simulator can detect what part of the simulated >>>>>>>>>> program is the simulator itself and skip the simulation of that >>>>>>>>>> code. The code of the simulator itself is already known so there >>>>>>>>>> is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has >>>>>>>>> convinced everybody, and he'll keep on spewing it until he gets >>>>>>>>> that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD would never stop >>>>>>>> running unless aborted
That hever happens if DD halts or never exhibits a behaviour
pattern that HHH recognizes as non-halting.
and therefore doesn't correctly simulate the fixed immutable code
known as DD.
That you don't understand that HHH does not correctly simulate DD
because it aborts is not my mistake.
It is not my lack of understanding.
It is verified fact that unless HHH aborts that HHH never stops running.
Yes, it is your lack of understanding that along the same lines unless
HHH lets its input halt on its own, DD will always be halting.
We are not talking about the diagonal program to a non-aborting simulator however.
int DD()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a return Halt_Status;
}
int main()
{
-a printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
int main()
{
-a-a printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
Since DD consists of the code of the function DD, the code of the
function HHH, and the code of everything that HHH calls down the
OS level, it halts by itself.
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
int main()
{
-a-a printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
Since DD consists of the code of the function DD, the code of the
function HHH, and the code of everything that HHH calls down the OS
level, it halts by itself.
On 09/10/2025 17:21, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
int main()
{
-a-a printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
Since DD consists of the code of the function DD, the code of the
function HHH, and the code of everything that HHH calls down the OS
level, it halts by itself.
Yes. Note that at no point is DD called in the above program, so its
halting behaviour is never put to the test.
Simulation is not execution.
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
int main()
{
-a-a printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
Since DD consists of the code of the function DD, the code of the
function HHH, and the code of everything that HHH calls down the OS
level, it halts by itself.
In other words you dodged my questions about your
programming credentials because you have none.
Until you provide ALL OF THE REASONING PROVIDING--- Synchronet 3.21a-Linux NewsLink 1.2
ALL OF THE DETAILS OF EXACTLY HOW I AM WRONG
it seems reasonable to conclude that you do not
have any of these details and only have pure bluster.
On 2025-10-09 04:00:35 +0000, olcott said:
On 10/8/2025 4:52 AM, Mikko wrote:
On 2025-10-07 14:32:35 +0000, olcott said:
On 10/7/2025 3:49 AM, Mikko wrote:
On 2025-10-07 00:18:52 +0000, olcott said:
On 10/6/2025 4:11 AM, Mikko wrote:
On 2025-10-05 13:51:53 +0000, olcott said:
On 10/5/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-10-05, olcott <polcott333@gmail.com> wrote:
It is unreasonable to construe any logical
impossibility as an actual limitation.
That could practically be your motto.
A birthday case is limited in that it cannot land an
airliner. An actual hamburger patty is also limited
in that it cannot get elected to the US senate.
Both birthday cakes and hamburger patties are much more limited
that that. In paticular, we want that they are edible.
Yes and Turing machines do not have psychic
ability to report on behaviors that they cannot
see. The best that they can do is an execution
trace of the behavior that the input specifies
that sometimes includes the input calling its
own decider in recursive simulation.
Turns out that the best they can do is enouth to construct
a universal Turing machine but not enough to construct a
halt decider.
If you want to find out how much Bill weighs
you will not get this by weigh his little sister.
You will only get this by weighing Bill.
Or something that is known to weight the same as Bill,
or something whose weight has a known ratio to Bill's
weight.
If you want to find out if an input finite string
specifies the semantic property of halting you must
test this actual input finite string.
Or something that is known to have some determinable feature if
and only if the string asked about has the semantic property of
halting.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Above, unlike the original, does not define or require or claim
anuthing. Besides, the original does not say "unless aborted".
The above is the Linz proof construed with my
unique idea of a simulating halt decider. I assume
that you know what a simulating halt decider is by now.
The above is not a proof. A proof is a sequence of claims. The
above is not.
On 2025-10-09 04:02:32 +0000, olcott said:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its >>>>>>> simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has
convinced everybody, and he'll keep on spewing it until he gets
that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern
that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
If the simulation is never stops then HHH is not a decider.
But in reality the simulation is halted and HHH incorrectly
returns false and DD halts.
On 2025-10-07 14:43:55 +0000, olcott said:
On 10/7/2025 4:00 AM, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
On 10/6/2025 4:27 AM, Mikko wrote:
On 2025-10-05 12:40:19 +0000, olcott said:
On 10/4/2025 11:34 AM, Kaz Kylheku wrote:
On 2025-10-04, olcott <polcott333@gmail.com> wrote:
All Turing machine deciders only compute the mapping
from their finite string inputs to an accept state or reject
state on the basis that this input finite string specifies a
semantic or syntactic property.
And that is what is incomputable. It's possible for the finite
string input to specify a diagonal case that is wrongly decided.
When the finite string input specifies a diagonal case
the "do the opposite" code becomes unreachable.
That depends on the decider candidate.
When the decider candidate is a simulating halt decider
then its simulated input cannot possibly ever reach the
do the opposite code.
It can, if the simulator can detect what part of the simulated program
is the simulator itself and skip the simulation of that code.
It seems to be the case that a function
cannot know its own machine address and
still be Turing computable otherwise HHH
would know that DD is specifying recursive
emulation as soon as DD calls HHH(DD).
The code
of the simulator itself is already known so there is no need to simulate >>> it.
The non-halting behavior of DD() is based on
recursive simulation this needs to be verified.
There is no non-halting behavour of DD(). DD() halts.
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
int main()
{
-a-a printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
Since DD consists of the code of the function DD, the code of the
function HHH, and the code of everything that HHH calls down the OS
level, it halts by itself.
In other words you dodged my questions about your
programming credentials because you have none.
I'll let you respond to yourself:
On 3/9/2025 6:28 PM, olcott wrote:
Until you provide ALL OF THE REASONING PROVIDING
ALL OF THE DETAILS OF EXACTLY HOW I AM WRONG
it seems reasonable to conclude that you do not
have any of these details and only have pure bluster.
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
int main()
{
-a-a printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
Since DD consists of the code of the function DD, the code of the
function HHH, and the code of everything that HHH calls down the OS
level, it halts by itself.
In other words you dodged my questions about your
programming credentials because you have none.
I'll let you respond to yourself:
On 3/9/2025 6:28 PM, olcott wrote:
Until you provide ALL OF THE REASONING PROVIDING
ALL OF THE DETAILS OF EXACTLY HOW I AM WRONG
it seems reasonable to conclude that you do not
have any of these details and only have pure bluster.
In other words you know that you don't have
the technical competence to rebut what I say
about complex algorithms in C.
No DD ever halts by itself. They all require HHH(DD)
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
int main()
{
-a-a printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
Since DD consists of the code of the function DD, the code of the
function HHH, and the code of everything that HHH calls down the OS >>>>> level, it halts by itself.
In other words you dodged my questions about your
programming credentials because you have none.
I'll let you respond to yourself:
On 3/9/2025 6:28 PM, olcott wrote:
Until you provide ALL OF THE REASONING PROVIDING
ALL OF THE DETAILS OF EXACTLY HOW I AM WRONG
it seems reasonable to conclude that you do not
have any of these details and only have pure bluster.
In other words you know that you don't have
the technical competence to rebut what I say
about complex algorithms in C.
No DD ever halts by itself. They all require HHH(DD)
Which is part of DD therefore DD halts by itself.
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
int main()
{
-a-a printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
Since DD consists of the code of the function DD, the code of the >>>>>> function HHH, and the code of everything that HHH calls down the
OS level, it halts by itself.
In other words you dodged my questions about your
programming credentials because you have none.
I'll let you respond to yourself:
On 3/9/2025 6:28 PM, olcott wrote:
Until you provide ALL OF THE REASONING PROVIDING
ALL OF THE DETAILS OF EXACTLY HOW I AM WRONG
it seems reasonable to conclude that you do not
have any of these details and only have pure bluster.
In other words you know that you don't have
the technical competence to rebut what I say
about complex algorithms in C.
No DD ever halts by itself. They all require HHH(DD)
Which is part of DD therefore DD halts by itself.
No DD ever halts unless HHH(DD) aborts its simulation.
On 10/9/2025 1:43 PM, olcott wrote:
No DD ever halts by itself. They all require HHH(DD)
Which is part of DD therefore DD halts by itself.
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
How is this DD going to halt on its own?
Which it does, therefore DD halts.No DD ever halts unless HHH(DD) aborts its simulation.No DD ever halts by itself. They all require HHH(DD)Which is part of DD therefore DD halts by itself.
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
How is this DD going to halt on its own?
Try running it on a UTM.
No DD ever halts unless HHH(DD) aborts its simulation.No DD ever halts by itself. They all require HHH(DD)Which is part of DD therefore DD halts by itself.
Which it does, therefore DD halts.
On 10/9/2025 2:29 PM, joes wrote:
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a-a int Halt_Status = HHH(DD);
-a-a-a if (Halt_Status)
-a-a-a-a-a HERE: goto HERE;
-a-a-a return Halt_Status;
}
How is this DD going to halt on its own?
Try running it on a UTM.
That would not be the behavior that HHH(DD) sees.
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the behaviour of UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself will never
stop running.
[this criterion, these criteria]We must see what would happen if it did not abort as our basis to see ifWhich it does, therefore DD halts.No DD ever halts unless HHH(DD) aborts its simulation.No DD ever halts by itself. They all require HHH(DD)Which is part of DD therefore DD halts by itself.
this criteria is met:
On 10/9/2025 4:04 PM, olcott wrote:
On 10/9/2025 2:29 PM, joes wrote:
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
int DD()
{
-a-a-a int Halt_Status = HHH(DD);
-a-a-a if (Halt_Status)
-a-a-a-a-a HERE: goto HERE;
-a-a-a return Halt_Status;
}
How is this DD going to halt on its own?
Try running it on a UTM.
That would not be the behavior that HHH(DD) sees.
Thus demonstrating how HHH gets the wrong answer other that the one a
halt decider is required to give:
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:
On 10/9/2025 2:29 PM, joes wrote:
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself will never
stop running.
I mean. ThatrCOs why HHH is wrong. It does not look at the behaviour of UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls
UTM(DDu). But as per your own statements, it absolutely should! HHH overeagerly closes its eyes to the abort contained within DD.
We must see what would happen if it did not abort as our basis to see ifWhich it does, therefore DD halts.No DD ever halts unless HHH(DD) aborts its simulation.No DD ever halts by itself. They all require HHH(DD)Which is part of DD therefore DD halts by itself.
this criteria is met:
[this criterion, these criteria]
We must not see what would happen if the input were different.
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:I am estimating that you have very little actual programming experience
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the behaviour of
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself will
never stop running.
UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls
UTM(DDu). But as per your own statements, it absolutely should! HHH
overeagerly closes its eyes to the abort contained within DD.
or you would know that a function cannot possibly know anything about
its caller.
IrCOm gonna bow out here if you think deciders should not report on their inputs.Yes we must. It is required.We must not see what would happen if the input were different.We must see what would happen if it did not abort as our basis to seeNo DD ever halts unless HHH(DD) aborts its simulation.Which it does, therefore DD halts.
if this criteria is met:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:I am estimating that you have very little actual programming experience
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the behaviour of
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself will
never stop running.
UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls
UTM(DDu). But as per your own statements, it absolutely should! HHH
overeagerly closes its eyes to the abort contained within DD.
or you would know that a function cannot possibly know anything about
its caller.
Yes we must. It is required.We must not see what would happen if the input were different.We must see what would happen if it did not abort as our basis to seeNo DD ever halts unless HHH(DD) aborts its simulation.Which it does, therefore DD halts.
if this criteria is met:
IrCOm gonna bow out here if you think deciders should not report on their inputs.
On 10/9/2025 4:11 PM, joes wrote:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:I am estimating that you have very little actual programming experience
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the behaviour of >>>> UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself will
never stop running.
UTM(DDu). But as per your own statements, it absolutely should! HHH
overeagerly closes its eyes to the abort contained within DD.
or you would know that a function cannot possibly know anything about
its caller.
Yes we must. It is required.We must not see what would happen if the input were different.We must see what would happen if it did not abort as our basis to see >>>>> if this criteria is met:No DD ever halts unless HHH(DD) aborts its simulation.Which it does, therefore DD halts.
IrCOm gonna bow out here if you think deciders should not report on their
inputs.
*I have to read and reread to get the words right*
I read that backwards the first time.
Deciders must only report on their inputs
thus
must not ever report on the behavior of their caller.
The fact that the main-->DD() caller of HHH(DD)
halts is none of the damn business of HHH.
HHH is only concerned with whether it must
abort the simulation of its input to prevent
its own non-termination AND YES IT MUST !!!
The way that it does this is it determines
what the behavior would be if itself was a UTM.
On 10/9/2025 5:38 PM, olcott wrote:
On 10/9/2025 4:11 PM, joes wrote:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:I am estimating that you have very little actual programming experience >>>> or you would know that a function cannot possibly know anything about
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the behaviour of >>>>> UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself will >>>>>> never stop running.
UTM(DDu). But as per your own statements, it absolutely should! HHH
overeagerly closes its eyes to the abort contained within DD.
its caller.
Yes we must. It is required.We must not see what would happen if the input were different.We must see what would happen if it did not abort as our basis to see >>>>>> if this criteria is met:No DD ever halts unless HHH(DD) aborts its simulation.Which it does, therefore DD halts.
IrCOm gonna bow out here if you think deciders should not report on their >>> inputs.
*I have to read and reread to get the words right*
I read that backwards the first time.
Deciders must only report on their inputs
i.e. the Turing machine that the input finite string is a representation
thus
must not ever report on the behavior of their caller.
False, it must report on *all* machines.
The fact that the main-->DD() caller of HHH(DD)
halts is none of the damn business of HHH.
It is if it wants to meet its requirements:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
HHH is only concerned with whether it must
abort the simulation of its input to prevent
its own non-termination AND YES IT MUST !!!
The way that it does this is it determines
what the behavior would be if itself was a UTM.
In other words, it decides on a non-input.
On 10/9/2025 4:41 PM, dbush wrote:
On 10/9/2025 5:38 PM, olcott wrote:
On 10/9/2025 4:11 PM, joes wrote:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:I am estimating that you have very little actual programming
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the behaviour of >>>>>> UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls >>>>>> UTM(DDu). But as per your own statements, it absolutely should! HHH >>>>>> overeagerly closes its eyes to the abort contained within DD.
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself will >>>>>>> never stop running.
experience
or you would know that a function cannot possibly know anything about >>>>> its caller.
Yes we must. It is required.We must not see what would happen if the input were different.We must see what would happen if it did not abort as our basis to >>>>>>> seeNo DD ever halts unless HHH(DD) aborts its simulation.Which it does, therefore DD halts.
if this criteria is met:
IrCOm gonna bow out here if you think deciders should not report on their >>>> inputs.
*I have to read and reread to get the words right*
I read that backwards the first time.
Deciders must only report on their inputs
i.e. the Turing machine that the input finite string is a representation
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
thus
must not ever report on the behavior of their caller.
False, it must report on *all* machines.
How about the machine that I don't even know
how I will encode ten years from now?
The fact that the main-->DD() caller of HHH(DD)
halts is none of the damn business of HHH.
It is if it wants to meet its requirements:
It is these requirements that are incorrect.
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
HHH is only concerned with whether it must
abort the simulation of its input to prevent
its own non-termination AND YES IT MUST !!!
The way that it does this is it determines
what the behavior would be if itself was a UTM.
In other words, it decides on a non-input.
It decides two hypothetical scenarios on the same
input.
It is always the case that if D simulated
by H would never stop running if not aborted
then
it must be aborted because all halt deciders must
always halt.
all halt deciders
must always halt.
On 10/9/2025 4:41 PM, dbush wrote:
i.e. the Turing machine that the input finite string is a representation
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 4:41 PM, dbush wrote:
i.e. the Turing machine that the input finite string is a representation >>>
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
And, so, you are saying that cannot be the case, because it is your own wisdom which is coming from the mind of God?
Or are you saying that if you somehow knew of a wisdom that came
straight from the mind of God, you would accept it without proof or any
kind of thinking?
What exactly is your intellectual yardstick for being right?
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 4:41 PM, dbush wrote:
i.e. the Turing machine that the input finite string is a representation >>>
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
And, so, you are saying that cannot be the case, because it is your own wisdom which is coming from the mind of God?
Or are you saying that if you somehow knew of a wisdom that came
straight from the mind of God, you would accept it without proof or any
kind of thinking?
What exactly is your intellectual yardstick for being right?
On 10/9/2025 7:58 PM, olcott wrote:
On 10/9/2025 4:41 PM, dbush wrote:
On 10/9/2025 5:38 PM, olcott wrote:
On 10/9/2025 4:11 PM, joes wrote:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:I am estimating that you have very little actual programming
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself will >>>>>>>> never stop running.
behaviour of
UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls >>>>>>> UTM(DDu). But as per your own statements, it absolutely should! HHH >>>>>>> overeagerly closes its eyes to the abort contained within DD.
experience
or you would know that a function cannot possibly know anything about >>>>>> its caller.
Yes we must. It is required.We must not see what would happen if the input were different.We must see what would happen if it did not abort as our basis >>>>>>>> to seeNo DD ever halts unless HHH(DD) aborts its simulation.Which it does, therefore DD halts.
if this criteria is met:
IrCOm gonna bow out here if you think deciders should not report on >>>>> their
inputs.
*I have to read and reread to get the words right*
I read that backwards the first time.
Deciders must only report on their inputs
i.e. the Turing machine that the input finite string is a representation >>>
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
Not conventional wisdom, just definitions.
thus
must not ever report on the behavior of their caller.
False, it must report on *all* machines.
How about the machine that I don't even know
how I will encode ten years from now?
YES!-a *All* possible machines!
The fact that the main-->DD() caller of HHH(DD)
halts is none of the damn business of HHH.
It is if it wants to meet its requirements:
It is these requirements that are incorrect.
Which is exactly what Turing and Linz proved.
If it was then both professor Sipser and Ben
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
HHH is only concerned with whether it must
abort the simulation of its input to prevent
its own non-termination AND YES IT MUST !!!
The way that it does this is it determines
what the behavior would be if itself was a UTM.
In other words, it decides on a non-input.
It decides two hypothetical scenarios on the same
input.
Category error.
On 10/9/2025 7:06 PM, dbush wrote:
On 10/9/2025 7:58 PM, olcott wrote:
On 10/9/2025 4:41 PM, dbush wrote:
On 10/9/2025 5:38 PM, olcott wrote:
On 10/9/2025 4:11 PM, joes wrote:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:I am estimating that you have very little actual programming
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself will >>>>>>>>> never stop running.
behaviour of
UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls >>>>>>>> UTM(DDu). But as per your own statements, it absolutely should! HHH >>>>>>>> overeagerly closes its eyes to the abort contained within DD.
experience
or you would know that a function cannot possibly know anything >>>>>>> about
its caller.
Yes we must. It is required.We must not see what would happen if the input were different.We must see what would happen if it did not abort as our basis >>>>>>>>> to seeNo DD ever halts unless HHH(DD) aborts its simulation.Which it does, therefore DD halts.
if this criteria is met:
IrCOm gonna bow out here if you think deciders should not report on >>>>>> their
inputs.
*I have to read and reread to get the words right*
I read that backwards the first time.
Deciders must only report on their inputs
i.e. the Turing machine that the input finite string is a
representation
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
Not conventional wisdom, just definitions.
Not at all. I have told you my definitions
hundreds of times and you never understood
a word of it.
thus
must not ever report on the behavior of their caller.
False, it must report on *all* machines.
How about the machine that I don't even know
how I will encode ten years from now?
YES!-a *All* possible machines!
So then tell me does this machine that
does not exist halt or fail to halt?
The fact that the main-->DD() caller of HHH(DD)
halts is none of the damn business of HHH.
It is if it wants to meet its requirements:
It is these requirements that are incorrect.
Which is exactly what Turing and Linz proved.
Having a Turing machine report on something that it
cannot see is as logically impossible as a Turing
machine that computes the square root of a dead chicken.
All logical imposibilities are equally logically impossible
If it was then both professor Sipser and Ben
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
HHH is only concerned with whether it must
abort the simulation of its input to prevent
its own non-termination AND YES IT MUST !!!
The way that it does this is it determines
what the behavior would be if itself was a UTM.
In other words, it decides on a non-input.
It decides two hypothetical scenarios on the same
input.
Category error.
would have not agreed.
professor Sipser did not understand the
significance of these words
I exchanged emails with him about this. He does not agree with anything substantive that PO has written. I won't quote him, as I don't have permission, but he was, let's say... forthright, in his reply to me.
So that PO will have no cause to quote me as supporting his case: what Sipser understood he was agreeing to was NOT what PO interprets it as meaning. Sipser would not agree that the conclusion applies in PO's HHH(DDD) scenario, where DDD halts.
joes <noreply@example.org> writes:
Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:
Professor Sipser clearly agreed that an H that does a finite simulation
of D is to predict the behavior of an unlimited simulation of D.
If the simulator *itself* would not abort. The H called by D is,
by construction, the same and *does* abort.
We don't really know what context Sipser was given. I got in touch at
the time so do I know he had enough context to know that PO's ideas were "wacky" and that had agreed to what he considered a "minor remark".
Since PO considers his words finely crafted and key to his so-called
work I think it's clear that Sipser did not take the "minor remark" he agreed to to mean what PO takes it to mean! My own take if that he
(Sipser) read it as a general remark about how to determine some cases,
i.e. that D names an input that H can partially simulate to determine
it's halting or otherwise. We all know or could construct some such
cases.
I suspect he was tricked because PO used H and D as the names without
making it clear that D was constructed from H in the usual way (Sipser
uses H and D in at least one of his proofs). Of course, he is clued in enough know that, if D is indeed constructed from H like that, the
"minor remark" becomes true by being a hypothetical: if the moon is made
of cheese, the Martians can look forward to a fine fondue. But,
personally, I think the professor is more straight talking than that,
and he simply took as a method that can work for some inputs. That's
the only way is could be seen as a "minor remark" with being accused of being disingenuous.
On 10/9/2025 9:37 PM, olcott wrote:
On 10/9/2025 7:06 PM, dbush wrote:
On 10/9/2025 7:58 PM, olcott wrote:
On 10/9/2025 4:41 PM, dbush wrote:
On 10/9/2025 5:38 PM, olcott wrote:
On 10/9/2025 4:11 PM, joes wrote:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:experience
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself >>>>>>>>>> will
never stop running.
behaviour of
UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu calls >>>>>>>>> UTM(DDu). But as per your own statements, it absolutely should! >>>>>>>>> HHH
overeagerly closes its eyes to the abort contained within DD. >>>>>>>> I am estimating that you have very little actual programming
or you would know that a function cannot possibly know anything >>>>>>>> about
its caller.
We must not see what would happen if the input were different. >>>>>>>> Yes we must. It is required.We must see what would happen if it did not abort as our basis >>>>>>>>>> to seeNo DD ever halts unless HHH(DD) aborts its simulation.Which it does, therefore DD halts.
if this criteria is met:
IrCOm gonna bow out here if you think deciders should not report on >>>>>>> their
inputs.
*I have to read and reread to get the words right*
I read that backwards the first time.
Deciders must only report on their inputs
i.e. the Turing machine that the input finite string is a
representation
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
Not conventional wisdom, just definitions.
Not at all. I have told you my definitions
hundreds of times and you never understood
a word of it.
And since your definition is not the definition of a halt decider, it is irrelevant.
thus
must not ever report on the behavior of their caller.
False, it must report on *all* machines.
How about the machine that I don't even know
how I will encode ten years from now?
YES!-a *All* possible machines!
So then tell me does this machine that
does not exist halt or fail to halt?
Once it is defined,
it can be decided on, and a total halt decider is
required to decide it.
The fact that the main-->DD() caller of HHH(DD)
halts is none of the damn business of HHH.
It is if it wants to meet its requirements:
It is these requirements that are incorrect.
Which is exactly what Turing and Linz proved.
Having a Turing machine report on something that it
cannot see is as logically impossible as a Turing
machine that computes the square root of a dead chicken.
All logical imposibilities are equally logically impossible
Then you agree that Turing and Linz are correct.
If it was then both professor Sipser and Ben
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
HHH is only concerned with whether it must
abort the simulation of its input to prevent
its own non-termination AND YES IT MUST !!!
The way that it does this is it determines
what the behavior would be if itself was a UTM.
In other words, it decides on a non-input.
It decides two hypothetical scenarios on the same
input.
Category error.
would have not agreed.
Try again:
On 10/4/2025 5:00 PM, olcott wrote:
professor Sipser did not understand the
significance of these words
On 10/9/2025 8:42 PM, dbush wrote:
On 10/9/2025 9:37 PM, olcott wrote:
On 10/9/2025 7:06 PM, dbush wrote:
On 10/9/2025 7:58 PM, olcott wrote:
On 10/9/2025 4:41 PM, dbush wrote:
On 10/9/2025 5:38 PM, olcott wrote:
On 10/9/2025 4:11 PM, joes wrote:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:or you would know that a function cannot possibly know anything >>>>>>>>> about
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the >>>>>>>>>> behaviour of
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that itself >>>>>>>>>>> will
never stop running.
UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu >>>>>>>>>> calls
UTM(DDu). But as per your own statements, it absolutely
should! HHH
overeagerly closes its eyes to the abort contained within DD. >>>>>>>>> I am estimating that you have very little actual programming >>>>>>>>> experience
its caller.
We must not see what would happen if the input were different. >>>>>>>>> Yes we must. It is required.We must see what would happen if it did not abort as our >>>>>>>>>>> basis to seeNo DD ever halts unless HHH(DD) aborts its simulation. >>>>>>>>>>>> Which it does, therefore DD halts.
if this criteria is met:
IrCOm gonna bow out here if you think deciders should not report >>>>>>>> on their
inputs.
*I have to read and reread to get the words right*
I read that backwards the first time.
Deciders must only report on their inputs
i.e. the Turing machine that the input finite string is a
representation
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
Not conventional wisdom, just definitions.
Not at all. I have told you my definitions
hundreds of times and you never understood
a word of it.
And since your definition is not the definition of a halt decider, it
is irrelevant.
Sure just like on stack exchange all new ideas
are bad ideas.
thus
must not ever report on the behavior of their caller.
False, it must report on *all* machines.
How about the machine that I don't even know
how I will encode ten years from now?
YES!-a *All* possible machines!
So then tell me does this machine that
does not exist halt or fail to halt?
Once it is defined,
No that is the point. You said ALL machines and
this includes ones that do not currently exist.
it can be decided on, and a total halt decider is required to decide it.
The fact that the main-->DD() caller of HHH(DD)
halts is none of the damn business of HHH.
It is if it wants to meet its requirements:
It is these requirements that are incorrect.
Which is exactly what Turing and Linz proved.
Having a Turing machine report on something that it
cannot see is as logically impossible as a Turing
machine that computes the square root of a dead chicken.
All logical imposibilities are equally logically impossible
Then you agree that Turing and Linz are correct.
Linz was brilliant he was not trying to establish
new ground. He only sought to present the conventional
position succinctly. It seems to me that he did far
better than anyone else on this.
You can't make a halt decider
On 10/9/2025 10:55 PM, olcott wrote:
On 10/9/2025 8:42 PM, dbush wrote:
On 10/9/2025 9:37 PM, olcott wrote:
On 10/9/2025 7:06 PM, dbush wrote:
On 10/9/2025 7:58 PM, olcott wrote:
On 10/9/2025 4:41 PM, dbush wrote:
On 10/9/2025 5:38 PM, olcott wrote:
On 10/9/2025 4:11 PM, joes wrote:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:or you would know that a function cannot possibly know
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the >>>>>>>>>>> behaviour of
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott:
On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that >>>>>>>>>>>> itself will
never stop running.
UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu >>>>>>>>>>> calls
UTM(DDu). But as per your own statements, it absolutely >>>>>>>>>>> should! HHH
overeagerly closes its eyes to the abort contained within DD. >>>>>>>>>> I am estimating that you have very little actual programming >>>>>>>>>> experience
anything about
its caller.
We must not see what would happen if the input were different. >>>>>>>>>> Yes we must. It is required.We must see what would happen if it did not abort as our >>>>>>>>>>>> basis to seeNo DD ever halts unless HHH(DD) aborts its simulation. >>>>>>>>>>>>> Which it does, therefore DD halts.
if this criteria is met:
IrCOm gonna bow out here if you think deciders should not report >>>>>>>>> on their
inputs.
*I have to read and reread to get the words right*
I read that backwards the first time.
Deciders must only report on their inputs
i.e. the Turing machine that the input finite string is a
representation
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
Not conventional wisdom, just definitions.
Not at all. I have told you my definitions
hundreds of times and you never understood
a word of it.
And since your definition is not the definition of a halt decider, it
is irrelevant.
Sure just like on stack exchange all new ideas
are bad ideas.
Your irrelevant analogy construes your admission that the above is correct.
thus
must not ever report on the behavior of their caller.
False, it must report on *all* machines.
How about the machine that I don't even know
how I will encode ten years from now?
YES!-a *All* possible machines!
So then tell me does this machine that
does not exist halt or fail to halt?
Once it is defined,
No that is the point. You said ALL machines and
this includes ones that do not currently exist.
But it can exist and at some point will exist, at which point it can be decided on.
it can be decided on, and a total halt decider is required to decide it. >>>
The fact that the main-->DD() caller of HHH(DD)
halts is none of the damn business of HHH.
It is if it wants to meet its requirements:
It is these requirements that are incorrect.
Which is exactly what Turing and Linz proved.
Having a Turing machine report on something that it
cannot see is as logically impossible as a Turing
machine that computes the square root of a dead chicken.
All logical imposibilities are equally logically impossible
Then you agree that Turing and Linz are correct.
Linz was brilliant he was not trying to establish
new ground. He only sought to present the conventional
position succinctly. It seems to me that he did far
better than anyone else on this.
You can't make a halt decider
Which is exactly what Turing and Linz proved.
On 10/9/2025 4:57 AM, Mikko wrote:
On 2025-10-09 04:00:35 +0000, olcott said:
On 10/8/2025 4:52 AM, Mikko wrote:
On 2025-10-07 14:32:35 +0000, olcott said:
On 10/7/2025 3:49 AM, Mikko wrote:
On 2025-10-07 00:18:52 +0000, olcott said:
On 10/6/2025 4:11 AM, Mikko wrote:
On 2025-10-05 13:51:53 +0000, olcott said:
On 10/5/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-10-05, olcott <polcott333@gmail.com> wrote:
It is unreasonable to construe any logical
impossibility as an actual limitation.
That could practically be your motto.
A birthday case is limited in that it cannot land an
airliner. An actual hamburger patty is also limited
in that it cannot get elected to the US senate.
Both birthday cakes and hamburger patties are much more limited >>>>>>>> that that. In paticular, we want that they are edible.
Yes and Turing machines do not have psychic
ability to report on behaviors that they cannot
see. The best that they can do is an execution
trace of the behavior that the input specifies
that sometimes includes the input calling its
own decider in recursive simulation.
Turns out that the best they can do is enouth to construct
a universal Turing machine but not enough to construct a
halt decider.
If you want to find out how much Bill weighs
you will not get this by weigh his little sister.
You will only get this by weighing Bill.
Or something that is known to weight the same as Bill,
or something whose weight has a known ratio to Bill's
weight.
If you want to find out if an input finite string
specifies the semantic property of halting you must
test this actual input finite string.
Or something that is known to have some determinable feature if
and only if the string asked about has the semantic property of
halting.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Above, unlike the original, does not define or require or claim
anuthing. Besides, the original does not say "unless aborted".
The above is the Linz proof construed with my
unique idea of a simulating halt decider. I assume
that you know what a simulating halt decider is by now.
The above is not a proof. A proof is a sequence of claims. The
above is not.
The first step of my proof is getting you
to totally understand the above.
On 10/9/2025 5:04 AM, Mikko wrote:
On 2025-10-09 04:02:32 +0000, olcott said:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its >>>>>>>> simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not interested. >>>>>> He just wants to be assured that his baloney has convinced everybody, >>>>>> and he'll keep on spewing it until he gets that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern
that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
If the simulation is never stops then HHH is not a decider.
Yes, but until you understood this part we could
not move on to the next part.
But in reality the simulation is halted and HHH incorrectly
returns false and DD halts.
There is no DD() that halts here.
HHH(DD) does correctly determine the halt status--
of the behavior that its actual input actually
specifies.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
On 10/9/2025 5:08 AM, Mikko wrote:
On 2025-10-07 14:43:55 +0000, olcott said:
On 10/7/2025 4:00 AM, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
On 10/6/2025 4:27 AM, Mikko wrote:
On 2025-10-05 12:40:19 +0000, olcott said:
On 10/4/2025 11:34 AM, Kaz Kylheku wrote:
On 2025-10-04, olcott <polcott333@gmail.com> wrote:When the finite string input specifies a diagonal case
All Turing machine deciders only compute the mapping
from their finite string inputs to an accept state or reject >>>>>>>>> state on the basis that this input finite string specifies a >>>>>>>>> semantic or syntactic property.
And that is what is incomputable. It's possible for the finite >>>>>>>> string input to specify a diagonal case that is wrongly decided. >>>>>>>
the "do the opposite" code becomes unreachable.
That depends on the decider candidate.
When the decider candidate is a simulating halt decider
then its simulated input cannot possibly ever reach the
do the opposite code.
It can, if the simulator can detect what part of the simulated program >>>> is the simulator itself and skip the simulation of that code.
It seems to be the case that a function
cannot know its own machine address and
still be Turing computable otherwise HHH
would know that DD is specifying recursive
emulation as soon as DD calls HHH(DD).
The code
of the simulator itself is already known so there is no need to simulate >>>> it.
The non-halting behavior of DD() is based on
recursive simulation this needs to be verified.
There is no non-halting behavour of DD(). DD() halts.
And someone saw that Bill's identical twin brother
Bob robbed a liquor store making Bill guilty because
he looks just like Bob.
On 10/9/2025 10:25 PM, dbush wrote:
On 10/9/2025 10:55 PM, olcott wrote:
On 10/9/2025 8:42 PM, dbush wrote:
On 10/9/2025 9:37 PM, olcott wrote:
On 10/9/2025 7:06 PM, dbush wrote:
On 10/9/2025 7:58 PM, olcott wrote:
On 10/9/2025 4:41 PM, dbush wrote:
On 10/9/2025 5:38 PM, olcott wrote:
On 10/9/2025 4:11 PM, joes wrote:
Am Thu, 09 Oct 2025 15:54:33 -0500 schrieb olcott:
On 10/9/2025 3:12 PM, joes wrote:I didnrCOt write anything about callers.
Am Thu, 09 Oct 2025 15:04:21 -0500 schrieb olcott:or you would know that a function cannot possibly know
On 10/9/2025 2:29 PM, joes wrote:I mean. ThatrCOs why HHH is wrong. It does not look at the >>>>>>>>>>>> behaviour of
Am Thu, 09 Oct 2025 12:59:33 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 10/9/2025 12:50 PM, dbush wrote:
On 10/9/2025 1:43 PM, olcott wrote:
On 10/9/2025 11:36 AM, dbush wrote:
On 10/9/2025 12:30 PM, olcott wrote:
On 10/9/2025 11:21 AM, dbush wrote:
On 10/9/2025 12:15 PM, olcott wrote:
That would not be the behavior that HHH(DD) sees.Try running it on a UTM.How is this DD going to halt on its own?
HHH(DD) sees that unless is aborts its simulation that >>>>>>>>>>>>> itself will
never stop running.
UTM(DD), where DD calls HHH; it looks at UTM(DDu), where DDu >>>>>>>>>>>> calls
UTM(DDu). But as per your own statements, it absolutely >>>>>>>>>>>> should! HHH
overeagerly closes its eyes to the abort contained within DD. >>>>>>>>>>> I am estimating that you have very little actual programming >>>>>>>>>>> experience
anything about
its caller.
We must not see what would happen if the input were different. >>>>>>>>>>> Yes we must. It is required.We must see what would happen if it did not abort as our >>>>>>>>>>>>> basis to seeNo DD ever halts unless HHH(DD) aborts its simulation. >>>>>>>>>>>>>> Which it does, therefore DD halts.
if this criteria is met:
IrCOm gonna bow out here if you think deciders should not report >>>>>>>>>> on their
inputs.
*I have to read and reread to get the words right*
I read that backwards the first time.
Deciders must only report on their inputs
i.e. the Turing machine that the input finite string is a
representation
Yes you are good as spouting off conventional wisdom
as if this conventional wisdom were coming directly
from the mind of God.
Not conventional wisdom, just definitions.
Not at all. I have told you my definitions
hundreds of times and you never understood
a word of it.
And since your definition is not the definition of a halt decider,
it is irrelevant.
Sure just like on stack exchange all new ideas
are bad ideas.
Your irrelevant analogy construes your admission that the above is
correct.
thus
must not ever report on the behavior of their caller.
False, it must report on *all* machines.
How about the machine that I don't even know
how I will encode ten years from now?
YES!-a *All* possible machines!
So then tell me does this machine that
does not exist halt or fail to halt?
Once it is defined,
No that is the point. You said ALL machines and
this includes ones that do not currently exist.
But it can exist and at some point will exist, at which point it can
be decided on.
it can be decided on, and a total halt decider is required to decide
it.
The fact that the main-->DD() caller of HHH(DD)
halts is none of the damn business of HHH.
It is if it wants to meet its requirements:
It is these requirements that are incorrect.
Which is exactly what Turing and Linz proved.
Having a Turing machine report on something that it
cannot see is as logically impossible as a Turing
machine that computes the square root of a dead chicken.
All logical imposibilities are equally logically impossible
Then you agree that Turing and Linz are correct.
Linz was brilliant he was not trying to establish
new ground. He only sought to present the conventional
position succinctly. It seems to me that he did far
better than anyone else on this.
You can't make a halt decider
Which is exactly what Turing and Linz proved.
My most convincing argument is that halt deciders
cannot be correctly required to do things the deciders
cannot do.
The can only compute the mapping from the
input machine description on the basis of the behavior
that this machine description actually specifies.
DD does call HHH(DD) in recursive simulation this
behavior must be modeled and cannot be ignored.
On 10/10/2025 12:49 AM, olcott wrote:
On 2025-10-09 17:32:08 +0000, olcott said:
On 10/9/2025 4:57 AM, Mikko wrote:
On 2025-10-09 04:00:35 +0000, olcott said:
On 10/8/2025 4:52 AM, Mikko wrote:
On 2025-10-07 14:32:35 +0000, olcott said:
On 10/7/2025 3:49 AM, Mikko wrote:
On 2025-10-07 00:18:52 +0000, olcott said:
On 10/6/2025 4:11 AM, Mikko wrote:
On 2025-10-05 13:51:53 +0000, olcott said:
On 10/5/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-10-05, olcott <polcott333@gmail.com> wrote:
It is unreasonable to construe any logical
impossibility as an actual limitation.
That could practically be your motto.
A birthday case is limited in that it cannot land an
airliner. An actual hamburger patty is also limited
in that it cannot get elected to the US senate.
Both birthday cakes and hamburger patties are much more limited >>>>>>>>> that that. In paticular, we want that they are edible.
Yes and Turing machines do not have psychic
ability to report on behaviors that they cannot
see. The best that they can do is an execution
trace of the behavior that the input specifies
that sometimes includes the input calling its
own decider in recursive simulation.
Turns out that the best they can do is enouth to construct
a universal Turing machine but not enough to construct a
halt decider.
If you want to find out how much Bill weighs
you will not get this by weigh his little sister.
You will only get this by weighing Bill.
Or something that is known to weight the same as Bill,
or something whose weight has a known ratio to Bill's
weight.
If you want to find out if an input finite string
specifies the semantic property of halting you must
test this actual input finite string.
Or something that is known to have some determinable feature if
and only if the string asked about has the semantic property of
halting.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Above, unlike the original, does not define or require or claim
anuthing. Besides, the original does not say "unless aborted".
The above is the Linz proof construed with my
unique idea of a simulating halt decider. I assume
that you know what a simulating halt decider is by now.
The above is not a proof. A proof is a sequence of claims. The
above is not.
The first step of my proof is getting you
to totally understand the above.
What has that as the first step is not a proof.
Every step of a proof
is a claim, inluding the first and the last. There may be a label and justification atteched to that claim but the claim itself is the step
of the proof.
At this point it is sufficent to understand that your "adaptation"
is not what you said it be.
On 2025-10-09 17:37:15 +0000, olcott said:
On 10/9/2025 5:04 AM, Mikko wrote:
On 2025-10-09 04:02:32 +0000, olcott said:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then >>>>>>>>> its simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is
already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has
convinced everybody, and he'll keep on spewing it until he gets >>>>>>> that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern >>>>> that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
If the simulation is never stops then HHH is not a decider.
Yes, but until you understood this part we could
not move on to the next part.
FOrtunately it is not necessary or even useful to move to the next part.
On 2025-10-09 17:39:14 +0000, olcott said:
On 10/9/2025 5:08 AM, Mikko wrote:
On 2025-10-07 14:43:55 +0000, olcott said:
On 10/7/2025 4:00 AM, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
On 10/6/2025 4:27 AM, Mikko wrote:
On 2025-10-05 12:40:19 +0000, olcott said:
On 10/4/2025 11:34 AM, Kaz Kylheku wrote:
On 2025-10-04, olcott <polcott333@gmail.com> wrote:When the finite string input specifies a diagonal case
All Turing machine deciders only compute the mapping
from their finite string inputs to an accept state or reject >>>>>>>>>> state on the basis that this input finite string specifies a >>>>>>>>>> semantic or syntactic property.
And that is what is incomputable. It's possible for the finite >>>>>>>>> string input to specify a diagonal case that is wrongly decided. >>>>>>>>
the "do the opposite" code becomes unreachable.
That depends on the decider candidate.
When the decider candidate is a simulating halt decider
then its simulated input cannot possibly ever reach the
do the opposite code.
It can, if the simulator can detect what part of the simulated program >>>>> is the simulator itself and skip the simulation of that code.
It seems to be the case that a function
cannot know its own machine address and
still be Turing computable otherwise HHH
would know that DD is specifying recursive
emulation as soon as DD calls HHH(DD).
The code
of the simulator itself is already known so there is no need to
simulate
it.
The non-halting behavior of DD() is based on
recursive simulation this needs to be verified.
There is no non-halting behavour of DD(). DD() halts.
And someone saw that Bill's identical twin brother
Bob robbed a liquor store making Bill guilty because
he looks just like Bob.
Yes, that is analogous how your HHH concludes that DD halts.
It analyses a bother of DD that does not look just like DD
but close enough that HHH does not see the difference.
On 10/10/2025 7:02 AM, dbush wrote:
On 10/10/2025 12:49 AM, olcott wrote:
It is flatly incorrect to require a halt decider
to do something that no decider can do.
Op 10.okt.2025 om 16:08 schreef olcott:
On 10/10/2025 7:02 AM, dbush wrote:
On 10/10/2025 12:49 AM, olcott wrote:
It is flatly incorrect to require a halt decider to do
something that no decider can do.
It is flatly incorrect to require that I jump to the moon,
because that is something that no human can do. So it cannot
be proven that I cannot jump to the moon, because it is
incorrect to require something I cannot do.
On 10/10/2025 21:26, Fred. Zwarts wrote:
Op 10.okt.2025 om 16:08 schreef olcott:
On 10/10/2025 7:02 AM, dbush wrote:
On 10/10/2025 12:49 AM, olcott wrote:
It is flatly incorrect to require a halt decider to do something that
no decider can do.
QED.
It is flatly incorrect to require that I jump to the moon, because
that is something that no human can do. So it cannot be proven that I
cannot jump to the moon, because it is incorrect to require something
I cannot do.
It is, however, perfectly in order to assume that you *can* jump to the moon, derive a contradiction from the assumption, and thus show that the assumption was false. Crucially, no moons were jumped in the making of
this proof.
It is flatly incorrect to require a halt decider to do something that no decider can do.From? Absolutely not. They should compute whether a TM halts based on
Deciders can only compute the mapping from their inputs. Halt deciders
are required to compute the mapping from non-inputs.
On 10/9/2025 8:56 AM, joes wrote:If HHH were a pure (non-aborting) simulator, i.e. a UTM, that UTM would
Am Thu, 09 Oct 2025 08:00:32 -0500 schrieb olcott:
On 10/9/2025 5:45 AM, dbush wrote:
That you don't understand that HHH does not correctly simulate DD
because it aborts is not my mistake.
It is verified fact that unless HHH aborts that HHH never stops
running.
Yes, it is your lack of understanding that along the same lines unlessint DD()
HHH lets its input halt on its own, DD will always be halting.
We are not talking about the diagonal program to a non-aborting
simulator however.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
Am Fri, 10 Oct 2025 09:08:37 -0500 schrieb olcott:
It is flatly incorrect to require a halt decider to do something that noFrom? Absolutely not. They should compute whether a TM halts based on
decider can do.
Deciders can only compute the mapping from their inputs. Halt deciders
are required to compute the mapping from non-inputs.
its encoding. It turns out to be impossible to map that *to* the halting status.
On 10/10/2025 3:15 AM, Mikko wrote:
On 2025-10-09 17:32:08 +0000, olcott said:
On 10/9/2025 4:57 AM, Mikko wrote:
On 2025-10-09 04:00:35 +0000, olcott said:
On 10/8/2025 4:52 AM, Mikko wrote:
On 2025-10-07 14:32:35 +0000, olcott said:
On 10/7/2025 3:49 AM, Mikko wrote:
On 2025-10-07 00:18:52 +0000, olcott said:
On 10/6/2025 4:11 AM, Mikko wrote:
On 2025-10-05 13:51:53 +0000, olcott said:
On 10/5/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-10-05, olcott <polcott333@gmail.com> wrote:
It is unreasonable to construe any logical
impossibility as an actual limitation.
That could practically be your motto.
A birthday case is limited in that it cannot land an
airliner. An actual hamburger patty is also limited
in that it cannot get elected to the US senate.
Both birthday cakes and hamburger patties are much more limited >>>>>>>>>> that that. In paticular, we want that they are edible.
Yes and Turing machines do not have psychic
ability to report on behaviors that they cannot
see. The best that they can do is an execution
trace of the behavior that the input specifies
that sometimes includes the input calling its
own decider in recursive simulation.
Turns out that the best they can do is enouth to construct
a universal Turing machine but not enough to construct a
halt decider.
If you want to find out how much Bill weighs
you will not get this by weigh his little sister.
You will only get this by weighing Bill.
Or something that is known to weight the same as Bill,
or something whose weight has a known ratio to Bill's
weight.
If you want to find out if an input finite string
specifies the semantic property of halting you must
test this actual input finite string.
Or something that is known to have some determinable feature if
and only if the string asked about has the semantic property of
halting.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Above, unlike the original, does not define or require or claim
anuthing. Besides, the original does not say "unless aborted".
The above is the Linz proof construed with my
unique idea of a simulating halt decider. I assume
that you know what a simulating halt decider is by now.
The above is not a proof. A proof is a sequence of claims. The
above is not.
The first step of my proof is getting you
to totally understand the above.
What has that as the first step is not a proof.
The first step of any proof is the definition of the terms
The term [semantic property of finite string input]
On 10/10/2025 3:23 AM, Mikko wrote:
On 2025-10-09 17:37:15 +0000, olcott said:
On 10/9/2025 5:04 AM, Mikko wrote:
On 2025-10-09 04:02:32 +0000, olcott said:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its >>>>>>>>>> simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is >>>>>>>>> already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not interested.
He just wants to be assured that his baloney has convinced everybody, >>>>>>>> and he'll keep on spewing it until he gets that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern >>>>>> that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
If the simulation is never stops then HHH is not a decider.
Yes, but until you understood this part we could
not move on to the next part.
FOrtunately it is not necessary or even useful to move to the next part.
This rubric provides complete understanding of the
term [semantic halting property of finite string input]
to every LLM, even the otherwise stupid ones.
On 10/10/2025 3:25 AM, Mikko wrote:
On 2025-10-09 17:39:14 +0000, olcott said:
On 10/9/2025 5:08 AM, Mikko wrote:
On 2025-10-07 14:43:55 +0000, olcott said:
On 10/7/2025 4:00 AM, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
On 10/6/2025 4:27 AM, Mikko wrote:
On 2025-10-05 12:40:19 +0000, olcott said:
On 10/4/2025 11:34 AM, Kaz Kylheku wrote:
On 2025-10-04, olcott <polcott333@gmail.com> wrote:When the finite string input specifies a diagonal case
All Turing machine deciders only compute the mapping
from their finite string inputs to an accept state or reject >>>>>>>>>>> state on the basis that this input finite string specifies a >>>>>>>>>>> semantic or syntactic property.
And that is what is incomputable. It's possible for the finite >>>>>>>>>> string input to specify a diagonal case that is wrongly decided. >>>>>>>>>
the "do the opposite" code becomes unreachable.
That depends on the decider candidate.
When the decider candidate is a simulating halt decider
then its simulated input cannot possibly ever reach the
do the opposite code.
It can, if the simulator can detect what part of the simulated program >>>>>> is the simulator itself and skip the simulation of that code.
It seems to be the case that a function
cannot know its own machine address and
still be Turing computable otherwise HHH
would know that DD is specifying recursive
emulation as soon as DD calls HHH(DD).
The code
of the simulator itself is already known so there is no need to simulate >>>>>> it.
The non-halting behavior of DD() is based on
recursive simulation this needs to be verified.
There is no non-halting behavour of DD(). DD() halts.
And someone saw that Bill's identical twin brother
Bob robbed a liquor store making Bill guilty because
he looks just like Bob.
Yes, that is analogous how your HHH concludes that DD halts.
No it is the analysis of how people continue to
mistakenly believe that HHH must not report on
the actual behavior that its actual input actually specifies.
It analyses a bother of DD that does not look just like DD
but close enough that HHH does not see the difference.
Am Thu, 09 Oct 2025 11:15:44 -0500 schrieb olcott:
On 10/9/2025 8:56 AM, joes wrote:
Am Thu, 09 Oct 2025 08:00:32 -0500 schrieb olcott:
On 10/9/2025 5:45 AM, dbush wrote:
That you don't understand that HHH does not correctly simulate DD
because it aborts is not my mistake.
It is verified fact that unless HHH aborts that HHH never stops
running.
If HHH were a pure (non-aborting) simulator, i.e. a UTM, that UTM would
truly not halt on nonhalting inputs. HHH does abort though, therefore
the input DD that calls it halts as well. The rCRunlessrCY is fulfilled.
That makes the rest of the sentence hypothetical.
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
Yes, it is your lack of understanding that along the same lines unlessint DD()
HHH lets its input halt on its own, DD will always be halting.
We are not talking about the diagonal program to a non-aborting
simulator however.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
printf("Input_Halts = ", HHH(DD));
}
How is this DD going to halt on its own?
It would halt without being (passive) aborted. It doesnrCOt run forever.
(Not that being aborted means halting.)
Am Fri, 10 Oct 2025 09:08:37 -0500 schrieb olcott:
It is flatly incorrect to require a halt decider to do something that no
decider can do.
Deciders can only compute the mapping from their inputs. Halt deciders
are required to compute the mapping from non-inputs.
From? Absolutely not. They should compute whether a TM halts based on
its encoding. It turns out to be impossible to map that *to* the halting status.
On 10/11/2025 3:32 AM, joes wrote:
Am Thu, 09 Oct 2025 11:15:44 -0500 schrieb olcott:
On 10/9/2025 8:56 AM, joes wrote:
Am Thu, 09 Oct 2025 08:00:32 -0500 schrieb olcott:
On 10/9/2025 5:45 AM, dbush wrote:
That you don't understand that HHH does not correctly simulate DD
because it aborts is not my mistake.
It is verified fact that unless HHH aborts that HHH never stops
running.
If HHH were a pure (non-aborting) simulator, i.e. a UTM, that UTM would
truly not halt on nonhalting inputs. HHH does abort though, therefore
the input DD that calls it halts as well. The rCRunlessrCY is fulfilled.
That makes the rest of the sentence hypothetical.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
-a-a-a If simulating halt decider H correctly simulates its
-a-a-a input D until H correctly determines that its simulated D
-a-a-a would never stop running unless aborted then
Professor Sipser understood this, Ben Bacarisse understood
that and understood it was met. Claude AI understood this
and understood that it was met.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
-a H can abort its simulation of D and correctly report that D
-a specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
professor Sipser did not understand the
significance of these words
I exchanged emails with him about this. He does not agree with anything substantive that PO has written. I won't quote him, as I don't have permission, but he was, let's say... forthright, in his reply to me.
So that PO will have no cause to quote me as supporting his case: what Sipser understood he was agreeing to was NOT what PO interprets it as meaning. Sipser would not agree that the conclusion applies in PO's HHH(DDD) scenario, where DDD halts.
joes <noreply@example.org> writes:
Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:
Professor Sipser clearly agreed that an H that does a finite simulation
of D is to predict the behavior of an unlimited simulation of D.
If the simulator *itself* would not abort. The H called by D is,
by construction, the same and *does* abort.
We don't really know what context Sipser was given. I got in touch at
the time so do I know he had enough context to know that PO's ideas were "wacky" and that had agreed to what he considered a "minor remark".
Since PO considers his words finely crafted and key to his so-called
work I think it's clear that Sipser did not take the "minor remark" he agreed to to mean what PO takes it to mean! My own take if that he
(Sipser) read it as a general remark about how to determine some cases,
i.e. that D names an input that H can partially simulate to determine
it's halting or otherwise. We all know or could construct some such
cases.
I suspect he was tricked because PO used H and D as the names without
making it clear that D was constructed from H in the usual way (Sipser
uses H and D in at least one of his proofs). Of course, he is clued in enough know that, if D is indeed constructed from H like that, the
"minor remark" becomes true by being a hypothetical: if the moon is made
of cheese, the Martians can look forward to a fine fondue. But,
personally, I think the professor is more straight talking than that,
and he simply took as a method that can work for some inputs. That's
the only way is could be seen as a "minor remark" with being accused of being disingenuous.
On 10/11/2025 3:15 AM, joes wrote:
Am Fri, 10 Oct 2025 09:08:37 -0500 schrieb olcott:
It is flatly incorrect to require a halt decider to do something that no >>> decider can do.
Deciders can only compute the mapping from their inputs. Halt deciders
are required to compute the mapping from non-inputs.
From? Absolutely not. They should compute whether a TM halts based on
its encoding. It turns out to be impossible to map that *to* the halting
status.
The input to HHH(DD)
specifies that DD calls HHH(DD)
in recursive simulation, such that the call from the
simulated DD to the simulated HHH(DD) cannot possibly
return. *This cannot be correctly ignored*
The input to HHH1(DD) specifies that the call from the
simulated DD to the simulated HHH(DD) does return.
Turing machine deciders only compute the mapping
from their finite string inputs to an accept state
or reject state on the basis that this input finite
string specifies a semantic or syntactic property.
The only way to correctly determine the actual behaviorIs to determine which machine the finite string is defined to be a
that an actual input actually specifies
On 2025-10-10 16:16:21 +0000, olcott said:
On 10/10/2025 3:15 AM, Mikko wrote:
On 2025-10-09 17:32:08 +0000, olcott said:
On 10/9/2025 4:57 AM, Mikko wrote:
On 2025-10-09 04:00:35 +0000, olcott said:
On 10/8/2025 4:52 AM, Mikko wrote:
On 2025-10-07 14:32:35 +0000, olcott said:
On 10/7/2025 3:49 AM, Mikko wrote:
On 2025-10-07 00:18:52 +0000, olcott said:
On 10/6/2025 4:11 AM, Mikko wrote:
On 2025-10-05 13:51:53 +0000, olcott said:
On 10/5/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-10-05, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> It is unreasonable to construe any logical
impossibility as an actual limitation.
That could practically be your motto.
A birthday case is limited in that it cannot land an
airliner. An actual hamburger patty is also limited
in that it cannot get elected to the US senate.
Both birthday cakes and hamburger patties are much more limited >>>>>>>>>>> that that. In paticular, we want that they are edible.
Yes and Turing machines do not have psychic
ability to report on behaviors that they cannot
see. The best that they can do is an execution
trace of the behavior that the input specifies
that sometimes includes the input calling its
own decider in recursive simulation.
Turns out that the best they can do is enouth to construct
a universal Turing machine but not enough to construct a
halt decider.
If you want to find out how much Bill weighs
you will not get this by weigh his little sister.
You will only get this by weighing Bill.
Or something that is known to weight the same as Bill,
or something whose weight has a known ratio to Bill's
weight.
If you want to find out if an input finite string
specifies the semantic property of halting you must
test this actual input finite string.
Or something that is known to have some determinable feature if
and only if the string asked about has the semantic property of
halting.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Above, unlike the original, does not define or require or claim
anuthing. Besides, the original does not say "unless aborted".
The above is the Linz proof construed with my
unique idea of a simulating halt decider. I assume
that you know what a simulating halt decider is by now.
The above is not a proof. A proof is a sequence of claims. The
above is not.
The first step of my proof is getting you
to totally understand the above.
What has that as the first step is not a proof.
The first step of any proof is the definition of the terms
The term [semantic property of finite string input]
We don't need the general definition of "semantic property of finite
string input" when the discussion is restricted to halting, which is
just one property.
On 2025-10-10 16:21:10 +0000, olcott said:
On 10/10/2025 3:23 AM, Mikko wrote:
On 2025-10-09 17:37:15 +0000, olcott said:
On 10/9/2025 5:04 AM, Mikko wrote:
On 2025-10-09 04:02:32 +0000, olcott said:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then >>>>>>>>>>> its simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is >>>>>>>>>> already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has >>>>>>>>> convinced everybody, and he'll keep on spewing it until he gets >>>>>>>>> that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern >>>>>>> that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
If the simulation is never stops then HHH is not a decider.
Yes, but until you understood this part we could
not move on to the next part.
FOrtunately it is not necessary or even useful to move to the next part.
This rubric provides complete understanding of the
term [semantic halting property of finite string input]
to every LLM, even the otherwise stupid ones.
The meaning of "semantic halting property of finite string input" is
not needed. The phrase is not used in a typical halting problem
statement and not needed in the proof of uncomputability of halting.
It is sufficient to define what it means that a Turing machine halts.
On 2025-10-10 16:23:30 +0000, olcott said:
On 10/10/2025 3:25 AM, Mikko wrote:
On 2025-10-09 17:39:14 +0000, olcott said:
On 10/9/2025 5:08 AM, Mikko wrote:
On 2025-10-07 14:43:55 +0000, olcott said:
On 10/7/2025 4:00 AM, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
On 10/6/2025 4:27 AM, Mikko wrote:
On 2025-10-05 12:40:19 +0000, olcott said:
On 10/4/2025 11:34 AM, Kaz Kylheku wrote:
On 2025-10-04, olcott <polcott333@gmail.com> wrote:When the finite string input specifies a diagonal case
All Turing machine deciders only compute the mapping
from their finite string inputs to an accept state or reject >>>>>>>>>>>> state on the basis that this input finite string specifies a >>>>>>>>>>>> semantic or syntactic property.
And that is what is incomputable. It's possible for the finite >>>>>>>>>>> string input to specify a diagonal case that is wrongly decided. >>>>>>>>>>
the "do the opposite" code becomes unreachable.
That depends on the decider candidate.
When the decider candidate is a simulating halt decider
then its simulated input cannot possibly ever reach the
do the opposite code.
It can, if the simulator can detect what part of the simulated
program
is the simulator itself and skip the simulation of that code.
It seems to be the case that a function
cannot know its own machine address and
still be Turing computable otherwise HHH
would know that DD is specifying recursive
emulation as soon as DD calls HHH(DD).
The code
of the simulator itself is already known so there is no need to >>>>>>> simulate
it.
The non-halting behavior of DD() is based on
recursive simulation this needs to be verified.
There is no non-halting behavour of DD(). DD() halts.
And someone saw that Bill's identical twin brother
Bob robbed a liquor store making Bill guilty because
he looks just like Bob.
Yes, that is analogous how your HHH concludes that DD halts.
No it is the analysis of how people continue to
mistakenly believe that HHH must not report on
the actual behavior that its actual input actually specifies.
Your "analysis" is analogous to the behaviour of your HHH:
It analyses a bother of DD that does not look just like DD
but close enough that HHH does not see the difference.
You did not find any error in my analogy.
Yes we do. In is incorrect to require halt deciders
to do things that no decider can ever do.
On 10/11/2025 3:32 AM, joes wrote:Please use quotation marks for clarity.
Am Thu, 09 Oct 2025 11:15:44 -0500 schrieb olcott:
On 10/9/2025 8:56 AM, joes wrote:
Am Thu, 09 Oct 2025 08:00:32 -0500 schrieb olcott:
On 10/9/2025 5:45 AM, dbush wrote:
If HHH were a pure (non-aborting) simulator, i.e. a UTM, that UTM would
truly not halt on nonhalting inputs. HHH does abort though, therefore
the input DD that calls it halts as well. The rCRunlessrCY is fulfilled.
That makes the rest of the sentence hypothetical.
Claude AI also understood
that D specifies a non-halting sequence of configurations.
must mean the simulated D or it is incorrect.
The pattern is wrong. A UTM and HHH1 simulate DD as halting just fine.Yes, it is your lack of understanding that along the same lines
unless HHH lets its input halt on its own, DD will always be halting.
The clear correct and direct answer is that DD cannot halt on its own an intervention must be made. HHH does this on the basis that its simulatedHow is this DD going to halt on its own?It would halt without being (passive) aborted. It doesnrCOt run forever.
D matches the non-halting behavior pattern of recursive simulation.
I just told the LLM systems that there is such a thing as "aThere is no such pattern in DD. It calls HHH which does only two levels
non-terminating behavior pattern" they figured out on their on that it
is recursive simulation.
On 10/11/2025 4:51 AM, Mikko wrote:No, DD does not specify that. It calls HHH which aborts.
On 2025-10-10 16:23:30 +0000, olcott said:
On 10/10/2025 3:25 AM, Mikko wrote:
On 2025-10-09 17:39:14 +0000, olcott said:
On 10/9/2025 5:08 AM, Mikko wrote:
On 2025-10-07 14:43:55 +0000, olcott said:
And someone saw that Bill's identical twin brother Bob robbed aThe non-halting behavior of DD() is based on recursive simulation >>>>>>> this needs to be verified.There is no non-halting behavour of DD(). DD() halts.
liquor store making Bill guilty because he looks just like Bob.
Your "analysis" is analogous to the behaviour of your HHH:Yes, that is analogous how your HHH concludes that DD halts.No it is the analysis of how people continue to mistakenly believe
that HHH must not report on the actual behavior that its actual input
actually specifies.
You did not find any error in my analogy.It analyses a bother of DD that does not look just like DD but close
enough that HHH does not see the difference.
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive
simulation, such that the call from the simulated DD to the simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored*
The input to HHH1(DD) specifies that the call from the simulated DD toNo, this is the same input.
the simulated HHH(DD) does return.
Am Sat, 11 Oct 2025 07:24:52 -0500 schrieb olcott:
On 10/11/2025 3:32 AM, joes wrote:
Am Thu, 09 Oct 2025 11:15:44 -0500 schrieb olcott:
On 10/9/2025 8:56 AM, joes wrote:
Am Thu, 09 Oct 2025 08:00:32 -0500 schrieb olcott:
On 10/9/2025 5:45 AM, dbush wrote:
If HHH were a pure (non-aborting) simulator, i.e. a UTM, that UTM would
truly not halt on nonhalting inputs. HHH does abort though, therefore
the input DD that calls it halts as well. The rCRunlessrCY is fulfilled. >>> That makes the rest of the sentence hypothetical.
Claude AI also understoodPlease use quotation marks for clarity.
that D specifies a non-halting sequence of configurations.
must mean the simulated D or it is incorrect.
Yes, it is your lack of understanding that along the same lines
unless HHH lets its input halt on its own, DD will always be halting.
The clear correct and direct answer is that DD cannot halt on its own anHow is this DD going to halt on its own?It would halt without being (passive) aborted. It doesnrCOt run forever.
intervention must be made. HHH does this on the basis that its simulated
D matches the non-halting behavior pattern of recursive simulation.
The pattern is wrong. A UTM and HHH1 simulate DD as halting just fine.
I just told the LLM systems that there is such a thing as "a
non-terminating behavior pattern" they figured out on their on that it
is recursive simulation.
There is no such pattern in DD. It calls HHH which does only two levels
of simulation. DD_UTM has that pattern, but it is not the input.
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
On 10/11/2025 4:51 AM, Mikko wrote:
On 2025-10-10 16:23:30 +0000, olcott said:
On 10/10/2025 3:25 AM, Mikko wrote:
On 2025-10-09 17:39:14 +0000, olcott said:
On 10/9/2025 5:08 AM, Mikko wrote:
On 2025-10-07 14:43:55 +0000, olcott said:
And someone saw that Bill's identical twin brother Bob robbed aThe non-halting behavior of DD() is based on recursive simulation >>>>>>>> this needs to be verified.There is no non-halting behavour of DD(). DD() halts.
liquor store making Bill guilty because he looks just like Bob.
Your "analysis" is analogous to the behaviour of your HHH:Yes, that is analogous how your HHH concludes that DD halts.No it is the analysis of how people continue to mistakenly believe
that HHH must not report on the actual behavior that its actual input
actually specifies.
You did not find any error in my analogy.It analyses a bother of DD that does not look just like DD but close >>>>> enough that HHH does not see the difference.
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive
simulation, such that the call from the simulated DD to the simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored*
No, DD does not specify that. It calls HHH which aborts.
The input to HHH1(DD) specifies that the call from the simulated DD toNo, this is the same input.
the simulated HHH(DD) does return.
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
On 10/11/2025 4:51 AM, Mikko wrote:
On 2025-10-10 16:23:30 +0000, olcott said:
On 10/10/2025 3:25 AM, Mikko wrote:
On 2025-10-09 17:39:14 +0000, olcott said:
On 10/9/2025 5:08 AM, Mikko wrote:
There is no non-halting behavour of DD(). DD() halts.And someone saw that Bill's identical twin brother Bob robbed a
liquor store making Bill guilty because he looks just like Bob.
Yes, that is analogous how your HHH concludes that DD halts.
It analyses a bother of DD that does not look just like DD but
close enough that HHH does not see the difference.
You keep confusing the directly executed DD with the correctly simulated input DD are you making this mistake on purpose?The input to HHH(DD) specifies that DD calls HHH(DD) in recursiveNo, DD does not specify that. It calls HHH which aborts.
simulation, such that the call from the simulated DD to the simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored*
The input to HHH1(DD) specifies that the call from the simulated DD toNo, this is the same input.
the simulated HHH(DD) does return.
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
On 10/11/2025 4:51 AM, Mikko wrote:
On 2025-10-10 16:23:30 +0000, olcott said:
On 10/10/2025 3:25 AM, Mikko wrote:
On 2025-10-09 17:39:14 +0000, olcott said:
On 10/9/2025 5:08 AM, Mikko wrote:
There is no non-halting behavour of DD(). DD() halts.And someone saw that Bill's identical twin brother Bob robbed a >>>>>>>> liquor store making Bill guilty because he looks just like Bob.
Yes, that is analogous how your HHH concludes that DD halts.
It analyses a bother of DD that does not look just like DD but
close enough that HHH does not see the difference.
You keep confusing the directly executed DD with the correctly simulatedThe input to HHH(DD) specifies that DD calls HHH(DD) in recursiveNo, DD does not specify that. It calls HHH which aborts.
simulation, such that the call from the simulated DD to the simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored*
input DD are you making this mistake on purpose?
The input to HHH1(DD) specifies that the call from the simulated DD to >>>> the simulated HHH(DD) does return.No, this is the same input.
ItrCOs not a mistake. We have the program DD which calls HHH which aborts.
We encode that program and pass it to HHH. HHH then simulates DD
calling an aborting simulator. The input is the encoding of DD, not
that of DD_UTM.
On 10/11/2025 9:19 AM, olcott wrote:
Yes we do. In is incorrect to require halt deciders
to do things that no decider can ever do.
Then the only possible conclusion is that halt deciders don't exist.
Which is exactly what Turing and Linz proved.
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
On 10/11/2025 4:51 AM, Mikko wrote:
On 2025-10-10 16:23:30 +0000, olcott said:
On 10/10/2025 3:25 AM, Mikko wrote:
On 2025-10-09 17:39:14 +0000, olcott said:
And someone saw that Bill's identical twin brother Bob robbed a >>>>>>>>> liquor store making Bill guilty because he looks just like Bob.
Yes, that is analogous how your HHH concludes that DD halts.
It analyses a bother of DD that does not look just like DD but >>>>>>>> close enough that HHH does not see the difference.
You keep confusing the directly executed DD with the correctlyThe input to HHH(DD) specifies that DD calls HHH(DD) in recursiveNo, DD does not specify that. It calls HHH which aborts.
simulation, such that the call from the simulated DD to the
simulated HHH(DD) cannot possibly return. *This cannot be correctly
ignored*
simulated input DD are you making this mistake on purpose?
The input to HHH1(DD) specifies that the call from the simulated DDNo, this is the same input.
to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH which
aborts.
We encode that program and pass it to HHH. HHH then simulates DD
calling an aborting simulator. The input is the encoding of DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive
simulation, such that the call from the simulated DD to the simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored*
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
On 10/11/2025 4:51 AM, Mikko wrote:
On 2025-10-10 16:23:30 +0000, olcott said:
On 10/10/2025 3:25 AM, Mikko wrote:
On 2025-10-09 17:39:14 +0000, olcott said:
And someone saw that Bill's identical twin brother Bob robbed a >>>>>>>>>> liquor store making Bill guilty because he looks just like Bob. >>>>>Yes, that is analogous how your HHH concludes that DD halts.
It analyses a bother of DD that does not look just like DD but >>>>>>>>> close enough that HHH does not see the difference.
You keep confusing the directly executed DD with the correctlyThe input to HHH(DD) specifies that DD calls HHH(DD) in recursiveNo, DD does not specify that. It calls HHH which aborts.
simulation, such that the call from the simulated DD to the
simulated HHH(DD) cannot possibly return. *This cannot be correctly >>>>>> ignored*
simulated input DD are you making this mistake on purpose?
The input to HHH1(DD) specifies that the call from the simulated DD >>>>>> to the simulated HHH(DD) does return.No, this is the same input.
ItrCOs not a mistake. We have the program DD which calls HHH which
aborts.
We encode that program and pass it to HHH. HHH then simulates DD
calling an aborting simulator. The input is the encoding of DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive
simulation, such that the call from the simulated DD to the simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt return. You specifically coded it that way. DD specifies a call to it, therefore
DD returns.
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an intentionally deceiving way that to attempt to fool others intoYou keep confusing the directly executed DD with the correctlyThe input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>> simulation, such that the call from the simulated DD to theNo, DD does not specify that. It calls HHH which aborts.
simulated HHH(DD) cannot possibly return. *This cannot be
correctly ignored*
simulated input DD are you making this mistake on purpose?
The input to HHH1(DD) specifies that the call from the simulated >>>>>>> DD to the simulated HHH(DD) does return.No, this is the same input.
ItrCOs not a mistake. We have the program DD which calls HHH which
aborts.
We encode that program and pass it to HHH. HHH then simulates DD
calling an aborting simulator. The input is the encoding of DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive
simulation, such that the call from the simulated DD to the simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt return. >> You specifically coded it that way. DD specifies a call to it,
therefore DD returns.
believing that the simulated instance of HHH(DD) that simulated DD calls
ever returns.
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in anYou keep confusing the directly executed DD with the correctlyThe input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>> simulation, such that the call from the simulated DD to theNo, DD does not specify that. It calls HHH which aborts.
simulated HHH(DD) cannot possibly return. *This cannot be
correctly ignored*
simulated input DD are you making this mistake on purpose?
The input to HHH1(DD) specifies that the call from the simulated >>>>>>>> DD to the simulated HHH(DD) does return.No, this is the same input.
ItrCOs not a mistake. We have the program DD which calls HHH which
aborts.
We encode that program and pass it to HHH. HHH then simulates DD
calling an aborting simulator. The input is the encoding of DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive
simulation, such that the call from the simulated DD to the simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt return. >>> You specifically coded it that way. DD specifies a call to it,
therefore DD returns.
intentionally deceiving way that to attempt to fool others into
believing that the simulated instance of HHH(DD) that simulated DD calls
ever returns.
*What* is only because of that? What is the strawman? HHH aborting
doesnrCOt make DD non-halting. You know that DD halts. That can only
be possible if HHH halts.
On 10/11/2025 8:24 AM, dbush wrote:Namely that the following requirements cannot be satisfied as Turing and
On 10/11/2025 9:19 AM, olcott wrote:
Yes we do. In is incorrect to require halt deciders
to do things that no decider can ever do.
Then the only possible conclusion is that halt deciders don't exist.
Which is exactly what Turing and Linz proved.
I pointed out specific incoherence
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in anYou keep confusing the directly executed DD with the correctlyThe input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>>> simulation, such that the call from the simulated DD to theNo, DD does not specify that. It calls HHH which aborts.
simulated HHH(DD) cannot possibly return. *This cannot be
correctly ignored*
simulated input DD are you making this mistake on purpose?
The input to HHH1(DD) specifies that the call from the simulated >>>>>>>>> DD to the simulated HHH(DD) does return.No, this is the same input.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD
calling an aborting simulator. The input is the encoding of DD, not >>>>>> that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive
simulation, such that the call from the simulated DD to the simulated >>>>> HHH(DD) cannot possibly return. *This cannot be correctly ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt return. >>>> You specifically coded it that way. DD specifies a call to it,
therefore DD returns.
intentionally deceiving way that to attempt to fool others into
believing that the simulated instance of HHH(DD) that simulated DD calls >>> ever returns.
*What* is only because of that? What is the strawman? HHH aborting
doesnrCOt make DD non-halting. You know that DD halts. That can only
be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a return 1.
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in anYou keep confusing the directly executed DD with the correctly >>>>>>>> simulated input DD are you making this mistake on purpose?The input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>>>> simulation, such that the call from the simulated DD to the >>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot beNo, DD does not specify that. It calls HHH which aborts.
correctly ignored*
The input to HHH1(DD) specifies that the call from the simulated >>>>>>>>>> DD to the simulated HHH(DD) does return.No, this is the same input.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD >>>>>>> calling an aborting simulator. The input is the encoding of DD, not >>>>>>> that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive
simulation, such that the call from the simulated DD to the simulated >>>>>> HHH(DD) cannot possibly return. *This cannot be correctly ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt return.
You specifically coded it that way. DD specifies a call to it,
therefore DD returns.
intentionally deceiving way that to attempt to fool others into
believing that the simulated instance of HHH(DD) that simulated DD
calls
ever returns.
*What* is only because of that? What is the strawman? HHH aborting
doesnrCOt make DD non-halting. You know that DD halts. That can only
be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in the
halting computation DD and therefore is *not* a non-terminating behavior pattern.
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in anHonestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>> return.You keep confusing the directly executed DD with the correctly >>>>>>>>> simulated input DD are you making this mistake on purpose?The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts.
simulation, such that the call from the simulated DD to the >>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the simulated >>>>>>>>>>> DD to the simulated HHH(DD) does return.No, this is the same input.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD >>>>>>>> calling an aborting simulator. The input is the encoding of DD, not >>>>>>>> that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>> simulation, such that the call from the simulated DD to the
simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored* >>>>>>
You specifically coded it that way. DD specifies a call to it,
therefore DD returns.
intentionally deceiving way that to attempt to fool others into
believing that the simulated instance of HHH(DD) that simulated DD
calls
ever returns.
*What* is only because of that? What is the strawman? HHH aborting
doesnrCOt make DD non-halting. You know that DD halts. That can only
be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in the
halting computation DD and therefore is *not* a non-terminating
behavior pattern.
The pattern does exist in the input.
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in anHonestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>>> return.You keep confusing the directly executed DD with the correctly >>>>>>>>>> simulated input DD are you making this mistake on purpose? >>>>>>>>>>The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts.
simulation, such that the call from the simulated DD to the >>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD >>>>>>>>> calling an aborting simulator. The input is the encoding of DD, >>>>>>>>> not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>> simulation, such that the call from the simulated DD to the
simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored* >>>>>>>
You specifically coded it that way. DD specifies a call to it,
therefore DD returns.
intentionally deceiving way that to attempt to fool others into
believing that the simulated instance of HHH(DD) that simulated DD >>>>>> calls
ever returns.
*What* is only because of that? What is the strawman? HHH aborting
doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in the
halting computation DD and therefore is *not* a non-terminating
behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in anHonestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>>> return.You keep confusing the directly executed DD with the correctly >>>>>>>>>> simulated input DD are you making this mistake on purpose? >>>>>>>>>>The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts.
simulation, such that the call from the simulated DD to the >>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD >>>>>>>>> calling an aborting simulator. The input is the encoding of DD, >>>>>>>>> not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>> simulation, such that the call from the simulated DD to the
simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored* >>>>>>>
You specifically coded it that way. DD specifies a call to it,
therefore DD returns.
intentionally deceiving way that to attempt to fool others into
believing that the simulated instance of HHH(DD) that simulated DD >>>>>> calls
ever returns.
*What* is only because of that? What is the strawman? HHH aborting
doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in the
halting computation DD and therefore is *not* a non-terminating
behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
On 10/11/2025 4:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an >>>>>>> intentionally deceiving way that to attempt to fool others intoHonestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>>>> return.The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>> You keep confusing the directly executed DD with the correctly >>>>>>>>>>> simulated input DD are you making this mistake on purpose? >>>>>>>>>>>
simulation, such that the call from the simulated DD to the >>>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD >>>>>>>>>> calling an aborting simulator. The input is the encoding of >>>>>>>>>> DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>>> simulation, such that the call from the simulated DD to the >>>>>>>>> simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored* >>>>>>>>
You specifically coded it that way. DD specifies a call to it, >>>>>>>> therefore DD returns.
believing that the simulated instance of HHH(DD) that simulated >>>>>>> DD calls
ever returns.
*What* is only because of that? What is the strawman? HHH aborting >>>>>> doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in the
halting computation DD and therefore is *not* a non-terminating
behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
Correction: and because DD halts, the pattern is proven to *not* be a non-halting behavior pattern.
On 10/11/2025 3:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an >>>>>>> intentionally deceiving way that to attempt to fool others intoHonestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>>>> return.The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>> You keep confusing the directly executed DD with the correctly >>>>>>>>>>> simulated input DD are you making this mistake on purpose? >>>>>>>>>>>
simulation, such that the call from the simulated DD to the >>>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD >>>>>>>>>> calling an aborting simulator. The input is the encoding of >>>>>>>>>> DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>>> simulation, such that the call from the simulated DD to the >>>>>>>>> simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored* >>>>>>>>
You specifically coded it that way. DD specifies a call to it, >>>>>>>> therefore DD returns.
believing that the simulated instance of HHH(DD) that simulated >>>>>>> DD calls
ever returns.
*What* is only because of that? What is the strawman? HHH aborting >>>>>> doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in the
halting computation DD and therefore is *not* a non-terminating
behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
The DD directly executed process called from
main that calls HHH cannot possibly be an
argument to the function HHH.
On 10/11/2025 3:41 PM, dbush wrote:
On 10/11/2025 4:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an >>>>>>>> intentionally deceiving way that to attempt to fool others into >>>>>>>> believing that the simulated instance of HHH(DD) that simulated >>>>>>>> DD callsThe input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>>> You keep confusing the directly executed DD with the correctly >>>>>>>>>>>> simulated input DD are you making this mistake on purpose? >>>>>>>>>>>>
simulation, such that the call from the simulated DD to the >>>>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>>>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD >>>>>>>>>>> calling an aborting simulator. The input is the encoding of >>>>>>>>>>> DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>>>> simulation, such that the call from the simulated DD to the >>>>>>>>>> simulated
HHH(DD) cannot possibly return. *This cannot be correctly >>>>>>>>>> ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>>>>> return.
You specifically coded it that way. DD specifies a call to it, >>>>>>>>> therefore DD returns.
ever returns.
*What* is only because of that? What is the strawman? HHH aborting >>>>>>> doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input >>>>>> until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in
the halting computation DD and therefore is *not* a non-terminating >>>>> behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
Correction: and because DD halts, the pattern is proven to *not* be a
non-halting behavior pattern.
Given that Bill's identical twin brother Bob
was seen robbing a liquor store this conclusively
proves that Bill is guilty because he looks
just like Bob.
On 10/11/2025 4:59 PM, olcott wrote:
On 10/11/2025 3:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an >>>>>>>> intentionally deceiving way that to attempt to fool others into >>>>>>>> believing that the simulated instance of HHH(DD) that simulated >>>>>>>> DD callsThe input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>>> You keep confusing the directly executed DD with the correctly >>>>>>>>>>>> simulated input DD are you making this mistake on purpose? >>>>>>>>>>>>
simulation, such that the call from the simulated DD to the >>>>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>>>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD >>>>>>>>>>> calling an aborting simulator. The input is the encoding of >>>>>>>>>>> DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>>>> simulation, such that the call from the simulated DD to the >>>>>>>>>> simulated
HHH(DD) cannot possibly return. *This cannot be correctly >>>>>>>>>> ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>>>>> return.
You specifically coded it that way. DD specifies a call to it, >>>>>>>>> therefore DD returns.
ever returns.
*What* is only because of that? What is the strawman? HHH aborting >>>>>>> doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input >>>>>> until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in
the halting computation DD and therefore is *not* a non-terminating >>>>> behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
The DD directly executed process called from
main that calls HHH cannot possibly be an
argument to the function HHH.
But since directly executing DD will always do the same thing, HHH must predict what *would* happen if DD was executed directly, not necessarily "this time".
On 10/11/2025 5:01 PM, olcott wrote:
On 10/11/2025 3:41 PM, dbush wrote:
On 10/11/2025 4:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an >>>>>>>>> intentionally deceiving way that to attempt to fool others into >>>>>>>>> believing that the simulated instance of HHH(DD) that simulated >>>>>>>>> DD callsThe input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>>>> You keep confusing the directly executed DD with the correctly >>>>>>>>>>>>> simulated input DD are you making this mistake on purpose? >>>>>>>>>>>>>
simulation, such that the call from the simulated DD to the >>>>>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH >>>>>>>>>>>> which
aborts.
We encode that program and pass it to HHH. HHH then
simulates DD
calling an aborting simulator. The input is the encoding of >>>>>>>>>>>> DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>> recursive
simulation, such that the call from the simulated DD to the >>>>>>>>>>> simulated
HHH(DD) cannot possibly return. *This cannot be correctly >>>>>>>>>>> ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>>>>>> return.
You specifically coded it that way. DD specifies a call to it, >>>>>>>>>> therefore DD returns.
ever returns.
*What* is only because of that? What is the strawman? HHH aborting >>>>>>>> doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in
the halting computation DD and therefore is *not* a non-
terminating behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
Correction: and because DD halts, the pattern is proven to *not* be a
non-halting behavior pattern.
Given that Bill's identical twin brother Bob
was seen robbing a liquor store this conclusively
proves that Bill is guilty because he looks
just like Bob.
Which is exactly why you think that HHH(DD) should report on the non-
input DDn.
On 10/11/2025 4:01 PM, dbush wrote:
On 10/11/2025 4:59 PM, olcott wrote:
On 10/11/2025 3:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an >>>>>>>>> intentionally deceiving way that to attempt to fool others into >>>>>>>>> believing that the simulated instance of HHH(DD) that simulated >>>>>>>>> DD callsThe input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>>>> You keep confusing the directly executed DD with the correctly >>>>>>>>>>>>> simulated input DD are you making this mistake on purpose? >>>>>>>>>>>>>
simulation, such that the call from the simulated DD to the >>>>>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH >>>>>>>>>>>> which
aborts.
We encode that program and pass it to HHH. HHH then
simulates DD
calling an aborting simulator. The input is the encoding of >>>>>>>>>>>> DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>> recursive
simulation, such that the call from the simulated DD to the >>>>>>>>>>> simulated
HHH(DD) cannot possibly return. *This cannot be correctly >>>>>>>>>>> ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>>>>>> return.
You specifically coded it that way. DD specifies a call to it, >>>>>>>>>> therefore DD returns.
ever returns.
*What* is only because of that? What is the strawman? HHH aborting >>>>>>>> doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in
the halting computation DD and therefore is *not* a non-
terminating behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
The DD directly executed process called from
main that calls HHH cannot possibly be an
argument to the function HHH.
But since directly executing DD will always do the same thing, HHH
must predict what *would* happen if DD was executed directly, not
necessarily "this time".
That is stupidly saying the same thing as
you never ever have to eat any food because
you know that after you eat you will no
longer be hungry.
DD only haltsBecause it executes a sequence of steps that result in it reaching a
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping (see below). And Turing
On 10/11/2025 5:01 PM, olcott wrote:
On 10/11/2025 3:41 PM, dbush wrote:
On 10/11/2025 4:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an >>>>>>>>>> intentionally deceiving way that to attempt to fool others into >>>>>>>>>> believing that the simulated instance of HHH(DD) thatsimulated input DD are you making this mistake on purpose? >>>>>>>>>>>>>>The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>>>>> You keep confusing the directly executed DD with the >>>>>>>>>>>>>> correctly
simulation, such that the call from the simulated DD to the >>>>>>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH >>>>>>>>>>>>> which
aborts.
We encode that program and pass it to HHH. HHH then >>>>>>>>>>>>> simulates DD
calling an aborting simulator. The input is the encoding of >>>>>>>>>>>>> DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>> recursive
simulation, such that the call from the simulated DD to the >>>>>>>>>>>> simulated
HHH(DD) cannot possibly return. *This cannot be correctly >>>>>>>>>>>> ignored*
Honestly, I donrCOt know where you get the idea that HHH >>>>>>>>>>> doesnrCOt return.
You specifically coded it that way. DD specifies a call to it, >>>>>>>>>>> therefore DD returns.
simulated DD calls
ever returns.
*What* is only because of that? What is the strawman? HHH aborting >>>>>>>>> doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>>>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its
input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in >>>>>>> the halting computation DD and therefore is *not* a non-
terminating behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
Correction: and because DD halts, the pattern is proven to *not* be
a non-halting behavior pattern.
Given that Bill's identical twin brother Bob
was seen robbing a liquor store this conclusively
proves that Bill is guilty because he looks
just like Bob.
Which is exactly why you think that HHH(DD) should report on the non-
input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
On 10/11/2025 5:26 PM, olcott wrote:Not at all. This HHH(DD) must only compute the
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
On 10/11/2025 5:01 PM, olcott wrote:
On 10/11/2025 3:41 PM, dbush wrote:
On 10/11/2025 4:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an >>>>>>>>>>> intentionally deceiving way that to attempt to fool others into >>>>>>>>>>> believing that the simulated instance of HHH(DD) thatsimulated input DD are you making this mistake on purpose? >>>>>>>>>>>>>>>The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>>>>>> You keep confusing the directly executed DD with the >>>>>>>>>>>>>>> correctly
simulation, such that the call from the simulated DD to >>>>>>>>>>>>>>>>> the
simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH >>>>>>>>>>>>>> which
aborts.
We encode that program and pass it to HHH. HHH then >>>>>>>>>>>>>> simulates DD
calling an aborting simulator. The input is the encoding >>>>>>>>>>>>>> of DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>> recursive
simulation, such that the call from the simulated DD to the >>>>>>>>>>>>> simulated
HHH(DD) cannot possibly return. *This cannot be correctly >>>>>>>>>>>>> ignored*
Honestly, I donrCOt know where you get the idea that HHH >>>>>>>>>>>> doesnrCOt return.
You specifically coded it that way. DD specifies a call to it, >>>>>>>>>>>> therefore DD returns.
simulated DD calls
ever returns.
*What* is only because of that? What is the strawman? HHH >>>>>>>>>> aborting
doesnrCOt make DD non-halting. You know that DD halts. That can >>>>>>>>>> only
be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its >>>>>>>>> input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: >>>>>>>>> -a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in >>>>>>>> the halting computation DD and therefore is *not* a non-
terminating behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
Correction: and because DD halts, the pattern is proven to *not* be >>>>> a non-halting behavior pattern.
Given that Bill's identical twin brother Bob
was seen robbing a liquor store this conclusively
proves that Bill is guilty because he looks
just like Bob.
Which is exactly why you think that HHH(DD) should report on the non-
input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
On 10/11/2025 5:01 PM, olcott wrote:
On 10/11/2025 3:41 PM, dbush wrote:
On 10/11/2025 4:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:It is only because you deliberately use the strawman error >>>>>>>>>>>> in an
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott: >>>>>>>>>>>simulated input DD are you making this mistake on purpose? >>>>>>>>>>>>>>>>
The input to HHH(DD) specifies that DD calls HHH(DD) >>>>>>>>>>>>>>>>>> in recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>>>>>>> You keep confusing the directly executed DD with the >>>>>>>>>>>>>>>> correctly
simulation, such that the call from the simulated DD >>>>>>>>>>>>>>>>>> to the
simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls >>>>>>>>>>>>>>> HHH which
aborts.
We encode that program and pass it to HHH. HHH then >>>>>>>>>>>>>>> simulates DD
calling an aborting simulator. The input is the encoding >>>>>>>>>>>>>>> of DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>>> recursive
simulation, such that the call from the simulated DD to >>>>>>>>>>>>>> the simulated
HHH(DD) cannot possibly return. *This cannot be correctly >>>>>>>>>>>>>> ignored*
Honestly, I donrCOt know where you get the idea that HHH >>>>>>>>>>>>> doesnrCOt return.
You specifically coded it that way. DD specifies a call to it, >>>>>>>>>>>>> therefore DD returns.
intentionally deceiving way that to attempt to fool others into >>>>>>>>>>>> believing that the simulated instance of HHH(DD) that >>>>>>>>>>>> simulated DD calls
ever returns.
*What* is only because of that? What is the strawman? HHH >>>>>>>>>>> aborting
doesnrCOt make DD non-halting. You know that DD halts. That can >>>>>>>>>>> only
be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its >>>>>>>>>> input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: >>>>>>>>>> -a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists >>>>>>>>> in the halting computation DD and therefore is *not* a non- >>>>>>>>> terminating behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
Correction: and because DD halts, the pattern is proven to *not*
be a non-halting behavior pattern.
Given that Bill's identical twin brother Bob
was seen robbing a liquor store this conclusively
proves that Bill is guilty because he looks
just like Bob.
Which is exactly why you think that HHH(DD) should report on the
non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
On 10/11/2025 5:26 PM, olcott wrote:Not at all. This HHH(DD) must only compute the
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on the non-
input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on the
non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on the
non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
On 10/11/2025 4:54 PM, dbush wrote:And since it can't do that and also perform the required mapping to be a
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on the
non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
On 10/11/2025 6:10 PM, olcott wrote:OK so you are either a liar or incompetent.
On 10/11/2025 4:54 PM, dbush wrote:And since it can't do that
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on the >>>>>>> non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:OK so you are either a liar or incompetent.
On 10/11/2025 4:54 PM, dbush wrote:And since it can't do that and also perform the required mapping to be a
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on the >>>>>>>> non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
halt decider (see below), it's not a halt decider.
It doesn't matter which.
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly --- Synchronet 3.21a-Linux NewsLink 1.2
On 10/11/2025 6:30 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:OK so you are either a liar or incompetent.
On 10/11/2025 4:54 PM, dbush wrote:And since it can't do that and also perform the required mapping to
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on >>>>>>>>> the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
be a halt decider (see below), it's not a halt decider.
It doesn't matter which.
So now you're claiming that HHH computes the below mapping?
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in anYou keep confusing the directly executed DD with the correctlyThe input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>>> simulation, such that the call from the simulated DD to theNo, DD does not specify that. It calls HHH which aborts.
simulated HHH(DD) cannot possibly return. *This cannot be
correctly ignored*
simulated input DD are you making this mistake on purpose?
The input to HHH1(DD) specifies that the call from the simulated >>>>>>>>> DD to the simulated HHH(DD) does return.No, this is the same input.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD
calling an aborting simulator. The input is the encoding of DD, not >>>>>> that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive
simulation, such that the call from the simulated DD to the simulated >>>>> HHH(DD) cannot possibly return. *This cannot be correctly ignored*
Honestly, I donrCOt know where you get the idea that HHH doesnrCOt return. >>>> You specifically coded it that way. DD specifies a call to it,
therefore DD returns.
intentionally deceiving way that to attempt to fool others into
believing that the simulated instance of HHH(DD) that simulated DD calls >>> ever returns.
*What* is only because of that? What is the strawman? HHH aborting
doesnrCOt make DD non-halting. You know that DD halts. That can only
be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a return 1.
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on the >>>>>>> non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping to be a halt decider (see below), it's not a halt decider.
On 10/11/2025 5:34 PM, dbush wrote:And since it can't do that and also compute the following mapping, it's
On 10/11/2025 6:30 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:OK so you are either a liar or incompetent.
On 10/11/2025 4:54 PM, dbush wrote:And since it can't do that and also perform the required mapping to
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on >>>>>>>>>> the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
be a halt decider (see below), it's not a halt decider.
It doesn't matter which.
So now you're claiming that HHH computes the below mapping?
I am claiming that HHH(DD) correctly prevents its
own non-termination.
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on the >>>>>>>> non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping to be
a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on >>>>>>>>> the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping to
be a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on >>>>>>>>>> the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping to
be a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
In other words you could find any error in my post so you resort to the
lame tactic of ad hominem personal attack.
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on >>>>>>>>>>> the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping to >>>>> be a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so you resort to the lame tactic of ad hominem personal attack.
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on >>>>>>>>>>> the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping to >>>>> be a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so you resort to the lame tactic of ad hominem personal attack.
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are wrong
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on >>>>>>>>>>>> the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping
to be a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so you resort tothe
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
On 10/11/2025 6:37 PM, dbush wrote:In other words, you're unable to understand my explanations why your are
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on >>>>>>>>>>>> the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping
to be a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so you resort tothe
lame tactic of ad hominem personal attack.
I use correctly reasoning and you rebut it
with incorrect reasoning and you do this to
be dishonest.
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are wrong
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report >>>>>>>>>>>>> on the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping >>>>>>> to be a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so you resortto the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
does not make me dishonest.
On 10/11/2025 6:44 PM, dbush wrote:
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are wrong
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report >>>>>>>>>>>>>> on the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping >>>>>>>> to be a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so you resortto the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
does not make me dishonest.
That you refuse to even consider those
aspects that I have correctly proven makes
you dishonest.
On 10/11/2025 9:14 PM, olcott wrote:
On 10/11/2025 6:44 PM, dbush wrote:
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are wrong
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report >>>>>>>>>>>>>>> on the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required
mapping to be a halt decider (see below), it's not a halt decider. >>>>>>>>>
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so you resort >>>>> to the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
does not make me dishonest.
That you refuse to even consider those
aspects that I have correctly proven makes
you dishonest.
That DD halts when executed directly proves that any pattern contained
in DD is *not* a non-halting behavior pattern.
That you fail to understand that is not my mistake.
On 10/11/2025 8:18 PM, dbush wrote:And that recursive simulation is finite, as proven by the fact that DD
On 10/11/2025 9:14 PM, olcott wrote:
On 10/11/2025 6:44 PM, dbush wrote:
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should >>>>>>>>>>>>>>>> report on the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required
mapping to be a halt decider (see below), it's not a halt >>>>>>>>>> decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so youresort to the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
wrong does not make me dishonest.
That you refuse to even consider those
aspects that I have correctly proven makes
you dishonest.
That DD halts when executed directly proves that any pattern contained
in DD is *not* a non-halting behavior pattern.
That you fail to understand that is not my mistake.
DD does specify that it does call HHH(DD)
in recursive simulation.
On 10/11/2025 9:25 PM, olcott wrote:
On 10/11/2025 8:18 PM, dbush wrote:And that recursive simulation is finite, as proven by the fact that DD
On 10/11/2025 9:14 PM, olcott wrote:
On 10/11/2025 6:44 PM, dbush wrote:
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should >>>>>>>>>>>>>>>>> report on the non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required >>>>>>>>>>> mapping to be a halt decider (see below), it's not a halt >>>>>>>>>>> decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so youresort to the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
wrong does not make me dishonest.
That you refuse to even consider those
aspects that I have correctly proven makes
you dishonest.
That DD halts when executed directly proves that any pattern
contained in DD is *not* a non-halting behavior pattern.
That you fail to understand that is not my mistake.
DD does specify that it does call HHH(DD)
in recursive simulation.
halts when executed directly.
On 10/11/2025 8:29 PM, dbush wrote:
On 10/11/2025 9:25 PM, olcott wrote:
On 10/11/2025 8:18 PM, dbush wrote:And that recursive simulation is finite, as proven by the fact that DD
On 10/11/2025 9:14 PM, olcott wrote:
On 10/11/2025 6:44 PM, dbush wrote:
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should >>>>>>>>>>>>>>>>>> report on the non- input DDn.
HHH(DD) must abort its simulation to prevent >>>>>>>>>>>>>>>>> its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required >>>>>>>>>>>> mapping to be a halt decider (see below), it's not a halt >>>>>>>>>>>> decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote:
In other words you could find any error in my post so you >>>>>>>> resort to the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
wrong does not make me dishonest.
That you refuse to even consider those
aspects that I have correctly proven makes
you dishonest.
That DD halts when executed directly proves that any pattern
contained in DD is *not* a non-halting behavior pattern.
That you fail to understand that is not my mistake.
DD does specify that it does call HHH(DD)
in recursive simulation.
halts when executed directly.
OK you are doing better now.
It never has been about the recursion being
finite or being infinite. It has always been
about whether or not HHH(DD) must abort its
simulation to prevent its own non-termination.
On 10/11/2025 10:30 PM, olcott wrote:
On 10/11/2025 8:29 PM, dbush wrote:
On 10/11/2025 9:25 PM, olcott wrote:
On 10/11/2025 8:18 PM, dbush wrote:And that recursive simulation is finite, as proven by the fact that
On 10/11/2025 9:14 PM, olcott wrote:
On 10/11/2025 6:44 PM, dbush wrote:
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are >>>>>>> wrong does not make me dishonest.
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping >>>>>>>>>>>>>>>> Not at all.
Which is exactly why you think that HHH(DD) should >>>>>>>>>>>>>>>>>>> report on the non- input DDn.
HHH(DD) must abort its simulation to prevent >>>>>>>>>>>>>>>>>> its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required >>>>>>>>>>>>> mapping to be a halt decider (see below), it's not a halt >>>>>>>>>>>>> decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote: >>>>>>>>> -a> In other words you could find any error in my post so you >>>>>>>>> resort to the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
That you refuse to even consider those
aspects that I have correctly proven makes
you dishonest.
That DD halts when executed directly proves that any pattern
contained in DD is *not* a non-halting behavior pattern.
That you fail to understand that is not my mistake.
DD does specify that it does call HHH(DD)
in recursive simulation.
DD halts when executed directly.
OK you are doing better now.
It never has been about the recursion being
finite or being infinite. It has always been
about whether or not HHH(DD) must abort its
simulation to prevent its own non-termination.
That works in the non-diagonal cases since changing the code of function
HHH is equivalent to passing the same machine description to algorithm UTM.
In the diagonal cases it does not work that way because changing
function HHH means you change algorithm DD to algorithm DDn and instead report on the non-input DDn.
On 10/11/2025 9:38 PM, dbush wrote:
On 10/11/2025 10:30 PM, olcott wrote:
On 10/11/2025 8:29 PM, dbush wrote:
On 10/11/2025 9:25 PM, olcott wrote:
On 10/11/2025 8:18 PM, dbush wrote:And that recursive simulation is finite, as proven by the fact that
On 10/11/2025 9:14 PM, olcott wrote:
On 10/11/2025 6:44 PM, dbush wrote:
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are >>>>>>>> wrong does not make me dishonest.
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping >>>>>>>>>>>>>>>>> Not at all.
Which is exactly why you think that HHH(DD) should >>>>>>>>>>>>>>>>>>>> report on the non- input DDn.
HHH(DD) must abort its simulation to prevent >>>>>>>>>>>>>>>>>>> its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required >>>>>>>>>>>>>> mapping to be a halt decider (see below), it's not a halt >>>>>>>>>>>>>> decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote: >>>>>>>>>> -a> In other words you could find any error in my post so you >>>>>>>>>> resort to the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
That you refuse to even consider those
aspects that I have correctly proven makes
you dishonest.
That DD halts when executed directly proves that any pattern
contained in DD is *not* a non-halting behavior pattern.
That you fail to understand that is not my mistake.
DD does specify that it does call HHH(DD)
in recursive simulation.
DD halts when executed directly.
OK you are doing better now.
It never has been about the recursion being
finite or being infinite. It has always been
about whether or not HHH(DD) must abort its
simulation to prevent its own non-termination.
That works in the non-diagonal cases since changing the code of
function HHH is equivalent to passing the same machine description to
algorithm UTM.
In the diagonal cases it does not work that way because changing
function HHH means you change algorithm DD to algorithm DDn and
instead report on the non-input DDn.
That only means that you are pretending to be
too dumb to understand this simple notion:
(Which is dishonest unless you actually are too dumb)
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a return 1.
You seem to be stupidly acting like a simulating halt
decider
must always report halts because it always
forces otherwise non-halting inputs to stop running.
On 10/11/2025 10:46 PM, olcott wrote:
On 10/11/2025 9:38 PM, dbush wrote:
On 10/11/2025 10:30 PM, olcott wrote:
On 10/11/2025 8:29 PM, dbush wrote:
On 10/11/2025 9:25 PM, olcott wrote:
On 10/11/2025 8:18 PM, dbush wrote:And that recursive simulation is finite, as proven by the fact that >>>>> DD halts when executed directly.
On 10/11/2025 9:14 PM, olcott wrote:
On 10/11/2025 6:44 PM, dbush wrote:
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your are >>>>>>>>> wrong does not make me dishonest.
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping >>>>>>>>>>>>>>>>>> Not at all.
Which is exactly why you think that HHH(DD) should >>>>>>>>>>>>>>>>>>>>> report on the non- input DDn.
HHH(DD) must abort its simulation to prevent >>>>>>>>>>>>>>>>>>>> its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required >>>>>>>>>>>>>>> mapping to be a halt decider (see below), it's not a halt >>>>>>>>>>>>>>> decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote: >>>>>>>>>>> -a> In other words you could find any error in my post so you >>>>>>>>>>> resort to the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
That you refuse to even consider those
aspects that I have correctly proven makes
you dishonest.
That DD halts when executed directly proves that any pattern
contained in DD is *not* a non-halting behavior pattern.
That you fail to understand that is not my mistake.
DD does specify that it does call HHH(DD)
in recursive simulation.
OK you are doing better now.
It never has been about the recursion being
finite or being infinite. It has always been
about whether or not HHH(DD) must abort its
simulation to prevent its own non-termination.
That works in the non-diagonal cases since changing the code of
function HHH is equivalent to passing the same machine description to
algorithm UTM.
In the diagonal cases it does not work that way because changing
function HHH means you change algorithm DD to algorithm DDn and
instead report on the non-input DDn.
That only means that you are pretending to be
too dumb to understand this simple notion:
(Which is dishonest unless you actually are too dumb)
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
And your HHH doesn't meet the above spec because the pattern it detects exists in the halting computation DD and is therefore *not* a non-
halting behavior pattern.
On 10/11/2025 9:50 PM, dbush wrote:
On 10/11/2025 10:46 PM, olcott wrote:
On 10/11/2025 9:38 PM, dbush wrote:
On 10/11/2025 10:30 PM, olcott wrote:
On 10/11/2025 8:29 PM, dbush wrote:
On 10/11/2025 9:25 PM, olcott wrote:
On 10/11/2025 8:18 PM, dbush wrote:And that recursive simulation is finite, as proven by the fact
On 10/11/2025 9:14 PM, olcott wrote:
On 10/11/2025 6:44 PM, dbush wrote:
On 10/11/2025 7:41 PM, olcott wrote:
On 10/11/2025 6:37 PM, dbush wrote:That you aren't able to understand my explanations why your >>>>>>>>>> are wrong does not make me dishonest.
On 10/11/2025 7:33 PM, olcott wrote:
On 10/11/2025 6:29 PM, dbush wrote:
On 10/11/2025 7:16 PM, olcott wrote:
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:
On 10/11/2025 4:02 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>But it must also compute the required mapping >>>>>>>>>>>>>>>>>>> Not at all.
Which is exactly why you think that HHH(DD) should >>>>>>>>>>>>>>>>>>>>>> report on the non- input DDn.
HHH(DD) must abort its simulation to prevent >>>>>>>>>>>>>>>>>>>>> its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required >>>>>>>>>>>>>>>> mapping to be a halt decider (see below), it's not a >>>>>>>>>>>>>>>> halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
A bad analogy is less than no rebuttal.
You are a jackass.
I'll let you respond to yourself:
On Monday, March 6, 2023 at 3:19:42-aPM UTC-5, olcott wrote: >>>>>>>>>>>> -a> In other words you could find any error in my post so you >>>>>>>>>>>> resort to the
lame tactic of ad hominem personal attack.
You strive to be disagreeable and this makes
you dishonest.
That you refuse to even consider those
aspects that I have correctly proven makes
you dishonest.
That DD halts when executed directly proves that any pattern
contained in DD is *not* a non-halting behavior pattern.
That you fail to understand that is not my mistake.
DD does specify that it does call HHH(DD)
in recursive simulation.
that DD halts when executed directly.
OK you are doing better now.
It never has been about the recursion being
finite or being infinite. It has always been
about whether or not HHH(DD) must abort its
simulation to prevent its own non-termination.
That works in the non-diagonal cases since changing the code of
function HHH is equivalent to passing the same machine description
to algorithm UTM.
In the diagonal cases it does not work that way because changing
function HHH means you change algorithm DD to algorithm DDn and
instead report on the non-input DDn.
That only means that you are pretending to be
too dumb to understand this simple notion:
(Which is dishonest unless you actually are too dumb)
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
And your HHH doesn't meet the above spec because the pattern it
detects exists in the halting computation DD and is therefore *not* a
non- halting behavior pattern.
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
On 10/11/2025 10:55 PM, olcott wrote:>>
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
You're the one repeating previously refuted claims.
If you claim "X", and say "X is wrong because Y", and you later say "but
X is right", I'll again respond with "X is wrong because Y".
That you don't understand that non-halting behaviors patterns don't
exist in halting programs is not my mistake.
On 10/11/2025 9:59 PM, dbush wrote:
On 10/11/2025 10:55 PM, olcott wrote:>>void Infinite_Loop()
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
You're the one repeating previously refuted claims.
If you claim "X", and say "X is wrong because Y", and you later say
"but X is right", I'll again respond with "X is wrong because Y".
That you don't understand that non-halting behaviors patterns don't
exist in halting programs is not my mistake.
{
-a HERE: goto HERE;
-a return;
}
You are so stupidly acting like the input to
HHH(Infinite_Loop)
specifies a halting computation
On 10/11/2025 11:13 PM, olcott wrote:
On 10/11/2025 9:59 PM, dbush wrote:
On 10/11/2025 10:55 PM, olcott wrote:>>void Infinite_Loop()
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
You're the one repeating previously refuted claims.
If you claim "X", and say "X is wrong because Y", and you later say
"but X is right", I'll again respond with "X is wrong because Y".
That you don't understand that non-halting behaviors patterns don't
exist in halting programs is not my mistake.
{
-a-a HERE: goto HERE;
-a-a return;
}
You are so stupidly acting like the input to
HHH(Infinite_Loop)
i.e. finite string Infinite_Loop which is the description of algorithm Infinite_Loop which does not halt when executed directly
specifies a halting computation
No, we know that a non-halting behavior pattern (that matches some cases
but not all) exists in algorithm Infinite_Loop because it does not halt
when executed directly.
We know that a non-halting behavior pattern *does not* exist in
algorithm DD because it halts when executed directly.
On 10/11/2025 10:23 PM, dbush wrote:
On 10/11/2025 11:13 PM, olcott wrote:
On 10/11/2025 9:59 PM, dbush wrote:
On 10/11/2025 10:55 PM, olcott wrote:>>void Infinite_Loop()
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
You're the one repeating previously refuted claims.
If you claim "X", and say "X is wrong because Y", and you later say
"but X is right", I'll again respond with "X is wrong because Y".
That you don't understand that non-halting behaviors patterns don't
exist in halting programs is not my mistake.
{
-a-a HERE: goto HERE;
-a-a return;
}
You are so stupidly acting like the input to
HHH(Infinite_Loop)
i.e. finite string Infinite_Loop which is the description of algorithm
Infinite_Loop which does not halt when executed directly
specifies a halting computation
No, we know that a non-halting behavior pattern (that matches some
cases but not all) exists in algorithm Infinite_Loop because it does
not halt when executed directly.
We know that a non-halting behavior pattern *does not* exist in
algorithm DD because it halts when executed directly.
Yet that answer is not according to the actual
behavior that *THE INPUT ITSELF* to HHH(DD)
actually specifies
it is the behavior of a
non-input that is misconstrued as an input.
Any idiot knows the the executed process of
the caller of HHH(DD) cannot be exactly
one-and-the-same-thing as its argument.
On 10/11/2025 11:34 PM, olcott wrote:
On 10/11/2025 10:23 PM, dbush wrote:
On 10/11/2025 11:13 PM, olcott wrote:
On 10/11/2025 9:59 PM, dbush wrote:
On 10/11/2025 10:55 PM, olcott wrote:>>void Infinite_Loop()
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
You're the one repeating previously refuted claims.
If you claim "X", and say "X is wrong because Y", and you later say >>>>> "but X is right", I'll again respond with "X is wrong because Y".
That you don't understand that non-halting behaviors patterns don't >>>>> exist in halting programs is not my mistake.
{
-a-a HERE: goto HERE;
-a-a return;
}
You are so stupidly acting like the input to
HHH(Infinite_Loop)
i.e. finite string Infinite_Loop which is the description of
algorithm Infinite_Loop which does not halt when executed directly
specifies a halting computation
No, we know that a non-halting behavior pattern (that matches some
cases but not all) exists in algorithm Infinite_Loop because it does
not halt when executed directly.
We know that a non-halting behavior pattern *does not* exist in
algorithm DD because it halts when executed directly.
Yet that answer is not according to the actual
behavior that *THE INPUT ITSELF* to HHH(DD)
i.e. finite string DD, which is a description of machine DD and is
specified to possess all semantic properties of machine DD, including
the fact that it halts when executed directly.
actually specifies
False, see above.
it is the behavior of a
non-input that is misconstrued as an input.
No, you're the one claiming that HHH(DD) must report on the non-input DDn
Any idiot knows the the executed process of
the caller of HHH(DD) cannot be exactly
one-and-the-same-thing as its argument.
But since Turing machines always have exactly the same behavior for a
given input,
we can ask about the hypothetical case when machine DD is
executed directly, not necessarily "now", by giving it the finite string description of machine DD which is specified to possess all semantic properties of machine DD including the fact that it halts when executed directly.
On 10/11/2025 10:42 PM, dbush wrote:
On 10/11/2025 11:34 PM, olcott wrote:
On 10/11/2025 10:23 PM, dbush wrote:
On 10/11/2025 11:13 PM, olcott wrote:
On 10/11/2025 9:59 PM, dbush wrote:
On 10/11/2025 10:55 PM, olcott wrote:>>void Infinite_Loop()
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
You're the one repeating previously refuted claims.
If you claim "X", and say "X is wrong because Y", and you later
say "but X is right", I'll again respond with "X is wrong because Y". >>>>>>
That you don't understand that non-halting behaviors patterns
don't exist in halting programs is not my mistake.
{
-a-a HERE: goto HERE;
-a-a return;
}
You are so stupidly acting like the input to
HHH(Infinite_Loop)
i.e. finite string Infinite_Loop which is the description of
algorithm Infinite_Loop which does not halt when executed directly
specifies a halting computation
No, we know that a non-halting behavior pattern (that matches some
cases but not all) exists in algorithm Infinite_Loop because it does
not halt when executed directly.
We know that a non-halting behavior pattern *does not* exist in
algorithm DD because it halts when executed directly.
Yet that answer is not according to the actual
behavior that *THE INPUT ITSELF* to HHH(DD)
i.e. finite string DD, which is a description of machine DD and is
specified to possess all semantic properties of machine DD, including
the fact that it halts when executed directly.
actually specifies
False, see above.
it is the behavior of a
non-input that is misconstrued as an input.
No, you're the one claiming that HHH(DD) must report on the non-input DDn
How the Hell did you get that?
HHH(DD) is reporting on the otherwise unlimited
recursive simulation that its actual finite string
of x86 machine code specifies.
Any idiot knows the the executed process of
the caller of HHH(DD) cannot be exactly
one-and-the-same-thing as its argument.
But since Turing machines always have exactly the same behavior for a
given input,
I don't think that is literally true.
Computable functions
are required to have
exactly the same behavior for the same input.
HHH does have exactly the same behavior for the
same input. DD is not a computable function.
https://en.wikipedia.org/wiki/Computable_function
we can ask about the hypothetical case when machine DD is executed
directly, not necessarily "now", by giving it the finite string
description of machine DD which is specified to possess all semantic
properties of machine DD including the fact that it halts when
executed directly.
That is not the actual behavior of the actual input
as measured by the simulation of DD by HHH according
to the semantics of its language,
the ultimate measure
of correct simulation.
On 10/11/2025 11:51 PM, olcott wrote:
On 10/11/2025 10:42 PM, dbush wrote:
On 10/11/2025 11:34 PM, olcott wrote:
On 10/11/2025 10:23 PM, dbush wrote:
On 10/11/2025 11:13 PM, olcott wrote:
On 10/11/2025 9:59 PM, dbush wrote:
On 10/11/2025 10:55 PM, olcott wrote:>>void Infinite_Loop()
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
You're the one repeating previously refuted claims.
If you claim "X", and say "X is wrong because Y", and you later >>>>>>> say "but X is right", I'll again respond with "X is wrong because >>>>>>> Y".
That you don't understand that non-halting behaviors patterns
don't exist in halting programs is not my mistake.
{
-a-a HERE: goto HERE;
-a-a return;
}
You are so stupidly acting like the input to
HHH(Infinite_Loop)
i.e. finite string Infinite_Loop which is the description of
algorithm Infinite_Loop which does not halt when executed directly
specifies a halting computation
No, we know that a non-halting behavior pattern (that matches some
cases but not all) exists in algorithm Infinite_Loop because it
does not halt when executed directly.
We know that a non-halting behavior pattern *does not* exist in
algorithm DD because it halts when executed directly.
Yet that answer is not according to the actual
behavior that *THE INPUT ITSELF* to HHH(DD)
i.e. finite string DD, which is a description of machine DD and is
specified to possess all semantic properties of machine DD, including
the fact that it halts when executed directly.
actually specifies
False, see above.
it is the behavior of a
non-input that is misconstrued as an input.
No, you're the one claiming that HHH(DD) must report on the non-input
DDn
How the Hell did you get that?
HHH(DD) is reporting on the otherwise unlimited
recursive simulation that its actual finite string
of x86 machine code specifies.
In other words, you imagine changing the code of function HHH to not
abort, resulting in you now having algorithms HHHn and DDn and reporting
on the behavior of the non-input algorithm DDn.
Any idiot knows the the executed process of
the caller of HHH(DD) cannot be exactly
one-and-the-same-thing as its argument.
But since Turing machines always have exactly the same behavior for a
given input,
I don't think that is literally true.
Yes.-a It is true by the meaning of the words.-a If not, you could provide
a Turing machine X such that X(Y) behaves differently at different times.
You're just demonstrating that you don't even understand the basics of
the field you're making grand claims about.
Computable functions
i.e. mathematical mappings for which an algorithm exists to compute them
are required to have
exactly the same behavior for the same input.
Mathematical mappings don't have behavior.-a They simply associate inputs
to outputs.
HHH does have exactly the same behavior for the
same input. DD is not a computable function.
Category error: C functions aren't mathematical mappings.
Algorithm DD
*computes* some computable function.
And the input to algorithm DD is
an execution trace
which it also gives to HHH as an input, so HHH is
therefore DISQUALIFIED from being a halting decider.
https://en.wikipedia.org/wiki/Computable_function
we can ask about the hypothetical case when machine DD is executed
directly, not necessarily "now", by giving it the finite string
description of machine DD which is specified to possess all semantic
properties of machine DD including the fact that it halts when
executed directly.
That is not the actual behavior of the actual input
i.e. finite string DD, which is a description of machine DD and is
specified to possess all semantic properties of machine DD, including
the fact that it halts when executed directly.
as measured by the simulation of DD by HHH according
to the semantics of its language,
But HHH aborts in violation of the x86 language, therefore you have no measure.
the ultimate measure
of correct simulation.
False.-a It is a semantic tautology that the ultimate measure of correct simulation is that it exactly matches the behavior of the machine it is simulating.
On 10/11/2025 5:20 PM, dbush wrote:
On 10/11/2025 6:10 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:Then HHH is not a halt decider.
On 10/11/2025 5:26 PM, olcott wrote:Not at all.
On 10/11/2025 4:02 PM, dbush wrote:But it must also compute the required mapping
Which is exactly why you think that HHH(DD) should report on the >>>>>>>> non- input DDn.
HHH(DD) must abort its simulation to prevent
its own non-termination.
HHH(DD) only has the priority of preventing
its own non-termination.
And since it can't do that and also perform the required mapping to be
a halt decider (see below), it's not a halt decider.
Is 5 an integer?
No 5 is not an integer and a box of chocolates.
On 10/11/2025 4:43 AM, Mikko wrote:
On 2025-10-10 16:16:21 +0000, olcott said:
On 10/10/2025 3:15 AM, Mikko wrote:
On 2025-10-09 17:32:08 +0000, olcott said:
On 10/9/2025 4:57 AM, Mikko wrote:
On 2025-10-09 04:00:35 +0000, olcott said:
On 10/8/2025 4:52 AM, Mikko wrote:
On 2025-10-07 14:32:35 +0000, olcott said:
On 10/7/2025 3:49 AM, Mikko wrote:
On 2025-10-07 00:18:52 +0000, olcott said:
On 10/6/2025 4:11 AM, Mikko wrote:
On 2025-10-05 13:51:53 +0000, olcott said:
On 10/5/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-10-05, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> It is unreasonable to construe any logical
impossibility as an actual limitation.
That could practically be your motto.
A birthday case is limited in that it cannot land an >>>>>>>>>>>>> airliner. An actual hamburger patty is also limited
in that it cannot get elected to the US senate.
Both birthday cakes and hamburger patties are much more limited >>>>>>>>>>>> that that. In paticular, we want that they are edible.
Yes and Turing machines do not have psychic
ability to report on behaviors that they cannot
see. The best that they can do is an execution
trace of the behavior that the input specifies
that sometimes includes the input calling its
own decider in recursive simulation.
Turns out that the best they can do is enouth to construct >>>>>>>>>> a universal Turing machine but not enough to construct a
halt decider.
If you want to find out how much Bill weighs
you will not get this by weigh his little sister.
You will only get this by weighing Bill.
Or something that is known to weight the same as Bill,
or something whose weight has a known ratio to Bill's
weight.
If you want to find out if an input finite string
specifies the semantic property of halting you must
test this actual input finite string.
Or something that is known to have some determinable feature if >>>>>>>> and only if the string asked about has the semantic property of >>>>>>>> halting.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Above, unlike the original, does not define or require or claim >>>>>>>> anuthing. Besides, the original does not say "unless aborted".
The above is the Linz proof construed with my
unique idea of a simulating halt decider. I assume
that you know what a simulating halt decider is by now.
The above is not a proof. A proof is a sequence of claims. The
above is not.
The first step of my proof is getting you
to totally understand the above.
What has that as the first step is not a proof.
The first step of any proof is the definition of the terms
The term [semantic property of finite string input]
We don't need the general definition of "semantic property of finite
string input" when the discussion is restricted to halting, which is
just one property.
Yes we do. In is incorrect to require halt deciders
to do things that no decider can ever do.
On 10/11/2025 11:08 PM, dbush wrote:
On 10/11/2025 11:51 PM, olcott wrote:
On 10/11/2025 10:42 PM, dbush wrote:
On 10/11/2025 11:34 PM, olcott wrote:
On 10/11/2025 10:23 PM, dbush wrote:
On 10/11/2025 11:13 PM, olcott wrote:
On 10/11/2025 9:59 PM, dbush wrote:
On 10/11/2025 10:55 PM, olcott wrote:>>void Infinite_Loop()
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
You're the one repeating previously refuted claims.
If you claim "X", and say "X is wrong because Y", and you later >>>>>>>> say "but X is right", I'll again respond with "X is wrong
because Y".
That you don't understand that non-halting behaviors patterns >>>>>>>> don't exist in halting programs is not my mistake.
{
-a-a HERE: goto HERE;
-a-a return;
}
You are so stupidly acting like the input to
HHH(Infinite_Loop)
i.e. finite string Infinite_Loop which is the description of
algorithm Infinite_Loop which does not halt when executed directly >>>>>>
specifies a halting computation
No, we know that a non-halting behavior pattern (that matches some >>>>>> cases but not all) exists in algorithm Infinite_Loop because it
does not halt when executed directly.
We know that a non-halting behavior pattern *does not* exist in
algorithm DD because it halts when executed directly.
Yet that answer is not according to the actual
behavior that *THE INPUT ITSELF* to HHH(DD)
i.e. finite string DD, which is a description of machine DD and is
specified to possess all semantic properties of machine DD,
including the fact that it halts when executed directly.
actually specifies
False, see above.
it is the behavior of a
non-input that is misconstrued as an input.
No, you're the one claiming that HHH(DD) must report on the non-
input DDn
How the Hell did you get that?
HHH(DD) is reporting on the otherwise unlimited
recursive simulation that its actual finite string
of x86 machine code specifies.
In other words, you imagine changing the code of function HHH to not
abort, resulting in you now having algorithms HHHn and DDn and
reporting on the behavior of the non-input algorithm DDn.
Not at all, its a freaking "if" statement.
Any idiot knows the the executed process of
the caller of HHH(DD) cannot be exactly
one-and-the-same-thing as its argument.
But since Turing machines always have exactly the same behavior for
a given input,
I don't think that is literally true.
Yes.-a It is true by the meaning of the words.-a If not, you could
provide a Turing machine X such that X(Y) behaves differently at
different times.
UTM1(D) specifies a different sequence of moves than
UTM2(D) because D has UTM1 embedded within it and does
not have UTM2 embedded within it.
On 6/4/2025 4:20 AM, Fred. Zwarts wrote:simulated did that?
That did not answer the question: WHAT INSTRUCTION, correctly
When HHH1(DDD) simulates DDD it never simulates itself.two simulators.
When HHH(DDD) simulates DDD then simulates itself simulating
DDD the first instruction that this simulated HHH simulates
diverges from the simulation that HHH1 did.
You cannot point to any instruction interpreted differently by the
There are no instructions interpreted differently.
You're just demonstrating that you don't even understand the basics of
the field you're making grand claims about.
Computable functions
i.e. mathematical mappings for which an algorithm exists to compute them
are required to have
exactly the same behavior for the same input.
Mathematical mappings don't have behavior.-a They simply associate
inputs to outputs.
Yes.
The algorithm computes the mapping from its finite string input
HHH does have exactly the same behavior for the
same input. DD is not a computable function.
Category error: C functions aren't mathematical mappings.
C functions that are a pure function of their inputs
do compute mappings from their inputs.
-aAlgorithm DD *computes* some computable function.
pretty good trick to make it a pure function of the empty string.
And the input to algorithm DD is
the empty string.
an execution trace
nope it is the empty string.
which it also gives to HHH as an input, so HHH is therefore
DISQUALIFIED from being a halting decider.
https://en.wikipedia.org/wiki/Computable_function
we can ask about the hypothetical case when machine DD is executed
directly, not necessarily "now", by giving it the finite string
description of machine DD which is specified to possess all semantic
properties of machine DD including the fact that it halts when
executed directly.
That is not the actual behavior of the actual input
i.e. finite string DD, which is a description of machine DD and is
specified to possess all semantic properties of machine DD, including
the fact that it halts when executed directly.
It also specifies that it calls HHH(DD).
as measured by the simulation of DD by HHH according
to the semantics of its language,
But HHH aborts in violation of the x86 language, therefore you have no
measure.
Nope knuckle head you are incorrect.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a return 1.
the ultimate measure
of correct simulation.
False.-a It is a semantic tautology that the ultimate measure of
correct simulation is that it exactly matches the behavior of the
machine it is simulating.
Not when the violates the semantics of its language.
On 10/12/2025 12:28 AM, olcott wrote:
On 10/11/2025 11:08 PM, dbush wrote:
On 10/11/2025 11:51 PM, olcott wrote:
On 10/11/2025 10:42 PM, dbush wrote:
On 10/11/2025 11:34 PM, olcott wrote:
On 10/11/2025 10:23 PM, dbush wrote:
On 10/11/2025 11:13 PM, olcott wrote:
On 10/11/2025 9:59 PM, dbush wrote:
On 10/11/2025 10:55 PM, olcott wrote:>>void Infinite_Loop()
I get it you are an actual Chatbot that has
a very small token limit so you can't even
remember what I said three posts ago.
You're the one repeating previously refuted claims.
If you claim "X", and say "X is wrong because Y", and you later >>>>>>>>> say "but X is right", I'll again respond with "X is wrong
because Y".
That you don't understand that non-halting behaviors patterns >>>>>>>>> don't exist in halting programs is not my mistake.
{
-a-a HERE: goto HERE;
-a-a return;
}
You are so stupidly acting like the input to
HHH(Infinite_Loop)
i.e. finite string Infinite_Loop which is the description of
algorithm Infinite_Loop which does not halt when executed directly >>>>>>>
specifies a halting computation
No, we know that a non-halting behavior pattern (that matches
some cases but not all) exists in algorithm Infinite_Loop because >>>>>>> it does not halt when executed directly.
We know that a non-halting behavior pattern *does not* exist in >>>>>>> algorithm DD because it halts when executed directly.
Yet that answer is not according to the actual
behavior that *THE INPUT ITSELF* to HHH(DD)
i.e. finite string DD, which is a description of machine DD and is
specified to possess all semantic properties of machine DD,
including the fact that it halts when executed directly.
actually specifies
False, see above.
it is the behavior of a
non-input that is misconstrued as an input.
No, you're the one claiming that HHH(DD) must report on the non-
input DDn
How the Hell did you get that?
HHH(DD) is reporting on the otherwise unlimited
recursive simulation that its actual finite string
of x86 machine code specifies.
In other words, you imagine changing the code of function HHH to not
abort, resulting in you now having algorithms HHHn and DDn and
reporting on the behavior of the non-input algorithm DDn.
Not at all, its a freaking "if" statement.
Right, you saying that if DD was instead DDn that DDn would not halt,
i.e. you're reporting on a non-input.
Any idiot knows the the executed process of
the caller of HHH(DD) cannot be exactly
one-and-the-same-thing as its argument.
But since Turing machines always have exactly the same behavior for >>>>> a given input,
I don't think that is literally true.
Yes.-a It is true by the meaning of the words.-a If not, you could
provide a Turing machine X such that X(Y) behaves differently at
different times.
UTM1(D) specifies a different sequence of moves than
UTM2(D) because D has UTM1 embedded within it and does
not have UTM2 embedded within it.
1) that's not directly executed, so irrelevant
2) you admitted on the record that they are the same:
On 6/4/2025 12:38 PM, olcott wrote:
On 6/4/2025 4:20 AM, Fred. Zwarts wrote:simulated did that?
That did not answer the question: WHAT INSTRUCTION, correctly
When HHH1(DDD) simulates DDD it never simulates itself.
When HHH(DDD) simulates DDD then simulates itself simulating
DDD the first instruction that this simulated HHH simulates
diverges from the simulation that HHH1 did.
two simulators.You cannot point to any instruction interpreted differently by the
There are no instructions interpreted differently.
You're just demonstrating that you don't even understand the basics
of the field you're making grand claims about.
Computable functions
i.e. mathematical mappings for which an algorithm exists to compute them >>>
are required to have
exactly the same behavior for the same input.
Mathematical mappings don't have behavior.-a They simply associate
inputs to outputs.
Yes.
The algorithm computes the mapping from its finite string input
HHH does have exactly the same behavior for the
same input. DD is not a computable function.
Category error: C functions aren't mathematical mappings.
C functions that are a pure function of their inputs
do compute mappings from their inputs.
Yes, that's what I said below.
-aAlgorithm DD *computes* some computable function.
pretty good trick to make it a pure function of the empty string.
Nope, see below
And the input to algorithm DD is
the empty string.
Nope, see below
an execution trace
nope it is the empty string.
False, because DD behaves differently when the execution trace is empty compared to when it's not empty.-a Just because function DD doesn't take arguments doesn't mean algorithm DD doesn't have inputs.
which it also gives to HHH as an input, so HHH is therefore
DISQUALIFIED from being a halting decider.
https://en.wikipedia.org/wiki/Computable_function
we can ask about the hypothetical case when machine DD is executed
directly, not necessarily "now", by giving it the finite string
description of machine DD which is specified to possess all
semantic properties of machine DD including the fact that it halts
when executed directly.
That is not the actual behavior of the actual input
i.e. finite string DD, which is a description of machine DD and is
specified to possess all semantic properties of machine DD, including
the fact that it halts when executed directly.
It also specifies that it calls HHH(DD).
Which returns 0 when DD is executed directly.
as measured by the simulation of DD by HHH according
to the semantics of its language,
But HHH aborts in violation of the x86 language, therefore you have
no measure.
Nope knuckle head you are incorrect.
Then show where in the Intel instruction manual that the execution of
any instruction other than a HLT is allowed to stop instead of
executing the next instruction.
Failure to do so in your next reply, or within one hour of your next
post on this newsgroup, will be taken as you official on-the-record
admission that there is no such allowance and that HHH does NOT
correctly simulate DD and in fact violates the x86 language.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
And your HHH doesn't meet the above spec because the pattern it detects exists in the computation DD which halts when executed directly and is therefore *not* a non- halting behavior pattern.
On 10/12/2025 7:43 AM, dbush wrote:
On 10/12/2025 12:28 AM, olcott wrote:
On 10/11/2025 11:08 PM, dbush wrote:
But HHH aborts in violation of the x86 language, therefore you have
no measure.
Nope knuckle head you are incorrect.
Then show where in the Intel instruction manual that the execution of
any instruction other than a HLT is allowed to stop instead of
executing the next instruction.
Failure to do so in your next reply, or within one hour of your next
post on this newsgroup, will be taken as you official on-the-record
admission that there is no such allowance and that HHH does NOT
correctly simulate DD and in fact violates the x86 language.
--- Synchronet 3.21a-Linux NewsLink 1.2I updated this.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
And your HHH doesn't meet the above spec because the pattern it
detects exists in the computation DD which halts when executed
directly and is therefore *not* a non- halting behavior pattern.
On 2025-10-11 13:19:09 +0000, olcott said:
On 10/11/2025 4:43 AM, Mikko wrote:
We don't need the general definition of "semantic property of finite
string input" when the discussion is restricted to halting, which is
just one property.
Yes we do. In is incorrect to require halt deciders
to do things that no decider can ever do.
No, it is not incorrect. The purpose of the definition is to specify
what the term "halt decider" means so that it is possible to deremine
of any Turing machine whether it is a halt decider, and the definition satisfies that purpose.
On 10/11/2025 3:40 PM, dbush wrote:
On 10/11/2025 4:36 PM, olcott wrote:
On 10/11/2025 3:24 PM, dbush wrote:
On 10/11/2025 1:08 PM, olcott wrote:
On 10/11/2025 12:06 PM, joes wrote:
Am Sat, 11 Oct 2025 11:44:05 -0500 schrieb olcott:
On 10/11/2025 11:41 AM, joes wrote:
Am Sat, 11 Oct 2025 10:38:59 -0500 schrieb olcott:
On 10/11/2025 10:06 AM, joes wrote:
Am Sat, 11 Oct 2025 09:57:47 -0500 schrieb olcott:
On 10/11/2025 9:30 AM, joes wrote:
Am Sat, 11 Oct 2025 08:24:05 -0500 schrieb olcott:
It is only because you deliberately use the strawman error in an >>>>>>> intentionally deceiving way that to attempt to fool others intoHonestly, I donrCOt know where you get the idea that HHH doesnrCOt >>>>>>>> return.The input to HHH(DD) specifies that DD calls HHH(DD) in >>>>>>>>>>>>> recursiveNo, DD does not specify that. It calls HHH which aborts. >>>>>>>>>>> You keep confusing the directly executed DD with the correctly >>>>>>>>>>> simulated input DD are you making this mistake on purpose? >>>>>>>>>>>
simulation, such that the call from the simulated DD to the >>>>>>>>>>>>> simulated HHH(DD) cannot possibly return. *This cannot be >>>>>>>>>>>>> correctly ignored*
The input to HHH1(DD) specifies that the call from the >>>>>>>>>>>>> simulatedNo, this is the same input.
DD to the simulated HHH(DD) does return.
ItrCOs not a mistake. We have the program DD which calls HHH which >>>>>>>>>> aborts.
We encode that program and pass it to HHH. HHH then simulates DD >>>>>>>>>> calling an aborting simulator. The input is the encoding of >>>>>>>>>> DD, not
that of DD_UTM.
*OK then it is dishonestly*
The input to HHH(DD) specifies that DD calls HHH(DD) in recursive >>>>>>>>> simulation, such that the call from the simulated DD to the >>>>>>>>> simulated
HHH(DD) cannot possibly return. *This cannot be correctly ignored* >>>>>>>>
You specifically coded it that way. DD specifies a call to it, >>>>>>>> therefore DD returns.
believing that the simulated instance of HHH(DD) that simulated >>>>>>> DD calls
ever returns.
*What* is only because of that? What is the strawman? HHH aborting >>>>>> doesnrCOt make DD non-halting. You know that DD halts. That can only >>>>>> be possible if HHH halts.
This is met and you lie about it.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
This is *not* met because the pattern that HHH detects exists in the
halting computation DD and therefore is *not* a non-terminating
behavior pattern.
The pattern does exist in the input.
Proven false by the fact that DD halts.
The DD directly executed process called from
main that calls HHH cannot possibly be an
argument to the function HHH.
You never did confirm your programming expertise
so now it seems that you confirmed your expertise
is zilch.
On 10/11/2025 11:08 PM, dbush wrote:
On 10/11/2025 11:51 PM, olcott wrote:
On 10/11/2025 10:42 PM, dbush wrote:
On 10/11/2025 11:34 PM, olcott wrote:
On 10/11/2025 10:23 PM, dbush wrote:
We know that a non-halting behavior pattern *does not* exist in
algorithm DD because it halts when executed directly.
Yet that answer is not according to the actual behavior that *THE
INPUT ITSELF* to HHH(DD)
The code of DD rCRspecifiesrCY finite recursion. What are you talking about.HHH(DD) is reporting on the otherwise unlimited recursive simulationit is the behavior of a non-input that is misconstrued as an input.No, you're the one claiming that HHH(DD) must report on the non-input
DDn
that its actual finite string of x86 machine code specifies.
Exactly, if the input DD were actually DDn.In other words, you imagine changing the code of function HHH to notNot at all, its a freaking "if" statement.
abort, resulting in you now having algorithms HHHn and DDn and
reporting on the behavior of the non-input algorithm DDn.
WDYM with a simulator specifies? All UTMs are equal. HHH is not a UTM.UTM1(D) specifies a different sequence of moves than UTM2(D) because DYes.-a It is true by the meaning of the words.-a If not, you couldBut since Turing machines always have exactly the same behavior for aI don't think that is literally true.
given input,
provide a Turing machine X such that X(Y) behaves differently at
different times.
has UTM1 embedded within it and does not have UTM2 embedded within it.
HHH does not compute the mapping from DD to its halt status.Yes. The algorithm computes the mapping from its finite string inputComputable functionsi.e. mathematical mappings for which an algorithm exists to compute
them
are required to have exactly the same behavior for the same input.Mathematical mappings don't have behavior.-a They simply associate
inputs to outputs.
HHH is not pure. DD is computable, as evidenced by running it.C functions that are a pure function of their inputs do compute mappingsHHH does have exactly the same behavior for the same input. DD is notCategory error: C functions aren't mathematical mappings.
a computable function.
from their inputs.
Algorithm DD *computes* some computable function.pretty good trick to make it a pure function of the empty string.
And the input to algorithm DD isthe empty string.
an execution tracenope it is the empty string.
Is the rCRactual behaviourrCY whatever the simulator simulates?which it also gives to HHH as an input, so HHH is therefore
DISQUALIFIED from being a halting decider.
we can ask about the hypothetical case when machine DD is executedThat is not the actual behavior of the actual input
directly, not necessarily "now", by giving it the finite string
description of machine DD which is specified to possess all semantic
properties of machine DD including the fact that it halts when
executed directly.
Which aborts after a finite number of recursive simulations, noti.e. finite string DD, which is a description of machine DD and isIt also specifies that it calls HHH(DD).
specified to possess all semantic properties of machine DD, including
the fact that it halts when executed directly.
x86 does not allow arbitrarily stopping execution.Nope knuckle head you are incorrect.as measured by the simulation of DD by HHH according to the semanticsBut HHH aborts in violation of the x86 language, therefore you have no
of its language,
measure.
Such as not continuing to simulate. Or what is the violation?False.-a It is a semantic tautology that the ultimate measure of correctNot when the violates the semantics of its language.
simulation is that it exactly matches the behavior of the machine it is
simulating.
On 10/11/2025 8:29 PM, dbush wrote:Whether a program halts is very much about (in)finity.
On 10/11/2025 9:25 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:
On 10/11/2025 5:26 PM, olcott wrote:
Then HHH is not a halt decider.Not at all.HHH(DD) must abort its simulation to prevent its own >>>>>>>>>>>>>>>>> non-termination.But it must also compute the required mapping
It never has been about the recursion being finite or being infinite. ItDD does specify that it does call HHH(DD)And that recursive simulation is finite, as proven by the fact that DD
in recursive simulation.
halts when executed directly.
has always been about whether or not HHH(DD) must abort its simulation
to prevent its own non-termination.
On 10/12/2025 4:46 AM, Mikko wrote:
On 2025-10-11 13:19:09 +0000, olcott said:
On 10/11/2025 4:43 AM, Mikko wrote:
We don't need the general definition of "semantic property of finite
string input" when the discussion is restricted to halting, which is
just one property.
Yes we do. In is incorrect to require halt deciders
to do things that no decider can ever do.
No, it is not incorrect. The purpose of the definition is to specify
what the term "halt decider" means so that it is possible to deremine
of any Turing machine whether it is a halt decider, and the definition
satisfies that purpose.
All logical impossibilities are exactly equally
logically impossible no matter what the reason
is for them being logically impossible.
It is exactly equally logically impossible for
a halt decider to report the correct halt status
of an input that does the opposite of whatever
it says as it is for the purely mental object of
a Turing machine to give birth to a real live
fifteen story office building.
Am Sat, 11 Oct 2025 23:28:06 -0500 schrieb olcott:
On 10/11/2025 11:08 PM, dbush wrote:
On 10/11/2025 11:51 PM, olcott wrote:
On 10/11/2025 10:42 PM, dbush wrote:
On 10/11/2025 11:34 PM, olcott wrote:
On 10/11/2025 10:23 PM, dbush wrote:
We know that a non-halting behavior pattern *does not* exist in
algorithm DD because it halts when executed directly.
Yet that answer is not according to the actual behavior that *THE
INPUT ITSELF* to HHH(DD)
The input, as imagined by you to be distinct from the program, does not
have any behaviour of its own. You are referring entirely to HHHrCOs simulation of it, which depends on how it chooses to simulate it.
HHH(DD) is reporting on the otherwise unlimited recursive simulationit is the behavior of a non-input that is misconstrued as an input. >>>>> No, you're the one claiming that HHH(DD) must report on the non-input >>>>> DDn
that its actual finite string of x86 machine code specifies.
The code of DD rCRspecifiesrCY finite recursion. What are you talking about.
Exactly, if the input DD were actually DDn.In other words, you imagine changing the code of function HHH to notNot at all, its a freaking "if" statement.
abort, resulting in you now having algorithms HHHn and DDn and
reporting on the behavior of the non-input algorithm DDn.
WDYM with a simulator specifies? All UTMs are equal. HHH is not a UTM.UTM1(D) specifies a different sequence of moves than UTM2(D) because DYes.-a It is true by the meaning of the words.-a If not, you couldBut since Turing machines always have exactly the same behavior for a >>>>> given input,I don't think that is literally true.
provide a Turing machine X such that X(Y) behaves differently at
different times.
has UTM1 embedded within it and does not have UTM2 embedded within it.
HHH certainly diverges from the trace produced by direct execution.
HHH does not compute the mapping from DD to its halt status.Yes. The algorithm computes the mapping from its finite string inputComputable functionsi.e. mathematical mappings for which an algorithm exists to compute
them
are required to have exactly the same behavior for the same input.Mathematical mappings don't have behavior.-a They simply associate
inputs to outputs.
HHH is not pure. DD is computable, as evidenced by running it.C functions that are a pure function of their inputs do compute mappingsHHH does have exactly the same behavior for the same input. DD is notCategory error: C functions aren't mathematical mappings.
a computable function.
from their inputs.
Algorithm DD *computes* some computable function.pretty good trick to make it a pure function of the empty string.
And the input to algorithm DD isthe empty string.
an execution tracenope it is the empty string.
DD relies on global data.
which it also gives to HHH as an input, so HHH is therefore
DISQUALIFIED from being a halting decider.
Is the rCRactual behaviourrCY whatever the simulator simulates?we can ask about the hypothetical case when machine DD is executedThat is not the actual behavior of the actual input
directly, not necessarily "now", by giving it the finite string
description of machine DD which is specified to possess all semantic >>>>> properties of machine DD including the fact that it halts when
executed directly.
Which aborts after a finite number of recursive simulations, noti.e. finite string DD, which is a description of machine DD and isIt also specifies that it calls HHH(DD).
specified to possess all semantic properties of machine DD, including
the fact that it halts when executed directly.
running forever.
x86 does not allow arbitrarily stopping execution.Nope knuckle head you are incorrect.as measured by the simulation of DD by HHH according to the semanticsBut HHH aborts in violation of the x86 language, therefore you have no
of its language,
measure.
Such as not continuing to simulate. Or what is the violation?False.-a It is a semantic tautology that the ultimate measure of correct >>> simulation is that it exactly matches the behavior of the machine it isNot when the violates the semantics of its language.
simulating.
Am Sat, 11 Oct 2025 21:30:19 -0500 schrieb olcott:
On 10/11/2025 8:29 PM, dbush wrote:
On 10/11/2025 9:25 PM, olcott wrote:
On 10/11/2025 4:54 PM, dbush wrote:
On 10/11/2025 5:49 PM, olcott wrote:
On 10/11/2025 4:31 PM, dbush wrote:
On 10/11/2025 5:26 PM, olcott wrote:
Then HHH is not a halt decider.HHH(DD) must abort its simulation to prevent its own >>>>>>>>>>>>>>>>>> non-termination.But it must also compute the required mapping >>>>>>>>>>>>>>>> Not at all.
It never has been about the recursion being finite or being infinite. ItDD does specify that it does call HHH(DD)And that recursive simulation is finite, as proven by the fact that DD
in recursive simulation.
halts when executed directly.
has always been about whether or not HHH(DD) must abort its simulation
to prevent its own non-termination.
Whether a program halts is very much about (in)finity.
HHH would not need to abort DD, but it does. If it were HHHrCO that didnrCOt, DD wouldnrCOt be its diagonal program, and it would simulate it to its termination without aborting. Now HHHrCO *wouldnrCOt* terminate on input DDrCO,
its diagonal program built on itself, but that is not DD. There is no
point in talking about hypothetical changes; HHH is fixed to abort, and
the input DD calls that fixed HHH, not any other non-aborting simulator.
On 10/11/2025 10:42 PM, dbush wrote:From there ^. WDYM rCRotherwiserCY? DD does not specify unlimited recursion.
No, you're the one claiming that HHH(DD) must report on the non-inputHow the Hell did you get that?
DDn
HHH(DD) is reporting on the otherwise unlimited recursive simulation
that its actual finite string of x86 machine code specifies.
It is literally true: a TMrCOs behaviour depends only on its programmingBut since Turing machines always have exactly the same behavior for aI don't think that is literally true.
given input,
Computable functions are required to have exactly the same behavior for
the same input.
HHH does have exactly the same behavior for the same input. DD is not a computable function.
The measure of HHH being correct is that what it does? ThatrCOs circular.we can ask about the hypothetical case when machine DD is executedThat is not the actual behavior of the actual input as measured by the simulation of DD by HHH according to the semantics of its language, the ultimate measure of correct simulation.
directly, not necessarily "now", by giving it the finite string
description of machine DD which is specified to possess all semantic
properties of machine DD including the fact that it halts when executed
directly.
On 2025-10-12 15:39:40 +0000, olcott said:
On 10/12/2025 4:46 AM, Mikko wrote:
On 2025-10-11 13:19:09 +0000, olcott said:
On 10/11/2025 4:43 AM, Mikko wrote:
We don't need the general definition of "semantic property of finite >>>>> string input" when the discussion is restricted to halting, which is >>>>> just one property.
Yes we do. In is incorrect to require halt deciders
to do things that no decider can ever do.
No, it is not incorrect. The purpose of the definition is to specify
what the term "halt decider" means so that it is possible to deremine
of any Turing machine whether it is a halt decider, and the definition
satisfies that purpose.
All logical impossibilities are exactly equally
logically impossible no matter what the reason
is for them being logically impossible.
It is exactly equally logically impossible for
a halt decider to report the correct halt status
of an input that does the opposite of whatever
it says as it is for the purely mental object of
a Turing machine to give birth to a real live
fifteen story office building.
Irrelevant to the fact that the definition of "halt decider" does
what it needs to do and that all requirements in that definition
are therefore correct and justified.
Am Sat, 11 Oct 2025 22:51:48 -0500 schrieb olcott:
On 10/11/2025 10:42 PM, dbush wrote:
No, you're the one claiming that HHH(DD) must report on the non-inputHow the Hell did you get that?
DDn
HHH(DD) is reporting on the otherwise unlimited recursive simulation
that its actual finite string of x86 machine code specifies.
From there ^. WDYM rCRotherwiserCY? DD does not specify unlimited recursion.
But since Turing machines always have exactly the same behavior for aI don't think that is literally true.
given input,
Computable functions are required to have exactly the same behavior for
the same input.
HHH does have exactly the same behavior for the same input. DD is not a
computable function.
It is literally true: a TMrCOs behaviour depends only on its programming (i.e. state table) and the initial tape contents (the input). DD is computable as valid C code.
we can ask about the hypothetical case when machine DD is executedThat is not the actual behavior of the actual input as measured by the
directly, not necessarily "now", by giving it the finite string
description of machine DD which is specified to possess all semantic
properties of machine DD including the fact that it halts when executed
directly.
simulation of DD by HHH according to the semantics of its language, the
ultimate measure of correct simulation.
The measure of HHH being correct is that what it does? ThatrCOs circular.
The directly executed DD() is not a finite string
thus is outside of the domain of HHH thus does not
contradict that HHH(DD) rejects its input.
On 10/13/2025 4:03 AM, Mikko wrote:
On 2025-10-12 15:39:40 +0000, olcott said:
On 10/12/2025 4:46 AM, Mikko wrote:
On 2025-10-11 13:19:09 +0000, olcott said:
On 10/11/2025 4:43 AM, Mikko wrote:
We don't need the general definition of "semantic property of finite >>>>>> string input" when the discussion is restricted to halting, which is >>>>>> just one property.
Yes we do. In is incorrect to require halt deciders
to do things that no decider can ever do.
No, it is not incorrect. The purpose of the definition is to specify
what the term "halt decider" means so that it is possible to deremine
of any Turing machine whether it is a halt decider, and the definition >>>> satisfies that purpose.
All logical impossibilities are exactly equally
logically impossible no matter what the reason
is for them being logically impossible.
It is exactly equally logically impossible for
a halt decider to report the correct halt status
of an input that does the opposite of whatever
it says as it is for the purely mental object of
a Turing machine to give birth to a real live
fifteen story office building.
Irrelevant to the fact that the definition of "halt decider" does
what it needs to do and that all requirements in that definition
are therefore correct and justified.
Not when the halting problem requires a halt
decider to report on an input that is not in
its domain.
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except as noted in
the sig.
On 13/10/2025 14:29, olcott wrote:
The directly executed DD() is not a finite string
thus is outside of the domain of HHH thus does not
contradict that HHH(DD) rejects its input.
DD is a finite string! It fit entirely within a finite usenet post!
I think GPT agrees because it's a sycophant and your prompt challenged
it with strawmen from which it generated an agreement.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 10/11/2025 4:48 AM, Mikko wrote:
On 2025-10-10 16:21:10 +0000, olcott said:
On 10/10/2025 3:23 AM, Mikko wrote:
On 2025-10-09 17:37:15 +0000, olcott said:This rubric provides complete understanding of the
On 10/9/2025 5:04 AM, Mikko wrote:
On 2025-10-09 04:02:32 +0000, olcott said:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its >>>>>>>>>>>> simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is >>>>>>>>>>> already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not interested.
He just wants to be assured that his baloney has convinced everybody,
and he'll keep on spewing it until he gets that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern >>>>>>>> that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
If the simulation is never stops then HHH is not a decider.
Yes, but until you understood this part we could
not move on to the next part.
FOrtunately it is not necessary or even useful to move to the next part. >>>
term [semantic halting property of finite string input]
to every LLM, even the otherwise stupid ones.
The meaning of "semantic halting property of finite string input" is
not needed. The phrase is not used in a typical halting problem
statement and not needed in the proof of uncomputability of halting.
It is sufficient to define what it means that a Turing machine halts.
It is a brand new idea that I derived though semantic
logical entailment of other ideas. Are you saying that
all new ideas are always wrong?
On 10/11/2025 4:51 AM, Mikko wrote:
On 2025-10-10 16:23:30 +0000, olcott said:
On 10/10/2025 3:25 AM, Mikko wrote:
On 2025-10-09 17:39:14 +0000, olcott said:
On 10/9/2025 5:08 AM, Mikko wrote:
On 2025-10-07 14:43:55 +0000, olcott said:
On 10/7/2025 4:00 AM, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
On 10/6/2025 4:27 AM, Mikko wrote:
On 2025-10-05 12:40:19 +0000, olcott said:
On 10/4/2025 11:34 AM, Kaz Kylheku wrote:
On 2025-10-04, olcott <polcott333@gmail.com> wrote:When the finite string input specifies a diagonal case
All Turing machine deciders only compute the mapping >>>>>>>>>>>>> from their finite string inputs to an accept state or reject >>>>>>>>>>>>> state on the basis that this input finite string specifies a >>>>>>>>>>>>> semantic or syntactic property.
And that is what is incomputable. It's possible for the finite >>>>>>>>>>>> string input to specify a diagonal case that is wrongly decided. >>>>>>>>>>>
the "do the opposite" code becomes unreachable.
That depends on the decider candidate.
When the decider candidate is a simulating halt decider
then its simulated input cannot possibly ever reach the
do the opposite code.
It can, if the simulator can detect what part of the simulated program >>>>>>>> is the simulator itself and skip the simulation of that code.
It seems to be the case that a function
cannot know its own machine address and
still be Turing computable otherwise HHH
would know that DD is specifying recursive
emulation as soon as DD calls HHH(DD).
The code
of the simulator itself is already known so there is no need to simulate
it.
The non-halting behavior of DD() is based on
recursive simulation this needs to be verified.
There is no non-halting behavour of DD(). DD() halts.
And someone saw that Bill's identical twin brother
Bob robbed a liquor store making Bill guilty because
he looks just like Bob.
Yes, that is analogous how your HHH concludes that DD halts.
No it is the analysis of how people continue to
mistakenly believe that HHH must not report on
the actual behavior that its actual input actually specifies.
Your "analysis" is analogous to the behaviour of your HHH:
It analyses a bother of DD that does not look just like DD
but close enough that HHH does not see the difference.
You did not find any error in my analogy.
You have the analogy exactly backwards.
HHH does report on the semantic halting property
that its input actually specifies.
On 2025-10-11 13:21:27 +0000, olcott said:
On 10/11/2025 4:48 AM, Mikko wrote:
On 2025-10-10 16:21:10 +0000, olcott said:
On 10/10/2025 3:23 AM, Mikko wrote:
On 2025-10-09 17:37:15 +0000, olcott said:
On 10/9/2025 5:04 AM, Mikko wrote:
On 2025-10-09 04:02:32 +0000, olcott said:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider >>>>>>>>>>>>> then its simulated input cannot possibly ever reach the do >>>>>>>>>>>>> the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the >>>>>>>>>>>> simulation of that code. The code of the simulator itself is >>>>>>>>>>>> already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not >>>>>>>>>>> interested. He just wants to be assured that his baloney has >>>>>>>>>>> convinced everybody, and he'll keep on spewing it until he >>>>>>>>>>> gets that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour >>>>>>>>> pattern
that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
If the simulation is never stops then HHH is not a decider.
Yes, but until you understood this part we could
not move on to the next part.
FOrtunately it is not necessary or even useful to move to the next
part.
This rubric provides complete understanding of the
term [semantic halting property of finite string input]
to every LLM, even the otherwise stupid ones.
The meaning of "semantic halting property of finite string input" is
not needed. The phrase is not used in a typical halting problem
statement and not needed in the proof of uncomputability of halting.
It is sufficient to define what it means that a Turing machine halts.
It is a brand new idea that I derived though semantic
logical entailment of other ideas. Are you saying that
all new ideas are always wrong?
Nice to see that you don't disagree.
On 2025-10-10 16:21:10 +0000, olcott said:
On 10/10/2025 3:23 AM, Mikko wrote:
On 2025-10-09 17:37:15 +0000, olcott said:
On 10/9/2025 5:04 AM, Mikko wrote:
On 2025-10-09 04:02:32 +0000, olcott said:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then >>>>>>>>>>> its simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the
simulated program is the simulator itself and skip the
simulation of that code. The code of the simulator itself is >>>>>>>>>> already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not
interested. He just wants to be assured that his baloney has >>>>>>>>> convinced everybody, and he'll keep on spewing it until he gets >>>>>>>>> that assurance.
HHH(DD) needs to see all of the behavior of DD until
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern >>>>>>> that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
If the simulation is never stops then HHH is not a decider.
Yes, but until you understood this part we could
not move on to the next part.
FOrtunately it is not necessary or even useful to move to the next part.
This rubric provides complete understanding of the
term [semantic halting property of finite string input]
to every LLM, even the otherwise stupid ones.
The meaning of "semantic halting property of finite string input" is
not needed.
The phrase is not used in a typical halting problem
statement and not needed in the proof of uncomputability of halting.
It is sufficient to define what it means that a Turing machine halts.
On 10/15/2025 2:17 AM, Mikko wrote:
On 2025-10-11 13:21:27 +0000, olcott said:
On 10/11/2025 4:48 AM, Mikko wrote:
On 2025-10-10 16:21:10 +0000, olcott said:
On 10/10/2025 3:23 AM, Mikko wrote:
On 2025-10-09 17:37:15 +0000, olcott said:This rubric provides complete understanding of the
On 10/9/2025 5:04 AM, Mikko wrote:
On 2025-10-09 04:02:32 +0000, olcott said:
On 10/8/2025 5:02 AM, Mikko wrote:
On 2025-10-07 14:52:49 +0000, olcott said:
On 10/7/2025 4:11 AM, Richard Heathfield wrote:
On 07/10/2025 10:00, Mikko wrote:HHH(DD) needs to see all of the behavior of DD until
On 2025-10-07 00:26:00 +0000, olcott said:
<snip>
When the decider candidate is a simulating halt decider then its
simulated input cannot possibly ever reach the do
the opposite code.
It can, if the simulator can detect what part of the >>>>>>>>>>>>> simulated program is the simulator itself and skip the >>>>>>>>>>>>> simulation of that code. The code of the simulator itself is >>>>>>>>>>>>> already known so there is no need to simulate it.
I've told him that a dozen times at least. He's simply not interested.
He just wants to be assured that his baloney has convinced everybody,
and he'll keep on spewing it until he gets that assurance. >>>>>>>>>>>
HHH correctly determines that its simulated DD
would never stop running unless aborted
That hever happens if DD halts or never exhibits a behaviour pattern >>>>>>>>>> that HHH recognizes as non-halting.
DD correctly simulated by HHH never stops running
unless aborted.
If the simulation is never stops then HHH is not a decider.
Yes, but until you understood this part we could
not move on to the next part.
FOrtunately it is not necessary or even useful to move to the next part. >>>>>
term [semantic halting property of finite string input]
to every LLM, even the otherwise stupid ones.
The meaning of "semantic halting property of finite string input" is
not needed. The phrase is not used in a typical halting problem
statement and not needed in the proof of uncomputability of halting.
It is sufficient to define what it means that a Turing machine halts.
It is a brand new idea that I derived though semantic
logical entailment of other ideas. Are you saying that
all new ideas are always wrong?
Nice to see that you don't disagree.
I can't every tell what you mean what you say this.
You are never sufficiently specific on this.