I overcome the proof of undecidability of the Halting Problem in that
the code that "does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over and
over until HHH sees this repeating pattern and aborts or both HHH and DD crash due to OOM error.
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in that
the code that "does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over and
over until HHH sees this repeating pattern and aborts or both HHH and
DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already inside
DD when we call HHH:
Since HHH does correctly simulate itself simulating DD we have complete
proof that you are wrong.
I had to write the whole x86utm operating system to make this work.
On 5/15/2025 4:18 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in
that the code that "does the opposite of whatever value that HHH
returns" becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over
and over until HHH sees this repeating pattern and aborts or both
HHH and DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already
inside DD when we call HHH:
Since HHH does correctly simulate itself simulating DD we have
complete proof that you are wrong.
I had to write the whole x86utm operating system to make this work.
It is not possible to make this work even by "writing an operating
system"
so whatever you think you are doing it isn't addressing my core point:
you are NOT *fully* simulating DD by HHH because you are already inside
DD when you are calling HHH.
/Flibble
Anyone that is intimately familiar with how multi-tasking operating
systems work will understand how HHH could emulate itself emulating its input.
Mike already verified that HHH does correctly emulate itself emulating
DDD. He verified this by carefully studying the source-code.
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself
again over and over until HHH sees this repeating pattern
and aborts or both HHH and DD crash due to OOM error.
The key unresolved issue is whether or not HHH is supposed
to report on the actual behavior that its finite string
input actually specifies or some other basis.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
The exact meaning of those words would seem to rule out
any other basis.
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its
input D
On 16/05/2025 00:43, olcott wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:In other words you believe that professor Sipser screwed up when he
I overcome the proof of undecidability of the Halting Problem in that
the code that "does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
agreed with these exact words.
Or maybe he just knows what 'if' means.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
That's not a given. It's an 'if'.
<snip>
On 5/15/2025 6:57 PM, Richard Heathfield wrote:
On 16/05/2025 00:43, olcott wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
Or maybe he just knows what 'if' means.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 5/15/2025 5:08 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:35:24 -0500, olcott wrote:
On 5/15/2025 4:18 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in >>>>>>> that the code that "does the opposite of whatever value that HHH >>>>>>> returns" becomes unreachable to DD correctly simulated by HHH.It is not possible for HHH to simulate DD because we are already
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over >>>>>>> and over until HHH sees this repeating pattern and aborts or both >>>>>>> HHH and DD crash due to OOM error.
inside DD when we call HHH:
Since HHH does correctly simulate itself simulating DD we have
complete proof that you are wrong.
I had to write the whole x86utm operating system to make this work.
It is not possible to make this work even by "writing an operating
system"
so whatever you think you are doing it isn't addressing my core point: >>>> you are NOT *fully* simulating DD by HHH because you are already inside >>>> DD when you are calling HHH.
/Flibble
Anyone that is intimately familiar with how multi-tasking operating
systems work will understand how HHH could emulate itself emulating its
input.
What has multi-tasking got to do with it? You are talking out of your
arse, Peter. :)
Anyone that is intimately familiar with multi-tasking
operating systems will know the details of how HHH
emulates itself emulating DDD.
Whenever any HHH is about to begin emulating an input
it requests a separate process context with its own
virtual registers and stack from the x86utm operating
system. Then HHH calls the x86utm operating system
to execute
u32 DebugStep(Registers* master_state,
Registers* slave_state, Decoded_Line_Of_Code* decoded)
each instruction one-at-a-time as cooperative multi-tasking.
Mike already verified that HHH does correctly emulate itself emulating
DDD. He verified this by carefully studying the source-code.
The source code is the C code you posted in this thread, and it has the
problem I described.
/Flibble
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Mike verified that the HHH in the above file
does correctly emulate itself emulating DDD.
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in that
the code that "does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over and
over until HHH sees this repeating pattern and aborts or both HHH and DD >>> crash due to OOM error.
It is not possible for HHH to simulate DD because we are already inside DD >> when we call HHH:
On 5/15/2025 4:18 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in that >>>>> the code that "does the opposite of whatever value that HHH returns" >>>>> becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over and >>>>> over until HHH sees this repeating pattern and aborts or both HHH and >>>>> DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already inside >>>> DD when we call HHH:
Since HHH does correctly simulate itself simulating DD we have complete
proof that you are wrong.
I had to write the whole x86utm operating system to make this work.
It is not possible to make this work even by "writing an operating system" >> so whatever you think you are doing it isn't addressing my core point: you >> are NOT *fully* simulating DD by HHH because you are already inside DD
when you are calling HHH.
/Flibble
Anyone that is intimately familiar with how multi-tasking
operating systems work will understand how HHH could
emulate itself emulating its input.
On 5/15/2025 5:08 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:35:24 -0500, olcott wrote:
On 5/15/2025 4:18 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in >>>>>>> that the code that "does the opposite of whatever value that HHH >>>>>>> returns" becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over >>>>>>> and over until HHH sees this repeating pattern and aborts or both >>>>>>> HHH and DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already
inside DD when we call HHH:
Since HHH does correctly simulate itself simulating DD we have
complete proof that you are wrong.
I had to write the whole x86utm operating system to make this work.
It is not possible to make this work even by "writing an operating
system"
so whatever you think you are doing it isn't addressing my core point: >>>> you are NOT *fully* simulating DD by HHH because you are already inside >>>> DD when you are calling HHH.
/Flibble
Anyone that is intimately familiar with how multi-tasking operating
systems work will understand how HHH could emulate itself emulating its
input.
What has multi-tasking got to do with it? You are talking out of your
arse, Peter. :)
Anyone that is intimately familiar with multi-tasking
operating systems will know the details of how HHH
emulates itself emulating DDD.
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 5/15/2025 6:57 PM, Richard Heathfield wrote:
On 16/05/2025 00:43, olcott wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
Or maybe he just knows what 'if' means.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
It is a verified fact that HHH does simulate DD according
to the rules of the x86 language, thus correctly
until HHH correctly determines that its simulated DD
would never stop running unless aborted
On 5/15/2025 8:27 PM, Richard Heathfield wrote:
On 16/05/2025 02:21, olcott wrote:
On 5/15/2025 6:57 PM, Richard Heathfield wrote:
On 16/05/2025 00:43, olcott wrote:
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
Or maybe he just knows what 'if' means.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If
...and some more, but starting with that one.
When I prove that HHH/DD meets those words and
you still attempt rebuttal by ignoring them
that proves you are dishonest.
On 5/15/2025 9:02 PM, Richard Damon wrote:
On 5/15/25 7:43 PM, olcott wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
No, you just don't know the meaning of them.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Remember, he works in Computation Theory, and thus talks about
PROGRAMS, these BY DEFINITION include all of their algrorithm/code as
part of themselves.
You have admitted/stipuated that YOUR "DD" and "DDD" are NOT program,
but just (non-leaf) "C functions", and thus his statement just doesn't
apply to your system.
Also, "its simulated D would never stop runnign unless aborted" means
exactly that, The D that H was given
cannot possibly ever stop running unless aborted by H
You get waaaayyyy too confused when you try to address
more than one single point at a time. Even then it usually
takes you at least 50 times to actually see the words that
I said.
On 5/15/2025 9:07 PM, Richard Damon wrote:
On 5/15/25 7:25 PM, olcott wrote:
On 5/15/2025 5:08 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:35:24 -0500, olcott wrote:
On 5/15/2025 4:18 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
On 5/15/2025 3:59 PM, Mr Flibble wrote:It is not possible to make this work even by "writing an operating >>>>>> system"
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in >>>>>>>>> that the code that "does the opposite of whatever value that HHH >>>>>>>>> returns" becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>It is not possible for HHH to simulate DD because we are already >>>>>>>> inside DD when we call HHH:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over >>>>>>>>> and over until HHH sees this repeating pattern and aborts or both >>>>>>>>> HHH and DD crash due to OOM error.
Since HHH does correctly simulate itself simulating DD we have
complete proof that you are wrong.
I had to write the whole x86utm operating system to make this work. >>>>>>
so whatever you think you are doing it isn't addressing my core
point:
you are NOT *fully* simulating DD by HHH because you are already
inside
DD when you are calling HHH.
/Flibble
Anyone that is intimately familiar with how multi-tasking operating
systems work will understand how HHH could emulate itself emulating
its
input.
What has multi-tasking got to do with it? You are talking out of your >>>> arse, Peter. :)
Anyone that is intimately familiar with multi-tasking
operating systems will know the details of how HHH
emulates itself emulating DDD.
Whenever any HHH is about to begin emulating an input
it requests a separate process context with its own
virtual registers and stack from the x86utm operating
system. Then HHH calls the x86utm operating system
to execute
u32 DebugStep(Registers* master_state,
Registers* slave_state, Decoded_Line_Of_Code* decoded)
each instruction one-at-a-time as cooperative multi-tasking.
Which means your "simulator" isn't actually a Simulator. it just is
directly running the program in a debug single step mode.
Yes and by the same reasoning an x86 emulator
IS NOT an x86 emulator it IS an actual x86 chip.
Quit acting like a freaking moron you are much
smarter than that.
On 5/16/2025 2:01 AM, Mikko wrote:
On 2025-05-15 21:11:35 +0000, olcott said:void DDD()
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in
that the code that "does the opposite of whatever value that HHH
returns" becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over
and over until HHH sees this repeating pattern and aborts or both
HHH and DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already
inside DD when we call HHH:
A partial simulation is possible. But at some point HHH discontinues
the simulation and returns a guessed answer.
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
HHH simulates DDD the simulated DDD calls HHH(DDD)
HHH simulates DDD the simulated DDD calls HHH(DDD)
HHH simulates DDD the simulated DDD calls HHH(DDD)
HHH simulates DDD the simulated DDD calls HHH(DDD)
HHH simulates DDD the simulated DDD calls HHH(DDD)
How many more times before the fact that DDD correctly simulated by HHH cannot possibly reach its "return" statement?
void DDD()
{
HHH(DDD);
return;
}
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
On 5/16/2025 2:09 AM, Mikko wrote:
On 2025-05-15 23:25:36 +0000, olcott said:
On 5/15/2025 5:08 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:35:24 -0500, olcott wrote:
On 5/15/2025 4:18 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
On 5/15/2025 3:59 PM, Mr Flibble wrote:It is not possible to make this work even by "writing an operating >>>>>> system"
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in >>>>>>>>> that the code that "does the opposite of whatever value that HHH >>>>>>>>> returns" becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over >>>>>>>>> and over until HHH sees this repeating pattern and aborts or both >>>>>>>>> HHH and DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already >>>>>>>> inside DD when we call HHH:
Since HHH does correctly simulate itself simulating DD we have
complete proof that you are wrong.
I had to write the whole x86utm operating system to make this work. >>>>>>
so whatever you think you are doing it isn't addressing my core
point:
you are NOT *fully* simulating DD by HHH because you are already
inside
DD when you are calling HHH.
/Flibble
Anyone that is intimately familiar with how multi-tasking operating
systems work will understand how HHH could emulate itself emulating
its
input.
What has multi-tasking got to do with it? You are talking out of your >>>> arse, Peter. :)
Anyone that is intimately familiar with multi-tasking
operating systems will know the details of how HHH
emulates itself emulating DDD.
That is an implementation detail that is not required by the problem.
It is not an implementation detail when people insist
on rejecting my work because they falsely believe that
HHH cannot correctly simulate itself simulating DDD.
On 5/16/2025 2:07 AM, Mikko wrote:
On 2025-05-15 21:35:24 +0000, olcott said:
On 5/15/2025 4:18 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in >>>>>>> that
the code that "does the opposite of whatever value that HHH returns" >>>>>>> becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over >>>>>>> and
over until HHH sees this repeating pattern and aborts or both HHH >>>>>>> and
DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already
inside
DD when we call HHH:
Since HHH does correctly simulate itself simulating DD we have
complete
proof that you are wrong.
I had to write the whole x86utm operating system to make this work.
It is not possible to make this work even by "writing an operating
system"
so whatever you think you are doing it isn't addressing my core
point: you
are NOT *fully* simulating DD by HHH because you are already inside DD >>>> when you are calling HHH.
/Flibble
Anyone that is intimately familiar with how multi-tasking
operating systems work will understand how HHH could
emulate itself emulating its input.
Simulation is not a multi-tasking problem so knowledge of multi-tasking
operating systems is not relevant.
The simulation of one function in the same program
by another function in the same program does
require cooperative multi-tasking switching from
the simulator to the simulated and back.
(Sometimes parallel processing is
needed in order to perform a simulation in short enough time. An exampe
is weather prediction, where the prediction must be completed before the
predicted weather happens.)
On 5/16/2025 2:15 AM, Mikko wrote:
On 2025-05-16 01:21:04 +0000, olcott said:
On 5/15/2025 6:57 PM, Richard Heathfield wrote:
On 16/05/2025 00:43, olcott wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
Or maybe he just knows what 'if' means.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
It is a verified fact that HHH does simulate DD according
to the rules of the x86 language, thus correctly
until HHH correctly determines that its simulated DD
would never stop running unless aborted
Otherwise true but the "correctly" is not verified.
void DDD()
{
HHH(DDD);
return;
}
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
On 5/16/2025 2:01 AM, Mikko wrote:
On 2025-05-15 21:11:35 +0000, olcott said:
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in that >>>>> the code that "does the opposite of whatever value that HHH returns" >>>>> becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over and >>>>> over until HHH sees this repeating pattern and aborts or both HHH
and DD
crash due to OOM error.
It is not possible for HHH to simulate DD because we are already
inside DD
when we call HHH:
A partial simulation is possible. But at some point HHH discontinues
the simulation and returns a guessed answer.
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
HHH simulates DDD
the simulated DDD calls HHH(DDD)
HHH simulates DDD
the simulated DDD calls HHH(DDD)
HHH simulates DDD
the simulated DDD calls HHH(DDD)
HHH simulates DDD
the simulated DDD calls HHH(DDD)
HHH simulates DDD
the simulated DDD calls HHH(DDD)
How many more times before the fact that
DDD correctly simulated by HHH cannot
possibly reach its "return" statement?
On 5/16/2025 8:46 AM, Richard Damon wrote:
On 5/15/25 10:16 PM, olcott wrote:
On 5/15/2025 9:02 PM, Richard Damon wrote:
On 5/15/25 7:43 PM, olcott wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
No, you just don't know the meaning of them.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
Remember, he works in Computation Theory, and thus talks about
PROGRAMS, these BY DEFINITION include all of their algrorithm/code
as part of themselves.
You have admitted/stipuated that YOUR "DD" and "DDD" are NOT
program, but just (non-leaf) "C functions", and thus his statement
just doesn't apply to your system.
Also, "its simulated D would never stop runnign unless aborted"
means exactly that, The D that H was given
cannot possibly ever stop running unless aborted by H
"Aborted by H" wasn't in the quote.
Mike explains all of the details of how the
above quote does derive a correct Simulating Halt Decider.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
On 5/16/2025 10:45 AM, Richard Damon wrote:
On 5/16/25 11:10 AM, olcott wrote:
On 5/16/2025 2:15 AM, Mikko wrote:
On 2025-05-16 01:21:04 +0000, olcott said:
On 5/15/2025 6:57 PM, Richard Heathfield wrote:
On 16/05/2025 00:43, olcott wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
Or maybe he just knows what 'if' means.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
It is a verified fact that HHH does simulate DD according
to the rules of the x86 language, thus correctly
until HHH correctly determines that its simulated DD
would never stop running unless aborted
Otherwise true but the "correctly" is not verified.
void DDD()
{
HHH(DDD);
return;
}
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
When we fix DDD to be a program, by including the code for the HHH
that is using it, we can tell that if this HHH does simulate its input
correctly, then HHH will never answer.
Yes.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
proves that a partial simulation is correct
*H correctly simulates its input D until*
Proves that it is referring to the HHH that you referred to
*its simulated D would never stop running unless aborted*
On 5/16/2025 10:48 AM, Richard Heathfield wrote:
On 16/05/2025 16:10, olcott wrote:
<snip>
void DDD()
{
HHH(DDD);
return;
}
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
Anyone who knows C knows that there isn't much HHH can do with the
pointer value it's given. It can call DDD:
(*p)();
Sure when you make sure to totally ignore crucial
words in the specification of *HHH SIMULATES ITS INPUT*
then by using the strawman error on these dishonestly
changed words they are easy to rebut.
https://en.wikipedia.org/wiki/Straw_man
On the other hand when honest C programmers see
those words they will think of something like a C
interpreter written in C is doing the simulation.
On 5/16/2025 10:48 AM, Richard Heathfield wrote:
On 16/05/2025 16:10, olcott wrote:
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
Anyone who knows C knows that there isn't much HHH can do with
the pointer value it's given. It can call DDD:
(*p)();
Sure when you make sure to totally ignore crucial
words
then by using the strawman error on these dishonestly
changed words they are easy to rebut.
https://en.wikipedia.org/wiki/Straw_man
On the other hand when honest C programmers see
those words they will think of something like a C
interpreter written in C is doing the simulation.
On 5/16/2025 8:20 PM, Richard Heathfield wrote:
On 17/05/2025 00:59, olcott wrote:
On 5/16/2025 10:48 AM, Richard Heathfield wrote:
On 16/05/2025 16:10, olcott wrote:
<snip>
Only damned liars would remove this key context.
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
Anyone who knows C knows that there isn't much HHH can do
with the pointer value it's given. It can call DDD:
(*p)();
Sure when you make sure to totally ignore crucial
words
The crucial words - *so* crucial that you keep on repeating
them - are 'Anyone who knows C'.
You don't.
then by using the strawman error on these dishonestly
changed words they are easy to rebut.
I didn't change your words; I just rebutted them.
https://en.wikipedia.org/wiki/Straw_man
"A straw man fallacy (sometimes written as strawman) is the
informal fallacy of refuting an argument different from the one
actually under discussion."
When you said "Anyone who knows C" (as you have said very
often), you yourself opened the discussion.
If you don't want people to attack your woeful understanding if
the language, don't make the claim that you know the language.
On the other hand when honest C programmers see
those words they will think of something like a C
interpreter written in C is doing the simulation.
If you are claiming to have written a C interpreter, that's a
huge claim without any evidence whatsoever to support it.
When you dishonestly remove the context that you are
replying to fools might think that your rebuttal has merit.
On 5/16/2025 8:20 PM, Richard Heathfield wrote:
On 17/05/2025 00:59, olcott wrote:
On 5/16/2025 10:48 AM, Richard Heathfield wrote:
On 16/05/2025 16:10, olcott wrote:
<snip>
Only damned liars would remove this key context.
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
Anyone who knows C knows that there isn't much HHH can do with the
pointer value it's given. It can call DDD:
(*p)();
Sure when you make sure to totally ignore crucial
words
The crucial words - *so* crucial that you keep on repeating them - are
'Anyone who knows C'.
You don't.
then by using the strawman error on these dishonestly
changed words they are easy to rebut.
I didn't change your words; I just rebutted them.
https://en.wikipedia.org/wiki/Straw_man
"A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually under
discussion."
When you said "Anyone who knows C" (as you have said very often), you
yourself opened the discussion.
If you don't want people to attack your woeful understanding if the
language, don't make the claim that you know the language.
On the other hand when honest C programmers see
those words they will think of something like a C
interpreter written in C is doing the simulation.
If you are claiming to have written a C interpreter, that's a huge
claim without any evidence whatsoever to support it.
When you dishonestly remove the context that you are
replying to fools might think that your rebuttal has merit.
On 5/16/2025 7:23 PM, Richard Damon wrote:
On 5/16/25 7:59 PM, olcott wrote:
On 5/16/2025 10:48 AM, Richard Heathfield wrote:
On 16/05/2025 16:10, olcott wrote:
<snip>
void DDD()
{
HHH(DDD);
return;
}
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
Anyone who knows C knows that there isn't much HHH can do with the
pointer value it's given. It can call DDD:
(*p)();
Sure when you make sure to totally ignore crucial
words in the specification of *HHH SIMULATES ITS INPUT*
then by using the strawman error on these dishonestly
changed words they are easy to rebut.
https://en.wikipedia.org/wiki/Straw_man
On the other hand when honest C programmers see
those words they will think of something like a C
interpreter written in C is doing the simulation.
Nope, I have explained it, but it seems you are just to stupid to
understand (and if you stop here you will just prove your stupidity)
Yes, H uses its partial simulation to make the decision, and that can
be from the partial simulation.
But the criteria about being non-halting is based at looking at the
hypothetical correct simulation of this exact input (that is the
meaninf of its simulated input would not halt) and if that simulation
will ever reach a final state, which it does.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H
correctly simulates its input D until
H correctly determines that
its simulated D would never stop running unless aborted
THIS HAS ONE MEANING
*its simulated D would never stop running unless aborted*
its simulated input calls HHH in recursive emulation.
If this recursive emulation is not aborted then DD() never stops.
On 5/16/2025 9:44 PM, Richard Heathfield wrote:
On 17/05/2025 03:24, olcott wrote:
When you dishonestly remove the context that you are
replying to fools might think that your rebuttal has merit.
The context you claim was 'dishonestly' removed is:
void DDD()
{
HHH(DDD);
return;
}
with which we are all too, too familiar.
The context merely shows that the only information HHH receives
is a pointer to a function.
That's not enough for HHH to be able to do what you claim for
it *within the rules of C*.
Unless there is also an interpreter also written in C.
Any competent C programmer would know that C programs
can be simulated by C interpreters. If they don't know
this then that are not competent.
Your stance on the Linz proof shouldn't be about C but about
logic, and
This post was not about Linz.
As long as you continue to make incorrect claims about the
language, I reserve the right to rebut them.
It is possible to create a C function that
simulates the source-code of other C functions.
The essential idea of this is a C interpreter.
The actual HHH uses x86 emulation that is way
over most peoples heads.
On 5/16/2025 11:09 PM, Richard Heathfield wrote:
On 17/05/2025 04:49, olcott wrote:
<snip>
It is possible to create a C function that
simulates the source-code of other C functions.
The essential idea of this is a C interpreter.
No. You clearly have no idea what an interpreter is.
A C interpreter translates C, just as a C compiler translates
C, the difference being that the compiler writes down the
translation (like a book translator in a publishing house)
while the interpreter says it out loud, so to speak (like an
interpreter at a United Nations meeting).
In each case, the input is C, not machine code.
The actual HHH uses x86 emulation that is way
over most peoples heads.
Clearly not a C interpreter, then.
Modern language are a hybrid between compiling
and interpreting. Java compiles to byte code.
Interpreters translate code line-by-line and immediately execute
each one in real-time, without a separate compilation phase. The
interpreter effectively runs and translates the program
simultaneously. This means changes to the code can take effect
instantly, without waiting for compilation. But this flexibility
comes at a performance cost relative to compiled programs.
https://thelinuxcode.com/interpreters-c-programming/
void DDD()
{
HHH(DDD);
return;
}
We can easily imagine what the behavior
of DDD correctly simulated by HHH is
On 5/16/2025 9:58 PM, Richard Damon wrote:
On 5/16/25 10:46 PM, olcott wrote:
On 5/16/2025 7:23 PM, Richard Damon wrote:
On 5/16/25 7:59 PM, olcott wrote:
On 5/16/2025 10:48 AM, Richard Heathfield wrote:
On 16/05/2025 16:10, olcott wrote:
<snip>
void DDD()
{
HHH(DDD);
return;
}
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
Anyone who knows C knows that there isn't much HHH can do with the >>>>>> pointer value it's given. It can call DDD:
(*p)();
Sure when you make sure to totally ignore crucial
words in the specification of *HHH SIMULATES ITS INPUT*
then by using the strawman error on these dishonestly
changed words they are easy to rebut.
https://en.wikipedia.org/wiki/Straw_man
On the other hand when honest C programmers see
those words they will think of something like a C
interpreter written in C is doing the simulation.
Nope, I have explained it, but it seems you are just to stupid to
understand (and if you stop here you will just prove your stupidity)
Yes, H uses its partial simulation to make the decision, and that
can be from the partial simulation.
But the criteria about being non-halting is based at looking at the
hypothetical correct simulation of this exact input (that is the
meaninf of its simulated input would not halt) and if that
simulation will ever reach a final state, which it does.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H
correctly simulates its input D until
H correctly determines that
its simulated D would never stop running unless aborted
THIS HAS ONE MEANING
*its simulated D would never stop running unless aborted*
Right. "its simulated" specifying which input we are talkig about.
Would never stop running unless aborted, a desctiption of a correct
simulation, pointing out that this aborting just talked about doesn't
happen to this simulation.
its simulated input calls HHH in recursive emulation.
If this recursive emulation is not aborted then DD() never stops.
But that HHH is the original HHH that WILL abort
It is the job of HHH to determine whether or not its
input *WOULD NEVER STOP RUNNING UNLESS ABORTED*
On 5/16/2025 9:42 PM, Richard Damon wrote:
On 5/16/25 10:24 PM, olcott wrote:
On 5/16/2025 8:20 PM, Richard Heathfield wrote:
On 17/05/2025 00:59, olcott wrote:
On 5/16/2025 10:48 AM, Richard Heathfield wrote:
On 16/05/2025 16:10, olcott wrote:
<snip>
Only damned liars would remove this key context.
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
Anyone who knows C knows that there isn't much HHH can do with the >>>>>> pointer value it's given. It can call DDD:
(*p)();
Sure when you make sure to totally ignore crucial
words
The crucial words - *so* crucial that you keep on repeating them -
are 'Anyone who knows C'.
You don't.
then by using the strawman error on these dishonestly
changed words they are easy to rebut.
I didn't change your words; I just rebutted them.
https://en.wikipedia.org/wiki/Straw_man
"A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually
under discussion."
When you said "Anyone who knows C" (as you have said very often),
you yourself opened the discussion.
If you don't want people to attack your woeful understanding if the
language, don't make the claim that you know the language.
On the other hand when honest C programmers see
those words they will think of something like a C
interpreter written in C is doing the simulation.
If you are claiming to have written a C interpreter, that's a huge
claim without any evidence whatsoever to support it.
When you dishonestly remove the context that you are
replying to fools might think that your rebuttal has merit.
But that is your standard procedure, that and lying about the meaning
of words.
The fact that you need to always "paraphrase" statements and
requirements so you can change them just shows how you try to work.
Halt Deciders need to decide Halting, which is a property of the
direct running of the program given to the decider via a full
representation.
There are times where this doesn't seem to make sense.
Unless HHH(DDD) aborts its simulation then not even DDD() halts.
On 5/16/2025 2:09 AM, Mikko wrote:
On 2025-05-15 23:25:36 +0000, olcott said:
On 5/15/2025 5:08 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:35:24 -0500, olcott wrote:
On 5/15/2025 4:18 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
On 5/15/2025 3:59 PM, Mr Flibble wrote:It is not possible to make this work even by "writing an operating >>>>>> system"
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in >>>>>>>>> that the code that "does the opposite of whatever value that HHH >>>>>>>>> returns" becomes unreachable to DD correctly simulated by HHH. >>>>>>>>>
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over >>>>>>>>> and over until HHH sees this repeating pattern and aborts or both >>>>>>>>> HHH and DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already >>>>>>>> inside DD when we call HHH:
Since HHH does correctly simulate itself simulating DD we have
complete proof that you are wrong.
I had to write the whole x86utm operating system to make this work. >>>>>>
so whatever you think you are doing it isn't addressing my core point: >>>>>> you are NOT *fully* simulating DD by HHH because you are already inside >>>>>> DD when you are calling HHH.
/Flibble
Anyone that is intimately familiar with how multi-tasking operating
systems work will understand how HHH could emulate itself emulating its >>>>> input.
What has multi-tasking got to do with it? You are talking out of your >>>> arse, Peter. :)
Anyone that is intimately familiar with multi-tasking
operating systems will know the details of how HHH
emulates itself emulating DDD.
That is an implementation detail that is not required by the problem.
It is not an implementation detail when people insist
on rejecting my work because they falsely believe that
HHH cannot correctly simulate itself simulating DDD.
On 5/16/2025 2:07 AM, Mikko wrote:
On 2025-05-15 21:35:24 +0000, olcott said:
On 5/15/2025 4:18 PM, Mr Flibble wrote:
On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in that >>>>>>> the code that "does the opposite of whatever value that HHH returns" >>>>>>> becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over and >>>>>>> over until HHH sees this repeating pattern and aborts or both HHH and >>>>>>> DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already inside >>>>>> DD when we call HHH:
Since HHH does correctly simulate itself simulating DD we have complete >>>>> proof that you are wrong.
I had to write the whole x86utm operating system to make this work.
It is not possible to make this work even by "writing an operating system" >>>> so whatever you think you are doing it isn't addressing my core point: you >>>> are NOT *fully* simulating DD by HHH because you are already inside DD >>>> when you are calling HHH.
/Flibble
Anyone that is intimately familiar with how multi-tasking
operating systems work will understand how HHH could
emulate itself emulating its input.
Simulation is not a multi-tasking problem so knowledge of multi-tasking
operating systems is not relevant.
The simulation of one function in the same program
by another function in the same program does
require cooperative multi-tasking switching from
the simulator to the simulated and back.
On 5/16/2025 2:15 AM, Mikko wrote:
On 2025-05-16 01:21:04 +0000, olcott said:
On 5/15/2025 6:57 PM, Richard Heathfield wrote:
On 16/05/2025 00:43, olcott wrote:
On 5/15/2025 6:18 PM, Richard Damon wrote:
On 5/15/25 4:47 PM, olcott wrote:
I overcome the proof of undecidability of the Halting
Problem in that the code that
"does the opposite of whatever value that HHH returns"
becomes unreachable to DD correctly simulated by HHH.
Nope, only to youtr INCORRECTLY simuated by HHH.
In other words you believe that professor Sipser
screwed up when he agreed with these exact words.
Or maybe he just knows what 'if' means.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
It is a verified fact that HHH does simulate DD according
to the rules of the x86 language, thus correctly
until HHH correctly determines that its simulated DD
would never stop running unless aborted
Otherwise true but the "correctly" is not verified.
void DDD()
{
HHH(DDD);
return;
}
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
On Fri, 16 May 2025 10:00:26 -0500, olcott wrote:
On 5/16/2025 2:01 AM, Mikko wrote:
On 2025-05-15 21:11:35 +0000, olcott said:void DDD()
On 5/15/2025 3:59 PM, Mr Flibble wrote:
On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
I overcome the proof of undecidability of the Halting Problem in
that the code that "does the opposite of whatever value that HHH
returns" becomes unreachable to DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself again over
and over until HHH sees this repeating pattern and aborts or both
HHH and DD crash due to OOM error.
It is not possible for HHH to simulate DD because we are already
inside DD when we call HHH:
A partial simulation is possible. But at some point HHH discontinues
the simulation and returns a guessed answer.
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
HHH simulates DDD the simulated DDD calls HHH(DDD)
HHH simulates DDD the simulated DDD calls HHH(DDD)
HHH simulates DDD the simulated DDD calls HHH(DDD)
HHH simulates DDD the simulated DDD calls HHH(DDD)
HHH simulates DDD the simulated DDD calls HHH(DDD)
How many more times before the fact that DDD correctly simulated by HHH
cannot possibly reach its "return" statement?
How many more times before you realise that this recursion is due to the category error I have identified and as such it is undecidable.
On 5/16/2025 9:58 PM, Richard Damon wrote:
On 5/16/25 10:46 PM, olcott wrote:
On 5/16/2025 7:23 PM, Richard Damon wrote:
On 5/16/25 7:59 PM, olcott wrote:
On 5/16/2025 10:48 AM, Richard Heathfield wrote:
On 16/05/2025 16:10, olcott wrote:
<snip>
void DDD()
{
HHH(DDD);
return;
}
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
Anyone who knows C knows that there isn't much HHH can do with the >>>>>> pointer value it's given. It can call DDD:
(*p)();
Sure when you make sure to totally ignore crucial
words in the specification of *HHH SIMULATES ITS INPUT*
then by using the strawman error on these dishonestly
changed words they are easy to rebut.
https://en.wikipedia.org/wiki/Straw_man
On the other hand when honest C programmers see
those words they will think of something like a C
interpreter written in C is doing the simulation.
Nope, I have explained it, but it seems you are just to stupid to
understand (and if you stop here you will just prove your stupidity)
Yes, H uses its partial simulation to make the decision, and that
can be from the partial simulation.
But the criteria about being non-halting is based at looking at the
hypothetical correct simulation of this exact input (that is the
meaninf of its simulated input would not halt) and if that
simulation will ever reach a final state, which it does.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H
correctly simulates its input D until
H correctly determines that
its simulated D would never stop running unless aborted
THIS HAS ONE MEANING
*its simulated D would never stop running unless aborted*
Right. "its simulated" specifying which input we are talkig about.
Would never stop running unless aborted, a desctiption of a correct
simulation, pointing out that this aborting just talked about doesn't
happen to this simulation.
its simulated input calls HHH in recursive emulation.
If this recursive emulation is not aborted then DD() never stops.
But that HHH is the original HHH that WILL abort
It is the job of HHH to determine whether or not its
input *WOULD NEVER STOP RUNNING UNLESS ABORTED*
When you keep switching this back to
*WHAT HAPPENS WHEN DDD IS ABORTED*
You become a damned liar.
HHH and DDD and everything that HHH calls
*WOULD NEVER STOP RUNNING UNLESS DDD IS ABORTED*
On 5/16/2025 9:42 PM, Richard Damon wrote:
On 5/16/25 10:24 PM, olcott wrote:
On 5/16/2025 8:20 PM, Richard Heathfield wrote:
On 17/05/2025 00:59, olcott wrote:
On 5/16/2025 10:48 AM, Richard Heathfield wrote:
On 16/05/2025 16:10, olcott wrote:
<snip>
Only damned liars would remove this key context.
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
Anyone who knows C knows that there isn't much HHH can do with the >>>>>> pointer value it's given. It can call DDD:
(*p)();
Sure when you make sure to totally ignore crucial
words
The crucial words - *so* crucial that you keep on repeating them -
are 'Anyone who knows C'.
You don't.
then by using the strawman error on these dishonestly
changed words they are easy to rebut.
I didn't change your words; I just rebutted them.
https://en.wikipedia.org/wiki/Straw_man
"A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually
under discussion."
When you said "Anyone who knows C" (as you have said very often),
you yourself opened the discussion.
If you don't want people to attack your woeful understanding if the
language, don't make the claim that you know the language.
On the other hand when honest C programmers see
those words they will think of something like a C
interpreter written in C is doing the simulation.
If you are claiming to have written a C interpreter, that's a huge
claim without any evidence whatsoever to support it.
When you dishonestly remove the context that you are
replying to fools might think that your rebuttal has merit.
But that is your standard procedure, that and lying about the meaning
of words.
The fact that you need to always "paraphrase" statements and
requirements so you can change them just shows how you try to work.
Halt Deciders need to decide Halting, which is a property of the
direct running of the program given to the decider via a full
representation.
There are times where this doesn't seem to make sense.
Unless HHH(DDD) aborts its simulation then not even DDD() halts.
Since DD(), when made into a program, will halt when run, something
you have even agreed to, that means that by the clear meaning of the
words that HHH(DD) should say Halting, but you try to justify why your
lie might be correct, all based on lies about what a program actually
is, which shows up big by the fact that you have stated that you DD
isn't a program, and thus not what it needs to be to use.
Sorry, you are just proving how much of a liar you are.
On 5/16/2025 10:33 PM, Richard Heathfield wrote:
On 17/05/2025 03:55, olcott wrote:
On 5/16/2025 9:44 PM, Richard Heathfield wrote:
On 17/05/2025 03:24, olcott wrote:
<snip>
When you dishonestly remove the context that you are
replying to fools might think that your rebuttal has merit.
The context you claim was 'dishonestly' removed is:
void DDD()
{
HHH(DDD);
return;
}
with which we are all too, too familiar.
The context merely shows that the only information HHH receives is a
pointer to a function.
That's not enough for HHH to be able to do what you claim for it
*within the rules of C*.
Unless there is also an interpreter also written in C.
No, not even then, for reasons I have already explained.
Any competent C programmer would know that C programs
can be simulated by C interpreters. If they don't know
this then that are not competent.
A C interpreter (eg CH or CINT, both of which have Wiki pages, in case
you're interested) doesn't simulate C code. It interprets C code. You
don't pass C code to HHH in the form of a char * - "void
DDD()\n{\n\tHHH(DDD);\n\treturn;\n}\n", say - to HHH(). You pass a
function pointer. All HHH() can do with that pointer value is:
It is possible to create a C function that
simulates the source-code of other C functions.
The essential idea of this is a C interpreter.
The actual HHH uses x86 emulation that is way
over most peoples heads. When I said that HHH
simulates DDD reviewers are not free to ignore
the word "simulate".
They do this because they only glance at a
couple of my words to artificially contrive
some fake rebuttal.
On 2025-05-16 15:10:18 +0000, olcott said:
void DDD()
{
HHH(DDD);
return;
}
Anyone that knows C can tell that when HHH does simulate
DDD correctly that it keeps getting deeper in recursive
simulation until aborted or OOM error.
No, there are peole who do know C but don't know that HHH is not
void HHH(void (*f)(void)) {}
On 5/16/25 11:49 PM, olcott wrote:
It is possible to create a C function that
simulates the source-code of other C functions.
The essential idea of this is a C interpreter.
WHich means you need to pass it the source code of the funciton.
If they know C they should know that it's
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments and returns no value.
Richard Heathfield <rjh@cpax.org.uk> writes:
...
If they know C they should know that it's
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments and returns no
value.
Yes, but I am surprised that you are being so modern!! You used to
favour C90 and didn't really care for anything more recent.
Empty ()s in a declarator were made obsolete in C17 and made equivalent
to (void) in C23. Prior to C23 a parameter that is pointer to a
function taking no arguments would have to have been written as
u32 HHH(void (*P)(void))
and after C23 the (probable) intended meaning would have to be written
as
u32 HHH(void (*P)(...))
(Caveat: I'm not properly up to date anymore and, this not being
comp.lang.c, I may not be corrected by People Who Really Know.)
On 18/05/2025 23:18, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
...
If they know C they should know that it'sYes, but I am surprised that you are being so modern!! You used to
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments and returns no >>> value.
favour C90 and didn't really care for anything more recent.
I am just as surprised that you missed the distinction I was making, which was between these:
void HHH(void (*f)(void))
u32 HHH(void (*P)())
Empty parentheses had nothing to do with my point. On line 16 we find: typedef uint32_t u32;
uint32_t != void.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 18/05/2025 23:18, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
...
If they know C they should know that it'sYes, but I am surprised that you are being so modern!! You used to
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments and returns no >>>> value.
favour C90 and didn't really care for anything more recent.
I am just as surprised that you missed the distinction I was making, which >> was between these:
void HHH(void (*f)(void))
u32 HHH(void (*P)())
Empty parentheses had nothing to do with my point. On line 16 we find:
typedef uint32_t u32;
uint32_t != void.
Yes, I got the distinction you were making,
but I must have got confused
about the referent of "it" in the part I quoted. I was hoping to add
to the discussion despite ignoring your main point. Sorry.
On 5/18/2025 7:27 PM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 18/05/2025 23:18, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
...
If they know C they should know that it'sYes, but I am surprised that you are being so modern!! You
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments
and returns no
value.
used to
favour C90 and didn't really care for anything more recent.
I am just as surprised that you missed the distinction I was
making, which
was between these:
void HHH(void (*f)(void))
u32 HHH(void (*P)())
Empty parentheses had nothing to do with my point. On line 16
we find:
typedef uint32_t u32;
uint32_t != void.
Yes, I got the distinction you were making, but I must have got
confused
about the referent of "it" in the part I quoted. I was hoping
to add
to the discussion despite ignoring your main point. Sorry.
*Copied from the original post that he responded to*
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself
again over and over until HHH sees this repeating pattern
and aborts or both HHH and DD crash due to OOM error.
His main point was to dodge the actual meaning
of the word *simulate*
It was stipulated that HHH does simulate DDD.
No need to check every little punctuation mark.
On 5/18/2025 7:27 PM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 18/05/2025 23:18, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
...
If they know C they should know that it'sYes, but I am surprised that you are being so modern!! You used to
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments and
returns no
value.
favour C90 and didn't really care for anything more recent.
I am just as surprised that you missed the distinction I was making,
which
was between these:
void HHH(void (*f)(void))
u32 HHH(void (*P)())
Empty parentheses had nothing to do with my point. On line 16 we find:
typedef uint32_t u32;
uint32_t != void.
Yes, I got the distinction you were making, but I must have got confused
about the referent of "it" in the part I quoted. I was hoping to add
to the discussion despite ignoring your main point. Sorry.
*Copied from the original post that he responded to*
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself
again over and over until HHH sees this repeating pattern
and aborts or both HHH and DD crash due to OOM error.
His main point was to dodge the actual meaning
of the word *simulate*
On 5/18/2025 8:02 PM, Richard Heathfield wrote:
On 19/05/2025 01:33, olcott wrote:
On 5/18/2025 7:27 PM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
[Apologies for not snipping. This one was hard to know how best to
edit down.]
On 18/05/2025 23:18, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
...
If they know C they should know that it'sYes, but I am surprised that you are being so modern!! You used to >>>>>> favour C90 and didn't really care for anything more recent.
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments and
returns no
value.
I am just as surprised that you missed the distinction I was
making, which
was between these:
void HHH(void (*f)(void))
u32 HHH(void (*P)())
Empty parentheses had nothing to do with my point. On line 16 we find: >>>>> typedef uint32_t u32;
uint32_t != void.
Yes, I got the distinction you were making, but I must have got
confused
about the referent of "it" in the part I quoted. I was hoping to add >>>> to the discussion despite ignoring your main point. Sorry.
*Copied from the original post that he responded to*
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Not so. The post I responded to was Message-ID: <1009lm9$b15q$1@dont-
email.me>
There was a lot of quoted material, none of which mentioned int DD(),
although it did mention a void DDD().
The only original material was:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
No, there are peole who do know C but don't know that HHH is not
void HHH(void (*f)(void)) {} and how therefore cannot tell that
HHH does simulate DDD.
It was stipulated that HHH does simulate DDD.
No need to check every little punctuation mark.
On 5/18/2025 9:08 PM, Richard Heathfield wrote:There is a way it could be done within the rules of C, but the
On 19/05/2025 02:24, olcott wrote:
It was stipulated that HHH does simulate DDD.
That's all right then.
It's stipulated that you are correct.
Unless is it known that one C function
cannot possibly simulate another the
stipulation must be accepted by anyone
wanting an honest dialogue.
On 5/18/2025 11:12 PM, Richard Heathfield wrote:
On 19/05/2025 04:49, olcott wrote:
...a load of nonsense that didn't address my reply at all. I
won't rebut it point by point because I have already dealt with
all of his remarks, some of them several times over.
< SNIP! >
I'm beginning to wonder whether he ever learned to read for
comprehension.
That you tried to get away with dodging my point
and were mad when you got busted is noted.
I have an OCD like focus on a few single points.
Most all of my reviewers are totally scatter-brained
not being able to stay focused on a single point until
complete closure is achieved.
On 5/18/2025 11:57 PM, Richard Heathfield wrote:
On 19/05/2025 05:25, olcott wrote:
On 5/18/2025 11:12 PM, Richard Heathfield wrote:
On 19/05/2025 04:49, olcott wrote:
...a load of nonsense that didn't address my reply at all. I
won't rebut it point by point because I have already dealt
with all of his remarks, some of them several times over.
< SNIP! >
I'm beginning to wonder whether he ever learned to read for
comprehension.
That you tried to get away with dodging my point
I'm not dodging your point. I'm simply not interested in
debating your point when it is already being so expertly
debated by Mike Terry and
Mike Terry's recent post
Richard Heathfield <rjh@cpax.org.uk> writes:
...
If they know C they should know that it's
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments and returns no
value.
Yes, but I am surprised that you are being so modern!! You used to
favour C90 and didn't really care for anything more recent.
Empty ()s in a declarator were made obsolete in C17 and made equivalent
to (void) in C23. Prior to C23 a parameter that is pointer to a
function taking no arguments would have to have been written as
u32 HHH(void (*P)(void))
and after C23 the (probable) intended meaning would have to be written
as
u32 HHH(void (*P)(...))
(Caveat: I'm not properly up to date anymore and, this not being
comp.lang.c, I may not be corrected by People Who Really Know.)
On 17/05/2025 13:59, Richard Damon wrote:
On 5/16/25 11:49 PM, olcott wrote:
<snip>
It is possible to create a C function that
simulates the source-code of other C functions.
The essential idea of this is a C interpreter.
WHich means you need to pass it the source code of the funciton.
I'm not entirely sure that he knows what source code is.
In computing, source code, or simply code or source, is a plain text
computer program written in a programming language. A programmer
writes the human readable source code to control the behavior of a
computer.
On 5/18/2025 7:27 PM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 18/05/2025 23:18, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
...
If they know C they should know that it'sYes, but I am surprised that you are being so modern!! You used to
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments and returns no >>>>> value.
favour C90 and didn't really care for anything more recent.
I am just as surprised that you missed the distinction I was making, which >>> was between these:
void HHH(void (*f)(void))
u32 HHH(void (*P)())
Empty parentheses had nothing to do with my point. On line 16 we find:
typedef uint32_t u32;
uint32_t != void.
Yes, I got the distinction you were making, but I must have got confused
about the referent of "it" in the part I quoted. I was hoping to add
to the discussion despite ignoring your main point. Sorry.
*Copied from the original post that he responded to*
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD) to simulate itself
again over and over until HHH sees this repeating pattern
and aborts or both HHH and DD crash due to OOM error.
His main point was to dodge the actual meaning
of the word *simulate*
On 5/18/2025 8:02 PM, Richard Heathfield wrote:
On 19/05/2025 01:33, olcott wrote:
On 5/18/2025 7:27 PM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
[Apologies for not snipping. This one was hard to know how best to edit down.]
On 18/05/2025 23:18, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
...
If they know C they should know that it'sYes, but I am surprised that you are being so modern!! You used to >>>>>> favour C90 and didn't really care for anything more recent.
u32 HHH(void (*P)()), according to Halt7.c.
It takes a pointer to a function that accepts no arguments and returns no
value.
I am just as surprised that you missed the distinction I was making, which
was between these:
void HHH(void (*f)(void))
u32 HHH(void (*P)())
Empty parentheses had nothing to do with my point. On line 16 we find: >>>>> typedef uint32_t u32;
uint32_t != void.
Yes, I got the distinction you were making, but I must have got confused >>>> about the referent of "it" in the part I quoted. I was hoping to add >>>> to the discussion despite ignoring your main point. Sorry.
*Copied from the original post that he responded to*
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Not so. The post I responded to was Message-ID: <1009lm9$b15q$1@dont- email.me>
There was a lot of quoted material, none of which mentioned int DD(),
although it did mention a void DDD().
The only original material was:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
No, there are peole who do know C but don't know that HHH is not
void HHH(void (*f)(void)) {} and how therefore cannot tell that
HHH does simulate DDD.
It was stipulated that HHH does simulate DDD.
No need to check every little punctuation mark.
On 5/18/2025 9:08 PM, Richard Heathfield wrote:
On 19/05/2025 02:24, olcott wrote:
It was stipulated that HHH does simulate DDD.
That's all right then.
It's stipulated that you are correct.
Unless is it known that one C function
cannot possibly simulate another the
stipulation must be accepted by anyone
wanting an honest dialogue.
On 5/18/2025 11:57 PM, Richard Heathfield wrote:
On 19/05/2025 05:25, olcott wrote:
On 5/18/2025 11:12 PM, Richard Heathfield wrote:
On 19/05/2025 04:49, olcott wrote:
...a load of nonsense that didn't address my reply at all. I won't
rebut it point by point because I have already dealt with all of his
remarks, some of them several times over.
< SNIP! >
I'm beginning to wonder whether he ever learned to read for comprehension. >>>>
That you tried to get away with dodging my point
I'm not dodging your point. I'm simply not interested in debating your
point when it is already being so expertly debated by Mike Terry and
Mike Terry's recent post
On 5/14/2025 7:36 PM, Mike Terry wrote: https://al.howardknight.net/?STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
was succinct and correct and explained
all of the details of how a simulating halt decider could be
derived from these words:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 2025-05-18 11:09:57 +0000, Richard Heathfield said:
On 17/05/2025 13:59, Richard Damon wrote:
On 5/16/25 11:49 PM, olcott wrote:
<snip>
It is possible to create a C function that
simulates the source-code of other C functions.
The essential idea of this is a C interpreter.
WHich means you need to pass it the source code of the funciton.
I'm not entirely sure that he knows what source code is.
Should be easy eanough to find out. The first paragraph on
https://en.wikipedia.org/wiki/Source_code
On 5/18/2025 11:12 PM, Richard Heathfield wrote:
On 19/05/2025 04:49, olcott wrote:
...a load of nonsense that didn't address my reply at all. I won't
rebut it point by point because I have already dealt with all of his
remarks, some of them several times over.
< SNIP! >
I'm beginning to wonder whether he ever learned to read for
comprehension.
That you tried to get away with dodging my point
and were mad when you got busted is noted.
I have an OCD like focus on a few single points.
Most all of my reviewers are totally scatter-brained
not being able to stay focused on a single point until
complete closure is achieved.
On 5/18/2025 9:08 PM, Richard Heathfield wrote:
On 19/05/2025 02:24, olcott wrote:
It was stipulated that HHH does simulate DDD.
That's all right then.
It's stipulated that you are correct.
Unless is it known that one C function
cannot possibly simulate another the
stipulation must be accepted by anyone
wanting an honest dialogue.
On 19/05/2025 10:23, Mikko wrote:
On 2025-05-18 11:09:57 +0000, Richard Heathfield said:
On 17/05/2025 13:59, Richard Damon wrote:
On 5/16/25 11:49 PM, olcott wrote:
<snip>
It is possible to create a C function that
simulates the source-code of other C functions.
The essential idea of this is a C interpreter.
WHich means you need to pass it the source code of the funciton.
I'm not entirely sure that he knows what source code is.
Should be easy eanough to find out. The first paragraph on
https://en.wikipedia.org/wiki/Source_code
I'm not entirely sure that he reads terribly well.
On 2025-05-19 10:08:35 +0000, Richard Heathfield said:
On 19/05/2025 10:23, Mikko wrote:
On 2025-05-18 11:09:57 +0000, Richard Heathfield said:
On 17/05/2025 13:59, Richard Damon wrote:
On 5/16/25 11:49 PM, olcott wrote:
<snip>
It is possible to create a C function that
simulates the source-code of other C functions.
The essential idea of this is a C interpreter.
WHich means you need to pass it the source code of the
funciton.
I'm not entirely sure that he knows what source code is.
Should be easy eanough to find out. The first paragraph on
https://en.wikipedia.org/wiki/Source_code
I'm not entirely sure that he reads terribly well.
No reason to be. But I havn't seen any web pages that tell how
one could read better.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 149:10:00 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,764 |