On 10/29/2025 5:19 AM, Mikko wrote:
On 2025-10-28 14:54:09 +0000, olcott said:
On 10/28/2025 5:12 AM, Richard Heathfield wrote:
On 28/10/2025 09:25, Mikko wrote:
On 2025-10-28 01:33:19 +0000, Richard Damon said:
On 10/26/25 5:59 PM, olcott wrote:
On 10/26/2025 4:34 AM, Tristan Wibberley wrote:
On 26/10/2025 00:25, olcott wrote:
HHH(P) simulates a C function P step by step.
Do you mean that in the sense of "there exists a P" or "for all P" ? >>>>>>>>
A function pointer is the only input to HHH.
The rest of the spec make this more clear.
So, the memory it points to isn't part of the input?
THen I guess the decider isn't allowed to look at the memory.
According to the C rules a program may call the pointed function but >>>>> is not allowed to read the pointed memory in any other way.
Yes, a function pointer is a spectacularly bad choice of input. Far
better to pass in a filename to a file containing either the source or >>>> the binary.
Now when the goal is to show this:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
A data pointer that points to a COFF file image or a memoty image and
an integer for the size of the image would be a good input, too.
That has proven to be waaaayyyy over the head of almost
everyone here.
The whole point is to do a simple execution trace in your head.
On 10/29/2025 5:30 AM, Mikko wrote:
On 2025-10-28 14:58:32 +0000, olcott said:
On 10/28/2025 4:45 AM, Mikko wrote:
On 2025-10-27 14:42:01 +0000, olcott said:
On 10/27/2025 4:20 AM, Mikko wrote:
On 2025-10-25 23:25:13 +0000, olcott said:
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);
}
Instructions:
HHH(P) simulates a C function P step by step.
The simulation always stops once the function’s behavior can be >>>>>>> determined, producing a result that reflects what was observed.
Do not assume any prior knowledge about the Halting Problem or any >>>>>>> numeric mapping; the result’s meaning is entirely abstract.
Task (must follow strictly):
Trace the simulation of DD step by step, following the execution order >>>>>>> of each statement according to standard C semantics.
For every simulated evaluation, record what happens immediately after >>>>>>> HHH is called.
Continue this reasoning iteratively without skipping steps until the >>>>>>> simulation produces a result.
Deduce the final result of HHH(DD) based solely on this explicit >>>>>>> symbolic simulation.
Insufficient correction. The last sentence says "this explicit symbolic >>>>>> simulation" but there is no "this explicit symbolic simulation" mentioned
anywhere in the message. There is only one simulation that is not symbolic
and not required to be explicit.
The given inprormation is insufficient to fully answer the question. The >>>>>> code of HHH is not shown and the behaviour of HHH is only partially >>>>>> described. Therefore the answer can only be a list of possibilities that >>>>>> are not excluded by the problem specification:
a. If HHH can determine (correctly or otherwise) the behaviour of DD >>>>>> it returns a number that one way or another reflects that behaviour. >>>>>> b. Otherwise HHH never returns but keeps simulating forever or until it >>>>>> runs out of stack or heap or some other resource needed for the >>>>>> execution of HHH.
Now that four different LLM systems have been able
reverse-engineer the non-halting result by merely
being told to faithfully simulate DD with HHH and
see what happens this proves that all of my reviewers
have been dishonest with me for three years.
LLM systems are programmed to imitate normal human talk. They don't
usually protest for defective presentation as that is not common in
normal human communication. Instead they answer something and if
that is not the answer you wanted you may formulate your question
differently.
You haven't spoken with them lately.
They have 67-fold more memory than
two years ago.
That of course improves the quality of the imitations. But people are
not very good at rationl thinkig so an imitation must not be, either.
When I give it precise premises it seems to do semantic
logical entailment on the basis of these precise premises
infallibly.
On 2025-10-29 16:38:01 +0000, olcott said:
On 10/29/2025 5:19 AM, Mikko wrote:
On 2025-10-28 14:54:09 +0000, olcott said:
On 10/28/2025 5:12 AM, Richard Heathfield wrote:
On 28/10/2025 09:25, Mikko wrote:
On 2025-10-28 01:33:19 +0000, Richard Damon said:
On 10/26/25 5:59 PM, olcott wrote:
On 10/26/2025 4:34 AM, Tristan Wibberley wrote:
On 26/10/2025 00:25, olcott wrote:
HHH(P) simulates a C function P step by step.
Do you mean that in the sense of "there exists a P" or "for all >>>>>>>>> P" ?
A function pointer is the only input to HHH.
The rest of the spec make this more clear.
So, the memory it points to isn't part of the input?
THen I guess the decider isn't allowed to look at the memory.
According to the C rules a program may call the pointed function but >>>>>> is not allowed to read the pointed memory in any other way.
Yes, a function pointer is a spectacularly bad choice of input. Far >>>>> better to pass in a filename to a file containing either the source >>>>> or the binary.
Now when the goal is to show this:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
A data pointer that points to a COFF file image or a memoty image and
an integer for the size of the image would be a good input, too.
That has proven to be waaaayyyy over the head of almost
everyone here.
You are not "almost everyone".
The whole point is to do a simple execution trace in your head.
Perhaps you should try to improve your perfirmance in the art of
excution traces.
On 2025-10-29 16:40:12 +0000, olcott said:
On 10/29/2025 5:30 AM, Mikko wrote:
On 2025-10-28 14:58:32 +0000, olcott said:
On 10/28/2025 4:45 AM, Mikko wrote:
On 2025-10-27 14:42:01 +0000, olcott said:
On 10/27/2025 4:20 AM, Mikko wrote:
On 2025-10-25 23:25:13 +0000, olcott said:
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);
}
Instructions:
HHH(P) simulates a C function P step by step.
The simulation always stops once the function’s behavior can be >>>>>>>> determined, producing a result that reflects what was observed. >>>>>>>>
Do not assume any prior knowledge about the Halting Problem or >>>>>>>> any numeric mapping; the result’s meaning is entirely abstract. >>>>>>>>
Task (must follow strictly):
Trace the simulation of DD step by step, following the execution >>>>>>>> order of each statement according to standard C semantics.
For every simulated evaluation, record what happens immediately >>>>>>>> after HHH is called.
Continue this reasoning iteratively without skipping steps until >>>>>>>> the simulation produces a result.
Deduce the final result of HHH(DD) based solely on this explicit >>>>>>>> symbolic simulation.
Insufficient correction. The last sentence says "this explicit
symbolic
simulation" but there is no "this explicit symbolic simulation" >>>>>>> mentioned
anywhere in the message. There is only one simulation that is not >>>>>>> symbolic
and not required to be explicit.
The given inprormation is insufficient to fully answer the
question. The
code of HHH is not shown and the behaviour of HHH is only partially >>>>>>> described. Therefore the answer can only be a list of
possibilities that
are not excluded by the problem specification:
a. If HHH can determine (correctly or otherwise) the behaviour of DD >>>>>>> it returns a number that one way or another reflects that
behaviour.
b. Otherwise HHH never returns but keeps simulating forever or
until it
runs out of stack or heap or some other resource needed for the >>>>>>> execution of HHH.
Now that four different LLM systems have been able
reverse-engineer the non-halting result by merely
being told to faithfully simulate DD with HHH and
see what happens this proves that all of my reviewers
have been dishonest with me for three years.
LLM systems are programmed to imitate normal human talk. They don't
usually protest for defective presentation as that is not common in
normal human communication. Instead they answer something and if
that is not the answer you wanted you may formulate your question
differently.
You haven't spoken with them lately.
They have 67-fold more memory than
two years ago.
That of course improves the quality of the imitations. But people are
not very good at rationl thinkig so an imitation must not be, either.
When I give it precise premises it seems to do semantic
logical entailment on the basis of these precise premises
infallibly.
Maybe humans often seem to do semantic logical entailment on the basis
of precice premices when asked. But humans don't always do it correctly
and LLM systems try to imitate human answers, including mistakes.
On 10/30/2025 5:54 AM, Mikko wrote:
On 2025-10-29 16:38:01 +0000, olcott said:
On 10/29/2025 5:19 AM, Mikko wrote:
On 2025-10-28 14:54:09 +0000, olcott said:
On 10/28/2025 5:12 AM, Richard Heathfield wrote:
On 28/10/2025 09:25, Mikko wrote:
On 2025-10-28 01:33:19 +0000, Richard Damon said:
On 10/26/25 5:59 PM, olcott wrote:
On 10/26/2025 4:34 AM, Tristan Wibberley wrote:
On 26/10/2025 00:25, olcott wrote:
HHH(P) simulates a C function P step by step.
Do you mean that in the sense of "there exists a P" or "for all P" ? >>>>>>>>>>
A function pointer is the only input to HHH.
The rest of the spec make this more clear.
So, the memory it points to isn't part of the input?
THen I guess the decider isn't allowed to look at the memory.
According to the C rules a program may call the pointed function but >>>>>>> is not allowed to read the pointed memory in any other way.
Yes, a function pointer is a spectacularly bad choice of input. Far >>>>>> better to pass in a filename to a file containing either the source or >>>>>> the binary.
Now when the goal is to show this:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
A data pointer that points to a COFF file image or a memoty image and
an integer for the size of the image would be a good input, too.
That has proven to be waaaayyyy over the head of almost
everyone here.
You are not "almost everyone".
The whole point is to do a simple execution trace in your head.
Perhaps you should try to improve your perfirmance in the art of
excution traces.
There is no mistake in the essence of above.
Try and pint to any mistake IN THE ESSENCE.
On 10/30/2025 5:58 AM, Mikko wrote:
On 2025-10-29 16:40:12 +0000, olcott said:
On 10/29/2025 5:30 AM, Mikko wrote:
On 2025-10-28 14:58:32 +0000, olcott said:
On 10/28/2025 4:45 AM, Mikko wrote:
On 2025-10-27 14:42:01 +0000, olcott said:
On 10/27/2025 4:20 AM, Mikko wrote:
On 2025-10-25 23:25:13 +0000, olcott said:
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);
}
Instructions:
HHH(P) simulates a C function P step by step.
The simulation always stops once the function’s behavior can be >>>>>>>>> determined, producing a result that reflects what was observed. >>>>>>>>>
Do not assume any prior knowledge about the Halting Problem or any >>>>>>>>> numeric mapping; the result’s meaning is entirely abstract. >>>>>>>>>
Task (must follow strictly):
Trace the simulation of DD step by step, following the execution order
of each statement according to standard C semantics.
For every simulated evaluation, record what happens immediately after
HHH is called.
Continue this reasoning iteratively without skipping steps until the >>>>>>>>> simulation produces a result.
Deduce the final result of HHH(DD) based solely on this explicit >>>>>>>>> symbolic simulation.
Insufficient correction. The last sentence says "this explicit symbolic
simulation" but there is no "this explicit symbolic simulation" mentioned
anywhere in the message. There is only one simulation that is not symbolic
and not required to be explicit.
The given inprormation is insufficient to fully answer the question. The
code of HHH is not shown and the behaviour of HHH is only partially >>>>>>>> described. Therefore the answer can only be a list of possibilities that
are not excluded by the problem specification:
a. If HHH can determine (correctly or otherwise) the behaviour of DD >>>>>>>> it returns a number that one way or another reflects that behaviour.
b. Otherwise HHH never returns but keeps simulating forever or until it
runs out of stack or heap or some other resource needed for the >>>>>>>> execution of HHH.
Now that four different LLM systems have been able
reverse-engineer the non-halting result by merely
being told to faithfully simulate DD with HHH and
see what happens this proves that all of my reviewers
have been dishonest with me for three years.
LLM systems are programmed to imitate normal human talk. They don't >>>>>> usually protest for defective presentation as that is not common in >>>>>> normal human communication. Instead they answer something and if
that is not the answer you wanted you may formulate your question
differently.
You haven't spoken with them lately.
They have 67-fold more memory than
two years ago.
That of course improves the quality of the imitations. But people are
not very good at rationl thinkig so an imitation must not be, either.
When I give it precise premises it seems to do semantic
logical entailment on the basis of these precise premises
infallibly.
Maybe humans often seem to do semantic logical entailment on the basis
of precice premices when asked. But humans don't always do it correctly
and LLM systems try to imitate human answers, including mistakes.
I have gone over these details many thousands of
times. No one has ever pointed to any actual mistake.
On 2025-10-30 13:19:21 +0000, olcott said:
On 10/30/2025 5:54 AM, Mikko wrote:
On 2025-10-29 16:38:01 +0000, olcott said:
On 10/29/2025 5:19 AM, Mikko wrote:
On 2025-10-28 14:54:09 +0000, olcott said:
On 10/28/2025 5:12 AM, Richard Heathfield wrote:
On 28/10/2025 09:25, Mikko wrote:
On 2025-10-28 01:33:19 +0000, Richard Damon said:
On 10/26/25 5:59 PM, olcott wrote:According to the C rules a program may call the pointed function >>>>>>>> but
On 10/26/2025 4:34 AM, Tristan Wibberley wrote:
On 26/10/2025 00:25, olcott wrote:
HHH(P) simulates a C function P step by step.
Do you mean that in the sense of "there exists a P" or "for >>>>>>>>>>> all P" ?
A function pointer is the only input to HHH.
The rest of the spec make this more clear.
So, the memory it points to isn't part of the input?
THen I guess the decider isn't allowed to look at the memory. >>>>>>>>
is not allowed to read the pointed memory in any other way.
Yes, a function pointer is a spectacularly bad choice of input. >>>>>>> Far better to pass in a filename to a file containing either the >>>>>>> source or the binary.
Now when the goal is to show this:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
A data pointer that points to a COFF file image or a memoty image and >>>>> an integer for the size of the image would be a good input, too.
That has proven to be waaaayyyy over the head of almost
everyone here.
You are not "almost everyone".
The whole point is to do a simple execution trace in your head.
Perhaps you should try to improve your perfirmance in the art of
excution traces.
There is no mistake in the essence of above.
Try and pint to any mistake IN THE ESSENCE.
Others have already pointed out suffeiceintly may arrors, both exential
and others. Whether they are mistakes ir intentional is not important.
For me it is sufficient that you can't point out any substantial error
in my messages nor in any proofs you claim wrong.
On 2025-10-30 13:27:30 +0000, olcott said:
On 10/30/2025 5:58 AM, Mikko wrote:
On 2025-10-29 16:40:12 +0000, olcott said:
On 10/29/2025 5:30 AM, Mikko wrote:
On 2025-10-28 14:58:32 +0000, olcott said:When I give it precise premises it seems to do semantic
On 10/28/2025 4:45 AM, Mikko wrote:
On 2025-10-27 14:42:01 +0000, olcott said:
On 10/27/2025 4:20 AM, Mikko wrote:
On 2025-10-25 23:25:13 +0000, olcott said:
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);
}
Instructions:
HHH(P) simulates a C function P step by step.
The simulation always stops once the function’s behavior can >>>>>>>>>> be determined, producing a result that reflects what was
observed.
Do not assume any prior knowledge about the Halting Problem or >>>>>>>>>> any numeric mapping; the result’s meaning is entirely abstract. >>>>>>>>>>
Task (must follow strictly):
Trace the simulation of DD step by step, following the
execution order of each statement according to standard C >>>>>>>>>> semantics.
For every simulated evaluation, record what happens
immediately after HHH is called.
Continue this reasoning iteratively without skipping steps >>>>>>>>>> until the simulation produces a result.
Deduce the final result of HHH(DD) based solely on this
explicit symbolic simulation.
Insufficient correction. The last sentence says "this explicit >>>>>>>>> symbolic
simulation" but there is no "this explicit symbolic simulation" >>>>>>>>> mentioned
anywhere in the message. There is only one simulation that is >>>>>>>>> not symbolic
and not required to be explicit.
The given inprormation is insufficient to fully answer the
question. The
code of HHH is not shown and the behaviour of HHH is only
partially
described. Therefore the answer can only be a list of
possibilities that
are not excluded by the problem specification:
a. If HHH can determine (correctly or otherwise) the behaviour >>>>>>>>> of DD
it returns a number that one way or another reflects that >>>>>>>>> behaviour.
b. Otherwise HHH never returns but keeps simulating forever or >>>>>>>>> until it
runs out of stack or heap or some other resource needed for the >>>>>>>>> execution of HHH.
Now that four different LLM systems have been able
reverse-engineer the non-halting result by merely
being told to faithfully simulate DD with HHH and
see what happens this proves that all of my reviewers
have been dishonest with me for three years.
LLM systems are programmed to imitate normal human talk. They don't >>>>>>> usually protest for defective presentation as that is not common in >>>>>>> normal human communication. Instead they answer something and if >>>>>>> that is not the answer you wanted you may formulate your question >>>>>>> differently.
You haven't spoken with them lately.
They have 67-fold more memory than
two years ago.
That of course improves the quality of the imitations. But people are >>>>> not very good at rationl thinkig so an imitation must not be, either. >>>>
logical entailment on the basis of these precise premises
infallibly.
Maybe humans often seem to do semantic logical entailment on the basis
of precice premices when asked. But humans don't always do it correctly
and LLM systems try to imitate human answers, including mistakes.
I have gone over these details many thousands of
times. No one has ever pointed to any actual mistake.
Maybe nobody has pointed it out but being overly credulous can be
regarded as a mistake.
On 10/31/2025 6:45 AM, Mikko wrote:
On 2025-10-30 13:19:21 +0000, olcott said:
On 10/30/2025 5:54 AM, Mikko wrote:
On 2025-10-29 16:38:01 +0000, olcott said:
On 10/29/2025 5:19 AM, Mikko wrote:
On 2025-10-28 14:54:09 +0000, olcott said:
On 10/28/2025 5:12 AM, Richard Heathfield wrote:
On 28/10/2025 09:25, Mikko wrote:
On 2025-10-28 01:33:19 +0000, Richard Damon said:
On 10/26/25 5:59 PM, olcott wrote:According to the C rules a program may call the pointed
On 10/26/2025 4:34 AM, Tristan Wibberley wrote:
On 26/10/2025 00:25, olcott wrote:
HHH(P) simulates a C function P step by step.
Do you mean that in the sense of "there exists a P" or "for >>>>>>>>>>>> all P" ?
A function pointer is the only input to HHH.
The rest of the spec make this more clear.
So, the memory it points to isn't part of the input?
THen I guess the decider isn't allowed to look at the memory. >>>>>>>>>
function but
is not allowed to read the pointed memory in any other way.
Yes, a function pointer is a spectacularly bad choice of input. >>>>>>>> Far better to pass in a filename to a file containing either the >>>>>>>> source or the binary.
Now when the goal is to show this:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
A data pointer that points to a COFF file image or a memoty image and >>>>>> an integer for the size of the image would be a good input, too.
That has proven to be waaaayyyy over the head of almost
everyone here.
You are not "almost everyone".
The whole point is to do a simple execution trace in your head.
Perhaps you should try to improve your perfirmance in the art of
excution traces.
There is no mistake in the essence of above.
Try and pint to any mistake IN THE ESSENCE.
Others have already pointed out suffeiceintly may arrors, both exential
and others. Whether they are mistakes ir intentional is not important.
For me it is sufficient that you can't point out any substantial error
in my messages nor in any proofs you claim wrong.
Others have simply ignored H(D) and changed the
subject to something else.
On 10/31/2025 6:45 AM, Mikko wrote:
On 2025-10-30 13:19:21 +0000, olcott said:
On 10/30/2025 5:54 AM, Mikko wrote:
On 2025-10-29 16:38:01 +0000, olcott said:
On 10/29/2025 5:19 AM, Mikko wrote:
On 2025-10-28 14:54:09 +0000, olcott said:
On 10/28/2025 5:12 AM, Richard Heathfield wrote:
On 28/10/2025 09:25, Mikko wrote:
On 2025-10-28 01:33:19 +0000, Richard Damon said:
On 10/26/25 5:59 PM, olcott wrote:According to the C rules a program may call the pointed function but >>>>>>>>> is not allowed to read the pointed memory in any other way.
On 10/26/2025 4:34 AM, Tristan Wibberley wrote:
On 26/10/2025 00:25, olcott wrote:
HHH(P) simulates a C function P step by step.
Do you mean that in the sense of "there exists a P" or "for all P" ?
A function pointer is the only input to HHH.
The rest of the spec make this more clear.
So, the memory it points to isn't part of the input?
THen I guess the decider isn't allowed to look at the memory. >>>>>>>>>
Yes, a function pointer is a spectacularly bad choice of input. Far >>>>>>>> better to pass in a filename to a file containing either the source or
the binary.
Now when the goal is to show this:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
A data pointer that points to a COFF file image or a memoty image and >>>>>> an integer for the size of the image would be a good input, too.
That has proven to be waaaayyyy over the head of almost
everyone here.
You are not "almost everyone".
The whole point is to do a simple execution trace in your head.
Perhaps you should try to improve your perfirmance in the art of
excution traces.
There is no mistake in the essence of above.
Try and pint to any mistake IN THE ESSENCE.
Others have already pointed out suffeiceintly may arrors, both exential
and others. Whether they are mistakes ir intentional is not important.
For me it is sufficient that you can't point out any substantial error
in my messages nor in any proofs you claim wrong.
Others have simply ignored H(D) and changed the
subject to something else.
On 10/31/2025 6:47 AM, Mikko wrote:
On 2025-10-30 13:27:30 +0000, olcott said:
On 10/30/2025 5:58 AM, Mikko wrote:
On 2025-10-29 16:40:12 +0000, olcott said:
On 10/29/2025 5:30 AM, Mikko wrote:
On 2025-10-28 14:58:32 +0000, olcott said:When I give it precise premises it seems to do semantic
On 10/28/2025 4:45 AM, Mikko wrote:
On 2025-10-27 14:42:01 +0000, olcott said:
On 10/27/2025 4:20 AM, Mikko wrote:
On 2025-10-25 23:25:13 +0000, olcott said:
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);
}
Instructions:
HHH(P) simulates a C function P step by step.
The simulation always stops once the function’s behavior can be >>>>>>>>>>> determined, producing a result that reflects what was observed. >>>>>>>>>>>
Do not assume any prior knowledge about the Halting Problem or any >>>>>>>>>>> numeric mapping; the result’s meaning is entirely abstract. >>>>>>>>>>>
Task (must follow strictly):
Trace the simulation of DD step by step, following the execution order
of each statement according to standard C semantics.
For every simulated evaluation, record what happens immediately after
HHH is called.
Continue this reasoning iteratively without skipping steps until the
simulation produces a result.
Deduce the final result of HHH(DD) based solely on this explicit >>>>>>>>>>> symbolic simulation.
Insufficient correction. The last sentence says "this explicit symbolic
simulation" but there is no "this explicit symbolic simulation" mentioned
anywhere in the message. There is only one simulation that is not symbolic
and not required to be explicit.
The given inprormation is insufficient to fully answer the question. The
code of HHH is not shown and the behaviour of HHH is only partially >>>>>>>>>> described. Therefore the answer can only be a list of possibilities that
are not excluded by the problem specification:
a. If HHH can determine (correctly or otherwise) the behaviour of DD >>>>>>>>>> it returns a number that one way or another reflects that behaviour.
b. Otherwise HHH never returns but keeps simulating forever or until it
runs out of stack or heap or some other resource needed for the >>>>>>>>>> execution of HHH.
Now that four different LLM systems have been able
reverse-engineer the non-halting result by merely
being told to faithfully simulate DD with HHH and
see what happens this proves that all of my reviewers
have been dishonest with me for three years.
LLM systems are programmed to imitate normal human talk. They don't >>>>>>>> usually protest for defective presentation as that is not common in >>>>>>>> normal human communication. Instead they answer something and if >>>>>>>> that is not the answer you wanted you may formulate your question >>>>>>>> differently.
You haven't spoken with them lately.
They have 67-fold more memory than
two years ago.
That of course improves the quality of the imitations. But people are >>>>>> not very good at rationl thinkig so an imitation must not be, either. >>>>>
logical entailment on the basis of these precise premises
infallibly.
Maybe humans often seem to do semantic logical entailment on the basis >>>> of precice premices when asked. But humans don't always do it correctly >>>> and LLM systems try to imitate human answers, including mistakes.
I have gone over these details many thousands of
times. No one has ever pointed to any actual mistake.
Maybe nobody has pointed it out but being overly credulous can be
regarded as a mistake.
No it cannot. That is a stupid lie.
A mistake is an error in reasoning.
On 2025-10-31 13:27:14 +0000, olcott said:
On 10/31/2025 6:45 AM, Mikko wrote:
On 2025-10-30 13:19:21 +0000, olcott said:
On 10/30/2025 5:54 AM, Mikko wrote:
On 2025-10-29 16:38:01 +0000, olcott said:
On 10/29/2025 5:19 AM, Mikko wrote:
On 2025-10-28 14:54:09 +0000, olcott said:
On 10/28/2025 5:12 AM, Richard Heathfield wrote:
On 28/10/2025 09:25, Mikko wrote:
On 2025-10-28 01:33:19 +0000, Richard Damon said:Yes, a function pointer is a spectacularly bad choice of input. >>>>>>>>> Far better to pass in a filename to a file containing either >>>>>>>>> the source or the binary.
On 10/26/25 5:59 PM, olcott wrote:According to the C rules a program may call the pointed
On 10/26/2025 4:34 AM, Tristan Wibberley wrote:
On 26/10/2025 00:25, olcott wrote:
HHH(P) simulates a C function P step by step.
Do you mean that in the sense of "there exists a P" or "for >>>>>>>>>>>>> all P" ?
A function pointer is the only input to HHH.
The rest of the spec make this more clear.
So, the memory it points to isn't part of the input?
THen I guess the decider isn't allowed to look at the memory. >>>>>>>>>>
function but
is not allowed to read the pointed memory in any other way. >>>>>>>>>
Now when the goal is to show this:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
A data pointer that points to a COFF file image or a memoty image >>>>>>> and
an integer for the size of the image would be a good input, too.
That has proven to be waaaayyyy over the head of almost
everyone here.
You are not "almost everyone".
The whole point is to do a simple execution trace in your head.
Perhaps you should try to improve your perfirmance in the art of
excution traces.
There is no mistake in the essence of above.
Try and pint to any mistake IN THE ESSENCE.
Others have already pointed out suffeiceintly may arrors, both exential
and others. Whether they are mistakes ir intentional is not important.
For me it is sufficient that you can't point out any substantial error
in my messages nor in any proofs you claim wrong.
Others have simply ignored H(D) and changed the
subject to something else.
Changing the subject is fairly common here. In particular, you seem
to do that almost every time.
On 2025-10-31 13:38:26 +0000, olcott said:
On 10/31/2025 6:47 AM, Mikko wrote:
On 2025-10-30 13:27:30 +0000, olcott said:
On 10/30/2025 5:58 AM, Mikko wrote:
On 2025-10-29 16:40:12 +0000, olcott said:
On 10/29/2025 5:30 AM, Mikko wrote:
On 2025-10-28 14:58:32 +0000, olcott said:
On 10/28/2025 4:45 AM, Mikko wrote:
On 2025-10-27 14:42:01 +0000, olcott said:
On 10/27/2025 4:20 AM, Mikko wrote:
On 2025-10-25 23:25:13 +0000, olcott said:
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);
}
Instructions:
HHH(P) simulates a C function P step by step.
The simulation always stops once the function’s behavior can >>>>>>>>>>>> be determined, producing a result that reflects what was >>>>>>>>>>>> observed.
Do not assume any prior knowledge about the Halting Problem >>>>>>>>>>>> or any numeric mapping; the result’s meaning is entirely >>>>>>>>>>>> abstract.
Task (must follow strictly):
Trace the simulation of DD step by step, following the >>>>>>>>>>>> execution order of each statement according to standard C >>>>>>>>>>>> semantics.
For every simulated evaluation, record what happens
immediately after HHH is called.
Continue this reasoning iteratively without skipping steps >>>>>>>>>>>> until the simulation produces a result.
Deduce the final result of HHH(DD) based solely on this >>>>>>>>>>>> explicit symbolic simulation.
Insufficient correction. The last sentence says "this
explicit symbolic
simulation" but there is no "this explicit symbolic
simulation" mentioned
anywhere in the message. There is only one simulation that is >>>>>>>>>>> not symbolic
and not required to be explicit.
The given inprormation is insufficient to fully answer the >>>>>>>>>>> question. The
code of HHH is not shown and the behaviour of HHH is only >>>>>>>>>>> partially
described. Therefore the answer can only be a list of
possibilities that
are not excluded by the problem specification:
a. If HHH can determine (correctly or otherwise) the
behaviour of DD
it returns a number that one way or another reflects that >>>>>>>>>>> behaviour.
b. Otherwise HHH never returns but keeps simulating forever >>>>>>>>>>> or until it
runs out of stack or heap or some other resource needed for >>>>>>>>>>> the
execution of HHH.
Now that four different LLM systems have been able
reverse-engineer the non-halting result by merely
being told to faithfully simulate DD with HHH and
see what happens this proves that all of my reviewers
have been dishonest with me for three years.
LLM systems are programmed to imitate normal human talk. They >>>>>>>>> don't
usually protest for defective presentation as that is not
common in
normal human communication. Instead they answer something and if >>>>>>>>> that is not the answer you wanted you may formulate your question >>>>>>>>> differently.
You haven't spoken with them lately.
They have 67-fold more memory than
two years ago.
That of course improves the quality of the imitations. But people >>>>>>> are
not very good at rationl thinkig so an imitation must not be,
either.
When I give it precise premises it seems to do semantic
logical entailment on the basis of these precise premises
infallibly.
Maybe humans often seem to do semantic logical entailment on the basis >>>>> of precice premices when asked. But humans don't always do it
correctly
and LLM systems try to imitate human answers, including mistakes.
I have gone over these details many thousands of
times. No one has ever pointed to any actual mistake.
Maybe nobody has pointed it out but being overly credulous can be
regarded as a mistake.
No it cannot. That is a stupid lie.
Maybe it is a matter of opinion but I think that being overly credulous
can be a fatal mistake.
A mistake is an error in reasoning.
The usual meaning is more gneral than that but an error in reasoning
is often regarded as a mistake. A total lack of reasoning can also
be seen as an error of reasoning or just as a mistake.
On 11/1/2025 4:48 AM, Mikko wrote:
On 2025-10-31 13:38:26 +0000, olcott said:
On 10/31/2025 6:47 AM, Mikko wrote:
On 2025-10-30 13:27:30 +0000, olcott said:
On 10/30/2025 5:58 AM, Mikko wrote:
On 2025-10-29 16:40:12 +0000, olcott said:
On 10/29/2025 5:30 AM, Mikko wrote:
On 2025-10-28 14:58:32 +0000, olcott said:
On 10/28/2025 4:45 AM, Mikko wrote:
On 2025-10-27 14:42:01 +0000, olcott said:
On 10/27/2025 4:20 AM, Mikko wrote:
On 2025-10-25 23:25:13 +0000, olcott said:
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);
}
Instructions:
HHH(P) simulates a C function P step by step.
The simulation always stops once the function’s behavior >>>>>>>>>>>>> can be determined, producing a result that reflects what >>>>>>>>>>>>> was observed.
Do not assume any prior knowledge about the Halting Problem >>>>>>>>>>>>> or any numeric mapping; the result’s meaning is entirely >>>>>>>>>>>>> abstract.
Task (must follow strictly):
Trace the simulation of DD step by step, following the >>>>>>>>>>>>> execution order of each statement according to standard C >>>>>>>>>>>>> semantics.
For every simulated evaluation, record what happens >>>>>>>>>>>>> immediately after HHH is called.
Continue this reasoning iteratively without skipping steps >>>>>>>>>>>>> until the simulation produces a result.
Deduce the final result of HHH(DD) based solely on this >>>>>>>>>>>>> explicit symbolic simulation.
Insufficient correction. The last sentence says "this >>>>>>>>>>>> explicit symbolic
simulation" but there is no "this explicit symbolic
simulation" mentioned
anywhere in the message. There is only one simulation that >>>>>>>>>>>> is not symbolic
and not required to be explicit.
The given inprormation is insufficient to fully answer the >>>>>>>>>>>> question. The
code of HHH is not shown and the behaviour of HHH is only >>>>>>>>>>>> partially
described. Therefore the answer can only be a list of >>>>>>>>>>>> possibilities that
are not excluded by the problem specification:
a. If HHH can determine (correctly or otherwise) the
behaviour of DD
it returns a number that one way or another reflects that >>>>>>>>>>>> behaviour.
b. Otherwise HHH never returns but keeps simulating forever >>>>>>>>>>>> or until it
runs out of stack or heap or some other resource needed >>>>>>>>>>>> for the
execution of HHH.
Now that four different LLM systems have been able
reverse-engineer the non-halting result by merely
being told to faithfully simulate DD with HHH and
see what happens this proves that all of my reviewers
have been dishonest with me for three years.
LLM systems are programmed to imitate normal human talk. They >>>>>>>>>> don't
usually protest for defective presentation as that is not >>>>>>>>>> common in
normal human communication. Instead they answer something and if >>>>>>>>>> that is not the answer you wanted you may formulate your question >>>>>>>>>> differently.
You haven't spoken with them lately.
They have 67-fold more memory than
two years ago.
That of course improves the quality of the imitations. But
people are
not very good at rationl thinkig so an imitation must not be, >>>>>>>> either.
When I give it precise premises it seems to do semantic
logical entailment on the basis of these precise premises
infallibly.
Maybe humans often seem to do semantic logical entailment on the
basis
of precice premices when asked. But humans don't always do it
correctly
and LLM systems try to imitate human answers, including mistakes.
I have gone over these details many thousands of
times. No one has ever pointed to any actual mistake.
Maybe nobody has pointed it out but being overly credulous can be
regarded as a mistake.
No it cannot. That is a stupid lie.
Maybe it is a matter of opinion but I think that being overly credulous
can be a fatal mistake.
A mistake is an error in reasoning.
The usual meaning is more gneral than that but an error in reasoning
is often regarded as a mistake. A total lack of reasoning can also
be seen as an error of reasoning or just as a mistake.
Simply not paying any attention when a sequence of
correct reasoning is provided over and over again
and simply saying something like blah, blah, blah
you are wrong: is morally corrupt.
On 11/1/2025 4:35 AM, Mikko wrote:
On 2025-10-31 13:27:14 +0000, olcott said:
On 10/31/2025 6:45 AM, Mikko wrote:
On 2025-10-30 13:19:21 +0000, olcott said:
On 10/30/2025 5:54 AM, Mikko wrote:
On 2025-10-29 16:38:01 +0000, olcott said:
On 10/29/2025 5:19 AM, Mikko wrote:
On 2025-10-28 14:54:09 +0000, olcott said:That has proven to be waaaayyyy over the head of almost
On 10/28/2025 5:12 AM, Richard Heathfield wrote:
On 28/10/2025 09:25, Mikko wrote:
On 2025-10-28 01:33:19 +0000, Richard Damon said:Yes, a function pointer is a spectacularly bad choice of input. Far >>>>>>>>>> better to pass in a filename to a file containing either the source or
On 10/26/25 5:59 PM, olcott wrote:According to the C rules a program may call the pointed function but
On 10/26/2025 4:34 AM, Tristan Wibberley wrote:
On 26/10/2025 00:25, olcott wrote:
HHH(P) simulates a C function P step by step.
Do you mean that in the sense of "there exists a P" or "for all P" ?
A function pointer is the only input to HHH.
The rest of the spec make this more clear.
So, the memory it points to isn't part of the input?
THen I guess the decider isn't allowed to look at the memory. >>>>>>>>>>>
is not allowed to read the pointed memory in any other way. >>>>>>>>>>
the binary.
Now when the goal is to show this:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
A data pointer that points to a COFF file image or a memoty image and >>>>>>>> an integer for the size of the image would be a good input, too. >>>>>>>
everyone here.
You are not "almost everyone".
The whole point is to do a simple execution trace in your head.
Perhaps you should try to improve your perfirmance in the art of
excution traces.
There is no mistake in the essence of above.
Try and pint to any mistake IN THE ESSENCE.
Others have already pointed out suffeiceintly may arrors, both exential >>>> and others. Whether they are mistakes ir intentional is not important. >>>> For me it is sufficient that you can't point out any substantial error >>>> in my messages nor in any proofs you claim wrong.
Others have simply ignored H(D) and changed the
subject to something else.
Changing the subject is fairly common here. In particular, you seem
to do that almost every time.
I point out the error of every incoherent or incorrect
statement. When someone asks an incoherent question
that has no possible correct answer I point out the
incoherence. This is not changing the subject.
On 11/1/2025 4:48 AM, Mikko wrote:
On 2025-10-31 13:38:26 +0000, olcott said:
On 10/31/2025 6:47 AM, Mikko wrote:
On 2025-10-30 13:27:30 +0000, olcott said:
On 10/30/2025 5:58 AM, Mikko wrote:
On 2025-10-29 16:40:12 +0000, olcott said:
On 10/29/2025 5:30 AM, Mikko wrote:
On 2025-10-28 14:58:32 +0000, olcott said:When I give it precise premises it seems to do semantic
On 10/28/2025 4:45 AM, Mikko wrote:
On 2025-10-27 14:42:01 +0000, olcott said:
On 10/27/2025 4:20 AM, Mikko wrote:
On 2025-10-25 23:25:13 +0000, olcott said:
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);
}
Instructions:
HHH(P) simulates a C function P step by step.
The simulation always stops once the function’s behavior can be
determined, producing a result that reflects what was observed. >>>>>>>>>>>>>
Do not assume any prior knowledge about the Halting Problem or any
numeric mapping; the result’s meaning is entirely abstract. >>>>>>>>>>>>>
Task (must follow strictly):
Trace the simulation of DD step by step, following the execution order
of each statement according to standard C semantics. >>>>>>>>>>>>>
For every simulated evaluation, record what happens immediately after
HHH is called.
Continue this reasoning iteratively without skipping steps until the
simulation produces a result.
Deduce the final result of HHH(DD) based solely on this explicit >>>>>>>>>>>>> symbolic simulation.
Insufficient correction. The last sentence says "this explicit symbolic
simulation" but there is no "this explicit symbolic simulation" mentioned
anywhere in the message. There is only one simulation that is not symbolic
and not required to be explicit.
The given inprormation is insufficient to fully answer the question. The
code of HHH is not shown and the behaviour of HHH is only partially
described. Therefore the answer can only be a list of possibilities that
are not excluded by the problem specification:
a. If HHH can determine (correctly or otherwise) the behaviour of DD
it returns a number that one way or another reflects that behaviour.
b. Otherwise HHH never returns but keeps simulating forever or until it
runs out of stack or heap or some other resource needed for the >>>>>>>>>>>> execution of HHH.
Now that four different LLM systems have been able
reverse-engineer the non-halting result by merely
being told to faithfully simulate DD with HHH and
see what happens this proves that all of my reviewers
have been dishonest with me for three years.
LLM systems are programmed to imitate normal human talk. They don't >>>>>>>>>> usually protest for defective presentation as that is not common in >>>>>>>>>> normal human communication. Instead they answer something and if >>>>>>>>>> that is not the answer you wanted you may formulate your question >>>>>>>>>> differently.
You haven't spoken with them lately.
They have 67-fold more memory than
two years ago.
That of course improves the quality of the imitations. But people are >>>>>>>> not very good at rationl thinkig so an imitation must not be, either. >>>>>>>
logical entailment on the basis of these precise premises
infallibly.
Maybe humans often seem to do semantic logical entailment on the basis >>>>>> of precice premices when asked. But humans don't always do it correctly >>>>>> and LLM systems try to imitate human answers, including mistakes.
I have gone over these details many thousands of
times. No one has ever pointed to any actual mistake.
Maybe nobody has pointed it out but being overly credulous can be
regarded as a mistake.
No it cannot. That is a stupid lie.
Maybe it is a matter of opinion but I think that being overly credulous
can be a fatal mistake.
A mistake is an error in reasoning.
The usual meaning is more gneral than that but an error in reasoning
is often regarded as a mistake. A total lack of reasoning can also
be seen as an error of reasoning or just as a mistake.
Simply not paying any attention when a sequence of
correct reasoning is provided over and over again
and simply saying something like blah, blah, blah
you are wrong: is morally corrupt.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,075 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 90:35:28 |
| Calls: | 13,798 |
| Calls today: | 1 |
| Files: | 186,989 |
| D/L today: |
5,332 files (1,536M bytes) |
| Messages: | 2,438,212 |