On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to
stop at HHH's first departure from the rules of the C programming
language (or at least the first departure I spot).
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ", ((u32*)*destination) >>>>> [-1]);
Output("CopyMachineCode destination[-2]: ", ((u32*)*destination) >>>>> [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well, but
you make essentially the same mistake --- writing to memory that your
program doesn't own --- no fewer than four times in a single function.
I'll ignore the syntax error (a null statement at file scope is a
rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null
pointer constant... which is fine as long as you don't try to deref
it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax
errors, remember). destination is a null pointer, so destination[N]
derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you /dare/
to impugn other people's C knowledge! Crack a book, for pity's sake. >>>>>
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to
dereference a null pointer, you have no business trying to teach
anyone anything about C.
Your code is the work of a programmer so hideously incompetent that
'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about denigrating
other people's C knowledge is the height of arrogant hypocrisy.
That's to be expected, and PO's response ought to be to explain it so
that you understand. Instead he goes off on one of his rants, so
blamewise it's really down to PO.
PO's halt7.c is compiled (it is not linked), then the obj file is fed
as input to his x87utm.exe which is a kind of x86 obj code execution
environment. x87utm provides a number of primative calls that halt7.c
code can make, such as Allocate(), used to allocate a block of memory
for use in halt7.c. Within halt7.c code calls an Allocate() function,
and x86utm intercepts that and performs the function internally, then
jumps the calling code in halt7.c over the Allocate call where it
continues as normal. The call never goes to the implementation of
Allocate in halt7.c, so the null pointer dereferencing does not
actually occur. There are a whole bunch of similar x86utm primitive
operations that work in the same way.
PO should have said all that, not me, but it seems he's not interested
in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
Op 08.mei.2025 om 19:00 schreef olcott:
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I
plan to stop at HHH's first departure from the rules of
the C programming language (or at least the first
departure I spot).
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very
well, but you make essentially the same mistake --- writing
to memory that your program doesn't own --- no fewer than
four times in a single function.
I'll ignore the syntax error (a null statement at file
scope is a rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a
null pointer constant... which is fine as long as you
don't try to deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring
syntax errors, remember). destination is a null pointer,
so destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And
you / dare/ to impugn other people's C knowledge! Crack a
book, for pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad
idea to dereference a null pointer, you have no business
trying to teach anyone anything about C.
Your code is the work of a programmer so hideously
incompetent that 'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about
denigrating other people's C knowledge is the height of
arrogant hypocrisy.
works. That's to be expected, and PO's response ought to be
to explain it so that you understand. Instead he goes off on
one of his rants, so blamewise it's really down to PO.
PO's halt7.c is compiled (it is not linked), then the obj
file is fed as input to his x87utm.exe which is a kind of x86
obj code execution environment. x87utm provides a number of
primative calls that halt7.c code can make, such as
Allocate(), used to allocate a block of memory for use in
halt7.c. Within halt7.c code calls an Allocate() function,
and x86utm intercepts that and performs the function
internally, then jumps the calling code in halt7.c over the
Allocate call where it continues as normal. The call never
goes to the implementation of Allocate in halt7.c, so the
null pointer dereferencing does not actually occur. There
are a whole bunch of similar x86utm primitive operations that
work in the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
*until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And since H does not correctly determine that its simulated D
would never stop running unless aborted, it is a vacuous
statement and Sipser's agreement does not tell anything.
That is counter factual as any fully qualified
C programmer will tell you.
What my code actually does is totally irrelevant.
On Thu, 08 May 2025 21:01:42 +0100, Richard Heathfield wrote:
On 08/05/2025 20:42, olcott wrote:
On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
Op 08.mei.2025 om 19:00 schreef olcott:
That is counter factual as any fully qualified C programmer will tellI try to stay focused on the key essence gist of the issue and never >>>>> delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules of the x86 language
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> *until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And since H does not correctly determine that its simulated D would
never stop running unless aborted, it is a vacuous statement and
Sipser's agreement does not tell anything.
you.
As any competent C programmer can tell you, your simulation is driven by
assembly language, not C. Furthermore, neither halt7.c nor x86utm.cpp is
syntactically correct C. Once you fix the syntax errors, that still
leaves you with the undefined behaviour.
I don't believe the C ISO Standard explictly states that stack overflow is undefined behaviour
On 08/05/2025 20:42, olcott wrote:
On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
Op 08.mei.2025 om 19:00 schreef olcott:That is counter factual as any fully qualified C programmer will tell
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:Thanks for those details, they are correct.
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:deprecated.
<snip>
Does there exist an HHH such that DDD emulated by HHH according >>>>>>>>> to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to >>>>>>>> stop at HHH's first departure from the rules of the C programming >>>>>>>> language (or at least the first departure I spot).
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size; Output("CopyMachineCode
destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well, but >>>>>> you make essentially the same mistake --- writing to memory that
your program doesn't own --- no fewer than four times in a single
function.
I'll ignore the syntax error (a null statement at file scope is a >>>>>>>> rookie error).If you can't even understand what is essentially an infinite
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null >>>>>>>> pointer constant... which is fine as long as you don't try to
deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax >>>>>>>> errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you / >>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
pity's sake.
recursive relationship between two functions except that one
function can terminate the other then you don't have a clue about >>>>>>> the essence of my system.
If you can't even understand why it's a stupendously bad idea to
dereference a null pointer, you have no business trying to teach
anyone anything about C.
Your code is the work of a programmer so hideously incompetent that >>>>>> 'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about denigrating >>>>>> other people's C knowledge is the height of arrogant hypocrisy.
That's to be expected, and PO's response ought to be to explain it
so that you understand. Instead he goes off on one of his rants, so >>>>> blamewise it's really down to PO.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative calls >>>>> that halt7.c code can make, such as Allocate(), used to allocate a
block of memory for use in halt7.c. Within halt7.c code calls an
Allocate() function, and x86utm intercepts that and performs the
function internally, then jumps the calling code in halt7.c over the >>>>> Allocate call where it continues as normal. The call never goes to >>>>> the implementation of Allocate in halt7.c, so the null pointer
dereferencing does not actually occur. There are a whole bunch of
similar x86utm primitive operations that work in the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
I try to stay focused on the key essence gist of the issue and never
delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules of the x86 language
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And since H does not correctly determine that its simulated D would
never stop running unless aborted, it is a vacuous statement and
Sipser's agreement does not tell anything.
you.
As any competent C programmer can tell you, your simulation is driven by assembly language, not C. Furthermore, neither halt7.c nor x86utm.cpp is syntactically correct C. Once you fix the syntax errors, that still
leaves you with the undefined behaviour.
Getting it right is tedious.
When HHH <is> a correct simulator then DDD emulated
by HHH cannot possibly reach its own "return" instruction.
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to
stop at HHH's first departure from the rules of the C programming
language (or at least the first departure I spot).
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ", ((u32*)*destination) >>>>> [-1]);
Output("CopyMachineCode destination[-2]: ", ((u32*)*destination) >>>>> [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well, but
you make essentially the same mistake --- writing to memory that your
program doesn't own --- no fewer than four times in a single function.
I'll ignore the syntax error (a null statement at file scope is a
rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null
pointer constant... which is fine as long as you don't try to deref
it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax
errors, remember). destination is a null pointer, so destination[N]
derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you /dare/
to impugn other people's C knowledge! Crack a book, for pity's sake. >>>>>
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to
dereference a null pointer, you have no business trying to teach
anyone anything about C.
Your code is the work of a programmer so hideously incompetent that
'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about denigrating
other people's C knowledge is the height of arrogant hypocrisy.
That's to be expected, and PO's response ought to be to explain it so
that you understand. Instead he goes off on one of his rants, so
blamewise it's really down to PO.
PO's halt7.c is compiled (it is not linked), then the obj file is fed
as input to his x87utm.exe which is a kind of x86 obj code execution
environment. x87utm provides a number of primative calls that halt7.c
code can make, such as Allocate(), used to allocate a block of memory
for use in halt7.c. Within halt7.c code calls an Allocate() function,
and x86utm intercepts that and performs the function internally, then
jumps the calling code in halt7.c over the Allocate call where it
continues as normal. The call never goes to the implementation of
Allocate in halt7.c, so the null pointer dereferencing does not
actually occur. There are a whole bunch of similar x86utm primitive
operations that work in the same way.
PO should have said all that, not me, but it seems he's not interested
in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
On 5/8/2025 5:26 PM, Keith Thompson wrote:
No, the problem Richard was pointing out with olcott's Halt7.c
is that
*it's not valid C".
void DDD()
{
HHH(DDD);
return;
}
If you are a competent C programmer
then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
If you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
No, what you need is someone who is an expert in mathematical logic
(I am not) who can explain to you, in terms you can understand and
accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH is the same thing
as infinite recursion between HHH and DDD yet is
implemented as recursive simulation.
I doubt that any such person exists, but only for reasons related
to you.
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
"cannot possibly each"?
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells
me nothing about what it's supposed to do. Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
We need not know anything else about HHH to
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
The return statement is harmless but unnecessary.
"void DDD()" should be "void DDD(void)" (unless you're using C23, but
we've established that your not). Why did you choose to use empty
parentheses? (If you answer nothing else, please answer that.)
I am using Microsoft Visual Studio 2017.
It compiled cleanly.
On 5/8/2025 7:00 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
[...]I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly
wrong* leads me to think that he is largely ignorant of C (which is >>>>>> fine, most people are) and is unwilling to admit it. Watching the >>>>>> reactions of actual experts to his mathematical arguments leads me >>>>>> to the same conclusion about his knowledge of the relevant fields
of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
So you normally compile your code using the 2017 version of
Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct
a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
Microsoft's compiler did not report certain errors that any conforming C
compiler is required by the standard to report.
Microsoft's compiler *can* be invoked in a way that causes it to
diagnose such errors, though it may or may not become fully conforming.
I haven't used it lately, but a web search should tell you how to do
that.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors
would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted
for decades. Can you understand why I might decide that analyzing
your claims is not worth my time?
I learned C back when K & R was the standard.
So did I. I've kept up with the language as it has changed.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point.
Great. Then why do you keep posting code? Or is the above DDD()
function not included in "any of my code")?
For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
That's too vague for me to comment.
Do you know what a C language interpreter is?
I actually do this at the x86 machine code level
yet most people don't have a clue about that.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The above hypothetical HHH emulates the first four
instructions of DDD. This sequence repeats until a
OOM error.
On 5/8/2025 6:35 PM, Richard Damon wrote:
On 5/8/25 1:00 PM, olcott wrote:
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to
stop at HHH's first departure from the rules of the C programming >>>>>>> language (or at least the first departure I spot).
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well, but
you make essentially the same mistake --- writing to memory that
your program doesn't own --- no fewer than four times in a single
function.
I'll ignore the syntax error (a null statement at file scope is a >>>>>>> rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null
pointer constant... which is fine as long as you don't try to
deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax
errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you /
dare/ to impugn other people's C knowledge! Crack a book, for
pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to
dereference a null pointer, you have no business trying to teach
anyone anything about C.
Your code is the work of a programmer so hideously incompetent that
'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about denigrating
other people's C knowledge is the height of arrogant hypocrisy.
That's to be expected, and PO's response ought to be to explain it
so that you understand. Instead he goes off on one of his rants, so
blamewise it's really down to PO.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative calls
that halt7.c code can make, such as Allocate(), used to allocate a
block of memory for use in halt7.c. Within halt7.c code calls an
Allocate() function, and x86utm intercepts that and performs the
function internally, then jumps the calling code in halt7.c over the
Allocate call where it continues as normal. The call never goes to
the implementation of Allocate in halt7.c, so the null pointer
dereferencing does not actually occur. There are a whole bunch of
similar x86utm primitive operations that work in the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
Excpet, as you have admitted, your DD isn't a program (just a C
funciton), and thus not a proper input for a halt decider, which by
definiton must be a program.
Your C function can't be a program, as you have specifically said that
the function, and only the funciton is the input, and programs must
include in them all their code, so since the code of HHH isn't
included in DD or the input representing it, it isn't a program, and
thus not a proper input
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
But that statement implies, as required that H be a halt decider and D
to be a proper input to one, neither of which are satisfied, as you
have admitte
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
But it doesn't, as it doesn't correctly follow the behavior of the x86
language, as that requires HHH to follow the call instruction, which
it can not do as the required (and accepted by your) condition that
the decider is a pure function, which means it can only look at its
input, which does not include the code which the call points to.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
Right, and a halt decider is required to (try to) compute the mapping
from the input (which needs to be the representation of a program) to
the results of running that program (since that is the DEFINITION of
Halt Deciding).
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Right, just as HHH trying to claim that its answer is based on the
fact that it can't reach the end of its simulation of the input isn't
the correct requirement for HHH.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
Right, which is Halting, since that behavior is DEFINED to be the
behavior of running the program the input represents.
Just like requiring sum(3,2) to report on the sum of 5 + 7
a value other than its input specifies HHH IS NOT ALLOWED
to report on anything other than the behavior that its input
specifies.
Its input specifies that it calls HHH(DD) in recursive
emulation. THIS CANNOT BE IGNORED.
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly
wrong* leads me to think that he is largely ignorant of C (which is
fine, most people are) and is unwilling to admit it. Watching the
reactions of actual experts to his mathematical arguments leads me
to the same conclusion about his knowledge of the relevant fields
of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
[...]
So you normally compile your code using the 2017 version of Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct
a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors
would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted
for decades. Can you understand why I might decide that analyzing
your claims is not worth my time?
I learned C back when K & R was the standard.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
On 5/8/2025 8:15 PM, Richard Damon wrote:
On 5/8/25 7:59 PM, olcott wrote:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
"cannot possibly each"?
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells
me nothing about what it's supposed to do. Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
So you retract your stipulations?
We need not know anything else about HHH to
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
Excpet that then you can't change HHH to make it the decider, as that
changes the code of the program to be decided.
*We can't get to that step until after this step is complete*
So you agree with my above paragraph:
We need not know anything else about HHH to
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
On 5/8/2025 8:13 PM, Richard Damon wrote:
On 5/8/25 8:05 PM, olcott wrote:
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
If you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
No, what you need is someone who is an expert in mathematical logic
(I am not) who can explain to you, in terms you can understand and
accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
No, the problem is you don't.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
And claiming the behavior of a program that isn;t the behavior of that
program is just a lie.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
On 5/8/2025 8:07 PM, Richard Damon wrote:
On 5/8/25 8:14 PM, olcott wrote:
On 5/8/2025 7:00 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
[...]I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly >>>>>>>> wrong* leads me to think that he is largely ignorant of C (which is >>>>>>>> fine, most people are) and is unwilling to admit it. Watching the >>>>>>>> reactions of actual experts to his mathematical arguments leads me >>>>>>>> to the same conclusion about his knowledge of the relevant fields >>>>>>>> of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
So you normally compile your code using the 2017 version of
Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct >>>>>> a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
Microsoft's compiler did not report certain errors that any
conforming C
compiler is required by the standard to report.
Microsoft's compiler *can* be invoked in a way that causes it to
diagnose such errors, though it may or may not become fully conforming. >>>> I haven't used it lately, but a web search should tell you how to do
that.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors >>>>>> would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted >>>>>> for decades. Can you understand why I might decide that analyzing >>>>>> your claims is not worth my time?
I learned C back when K & R was the standard.
So did I. I've kept up with the language as it has changed.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point.
Great. Then why do you keep posting code? Or is the above DDD()
function not included in "any of my code")?
For example when >>>>> the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
That's too vague for me to comment.
Do you know what a C language interpreter is?
I actually do this at the x86 machine code level
yet most people don't have a clue about that.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The above hypothetical HHH emulates the first four
instructions of DDD. This sequence repeats until a
OOM error.
Which is INVALID as in input to a halt decider
We aren't even talking about a halt decider yet.
We are only testing to see if the idea of recursive
simulation is understood to be equivalent to infinite
recursion.
On 5/8/2025 9:02 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
No, what you need is someone who is an expert in mathematical logicIf you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
(I am not) who can explain to you, in terms you can understand and
accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
You see, this is something you've gotten wrong, and you need somebody
who can explain that to you in terms you can understand and accept.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
Is there any reason you couldn't have written that as follows?
void DDD(void)
{
HHH(DDD);
}
You could then talk about it not reaching its closing brace rather
than not reaching its "return" instruction. BTW, it's correctly
called a "return statement" in C; dropping it would make it easier
to avoid your incorrect use of terminology. (Assembly or machine
code has "instructions"; C has "statements" and "declarations".)
DDD correctly simulated by HHH is the same thing
as infinite recursion between HHH and DDD yet is
implemented as recursive simulation.
Sure, infinite recursion is infinite, regardless of how it's
implemented, assuming it's implemented correctly. That's so trivally
obvious that I simply don't believe that "the comp.sci" people are
failing to understand it -- though I can believe that you believe it.
Look at their replies to this post.
Not a one of them will agree that
void DDD()
{
HHH(DDD);
return; // final halt state
}
When 1 or more instructions of DDD are correctly
simulated by HHH then the correctly simulated DDD cannot
possibly reach its "return" instruction (final halt state).
They have consistently disagreed with this
simple point for three years.
I doubt that any such person exists, but only for reasons related
to you.
On 5/8/2025 8:18 PM, Richard Damon wrote:
On 5/8/25 7:48 PM, olcott wrote:
On 5/8/2025 6:35 PM, Richard Damon wrote:
On 5/8/25 1:00 PM, olcott wrote:
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works. >>>>>> That's to be expected, and PO's response ought to be to explain it >>>>>> so that you understand. Instead he goes off on one of his rants, >>>>>> so blamewise it's really down to PO.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to >>>>>>>>> stop at HHH's first departure from the rules of the C
programming language (or at least the first departure I spot). >>>>>>>>>
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well,
but you make essentially the same mistake --- writing to memory
that your program doesn't own --- no fewer than four times in a
single function.
I'll ignore the syntax error (a null statement at file scope is >>>>>>>>> a rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null >>>>>>>>> pointer constant... which is fine as long as you don't try to >>>>>>>>> deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax >>>>>>>>> errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you / >>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for >>>>>>>>> pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to >>>>>>> dereference a null pointer, you have no business trying to teach >>>>>>> anyone anything about C.
Your code is the work of a programmer so hideously incompetent
that 'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about
denigrating other people's C knowledge is the height of arrogant >>>>>>> hypocrisy.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative
calls that halt7.c code can make, such as Allocate(), used to
allocate a block of memory for use in halt7.c. Within halt7.c
code calls an Allocate() function, and x86utm intercepts that and
performs the function internally, then jumps the calling code in
halt7.c over the Allocate call where it continues as normal. The >>>>>> call never goes to the implementation of Allocate in halt7.c, so
the null pointer dereferencing does not actually occur. There are >>>>>> a whole bunch of similar x86utm primitive operations that work in
the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
Excpet, as you have admitted, your DD isn't a program (just a C
funciton), and thus not a proper input for a halt decider, which by
definiton must be a program.
Your C function can't be a program, as you have specifically said
that the function, and only the funciton is the input, and programs
must include in them all their code, so since the code of HHH isn't
included in DD or the input representing it, it isn't a program, and
thus not a proper input
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> *until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
But that statement implies, as required that H be a halt decider and
D to be a proper input to one, neither of which are satisfied, as
you have admitte
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
But it doesn't, as it doesn't correctly follow the behavior of the
x86 language, as that requires HHH to follow the call instruction,
which it can not do as the required (and accepted by your) condition
that the decider is a pure function, which means it can only look at
its input, which does not include the code which the call points to.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
Right, and a halt decider is required to (try to) compute the
mapping from the input (which needs to be the representation of a
program) to the results of running that program (since that is the
DEFINITION of Halt Deciding).
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Right, just as HHH trying to claim that its answer is based on the
fact that it can't reach the end of its simulation of the input
isn't the correct requirement for HHH.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
Right, which is Halting, since that behavior is DEFINED to be the
behavior of running the program the input represents.
Just like requiring sum(3,2) to report on the sum of 5 + 7
a value other than its input specifies HHH IS NOT ALLOWED
to report on anything other than the behavior that its input
specifies.
Its input specifies that it calls HHH(DD) in recursive
emulation. THIS CANNOT BE IGNORED.
No it doesn't, it calls HHH, which does what it does. Since your
decider HHH is defined to abort and return 0, so is the HHH that DD
calls, since it was built from that machine.
What we can not ignore is that HHH has a definition, and HHH needs to
interprete the call in DD by that definition, not you LIE that HHH is
just a correct simulator, since it isn't.
Sorry, you are the one that is choosing to ignore the input and
replace it with somethng it isn't, becaue you don't understand that
you did define it when you created your HHH to abort and return 0.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For every HHH that can possibly exist at machine address
000015d2 that correctly emulates 1 or more x86 instructions
of DDD (the exact machine code bytes specified above) no
correctly emulated DDD ever reaches their own "return"
instruction.
This may simply be too difficult for most everyone here.
Instead of simply saying they they don't understand the
x86 language they try to deflect away from this subject
to try to hide their own ignorance.
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that implies that HHH does not correctly simulate DDD. Richard, you've read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell, assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells
me nothing about what it's supposed to do. Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is passed
to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH to
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
Then the return statement (which is unnecessary anyway) will never be
reached.
It is only there to mark a final halt state.
In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
This conclusion relies on my understanding of what you've said about
your code, which I consider to be unreliable.
I am not even talking about my code. I am
talking about the purely hypothetical code
that you just agreed to.
No doubt you believe that there is some significance to the
apparent fact that the return statement will never be reached,
assuming that's a correct and relevant conclusion. I don't know
what that significance might be.
I will tell you that later after you understand
some prerequisite ideas first.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The same thing that applied to DDD equally
applies to the more complicated DD.
When 1 or more instructions of DD are correctly
simulated by HHH the correctly simulated DD
cannot possibly get past its call to HHH(DD).
Thus DD also never reaches its "return" instruction.
The return statement is harmless but unnecessary.
"void DDD()" should be "void DDD(void)" (unless you're using C23,
but
we've established that your not). Why did you choose to use empty
parentheses? (If you answer nothing else, please answer that.)
I am using Microsoft Visual Studio 2017.
It compiled cleanly.
Microsoft Visual Studio 2017 is not a conforming C compiler. It has
options that cause it to attempt to be one. You are feeding it
incorrect code, and it's failing to diagnose it. Your code would
also compile cleanly if you fixed the errors. *Correct* C code
might be part of a more valid argument for your claims than the
one you're making. *Incorrect* C code hurts your credibility,
something I thought you cared about. (Using C at all is an odd
choice, but I won't get into that.)
If there were a refutation of the proof of the insolubility of the
Halting Problem, I do not believe it would really depend on the
vagaries of the 2017 version of Microsoft Visual Studio.
Oh, and I'm very likely to tire of this discussion very soon, so
think carefully if you want to make a point that you'd like me to
pay attention to. Among other things, your repeated insults against
people who dare to disagree with you do not motivate me to engage
with you. I probably shouldn't have jumped into this discussion,
but the noise level here is already so high I don't feel very bad
about it.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells
me nothing about what it's supposed to do. Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is passed
to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH to
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
Then the return statement (which is unnecessary anyway) will never be
reached.
It is only there to mark a final halt state.
In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
This conclusion relies on my understanding of what you've said about
your code, which I consider to be unreliable.
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly
wrong* leads me to think that he is largely ignorant of C
(which is
fine, most people are) and is unwilling to admit it.
Watching the
reactions of actual experts to his mathematical arguments
leads me
to the same conclusion about his knowledge of the relevant
fields
of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
[...]
So you normally compile your code using the 2017 version of
Microsoft
Visual Studio.
I have no particular problem with that, but your failure to
correct
a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
I've pointed out several
syntax errors and constraint violations; at least the syntax
errors
would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
Do you know what a C language interpreter is?
I propose that whenever olcott makes a repetitive post, everyone
ignores it.
On 5/8/2025 11:50 PM, Richard Heathfield wrote:
On 09/05/2025 01:14, olcott wrote:
Do you know what a C language interpreter is?
Of course he does.
A C language interpreter is not absolved from the requirement
to diagnose C syntax errors.
If you think that your x86utm.cpp code qualifies as a C
language interpreter, you are mistaken. You don't even grant it
access to the C code.
I am explaining is as a c language interpreter only
because its actual x86 basis seems over everyone's head.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 09/05/2025 00:53, olcott wrote:[...]
On 5/8/2025 6:45 PM, Keith Thompson wrote:
I have no particular problem with that, but your failure to correctAs I already proved Microsoft reported no such errors.
a number of C errors in your code is odd.
That's tantamount to a claim of a bug in your compiler. Conforming C
compilers are /required/ to report syntax errors.
Meh. Most C compilers, certainly including gcc, clang, and
Microsoft's C compiler, are not conforming by default. In fact,
I don't know of any that are.
I consider this unfortunate, but it means that if you want a
conforming C compiler, you need to use apply additional options
("-std=cNN -pedantic" for gcc and clang, and something else for
Microsoft's compiler).
The problem, of course, is that different C compilers in their default
modes are lax in different ways, so an error that compiler X ignores by default might become fatal when you use compiler Y.
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly
wrong* leads me to think that he is largely ignorant of C (which is
fine, most people are) and is unwilling to admit it. Watching the
reactions of actual experts to his mathematical arguments leads me
to the same conclusion about his knowledge of the relevant fields
of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
[...]
So you normally compile your code using the 2017 version of Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct
a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors
would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted
for decades. Can you understand why I might decide that analyzing
your claims is not worth my time?
I learned C back when K & R was the standard.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that implies that HHH does not correctly simulate DDD. Richard, you've read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell, assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
On 5/8/2025 7:00 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
[...]I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly
wrong* leads me to think that he is largely ignorant of C (which is >>>>>> fine, most people are) and is unwilling to admit it. Watching the >>>>>> reactions of actual experts to his mathematical arguments leads me >>>>>> to the same conclusion about his knowledge of the relevant fields
of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
So you normally compile your code using the 2017 version of
Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct
a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
Microsoft's compiler did not report certain errors that any conforming C
compiler is required by the standard to report.
Microsoft's compiler *can* be invoked in a way that causes it to
diagnose such errors, though it may or may not become fully conforming.
I haven't used it lately, but a web search should tell you how to do
that.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors
would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted
for decades. Can you understand why I might decide that analyzing
your claims is not worth my time?
I learned C back when K & R was the standard.
So did I. I've kept up with the language as it has changed.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point.
Great. Then why do you keep posting code? Or is the above DDD()
function not included in "any of my code")?
For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
That's too vague for me to comment.
Do you know what a C language interpreter is?
I actually do this at the x86 machine code level
yet most people don't have a clue about that.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The above hypothetical HHH emulates the first four
instructions of DDD. This sequence repeats until a
OOM error.
On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
Op 08.mei.2025 om 19:00 schreef olcott:
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to
stop at HHH's first departure from the rules of the C programming >>>>>>> language (or at least the first departure I spot).
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well, but
you make essentially the same mistake --- writing to memory that
your program doesn't own --- no fewer than four times in a single
function.
I'll ignore the syntax error (a null statement at file scope is a >>>>>>> rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null
pointer constant... which is fine as long as you don't try to
deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax
errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you /
dare/ to impugn other people's C knowledge! Crack a book, for
pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to
dereference a null pointer, you have no business trying to teach
anyone anything about C.
Your code is the work of a programmer so hideously incompetent that
'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about denigrating
other people's C knowledge is the height of arrogant hypocrisy.
That's to be expected, and PO's response ought to be to explain it
so that you understand. Instead he goes off on one of his rants, so
blamewise it's really down to PO.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative calls
that halt7.c code can make, such as Allocate(), used to allocate a
block of memory for use in halt7.c. Within halt7.c code calls an
Allocate() function, and x86utm intercepts that and performs the
function internally, then jumps the calling code in halt7.c over the
Allocate call where it continues as normal. The call never goes to
the implementation of Allocate in halt7.c, so the null pointer
dereferencing does not actually occur. There are a whole bunch of
similar x86utm primitive operations that work in the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
And since H does not correctly determine that its simulated D would
never stop running unless aborted, it is a vacuous statement and
Sipser's agreement does not tell anything.
That is counter factual as any fully qualified
C programmer will tell you.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by any HHH cannot
possibly reach its own simulated "return"
instruction.
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
If you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
No, what you need is someone who is an expert in mathematical logic
(I am not) who can explain to you, in terms you can understand and
accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH is the same thing
as infinite recursion between HHH and DDD yet is
implemented as recursive simulation.
On 5/8/2025 8:13 PM, Richard Damon wrote:
On 5/8/25 8:05 PM, olcott wrote:
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
If you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
No, what you need is someone who is an expert in mathematical logic
(I am not) who can explain to you, in terms you can understand and
accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
No, the problem is you don't.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
And claiming the behavior of a program that isn;t the behavior of that
program is just a lie.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells
me nothing about what it's supposed to do. Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is passed
to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH to
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
On 5/8/2025 10:14 PM, Mike Terry wrote:Yeah, so not a full simulation.
On 09/05/2025 03:13, olcott wrote:
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
His simulation is in fact a single-stepped x86 instruction simulation,A full simulation of infinite recursion?
where the stepping of each x86 instruction is under the HHH's control.
HHH can continue stepping the simulation until its target returns, in
which case the situation is logically just like direct call, as you
have described. Or HHH could step just 3 x86 instructions (say) and
then decide to return (aka "abort" its simulation). Let's call that /
partial/ simulation in contrast with /full/ simulation which you've
been supposing.
I am only doing one tiny idea at a time here.
That's wrong as written. HHH cannot simulate DDD returning in aNo one here ever agreed that when 1 or more instructions of DDD areEverybody on comp.theory understands this much.In practice, the program will likely crash due to a stack overflow,Yes you totally have this correctly.
unless the compiler implements tail-call optimization, in which case
the program might just run forever -- which also means the
unnecessary return statement will never be reached.
None of the dozens of comp.theory people could ever achieve that level
of understanding even after three years. That is why I needed to post
on comp.lang.c.
correctly simulated by HHH that DDD cannot possibly reach its own
"return" instruction.
It's true for a finite number. Aborting is not correct simulation, evenThis conclusion relies on my understanding of what you've said about
your code, which I consider to be unreliable.
Hmm, did PO make it clear that when he says
"..DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction."
he is not talking about whether "DDD halts"? [I.e. halts when run
directly from main() outside of a simulator.] No, what he is talking
about is whether the /step-by-step partial simuation/ of DDD performed
by HHH proceeds as far as DDD returning.
When 1 or more steps of DDD are correctly simulated by HHH the simulated
DDD cannot possibly reach its "return" instruction (final halt state).
No one here has agreed to that. Not in several years of coaxing and elaboration.
On 5/8/2025 6:35 PM, Richard Damon wrote:
On 5/8/25 1:00 PM, olcott wrote:
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to
stop at HHH's first departure from the rules of the C programming >>>>>>> language (or at least the first departure I spot).
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well, but
you make essentially the same mistake --- writing to memory that
your program doesn't own --- no fewer than four times in a single
function.
I'll ignore the syntax error (a null statement at file scope is a >>>>>>> rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null
pointer constant... which is fine as long as you don't try to
deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax
errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you /
dare/ to impugn other people's C knowledge! Crack a book, for
pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to
dereference a null pointer, you have no business trying to teach
anyone anything about C.
Your code is the work of a programmer so hideously incompetent that
'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about denigrating
other people's C knowledge is the height of arrogant hypocrisy.
That's to be expected, and PO's response ought to be to explain it
so that you understand. Instead he goes off on one of his rants, so
blamewise it's really down to PO.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative calls
that halt7.c code can make, such as Allocate(), used to allocate a
block of memory for use in halt7.c. Within halt7.c code calls an
Allocate() function, and x86utm intercepts that and performs the
function internally, then jumps the calling code in halt7.c over the
Allocate call where it continues as normal. The call never goes to
the implementation of Allocate in halt7.c, so the null pointer
dereferencing does not actually occur. There are a whole bunch of
similar x86utm primitive operations that work in the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
Excpet, as you have admitted, your DD isn't a program (just a C
funciton), and thus not a proper input for a halt decider, which by
definiton must be a program.
Your C function can't be a program, as you have specifically said that
the function, and only the funciton is the input, and programs must
include in them all their code, so since the code of HHH isn't
included in DD or the input representing it, it isn't a program, and
thus not a proper input
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
But that statement implies, as required that H be a halt decider and D
to be a proper input to one, neither of which are satisfied, as you
have admitte
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
But it doesn't, as it doesn't correctly follow the behavior of the x86
language, as that requires HHH to follow the call instruction, which
it can not do as the required (and accepted by your) condition that
the decider is a pure function, which means it can only look at its
input, which does not include the code which the call points to.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
Right, and a halt decider is required to (try to) compute the mapping
from the input (which needs to be the representation of a program) to
the results of running that program (since that is the DEFINITION of
Halt Deciding).
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Right, just as HHH trying to claim that its answer is based on the
fact that it can't reach the end of its simulation of the input isn't
the correct requirement for HHH.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
Right, which is Halting, since that behavior is DEFINED to be the
behavior of running the program the input represents.
Just like requiring sum(3,2) to report on the sum of 5 + 7
a value other than its input specifies HHH IS NOT ALLOWED
to report on anything other than the behavior that its input
specifies.
On 5/8/2025 8:18 PM, Richard Damon wrote:Nobody disagreed with it, we all see that HHH fails to reach the
On 5/8/25 7:48 PM, olcott wrote:
On 5/8/2025 6:35 PM, Richard Damon wrote:
On 5/8/25 1:00 PM, olcott wrote:
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works. >>>>>> That's to be expected, and PO's response ought to be to explain it >>>>>> so that you understand. Instead he goes off on one of his rants, >>>>>> so blamewise it's really down to PO.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to >>>>>>>>> stop at HHH's first departure from the rules of the C
programming language (or at least the first departure I spot). >>>>>>>>>
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well,
but you make essentially the same mistake --- writing to memory
that your program doesn't own --- no fewer than four times in a
single function.
I'll ignore the syntax error (a null statement at file scope is >>>>>>>>> a rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null >>>>>>>>> pointer constant... which is fine as long as you don't try to >>>>>>>>> deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax >>>>>>>>> errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you / >>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for >>>>>>>>> pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to >>>>>>> dereference a null pointer, you have no business trying to teach >>>>>>> anyone anything about C.
Your code is the work of a programmer so hideously incompetent
that 'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about
denigrating other people's C knowledge is the height of arrogant >>>>>>> hypocrisy.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative
calls that halt7.c code can make, such as Allocate(), used to
allocate a block of memory for use in halt7.c. Within halt7.c
code calls an Allocate() function, and x86utm intercepts that and
performs the function internally, then jumps the calling code in
halt7.c over the Allocate call where it continues as normal. The >>>>>> call never goes to the implementation of Allocate in halt7.c, so
the null pointer dereferencing does not actually occur. There are >>>>>> a whole bunch of similar x86utm primitive operations that work in
the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
Excpet, as you have admitted, your DD isn't a program (just a C
funciton), and thus not a proper input for a halt decider, which by
definiton must be a program.
Your C function can't be a program, as you have specifically said
that the function, and only the funciton is the input, and programs
must include in them all their code, so since the code of HHH isn't
included in DD or the input representing it, it isn't a program, and
thus not a proper input
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> *until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
But that statement implies, as required that H be a halt decider and
D to be a proper input to one, neither of which are satisfied, as
you have admitte
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
But it doesn't, as it doesn't correctly follow the behavior of the
x86 language, as that requires HHH to follow the call instruction,
which it can not do as the required (and accepted by your) condition
that the decider is a pure function, which means it can only look at
its input, which does not include the code which the call points to.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
Right, and a halt decider is required to (try to) compute the
mapping from the input (which needs to be the representation of a
program) to the results of running that program (since that is the
DEFINITION of Halt Deciding).
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Right, just as HHH trying to claim that its answer is based on the
fact that it can't reach the end of its simulation of the input
isn't the correct requirement for HHH.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
Right, which is Halting, since that behavior is DEFINED to be the
behavior of running the program the input represents.
Just like requiring sum(3,2) to report on the sum of 5 + 7
a value other than its input specifies HHH IS NOT ALLOWED
to report on anything other than the behavior that its input
specifies.
Its input specifies that it calls HHH(DD) in recursive
emulation. THIS CANNOT BE IGNORED.
No it doesn't, it calls HHH, which does what it does. Since your
decider HHH is defined to abort and return 0, so is the HHH that DD
calls, since it was built from that machine.
What we can not ignore is that HHH has a definition, and HHH needs to
interprete the call in DD by that definition, not you LIE that HHH is
just a correct simulator, since it isn't.
Sorry, you are the one that is choosing to ignore the input and
replace it with somethng it isn't, becaue you don't understand that
you did define it when you created your HHH to abort and return 0.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For every HHH that can possibly exist at machine address
000015d2 that correctly emulates 1 or more x86 instructions
of DDD (the exact machine code bytes specified above) no
correctly emulated DDD ever reaches their own "return"
instruction.
This may simply be too difficult for most everyone here.
Instead of simply saying they they don't understand the
x86 language they try to deflect away from this subject
to try to hide their own ignorance.
Richard Damon <news.x.richarddamon@xoxy.net> writes:
On 5/8/25 10:23 PM, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the abovevoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
that
implies that HHH does not correctly simulate DDD. Richard, you've read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code
is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
You are missing the equivocation he is using on what is "DDD()"
First, he tries to define it as just the code of the function, and not
including any of the code that it calls. He does this so all the
various HHH that he talks about are given the "same" input.
Then he tries to also say that when those functions look at DDD, they
can follow the memory chain to the functions that it calls, that
weren't actually part of the input.
This means the "behavior" of his input isn't actually defined by the input.
I haven't seen any of that in the posts to which I've recently replied
(and I absolutely do not have the patience to read everything he's
posted here).
What I've seen in the articles to which I've recently replied has been
just a strangely little C function and some claims about simulation.
Viewed in isolation, I don't think any of that (again, ignoring the vast majority of what he's posted in this newsgroup) seems contradictory so far.
He has also, to get around other objections about what he is doing,
stipulated that his functions must be pure functions, and thus only
dependent on their direct input, other wise we can add the following
code to the beginning of HHH to make his statement false:
I've seen no mention of pure functions in the posts to which I've
recently replied.
[...]
On 5/8/2025 11:50 PM, Richard Heathfield wrote:
On 09/05/2025 01:14, olcott wrote:
Do you know what a C language interpreter is?
Of course he does.
A C language interpreter is not absolved from the requirement to
diagnose C syntax errors.
If you think that your x86utm.cpp code qualifies as a C language
interpreter, you are mistaken. You don't even grant it access to the C
code.
I am explaining is as a c language interpreter only
because its actual x86 basis seems over everyone's head.
On 5/8/2025 11:22 PM, Keith Thompson wrote:
Richard Damon <news.x.richarddamon@xoxy.net> writes:You are seeing some of the same misdirection that I have been seeing.
On 5/8/25 10:23 PM, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the abovevoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
that
implies that HHH does not correctly simulate DDD. Richard, you've read >>>> far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code
is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
You are missing the equivocation he is using on what is "DDD()"
First, he tries to define it as just the code of the function, and not
including any of the code that it calls. He does this so all the
various HHH that he talks about are given the "same" input.
Then he tries to also say that when those functions look at DDD, they
can follow the memory chain to the functions that it calls, that
weren't actually part of the input.
This means the "behavior" of his input isn't actually defined by the
input.
I haven't seen any of that in the posts to which I've recently replied
(and I absolutely do not have the patience to read everything he's
posted here).
What I've seen in the articles to which I've recently replied has been
just a strangely little C function and some claims about simulation.
Viewed in isolation, I don't think any of that (again, ignoring the vast
majority of what he's posted in this newsgroup) seems contradictory so
far.
He has also, to get around other objections about what he is doing,
stipulated that his functions must be pure functions, and thus only
dependent on their direct input, other wise we can add the following
code to the beginning of HHH to make his statement false:
I've seen no mention of pure functions in the posts to which I've
recently replied.
[...]
Most people here change the subject when they come across difficult
and crucial material.
On 5/8/2025 11:11 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:Does HHH correctly simulate DDD *and do nothing else*?
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells >>>>>> me nothing about what it's supposed to do. Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate *every* function whose address is passed
to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH toAssuming that HHH(DDD) "correctly simulates" DDD, and assuming it
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
I find that difficult to believe.
Then the return statement (which is unnecessary anyway) will never be
reached.
It is only there to mark a final halt state.
The closing "}" does that equally well.
In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
I'll note that I've posted in comp.theory, not in comp.lang.c.
I never see anything you post in comp.lang.c.
This conclusion relies on my understanding of what you've said about
your code, which I consider to be unreliable.
I am not even talking about my code. I am
talking about the purely hypothetical code
that you just agreed to.
Do not overestimate what I've agreed to. I must still consider the
possibility that I've been led into a logical trap of some sort,
and that I've missed some subtle flaw.
No doubt you believe that there is some significance to the
apparent fact that the return statement will never be reached,
assuming that's a correct and relevant conclusion. I don't know
what that significance might be.
I will tell you that later after you understand
some prerequisite ideas first.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
So now HHH returns an int result, and you store that result
in a variable named "Halt_Status". You haven't said here what
the meaning of that result might be, and I decline to make any
assumptions based on what you've called it. You could rename
"Halt_Status" to "Foo" and have effectively identical code.
Previously DDD would "correctly simulate" the function whose address is
passed to it. Now it does that and returns an int result.
If you want to say anything about the meaning of the result returned
by HHH, feel free to say it.
The same thing that applied to DDD equally
applies to the more complicated DD.
When 1 or more instructions of DD are correctly
simulated by HHH the correctly simulated DD
cannot possibly get past its call to HHH(DD).
Thus DD also never reaches its "return" instruction.
Now you're talking about simulating "1 or more instructions"
of DD. I thought that HHH was supposed to "accurately simulate"
the function whose argument is passed to it. Emulating just "1 or
more instructions" is not accurate simulation.
If HHH *fully* simulates the execution of DD, then your code above
exhibits endless recursion,
In computer science "halting" is not merely stopping running.
"Halting" is reaching a final halt state such as the "return"
instruction.
which is not particularly interesting,
and it never reaches the "if (Halt_Status)". (DD calls HHH, which
simulates DD; HHH, in simulating DD, must do the equivalent of
calling HHH, and so on.)
It turns out to be very interesting you merely need
to grok a few details first.
You've introduced the idea of simulating only some finite number
of instructions of the simulated functions, but you haven't really
said how that happens (except perhaps in some x86 code that I
don't understand). You've implied that a sufficient knowledge of C
would let someone understand your arguments, but part of what you're
saying seems to depend on x86 assembly and/or machine code (which I'm
not going to learn for the sake of this discussion).
If I would need to understand x86 code to understand your claims, then
let's just stop here.
[SNIP]
On 5/8/2025 10:14 PM, Mike Terry wrote:
On 09/05/2025 03:13, olcott wrote:
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells >>>>>> me nothing about what it's supposed to do. Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is passed
to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH to
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
PO is being quite deceptive here.
I am only referring to the above hypothetical HHH/DDD pair.
Everyone here has consistently denied that when DDD is
correctly simulated by HHH that this DDD cannot possibly
reach its "return" instruction (final halt state).
His simulation is in fact a single-stepped x86 instruction simulation,
where the stepping of each x86 instruction is under the HHH's control.
HHH can continue stepping the simulation until its target returns, in
which case the situation is logically just like direct call, as you
have described. Or HHH could step just 3 x86 instructions (say) and
then decide to return (aka "abort" its simulation). Let's call that /
partial/ simulation in contrast with /full/ simulation which you've
been supposing.
A full simulation of infinite recursion?
I am only doing one tiny idea at a time here.
Oh, did he forget to mention that? Anyhow, in the general case with /
partial/ simulation there is more to think about as it is obvioudly /
not/ logically equivalent to direct execution.
That is changing the subject away from
DDD correctly simulated by HHH.
Oh, and obviously everybody in comp.theory gets all this. The problem
is with PO and his inability to communicate his ideas properly and his
inability to understand what other people understand or disagree with.
He goes on for months/years claiming people don't understand things
they agree with, but it's down to his duffer wording...
Then the return statement (which is unnecessary anyway) will never be
reached.
It is only there to mark a final halt state.
In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
Everybody on comp.theory understands this much.
No one here ever agreed that when 1 or more
instructions of DDD are correctly simulated
by HHH that DDD cannot possibly reach its
own "return" instruction.
Everyone has found one excuse or another to
deny this.
PO's plan is that when he goes elsewhere he can start with noobies and
trick them into agreeing with certain "wordings" by not explaining
relevent context for his questions. Then he goes back to comp.theory
and triumphantly claims support from elsewhere, proving to himself
that comp.theory posters are all idiots. :)
So beware!
This conclusion relies on my understanding of what you've said about
your code, which I consider to be unreliable.
Hmm, did PO make it clear that when he says
"..DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction."
Unless we go one tiny step at a time everyone
permanently leaps to a false conclusion and stays
there.
he is not talking about whether "DDD halts"? [I.e. halts when run
directly from main() outside of a simulator.] No, what he is talking
about is whether the /step-by-step partial simuation/ of DDD performed
by HHH proceeds as far as DDD returning.
When 1 or more steps of DDD are correctly simulated
by HHH the simulated DDD cannot possibly reach its
"return" instruction (final halt state).
No one here has agreed to that. Not in several
years of coaxing and elaboration.
Don't forget - HHH is allowed to simply stop simulating and return
whenever it likes! Maybe it only wants to simulate 48 x86
instructions, or just 1, or maybe it's in for the long haul and
simulates until DDD returns [if it ever does].
When 1 or more steps of DDD are correctly simulated
by HHH the simulated DDD cannot possibly reach its
"return" instruction (final halt state).
remains a verified fact.
So you need to re-analyse everything you've said with this new
information that PO forgot to make clear.
Regards,
Mike.
On 5/8/2025 5:13 PM, Richard Heathfield wrote:
On 08/05/2025 22:41, olcott wrote:
What my code actually does is totally irrelevant.
On that, at least, we can agree.
That an HHH can be created that does correctly
determine the halt status of this input is the
whole point.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
olcott <polcott333@gmail.com> writes:
On 5/8/2025 11:11 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 8:30 PM, Keith Thompson wrote:I find that difficult to believe.
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:Does HHH correctly simulate DDD *and do nothing else*?
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells >>>>>>> me nothing about what it's supposed to do. Without knowing what >>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?). >>>>>>>
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate *every* function whose address is passed >>>>> to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH toAssuming that HHH(DDD) "correctly simulates" DDD, and assuming it
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
The closing "}" does that equally well.Then the return statement (which is unnecessary anyway) will never be >>>>> reached.
It is only there to mark a final halt state.
I'll note that I've posted in comp.theory, not in comp.lang.c.In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the >>>>> unnecessary return statement will never be reached.
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
I never see anything you post in comp.lang.c.
Do not overestimate what I've agreed to. I must still consider theThis conclusion relies on my understanding of what you've said about >>>>> your code, which I consider to be unreliable.
I am not even talking about my code. I am
talking about the purely hypothetical code
that you just agreed to.
possibility that I've been led into a logical trap of some sort,
and that I've missed some subtle flaw.
So now HHH returns an int result, and you store that resultNo doubt you believe that there is some significance to the
apparent fact that the return statement will never be reached,
assuming that's a correct and relevant conclusion. I don't know
what that significance might be.
I will tell you that later after you understand
some prerequisite ideas first.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
in a variable named "Halt_Status". You haven't said here what
the meaning of that result might be, and I decline to make any
assumptions based on what you've called it. You could rename
"Halt_Status" to "Foo" and have effectively identical code.
Previously DDD would "correctly simulate" the function whose address
is
passed to it. Now it does that and returns an int result.
If you want to say anything about the meaning of the result returned
by HHH, feel free to say it.
The same thing that applied to DDD equallyNow you're talking about simulating "1 or more instructions"
applies to the more complicated DD.
When 1 or more instructions of DD are correctly
simulated by HHH the correctly simulated DD
cannot possibly get past its call to HHH(DD).
Thus DD also never reaches its "return" instruction.
of DD. I thought that HHH was supposed to "accurately simulate"
the function whose argument is passed to it. Emulating just "1 or
more instructions" is not accurate simulation.
If HHH *fully* simulates the execution of DD, then your code above
exhibits endless recursion,
In computer science "halting" is not merely stopping running.
"Halting" is reaching a final halt state such as the "return"
instruction.
I fail to see either the truth or the relevance of that statement.
We weren't even talking about halting. You did use the C identifier "Halt_Status", but I already told you that the spelling of an
identifier implies nothing about its meaning. I said that you
hadn't said anything about the meaning of Halt_Status. You declined
to explain.
You continue to use the term "return instruction". There is no such
thing in C. There is a return *statement*. Do you have some reason to insist on using incorrect terminology?
which is not particularly interesting,
and it never reaches the "if (Halt_Status)". (DD calls HHH, which
simulates DD; HHH, in simulating DD, must do the equivalent of
calling HHH, and so on.)
It turns out to be very interesting you merely need
to grok a few details first.
It's unlikely I'll continue paying attention long enough for it to get interesting.
You've introduced the idea of simulating only some finite number
of instructions of the simulated functions, but you haven't really
said how that happens (except perhaps in some x86 code that I
don't understand). You've implied that a sufficient knowledge of C
would let someone understand your arguments, but part of what you're
saying seems to depend on x86 assembly and/or machine code (which I'm
not going to learn for the sake of this discussion).
If I would need to understand x86 code to understand your claims,
then
let's just stop here.
[SNIP]
You didn't respond to the above. I'll ask directly.
Would I need to understand x86 code to understand your claims? Yes or no.
On 5/9/2025 12:31 AM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 11:11 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 8:30 PM, Keith Thompson wrote:I find that difficult to believe.
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:Does HHH correctly simulate DDD *and do nothing else*?
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make >>>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells >>>>>>>> me nothing about what it's supposed to do. Without knowing what >>>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?). >>>>>>>>
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate *every* function whose address is passed >>>>>> to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between >>>>>> calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH toAssuming that HHH(DDD) "correctly simulates" DDD, and assuming it
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
The closing "}" does that equally well.Then the return statement (which is unnecessary anyway) will never be >>>>>> reached.
It is only there to mark a final halt state.
I'll note that I've posted in comp.theory, not in comp.lang.c.In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in >>>>>> which case the program might just run forever -- which also means the >>>>>> unnecessary return statement will never be reached.
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
I never see anything you post in comp.lang.c.
Do not overestimate what I've agreed to. I must still consider theThis conclusion relies on my understanding of what you've said about >>>>>> your code, which I consider to be unreliable.
I am not even talking about my code. I am
talking about the purely hypothetical code
that you just agreed to.
possibility that I've been led into a logical trap of some sort,
and that I've missed some subtle flaw.
So now HHH returns an int result, and you store that resultNo doubt you believe that there is some significance to the
apparent fact that the return statement will never be reached,
assuming that's a correct and relevant conclusion. I don't know
what that significance might be.
I will tell you that later after you understand
some prerequisite ideas first.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
in a variable named "Halt_Status". You haven't said here what
the meaning of that result might be, and I decline to make any
assumptions based on what you've called it. You could rename
"Halt_Status" to "Foo" and have effectively identical code.
Previously DDD would "correctly simulate" the function whose address
is
passed to it. Now it does that and returns an int result.
If you want to say anything about the meaning of the result returned
by HHH, feel free to say it.
The same thing that applied to DDD equallyNow you're talking about simulating "1 or more instructions"
applies to the more complicated DD.
When 1 or more instructions of DD are correctly
simulated by HHH the correctly simulated DD
cannot possibly get past its call to HHH(DD).
Thus DD also never reaches its "return" instruction.
of DD. I thought that HHH was supposed to "accurately simulate"
the function whose argument is passed to it. Emulating just "1 or
more instructions" is not accurate simulation.
If HHH *fully* simulates the execution of DD, then your code above
exhibits endless recursion,
In computer science "halting" is not merely stopping running.
"Halting" is reaching a final halt state such as the "return"
instruction.
I fail to see either the truth or the relevance of that statement.
The "return" instruction marks the final halt state.
The actual basis for halting: Reaching a Final Halt State
The halting problem proofs have very specific specific parameters.
We weren't even talking about halting. You did use the C identifier
"Halt_Status", but I already told you that the spelling of an
identifier implies nothing about its meaning. I said that you
hadn't said anything about the meaning of Halt_Status. You declined
to explain.
You continue to use the term "return instruction". There is no such
thing in C. There is a return *statement*. Do you have some reason to
insist on using incorrect terminology?
which is not particularly interesting,
and it never reaches the "if (Halt_Status)". (DD calls HHH, which
simulates DD; HHH, in simulating DD, must do the equivalent of
calling HHH, and so on.)
It turns out to be very interesting you merely need
to grok a few details first.
It's unlikely I'll continue paying attention long enough for it to get
interesting.
You've introduced the idea of simulating only some finite number
of instructions of the simulated functions, but you haven't really
said how that happens (except perhaps in some x86 code that I
don't understand). You've implied that a sufficient knowledge of C
would let someone understand your arguments, but part of what you're
saying seems to depend on x86 assembly and/or machine code (which I'm
not going to learn for the sake of this discussion).
If I would need to understand x86 code to understand your claims,
then
let's just stop here.
[SNIP]
You didn't respond to the above. I'll ask directly.
Would I need to understand x86 code to understand your claims? Yes or
no.
It makes it much easier because the state transition graph
of the control flow at the x86 level is unequivocal.
On 5/9/2025 3:39 AM, Fred. Zwarts wrote:Because it runs forever, and a decider needs to return.
Op 09.mei.2025 om 01:53 schreef olcott:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
A vacuous statement, because HHH cannot correctly simulate DDD, whichYou are using C, a language in which you appear to have littleI learned C back when K & R was the standard.
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted
for decades. Can you understand why I might decide that analyzing
your claims is not worth my time?
We don't need to look at any of my code for me to totally prove my
point. For example when the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own "return" instruction.
includes HHH itself.
A vacuous statement does not prove anything.
You are saying that the smartest genius (not me)
in the universe cannot possibly create an HHH that simulates itself simulating DDD?
What is the evidence for this wild-eyed claim?
On 5/9/2025 4:48 AM, joes wrote:HHH simulates DDD returning only in an infinite number of steps.
Am Thu, 08 May 2025 22:34:35 -0500 schrieb olcott:Didn't you know this?
On 5/8/2025 10:14 PM, Mike Terry wrote:Yeah, so not a full simulation.
On 09/05/2025 03:13, olcott wrote:
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
His simulation is in fact a single-stepped x86 instructionA full simulation of infinite recursion?
simulation, where the stepping of each x86 instruction is under the
HHH's control. HHH can continue stepping the simulation until its
target returns, in which case the situation is logically just like
direct call, as you have described. Or HHH could step just 3 x86
instructions (say) and then decide to return (aka "abort" its
simulation). Let's call that /
partial/ simulation in contrast with /full/ simulation which you've
been supposing.
I am only doing one tiny idea at a time here.
It is incorrect for a simulating termination analyzer to do a full
simulation of a non-halting input.
HHH can simulate 1 or more instructions of DDD,That's wrong as written. HHH cannot simulate DDD returning in a finiteNo one here ever agreed that when 1 or more instructions of DDD areEverybody on comp.theory understands this much.In practice, the program will likely crash due to a stack overflow, >>>>>> unless the compiler implements tail-call optimization, in whichYes you totally have this correctly.
case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
None of the dozens of comp.theory people could ever achieve that
level of understanding even after three years. That is why I needed
to post on comp.lang.c.
correctly simulated by HHH that DDD cannot possibly reach its own
"return" instruction.
number of instructions, it takes infinitely many.
this is not actually logically impossible.
When HHH does correctly simulate 1 or more instructions of DDD then DDD
never reaches its "return statement" final halt state.
Yes, that is why HHH cannot both be a decider and simulate correctly.This conclusion relies on my understanding of what you've said
about your code, which I consider to be unreliable.
Hmm, did PO make it clear that when he says
"..DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction."
he is not talking about whether "DDD halts"? [I.e. halts when run
directly from main() outside of a simulator.] No, what he is talking >>>> about is whether the /step-by-step partial simuation/ of DDD
performed by HHH proceeds as far as DDD returning.
When 1 or more steps of DDD are correctly simulated by HHH the
simulated DDD cannot possibly reach its "return" instruction (final
halt state). No one here has agreed to that. Not in several years of
coaxing and elaboration.
It's true for a finite number. Aborting is not correct simulation, evenIt is incorrect for a simulating termination analyzer to do a full
if HHH did return that DDD halts.
simulation of a non-halting input.
On 5/9/2025 3:41 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 02:14 schreef olcott:
On 5/8/2025 7:00 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
[...]I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly >>>>>>>> wrong* leads me to think that he is largely ignorant of C (which is >>>>>>>> fine, most people are) and is unwilling to admit it. Watching the >>>>>>>> reactions of actual experts to his mathematical arguments leads me >>>>>>>> to the same conclusion about his knowledge of the relevant fields >>>>>>>> of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
So you normally compile your code using the 2017 version of
Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct >>>>>> a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
Microsoft's compiler did not report certain errors that any
conforming C
compiler is required by the standard to report.
Microsoft's compiler *can* be invoked in a way that causes it to
diagnose such errors, though it may or may not become fully conforming. >>>> I haven't used it lately, but a web search should tell you how to do
that.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors >>>>>> would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted >>>>>> for decades. Can you understand why I might decide that analyzing >>>>>> your claims is not worth my time?
I learned C back when K & R was the standard.
So did I. I've kept up with the language as it has changed.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point.
Great. Then why do you keep posting code? Or is the above DDD()
function not included in "any of my code")?
For example when >>>>> the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
That's too vague for me to comment.
Do you know what a C language interpreter is?
I actually do this at the x86 machine code level
yet most people don't have a clue about that.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The above hypothetical HHH emulates the first four
instructions of DDD. This sequence repeats until a
OOM error.
Only in your dream, because HHH has code to abort and after that abort
the program halts without OOM error.
Every competent C programmer will understand that.
The above set of hypothetical HHH instances correctly
simulates 1 or more instructions of DDD including
its call to HHH(DDD). This does include HHH emulating
itself emulating DDD.
If you think it is impossible for HHH to emulate itself
emulating DDD then you don't have a clue about cooperative
multi-tasking and differing process contexts.
On 5/9/2025 5:59 AM, Richard Damon wrote:
On 5/9/25 12:22 AM, Keith Thompson wrote:
Richard Damon <news.x.richarddamon@xoxy.net> writes:
On 5/8/25 10:23 PM, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the abovevoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
that
implies that HHH does not correctly simulate DDD. Richard, you've
read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code
is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to >>>>> do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
You are missing the equivocation he is using on what is "DDD()"
First, he tries to define it as just the code of the function, and not >>>> including any of the code that it calls. He does this so all the
various HHH that he talks about are given the "same" input.
Then he tries to also say that when those functions look at DDD, they
can follow the memory chain to the functions that it calls, that
weren't actually part of the input.
This means the "behavior" of his input isn't actually defined by the
input.
I haven't seen any of that in the posts to which I've recently replied
(and I absolutely do not have the patience to read everything he's
posted here).
What I've seen in the articles to which I've recently replied has been
just a strangely little C function and some claims about simulation.
Viewed in isolation, I don't think any of that (again, ignoring the vast >>> majority of what he's posted in this newsgroup) seems contradictory
so far.
The problem is the subtile one that he needs all "versions" of the
input "DDD" to be the "same input" no matter what decider he uses,
which means he can't include the code for the decider called as part
of the input.
But also, as I explained, he needs to define the decider to be a pure
function to outlaw the trivial solution of the decider short-cutting
itself when it is called by the input with a static variable, which
means it can't do the job without it being part of the input.
He has also, to get around other objections about what he is doing,
stipulated that his functions must be pure functions, and thus only
dependent on their direct input, other wise we can add the following
code to the beginning of HHH to make his statement false:
I've seen no mention of pure functions in the posts to which I've
recently replied.
Again, that is because that side of the equivocation hasn't been
argued recently. Perhaps when he starts to argue that the decider is
allowed to look at the "non-input" code, we will get back to that.
void DDD()
{
HHH(DDD);
return;
}
*Subtle strawman deception change away from this exact subject*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
On 5/8/2025 11:22 PM, Keith Thompson wrote:
Richard Damon <news.x.richarddamon@xoxy.net> writes:
On 5/8/25 10:23 PM, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the abovevoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
that
implies that HHH does not correctly simulate DDD. Richard, you've read >>>> far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code
is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
You are missing the equivocation he is using on what is "DDD()"
First, he tries to define it as just the code of the function, and not
including any of the code that it calls. He does this so all the
various HHH that he talks about are given the "same" input.
Then he tries to also say that when those functions look at DDD, they
can follow the memory chain to the functions that it calls, that
weren't actually part of the input.
This means the "behavior" of his input isn't actually defined by the
input.
I haven't seen any of that in the posts to which I've recently replied
(and I absolutely do not have the patience to read everything he's
posted here).
What I've seen in the articles to which I've recently replied has been
just a strangely little C function and some claims about simulation.
Viewed in isolation, I don't think any of that (again, ignoring the vast
majority of what he's posted in this newsgroup) seems contradictory so
far.
When viewed in isolation (as intended) there is no basis
for rebuttal. Richard refers to extraneous irrelevant
points in an attempt to deflect the conversation away
from the simple truth:
void DDD()
{
HHH(DDD);
return;
}
"..DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction."
He has also, to get around other objections about what he is doing,
stipulated that his functions must be pure functions, and thus only
dependent on their direct input, other wise we can add the following
code to the beginning of HHH to make his statement false:
I've seen no mention of pure functions in the posts to which I've
recently replied.
[...]
Dodging and weaving is Richard's style.
On 5/9/2025 3:47 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 04:23 schreef Keith Thompson:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that
implies that HHH does not correctly simulate DDD. Richard, you've read >>> far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
What you are missing is that the next step of olcott is to say that
when he uses the 'exact same HHH, with only some extra code to abort
the simulation', it is still an infinite recursion. He does not
understand that adding the abort code makes the behaviour
fundamentally different.
When 1 or more statements of DDD are correctly simulated
by HHH this correctly simulated DDD cannot possibly reach
its own "return statement" final halt state.
Reaching the final halt state is the only correct
measure of halting. Thus the finite string input
to HHH(DDD) specifies a non-halting sequence of
configurations.
It is difficult for him to understand, because he refuses to use
different names for the different versions of HHH, because he dreams
that they are al exactly the same (except for small changes).
On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 01:53 schreef olcott:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly
wrong* leads me to think that he is largely ignorant of C (which is >>>>>> fine, most people are) and is unwilling to admit it. Watching the >>>>>> reactions of actual experts to his mathematical arguments leads me >>>>>> to the same conclusion about his knowledge of the relevant fields
of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
[...]
So you normally compile your code using the 2017 version of Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct
a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors
would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted
for decades. Can you understand why I might decide that analyzing
your claims is not worth my time?
I learned C back when K & R was the standard.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
A vacuous statement, because HHH cannot correctly simulate DDD, which
includes HHH itself.
A vacuous statement does not prove anything.
You are saying that the smartest genius (not me)
in the universe cannot possibly create an HHH
that simulates itself simulating DDD?
What is the evidence for this wild-eyed claim?
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that implies that HHH does not correctly simulate DDD. Richard, you've read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell, assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
On 5/9/2025 10:42 AM, joes wrote:
Am Fri, 09 May 2025 10:33:27 -0500 schrieb olcott:
On 5/9/2025 3:39 AM, Fred. Zwarts wrote:Because it runs forever, and a decider needs to return.
Op 09.mei.2025 om 01:53 schreef olcott:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
A vacuous statement, because HHH cannot correctly simulate DDD, whichYou are using C, a language in which you appear to have littleI learned C back when K & R was the standard.
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted >>>>>> for decades. Can you understand why I might decide that analyzing >>>>>> your claims is not worth my time?
We don't need to look at any of my code for me to totally prove my
point. For example when the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own "return" instruction. >>>>>
includes HHH itself.
A vacuous statement does not prove anything.
You are saying that the smartest genius (not me)
in the universe cannot possibly create an HHH that simulates itself
simulating DDD?
What is the evidence for this wild-eyed claim?
In other words you are trying to change the subject
from this:
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 01:53 schreef olcott:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly
wrong* leads me to think that he is largely ignorant of C (which is >>>>>> fine, most people are) and is unwilling to admit it. Watching the >>>>>> reactions of actual experts to his mathematical arguments leads me >>>>>> to the same conclusion about his knowledge of the relevant fields
of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
[...]
So you normally compile your code using the 2017 version of Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct
a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors
would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted
for decades. Can you understand why I might decide that analyzing
your claims is not worth my time?
I learned C back when K & R was the standard.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
A vacuous statement, because HHH cannot correctly simulate DDD, which
includes HHH itself.
A vacuous statement does not prove anything.
If you think it is impossible for HHH to emulate itself
emulating DDD then you don't have a clue about cooperative
multi-tasking with differing process contexts.
On 5/9/2025 4:03 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 03:35 schreef olcott:
On 5/8/2025 8:13 PM, Richard Damon wrote:
On 5/8/25 8:05 PM, olcott wrote:
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
If you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
No, what you need is someone who is an expert in mathematical logic >>>>>> (I am not) who can explain to you, in terms you can understand and >>>>>> accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
No, the problem is you don't.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
And claiming the behavior of a program that isn;t the behavior of
that program is just a lie.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
No need to repeat vacuous statements. It does not matter how many
times you multiply 0, it will remains 0.
DDD contains an HHH that aborts,
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
so a correct simulation will take that into account and reach the
'return'. HHH does not do such a correct simulation, which makes your
statements vacuous.
On 5/9/2025 4:00 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 02:05 schreef olcott:
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
If you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
No, what you need is someone who is an expert in mathematical logic
(I am not) who can explain to you, in terms you can understand and
accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
The HHH that you propose and is included in DDD does halt. But it is
known that this HHH prematurely aborts which makes it impossible for
the simulation to reach the reachable 'return'. HHH simply ignores the
conditional abort in the simulation.
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On 5/8/2025 9:02 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
No, what you need is someone who is an expert in mathematical logicIf you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
(I am not) who can explain to you, in terms you can understand and
accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
You see, this is something you've gotten wrong, and you need somebody
who can explain that to you in terms you can understand and accept.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
Is there any reason you couldn't have written that as follows?
void DDD(void)
{
HHH(DDD);
}
You could then talk about it not reaching its closing brace rather
than not reaching its "return" instruction. BTW, it's correctly
called a "return statement" in C; dropping it would make it easier
to avoid your incorrect use of terminology. (Assembly or machine
code has "instructions"; C has "statements" and "declarations".)
I need the "return statement" to explicitly
mark the computer science: "final halt state".
DDD correctly simulated by HHH is the same thing
as infinite recursion between HHH and DDD yet is
implemented as recursive simulation.
Sure, infinite recursion is infinite, regardless of how it's
implemented, assuming it's implemented correctly. That's so trivally
obvious that I simply don't believe that "the comp.sci" people are
failing to understand it -- though I can believe that you believe it.
Richard provided the same kind of fake "rebuttal"
that I always get.
void DDD()
{
HHH(DDD);
return;
}
"..DDD correctly simulated by HHH cannot
possibly REACH its own "return statement".
Everyone here has been denying that simple
statement for three years. They do this by
changing the subject away from the question
being asked to irrelevant details.
I am only referring to the above hypothetical
HHH/DDD pair of C functions.
When 1 or more statements of DDD are correctly
simulated by HHH then the simulated DDD cannot
possibly reach its own "return statement" final
halt state.
On 5/9/2025 4:48 AM, joes wrote:
Am Thu, 08 May 2025 22:34:35 -0500 schrieb olcott:
On 5/8/2025 10:14 PM, Mike Terry wrote:Yeah, so not a full simulation.
On 09/05/2025 03:13, olcott wrote:
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
His simulation is in fact a single-stepped x86 instruction simulation, >>>> where the stepping of each x86 instruction is under the HHH's control. >>>> HHH can continue stepping the simulation until its target returns, inA full simulation of infinite recursion?
which case the situation is logically just like direct call, as you
have described. Or HHH could step just 3 x86 instructions (say) and
then decide to return (aka "abort" its simulation). Let's call that / >>>> partial/ simulation in contrast with /full/ simulation which you've
been supposing.
I am only doing one tiny idea at a time here.
Didn't you know this?
It is incorrect for a simulating termination analyzer
to do a full simulation of a non-halting input.
That's wrong as written. HHH cannot simulate DDD returning in aNo one here ever agreed that when 1 or more instructions of DDD areEverybody on comp.theory understands this much.In practice, the program will likely crash due to a stack overflow, >>>>>> unless the compiler implements tail-call optimization, in which case >>>>>> the program might just run forever -- which also means theYes you totally have this correctly.
unnecessary return statement will never be reached.
None of the dozens of comp.theory people could ever achieve that level >>>>> of understanding even after three years. That is why I needed to post >>>>> on comp.lang.c.
correctly simulated by HHH that DDD cannot possibly reach its own
"return" instruction.
finite number of instructions, it takes infinitely many.
HHH can simulate 1 or more instructions of DDD,
this is not actually logically impossible.
When HHH does correctly simulate 1 or more
instructions of DDD then DDD never reaches its
"return statement" final halt state.
This conclusion relies on my understanding of what you've said about >>>>>> your code, which I consider to be unreliable.
Hmm, did PO make it clear that when he says
"..DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction."
he is not talking about whether "DDD halts"? [I.e. halts when run
directly from main() outside of a simulator.] No, what he is talking >>>> about is whether the /step-by-step partial simuation/ of DDD performed >>>> by HHH proceeds as far as DDD returning.
When 1 or more steps of DDD are correctly simulated by HHH the simulated >>> DDD cannot possibly reach its "return" instruction (final halt state).
No one here has agreed to that. Not in several years of coaxing and
elaboration.
It's true for a finite number. Aborting is not correct simulation, even
if HHH did return that DDD halts.
Didn't you know this?
It is incorrect for a simulating termination analyzer
to do a full simulation of a non-halting input.
On 5/9/2025 1:17 AM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 12:31 AM, Keith Thompson wrote:[...]
You didn't respond to the above. I'll ask directly.
Would I need to understand x86 code to understand your claims? Yes
or no.
It makes it much easier because the state transition graph
of the control flow at the x86 level is unequivocal.
What a pity you couldn't have made that clear much sooner.
Your help on the C part was very useful.
The x86 part is only needed to understand
the internals of the simulating termination
analyzer.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
You don't need to understand the first two instructions.
The next two instructions simply call HHH(DDD) in
recursive emulation.
At the x86 machine code level HHH can see that the
first four instructions of DDD repeats. It sees this
after it emulates DDD and then emulates itself
emulating DDD once.
As I said, I'm not very familiar with x86 code, and it's
absolutely not worth my time and effort to learn it for the sake
of understanding your claims.
Bye.
On 5/9/2025 4:14 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 04:13 schreef olcott:
On 5/8/2025 8:30 PM, Keith Thompson wrote:Only if you forget that your proposed HHH aborts and returns.
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells >>>>>> me nothing about what it's supposed to do. Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is passed
to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH to
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
*This slight augmentation takes that into account*
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On 5/9/2025 6:25 AM, Richard Damon wrote:
On 5/8/25 6:20 PM, olcott wrote:
On 5/8/2025 5:13 PM, Richard Heathfield wrote:
On 08/05/2025 22:41, olcott wrote:
What my code actually does is totally irrelevant.
On that, at least, we can agree.
That an HHH can be created that does correctly
determine the halt status of this input is the
whole point.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Except that it doesn't, as your "input", being just that function,
doesn't HAVE a halting status. It only gets that once it is paired
with a specific version of HHH.
If that HHH aborts its simulation and returns 0, then it halts, and
that HHH wasn't a correct halt decider.
Since you claim that is what you HHH does, and that would be the DD
that it is given, it is thus clear that when we fix your input to be
what you intend, your claim is false.
That you keep making your "clearly false due to the category error in
it" claim just shows your stupidity.
You just don't understand the basic meaning of the terms you use,
because you decided it would be better to be ignorant, then to know
you are wrong.
You try to get away with changing the subject from this:
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On 5/9/2025 3:33 AM, Fred. Zwarts wrote:
Op 08.mei.2025 om 21:42 schreef olcott:
On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
Op 08.mei.2025 om 19:00 schreef olcott:
On 5/8/2025 11:14 AM, Mike Terry wrote:And since H does not correctly determine that its simulated D would
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works. >>>>>> That's to be expected, and PO's response ought to be to explain it >>>>>> so that you understand. Instead he goes off on one of his rants, >>>>>> so blamewise it's really down to PO.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to >>>>>>>>> stop at HHH's first departure from the rules of the C
programming language (or at least the first departure I spot). >>>>>>>>>
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well,
but you make essentially the same mistake --- writing to memory
that your program doesn't own --- no fewer than four times in a
single function.
I'll ignore the syntax error (a null statement at file scope is >>>>>>>>> a rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null >>>>>>>>> pointer constant... which is fine as long as you don't try to >>>>>>>>> deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax >>>>>>>>> errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you / >>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for >>>>>>>>> pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to >>>>>>> dereference a null pointer, you have no business trying to teach >>>>>>> anyone anything about C.
Your code is the work of a programmer so hideously incompetent
that 'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about
denigrating other people's C knowledge is the height of arrogant >>>>>>> hypocrisy.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative
calls that halt7.c code can make, such as Allocate(), used to
allocate a block of memory for use in halt7.c. Within halt7.c
code calls an Allocate() function, and x86utm intercepts that and
performs the function internally, then jumps the calling code in
halt7.c over the Allocate call where it continues as normal. The >>>>>> call never goes to the implementation of Allocate in halt7.c, so
the null pointer dereferencing does not actually occur. There are >>>>>> a whole bunch of similar x86utm primitive operations that work in
the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> *until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
never stop running unless aborted, it is a vacuous statement and
Sipser's agreement does not tell anything.
That is counter factual as any fully qualified
C programmer will tell you.
All fully qualified C programmers told me that it is not counter-
factual. But I suppose in your language counter-factual means 'not in
my dreams'.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by any HHH cannot
possibly reach its own simulated "return"
instruction.
Another vacuous statement, as HHH cannot correctly simulate DDD which
includes HHH itself.
It is stipulated that HHH does simulate itself
simulating DDD. It is also conclusively proven in
code that you cannot understand.
On 5/9/2025 4:25 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 01:48 schreef olcott:
On 5/8/2025 6:35 PM, Richard Damon wrote:Indeed, therefore HHH should process the actual input: including the
On 5/8/25 1:00 PM, olcott wrote:
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works. >>>>>> That's to be expected, and PO's response ought to be to explain it >>>>>> so that you understand. Instead he goes off on one of his rants, >>>>>> so blamewise it's really down to PO.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to >>>>>>>>> stop at HHH's first departure from the rules of the C
programming language (or at least the first departure I spot). >>>>>>>>>
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well,
but you make essentially the same mistake --- writing to memory
that your program doesn't own --- no fewer than four times in a
single function.
I'll ignore the syntax error (a null statement at file scope is >>>>>>>>> a rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null >>>>>>>>> pointer constant... which is fine as long as you don't try to >>>>>>>>> deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax >>>>>>>>> errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you / >>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for >>>>>>>>> pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to >>>>>>> dereference a null pointer, you have no business trying to teach >>>>>>> anyone anything about C.
Your code is the work of a programmer so hideously incompetent
that 'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about
denigrating other people's C knowledge is the height of arrogant >>>>>>> hypocrisy.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative
calls that halt7.c code can make, such as Allocate(), used to
allocate a block of memory for use in halt7.c. Within halt7.c
code calls an Allocate() function, and x86utm intercepts that and
performs the function internally, then jumps the calling code in
halt7.c over the Allocate call where it continues as normal. The >>>>>> call never goes to the implementation of Allocate in halt7.c, so
the null pointer dereferencing does not actually occur. There are >>>>>> a whole bunch of similar x86utm primitive operations that work in
the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
Excpet, as you have admitted, your DD isn't a program (just a C
funciton), and thus not a proper input for a halt decider, which by
definiton must be a program.
Your C function can't be a program, as you have specifically said
that the function, and only the funciton is the input, and programs
must include in them all their code, so since the code of HHH isn't
included in DD or the input representing it, it isn't a program, and
thus not a proper input
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> *until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
But that statement implies, as required that H be a halt decider and
D to be a proper input to one, neither of which are satisfied, as
you have admitte
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
But it doesn't, as it doesn't correctly follow the behavior of the
x86 language, as that requires HHH to follow the call instruction,
which it can not do as the required (and accepted by your) condition
that the decider is a pure function, which means it can only look at
its input, which does not include the code which the call points to.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
Right, and a halt decider is required to (try to) compute the
mapping from the input (which needs to be the representation of a
program) to the results of running that program (since that is the
DEFINITION of Halt Deciding).
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Right, just as HHH trying to claim that its answer is based on the
fact that it can't reach the end of its simulation of the input
isn't the correct requirement for HHH.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
Right, which is Halting, since that behavior is DEFINED to be the
behavior of running the program the input represents.
Just like requiring sum(3,2) to report on the sum of 5 + 7
a value other than its input specifies HHH IS NOT ALLOWED
to report on anything other than the behavior that its input
specifies.
HHH that aborts, not the hypothetical HHH that does not abort.
HHH cannot say to itself I have no need to abort
because I will abort later on. It either aborts
as soon as it recognizes the non terminating
pattern specified by itself input or no HHH ever aborts.
Sum(3,2) should process the actual input, not the hypothetical input 5
and 7.
HHH should process all relevant input, including the part with the
conditional abort, not only the first part of the input.
Sum(3,2) should process all relevant input, not only the 2 and ignore
the 3.
So, go and fix HHH.
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state).
Reaching a final halt state means halting.
Unable to reach a final halt state means non-terminating.
Thus HHH(DDD) is correct to reject its finite input string
DDD as specifying a non-terminating sequence of configurations.
On 5/9/2025 4:28 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 03:55 schreef olcott:
On 5/8/2025 8:18 PM, Richard Damon wrote:
On 5/8/25 7:48 PM, olcott wrote:
On 5/8/2025 6:35 PM, Richard Damon wrote:
On 5/8/25 1:00 PM, olcott wrote:
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated byLet's take a look.
HHH according to the rules of the C programming language >>>>>>>>>>>
The file is 1373 lines long, but don't worry, because I plan >>>>>>>>>>> to stop at HHH's first departure from the rules of the C >>>>>>>>>>> programming language (or at least the first departure I spot). >>>>>>>>>>>
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well, >>>>>>>>> but you make essentially the same mistake --- writing to memory >>>>>>>>> that your program doesn't own --- no fewer than four times in a >>>>>>>>> single function.
I'll ignore the syntax error (a null statement at file scope >>>>>>>>>>> is a rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a >>>>>>>>>>> null pointer constant... which is fine as long as you don't >>>>>>>>>>> try to deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring >>>>>>>>>>> syntax errors, remember). destination is a null pointer, so >>>>>>>>>>> destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And >>>>>>>>>>> you / dare/ to impugn other people's C knowledge! Crack a >>>>>>>>>>> book, for pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea >>>>>>>>> to dereference a null pointer, you have no business trying to >>>>>>>>> teach anyone anything about C.
Your code is the work of a programmer so hideously incompetent >>>>>>>>> that 'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about
denigrating other people's C knowledge is the height of
arrogant hypocrisy.
works. That's to be expected, and PO's response ought to be to >>>>>>>> explain it so that you understand. Instead he goes off on one >>>>>>>> of his rants, so blamewise it's really down to PO.
PO's halt7.c is compiled (it is not linked), then the obj file >>>>>>>> is fed as input to his x87utm.exe which is a kind of x86 obj
code execution environment. x87utm provides a number of
primative calls that halt7.c code can make, such as Allocate(), >>>>>>>> used to allocate a block of memory for use in halt7.c. Within >>>>>>>> halt7.c code calls an Allocate() function, and x86utm intercepts >>>>>>>> that and performs the function internally, then jumps the
calling code in halt7.c over the Allocate call where it
continues as normal. The call never goes to the implementation >>>>>>>> of Allocate in halt7.c, so the null pointer dereferencing does >>>>>>>> not actually occur. There are a whole bunch of similar x86utm >>>>>>>> primitive operations that work in the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
Excpet, as you have admitted, your DD isn't a program (just a C
funciton), and thus not a proper input for a halt decider, which
by definiton must be a program.
Your C function can't be a program, as you have specifically said
that the function, and only the funciton is the input, and
programs must include in them all their code, so since the code of >>>>>> HHH isn't included in DD or the input representing it, it isn't a
program, and thus not a proper input
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
*until H correctly determines that*
*its simulated D would never stop running unless aborted* >>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
But that statement implies, as required that H be a halt decider
and D to be a proper input to one, neither of which are satisfied, >>>>>> as you have admitte
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
But it doesn't, as it doesn't correctly follow the behavior of the >>>>>> x86 language, as that requires HHH to follow the call instruction, >>>>>> which it can not do as the required (and accepted by your)
condition that the decider is a pure function, which means it can
only look at its input, which does not include the code which the
call points to.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
Right, and a halt decider is required to (try to) compute the
mapping from the input (which needs to be the representation of a
program) to the results of running that program (since that is the >>>>>> DEFINITION of Halt Deciding).
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Right, just as HHH trying to claim that its answer is based on the >>>>>> fact that it can't reach the end of its simulation of the input
isn't the correct requirement for HHH.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
Right, which is Halting, since that behavior is DEFINED to be the
behavior of running the program the input represents.
Just like requiring sum(3,2) to report on the sum of 5 + 7
a value other than its input specifies HHH IS NOT ALLOWED
to report on anything other than the behavior that its input
specifies.
Its input specifies that it calls HHH(DD) in recursive
emulation. THIS CANNOT BE IGNORED.
No it doesn't, it calls HHH, which does what it does. Since your
decider HHH is defined to abort and return 0, so is the HHH that DD
calls, since it was built from that machine.
What we can not ignore is that HHH has a definition, and HHH needs
to interprete the call in DD by that definition, not you LIE that
HHH is just a correct simulator, since it isn't.
Sorry, you are the one that is choosing to ignore the input and
replace it with somethng it isn't, becaue you don't understand that
you did define it when you created your HHH to abort and return 0.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For every HHH that can possibly exist at machine address
000015d2 that correctly emulates 1 or more x86 instructions
of DDD (the exact machine code bytes specified above) no
correctly emulated DDD ever reaches their own "return"
instruction.
This may simply be too difficult for most everyone here.
Instead of simply saying they they don't understand the
x86 language they try to deflect away from this subject
to try to hide their own ignorance.
Nobody disagreed with it, we all see that HHH fails to reach the
'return', because it prematurely aborts
*That remains counter-factual because this is true*
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
On 5/9/2025 3:07 PM, Richard Heathfield wrote:
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively what
you're trying to do when you fire up the simulation from inside DDD).
How the Hell did you twist my words to say that?
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On 5/9/2025 3:07 PM, Richard Heathfield wrote:
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is
effectively what you're trying to do when you fire up the
simulation from inside DDD).
How the Hell did you twist my words to say that?
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On 5/9/2025 12:00 PM, Richard Damon wrote:
On 5/9/25 11:48 AM, olcott wrote:
On 5/9/2025 3:47 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 04:23 schreef Keith Thompson:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that >>>>> implies that HHH does not correctly simulate DDD. Richard, you've
read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is >>>>> equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell, >>>>> assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to >>>>> do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
What you are missing is that the next step of olcott is to say that
when he uses the 'exact same HHH, with only some extra code to abort
the simulation', it is still an infinite recursion. He does not
understand that adding the abort code makes the behaviour
fundamentally different.
When 1 or more statements of DDD are correctly simulated
by HHH this correctly simulated DDD cannot possibly reach
its own "return statement" final halt state.
But HHH can not correctly emulate this input (the code of just DDD)
past the call instruction and remain a pure function, as it hasn't
been given that code.
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively
what you're trying to do when you fire up the simulation from inside
DDD).
How the Hell did you twist my words to say that?
I haven't touched your words. What I have done is to observe that
DDD's /only/ action is to call a simulator. Since DDD isn't itself a
simulator, there is nothing to simulate except a call to a simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains
control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On what grounds can you persuade an extraordinarily sceptical
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will never be reached. In practice, the program will likely crash due to a stack overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the unnecessary return statement will never be reached.
On 5/8/2025 11:11 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:Does HHH correctly simulate DDD *and do nothing else*?
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make
the same claim). I don't know what HHH is. The name "HHH" tells >>>>>> me nothing about what it's supposed to do. Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate *every* function whose address is passed
to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH toAssuming that HHH(DDD) "correctly simulates" DDD, and assuming it
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
I find that difficult to believe.
Then the return statement (which is unnecessary anyway) will never be
reached.
It is only there to mark a final halt state.
The closing "}" does that equally well.
In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
I'll note that I've posted in comp.theory, not in comp.lang.c.
I never see anything you post in comp.lang.c.
This conclusion relies on my understanding of what you've said about
your code, which I consider to be unreliable.
I am not even talking about my code. I am
talking about the purely hypothetical code
that you just agreed to.
Do not overestimate what I've agreed to. I must still consider the
possibility that I've been led into a logical trap of some sort,
and that I've missed some subtle flaw.
No doubt you believe that there is some significance to the
apparent fact that the return statement will never be reached,
assuming that's a correct and relevant conclusion. I don't know
what that significance might be.
I will tell you that later after you understand
some prerequisite ideas first.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
So now HHH returns an int result, and you store that result
in a variable named "Halt_Status". You haven't said here what
the meaning of that result might be, and I decline to make any
assumptions based on what you've called it. You could rename
"Halt_Status" to "Foo" and have effectively identical code.
Previously DDD would "correctly simulate" the function whose address is
passed to it. Now it does that and returns an int result.
If you want to say anything about the meaning of the result returned
by HHH, feel free to say it.
The same thing that applied to DDD equally
applies to the more complicated DD.
When 1 or more instructions of DD are correctly
simulated by HHH the correctly simulated DD
cannot possibly get past its call to HHH(DD).
Thus DD also never reaches its "return" instruction.
Now you're talking about simulating "1 or more instructions"
of DD. I thought that HHH was supposed to "accurately simulate"
the function whose argument is passed to it. Emulating just "1 or
more instructions" is not accurate simulation.
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
When 1 or more instructions of DD are correctly
emulated by HHH the correctly emulated DD cannot
possibly get past its call to HHH(DD).
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is
effectively what you're trying to do when you fire up the
simulation from inside DDD).
How the Hell did you twist my words to say that?
I haven't touched your words. What I have done is to observe
that DDD's /only/ action is to call a simulator. Since DDD
isn't itself a simulator, there is nothing to simulate except a
call to a simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never
regains control after the first recursion. To return, it must
abort the simulation, which means the simulation fails.
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On what grounds can you persuade an extraordinarily sceptical
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) willnever be
reached.
HHH cannot successfully complete its task, because it never
regains control after the first recursion.
In practice, the program will likely crash due to a
stack
overflow, unless the compiler implements tail-calloptimization, in
which case the program might just run forever -- which alsomeans the
unnecessary return statement will never be reached.
On 5/9/2025 6:36 PM, Richard Damon wrote:
On 5/9/25 7:02 PM, olcott wrote:
On 5/8/2025 11:11 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:Does HHH correctly simulate DDD *and do nothing else*?
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make >>>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells >>>>>>>> me nothing about what it's supposed to do. Without knowing what >>>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?). >>>>>>>>
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate *every* function whose address is passed >>>>>> to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between >>>>>> calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH toAssuming that HHH(DDD) "correctly simulates" DDD, and assuming it
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
I find that difficult to believe.
Then the return statement (which is unnecessary anyway) will never be >>>>>> reached.
It is only there to mark a final halt state.
The closing "}" does that equally well.
In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in >>>>>> which case the program might just run forever -- which also means the >>>>>> unnecessary return statement will never be reached.
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
I'll note that I've posted in comp.theory, not in comp.lang.c.
I never see anything you post in comp.lang.c.
This conclusion relies on my understanding of what you've said about >>>>>> your code, which I consider to be unreliable.
I am not even talking about my code. I am
talking about the purely hypothetical code
that you just agreed to.
Do not overestimate what I've agreed to. I must still consider the
possibility that I've been led into a logical trap of some sort,
and that I've missed some subtle flaw.
No doubt you believe that there is some significance to the
apparent fact that the return statement will never be reached,
assuming that's a correct and relevant conclusion. I don't know
what that significance might be.
I will tell you that later after you understand
some prerequisite ideas first.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
So now HHH returns an int result, and you store that result
in a variable named "Halt_Status". You haven't said here what
the meaning of that result might be, and I decline to make any
assumptions based on what you've called it. You could rename
"Halt_Status" to "Foo" and have effectively identical code.
Previously DDD would "correctly simulate" the function whose address is >>>> passed to it. Now it does that and returns an int result.
If you want to say anything about the meaning of the result returned
by HHH, feel free to say it.
The same thing that applied to DDD equally
applies to the more complicated DD.
When 1 or more instructions of DD are correctly
simulated by HHH the correctly simulated DD
cannot possibly get past its call to HHH(DD).
Thus DD also never reaches its "return" instruction.
Now you're talking about simulating "1 or more instructions"
of DD. I thought that HHH was supposed to "accurately simulate"
the function whose argument is passed to it. Emulating just "1 or
more instructions" is not accurate simulation.
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, Correctly Emulating *ALL* of the instructions is the definition of
correct emulation.
In other words it is waaayyy over your head that
when correctly emulating an infinite number of
instructions of DD is not enough for DD correctly
emulated by HHH to reach its own final halt
state that fewer than infinity might be enough?
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that implies that HHH does not correctly simulate DDD. Richard, you've read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell, assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately simulating the
whole of DDD's behaviour.
On 5/9/25 8:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:This is just typical Olcottian behavior, Actual definitons
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
don't matter to him, which is what makes so much of what he says
just turn out to be lies when they are interpreted (as they must
be) with the actual definitions.
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to
accept incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to
accept incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
On 5/9/2025 8:32 PM, Richard Heathfield wrote:<snip>
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to
accept incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
The entire sequence of the first four instructions
of DDD is emulated correctly.
On 5/9/2025 7:23 PM, Mike Terry wrote:
On 09/05/2025 03:23, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that
implies that HHH does not correctly simulate DDD. Richard, you've read >>> far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
Depends on what you've picked up on.
Do you get that HHH's simulation is a /partial/ simulation? HHH is free
That was not in the specification that he responded to.
Thus within this specification DDD correctly simulated
by HHH cannot possibly reach its final halt state in an
infinite number of steps.
If an infinite number steps steps is insufficient
then how can less an infinite steps possibly help?
to simulate a few x86 instructions of DDD, and then simply abandon the
simulation and return. Since such a simulation is obviously NOT
equivalent to a direct call to DDD, and above you argue that it is,
I'd say you've missed that.
The other thing to be aware of is that use of terminology "simulation"
varies considerably between posters! This in turn affects what
different posters consider a "correct" simulation.
<snip>
PO is a (b)(c) guy. Since his HHH (more or less) simulates individual
instructions correctly, PO claims HHH "correctly" simulates DDD.
Others who are in (a) or (d) camps would say that HHH does not
correctly simulate DDD, because either HHH performs a /partial/
simulation [for them an error in its own right] or because HHH decides
nothalt when in fact PO's DDD halts.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Try to show how DDD simulated by HHH according to the
rules of the x86 language reaches its own "ret"
instruction final state and you already know that
you will fail. You dodge this question so that
you can remain disagreeable.
Terminology usage is not a right/wrong issue, but the different
possibilities maximise misunderstandings if not resolved. E.g. as I
said PO's simulations are nearly always taken to be partial. Richard
D. knows that, but as he is in (b) camp he points out that PO is lying
every time he says "HHH correctly simulates DDD". PO then says RD is
playing head games and challenges RD to point out an error, and so it
goes on for hundreds of posts. To be fair, PO should be well aware
that RD is in camp (a), but does nothing to resolve the terminology
issue, so both posters get what they deserve!
I resolved the terminology issue long ago and
you and everyone else ignores this so that you
can remain disagreeable.
When one or more instructions of DDD are emulated
by HHH according to the rules of the x86 language
this emulated DDD cannot possibly reach its own
final halt state because it calls HHH(DDD) in
recursive emulation.
FTR I am in the (b)(c) camp... I could explain why I think that's
more logical, but that's going OT I think.
Other posters have suggested that what you're missing is some
variation of "once you answer PO's current question (about whether the
simulation by HHH progresses as far as DDD's return) PO will go on to
do something else wrong". Well, of course he will, but that's hardly
something you're missing if he's not done it yet! :) I'd also say
it's no reason not to answer PO's question honestly, acknowledging
that he is talking about /partial/ simulations... The time to
challenge future mistakes he will go on to make, is when he makes them.
Mike.
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately simulating the
whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
On 5/9/2025 7:38 PM, Richard Damon wrote:
On 5/9/25 8:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:This is just typical Olcottian behavior, Actual definitons don't
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately simulating
the whole of DDD's behaviour.
matter to him, which is what makes so much of what he says just turn
out to be lies when they are interpreted (as they must be) with the
actual definitions.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Try to show how DDD simulated by HHH according to the
rules of the x86 language reaches its own "ret"
instruction final state and you already know that
you will fail. You dodge this question so that
you can remain disagreeable.
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately simulating
the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to accept
incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
On 5/9/2025 9:15 PM, Richard Heathfield wrote:
On 10/05/2025 02:48, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to accept
incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
Assumes facts not in evidence. Your HHH function is in a translation
unit that contains a syntax error.
It is a truism that when DDD is emulated by HHH
according to the rules of the x86 language that
the first four instructions of DDD would be emulated
and then HHH would also be required to emulate
itself emulating DDD.
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately simulating >>>>>> the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to accept
incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The entire sequence of the first four instructions
of DDD is emulated correctly. This sequence also
includes HHH emulating itself emulating DDD. This
results in a whole other sequence of first three
instructions of DDD being correctly emulated.
On 5/9/2025 9:20 PM, Richard Damon wrote:
Excpet that no HHH CAN correct emulate the DDD that you give
it, as the input for DDD just isn't a complete program,
Do I have to repeat this 1000 times before you ever notice
that I said it once?
On 5/9/2025 9:25 PM, Richard Damon wrote:
On 5/9/25 8:54 PM, olcott wrote:
On 5/9/2025 7:38 PM, Richard Damon wrote:
On 5/9/25 8:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:This is just typical Olcottian behavior, Actual definitons don't
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately simulating
the whole of DDD's behaviour.
matter to him, which is what makes so much of what he says just turn
out to be lies when they are interpreted (as they must be) with the
actual definitions.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Try to show how DDD simulated by HHH according to the
rules of the x86 language reaches its own "ret"
instruction final state and you already know that
you will fail. You dodge this question so that
you can remain disagreeable.
The problem is that HHH can not emulate this input past the call
000015d2 instruction,
Do I have to repeat this 1000 times !!!
HHH is in the same memory space as DDD
HHH is in the same memory space as DDD
HHH is in the same memory space as DDD
HHH is in the same memory space as DDD
HHH is in the same memory space as DDD
so when DDD calls HHH(DDD) then HHH must
emulate itself emulating DDD OR IT IS WRONG
On 5/9/2025 9:20 PM, Richard Damon wrote:
On 5/9/25 8:48 PM, olcott wrote:
On 5/9/2025 7:23 PM, Mike Terry wrote:
On 09/05/2025 03:23, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that >>>>> implies that HHH does not correctly simulate DDD. Richard, you've
read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is >>>>> equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell, >>>>> assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to >>>>> do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
Depends on what you've picked up on.
Do you get that HHH's simulation is a /partial/ simulation? HHH is
free
That was not in the specification that he responded to.
Thus within this specification DDD correctly simulated
by HHH cannot possibly reach its final halt state in an
infinite number of steps.
Excpet that no HHH CAN correct emulate the DDD that you give it, as
the input for DDD just isn't a complete program,
Do I have to repeat this 1000 times before you ever notice
that I said it once?
HHH is in the same freaking memory space as DDD.
On 5/9/2025 9:15 PM, Richard Heathfield wrote:
On 10/05/2025 02:48, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to accept
incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
Assumes facts not in evidence. Your HHH function is in a translation
unit that contains a syntax error.
It is a truism that when DDD is emulated by HHH
according to the rules of the x86 language that
the first four instructions of DDD would be emulated
and then HHH would also be required to emulate
itself emulating DDD.
On 5/9/2025 9:39 PM, Richard Damon wrote:
On 5/9/25 10:20 PM, olcott wrote:
On 5/9/2025 9:15 PM, Richard Heathfield wrote:
On 10/05/2025 02:48, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to
accept incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
Assumes facts not in evidence. Your HHH function is in a translation
unit that contains a syntax error.
It is a truism that when DDD is emulated by HHH
according to the rules of the x86 language that
the first four instructions of DDD would be emulated
and then HHH would also be required to emulate
itself emulating DDD.
Nope, because by your definitions HHH can not correctly emulate that
DDD, as it doesn't include the code for the HHH that it calls,
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
On 5/9/2025 9:19 PM, Richard Heathfield wrote:
On 10/05/2025 02:50, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:<snip>
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to accept
incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
The entire sequence of the first four instructions
of DDD is emulated correctly.
Nope. Syntax errors don't count as correct.
Any HHH that emulates DDD according to the rules
of the x86 language must emulate the first four
instructions of DDD followed by HHH emulating
itself emulated DDD and then the first three
instructions of DDD when seven of the instructions
of DDD are correctly emulated.
This is axiomatic according to the rules of
the x86 language applied to the input to HHH(DDD).
On 5/9/2025 9:30 PM, Richard Damon wrote:
On 5/9/25 8:51 PM, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately simulating
the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
Nope, as that *IS* the definition of a correct emulation of a non-
halting input, as the definition of "correcdt emulation" is to exactly
reproduce the behavior of that program, so if the program won't halt,
neither can the emulation.
That a psychotic way to define a simulating termination analyzer.
On 5/9/2025 10:12 PM, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 09/05/2025 03:23, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the abovevoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
that
implies that HHH does not correctly simulate DDD. Richard, you've read >>>> far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code
is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
Depends on what you've picked up on.
Do you get that HHH's simulation is a /partial/ simulation? HHH is
free to simulate a few x86 instructions of DDD, and then simply
abandon the simulation and return. Since such a simulation is
obviously NOT equivalent to a direct call to DDD, and above you argue
that it is, I'd say you've missed that.
I have not read the vast majority of olcott's post here. For most
of the recent discussion I had with him, there was no mention of
partial simulation. olcott finally said something about simulating
just a few instructions, but at the same time he finally indicated
that understanding his arguments would require an understanding of
x86 machine and/or assembly language. That's when I bailed out.
A "correct simulation", as I understand the term, would require fully
simulate the execution of DDD. If DDD never halts, its simulation never
halts. olcott seems to think that he's found a way around this that's
relevant to the Halting Problem, but I withdrew before getting to that
point.
It only need be a correct simulation until HHH sees the
repeating pattern that would cause itself to never terminate.
The best selling author of theory of computation textbooks
agreed that I could quote his agreement with my 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 Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively
what you're trying to do when you fire up the simulation from
inside DDD).
How the Hell did you twist my words to say that?
DDD's /only/ action is to call a simulator. Since DDD isn't itself a
simulator, there is nothing to simulate except a call to a
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains
control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will never be
reached. In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so. I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution. I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates
DDD, then HHH correctly simulates DDD". (My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.) I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.
Don't know why you people stick on the 'simulation' stuff so long.
The HP simply asks for such an H (in function form. POOH does not
resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
On 5/9/2025 10:17 PM, Richard Damon wrote:
On 5/9/25 10:27 PM, olcott wrote:
On 5/9/2025 9:19 PM, Richard Heathfield wrote:
On 10/05/2025 02:50, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:<snip>
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to
accept incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
The entire sequence of the first four instructions
of DDD is emulated correctly.
Nope. Syntax errors don't count as correct.
Any HHH that emulates DDD according to the rules
of the x86 language must emulate the first four
instructions of DDD followed by HHH emulating
itself emulated DDD and then the first three
instructions of DDD when seven of the instructions
of DDD are correctly emulated.
This is axiomatic according to the rules of
the x86 language applied to the input to HHH(DDD).
Nope.
I have shown an HHH that just by the rules of the x86 language can
correctly emulate the code of DDD that references itself.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
You cannot possibly show any HHH that emulates this
DDD according to the rules of the x86 language such
that this DDD ever reaches its "ret" instruction
final halt state.
On 5/9/2025 10:13 PM, wij wrote:
On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively >>>>>>> what you're trying to do when you fire up the simulation from
inside DDD).
How the Hell did you twist my words to say that?
DDD's /only/ action is to call a simulator. Since DDD isn't itself a >>>>> simulator, there is nothing to simulate except a call to a
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains
control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will never be >>>>> reached. In practice, the program will likely crash due to a stack >>>>> overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the >>>>> unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so. I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution. I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates
DDD, then HHH correctly simulates DDD". (My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.) I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.
Don't know why you people stick on the 'simulation' stuff so long.
The HP simply asks for such an H (in function form. POOH does not
resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
My invention of a simulating termination
analyzer shows exactly how to compute the
mapping that the input that HHH(DD) specifies
into a correct answer for the halting problem's
otherwise impossible input.
All rebuttals are based on failing to compute
this mapping correctly.
On 5/9/2025 9:40 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively
what you're trying to do when you fire up the simulation from
inside DDD).
How the Hell did you twist my words to say that?
DDD's /only/ action is to call a simulator. Since DDD isn't itself a
simulator, there is nothing to simulate except a call to a
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains
control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will never be
reached. In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
Yes and then I moved on the next tiny incremental
step of my proof. Correctly simulated less than
an infinite number of instructions does not help
the simulated DDD to reach its "return statement"
final halt state.
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so.
Right this takes a glimmering of understanding of
the x86 language. The x86 language it needed to
get an exactly precise understanding of the control
flow of DDD as directed graph state transition
diagram.
I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution.
I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates
DDD, then HHH correctly simulates DDD".
No much more than this you acknowledged that
when DDD is correctly simulated by HHH that
the simulated DDD cannot possibly reach its
own "return statement" (final halt state)
This is very important to computer science because
non-termination is entirely measured by the impossibility
of reaching a final halt state.
From all of the we know that when HHH(DDD) reports
on the behavior of its correct simulation of its input
that it can correctly reject this input as not
specifying a sequence of configurations that halts.
(My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.) I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.
Can we proceed to the next tiny increment of scope?
When one or more statements of DDD are correctly
simulated by HHH the correctly simulated DDD still
cannot possibly reach its own "return" statement.
This is trivial. When an infinite number of steps
of correct simulation are not enough we can conclude
that less than an infinite number of steps is also
insufficient.
That was the tiny increment of scope. Now I
show why that was important.
It is a fact that when HHH rejects its input
DDD as specifying a non-halting sequence of
configurations on the basis of the behavior
of DDD correctly simulated by HHH, that HHH
is necessary correct.
If you pay 100% complete attention and make
sure to totally ignore mere rhetoric as any
possible correct rebuttal you will find that
every "rebuttal" either commits the strawman
error changing my words and then rebutting the
changed words or simply dodges by attempting
to change the subject.
There has been no actual rebuttal of these
exact words:
It is a fact that when HHH rejects its input
DDD as specifying a non-halting sequence of
configurations on the basis of the behavior
of DDD correctly simulated by HHH, that HHH
is necessary correct.
They always either change the words or change
the subject.
On 5/9/2025 3:41 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 02:14 schreef olcott:
On 5/8/2025 7:00 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
[...]I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly >>>>>>>> wrong* leads me to think that he is largely ignorant of C (which is >>>>>>>> fine, most people are) and is unwilling to admit it. Watching the >>>>>>>> reactions of actual experts to his mathematical arguments leads me >>>>>>>> to the same conclusion about his knowledge of the relevant fields >>>>>>>> of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
So you normally compile your code using the 2017 version of
Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct >>>>>> a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
Microsoft's compiler did not report certain errors that any
conforming C
compiler is required by the standard to report.
Microsoft's compiler *can* be invoked in a way that causes it to
diagnose such errors, though it may or may not become fully conforming. >>>> I haven't used it lately, but a web search should tell you how to do
that.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors >>>>>> would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted >>>>>> for decades. Can you understand why I might decide that analyzing >>>>>> your claims is not worth my time?
I learned C back when K & R was the standard.
So did I. I've kept up with the language as it has changed.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point.
Great. Then why do you keep posting code? Or is the above DDD()
function not included in "any of my code")?
For example when >>>>> the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
That's too vague for me to comment.
Do you know what a C language interpreter is?
I actually do this at the x86 machine code level
yet most people don't have a clue about that.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The above hypothetical HHH emulates the first four
instructions of DDD. This sequence repeats until a
OOM error.
Only in your dream, because HHH has code to abort and after that abort
the program halts without OOM error.
Every competent C programmer will understand that.
The above set of hypothetical HHH instances correctly
simulates 1 or more instructions of DDD including
its call to HHH(DDD). This does include HHH emulating
itself emulating DDD.
If you think it is impossible for HHH to emulate itself
emulating DDD then you don't have a clue about cooperative
multi-tasking and differing process contexts.
On 5/9/2025 3:33 AM, Fred. Zwarts wrote:
Op 08.mei.2025 om 21:42 schreef olcott:
On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
Op 08.mei.2025 om 19:00 schreef olcott:
On 5/8/2025 11:14 AM, Mike Terry wrote:And since H does not correctly determine that its simulated D would
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works. >>>>>> That's to be expected, and PO's response ought to be to explain it >>>>>> so that you understand. Instead he goes off on one of his rants, >>>>>> so blamewise it's really down to PO.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to >>>>>>>>> stop at HHH's first departure from the rules of the C
programming language (or at least the first departure I spot). >>>>>>>>>
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well,
but you make essentially the same mistake --- writing to memory
that your program doesn't own --- no fewer than four times in a
single function.
I'll ignore the syntax error (a null statement at file scope is >>>>>>>>> a rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null >>>>>>>>> pointer constant... which is fine as long as you don't try to >>>>>>>>> deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax >>>>>>>>> errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you / >>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for >>>>>>>>> pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to >>>>>>> dereference a null pointer, you have no business trying to teach >>>>>>> anyone anything about C.
Your code is the work of a programmer so hideously incompetent
that 'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about
denigrating other people's C knowledge is the height of arrogant >>>>>>> hypocrisy.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative
calls that halt7.c code can make, such as Allocate(), used to
allocate a block of memory for use in halt7.c. Within halt7.c
code calls an Allocate() function, and x86utm intercepts that and
performs the function internally, then jumps the calling code in
halt7.c over the Allocate call where it continues as normal. The >>>>>> call never goes to the implementation of Allocate in halt7.c, so
the null pointer dereferencing does not actually occur. There are >>>>>> a whole bunch of similar x86utm primitive operations that work in
the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> *until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
never stop running unless aborted, it is a vacuous statement and
Sipser's agreement does not tell anything.
That is counter factual as any fully qualified
C programmer will tell you.
All fully qualified C programmers told me that it is not counter-
factual. But I suppose in your language counter-factual means 'not in
my dreams'.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by any HHH cannot
possibly reach its own simulated "return"
instruction.
Another vacuous statement, as HHH cannot correctly simulate DDD which
includes HHH itself.
It is stipulated that HHH does simulate itself
simulating DDD. It is also conclusively proven in
code that you cannot understand.
On 5/9/2025 3:47 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 04:23 schreef Keith Thompson:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that
implies that HHH does not correctly simulate DDD. Richard, you've read >>> far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
What you are missing is that the next step of olcott is to say that
when he uses the 'exact same HHH, with only some extra code to abort
the simulation', it is still an infinite recursion. He does not
understand that adding the abort code makes the behaviour
fundamentally different.
When 1 or more statements of DDD are correctly simulated
by HHH this correctly simulated DDD cannot possibly reach
its own "return statement" final halt state.
On 5/8/2025 11:22 PM, Keith Thompson wrote:
Richard Damon <news.x.richarddamon@xoxy.net> writes:
On 5/8/25 10:23 PM, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the abovevoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
that
implies that HHH does not correctly simulate DDD. Richard, you've read >>>> far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code
is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
You are missing the equivocation he is using on what is "DDD()"
First, he tries to define it as just the code of the function, and not
including any of the code that it calls. He does this so all the
various HHH that he talks about are given the "same" input.
Then he tries to also say that when those functions look at DDD, they
can follow the memory chain to the functions that it calls, that
weren't actually part of the input.
This means the "behavior" of his input isn't actually defined by the
input.
I haven't seen any of that in the posts to which I've recently replied
(and I absolutely do not have the patience to read everything he's
posted here).
What I've seen in the articles to which I've recently replied has been
just a strangely little C function and some claims about simulation.
Viewed in isolation, I don't think any of that (again, ignoring the vast
majority of what he's posted in this newsgroup) seems contradictory so
far.
When viewed in isolation (as intended) there is no basis
for rebuttal. Richard refers to extraneous irrelevant
points in an attempt to deflect the conversation away
from the simple truth:
void DDD()
{
HHH(DDD);
return;
}
"..DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction."
On 5/9/2025 4:25 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 01:48 schreef olcott:
On 5/8/2025 6:35 PM, Richard Damon wrote:Indeed, therefore HHH should process the actual input: including the
On 5/8/25 1:00 PM, olcott wrote:
On 5/8/2025 11:14 AM, Mike Terry wrote:
On 08/05/2025 06:33, Richard Heathfield wrote:
On 08/05/2025 06:22, olcott wrote:One problem here is that you don't understand how PO's code works. >>>>>> That's to be expected, and PO's response ought to be to explain it >>>>>> so that you understand. Instead he goes off on one of his rants, >>>>>> so blamewise it's really down to PO.
On 5/7/2025 11:09 PM, Richard Heathfield wrote:
On 08/05/2025 02:20, olcott wrote:
<snip>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
Let's take a look.
The file is 1373 lines long, but don't worry, because I plan to >>>>>>>>> stop at HHH's first departure from the rules of the C
programming language (or at least the first departure I spot). >>>>>>>>>
Turn in your songbook if you will to:
void CopyMachineCode(u8* source, u8** destination)
{
u32 size;
for (size = 0; source[size] != 0xcc; size++)
;
*destination = (u8*) Allocate(size);
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
((u32*)*destination)[-1] = size;
Output("CopyMachineCode destination[-1]: ",
((u32*)*destination) [-1]);
Output("CopyMachineCode destination[-2]: ",
((u32*)*destination) [-2]);
};
deprecated.
It's not just deprecated. It's hopelessly broken.
Everybody makes mistakes, and one slip would be all very well,
but you make essentially the same mistake --- writing to memory
that your program doesn't own --- no fewer than four times in a
single function.
I'll ignore the syntax error (a null statement at file scope is >>>>>>>>> a rookie error).
Instead, let's jump straight to this line:
*destination = (u8*) Allocate(size);
On line 79 of my copy of the code, we find:
u32* Allocate(u32 size) { return 0; }
In C, 0 is a null pointer constant, so Allocate returns a null >>>>>>>>> pointer constant... which is fine as long as you don't try to >>>>>>>>> deref it. So now *destination is NULL.
We go on:
for (u32 N = 0; N < size; N++)
{
Output("source[N]: ", source[N]);
*destination[N] = source[N];
}
*destination[N] is our first big problem (we're ignoring syntax >>>>>>>>> errors, remember). destination is a null pointer, so
destination[N] derefs a null pointer.
That's a fail. 0/10, D-, go away and write it again. And you / >>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for >>>>>>>>> pity's sake.
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.
If you can't even understand why it's a stupendously bad idea to >>>>>>> dereference a null pointer, you have no business trying to teach >>>>>>> anyone anything about C.
Your code is the work of a programmer so hideously incompetent
that 'programmer' is scarcely a fair word to use.
When you publish code like that, to even *think* about
denigrating other people's C knowledge is the height of arrogant >>>>>>> hypocrisy.
PO's halt7.c is compiled (it is not linked), then the obj file is
fed as input to his x87utm.exe which is a kind of x86 obj code
execution environment. x87utm provides a number of primative
calls that halt7.c code can make, such as Allocate(), used to
allocate a block of memory for use in halt7.c. Within halt7.c
code calls an Allocate() function, and x86utm intercepts that and
performs the function internally, then jumps the calling code in
halt7.c over the Allocate call where it continues as normal. The >>>>>> call never goes to the implementation of Allocate in halt7.c, so
the null pointer dereferencing does not actually occur. There are >>>>>> a whole bunch of similar x86utm primitive operations that work in
the same way.
PO should have said all that, not me, but it seems he's not
interested in genuine communication.
Mike.
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language
Excpet, as you have admitted, your DD isn't a program (just a C
funciton), and thus not a proper input for a halt decider, which by
definiton must be a program.
Your C function can't be a program, as you have specifically said
that the function, and only the funciton is the input, and programs
must include in them all their code, so since the code of HHH isn't
included in DD or the input representing it, it isn't a program, and
thus not a proper input
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> *until H correctly determines that*
*its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
But that statement implies, as required that H be a halt decider and
D to be a proper input to one, neither of which are satisfied, as
you have admitte
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
But it doesn't, as it doesn't correctly follow the behavior of the
x86 language, as that requires HHH to follow the call instruction,
which it can not do as the required (and accepted by your) condition
that the decider is a pure function, which means it can only look at
its input, which does not include the code which the call points to.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
Right, and a halt decider is required to (try to) compute the
mapping from the input (which needs to be the representation of a
program) to the results of running that program (since that is the
DEFINITION of Halt Deciding).
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Right, just as HHH trying to claim that its answer is based on the
fact that it can't reach the end of its simulation of the input
isn't the correct requirement for HHH.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
Right, which is Halting, since that behavior is DEFINED to be the
behavior of running the program the input represents.
Just like requiring sum(3,2) to report on the sum of 5 + 7
a value other than its input specifies HHH IS NOT ALLOWED
to report on anything other than the behavior that its input
specifies.
HHH that aborts, not the hypothetical HHH that does not abort.
HHH cannot say to itself I have no need to abort
because I will abort later on. It either aborts
as soon as it recognizes the non terminating
pattern specified by itself input or no HHH ever aborts.
Sum(3,2) should process the actual input, not the hypothetical input 5
and 7.
HHH should process all relevant input, including the part with the
conditional abort, not only the first part of the input.
Sum(3,2) should process all relevant input, not only the 2 and ignore
the 3.
So, go and fix HHH.
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state).
On 5/10/2025 12:27 AM, wij wrote:
On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
On 5/10/2025 12:13 AM, wij wrote:
On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
When mathematical mapping is properly understood
it will be known that functions computed by models
of computation must transform their input into
outputs according to the specific steps of an
algorithm.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For example HHH(DDD) only correctly map to the
behavior that its input actually specifies by correctly
emulating DDD according to the rules of the x86 language.
This causes the first four instructions of DDD
to be emulated followed by HHH emulating itself
emulating the first three instructions of DDD.
It is right at this recursive simulation just
before HHH(DDD) is called again that HHH recognizes
the repeating pattern and rejects DDD.
Yes, but you still did not answer the question: Is POOH exactly
about HP?
>>>>> H(D)=1 if D() halt.
>>>>> H(D)=0 if D() not halt.
Right now it is mostly about proving the
above requirements are is mistaken.
Why is the requirement invalid?
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
The notion that the behavior specified by the finite
string input to a simulating termination analyzer
does sometimes differ from the behavior of its direct
execution. It is a provably different sequence of steps.
On 5/9/2025 10:13 PM, wij wrote:And the input specifies a program that aborts and halts, but HHH ignores
On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively >>>>>>> what you're trying to do when you fire up the simulation from
inside DDD).
How the Hell did you twist my words to say that?
DDD's /only/ action is to call a simulator. Since DDD isn't itself a >>>>> simulator, there is nothing to simulate except a call to a
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains
control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will never be >>>>> reached. In practice, the program will likely crash due to a stack >>>>> overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the >>>>> unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so. I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution. I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates
DDD, then HHH correctly simulates DDD". (My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.) I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.
Don't know why you people stick on the 'simulation' stuff so long.
The HP simply asks for such an H (in function form. POOH does not
resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
My invention of a simulating termination
analyzer shows exactly how to compute the
mapping that the input that HHH(DD) specifies
into a correct answer for the halting problem's
otherwise impossible input.
On 5/9/2025 9:40 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively
what you're trying to do when you fire up the simulation from
inside DDD).
How the Hell did you twist my words to say that?
DDD's /only/ action is to call a simulator. Since DDD isn't itself a
simulator, there is nothing to simulate except a call to a
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains
control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will never be
reached. In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
Yes and then I moved on the next tiny incremental> step of my proof. Correctly simulated less than
an infinite number of instructions does not help
the simulated DDD to reach its "return statement"
final halt state.
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so.
Right this takes a glimmering of understanding of
the x86 language. The x86 language it needed to
get an exactly precise understanding of the control
flow of DDD as directed graph state transition
diagram.
I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution.
I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates
DDD, then HHH correctly simulates DDD".
No much more than this you acknowledged that
when DDD is correctly simulated by HHH that
the simulated DDD cannot possibly reach its
own "return statement" (final halt state)
This is very important to computer science because
non-termination is entirely measured by the impossibility
of reaching a final halt state.
From all of the we know that when HHH(DDD) reports
on the behavior of its correct simulation of its input
that it can correctly reject this input as not
specifying a sequence of configurations that halts.
On 5/9/2025 10:53 PM, Richard Damon wrote:
On 5/9/25 11:24 PM, olcott wrote:
On 5/9/2025 10:13 PM, wij wrote:
On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that >>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a >>>>>>> simulator, there is nothing to simulate except a call to a
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively >>>>>>>>> what you're trying to do when you fire up the simulation from >>>>>>>>> inside DDD).
How the Hell did you twist my words to say that?
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains >>>>>>> control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it >>>>>>> does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will
never be
reached. In practice, the program will likely crash due to a stack >>>>>>> overflow, unless the compiler implements tail-call optimization, in >>>>>>> which case the program might just run forever -- which also means >>>>>>> the
unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so. I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution. I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates >>>>> DDD, then HHH correctly simulates DDD". (My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.) I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.
Don't know why you people stick on the 'simulation' stuff so long.
The HP simply asks for such an H (in function form. POOH does not
resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
My invention of a simulating termination
analyzer shows exactly how to compute the
mapping that the input that HHH(DD) specifies
into a correct answer for the halting problem's
otherwise impossible input.
All rebuttals are based on failing to compute
this mapping correctly.
The problem is you don't compute the correct mapping, as you LIE by
changing the defined mapping with your strawman,
Termination Analyzer, BY THEIR DEFINITION, determine if the program
represented by their input will halt when run. PERIOD.
When definitions contradict each other at
least one of them is wrong.
HHH(DDD) computes the mapping from its input finite
string according to the rules of the x86 language
thus obtains the actual behavior THAT THIS INPUT STRING SPECIFIES.
On 5/9/2025 10:31 PM, Richard Damon wrote:
On 5/9/25 11:13 PM, wij wrote:
On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively >>>>>>>> what you're trying to do when you fire up the simulation from
inside DDD).
How the Hell did you twist my words to say that?
DDD's /only/ action is to call a simulator. Since DDD isn't itself a >>>>>> simulator, there is nothing to simulate except a call to a
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains >>>>>> control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will never be >>>>>> reached. In practice, the program will likely crash due to a stack >>>>>> overflow, unless the compiler implements tail-call optimization, in >>>>>> which case the program might just run forever -- which also means the >>>>>> unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so. I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution. I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates
DDD, then HHH correctly simulates DDD". (My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.) I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.
Don't know why you people stick on the 'simulation' stuff so long.
The HP simply asks for such an H (in function form. POOH does not
resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
The issue is Peter thinks that by making H a "simulating Halt Decider"
or a "Simulating Termination Analyzer" it can change the definition,
by trying to put out a lying definition of Halting by lying about the
definition of correct simulation and what is the input.
It is a stupid idea that halt deciders must be either
infallible or wrong so I switched to termination analyzers.
A termination analyzer is correct if it can process a
single input that itself has no inputs.
A termination analyzer is correct if it can process a
single input that itself has no inputs.
On 5/9/2025 10:12 PM, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 09/05/2025 03:23, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the abovevoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
that
implies that HHH does not correctly simulate DDD. Richard, you've read >>>> far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code
is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
Depends on what you've picked up on.
Do you get that HHH's simulation is a /partial/ simulation? HHH is
free to simulate a few x86 instructions of DDD, and then simply
abandon the simulation and return. Since such a simulation is
obviously NOT equivalent to a direct call to DDD, and above you argue
that it is, I'd say you've missed that.
I have not read the vast majority of olcott's post here. For most
of the recent discussion I had with him, there was no mention of
partial simulation. olcott finally said something about simulating
just a few instructions, but at the same time he finally indicated
that understanding his arguments would require an understanding of
x86 machine and/or assembly language. That's when I bailed out.
A "correct simulation", as I understand the term, would require fully
simulate the execution of DDD. If DDD never halts, its simulation never
halts. olcott seems to think that he's found a way around this that's
relevant to the Halting Problem, but I withdrew before getting to that
point.
It only need be a correct simulation until HHH sees the
repeating pattern that would cause itself to never terminate.
The best selling author of theory of computation textbooks
agreed that I could quote his agreement with my 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/9/2025 7:23 PM, Mike Terry wrote:It will certainly help. Not in making a better simulator, but by
On 09/05/2025 03:23, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that
implies that HHH does not correctly simulate DDD. Richard, you've read >>> far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
Depends on what you've picked up on.
Do you get that HHH's simulation is a /partial/ simulation? HHH is free
That was not in the specification that he responded to.
Thus within this specification DDD correctly simulated
by HHH cannot possibly reach its final halt state in an
infinite number of steps.
If an infinite number steps steps is insufficient
then how can less an infinite steps possibly help?
On 5/9/2025 10:29 PM, Richard Damon wrote:But since D is aborted, this is a vacuous statement.
On 5/9/25 11:17 PM, olcott wrote:
On 5/9/2025 10:12 PM, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 09/05/2025 03:23, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the above >>>>>> thatvoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
implies that HHH does not correctly simulate DDD. Richard, you've >>>>>> read
far more of olcott's posts than I have, so perhaps you can clarify. >>>>>> If we assume that HHH correctly simulates DDD, then the above code >>>>>> is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD >>>>>> can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending >>>>>> loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to >>>>>> do with the halting problem as far as I can tell, though of course >>>>>> olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
Depends on what you've picked up on.
Do you get that HHH's simulation is a /partial/ simulation? HHH is >>>>> free to simulate a few x86 instructions of DDD, and then simply
abandon the simulation and return. Since such a simulation is
obviously NOT equivalent to a direct call to DDD, and above you argue >>>>> that it is, I'd say you've missed that.
I have not read the vast majority of olcott's post here. For most
of the recent discussion I had with him, there was no mention of
partial simulation. olcott finally said something about simulating
just a few instructions, but at the same time he finally indicated
that understanding his arguments would require an understanding of
x86 machine and/or assembly language. That's when I bailed out.
A "correct simulation", as I understand the term, would require fully
simulate the execution of DDD. If DDD never halts, its simulation
never
halts. olcott seems to think that he's found a way around this that's >>>> relevant to the Halting Problem, but I withdrew before getting to that >>>> point.
It only need be a correct simulation until HHH sees the
repeating pattern that would cause itself to never terminate.
Right, but that pattern needs to be based on the fact that HHH is a
program that can abort its simulation, and in fact WILL.
The best selling author of theory of computation textbooks
agreed that I could quote his agreement with my 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>
*simulated D would never stop running unless aborted*
means determining what would happen if this H never aborted.
On 5/9/2025 4:00 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 02:05 schreef olcott:
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
If you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
No, what you need is someone who is an expert in mathematical logic
(I am not) who can explain to you, in terms you can understand and
accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
The HHH that you propose and is included in DDD does halt. But it is
known that this HHH prematurely aborts which makes it impossible for
the simulation to reach the reachable 'return'. HHH simply ignores the
conditional abort in the simulation.
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On 5/9/2025 4:03 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 03:35 schreef olcott:
On 5/8/2025 8:13 PM, Richard Damon wrote:
On 5/8/25 8:05 PM, olcott wrote:
On 5/8/2025 6:54 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:30 PM, Richard Heathfield wrote:[...]
On 08/05/2025 23:50, olcott wrote:
If you are a competent C programmerKeith Thompson is a highly-respected and very competent C
programmer.
*Then he is just who I need*
No, what you need is someone who is an expert in mathematical logic >>>>>> (I am not) who can explain to you, in terms you can understand and >>>>>> accept, where you've gone wrong. Some expertise in C could also
be helpful.
The key gap in my proof is that none of the comp.sci
people seems to have a slight clue about simple C
programming.
No, the problem is you don't.
void DDD()
{
HHH(DDD);
return;
}
*THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
And claiming the behavior of a program that isn;t the behavior of
that program is just a lie.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
No need to repeat vacuous statements. It does not matter how many
times you multiply 0, it will remains 0.
DDD contains an HHH that aborts,
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
Op 09.mei.2025 om 01:53 schreef olcott:
On 5/8/2025 6:45 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 5:26 PM, Keith Thompson wrote:[...]
I am more nearly an expert on C than on the Halting Problem.
Watching olcott base his arguments on C *and getting C so badly
wrong* leads me to think that he is largely ignorant of C (which is >>>>>> fine, most people are) and is unwilling to admit it. Watching the >>>>>> reactions of actual experts to his mathematical arguments leads me >>>>>> to the same conclusion about his knowledge of the relevant fields
of mathematics.
If Halt7.c is not compiled with the Microsoft
compiler then it will not produce the required
object file type.
The rest of the system has compiled under
Linux. I haven't tried this in a few years.
[...]
So you normally compile your code using the 2017 version of Microsoft
Visual Studio.
I have no particular problem with that, but your failure to correct
a number of C errors in your code is odd.
As I already proved Microsoft reported no such errors.
I've pointed out several
syntax errors and constraint violations; at least the syntax errors
would be trivial to fix (even if your compiler is lax enough to
fail to diagnose them). Richard Heathfield has pointed out code
that dereferences a null pointer.
Mike corrected Richard on this.
Those are stub functions intercepted
by x86utm the operating system.
You are using C, a language in which you appear to have little
apparent expertise or willingness to learn, to demonstrate claims
that, if true, would overturn ideas that have been generally accepted
for decades. Can you understand why I might decide that analyzing
your claims is not worth my time?
I learned C back when K & R was the standard.
void DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
A vacuous statement, because HHH cannot correctly simulate DDD, which
includes HHH itself.
A vacuous statement does not prove anything.
You are saying that the smartest genius (not me)
in the universe cannot possibly create an HHH
that simulates itself simulating DDD?
What is the evidence for this wild-eyed claim?
On 5/9/2025 10:12 PM, Richard Damon wrote:
On 5/9/25 10:47 PM, olcott wrote:
On 5/9/2025 9:39 PM, Richard Damon wrote:
On 5/9/25 10:20 PM, olcott wrote:
On 5/9/2025 9:15 PM, Richard Heathfield wrote:
On 10/05/2025 02:48, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail
accurately simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people
to accept incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
Assumes facts not in evidence. Your HHH function is in a
translation unit that contains a syntax error.
It is a truism that when DDD is emulated by HHH
according to the rules of the x86 language that
the first four instructions of DDD would be emulated
and then HHH would also be required to emulate
itself emulating DDD.
Nope, because by your definitions HHH can not correctly
emulate that DDD, as it doesn't include the code for the HHH
that it calls,
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
But that doesn't mean that HHH is allowed to access it.
Yes it does mean this.
Op 09.mei.2025 om 17:48 schreef olcott:
When 1 or more statements of DDD are correctly simulatedYou see? Exactly what I predicted. Now he uses another HHH that
by HHH this correctly simulated DDD cannot possibly reach
its own "return statement" final halt state.
does not correctly simulate the whole input, but only makes a
start. He will still hold his claim that there is an infinite
recursion and may quote a C expert, Keith Thompson, to support
his claim. The only way out is that Keith Thompson explicitly
explains that his example only holds for the simulator that does
not stop after 1 or more statements.
Op 10.mei.2025 om 05:13 schreef olcott:
On 5/9/2025 9:40 PM, Keith Thompson wrote:
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
Yes and then I moved on the next tiny incremental> step of my
proof. Correctly simulated less than
an infinite number of instructions does not help
the simulated DDD to reach its "return statement"
final halt state.
The word 'tiny' is misleading. It is a fundamental change. Now
HHH does no longer do a correct simulation, because it ignores
the input part of the input that specifies that HHH simulates
only a *finite* number of steps.
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately simulating >>>>>> the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to accept
incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The entire sequence of the first four instructions
of DDD is emulated correctly. This sequence also
includes HHH emulating itself emulating DDD. This
results in a whole other sequence of first three
instructions of DDD being correctly emulated.
On 5/9/2025 9:15 PM, Richard Heathfield wrote:
On 10/05/2025 02:48, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately
simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to accept
incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
Assumes facts not in evidence. Your HHH function is in a translation
unit that contains a syntax error.
It is a truism that when DDD is emulated by HHH
according to the rules of the x86 language that
the first four instructions of DDD would be emulated
and then HHH would also be required to emulate
itself emulating DDD.
On 5/9/2025 10:12 PM, Richard Damon wrote:
On 5/9/25 10:47 PM, olcott wrote:
On 5/9/2025 9:39 PM, Richard Damon wrote:
On 5/9/25 10:20 PM, olcott wrote:
On 5/9/2025 9:15 PM, Richard Heathfield wrote:
On 10/05/2025 02:48, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately >>>>>>>>>>>> simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to >>>>>>>>>> accept incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
Assumes facts not in evidence. Your HHH function is in a
translation unit that contains a syntax error.
It is a truism that when DDD is emulated by HHH
according to the rules of the x86 language that
the first four instructions of DDD would be emulated
and then HHH would also be required to emulate
itself emulating DDD.
Nope, because by your definitions HHH can not correctly emulate that
DDD, as it doesn't include the code for the HHH that it calls,
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
But that doesn't mean that HHH is allowed to access it.
Yes it does mean this.
On 5/9/2025 10:43 PM, wij wrote:
On Fri, 2025-05-09 at 22:24 -0500, olcott wrote:
On 5/9/2025 10:13 PM, wij wrote:
On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that >>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a >>>>>>> simulator, there is nothing to simulate except a call to a
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively >>>>>>>>> what you're trying to do when you fire up the simulation from >>>>>>>>> inside DDD).
How the Hell did you twist my words to say that?
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains >>>>>>> control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it >>>>>>> does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will
never be
reached. In practice, the program will likely crash due to a stack >>>>>>> overflow, unless the compiler implements tail-call optimization, in >>>>>>> which case the program might just run forever -- which also means >>>>>>> the
unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so. I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution. I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates >>>>> DDD, then HHH correctly simulates DDD". (My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.) I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.
Don't know why you people stick on the 'simulation' stuff so long.
The HP simply asks for such an H (in function form. POOH does not
resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
My invention of a simulating termination
analyzer shows exactly how to compute the
mapping that the input that HHH(DD) specifies
into a correct answer for the halting problem's
otherwise impossible input.
All rebuttals are based on failing to compute
this mapping correctly.
What is the correct mapping?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Computing the mapping of DDD emulated by HHH
according the the rules of the x86 language
to its behavior by HHH actually emulating DDD.
If POOH are not talking about the mapping:
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
The way that simulating termination analyzers process
their input by showing all of the steps of how the mapping
must be computed refutes the above simplistic view.
POOH is likely nothing to do with HP
On 5/9/2025 11:32 PM, wij wrote:
On Fri, 2025-05-09 at 23:18 -0500, olcott wrote:
On 5/9/2025 10:43 PM, wij wrote:
On Fri, 2025-05-09 at 22:24 -0500, olcott wrote:
On 5/9/2025 10:13 PM, wij wrote:
On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:Don't know why you people stick on the 'simulation' stuff so long. >>>>>> The HP simply asks for such an H (in function form. POOH does not
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that >>>>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively >>>>>>>>>>> what you're trying to do when you fire up the simulation from >>>>>>>>>>> inside DDD).
How the Hell did you twist my words to say that?
itself a
simulator, there is nothing to simulate except a call to a
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never
regains
control after the first recursion. To return, it must abort the >>>>>>>>> simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical >>>>>>>>> readership that HHH 'correctly simulated' DDD?
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it >>>>>>>>> does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will >>>>>>>>> never be
reached. In practice, the program will likely crash due to a >>>>>>>>> stack
overflow, unless the compiler implements tail-call
optimization, in
which case the program might just run forever -- which also
means the
unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given >>>>>>> that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would >>>>>>> accept that if I were ten feet tall I would bump my head against >>>>>>> the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it >>>>>>> would even be logically possible for it to do so. I also did not >>>>>>> address any issues of partial simulation, where olcott claims that >>>>>>> HHH can "accurately simulate" only a few x86 instructions rather >>>>>>> than simulating its entire execution. I did not participate in >>>>>>> any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine >>>>>>> and assembly code reasonably well if motivated to do so, but I am >>>>>>> not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates >>>>>>> DDD, then HHH correctly simulates DDD". (My understanding from >>>>>>> posts by others, whom I presume to be sufficiently knowledgeable, >>>>>>> is that HHH logically cannot accurately simulate DDD.) I would >>>>>>> prefer that olcott refrain from using my words to support any of >>>>>>> his arguments beyond the scope of what he and I directly discussed. >>>>>>
resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
My invention of a simulating termination
analyzer shows exactly how to compute the
mapping that the input that HHH(DD) specifies
into a correct answer for the halting problem's
otherwise impossible input.
All rebuttals are based on failing to compute
this mapping correctly.
What is the correct mapping?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Computing the mapping of DDD emulated by HHH
according the the rules of the x86 language
to its behavior by HHH actually emulating DDD.
The above says you have no idea what the mapping is.
If POOH are not talking about the mapping:
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
The way that simulating termination analyzers process
their input by showing all of the steps of how the mapping
must be computed refutes the above simplistic view.
No (real) problem with that. But the HP asks:
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
You still evade the question: Is POO H anything to do with the HP?
I have recently proven that the above requirements are incorrect.
That people consistently ignore this proof with pure bluster
is not actually any rebuttal at all.
POOH is likely nothing to do with HP
On 5/9/2025 10:53 PM, Richard Damon wrote:
On 5/9/25 11:24 PM, olcott wrote:
On 5/9/2025 10:13 PM, wij wrote:
On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that >>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a >>>>>>> simulator, there is nothing to simulate except a call to a
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively >>>>>>>>> what you're trying to do when you fire up the simulation from >>>>>>>>> inside DDD).
How the Hell did you twist my words to say that?
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains >>>>>>> control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it >>>>>>> does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will
never be
reached. In practice, the program will likely crash due to a stack >>>>>>> overflow, unless the compiler implements tail-call optimization, in >>>>>>> which case the program might just run forever -- which also means >>>>>>> the
unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so. I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution. I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates >>>>> DDD, then HHH correctly simulates DDD". (My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.) I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.
Don't know why you people stick on the 'simulation' stuff so long.
The HP simply asks for such an H (in function form. POOH does not
resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
My invention of a simulating termination
analyzer shows exactly how to compute the
mapping that the input that HHH(DD) specifies
into a correct answer for the halting problem's
otherwise impossible input.
All rebuttals are based on failing to compute
this mapping correctly.
The problem is you don't compute the correct mapping, as you LIE by
changing the defined mapping with your strawman,
Termination Analyzer, BY THEIR DEFINITION, determine if the program
represented by their input will halt when run. PERIOD.
When definitions contradict each other at
least one of them is wrong.
HHH(DDD) computes the mapping from its input finite
string according to the rules of the x86 language
thus obtains the actual behavior THAT THIS INPUT STRING SPECIFIES.
Until you can docuemnt a reliable source that gives your strawman, you
ar just proven to be a stupid liar that has proved his ignorance.
My reasoning itself is air tight. You usually only have weasel words.
On 5/9/2025 10:31 PM, Richard Damon wrote:
On 5/9/25 11:13 PM, wij wrote:
On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe that
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is effectively >>>>>>>> what you're trying to do when you fire up the simulation from
inside DDD).
How the Hell did you twist my words to say that?
DDD's /only/ action is to call a simulator. Since DDD isn't itself a >>>>>> simulator, there is nothing to simulate except a call to a
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains >>>>>> control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
void DDD()On what grounds can you persuade an extraordinarily sceptical
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will never be >>>>>> reached. In practice, the program will likely crash due to a stack >>>>>> overflow, unless the compiler implements tail-call optimization, in >>>>>> which case the program might just run forever -- which also means the >>>>>> unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make
a clarification.
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD. Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
I did not address whether the assumption is valid. I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so. I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution. I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code. (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
What I acknowledged was barely more than "if HHH correctly simulates
DDD, then HHH correctly simulates DDD". (My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.) I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.
Don't know why you people stick on the 'simulation' stuff so long.
The HP simply asks for such an H (in function form. POOH does not
resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
The issue is Peter thinks that by making H a "simulating Halt Decider"
or a "Simulating Termination Analyzer" it can change the definition,
by trying to put out a lying definition of Halting by lying about the
definition of correct simulation and what is the input.
It is a stupid idea that halt deciders must be either
infallible or wrong so I switched to termination analyzers.
A termination analyzer is correct if it can process a
single input that itself has no inputs.
On 5/9/2025 10:29 PM, Richard Damon wrote:
On 5/9/25 11:17 PM, olcott wrote:
On 5/9/2025 10:12 PM, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 09/05/2025 03:23, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the above >>>>>> thatvoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
implies that HHH does not correctly simulate DDD. Richard, you've >>>>>> read
far more of olcott's posts than I have, so perhaps you can clarify. >>>>>> If we assume that HHH correctly simulates DDD, then the above code >>>>>> is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD >>>>>> can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending >>>>>> loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to >>>>>> do with the halting problem as far as I can tell, though of course >>>>>> olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
Depends on what you've picked up on.
Do you get that HHH's simulation is a /partial/ simulation? HHH is >>>>> free to simulate a few x86 instructions of DDD, and then simply
abandon the simulation and return. Since such a simulation is
obviously NOT equivalent to a direct call to DDD, and above you argue >>>>> that it is, I'd say you've missed that.
I have not read the vast majority of olcott's post here. For most
of the recent discussion I had with him, there was no mention of
partial simulation. olcott finally said something about simulating
just a few instructions, but at the same time he finally indicated
that understanding his arguments would require an understanding of
x86 machine and/or assembly language. That's when I bailed out.
A "correct simulation", as I understand the term, would require fully
simulate the execution of DDD. If DDD never halts, its simulation
never
halts. olcott seems to think that he's found a way around this that's >>>> relevant to the Halting Problem, but I withdrew before getting to that >>>> point.
It only need be a correct simulation until HHH sees the
repeating pattern that would cause itself to never terminate.
Right, but that pattern needs to be based on the fact that HHH is a
program that can abort its simulation, and in fact WILL.
The best selling author of theory of computation textbooks
agreed that I could quote his agreement with my 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>
*simulated D would never stop running unless aborted*
means determining what would happen if this H never aborted.
On 5/9/2025 10:12 PM, Richard Damon wrote:
On 5/9/25 10:47 PM, olcott wrote:
On 5/9/2025 9:39 PM, Richard Damon wrote:
On 5/9/25 10:20 PM, olcott wrote:
On 5/9/2025 9:15 PM, Richard Heathfield wrote:
On 10/05/2025 02:48, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately >>>>>>>>>>>> simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to >>>>>>>>>> accept incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
Assumes facts not in evidence. Your HHH function is in a
translation unit that contains a syntax error.
It is a truism that when DDD is emulated by HHH
according to the rules of the x86 language that
the first four instructions of DDD would be emulated
and then HHH would also be required to emulate
itself emulating DDD.
Nope, because by your definitions HHH can not correctly emulate that
DDD, as it doesn't include the code for the HHH that it calls,
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
But that doesn't mean that HHH is allowed to access it.
Yes it does mean this.
On 5/9/2025 10:50 PM, Richard Damon wrote:
On 5/9/25 11:29 PM, olcott wrote:
On 5/9/2025 10:17 PM, Richard Damon wrote:
On 5/9/25 10:27 PM, olcott wrote:
On 5/9/2025 9:19 PM, Richard Heathfield wrote:
On 10/05/2025 02:50, olcott wrote:
On 5/9/2025 8:32 PM, Richard Heathfield wrote:<snip>
On 10/05/2025 02:29, olcott wrote:
On 5/9/2025 8:15 PM, Richard Heathfield wrote:
On 10/05/2025 01:51, olcott wrote:
On 5/9/2025 7:29 PM, Richard Heathfield wrote:
On 10/05/2025 00:02, olcott wrote:
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, it's not. Correct emulation would entail accurately >>>>>>>>>>>> simulating the whole of DDD's behaviour.
It is stupidly wrong to require the complete
emulation of a non-terminating input.
It is touchingly naive to think you can persuade people to >>>>>>>>>> accept incomplete emulation as 'correct'.
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.
Which instruction do you think is emulated correctly?
The entire sequence of the first four instructions
of DDD is emulated correctly.
Nope. Syntax errors don't count as correct.
Any HHH that emulates DDD according to the rules
of the x86 language must emulate the first four
instructions of DDD followed by HHH emulating
itself emulated DDD and then the first three
instructions of DDD when seven of the instructions
of DDD are correctly emulated.
This is axiomatic according to the rules of
the x86 language applied to the input to HHH(DDD).
Nope.
I have shown an HHH that just by the rules of the x86 language can
correctly emulate the code of DDD that references itself.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
You cannot possibly show any HHH that emulates this
DDD according to the rules of the x86 language such
that this DDD ever reaches its "ret" instruction
final halt state.
Sure I have. I guess you are just admitting you are a blantant liar.
int HHH(ptr P) {
static int flag = 0;
if (flag) return 0;
flag = 1;
/* Now put your existing code for a correct simulator that never
aborts */
Tell me why this simulator can't reach the final state of DDD when we
call HHH(DDD)
it will simulate the introduction to DDD, then go into HHH and see
that flag has been set to 1 by the initial call to HHH, and then
immediately return 0 to DDD which will then halt.
THis has been explained several time TODAY, and thus your denial is
just proof that you are just a stupid liar.
I guess you want to get the express ticket to that lake of fire.
That would work so I need to make my spec tighter.
On 5/9/2025 6:36 PM, Richard Damon wrote:
On 5/9/25 7:02 PM, olcott wrote:
On 5/8/2025 11:11 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 8:30 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:Does HHH correctly simulate DDD *and do nothing else*?
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.
I am a competent C programmer (and I don't believe you can make >>>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells >>>>>>>> me nothing about what it's supposed to do. Without knowing what >>>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?). >>>>>>>>
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.
Does HHH correctly simulate *every* function whose address is passed >>>>>> to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between >>>>>> calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
We need not know anything else about HHH toAssuming that HHH(DDD) "correctly simulates" DDD, and assuming it
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Exactly. None of these people on comp.theory could
get that even after three years.
I find that difficult to believe.
Then the return statement (which is unnecessary anyway) will never be >>>>>> reached.
It is only there to mark a final halt state.
The closing "}" does that equally well.
In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in >>>>>> which case the program might just run forever -- which also means the >>>>>> unnecessary return statement will never be reached.
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
I'll note that I've posted in comp.theory, not in comp.lang.c.
I never see anything you post in comp.lang.c.
This conclusion relies on my understanding of what you've said about >>>>>> your code, which I consider to be unreliable.
I am not even talking about my code. I am
talking about the purely hypothetical code
that you just agreed to.
Do not overestimate what I've agreed to. I must still consider the
possibility that I've been led into a logical trap of some sort,
and that I've missed some subtle flaw.
No doubt you believe that there is some significance to the
apparent fact that the return statement will never be reached,
assuming that's a correct and relevant conclusion. I don't know
what that significance might be.
I will tell you that later after you understand
some prerequisite ideas first.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
So now HHH returns an int result, and you store that result
in a variable named "Halt_Status". You haven't said here what
the meaning of that result might be, and I decline to make any
assumptions based on what you've called it. You could rename
"Halt_Status" to "Foo" and have effectively identical code.
Previously DDD would "correctly simulate" the function whose address is >>>> passed to it. Now it does that and returns an int result.
If you want to say anything about the meaning of the result returned
by HHH, feel free to say it.
The same thing that applied to DDD equally
applies to the more complicated DD.
When 1 or more instructions of DD are correctly
simulated by HHH the correctly simulated DD
cannot possibly get past its call to HHH(DD).
Thus DD also never reaches its "return" instruction.
Now you're talking about simulating "1 or more instructions"
of DD. I thought that HHH was supposed to "accurately simulate"
the function whose argument is passed to it. Emulating just "1 or
more instructions" is not accurate simulation.
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
No, Correctly Emulating *ALL* of the instructions is the definition of
correct emulation.
In other words it is waaayyy over your head that
when correctly emulating an infinite number of
instructions of DD is not enough for DD correctly
emulated by HHH to reach its own final halt
state that fewer than infinity might be enough?
On 5/10/2025 7:37 AM, Bonita Montero wrote:
Am 09.05.2025 um 04:22 schrieb olcott:
Look at their replies to this post.
Not a one of them will agree that
void DDD()
{
HHH(DDD);
return; // final halt state
}
When 1 or more instructions of DDD are correctly
simulated by HHH then the correctly simulated DDD cannot
possibly reach its "return" instruction (final halt state).
They have consistently disagreed with this
simple point for three years.
I guess that not even a professor of theoretical computer
science would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's
otherwise "impossible" input is actually non halting.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
On 5/10/2025 1:19 AM, wij wrote:
On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
On 5/10/2025 1:00 AM, wij wrote:
On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
On 5/10/2025 12:27 AM, wij wrote:
On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
On 5/10/2025 12:13 AM, wij wrote:
On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
When mathematical mapping is properly understood
it will be known that functions computed by models
of computation must transform their input into
outputs according to the specific steps of an
algorithm.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For example HHH(DDD) only correctly map to the
behavior that its input actually specifies by correctly
emulating DDD according to the rules of the x86 language.
This causes the first four instructions of DDD
to be emulated followed by HHH emulating itself
emulating the first three instructions of DDD.
It is right at this recursive simulation just
before HHH(DDD) is called again that HHH recognizes
the repeating pattern and rejects DDD.
Yes, but you still did not answer the question: Is POOH exactly >>>>>>>> about HP?
>>>>> H(D)=1 if D() halt.
>>>>> H(D)=0 if D() not halt.
Right now it is mostly about proving the
above requirements are is mistaken.
Why is the requirement invalid?
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
The notion that the behavior specified by the finite
string input to a simulating termination analyzer
POOH reads(takes) its input as a function, not 'finite string'.
Are you talking about POOH now? There is no POOH that takes
'finite string'.
It <is> a finite string of x86 bytes.
Disagree.
The D in Halt7.c (I just saw once) does not treat H as 'finite string',
D calls H. H also does not treat D as 'finite string'.
HHH and DDD and DD are the most recent functions.
HHH does emulate its finite strings of x86 machine code
according to the rules of the x86 language.
On 5/10/2025 10:14 AM, wij wrote:
On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
On 5/10/2025 1:19 AM, wij wrote:
On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
On 5/10/2025 1:00 AM, wij wrote:
On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
On 5/10/2025 12:27 AM, wij wrote:
On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
On 5/10/2025 12:13 AM, wij wrote:
On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
When mathematical mapping is properly understood
it will be known that functions computed by models
of computation must transform their input into
outputs according to the specific steps of an
algorithm.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For example HHH(DDD) only correctly map to the
behavior that its input actually specifies by correctly
emulating DDD according to the rules of the x86 language. >>>>>>>>>>>
This causes the first four instructions of DDD
to be emulated followed by HHH emulating itself
emulating the first three instructions of DDD.
It is right at this recursive simulation just
before HHH(DDD) is called again that HHH recognizes
the repeating pattern and rejects DDD.
Yes, but you still did not answer the question: Is POOH
exactly about HP?
>>>>> H(D)=1 if D() halt.
>>>>> H(D)=0 if D() not halt.
Right now it is mostly about proving the
above requirements are is mistaken.
Why is the requirement invalid?
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
The notion that the behavior specified by the finite
string input to a simulating termination analyzer
POOH reads(takes) its input as a function, not 'finite
string'.
Are you talking about POOH now? There is no POOH that takes
'finite string'.
It <is> a finite string of x86 bytes.
Disagree.
The D in Halt7.c (I just saw once) does not treat H as
'finite string',
D calls H. H also does not treat D as 'finite string'.
HHH and DDD and DD are the most recent functions.
HHH does emulate its finite strings of x86 machine code
according to the rules of the x86 language.
This is from a copy of Halt7.c:
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
H reads a *pointer*.
In P, P *calls* H.
Both do not process 'finite string'.
What it is it a pointer to a box of chocolates?
finite strings are passed as pointers to finite
string in C.
On 5/10/2025 10:14 AM, wij wrote:
On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
On 5/10/2025 1:19 AM, wij wrote:
On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
On 5/10/2025 1:00 AM, wij wrote:
On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
On 5/10/2025 12:27 AM, wij wrote:
On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
On 5/10/2025 12:13 AM, wij wrote:
On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
When mathematical mapping is properly understood
it will be known that functions computed by models
of computation must transform their input into
outputs according to the specific steps of an
algorithm.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For example HHH(DDD) only correctly map to the
behavior that its input actually specifies by correctly
emulating DDD according to the rules of the x86 language. >>>>>>>>>>>
This causes the first four instructions of DDD
to be emulated followed by HHH emulating itself
emulating the first three instructions of DDD.
It is right at this recursive simulation just
before HHH(DDD) is called again that HHH recognizes
the repeating pattern and rejects DDD.
Yes, but you still did not answer the question: Is POOH
exactly about HP?
>>>>> H(D)=1 if D() halt.
>>>>> H(D)=0 if D() not halt.
Right now it is mostly about proving the
above requirements are is mistaken.
Why is the requirement invalid?
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
The notion that the behavior specified by the finite
string input to a simulating termination analyzer
POOH reads(takes) its input as a function, not 'finite string'.
Are you talking about POOH now? There is no POOH that takes
'finite string'.
It <is> a finite string of x86 bytes.
Disagree.
The D in Halt7.c (I just saw once) does not treat H as 'finite string', >>>> D calls H. H also does not treat D as 'finite string'.
HHH and DDD and DD are the most recent functions.
HHH does emulate its finite strings of x86 machine code
according to the rules of the x86 language.
This is from a copy of Halt7.c:
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
H reads a *pointer*.
In P, P *calls* H.
Both do not process 'finite string'.
What it is it a pointer to a box of chocolates?
finite strings are passed as pointers to finite
string in C.
does sometimes differ from the behavior of its direct
execution. It is a provably different sequence of steps.
This is a verified fact.
The pathological relationship that inputs can have
with their simulating termination analyzer changes
the behavior of these inputs relative to their direct
execution.
So, you redefined the halting problem should be about the behavior of D >>>> decided by POOH, not the 'direct' behavior of D?
Not at all. HHH(DDD) reports on the behavior that DDD
actually specifies. All my critics require HHH to report
on behavior that DDD does not actually specify.
The actual behavior that DDD specifies is measured
by HHH emulating DDD according to the rules of the
x86 language. My critics insist on ignoring these
rules because it does not derive the behavior that
they expect.
From this reply and others before. Can we conclude that POOH is
about the pathological relationship inputs to the halting decider H.
IOW, POOH computes the function: POOH(D)=1 iff D is pathological.
POOH is not about the 'incorrect' problem HP: POOH(D)=1 iff D() halt?
Once we have the extra detail about how models
of computation computing functions must compute
the mapping from their actual inputs to the
behaviors that these inputs actually specify
then we can see that I corrected a mistake in
the theory of computation.
On 5/10/2025 11:00 AM, wij wrote:
On Sat, 2025-05-10 at 10:43 -0500, olcott wrote:
On 5/10/2025 10:14 AM, wij wrote:
H reads a *pointer*.
In P, P *calls* H.
Both do not process 'finite string'.
What it is it a pointer to a box of chocolates?
finite strings are passed as pointers to finite
string in C.
Nope. I don't believe it is a pointer to chocolates, even if
you say so.
It is about the code of D/H itself. They do not process string,
the fact says
the author of the program does not intend to process 'string'.
The input to HHH(DDD) is a pointer to a finite string
of machine code.
HHH applies an x86 emulator to this
finite string.
On 5/10/2025 7:37 AM, Bonita Montero wrote:
I guess that not even a professor of theoretical computer
science would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's
otherwise "impossible" input is actually non halting.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
On 5/9/2025 11:51 PM, wij wrote:
On Fri, 2025-05-09 at 23:44 -0500, olcott wrote:
On 5/9/2025 11:32 PM, wij wrote:it that correct?
On Fri, 2025-05-09 at 23:18 -0500, olcott wrote:
On 5/9/2025 10:43 PM, wij wrote:
On Fri, 2025-05-09 at 22:24 -0500, olcott wrote:
On 5/9/2025 10:13 PM, wij wrote:
On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 5/9/2025 4:40 PM, Richard Heathfield wrote:
On 09/05/2025 21:15, olcott wrote:
On 5/9/2025 3:07 PM, Richard Heathfield wrote:I haven't touched your words. What I have done is to observe >>>>>>>>>>> that
On 09/05/2025 20:46, olcott wrote:
We have not begun to get into any of those points. >>>>>>>>>>>>>> We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.
DDD can't be correctly simulated by itself (which is >>>>>>>>>>>>> effectively
what you're trying to do when you fire up the simulation from >>>>>>>>>>>>> inside DDD).
How the Hell did you twist my words to say that?
DDD's /only/ action is to call a simulator. Since DDD isn't >>>>>>>>>>> itself a
simulator, there is nothing to simulate except a call to a >>>>>>>>>>> simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never >>>>>>>>>>> regains
control after the first recursion. To return, it must abort the >>>>>>>>>>> simulation, which means the simulation fails.
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”. >>>>>>>>>>> On what grounds can you persuade an extraordinarily sceptical >>>>>>>>>>> readership that HHH 'correctly simulated' DDD?
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
On 5/8/2025 8:30 PM, Keith Thompson wrote:
Assuming that HHH(DDD) "correctly simulates" DDD, and
assuming it
does nothing else, your code would be equivalent to this: >>>>>>>>>>>
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will >>>>>>>>>>> never be
reached. In practice, the program will likely crash due to a >>>>>>>>>>> stack
overflow, unless the compiler implements tail-call
optimization, in
which case the program might just run forever -- which also >>>>>>>>>>> means the
unnecessary return statement will never be reached.
I had not intended to post again, but I feel the need to make >>>>>>>>> a clarification.
I acknowledged that the return statement would never be reached >>>>>>>>> *given the assumption* that HHH correctly simulates DDD. Given >>>>>>>>> that assumption, a call to DDD() should be equivalent to a call >>>>>>>>> to HHH(DDD).
I did not address whether the assumption is valid. I merely >>>>>>>>> temporarily accepted it for the sake of discussion, just as I >>>>>>>>> would
accept that if I were ten feet tall I would bump my head against >>>>>>>>> the ceiling in my house.
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it >>>>>>>>> would even be logically possible for it to do so. I also did not >>>>>>>>> address any issues of partial simulation, where olcott claims that >>>>>>>>> HHH can "accurately simulate" only a few x86 instructions rather >>>>>>>>> than simulating its entire execution. I did not participate in >>>>>>>>> any discussion that would require knowledge of x86 machine or >>>>>>>>> assembly code. (I have no doubt that I could learn x86 machine >>>>>>>>> and assembly code reasonably well if motivated to do so, but I am >>>>>>>>> not so motivated.)
What I acknowledged was barely more than "if HHH correctly
simulates
DDD, then HHH correctly simulates DDD". (My understanding from >>>>>>>>> posts by others, whom I presume to be sufficiently knowledgeable, >>>>>>>>> is that HHH logically cannot accurately simulate DDD.) I would >>>>>>>>> prefer that olcott refrain from using my words to support any of >>>>>>>>> his arguments beyond the scope of what he and I directly
discussed.
Don't know why you people stick on the 'simulation' stuff so long. >>>>>>>> The HP simply asks for such an H (in function form. POOH does not >>>>>>>> resemble TM):
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
My invention of a simulating termination
analyzer shows exactly how to compute the
mapping that the input that HHH(DD) specifies
into a correct answer for the halting problem's
otherwise impossible input.
All rebuttals are based on failing to compute
this mapping correctly.
What is the correct mapping?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Computing the mapping of DDD emulated by HHH
according the the rules of the x86 language
to its behavior by HHH actually emulating DDD.
The above says you have no idea what the mapping is.
If POOH are not talking about the mapping:
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
The way that simulating termination analyzers process
their input by showing all of the steps of how the mapping
must be computed refutes the above simplistic view.
No (real) problem with that. But the HP asks:
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
You still evade the question: Is POO H anything to do with the HP?
I have recently proven that the above requirements are incorrect.
Be it (HP) correct or not. Your 'revision' says POOH is not about the HP,
it that correct?
When mathematical mapping is properly understood
it will be known that functions computed by models
of computation must transform their input into
outputs according to the specific steps of an
algorithm.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For example HHH(DDD) only correctly map to the
behavior that its input actually specifies by correctly
emulating DDD according to the rules of the x86 language.
This causes the first four instructions of DDD
to be emulated followed by HHH emulating itself
emulating the first three instructions of DDD.
It is right at this recursive simulation just
before HHH(DDD) is called again that HHH recognizes
the repeating pattern and rejects DDD.
That people consistently ignore this proof with pure bluster
is not actually any rebuttal at all.
Other people's rebuttal of POOH may not be valid, if POOH is not about
the HP.
POOH is likely nothing to do with HP
On 5/10/2025 7:37 AM, Bonita Montero wrote:
Am 09.05.2025 um 04:22 schrieb olcott:
Look at their replies to this post.
Not a one of them will agree that
void DDD()
{
HHH(DDD);
return; // final halt state
}
When 1 or more instructions of DDD are correctly
simulated by HHH then the correctly simulated DDD cannot
possibly reach its "return" instruction (final halt state).
They have consistently disagreed with this
simple point for three years.
I guess that not even a professor of theoretical computer
science would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's
otherwise "impossible" input is actually non halting.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
On 5/9/2025 10:29 PM, Richard Damon wrote:
On 5/9/25 11:17 PM, olcott wrote:
On 5/9/2025 10:12 PM, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 09/05/2025 03:23, Keith Thompson wrote:
Richard Damon <richard@damon-family.org> writes:
On 5/8/25 7:53 PM, olcott wrote:[...]
Perhaps I've missed something. I don't see anything in the above >>>>>> thatvoid DDD()
{
HHH(DDD);
return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
implies that HHH does not correctly simulate DDD. Richard, you've >>>>>> read
far more of olcott's posts than I have, so perhaps you can clarify. >>>>>> If we assume that HHH correctly simulates DDD, then the above code >>>>>> is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD >>>>>> can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending >>>>>> loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to >>>>>> do with the halting problem as far as I can tell, though of course >>>>>> olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
Depends on what you've picked up on.
Do you get that HHH's simulation is a /partial/ simulation? HHH is >>>>> free to simulate a few x86 instructions of DDD, and then simply
abandon the simulation and return. Since such a simulation is
obviously NOT equivalent to a direct call to DDD, and above you argue >>>>> that it is, I'd say you've missed that.
I have not read the vast majority of olcott's post here. For most
of the recent discussion I had with him, there was no mention of
partial simulation. olcott finally said something about simulating
just a few instructions, but at the same time he finally indicated
that understanding his arguments would require an understanding of
x86 machine and/or assembly language. That's when I bailed out.
A "correct simulation", as I understand the term, would require fully
simulate the execution of DDD. If DDD never halts, its simulation
never
halts. olcott seems to think that he's found a way around this that's >>>> relevant to the Halting Problem, but I withdrew before getting to that >>>> point.
It only need be a correct simulation until HHH sees the
repeating pattern that would cause itself to never terminate.
Right, but that pattern needs to be based on the fact that HHH is a
program that can abort its simulation, and in fact WILL.
The best selling author of theory of computation textbooks
agreed that I could quote his agreement with my 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>
*simulated D would never stop running unless aborted*
means determining what would happen if this H never aborted.
On 5/10/2025 1:48 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer
science would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's
otherwise "impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in 1936 >> when he was just 24 years old.
Because I spent this much time I noticed key details
that no one else has ever bothered to notice before.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The Halting Problem's impossible input is correctly
determined to be non-halting when the measure of halting
is computing the mapping from the finite string input
to HHH(DD) on the basis of the behavior specified by
by DD emulated by HHH according to the rules of the x86
language.
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake: the category (type) error that I have described previously in this forum.
/Flibble
On 5/10/2025 1:37 PM, wij wrote:
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
On 5/10/2025 1:09 PM, wij wrote:
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
On 5/10/2025 12:01 PM, wij wrote:(otherwise, it will be an infinite recursive call which you agreed)
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
On 5/10/2025 11:29 AM, wij wrote:
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
On 5/10/2025 11:06 AM, wij wrote:
On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
On 5/10/2025 10:28 AM, wij wrote:
On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
Am 09.05.2025 um 04:22 schrieb olcott:
Look at their replies to this post.
Not a one of them will agree that
void DDD()
{
HHH(DDD);
return; // final halt state
}
When 1 or more instructions of DDD are correctly >>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot >>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt state). >>>>>>>>>>>>>>>
They have consistently disagreed with this
simple point for three years.
I guess that not even a professor of theoretical computer >>>>>>>>>>>>>> science would spend years working on so few lines of code. >>>>>>>>>>>>>>
I created a whole x86utm operating system.
It correctly determines that the halting problem's
otherwise "impossible" input is actually non halting. >>>>>>>>>>>>>
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
Nope.
From I know HHH(DD) decides whether the input DD is >>>>>>>>>>>> "impossible" input or
not.
DD has the standard form of the "impossible" input.
HHH merely rejects it as non-halting.
You said 'merely' rejects it as non-halting.
So, POOH do not answer the input of any other function?
The input that has baffled computer scientists for 90
years is merely correctly determined to be non-halting
when the behavior of this input is measured by HHH
emulating this input according to the rules of the x86
language.
The same thing applies to the Linz proof yet cannot
be understood until after HHH(DDD) and HHH(DD) are
fully understood.
HHH(DDD) (whatever) at most says DDD is a pathological/midtaken >>>>>>>> input.
Others of what you say are your imagine and wishes, so far so true. >>>>>>>>
DDD emulated by HHH accor not the 'HHH' that makes the final
decision
ding to the rules of
the x86 language specifies recursive emulation
that cannot possibly reach the final halt state
of DDD.
I have no problem with that. And, you said HHH merely rejects it
as non-halting.
You had denied HHH can decide the halting property of any input,
except DDD/DD/D..
As long as HHH correctly determines the halt status
of a single input that has no inputs then HHH is
a correct termination analyzer for that input.
Go it, that is a stronger statement that HHH ONLY decides DD.
I have no problem with that, but be noticed that the HHH inside DD
is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
will be an infinite recursive which cannot make any decision, which
you had agreed)
HHH(DD) correctly determines that its input specifies
recursive emulation when this input is emulated by HHH
HHH according to the rules of the x86 language.
From the about, so you are talking about 'the HHH' which does not
compute the final decision.
HHH does recognize the recursive emulation pattern
of DDD emulated by HHH according to the rules of
the x86 language.
*Thus exactly meets the following specification*
<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
This H won't be the same HHH inside the DD, otherwise an infinite
recursive call happens.
It must always be the outermost HHH that does this
because it has seen one entire recursive emulation
more than the next inner HHH.
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Professor Sipser is the best selling author of theory of
computation textbooks.
It is a pity that he could never take the five more minutes
required to understand the notion of recursive emulation and
thus see the significance of my work.
You can cite any one, I don't know who Sipsper is.
But yes, it is also a pity that Socrites and Turing did not know POOH.
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/ dp/113318779X
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake: the category (type) error that I have described previously in this forum.
/Flibble
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake:
the category (type) error that I have described previously in this
forum.
What arrogant self-important ignorance! Turing indeed solved the Entscheidungsproblem. His procedure has been verified by hundreds of thousands of mathematicians over the last century, and none of them have found flaws in it.
It is overwhelmingly likely that your lack of mathematical training has
led you to delude yourself about finding an error. The same applies to
Peter Olcott.
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake: the
category (type) error that I have described previously in this forum.
What arrogant self-important ignorance!
Turing indeed solved the
Entscheidungsproblem. His procedure has been verified by hundreds of thousands of mathematicians over the last century, and none of them have found flaws in it.
It is overwhelmingly likely that your lack of mathematical training has
led you to delude yourself about finding an error. The same applies to
Peter Olcott.
On 5/10/2025 3:07 PM, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake: the >>> category (type) error that I have described previously in this forum.
What arrogant self-important ignorance! Turing indeed solved the
Entscheidungsproblem. His procedure has been verified by hundreds of
thousands of mathematicians over the last century, and none of them have
found flaws in it.
It is overwhelmingly likely that your lack of mathematical training has
led you to delude yourself about finding an error. The same applies to
Peter Olcott.
/Flibble
Once we understand ....
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 5/10/2025 6:03 PM, olcott wrote:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:The H is the template that Professor Sipser agreed to.
On 5/10/2025 1:37 PM, wij wrote:
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:HHH does recognize the recursive emulation pattern of DDD emulated >>>>>> by HHH according to the rules of the x86 language.
On 5/10/2025 1:09 PM, wij wrote:
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:HHH(DD) correctly determines that its input specifies recursive >>>>>>>> emulation when this input is emulated by HHH HHH according to the >>>>>>>> rules of the x86 language.
On 5/10/2025 12:01 PM, wij wrote:(otherwise, it will be an infinite recursive call which you
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
On 5/10/2025 11:29 AM, wij wrote:
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:DDD emulated by HHH accor not the 'HHH' that makes the final >>>>>>>>>>>> decision
On 5/10/2025 11:06 AM, wij wrote:HHH(DDD) (whatever) at most says DDD is a pathological/ >>>>>>>>>>>>> midtaken input.
On Sat, 2025-05-10 at 10:45 -0500, olcott wrote: >>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:The input that has baffled computer scientists for 90 years >>>>>>>>>>>>>> is merely correctly determined to be non-halting when the >>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this >>>>>>>>>>>>>> input according to the rules of the x86 language.
You said 'merely' rejects it as non-halting.On Sat, 2025-05-10 at 09:33 -0500, olcott wrote: >>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:DD has the standard form of the "impossible" input. >>>>>>>>>>>>>>>> HHH merely rejects it as non-halting.
Nope.I created a whole x86utm operating system. >>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's >>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting. >>>>>>>>>>>>>>>>>>
Look at their replies to this post.
Not a one of them will agree that
void DDD()
{
HHH(DDD);
return; // final halt state >>>>>>>>>>>>>>>>>>>> }
When 1 or more instructions of DDD are correctly >>>>>>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD >>>>>>>>>>>>>>>>>>>> cannot possibly reach its "return" instruction (final >>>>>>>>>>>>>>>>>>>> halt state).
They have consistently disagreed with this simple >>>>>>>>>>>>>>>>>>>> point for three years.
I guess that not even a professor of theoretical >>>>>>>>>>>>>>>>>>> computer science would spend years working on so few >>>>>>>>>>>>>>>>>>> lines of code.
int DD()
{
int Halt_Status = HHH(DD); >>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
From I know HHH(DD) decides whether the >>>>>>>>>>>>>>>>> input DD
is "impossible"
input or not.
So, POOH do not answer the input of any other function? >>>>>>>>>>>>>>>
The same thing applies to the Linz proof yet cannot be >>>>>>>>>>>>>> understood until after HHH(DDD) and HHH(DD) are fully >>>>>>>>>>>>>> understood.
Others of what you say are your imagine and wishes, so far >>>>>>>>>>>>> so true.
agreed)
As long as HHH correctly determines the halt status of a single >>>>>>>>>> input that has no inputs then HHH is a correct termination >>>>>>>>>> analyzer for that input.ding to the rules of the x86 language specifies recursive >>>>>>>>>>>> emulation that cannot possibly reach the final halt state of >>>>>>>>>>>> DDD.I have no problem with that. And, you said HHH merely rejects >>>>>>>>>>> it as non-halting.
You had denied HHH can decide the halting property of any >>>>>>>>>>> input, except DDD/DD/D..
Go it, that is a stronger statement that HHH ONLY decides DD. >>>>>>>>> I have no problem with that, but be noticed that the HHH inside >>>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise, >>>>>>>>> the 'HHH'
will be an infinite recursive which cannot make any decision, >>>>>>>>> which you had agreed)
From the about, so you are talking about 'the HHH' which
does
not compute the final decision.
It must always be the outermost HHH that does this because it has*Thus exactly meets the following specification*
<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
This H won't be the same HHH inside the DD, otherwise an infinite >>>>>>> recursive call happens.
seen one entire recursive emulation more than the next inner HHH.
No problem. H is not HHH.
HHH is a specific implementation of H.
This is also a pitty no one here understand POOH can help AIIt is the same halting problem after its mistake has been corrected.
industry and mankind, even so mini.
So just like how ZFC corrected the error in set theory so that
Russell's Paradox could be correctly decided, HHH corrects the error
in the halting problem proof so that the otherwise impossible input
is correctly decided.
I don't know what that part of set theory works.
(My feeling is that they are garbage, for reasons,
unless you are doing logic researches)
The original set theory is now called naive set theory after its
mistake has been corrected. Thus the original halting problem proofs
can now be called the naive halting problem proofs.
Traditional logic (or the part mostly used) that won't cause confusion
is more reliable.
The halting problem itself remains the same, yet loses its most
important proof.
HP is based on TM. Proof of any other kind other than TM have to be
cautious.
Unless this is done as an actual simulating termination analyzer
That assumes one exists. Linz and others proved it doesn't, and you
have *explicitly* agreed with that.
On Sat, 10 May 2025 20:07:50 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake:
the category (type) error that I have described previously in this
forum.
What arrogant self-important ignorance! Turing indeed solved the
Entscheidungsproblem. His procedure has been verified by hundreds of
thousands of mathematicians over the last century, and none of them have
found flaws in it.
Not at all: I have simply found a flaw that has been overlooked all this time. Peter effectively found the same flaw but came at it from a
different angle.
It is overwhelmingly likely that your lack of mathematical training has
led you to delude yourself about finding an error. The same applies to
Peter Olcott.
Nope, I have formally defined the error that doesn't contradict Peter's
work.
/Flibble
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
On 5/10/2025 1:37 PM, wij wrote:
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
On 5/10/2025 1:09 PM, wij wrote:
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
On 5/10/2025 12:01 PM, wij wrote:(otherwise, it will be an infinite recursive call which you agreed) >>>>>>>>
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
On 5/10/2025 11:29 AM, wij wrote:
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
On 5/10/2025 11:06 AM, wij wrote:
On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
On 5/10/2025 10:28 AM, wij wrote:
On Sat, 2025-05-10 at 09:33 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
Look at their replies to this post.
Not a one of them will agree that
void DDD()
{
HHH(DDD);
return; // final halt state >>>>>>>>>>>>>>>>>>> }
When 1 or more instructions of DDD are correctly >>>>>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot >>>>>>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt >>>>>>>>>>>>>>>>>>> state).
They have consistently disagreed with this >>>>>>>>>>>>>>>>>>> simple point for three years.
I guess that not even a professor of theoretical computer >>>>>>>>>>>>>>>>>> science would spend years working on so few lines of >>>>>>>>>>>>>>>>>> code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's >>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting. >>>>>>>>>>>>>>>>>
int DD()
{
int Halt_Status = HHH(DD); >>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
Nope.
From I know HHH(DD) decides whether the input DD
is "impossible"
input
or
not.
DD has the standard form of the "impossible" input. >>>>>>>>>>>>>>> HHH merely rejects it as non-halting.
You said 'merely' rejects it as non-halting.
So, POOH do not answer the input of any other function? >>>>>>>>>>>>>>
The input that has baffled computer scientists for 90 >>>>>>>>>>>>> years is merely correctly determined to be non-halting >>>>>>>>>>>>> when the behavior of this input is measured by HHH
emulating this input according to the rules of the x86 >>>>>>>>>>>>> language.
The same thing applies to the Linz proof yet cannot
be understood until after HHH(DDD) and HHH(DD) are
fully understood.
HHH(DDD) (whatever) at most says DDD is a pathological/ >>>>>>>>>>>> midtaken input.
Others of what you say are your imagine and wishes, so far >>>>>>>>>>>> so true.
DDD emulated by HHH accor not the 'HHH' that makes the final >>>>>>>>>>> decision
ding to the rules of
the x86 language specifies recursive emulation
that cannot possibly reach the final halt state
of DDD.
I have no problem with that. And, you said HHH merely rejects >>>>>>>>>> it as non-halting.
You had denied HHH can decide the halting property of any
input, except DDD/DD/D..
As long as HHH correctly determines the halt status
of a single input that has no inputs then HHH is
a correct termination analyzer for that input.
Go it, that is a stronger statement that HHH ONLY decides DD.
I have no problem with that, but be noticed that the HHH inside DD >>>>>>>> is not the 'HHH' that makes the final decision (otherwise, the >>>>>>>> 'HHH'
will be an infinite recursive which cannot make any decision, which >>>>>>>> you had agreed)
HHH(DD) correctly determines that its input specifies
recursive emulation when this input is emulated by HHH
HHH according to the rules of the x86 language.
From the about, so you are talking about 'the HHH' which does >>>>>> not compute the final
decision.
HHH does recognize the recursive emulation pattern
of DDD emulated by HHH according to the rules of
the x86 language.
*Thus exactly meets the following specification*
<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
This H won't be the same HHH inside the DD, otherwise an infinite
recursive call happens.
It must always be the outermost HHH that does this
because it has seen one entire recursive emulation
more than the next inner HHH.
No problem. H is not HHH.
The H is the template that Professor Sipser agreed to.
HHH is a specific implementation of H.
This is also a pitty no one here understand POOH can help AI
industry and mankind, even so mini.
It is the same halting problem after its mistake
has been corrected. So just like how ZFC corrected
the error in set theory so that Russell's Paradox
could be correctly decided, HHH corrects the error
in the halting problem proof so that the otherwise
impossible input is correctly decided.
I don't know what that part of set theory works.
(My feeling is that they are garbage, for reasons,
unless you are doing logic researches)
The original set theory is now called naive set
theory after its mistake has been corrected. Thus
the original halting problem proofs can now be
called the naive halting problem proofs.
Traditional logic (or the part mostly used) that won't
cause confusion is more reliable.
The halting problem itself remains the same, yet
loses its most important proof.
HP is based on TM. Proof of any other kind other than TM have to be
cautious.
Unless this is done as an actual simulating termination
analyzer in a high level language like C and it operates
on a 100% complete exactingly precise input specification
such as the x86 language too many details slip through
the cracks of vagueness.
For example no one ever even noticed that it is 100%
impossible to derive an input that actually does the
opposite of whatever value that its termination
analyzer reports.
All of these proofs remain anchored in that false
assumption.
The part of 'logic' or 'philosophy' I saw from your posts are very
dubious,
hardly valid for HP.
I think you are referring to (and confused by) self-reference.
Sadly, the HP proof has nothing to do with self-reference.
Let me make the counter example this way:
void D() {
for(int X; X<LimX; ++X) { // X would enum all possible 'TM' whose >> value<LimX
if(simu(H',X) while(1); // H' decides whether X halts or not
} // (If X is not a valid program,
simu(H',X) returns 0.
// So, this H' is not exactly the
halting decider H
// but can be build from the original H)
}
So, there exists an encoding X that functions the same as D that H
cannot decide.
(note that no function call or self-reference in the above D)
The above D can be simplified to form another "impossible input":
void D2() {
if(simu(H',D2') while(1); // D2' is the 'source' of D2, also no
self ref. RECURSIVELY.
}
I have no idea what you are saying.
specifies a non-halting sequence of configurations. >>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
Professor Sipser is the best selling author of theory of
computation textbooks.
It is a pity that he could never take the five more minutes
required to understand the notion of recursive emulation and
thus see the significance of my work.
You can cite any one, I don't know who Sipsper is.
But yes, it is also a pity that Socrites and Turing did not know
POOH.
https://www.amazon.com/Introduction-Theory-Computation-Michael-
Sipser/dp/113318779X
On 5/10/2025 3:07 PM, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake: the >>> category (type) error that I have described previously in this forum.
What arrogant self-important ignorance! Turing indeed solved the
Entscheidungsproblem. His procedure has been verified by hundreds of
thousands of mathematicians over the last century, and none of them have
found flaws in it.
It is overwhelmingly likely that your lack of mathematical training has
led you to delude yourself about finding an error. The same applies to
Peter Olcott.
/Flibble
Once we understand that functions computed
by models of computation must apply the sequence
of steps of an algorithm to derive their output
from their input then we have one key element.
Then we also need to understand that termination
analyzers are required to compute the mapping from
this input to the behavior ACTUALLY SPECIFIED by
this input.
The last step is understanding is that computing
the mapping to the behavior specified by this
input finite string must be according to the
model's computation language.
This means that HHH is correct to reject its
input DD because DD emulated by HHH according
to the rules of the x86 language specifies
recursive emulation (non halting behavior).
*Likewise for the Linz Proof*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly
ever reach its own simulated final state ⟨Ĥ.qn⟩
On 5/10/2025 3:45 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 3:07 PM, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science >>>>>>>> would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan >>>>>> Turing's solution of the Entscheidungsproblem. He published this in >>>>>> 1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a
mistake: the
category (type) error that I have described previously in this forum.
What arrogant self-important ignorance! Turing indeed solved the
Entscheidungsproblem. His procedure has been verified by hundreds of >>>> thousands of mathematicians over the last century, and none of them
have
found flaws in it.
It is overwhelmingly likely that your lack of mathematical training has >>>> led you to delude yourself about finding an error. The same applies to >>>> Peter Olcott.
/Flibble
Once we understand ....
[ Irrelevant stuff deleted ]
That's the whole point. You _don't_ understand
I DO UNDERSTAND and your carefully memorized dogma
has no actual understanding to it. No one has been
able to point out an actual mistake in the essence
of my reasoning for a long time.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
THESE WORDS ARE A TRUSISM
When HHH(DDD) computes the mapping from its input DDD
to the behavior that this input specifies when DDD is
emulated by HHH according to the rules of the x86
language ...
Everyone either changes the subject or changes my
words in their rebuttal.
The key rebuttal is essentially:
"that is not the way that I memorized it".
On 5/10/2025 2:02 PM, wij wrote:
On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
On 5/10/2025 1:37 PM, wij wrote:
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
On 5/10/2025 1:09 PM, wij wrote:
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
On 5/10/2025 12:01 PM, wij wrote:(otherwise, it will be an infinite recursive call which you agreed) >>>>>>
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
On 5/10/2025 11:29 AM, wij wrote:
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
On 5/10/2025 11:06 AM, wij wrote:
On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
On 5/10/2025 10:28 AM, wij wrote:
On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
Am 09.05.2025 um 04:22 schrieb olcott:
Look at their replies to this post.
Not a one of them will agree that
void DDD()
{
HHH(DDD);
return; // final halt state >>>>>>>>>>>>>>>>> }
When 1 or more instructions of DDD are correctly >>>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot >>>>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt >>>>>>>>>>>>>>>>> state).
They have consistently disagreed with this
simple point for three years.
I guess that not even a professor of theoretical computer >>>>>>>>>>>>>>>> science would spend years working on so few lines of code. >>>>>>>>>>>>>>>>
I created a whole x86utm operating system.
It correctly determines that the halting problem's >>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting. >>>>>>>>>>>>>>>
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
https://github.com/plolcott/x86utm
Nope.
From I know HHH(DD) decides whether the input DD is
"impossible" input
or
not.
DD has the standard form of the "impossible" input.
HHH merely rejects it as non-halting.
You said 'merely' rejects it as non-halting.
So, POOH do not answer the input of any other function? >>>>>>>>>>>>
The input that has baffled computer scientists for 90
years is merely correctly determined to be non-halting
when the behavior of this input is measured by HHH
emulating this input according to the rules of the x86
language.
The same thing applies to the Linz proof yet cannot
be understood until after HHH(DDD) and HHH(DD) are
fully understood.
HHH(DDD) (whatever) at most says DDD is a pathological/
midtaken input.
Others of what you say are your imagine and wishes, so far so >>>>>>>>>> true.
DDD emulated by HHH accor not the 'HHH' that makes the final >>>>>>>>> decision
ding to the rules of
the x86 language specifies recursive emulation
that cannot possibly reach the final halt state
of DDD.
I have no problem with that. And, you said HHH merely rejects it >>>>>>>> as non-halting.
You had denied HHH can decide the halting property of any input, >>>>>>>> except DDD/DD/D..
As long as HHH correctly determines the halt status
of a single input that has no inputs then HHH is
a correct termination analyzer for that input.
Go it, that is a stronger statement that HHH ONLY decides DD.
I have no problem with that, but be noticed that the HHH inside DD >>>>>> is not the 'HHH' that makes the final decision (otherwise, the 'HHH' >>>>>> will be an infinite recursive which cannot make any decision, which >>>>>> you had agreed)
HHH(DD) correctly determines that its input specifies
recursive emulation when this input is emulated by HHH
HHH according to the rules of the x86 language.
From the about, so you are talking about 'the HHH' which does not
compute the final decision.
HHH does recognize the recursive emulation pattern
of DDD emulated by HHH according to the rules of
the x86 language.
*Thus exactly meets the following specification*This H won't be the same HHH inside the DD, otherwise an infinite
<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 >>>>
recursive call happens.
It must always be the outermost HHH that does this
because it has seen one entire recursive emulation
more than the next inner HHH.
No problem. H is not HHH.
The H is the template that Professor Sipser agreed to.
HHH is a specific implementation of H.
This is also a pitty no one here understand POOH can help AI industry
and mankind, even so mini.
It is the same halting problem after its mistake
has been corrected. So just like how ZFC corrected
the error in set theory so that Russell's Paradox
could be correctly decided, HHH corrects the error
in the halting problem proof so that the otherwise
impossible input is correctly decided.
The original set theory is now called naive set
theory after its mistake has been corrected. Thus
the original halting problem proofs can now be
called the naive halting problem proofs.
The halting problem itself remains the same, yet
loses its most important proof.
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
Professor Sipser is the best selling author of theory of
computation textbooks.
It is a pity that he could never take the five more minutes
required to understand the notion of recursive emulation and
thus see the significance of my work.
You can cite any one, I don't know who Sipsper is.
But yes, it is also a pity that Socrites and Turing did not know POOH. >>>>
https://www.amazon.com/Introduction-Theory-Computation-Michael-
Sipser/dp/113318779X
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake: the >>> category (type) error that I have described previously in this forum.
OK, then, give the page and line numbers from Turing's 1936 paper where
this alleged mistake was made. I would be surprised indeed if you'd even >> looked at Turing's paper, far less understood it. Yet you're ready to
denigrate his work.
Perhaps it is time for you to withdraw these uncalled for insinuations.
/Flibble
It is the whole gist of the entire idea of
the halting problem proof that is wrongheaded.
(1) It is anchored in the false assumption that an
input to a termination analyzer can actually
do this opposite of whatever value that this
analyzer returns. No one ever notices that this
"do the opposite" code is unreachable.
(2) It expects a self-contradictory (thus incorrect)
question to have a correct answer.
Can Carol correctly answer “no” to this (yes/no) question? https://www.cs.toronto.edu/~hehner/OSS.pdf
When the context of who is asked is understood
to be an aspect of the full meaning of the question
then the question posed to Carol is incorrect because
both yes and no are the wrong answer.
Credit to Richard Damon for finding the loophole
in the original question:
Can Carol correctly answer “no” to this question?
With the original version Carol can shake her head
to indicate "no" without actually saying "no".
On 5/10/2025 6:55 PM, Mr Flibble wrote:
On Sat, 10 May 2025 18:39:18 -0400, dbush wrote:There's no such thing as an ill-formed contradiction.
On 5/10/2025 6:03 PM, olcott wrote:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:The H is the template that Professor Sipser agreed to.
On 5/10/2025 1:37 PM, wij wrote:No problem. H is not HHH.
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:HHH does recognize the recursive emulation pattern of DDD
On 5/10/2025 1:09 PM, wij wrote:
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:HHH(DD) correctly determines that its input specifies recursive >>>>>>>>>> emulation when this input is emulated by HHH HHH according to >>>>>>>>>> the rules of the x86 language.
On 5/10/2025 12:01 PM, wij wrote:(otherwise, it will be an infinite recursive call which you >>>>>>>>>>> agreed)
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
On 5/10/2025 11:29 AM, wij wrote:
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote: >>>>>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:DDD emulated by HHH accor not the 'HHH' that makes the >>>>>>>>>>>>>> final decision
HHH(DDD) (whatever) at most says DDD is a pathological/ >>>>>>>>>>>>>>> midtaken input.On Sat, 2025-05-10 at 10:45 -0500, olcott wrote: >>>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:The input that has baffled computer scientists for 90 >>>>>>>>>>>>>>>> years is merely correctly determined to be non-halting >>>>>>>>>>>>>>>> when the behavior of this input is measured by HHH >>>>>>>>>>>>>>>> emulating this input according to the rules of the x86 >>>>>>>>>>>>>>>> language.
You said 'merely' rejects it as non-halting. >>>>>>>>>>>>>>>>> So, POOH do not answer the input of any other function? >>>>>>>>>>>>>>>>>On Sat, 2025-05-10 at 09:33 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>DD has the standard form of the "impossible" input. >>>>>>>>>>>>>>>>>> HHH merely rejects it as non-halting.
Nope.I created a whole x86utm operating system. >>>>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's >>>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting. >>>>>>>>>>>>>>>>>>>>Look at their replies to this post. >>>>>>>>>>>>>>>>>>>>>> Not a one of them will agree that
void DDD()
{
HHH(DDD);
return; // final halt state >>>>>>>>>>>>>>>>>>>>>> }
When 1 or more instructions of DDD are correctly >>>>>>>>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD >>>>>>>>>>>>>>>>>>>>>> cannot possibly reach its "return" instruction >>>>>>>>>>>>>>>>>>>>>> (final halt state).
They have consistently disagreed with this simple >>>>>>>>>>>>>>>>>>>>>> point for three years.
I guess that not even a professor of theoretical >>>>>>>>>>>>>>>>>>>>> computer science would spend years working on so few >>>>>>>>>>>>>>>>>>>>> lines of code.
int DD()
{
int Halt_Status = HHH(DD); >>>>>>>>>>>>>>>>>>>> if (Halt_Status) >>>>>>>>>>>>>>>>>>>> HERE: goto HERE; >>>>>>>>>>>>>>>>>>>> return Halt_Status; >>>>>>>>>>>>>>>>>>>> }
https://github.com/plolcott/x86utm
From I know HHH(DD) decides whether >>>>>>>>>>>>>>>>>>> the input DD
is "impossible"
input or not.
The same thing applies to the Linz proof yet cannot be >>>>>>>>>>>>>>>> understood until after HHH(DDD) and HHH(DD) are fully >>>>>>>>>>>>>>>> understood.
Others of what you say are your imagine and wishes, so far >>>>>>>>>>>>>>> so true.
As long as HHH correctly determines the halt status of a >>>>>>>>>>>> single input that has no inputs then HHH is a correctding to the rules of the x86 language specifies recursive >>>>>>>>>>>>>> emulation that cannot possibly reach the final halt state >>>>>>>>>>>>>> of DDD.I have no problem with that. And, you said HHH merely >>>>>>>>>>>>> rejects it as non-halting.
You had denied HHH can decide the halting property of any >>>>>>>>>>>>> input, except DDD/DD/D..
termination analyzer for that input.
Go it, that is a stronger statement that HHH ONLY decides DD. >>>>>>>>>>> I have no problem with that, but be noticed that the HHH >>>>>>>>>>> inside DD is not the 'HHH' that makes the final decision >>>>>>>>>>> (otherwise, the 'HHH'
will be an infinite recursive which cannot make any decision, >>>>>>>>>>> which you had agreed)
From the about, so you are talking about 'the HHH' which >>>>>>>>> does
not compute the final decision.
emulated by HHH according to the rules of the x86 language.
It must always be the outermost HHH that does this because it has >>>>>>>> seen one entire recursive emulation more than the next inner HHH. >>>>>>>*Thus exactly meets the following specification*
<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
This H won't be the same HHH inside the DD, otherwise an
infinite recursive call happens.
HHH is a specific implementation of H.
This is also a pitty no one here understand POOH can help AIIt is the same halting problem after its mistake has been
industry and mankind, even so mini.
corrected.
So just like how ZFC corrected the error in set theory so that
Russell's Paradox could be correctly decided, HHH corrects the
error in the halting problem proof so that the otherwise impossible >>>>>> input is correctly decided.
I don't know what that part of set theory works.
(My feeling is that they are garbage, for reasons,
unless you are doing logic researches)
The original set theory is now called naive set theory after its
mistake has been corrected. Thus the original halting problem
proofs can now be called the naive halting problem proofs.
Traditional logic (or the part mostly used) that won't cause
confusion is more reliable.
The halting problem itself remains the same, yet loses its most
important proof.
HP is based on TM. Proof of any other kind other than TM have to be
cautious.
Unless this is done as an actual simulating termination analyzer
That assumes one exists. Linz and others proved it doesn't, and you
have *explicitly* agreed with that.
Linz and others haven't proved jack shit: the contradiction at the
heart of the halting problem is a category (type) error, i.e.
ill-formed.
Once an assumption is made, *any* contradiction proves that assumption
false. It doesn't matter how outlandish the contradiction might seem.
On 5/10/2025 8:17 PM, wij wrote:
On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
You don't know the counter example in the HP proof, your D is
not the case what HP says.
Sure I do this is it! (as correctly encoded in C)
On 5/10/2025 8:17 PM, wij wrote:
On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
You don't know the counter example in the HP proof, your D is not the
case what HP says.
Sure I do this is it! (as correctly encoded in C)
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
On 5/10/2025 8:44 PM, wij wrote:
On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
On 5/10/2025 8:17 PM, wij wrote:
On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
You don't know the counter example in the HP proof, your D is not
the case what HP says.
Sure I do this is it! (as correctly encoded in C)
typedef void (*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);
}
Try to convert it to TM language to know you know nothing.
I spent 22 years on this. I started with the Linz text
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
cannot possibly reach its simulated final halt state
⟨Ĥ.qn⟩
To refute the HP, you need to understand what it exactly means in TM.
I have known this for 22 years.
Assembly (or C) also work, but you need to understand more details and
be able to map every assembly instruction or C expressions to TM
language.
The form of the DD above (in some books maybe) is for layman to
understand,
which is not exactly the case that the HP provides. Don't be silly.
On Sat, 10 May 2025 20:07:50 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake:
the category (type) error that I have described previously in this
forum.
What arrogant self-important ignorance! Turing indeed solved the
Entscheidungsproblem. His procedure has been verified by hundreds of
thousands of mathematicians over the last century, and none of them have
found flaws in it.
Not at all: I have simply found a flaw that has been overlooked all this time. Peter effectively found the same flaw but came at it from a
different angle.
It is overwhelmingly likely that your lack of mathematical training has
led you to delude yourself about finding an error. The same applies to
Peter Olcott.
Nope, I have formally defined the error that doesn't contradict Peter's
work.
/Flibble
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
On 5/10/2025 1:37 PM, wij wrote:
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
On 5/10/2025 1:09 PM, wij wrote:
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
On 5/10/2025 12:01 PM, wij wrote:
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
On 5/10/2025 11:29 AM, wij wrote:
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
On 5/10/2025 11:06 AM, wij wrote:
On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
On 5/10/2025 10:28 AM, wij wrote:
On Sat, 2025-05-10 at 09:33 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
It correctly determines that the halting problem's >>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
The input that has baffled computer scientists for 90 years >>>>>>>>>>>>> is merely correctly determined to be non-halting when the >>>>>>>>>>>>> behavior of this input is measured by HHH emulating this >>>>>>>>>>>>> input according to the rules of the x86 language.
I have no problem with that. And, you said HHH merely rejects >>>>>>>>>> it as non-halting. You had denied HHH can decide the halting >>>>>>>>>> property of any input, except DDD/DD/D..As long as HHH correctly determines the halt status of a single >>>>>>>>> input that has no inputs then HHH is a correct termination
analyzer for that input.
I have no problem with that, but be noticed that the HHH inside >>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise, the >>>>>>>> 'HHH'
will be an infinite recursive which cannot make any decision,
which you had agreed)
The original set theory is now called naive set theory after itsTraditional logic (or the part mostly used) that won't cause confusion
mistake has been corrected. Thus the original halting problem proofs
can now be called the naive halting problem proofs.
is more reliable.
Unless this is done as an actual simulating termination analyzer in aThe halting problem itself remains the same, yet loses its most
important proof.
HP is based on TM. Proof of any other kind other than TM have to be
cautious.
high level language like C and it operates on a 100% complete exactingly precise input specification such as the x86 language too many details
slip through the cracks of vagueness.
For example no one ever even noticed that it is 100% impossible toWrong, DDD calls HHH, which returns "non-halting", *and halts*.
derive an input that actually does the opposite of whatever value that
its termination analyzer reports.
On 5/10/2025 9:09 PM, wij wrote:
On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
On 5/10/2025 8:44 PM, wij wrote:
On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
On 5/10/2025 8:17 PM, wij wrote:
On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
You don't know the counter example in the HP proof, your D is not
the case what HP says.
Sure I do this is it! (as correctly encoded in C)
typedef void (*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);
}
Try to convert it to TM language to know you know nothing.
I spent 22 years on this. I started with the Linz text
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
cannot possibly reach its simulated final halt state
⟨Ĥ.qn⟩
To refute the HP, you need to understand what it exactly means in TM.
I have known this for 22 years.
A working TM. Build it explicitly from transition function, then explain
your derivation. You know nothing.
That would be like examining how an operating system
works entirely from its machine code.
We only have to actually know one detail:
Every counter-example input encoded in any model
of computation always specifies recursive simulation
that never halts to its corresponding simulating
termination analyzer.
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:The simulated DDD doesn't matter. HHH returns to DDD, and DDD then does
OK, then, give the page and line numbers from Turing's 1936 paper whereIt is the whole gist of the entire idea of the halting problem proof
this alleged mistake was made. I would be surprised indeed if you'd
even looked at Turing's paper, far less understood it. Yet you're
ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for insinuations.
that is wrongheaded.
(1) It is anchored in the false assumption that an input to a
termination analyzer can actually do this opposite of whatever value
that this analyzer returns. No one ever notices that this "do the
opposite" code is unreachable.
(2) It expects a self-contradictory (thus incorrect)Whether a program halts is not contradictory.
question to have a correct answer.
Can Carol correctly answer “no” to this (yes/no) question?Yes, HHH cannot answer correctly.
When the context of who is asked is understood to be an aspect of the
full meaning of the question then the question posed to Carol is
incorrect because both yes and no are the wrong answer.
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 20:07:50 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science >>>>>>> would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in >>>>> 1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake:
the category (type) error that I have described previously in this
forum.
What arrogant self-important ignorance! Turing indeed solved the
Entscheidungsproblem. His procedure has been verified by hundreds of
thousands of mathematicians over the last century, and none of them
have found flaws in it.
Not at all: I have simply found a flaw that has been overlooked all
this time. Peter effectively found the same flaw but came at it from a
different angle.
That's laughable. You're just a confused and deluded narcissistic
crank.
If you really believe you've found a flaw in Turing's paper, try writing
it up properly (something which is beyond you) and submit it for
publication to a reputable peer-reviewed mathematical journal. I'd be surprised if you even got a reply.
It is overwhelmingly likely that your lack of mathematical training
has led you to delude yourself about finding an error. The same
applies to Peter Olcott.
Nope, I have formally defined the error that doesn't contradict Peter's
work.
You don't even understand what "formally" means.
On 11/05/2025 12:48, Mr Flibble wrote:
On Sun, 11 May 2025 10:34:18 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
<snip>
Nope, I have formally defined the error that doesn't contradict
Peter's work.
You don't even understand what "formally" means.
Sure I do. I can formally define it again for you if you like? Here is
the formal definition:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
When executed directly, such an input would either halt or not,
category error or no.
Which is it?
On Sun, 11 May 2025 12:57:21 +0100, Richard Heathfield wrote:
On 11/05/2025 12:48, Mr Flibble wrote:
On Sun, 11 May 2025 10:34:18 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
<snip>
Nope, I have formally defined the error that doesn't contradict
Peter's work.
You don't even understand what "formally" means.
Sure I do. I can formally define it again for you if you like? Here is
the formal definition:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
When executed directly, such an input would either halt or not,
category error or no.
Which is it?
Peter's view:
* direct execution results in infinite recursion which is treated as non- halting.
Flibble's view:
* direct execution results in manifestation of the category error: which
in practice means a crash in the form of a stack fault (debatable halting equivalance) for a decider with finite resources (stack space) or non- halting for a decider with infinitie resources (stack space).
On Sun, 11 May 2025 10:34:18 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
Nope, I have formally defined the error that doesn't contradict Peter's
work.
You don't even understand what "formally" means.
Sure I do. I can formally define it again for you if you like? Here is the formal definition:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the simulating kind.
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake: the >>> category (type) error that I have described previously in this forum.
OK, then, give the page and line numbers from Turing's 1936 paper where
this alleged mistake was made. I would be surprised indeed if you'd even
looked at Turing's paper, far less understood it. Yet you're ready to
denigrate his work.
Perhaps it is time for you to withdraw these uncalled for insinuations.
/Flibble
It is the whole gist of the entire idea of
the halting problem proof that is wrongheaded.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science >>>>>>> would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan
Turing's solution of the Entscheidungsproblem. He published this in >>>>> 1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake:
the category (type) error that I have described previously in this
forum.
OK, then, give the page and line numbers from Turing's 1936 paper
where this alleged mistake was made. I would be surprised indeed if
you'd even looked at Turing's paper, far less understood it. Yet
you're ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for
insinuations.
/Flibble
It is the whole gist of the entire idea of the halting problem proof
that is wrongheaded.
You are, in fact, quite wrong. The halting problem is in the field of mathematics. You are ignorant of this field, thus unable to contribute towards it, or make judgments about it.
If you still think you are correct, and cannot point out a flaw in Alan Turing's original 1936 paper, perhaps you can find somebody qualified,
i.e. with (at least) a first degree in mathematics, to back up your
claim.
Otherwise your credibility lies close to zero.
On Sun, 11 May 2025 13:12:14 +0100, Richard Heathfield wrote:
On 11/05/2025 13:09, Mr Flibble wrote:
On Sun, 11 May 2025 12:57:21 +0100, Richard Heathfield wrote:
On 11/05/2025 12:48, Mr Flibble wrote:
On Sun, 11 May 2025 10:34:18 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
<snip>
Nope, I have formally defined the error that doesn't contradict
Peter's work.
You don't even understand what "formally" means.
Sure I do. I can formally define it again for you if you like? Here
is the formal definition:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the >>>>> simulating kind.
When executed directly, such an input would either halt or not,
category error or no.
Which is it?
Peter's view:
* direct execution results in infinite recursion which is treated as
non-
halting.
Flibble's view:
* direct execution results in manifestation of the category error:
which in practice means a crash in the form of a stack fault (debatable
halting equivalance) for a decider with finite resources (stack space)
or non- halting for a decider with infinitie resources (stack space).
So what you're saying is that the pair of you can't decide.
What is that supposed to mean?
The infinite recursion is a manifestation of the category error; the
halting problem relies on two aspects: self-reference then diagonalization but that latter can never happen as the former is invalid.
QED.
All you have demonstrated is hand waving.
On 11/05/2025 13:17, Mr Flibble wrote:
On Sun, 11 May 2025 13:12:14 +0100, Richard Heathfield wrote:
On 11/05/2025 13:09, Mr Flibble wrote:
On Sun, 11 May 2025 12:57:21 +0100, Richard Heathfield wrote:
On 11/05/2025 12:48, Mr Flibble wrote:
On Sun, 11 May 2025 10:34:18 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
<snip>
Nope, I have formally defined the error that doesn't contradict >>>>>>>> Peter's work.
You don't even understand what "formally" means.
Sure I do. I can formally define it again for you if you like? Here >>>>>> is the formal definition:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of
the simulating kind.
When executed directly, such an input would either halt or not,
category error or no.
Which is it?
Peter's view:
* direct execution results in infinite recursion which is treated as
non-
halting.
Flibble's view:
* direct execution results in manifestation of the category error:
which in practice means a crash in the form of a stack fault
(debatable halting equivalance) for a decider with finite resources
(stack space) or non- halting for a decider with infinitie resources
(stack space).
So what you're saying is that the pair of you can't decide.
What is that supposed to mean?
The infinite recursion is a manifestation of the category error; the
halting problem relies on two aspects: self-reference then
diagonalization but that latter can never happen as the former is
invalid.
QED.
All you have demonstrated is hand waving.
On the contrary, you described a category of decider program as
"pathological input" that demonstrated that the Halting Problem proof is flawed.
The Halting Problem proof claims to prove that there are some programs
whose termination status we can't know. You have devised a program
category which you claim overturns this proof, and you claim that you
can even describe the behaviour of at least one program in this
category, but you... don't know its termination status.
Got it. :-)
Are you here all week?
On 11/05/2025 13:09, Mr Flibble wrote:
On Sun, 11 May 2025 12:57:21 +0100, Richard Heathfield wrote:
On 11/05/2025 12:48, Mr Flibble wrote:
On Sun, 11 May 2025 10:34:18 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
<snip>
Nope, I have formally defined the error that doesn't contradict
Peter's work.
You don't even understand what "formally" means.
Sure I do. I can formally define it again for you if you like? Here
is the formal definition:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the
simulating kind.
When executed directly, such an input would either halt or not,
category error or no.
Which is it?
Peter's view:
* direct execution results in infinite recursion which is treated as
non-
halting.
Flibble's view:
* direct execution results in manifestation of the category error:
which in practice means a crash in the form of a stack fault (debatable
halting equivalance) for a decider with finite resources (stack space)
or non- halting for a decider with infinitie resources (stack space).
So what you're saying is that the pair of you can't decide.
QED.
On Sun, 11 May 2025 13:36:47 +0100, Richard Heathfield wrote:
On 11/05/2025 13:17, Mr Flibble wrote:
On Sun, 11 May 2025 13:12:14 +0100, Richard Heathfield wrote:
On 11/05/2025 13:09, Mr Flibble wrote:
On Sun, 11 May 2025 12:57:21 +0100, Richard Heathfield wrote:
On 11/05/2025 12:48, Mr Flibble wrote:
On Sun, 11 May 2025 10:34:18 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
<snip>
Nope, I have formally defined the error that doesn't contradict >>>>>>>>> Peter's work.
You don't even understand what "formally" means.
Sure I do. I can formally define it again for you if you like? Here >>>>>>> is the formal definition:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of >>>>>>> the simulating kind.
When executed directly, such an input would either halt or not,
category error or no.
Which is it?
Peter's view:
* direct execution results in infinite recursion which is treated as >>>>> non-
halting.
Flibble's view:
* direct execution results in manifestation of the category error:
which in practice means a crash in the form of a stack fault
(debatable halting equivalance) for a decider with finite resources
(stack space) or non- halting for a decider with infinitie resources >>>>> (stack space).
So what you're saying is that the pair of you can't decide.
What is that supposed to mean?
The infinite recursion is a manifestation of the category error; the
halting problem relies on two aspects: self-reference then
diagonalization but that latter can never happen as the former is
invalid.
QED.
All you have demonstrated is hand waving.
On the contrary, you described a category of decider program as
"pathological input" that demonstrated that the Halting Problem proof is
flawed.
The Halting Problem proof claims to prove that there are some programs
whose termination status we can't know. You have devised a program
category which you claim overturns this proof, and you claim that you
can even describe the behaviour of at least one program in this
category, but you... don't know its termination status.
I have fully described its termination status, again:
Flibble's view:
* direct execution results in manifestation of the category error:
which in practice means a crash in the form of a stack fault
(debatable halting equivalance) for a decider with finite resources
(stack space) or non- halting for a decider with infinitie resources
(stack space).
Peter's view:
* direct execution results in infinite recursion which is treated as non- halting.
On Sun, 11 May 2025 12:26:48 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science >>>>>>>> would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan >>>>>> Turing's solution of the Entscheidungsproblem. He published this in >>>>>> 1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake: >>>>> the category (type) error that I have described previously in this
forum.
OK, then, give the page and line numbers from Turing's 1936 paper
where this alleged mistake was made. I would be surprised indeed if
you'd even looked at Turing's paper, far less understood it. Yet
you're ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for
insinuations.
/Flibble
It is the whole gist of the entire idea of the halting problem proof
that is wrongheaded.
You are, in fact, quite wrong. The halting problem is in the field of
mathematics. You are ignorant of this field, thus unable to contribute
towards it, or make judgments about it.
If you still think you are correct, and cannot point out a flaw in Alan
Turing's original 1936 paper, perhaps you can find somebody qualified,
i.e. with (at least) a first degree in mathematics, to back up your
claim.
Appealing to authority is a logical fallacy.
Otherwise your credibility lies close to zero.
Ad hominem attack is a logical fallacy.
/Flibble
On 5/11/2025 5:34 AM, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 20:07:50 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer
science
would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this
with Alan
Turing's solution of the Entscheidungsproblem. He
published this in
1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a
mistake:
the category (type) error that I have described previously
in this
forum.
What arrogant self-important ignorance! Turing indeed solved
the
Entscheidungsproblem. His procedure has been verified by
hundreds of
thousands of mathematicians over the last century, and none
of them have
found flaws in it.
Not at all: I have simply found a flaw that has been
overlooked all this
time. Peter effectively found the same flaw but came at it
from a
different angle.
That's laughable. You're just a confused and deluded
narcissistic crank.
If you really believe you've found a flaw in Turing's paper,
try writing
it up properly (something which is beyond you) and submit it for
publication to a reputable peer-reviewed mathematical journal.
I'd be
surprised if you even got a reply.
It is overwhelmingly likely that your lack of mathematical
training has
led you to delude yourself about finding an error. The same
applies to
Peter Olcott.
Nope, I have formally defined the error that doesn't
contradict Peter's
work.
You don't even understand what "formally" means.
/Flibble
You pay attention to irrelevant details.
Flibble does understand the key essence of these
things better than you.
On 5/11/2025 7:26 AM, Alan Mackenzie wrote:
If you still think you are correct, and cannot point out a flaw
in Alan
Turing's original 1936 paper, perhaps you can find somebody
qualified,
i.e. with (at least) a first degree in mathematics, to back up
your
claim.
The flaw is that the conclusion is incorrect.
One can ignore every step in a proof and show
that it is wrong by simply proving that its
conclusion is incorrect.
The same thing applies to the Halting Problem's
counter example input:
On 5/11/2025 7:09 AM, Mr Flibble wrote:
On Sun, 11 May 2025 12:57:21 +0100, Richard Heathfield wrote:Not exactly, it is not direct execution.
On 11/05/2025 12:48, Mr Flibble wrote:
On Sun, 11 May 2025 10:34:18 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
<snip>
Nope, I have formally defined the error that doesn't
contradict
Peter's work.
You don't even understand what "formally" means.
Sure I do. I can formally define it again for you if you
like? Here is
the formal definition:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a
decider of the
simulating kind.
When executed directly, such an input would either halt or not,
category error or no.
Which is it?
Peter's view:
* direct execution results in infinite recursion which is
treated as non-
halting.
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
On 5/11/2025 6:13 AM, joes wrote:Yes, and then it returns to DDD, which then halts.
Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
HHH is only allowed to report on the behavior that its actual inputIt is the whole gist of the entire idea of the halting problem proofThe simulated DDD doesn't matter. HHH returns to DDD, and DDD then does
that is wrongheaded.
(1) It is anchored in the false assumption that an input to a
termination analyzer can actually do this opposite of whatever value
that this analyzer returns. No one ever notices that this "do the
opposite" code is unreachable.
the opposite.
actually specifies.
No, I can tell you that the correct answer to Carol's question is "no".Any yes/no question where both yes and no are the wrong answer is an incorrect polar question.Can Carol correctly answer “no” to this (yes/no) question?Yes, HHH cannot answer correctly.
When the context of who is asked is understood to be an aspect of the
full meaning of the question then the question posed to Carol is
incorrect because both yes and no are the wrong answer.
On 5/11/2025 9:34 AM, wij wrote:
On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
On 5/10/2025 9:09 PM, wij wrote:
On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
On 5/10/2025 8:44 PM, wij wrote:
On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
On 5/10/2025 8:17 PM, wij wrote:
On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
You don't know the counter example in the HP proof, your D is
not the case what HP says.
Sure I do this is it! (as correctly encoded in C)
typedef void (*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);
}
Try to convert it to TM language to know you know nothing.
I spent 22 years on this. I started with the Linz text
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
cannot possibly reach its simulated final halt state
⟨Ĥ.qn⟩
To refute the HP, you need to understand what it exactly means in TM. >>>>>I have known this for 22 years.
A working TM. Build it explicitly from transition function, then
explain
your derivation. You know nothing.
That would be like examining how an operating system
works entirely from its machine code.
You are refuting a CS foundamental theorem (i.e. HP) officially.
So, yes, and actually MORE need to be done (beyond your imagination).
Knowing a car or smart phone,... is far different from making one.
Knowing E=mc^2 is far from knowing relativity, making A-bomb
(actually, making
A-bomb don't need to know E=mc^2, people are often fooled by popular
saying)
Every chapter of Linz's book, C text textbook has exercises, you need
to those
exercises AT LEAST to comment CS (and computation theory is more
advanced topic
than TM). Saying so is because we know you can't do the exercise and
boast lots
about TM stuff (and pretty much anything else from just reading
words), even
about theorem.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
All that I need to know is that I proved that
embedded_H correctly recognizes the repeating
pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
cannot possibly reach its own simulated final
halt state of ⟨Ĥ.qn⟩
https://www.liarparadox.org/Linz_Proof.pdf
We only have to actually know one detail:
Every counter-example input encoded in any model
of computation always specifies recursive simulation
that never halts to its corresponding simulating
termination analyzer.
More example here that you don't understand nearly all CS terms.
Mere empty rhetoric entirely bereft of any supporting
reasoning. The x86 language is comparable to a RASP
machine that is equivalent to a Turing machine.
On 5/11/2025 6:07 AM, joes wrote:
Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
On 5/10/2025 1:37 PM, wij wrote:
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
On 5/10/2025 1:09 PM, wij wrote:
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
On 5/10/2025 12:01 PM, wij wrote:
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
On 5/10/2025 11:29 AM, wij wrote:
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
On 5/10/2025 11:06 AM, wij wrote:
On Sat, 2025-05-10 at 10:45 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
On Sat, 2025-05-10 at 09:33 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
It correctly determines that the halting problem's >>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
...which makes it halt.
The input that has baffled computer scientists for 90 years >>>>>>>>>>>>>>> is merely correctly determined to be non-halting when the >>>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this >>>>>>>>>>>>>>> input according to the rules of the x86 language.
Nobody is baffled. It halts.
I have no problem with that. And, you said HHH merely rejects >>>>>>>>>>>> it as non-halting. You had denied HHH can decide the halting >>>>>>>>>>>> property of any input, except DDD/DD/D..As long as HHH correctly determines the halt status of a single >>>>>>>>>>> input that has no inputs then HHH is a correct termination >>>>>>>>>>> analyzer for that input.
I have no problem with that, but be noticed that the HHH inside >>>>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise, the >>>>>>>>>> 'HHH'
will be an infinite recursive which cannot make any decision, >>>>>>>>>> which you had agreed)
The original set theory is now called naive set theory after itsTraditional logic (or the part mostly used) that won't cause confusion >>>> is more reliable.
mistake has been corrected. Thus the original halting problem proofs >>>>> can now be called the naive halting problem proofs.
The HP doesn't lead to contradictions.
Unless this is done as an actual simulating termination analyzer in aThe halting problem itself remains the same, yet loses its most
important proof.
HP is based on TM. Proof of any other kind other than TM have to be
cautious.
high level language like C and it operates on a 100% complete exactingly >>> precise input specification such as the x86 language too many details
slip through the cracks of vagueness.
TMs are concrete. What details, what vagueness?
There isn't even a common TM language.
If there was a TM language then examining
the details of a termination analyzer would
be like reverse engineering all of the details
of how an operating system works from its
machine code. Humans really need high level
abstractions or they get totally lost.
For example no one ever even noticed that it is 100% impossible toWrong, DDD calls HHH, which returns "non-halting", *and halts*.
derive an input that actually does the opposite of whatever value that
its termination analyzer reports.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
There is no possible way for DD emulated by HHH
according to the rules of the x86 language to
receive the return value from its call to HHH(DDD).
It has been this way for 90 years.
On Sun, 11 May 2025 10:34:18 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 20:07:50 +0000, Alan Mackenzie wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/10/2025 7:37 AM, Bonita Montero wrote:
[ .... ]
I guess that not even a professor of theoretical computer science >>>>>>>> would spend years working on so few lines of code.
I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.
You've spent over 20 years on this matter. Compare this with Alan >>>>>> Turing's solution of the Entscheidungsproblem. He published this in >>>>>> 1936 when he was just 24 years old.
Turing didn't solve anything: what he published contained a mistake: >>>>> the category (type) error that I have described previously in this
forum.
What arrogant self-important ignorance! Turing indeed solved the
Entscheidungsproblem. His procedure has been verified by hundreds of
thousands of mathematicians over the last century, and none of them
have found flaws in it.
Not at all: I have simply found a flaw that has been overlooked all
this time. Peter effectively found the same flaw but came at it from a
different angle.
That's laughable. You're just a confused and deluded narcissistic
crank.
If you really believe you've found a flaw in Turing's paper, try writing
it up properly (something which is beyond you) and submit it for
publication to a reputable peer-reviewed mathematical journal. I'd be
surprised if you even got a reply.
Such invective diatribes do you no favours, mate. The problem here is you cannot handle the fact that Flibble and Olcott have refuted the Halting Problem proofs, showing how they all contain the same flaw which Turing
and all who followed him overlooked.
It is overwhelmingly likely that your lack of mathematical training
has led you to delude yourself about finding an error. The same
applies to Peter Olcott.
Nope, I have formally defined the error that doesn't contradict Peter's
work.
You don't even understand what "formally" means.
Sure I do. I can formally define it again for you if you like? Here is the formal definition:
What constitutes halting problem pathological input:
Input that would cause infinite recursion when using a decider of the simulating kind.
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
/Flibble
On 5/11/2025 6:13 AM, joes wrote:
Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
OK, then, give the page and line numbers from Turing's 1936 paper where >>>> this alleged mistake was made. I would be surprised indeed if you'dIt is the whole gist of the entire idea of the halting problem proof
even looked at Turing's paper, far less understood it. Yet you're
ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for insinuations. >>>>
that is wrongheaded.
(1) It is anchored in the false assumption that an input to a
termination analyzer can actually do this opposite of whatever value
that this analyzer returns. No one ever notices that this "do the
opposite" code is unreachable.
The simulated DDD doesn't matter. HHH returns to DDD, and DDD then does
the opposite.
HHH is only allowed to report on the behavior that
its actual input actually specifies.
int sum(int x, int y) { return x + y; }
sum(3,2) is not allowed to report on the sum of 5 + 7
because that is not what its input specifies.
(2) It expects a self-contradictory (thus incorrect)Whether a program halts is not contradictory.
question to have a correct answer.
Asking sum(3,2) about the sum of 5 + 7
is the same as asking HHH(DDD) about the
direct execution of DDD().
Can Carol correctly answer “no” to this (yes/no) question?Yes, HHH cannot answer correctly.
When the context of who is asked is understood to be an aspect of the
full meaning of the question then the question posed to Carol is
incorrect because both yes and no are the wrong answer.
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Copyright PL Olcott 2025.
On 5/11/2025 1:38 PM, wij wrote:
On Sun, 2025-05-11 at 12:40 -0500, olcott wrote:
On 5/11/2025 12:21 PM, wij wrote:
On Sun, 2025-05-11 at 12:00 -0500, olcott wrote:
On 5/11/2025 11:28 AM, wij wrote:
On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:Everything is 100% irrelevant besides the fact that
On 5/11/2025 9:34 AM, wij wrote:
On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
On 5/10/2025 9:09 PM, wij wrote:
On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
On 5/10/2025 8:44 PM, wij wrote:
On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
On 5/10/2025 8:17 PM, wij wrote:
On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 5/10/2025 2:02 PM, wij wrote:
You don't know the counter example in the HP proof, your D >>>>>>>>>>>>>> is not the case
what HP
says.
Sure I do this is it! (as correctly encoded in C)
typedef void (*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);
}
Try to convert it to TM language to know you know nothing. >>>>>>>>>>>>
I spent 22 years on this. I started with the Linz text
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>> or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H >>>>>>>>>>> cannot possibly reach its simulated final halt state
⟨Ĥ.qn⟩
To refute the HP, you need to understand what it exactly >>>>>>>>>>>> means in TM.
I have known this for 22 years.
A working TM. Build it explicitly from transition function, >>>>>>>>>> then explain
your derivation. You know nothing.
That would be like examining how an operating system
works entirely from its machine code.
You are refuting a CS foundamental theorem (i.e. HP) officially. >>>>>>>> So, yes, and actually MORE need to be done (beyond your
imagination).
Knowing a car or smart phone,... is far different from making one. >>>>>>>> Knowing E=mc^2 is far from knowing relativity, making A-bomb
(actually, making
A-bomb don't need to know E=mc^2, people are often fooled by
popular saying)
Every chapter of Linz's book, C text textbook has exercises, you >>>>>>>> need to those
exercises AT LEAST to comment CS (and computation theory is more >>>>>>>> advanced topic
than TM). Saying so is because we know you can't do the exercise >>>>>>>> and boast lots
about TM stuff (and pretty much anything else from just reading >>>>>>>> words), even
about theorem.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
All that I need to know is that I proved that
embedded_H correctly recognizes the repeating
pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
cannot possibly reach its own simulated final
halt state of ⟨Ĥ.qn⟩
https://www.liarparadox.org/Linz_Proof.pdf
We only have to actually know one detail:
Every counter-example input encoded in any model
of computation always specifies recursive simulation
that never halts to its corresponding simulating
termination analyzer.
More example here that you don't understand nearly all CS terms. >>>>>>>>
Mere empty rhetoric entirely bereft of any supporting
reasoning. The x86 language is comparable to a RASP
machine that is equivalent to a Turing machine.
Question:
1. Do you understand that you can't do the exercises in Linz's book? >>>>>
I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
embedded_H cannot possibly reach its own simulated
final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports
on the behavior that its input specifies it can
correctly transition to Ĥ.qn.
2. Do you understand your ability of C/assembly/TM is less than 1
year CS level?
I construe C as high level assembly language thus
disregard any inessentials. No change since K & R
is of any use to me. I write C++ the same way. I
use it as C with classes. I also use std::vector a lot.
Q3. If people know the capability of the author of POOH is less than
1 year CS
level. How persuasive and reliable of POOH do you think it
would be?
Q4: Why no one can reproduce the result of POOH for these 22? years?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
All anyone need do to show that I am wrong
is provide the steps where DDD emulated by
HHH according to the rules of the x86 language
reaches its own emulated "ret" instruction.
Because no one can actually correctly show any
mistake in the above they resort to rhetoric
because that have no actual reasoning.
Q5: Do you remember you had claimed H(D) returns 1,0,both,... is
correct and
more. The answer changes. What is your comment of this?
q6: What is the return value of H(D) now, exactly?
I am only referring to the behavior of DDD
emulated by HHH according to the rules of
the x86 language.
On 5/11/2025 4:02 PM, Richard Damon wrote:
On 5/11/25 12:44 PM, olcott wrote:
On 5/11/2025 6:13 AM, joes wrote:
Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
OK, then, give the page and line numbers from Turing's 1936 paperIt is the whole gist of the entire idea of the halting problem proof >>>>> that is wrongheaded.
where
this alleged mistake was made. I would be surprised indeed if you'd >>>>>> even looked at Turing's paper, far less understood it. Yet you're >>>>>> ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for
insinuations.
(1) It is anchored in the false assumption that an input to a
termination analyzer can actually do this opposite of whatever value >>>>> that this analyzer returns. No one ever notices that this "do the
opposite" code is unreachable.
The simulated DDD doesn't matter. HHH returns to DDD, and DDD then does >>>> the opposite.
HHH is only allowed to report on the behavior that
its actual input actually specifies.
Which is DEFINED to be the bahavior of the program that the input
represents when run.
When you define 5 == 6 you are simply wrong.
That definition contradicts other axioms.
On 5/11/2025 3:36 PM, Richard Damon wrote:
On 5/11/25 12:37 PM, olcott wrote:
On 5/11/2025 6:07 AM, joes wrote:
Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:
On 5/10/2025 4:44 PM, wij wrote:...which makes it halt.
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
On 5/10/2025 1:37 PM, wij wrote:
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
On 5/10/2025 1:09 PM, wij wrote:
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
On 5/10/2025 12:01 PM, wij wrote:
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
On 5/10/2025 11:29 AM, wij wrote:
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
On Sat, 2025-05-10 at 10:45 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
On Sat, 2025-05-10 at 09:33 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
It correctly determines that the halting problem's >>>>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting. >>>>
The input that has baffled computer scientists for 90 >>>>>>>>>>>>>>>>> years
is merely correctly determined to be non-halting when the >>>>>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this >>>>>>>>>>>>>>>>> input according to the rules of the x86 language.
Nobody is baffled. It halts.
I have no problem with that. And, you said HHH merely rejects >>>>>>>>>>>>>> it as non-halting. You had denied HHH can decide the halting >>>>>>>>>>>>>> property of any input, except DDD/DD/D..As long as HHH correctly determines the halt status of a >>>>>>>>>>>>> single
input that has no inputs then HHH is a correct termination >>>>>>>>>>>>> analyzer for that input.
I have no problem with that, but be noticed that the HHH inside >>>>>>>>>>>> DD is not the 'HHH' that makes the final decision
(otherwise, the
'HHH'
will be an infinite recursive which cannot make any decision, >>>>>>>>>>>> which you had agreed)
The original set theory is now called naive set theory after its >>>>>>> mistake has been corrected. Thus the original halting problem proofs >>>>>>> can now be called the naive halting problem proofs.Traditional logic (or the part mostly used) that won't cause
confusion
is more reliable.
The HP doesn't lead to contradictions.
Unless this is done as an actual simulating termination analyzer in a >>>>> high level language like C and it operates on a 100% completeThe halting problem itself remains the same, yet loses its most
important proof.
HP is based on TM. Proof of any other kind other than TM have to be >>>>>> cautious.
exactingly
precise input specification such as the x86 language too many details >>>>> slip through the cracks of vagueness.
TMs are concrete. What details, what vagueness?
There isn't even a common TM language.
If there was a TM language then examining
the details of a termination analyzer would
be like reverse engineering all of the details
of how an operating system works from its
machine code. Humans really need high level
abstractions or they get totally lost.
There is a standardize version of the Turing Machine Language.
The fact the problem is too big for you to understand just shows that
you are just too stupid to understand it.
Note, Turing Machines CAN be described at a high level, just like the
OS. And just like understanding the OS with high level code needs an
understanding of the lower level code, understanding the high level
descriptions of Turing Machines needs an understanding of the basic
operaiton of a Turing Machine.
Since you couldn't handle a Turing Machine of only a few states, that
is about like not being able to understand an assembly function of
just a small number of instructions.
For example no one ever even noticed that it is 100% impossible toWrong, DDD calls HHH, which returns "non-halting", *and halts*.
derive an input that actually does the opposite of whatever value that >>>>> its termination analyzer reports.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
There is no possible way for DD emulated by HHH
according to the rules of the x86 language to
receive the return value from its call to HHH(DDD).
It has been this way for 90 years.
First, if that is ALL the input, HHH can't emulate past the call
instruction and be a pure function.
Sure it can.
On 5/11/2025 4:48 PM, wij wrote:
On Sun, 2025-05-11 at 15:53 -0500, olcott wrote:
On 5/11/2025 3:23 PM, wij wrote:
On Sun, 2025-05-11 at 15:19 -0500, olcott wrote:
On 5/11/2025 1:38 PM, wij wrote:
On Sun, 2025-05-11 at 12:40 -0500, olcott wrote:
On 5/11/2025 12:21 PM, wij wrote:
On Sun, 2025-05-11 at 12:00 -0500, olcott wrote:
On 5/11/2025 11:28 AM, wij wrote:
On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
On 5/11/2025 9:34 AM, wij wrote:
On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
On 5/10/2025 9:09 PM, wij wrote:
On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
On 5/10/2025 8:44 PM, wij wrote:
On Sat, 2025-05-10 at 20:26 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 5/10/2025 8:17 PM, wij wrote:
On Sat, 2025-05-10 at 17:03 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>> On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>>>> On 5/10/2025 2:02 PM, wij wrote:
You don't know the counter example in the HP proof, >>>>>>>>>>>>>>>>>> your D is not the
case
what HP
says.
Sure I do this is it! (as correctly encoded in C) >>>>>>>>>>>>>>>>>
typedef void (*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);
}
Try to convert it to TM language to know you know nothing. >>>>>>>>>>>>>>>>
I spent 22 years on this. I started with the Linz text >>>>>>>>>>>>>>>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>>> or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H >>>>>>>>>>>>>>> cannot possibly reach its simulated final halt state >>>>>>>>>>>>>>> ⟨Ĥ.qn⟩
To refute the HP, you need to understand what it exactly >>>>>>>>>>>>>>>> means in TM.
I have known this for 22 years.
A working TM. Build it explicitly from transition >>>>>>>>>>>>>> function, then explain
your derivation. You know nothing.
That would be like examining how an operating system >>>>>>>>>>>>> works entirely from its machine code.
You are refuting a CS foundamental theorem (i.e. HP)
officially.
So, yes, and actually MORE need to be done (beyond your >>>>>>>>>>>> imagination).
Knowing a car or smart phone,... is far different from >>>>>>>>>>>> making one.
Knowing E=mc^2 is far from knowing relativity, making A-bomb >>>>>>>>>>>> (actually, making
A-bomb don't need to know E=mc^2, people are often fooled by >>>>>>>>>>>> popular saying)
Every chapter of Linz's book, C text textbook has exercises, >>>>>>>>>>>> you need to those
exercises AT LEAST to comment CS (and computation theory is >>>>>>>>>>>> more advanced topic
than TM). Saying so is because we know you can't do the >>>>>>>>>>>> exercise and boast lots
about TM stuff (and pretty much anything else from just >>>>>>>>>>>> reading words), even
about theorem.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>> or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
All that I need to know is that I proved that
embedded_H correctly recognizes the repeating
pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
cannot possibly reach its own simulated final
halt state of ⟨Ĥ.qn⟩
https://www.liarparadox.org/Linz_Proof.pdf
We only have to actually know one detail:
Every counter-example input encoded in any model
of computation always specifies recursive simulation >>>>>>>>>>>>> that never halts to its corresponding simulating
termination analyzer.
More example here that you don't understand nearly all CS >>>>>>>>>>>> terms.
Mere empty rhetoric entirely bereft of any supporting
reasoning. The x86 language is comparable to a RASP
machine that is equivalent to a Turing machine.
Question:
1. Do you understand that you can't do the exercises in Linz's >>>>>>>>>> book?
Everything is 100% irrelevant besides the fact that
I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
embedded_H cannot possibly reach its own simulated
final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports
on the behavior that its input specifies it can
correctly transition to Ĥ.qn.
2. Do you understand your ability of C/assembly/TM is less >>>>>>>>>> than 1 year CS level?
I construe C as high level assembly language thus
disregard any inessentials. No change since K & R
is of any use to me. I write C++ the same way. I
use it as C with classes. I also use std::vector a lot.
Q3. If people know the capability of the author of POOH is less >>>>>>>> than 1 year CS
level. How persuasive and reliable of POOH do you think >>>>>>>> it would be?
Q4: Why no one can reproduce the result of POOH for these 22?
years?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
All anyone need do to show that I am wrong
is provide the steps where DDD emulated by
HHH according to the rules of the x86 language
reaches its own emulated "ret" instruction.
Because no one can actually correctly show any
mistake in the above they resort to rhetoric
because that have no actual reasoning.
Q5: Do you remember you had claimed H(D) returns 1,0,both,... is
correct and
more. The answer changes. What is your comment of this? >>>>>>
q6: What is the return value of H(D) now, exactly?
I am only referring to the behavior of DDD
emulated by HHH according to the rules of
the x86 language.
So, you longer refute the HP now?
ZFC corrected the error in set theory so that
it could resolve Russell's Paradox. The original
set theory has now called naive set theory.
I corrected the error of the HP that expects
HHH to report on behavior that is different
than the behavior that its input actually
specifies.
Specificly, "Halt(D)=1 iff D() halts" is an error?
And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)?
Yes that is an error because the behavior that
the input to HHH(DDD) specifies is the behavior
that HHH must report on.
On 11/05/2025 17:44, olcott wrote:
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to get it to compile and after we've
leeched out all the dodgy programming).
If the computer cannot correctly decide whether or not DD halts,
we have an undecidable computation,
and therefore some computations are undecidable, so Turing's conclusion was right. Who knew? (Apart
from practically everybody else, I mean.)
On 11/05/2025 18:11, Richard Heathfield wrote:
On 11/05/2025 17:44, olcott wrote:
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to
get it to compile and after we've leeched out all the dodgy
programming).
Done that.
It still stops.
If the computer cannot correctly decide whether or not DD halts,
The decider says it doesn't stop..
we have an undecidable computation,
No no, that doesn't make sense.
DD stops, and there are lots of
partial halt deciders that will decide that particular input
correctly. PO's DD isn't "undecidable".
No single computation can be undecidable, considered on its own!
There are only two possibilities: it halts or it doesn't.
On 5/11/2025 7:33 PM, wij wrote:
On Sun, 2025-05-11 at 18:08 -0500, olcott wrote:
On 5/11/2025 5:50 PM, wij wrote:
On Sun, 2025-05-11 at 17:30 -0500, olcott wrote:
On 5/11/2025 5:11 PM, wij wrote:
On Sun, 2025-05-11 at 17:00 -0500, olcott wrote:
[cut]
ZFC corrected the error in set theory so that
it could resolve Russell's Paradox. The original
set theory has now called naive set theory.
I corrected the error of the HP that expects
HHH to report on behavior that is different
than the behavior that its input actually
specifies.
Specificly, "Halt(D)=1 iff D() halts" is an error?
And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>>>>>>>
Yes that is an error because the behavior that
the input to HHH(DDD) specifies is the behavior
that HHH must report on.
If so, how do we know a given function e.g. D, halts or not by
giving it to H,
i.e. H(D)? Wrong question (according to you)?
H and D is too vague and ambiguous.
We know that the input to HHH(DDD) specifies
a non-halting sequence of configurations.
We know that the input to HHH1(DDD) specifies
a halting sequence of configurations.
Instead, every time we want to know whether D halts or not,
When we intentionally define an input to attempt
to thwart a specific termination analyzer THIS DOES
CHANGE THE BEHAVIOR.
If we let people run uploaded programs on our
network we need to know if these programs are
going to halt.
Unless HHH(DDD) rejects its input as non-halting
HHH will continue to eat up network resources.
But, according to POOH, if D going to eat up network resources, it
have to
happen when we run POOH(D), because you said D's halting property only >>>> valid to H.
If we want to prevent this kind of denial of service
attack HHH must be able correctly handle inputs that
are trying to thwart it or HHH fails.
When HHH is our official denial of service attack
preventer it either rejects its input DDD as non
halting or it gets stuck in recursive emulation
thus fails.
It always has been the requirement that a termination
analyzer was required to report on the behavior that
its input actually specifies.
This is a subtle nuance of functions computed by
models of computation that no one bothered to
pay attention to because they didn't know it made
any difference.
Is DDD a virus?
If on a real system an input tried to fool the
denial-of-service-attack detector IT WOULD FAIL.
Prior to my work a denial-of-service-attack detector
WOULD FAIL. It would not know to reject DDD.
On 5/11/2025 6:39 PM, Richard Damon wrote:
On 5/11/25 5:15 PM, olcott wrote:
On 5/11/2025 4:02 PM, Richard Damon wrote:
On 5/11/25 12:44 PM, olcott wrote:
On 5/11/2025 6:13 AM, joes wrote:
Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
OK, then, give the page and line numbers from Turing's 1936It is the whole gist of the entire idea of the halting problem proof >>>>>>> that is wrongheaded.
paper where
this alleged mistake was made. I would be surprised indeed if >>>>>>>> you'd
even looked at Turing's paper, far less understood it. Yet you're >>>>>>>> ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for
insinuations.
(1) It is anchored in the false assumption that an input to a
termination analyzer can actually do this opposite of whatever value >>>>>>> that this analyzer returns. No one ever notices that this "do the >>>>>>> opposite" code is unreachable.
The simulated DDD doesn't matter. HHH returns to DDD, and DDD then >>>>>> does
the opposite.
HHH is only allowed to report on the behavior that
its actual input actually specifies.
Which is DEFINED to be the bahavior of the program that the input
represents when run.
When you define 5 == 6 you are simply wrong.
That definition contradicts other axioms.
And where did I do that?
When the definition of the halting problem requires
the termination analyzer H to report on behavior besides
the behavior of the input D simulated by H according
to the rules of the computational language that the
input D is encoded within.
On 5/11/2025 7:38 PM, Mike Terry wrote:
On 11/05/2025 18:11, Richard Heathfield wrote:
On 11/05/2025 17:44, olcott wrote:
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to get it
to compile and after we've leeched out all the dodgy programming).
Done that. It still stops.
If the computer cannot correctly decide whether or not DD halts,
The decider says it doesn't stop..
we have an undecidable computation,
No no, that doesn't make sense. DD stops, and there are lots of
partial halt deciders that will decide that particular input
correctly. PO's DD isn't "undecidable".
No single computation can be undecidable, considered on its own!
There are only two possibilities: it halts or it doesn't. In either
case there is a decider which decides that /one specific input/
correctly. By extension, any finite number of computations is
decidable - we just have a giant switch statement followed by
returning halts/neverhalts as appropriate. If the input domain has
just n inputs, there are 2^n trivial deciders that together cater for
every combination of each input halting or never halting. One of
those deciders is a correct decider for that (finite domain) problem.
The HP is asking for a TM (or equiv.) that correctly decides EVERY
(P,I) in its one finite algorithm. That is what is proven
impossible. The trick of having a big switch statement no longer
works because there are infinitely many possible inputs.
Decidability for just one single input is trivial and not intersting.
and therefore some computations are undecidable, so Turing's
conclusion was right. Who knew? (Apart from practically everybody
else, I mean.)
Mike.
DDD emulated by HHH according to the rules of
the computational language that DD is encoded
within already proves that the HP "impossible"
input specifies a non-halting sequence of
configurations.
The same goes for the Linz proof.
The mistake is continuing to assume that a
termination analyzer must report on behavior
other than the behavior that its input specifies.
When an input is simulated according to
the behavior specified by the computation
language that it is encoded within
THEN THIS SIMULATION IS CORRECT.
It seems nuts (or dishonest) to claim otherwise.
On 5/11/2025 7:58 PM, dbush wrote:
On 5/11/2025 8:48 PM, olcott wrote:
On 5/11/2025 7:38 PM, Mike Terry wrote:
On 11/05/2025 18:11, Richard Heathfield wrote:
On 11/05/2025 17:44, olcott wrote:Done that. It still stops.
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to get
it to compile and after we've leeched out all the dodgy programming). >>>>
If the computer cannot correctly decide whether or not DD halts,
The decider says it doesn't stop..
we have an undecidable computation,
No no, that doesn't make sense. DD stops, and there are lots of
partial halt deciders that will decide that particular input
correctly. PO's DD isn't "undecidable".
No single computation can be undecidable, considered on its own!
There are only two possibilities: it halts or it doesn't. In either
case there is a decider which decides that /one specific input/
correctly. By extension, any finite number of computations is
decidable - we just have a giant switch statement followed by
returning halts/neverhalts as appropriate. If the input domain has
just n inputs, there are 2^n trivial deciders that together cater
for every combination of each input halting or never halting. One
of those deciders is a correct decider for that (finite domain)
problem.
The HP is asking for a TM (or equiv.) that correctly decides EVERY
(P,I) in its one finite algorithm. That is what is proven
impossible. The trick of having a big switch statement no longer
works because there are infinitely many possible inputs.
Decidability for just one single input is trivial and not intersting.
and therefore some computations are undecidable, so Turing's
conclusion was right. Who knew? (Apart from practically everybody
else, I mean.)
Mike.
DDD emulated by HHH according to the rules of
the computational language that DD is encoded
within
Doesn't happen, as you have admitted on the record:
I admitted on record that DDD is not infinitely
emulated by HHH. Because you are only a damned
Troll you try to twist this into incorrect emulation.
On 12/05/2025 18:05, Ben Bacarisse wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 12/05/2025 01:38, Mike Terry wrote:
<snip>
This is very odd. You know it either halts or it does not halt so whatNo single computation can be undecidable, considered on its own! There >>>>> are only two possibilities: it halts or it doesn't.
Or both, it seems. You say it halts (and I would not hesitate to take you at
your word if the alternative is to dredge up a Windows system from
somewhere). Olcott says it is non-halting.
do you mean by "Or both, it seems."?
'Odd' is exactly the word.
Mr Olcott claims it never halts,
and Mike Terry claims that it halts almost immediately.
Perhaps we should send DDD to a robopsychiatrist.
On 12/05/2025 01:38, Mike Terry wrote:
On 11/05/2025 18:11, Richard Heathfield wrote:
On 11/05/2025 17:44, olcott wrote:
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to get it to compile and after we've
leeched out all the dodgy programming).
Done that.
And you still had code left?
It still stops.
Okay.
If the computer cannot correctly decide whether or not DD halts,
The decider says it doesn't stop..
I said "cannot >>>correctly<<< decide".
we have an undecidable computation,
No no, that doesn't make sense.
Agreed. Therefore, even *after* taking out all the dodgy code, the decider must be broken.
DD stops, and there are lots of partial halt deciders that will decide that particular input
correctly. PO's DD isn't "undecidable".
I hear what you're saying (or at least I see what you typed), but if DD's result is so decidable,
how come his decider can't correctly decide?
No single computation can be undecidable, considered on its own! There are only two possibilities:
it halts or it doesn't.
Or both, it seems. You say it halts (and I would not hesitate to take you at your word if the
alternative is to dredge up a Windows system from somewhere). Olcott says it is non-halting.
And we both know it /can't/ be both...
Saying ".. /cannot/ correctly decide.." suggests you may be
thinking about something the wrong way.
Richard Heathfield <rjh@cpax.org.uk> writes:
Mr Olcott claims it never halts,
I don't think he does.
On 5/11/2025 8:15 PM, Richard Damon wrote:
On 5/11/25 8:51 PM, olcott wrote:
On 5/11/2025 7:33 PM, wij wrote:
On Sun, 2025-05-11 at 18:08 -0500, olcott wrote:
On 5/11/2025 5:50 PM, wij wrote:
On Sun, 2025-05-11 at 17:30 -0500, olcott wrote:
On 5/11/2025 5:11 PM, wij wrote:
On Sun, 2025-05-11 at 17:00 -0500, olcott wrote:
[cut]
ZFC corrected the error in set theory so that
it could resolve Russell's Paradox. The original
set theory has now called naive set theory.
I corrected the error of the HP that expects
HHH to report on behavior that is different
than the behavior that its input actually
specifies.
Specificly, "Halt(D)=1 iff D() halts" is an error?
And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>>>>>>>>>
Yes that is an error because the behavior that
the input to HHH(DDD) specifies is the behavior
that HHH must report on.
If so, how do we know a given function e.g. D, halts or not by >>>>>>>> giving it to H,
i.e. H(D)? Wrong question (according to you)?
H and D is too vague and ambiguous.
We know that the input to HHH(DDD) specifies
a non-halting sequence of configurations.
We know that the input to HHH1(DDD) specifies
a halting sequence of configurations.
Instead, every time we want to know whether D halts or not,
When we intentionally define an input to attempt
to thwart a specific termination analyzer THIS DOES
CHANGE THE BEHAVIOR.
If we let people run uploaded programs on our
network we need to know if these programs are
going to halt.
Unless HHH(DDD) rejects its input as non-halting
HHH will continue to eat up network resources.
But, according to POOH, if D going to eat up network resources, it >>>>>> have to
happen when we run POOH(D), because you said D's halting property
only
valid to H.
If we want to prevent this kind of denial of service
attack HHH must be able correctly handle inputs that
are trying to thwart it or HHH fails.
When HHH is our official denial of service attack
preventer it either rejects its input DDD as non
halting or it gets stuck in recursive emulation
thus fails.
It always has been the requirement that a termination
analyzer was required to report on the behavior that
its input actually specifies.
This is a subtle nuance of functions computed by
models of computation that no one bothered to
pay attention to because they didn't know it made
any difference.
Is DDD a virus?
If on a real system an input tried to fool the
denial-of-service-attack detector IT WOULD FAIL.
Prior to my work a denial-of-service-attack detector
WOULD FAIL. It would not know to reject DDD.
But DDD doesn't do a denial of service, so it is a false positive.
When HHH is a denial-of-service-detector and DDD
is trying to fool HHH into getting stuck in recursive
emulation thus causing denial-of-service HHH is not fooled.
On 5/11/2025 8:40 PM, Richard Damon wrote:
On 5/11/25 9:05 PM, olcott wrote:
On 5/11/2025 7:58 PM, dbush wrote:
On 5/11/2025 8:48 PM, olcott wrote:
On 5/11/2025 7:38 PM, Mike Terry wrote:
On 11/05/2025 18:11, Richard Heathfield wrote:
On 11/05/2025 17:44, olcott wrote:
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to
get it to compile and after we've leeched out all the dodgy
programming).
Done that. It still stops.
If the computer cannot correctly decide whether or not DD halts,
The decider says it doesn't stop..
we have an undecidable computation,
No no, that doesn't make sense. DD stops, and there are lots of
partial halt deciders that will decide that particular input
correctly. PO's DD isn't "undecidable".
No single computation can be undecidable, considered on its own!
There are only two possibilities: it halts or it doesn't. In
either case there is a decider which decides that /one specific
input/ correctly. By extension, any finite number of computations
is decidable - we just have a giant switch statement followed by
returning halts/neverhalts as appropriate. If the input domain
has just n inputs, there are 2^n trivial deciders that together
cater for every combination of each input halting or never
halting. One of those deciders is a correct decider for that
(finite domain) problem.
The HP is asking for a TM (or equiv.) that correctly decides EVERY >>>>>> (P,I) in its one finite algorithm. That is what is proven
impossible. The trick of having a big switch statement no longer >>>>>> works because there are infinitely many possible inputs.
Decidability for just one single input is trivial and not intersting. >>>>>>
and therefore some computations are undecidable, so Turing's
conclusion was right. Who knew? (Apart from practically everybody >>>>>>> else, I mean.)
Mike.
DDD emulated by HHH according to the rules of
the computational language that DD is encoded
within
Doesn't happen, as you have admitted on the record:
I admitted on record that DDD is not infinitely
emulated by HHH. Because you are only a damned
Troll you try to twist this into incorrect emulation.
Then why is the emulation of it non-halting?
You will never know because you have no idea
what infinite recursion is.
On 5/11/2025 8:27 PM, Richard Damon wrote:
On 5/11/25 8:48 PM, olcott wrote:
On 5/11/2025 7:38 PM, Mike Terry wrote:
On 11/05/2025 18:11, Richard Heathfield wrote:
On 11/05/2025 17:44, olcott wrote:Done that. It still stops.
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to get
it to compile and after we've leeched out all the dodgy programming). >>>>
If the computer cannot correctly decide whether or not DD halts,
The decider says it doesn't stop..
we have an undecidable computation,
No no, that doesn't make sense. DD stops, and there are lots of
partial halt deciders that will decide that particular input
correctly. PO's DD isn't "undecidable".
No single computation can be undecidable, considered on its own!
There are only two possibilities: it halts or it doesn't. In either
case there is a decider which decides that /one specific input/
correctly. By extension, any finite number of computations is
decidable - we just have a giant switch statement followed by
returning halts/neverhalts as appropriate. If the input domain has
just n inputs, there are 2^n trivial deciders that together cater
for every combination of each input halting or never halting. One
of those deciders is a correct decider for that (finite domain)
problem.
The HP is asking for a TM (or equiv.) that correctly decides EVERY
(P,I) in its one finite algorithm. That is what is proven
impossible. The trick of having a big switch statement no longer
works because there are infinitely many possible inputs.
Decidability for just one single input is trivial and not intersting.
and therefore some computations are undecidable, so Turing's
conclusion was right. Who knew? (Apart from practically everybody
else, I mean.)
Mike.
DDD emulated by HHH according to the rules of
the computational language that DD is encoded
within already proves that the HP "impossible"
input specifies a non-halting sequence of
configurations.
No it doesn't.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Show all the steps of DDD emulated by simulating
termination analyzer HHH according to the rules
of the x86 language where the emulated DDD reaches
its "ret" instruction.
You can't only because you know that you are
lying about this.
Your static data trick was clever yet your HHH
was not a simulating termination analyzer.
On 5/11/2025 8:59 PM, dbush wrote:
On 5/11/2025 9:56 PM, olcott wrote:
On 5/11/2025 8:27 PM, Richard Damon wrote:
On 5/11/25 8:48 PM, olcott wrote:
On 5/11/2025 7:38 PM, Mike Terry wrote:
On 11/05/2025 18:11, Richard Heathfield wrote:
On 11/05/2025 17:44, olcott wrote:
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to
get it to compile and after we've leeched out all the dodgy
programming).
Done that. It still stops.
If the computer cannot correctly decide whether or not DD halts,
The decider says it doesn't stop..
we have an undecidable computation,
No no, that doesn't make sense. DD stops, and there are lots of
partial halt deciders that will decide that particular input
correctly. PO's DD isn't "undecidable".
No single computation can be undecidable, considered on its own!
There are only two possibilities: it halts or it doesn't. In
either case there is a decider which decides that /one specific
input/ correctly. By extension, any finite number of computations
is decidable - we just have a giant switch statement followed by
returning halts/neverhalts as appropriate. If the input domain
has just n inputs, there are 2^n trivial deciders that together
cater for every combination of each input halting or never
halting. One of those deciders is a correct decider for that
(finite domain) problem.
The HP is asking for a TM (or equiv.) that correctly decides EVERY >>>>>> (P,I) in its one finite algorithm. That is what is proven
impossible. The trick of having a big switch statement no longer >>>>>> works because there are infinitely many possible inputs.
Decidability for just one single input is trivial and not intersting. >>>>>>
and therefore some computations are undecidable, so Turing's
conclusion was right. Who knew? (Apart from practically everybody >>>>>>> else, I mean.)
Mike.
DDD emulated by HHH according to the rules of
the computational language that DD is encoded
within already proves that the HP "impossible"
input specifies a non-halting sequence of
configurations.
No it doesn't.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Show all the steps of DDD emulated by simulating
termination analyzer HHH according to the rules
of the x86 language
Which it doesn't do as you have admitted on the record:
I am daring you to show what they should be.
You know you can't because you know you are a liar.
On 5/11/2025 8:31 PM, Richard Damon wrote:
On 5/11/25 8:29 PM, olcott wrote:
On 5/11/2025 6:39 PM, Richard Damon wrote:
On 5/11/25 5:15 PM, olcott wrote:
On 5/11/2025 4:02 PM, Richard Damon wrote:
On 5/11/25 12:44 PM, olcott wrote:
On 5/11/2025 6:13 AM, joes wrote:
Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
OK, then, give the page and line numbers from Turing's 1936 >>>>>>>>>> paper whereIt is the whole gist of the entire idea of the halting problem >>>>>>>>> proof
this alleged mistake was made. I would be surprised indeed if >>>>>>>>>> you'd
even looked at Turing's paper, far less understood it. Yet >>>>>>>>>> you're
ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for
insinuations.
that is wrongheaded.
(1) It is anchored in the false assumption that an input to a >>>>>>>>> termination analyzer can actually do this opposite of whatever >>>>>>>>> value
that this analyzer returns. No one ever notices that this "do the >>>>>>>>> opposite" code is unreachable.
The simulated DDD doesn't matter. HHH returns to DDD, and DDD
then does
the opposite.
HHH is only allowed to report on the behavior that
its actual input actually specifies.
Which is DEFINED to be the bahavior of the program that the input
represents when run.
When you define 5 == 6 you are simply wrong.
That definition contradicts other axioms.
And where did I do that?
When the definition of the halting problem requires
the termination analyzer H to report on behavior besides
the behavior of the input D simulated by H according
to the rules of the computational language that the
input D is encoded within.
Where do you get that behavior to be decided needs to be based on the
partial simulation of the decider.
The behavior of the input to HHH(DDD) is only correctly
measured by the behavior that it actually specifies.
Since DDD <is> a sequence of programming instructions
this behavior must be measured according to its
computer language.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD calls HHH(DDD) HHH is not free to
"interpret" this call as meaning JMP 00002183.
On 5/12/2025 9:17 PM, Mike Terry wrote:
On 12/05/2025 02:25, Richard Heathfield wrote:
On 12/05/2025 01:38, Mike Terry wrote:
On 11/05/2025 18:11, Richard Heathfield wrote:
On 11/05/2025 17:44, olcott wrote:Done that.
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to get
it to compile and after we've leeched out all the dodgy programming). >>>>
And you still had code left?
It still stops.
Okay.
If the computer cannot correctly decide whether or not DD halts,
The decider says it doesn't stop..
I said "cannot >>>correctly<<< decide".
There are infinitely many deciders that could be given the input.
Some of them decide that particular input correctly, and some
incorrectly.
PO's HHH is one of the ones that decide incorrectly.
When "correctly" means to report on behavior besides
that behavior that the input actually specifies then
it is wrong.
When 2 + 3 = 5 this is determined by the rules
of arithmetic.
When the behavior that the input specifies according
to the rules of the x86 language is non-halting then
HHH must report on this behavior.
HHH cannot compute the mapping from its input to
the behavior of the directly executed DD() for the
same reason that
int sum(int x, int y) { return x + y; }
sum(3,2) can not compute any mapping to sum 5 + 7.
THE INPUT SPECIFIES SOMETHING ELSE.
On 5/12/2025 11:46 AM, Ben Bacarisse wrote:
wij <wyniijj5@gmail.com> writes:
On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:...
On 5/10/2025 8:44 PM, wij wrote:
...Try to convert it to TM language to know you know nothing.
To refute the HP, you need to understand what it exactly means in TM. >>>>I have known this for 22 years.
A working TM. Build it explicitly from transition function, then explain >>> your derivation. You know nothing.
He did, in 2018, claim to have exactly such a thing:
"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."
"I [...] encoded all of the exact TMD instructions of the Linz Turing >> machine H that correctly decides halting for its fully encoded input
pair: (Ĥ, Ĥ)."
"I provide the exact ⊢* wildcard states after the Linz H.q0 and after >> Ĥ.qx (Linz incorrectly uses q0 twice) showing exactly how the actual >> Linz H would correctly decide the actual Linz (Ĥ, Ĥ)."
Of course, no such "fully encoded Turing Machines" were ever produced.
He spent months rowing back this claim, eventually settling on the
notion that he was using "poetic licence" rather than admit he was wrong.
<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 10/17/2022 10:23 AM, Ben Bacarisse wrote:
...D(D) would not halt unless H stops the simulation.
H /can/ correctly determine this silly criterion (in this one case)...
On 5/12/2025 3:03 AM, Mikko wrote:
On 2025-05-11 17:00:41 +0000, olcott said:
On 5/11/2025 11:28 AM, wij wrote:
On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
On 5/11/2025 9:34 AM, wij wrote:
On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
On 5/10/2025 9:09 PM, wij wrote:
On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
On 5/10/2025 8:44 PM, wij wrote:
On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
On 5/10/2025 8:17 PM, wij wrote:
On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
You don't know the counter example in the HP proof, your D >>>>>>>>>>>> is not the case what HP
says.
Sure I do this is it! (as correctly encoded in C)
typedef void (*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);
}
Try to convert it to TM language to know you know nothing. >>>>>>>>>>
I spent 22 years on this. I started with the Linz text
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>> or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
cannot possibly reach its simulated final halt state
⟨Ĥ.qn⟩
To refute the HP, you need to understand what it exactly means >>>>>>>>>> in TM.
I have known this for 22 years.
A working TM. Build it explicitly from transition function, then >>>>>>>> explain
your derivation. You know nothing.
That would be like examining how an operating system
works entirely from its machine code.
You are refuting a CS foundamental theorem (i.e. HP) officially.
So, yes, and actually MORE need to be done (beyond your imagination). >>>>>>
Knowing a car or smart phone,... is far different from making one. >>>>>> Knowing E=mc^2 is far from knowing relativity, making A-bomb
(actually, making
A-bomb don't need to know E=mc^2, people are often fooled by
popular saying)
Every chapter of Linz's book, C text textbook has exercises, you
need to those
exercises AT LEAST to comment CS (and computation theory is more
advanced topic
than TM). Saying so is because we know you can't do the exercise
and boast lots
about TM stuff (and pretty much anything else from just reading
words), even
about theorem.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
All that I need to know is that I proved that
embedded_H correctly recognizes the repeating
pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
cannot possibly reach its own simulated final
halt state of ⟨Ĥ.qn⟩
https://www.liarparadox.org/Linz_Proof.pdf
We only have to actually know one detail:
Every counter-example input encoded in any model
of computation always specifies recursive simulation
that never halts to its corresponding simulating
termination analyzer.
More example here that you don't understand nearly all CS terms.
Mere empty rhetoric entirely bereft of any supporting
reasoning. The x86 language is comparable to a RASP
machine that is equivalent to a Turing machine.
Question:
1. Do you understand that you can't do the exercises in Linz's book?
Everything is 100% irrelevant besides the fact that
I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
embedded_H cannot possibly reach its own simulated
final halt state ⟨Ĥ.qn⟩.
Which is irrelevant as from that you can't infer whether the input
specifies a halting computation.
That seems to show that you do not know that a halting
computation is defined as reaching a final halt state.
Stopping running for any other reason does not count as
halting.
Termination analyzers compute the mapping from their
inputs to the behavior that these inputs actually specify.
Clearly the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ specifies recursive simulation that does not halt.
When his HHH simulates DD, it spots a pattern in the simulation which PO calls his "infinite recursive simulation" pattern. PO believes that
this pattern "specifies non halting behaviour" but it does not, as it
can match for both halting and non-halting computations. Anyhow, PO has coded HHH to abort and return non-halting if it sees that pattern. He
really really really believes that pattern "specifies non halting",
despite observing with his own eyes DD halting when called directly!
The rest of his arguments are just attempts to justify why HHH is
"correct" to decide non-halting, despite DD halting. They generally
amount to something like "during simulation my HHH detected non-halting behaviour, so it is correct to decide non-halting".
On 5/12/2025 11:41 AM, dbush wrote:
On 5/12/2025 12:19 PM, olcott wrote:
On 5/12/2025 10:06 AM, dbush wrote:
On 5/12/2025 11:04 AM, olcott wrote:
Termination analyzers compute the mapping from their
inputs to the behavior that these inputs actually specify.
False. They compute the mapping from their input to the behavior of
the algorithm described by the input when executed directly, as per the >>>> requirements:
That is easily proven stupidly wrong.
Category error. Definitions are not proven:
Definitions that contradict other definitions are refuted.
On 5/11/2025 8:31 PM, Richard Damon wrote:
On 5/11/25 8:29 PM, olcott wrote:
On 5/11/2025 6:39 PM, Richard Damon wrote:
On 5/11/25 5:15 PM, olcott wrote:
On 5/11/2025 4:02 PM, Richard Damon wrote:
On 5/11/25 12:44 PM, olcott wrote:
On 5/11/2025 6:13 AM, joes wrote:
Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
OK, then, give the page and line numbers from Turing's 1936 >>>>>>>>>> paper whereIt is the whole gist of the entire idea of the halting problem >>>>>>>>> proof
this alleged mistake was made. I would be surprised indeed if >>>>>>>>>> you'd
even looked at Turing's paper, far less understood it. Yet >>>>>>>>>> you're
ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for
insinuations.
that is wrongheaded.
(1) It is anchored in the false assumption that an input to a >>>>>>>>> termination analyzer can actually do this opposite of whatever >>>>>>>>> value
that this analyzer returns. No one ever notices that this "do the >>>>>>>>> opposite" code is unreachable.
The simulated DDD doesn't matter. HHH returns to DDD, and DDD
then does
the opposite.
HHH is only allowed to report on the behavior that
its actual input actually specifies.
Which is DEFINED to be the bahavior of the program that the input
represents when run.
When you define 5 == 6 you are simply wrong.
That definition contradicts other axioms.
And where did I do that?
When the definition of the halting problem requires
the termination analyzer H to report on behavior besides
the behavior of the input D simulated by H according
to the rules of the computational language that the
input D is encoded within.
Where do you get that behavior to be decided needs to be based on the
partial simulation of the decider.
The behavior of the input to HHH(DDD) is only correctly
measured by the behavior that it actually specifies.
Since DDD <is> a sequence of programming instructions
this behavior must be measured according to its
computer language.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD calls HHH(DDD) HHH is not free to
"interpret" this call as meaning JMP 00002183.
On 5/11/2025 4:02 PM, Richard Damon wrote:
On 5/11/25 12:44 PM, olcott wrote:
On 5/11/2025 6:13 AM, joes wrote:
Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
OK, then, give the page and line numbers from Turing's 1936 paperIt is the whole gist of the entire idea of the halting problem proof >>>>> that is wrongheaded.
where
this alleged mistake was made. I would be surprised indeed if you'd >>>>>> even looked at Turing's paper, far less understood it. Yet you're >>>>>> ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for
insinuations.
(1) It is anchored in the false assumption that an input to a
termination analyzer can actually do this opposite of whatever value >>>>> that this analyzer returns. No one ever notices that this "do the
opposite" code is unreachable.
The simulated DDD doesn't matter. HHH returns to DDD, and DDD then does >>>> the opposite.
HHH is only allowed to report on the behavior that
its actual input actually specifies.
Which is DEFINED to be the bahavior of the program that the input
represents when run.
When you define 5 == 6 you are simply wrong.
That definition contradicts other axioms.
On 5/12/2025 9:17 PM, Mike Terry wrote:
On 12/05/2025 02:25, Richard Heathfield wrote:
On 12/05/2025 01:38, Mike Terry wrote:
On 11/05/2025 18:11, Richard Heathfield wrote:
On 11/05/2025 17:44, olcott wrote:Done that.
Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to get
it to compile and after we've leeched out all the dodgy programming). >>>>
And you still had code left?
It still stops.
Okay.
If the computer cannot correctly decide whether or not DD halts,
The decider says it doesn't stop..
I said "cannot >>>correctly<<< decide".
There are infinitely many deciders that could be given the input.
Some of them decide that particular input correctly, and some
incorrectly.
PO's HHH is one of the ones that decide incorrectly.
When "correctly" means to report on behavior besides
that behavior that the input actually specifies then
it is wrong.
When 2 + 3 = 5 this is determined by the rules
of arithmetic.
When the behavior that the input specifies according
to the rules of the x86 language is non-halting then
HHH must report on this behavior.
HHH cannot compute the mapping from its input to
the behavior of the directly executed DD() for the
same reason that
int sum(int x, int y) { return x + y; }
sum(3,2) can not compute any mapping to sum 5 + 7.
THE INPUT SPECIFIES SOMETHING ELSE.
On 5/12/2025 6:46 AM, dbush wrote:
On 5/12/2025 12:11 AM, olcott wrote:
On 5/11/2025 10:54 PM, dbush wrote:
On 5/11/2025 11:50 PM, olcott wrote:
On 5/11/2025 10:39 PM, dbush wrote:
On 5/11/2025 11:36 PM, olcott wrote:
You try to get away with changing the subject
because you know that you are lying about one
or more steps of DDD emulated by HHH according
to the rules of the x86 language
It is you who are changing the subject away from DDD emulated by
HHH (not one or more steps of DDD emulated by HHH) which you have
admitted for the record is not correct:
I am only referring to the hypothetical infinite
set of pure x86 emulators specified below:
Each of which is processing a distinct, different input.
Changing the input is not allowed.
I am examining all the elements of a infinite set
such that each HHH/DDD pair has a specific fixed form.
And each one has a distinctly different input, and as such the halt
status of one is unrelated to the halt status of another.
Changing the input is not allowed.
In other words you are clueless about mathematical induction.
It is true that when one step of DDD is emulated by HHH that
DDD does not halt.
It is true that when N steps of DDD are emulated by HHH that
DDD does not halt.
On 5/11/2025 11:52 AM, dbush wrote:
On 5/11/2025 12:44 PM, olcott wrote:
On 5/11/2025 6:13 AM, joes wrote:
Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
OK, then, give the page and line numbers from Turing's 1936 paperIt is the whole gist of the entire idea of the halting problem proof >>>>> that is wrongheaded.
where
this alleged mistake was made. I would be surprised indeed if you'd >>>>>> even looked at Turing's paper, far less understood it. Yet you're >>>>>> ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for
insinuations.
(1) It is anchored in the false assumption that an input to a
termination analyzer can actually do this opposite of whatever value >>>>> that this analyzer returns. No one ever notices that this "do the
opposite" code is unreachable.
The simulated DDD doesn't matter. HHH returns to DDD, and DDD then does >>>> the opposite.
HHH is only allowed to report on the behavior that
its actual input actually specifies.
False. It must report on the behavior of the algorithm described by
the input, as per the requirements:
That was always only based on the false assumption
that these behaviors could not possibly diverge.
When I proves that these behaviors DO diverge that
changes everything.
On 5/11/2025 10:54 PM, dbush wrote:
On 5/11/2025 11:50 PM, olcott wrote:
On 5/11/2025 10:39 PM, dbush wrote:
On 5/11/2025 11:36 PM, olcott wrote:
You try to get away with changing the subject
because you know that you are lying about one
or more steps of DDD emulated by HHH according
to the rules of the x86 language
It is you who are changing the subject away from DDD emulated by HHH
(not one or more steps of DDD emulated by HHH) which you have
admitted for the record is not correct:
I am only referring to the hypothetical infinite
set of pure x86 emulators specified below:
Each of which is processing a distinct, different input.
Changing the input is not allowed.
I am examining all the elements of a infinite set
such that each HHH/DDD pair has a specific fixed form.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For all x86 emulators HHH that emulate 1 or more x86 instructions
of an input there does not exist a DDD (matching the above template) correctly emulated by HHH such that DDD reaches its “ret” instruction final halt state.
On 5/11/2025 6:13 AM, joes wrote:
Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
OK, then, give the page and line numbers from Turing's 1936 paper where >>>> this alleged mistake was made. I would be surprised indeed if you'dIt is the whole gist of the entire idea of the halting problem proof
even looked at Turing's paper, far less understood it. Yet you're
ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for insinuations. >>>>
that is wrongheaded.
(1) It is anchored in the false assumption that an input to a
termination analyzer can actually do this opposite of whatever value
that this analyzer returns. No one ever notices that this "do the
opposite" code is unreachable.
The simulated DDD doesn't matter. HHH returns to DDD, and DDD then does
the opposite.
HHH is only allowed to report on the behavior that
its actual input actually specifies.
int sum(int x, int y) { return x + y; }
sum(3,2) is not allowed to report on the sum of 5 + 7
because that is not what its input specifies.
On 5/12/2025 12:30 PM, dbush wrote:
On 5/12/2025 1:16 PM, olcott wrote:
On 5/12/2025 12:07 PM, dbush wrote:
On 5/12/2025 12:54 PM, olcott wrote:
On 5/12/2025 11:41 AM, dbush wrote:
On 5/12/2025 12:19 PM, olcott wrote:
On 5/12/2025 10:06 AM, dbush wrote:
On 5/12/2025 11:04 AM, olcott wrote:
Termination analyzers compute the mapping from their
inputs to the behavior that these inputs actually specify.
False. They compute the mapping from their input to the
behavior of the algorithm described by the input when executed >>>>>>>> directly, as per the requirements:
That is easily proven stupidly wrong.
Category error. Definitions are not proven:
Definitions that contradict other definitions are refuted.
And you haven't shown a conflict with the definition of a solution
to the halting problem:
That you keep ignoring it its not
a matter of me never providing it.
In other words, you agree that no algorithm exists that can compute
the following mapping:
Likewise no algorithm exists that can compute
the square root of a dead rabbit. In neither
case is computation actually limited.
On 5/11/2025 6:07 AM, joes wrote:
Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:
On 5/10/2025 4:44 PM, wij wrote:
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
On 5/10/2025 2:02 PM, wij wrote:
On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
On 5/10/2025 1:37 PM, wij wrote:
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
On 5/10/2025 1:09 PM, wij wrote:
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
On 5/10/2025 12:01 PM, wij wrote:
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
On 5/10/2025 11:29 AM, wij wrote:
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
On 5/10/2025 11:06 AM, wij wrote:
On Sat, 2025-05-10 at 10:45 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
On Sat, 2025-05-10 at 09:33 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
It correctly determines that the halting problem's >>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
...which makes it halt.
The input that has baffled computer scientists for 90 years >>>>>>>>>>>>>>> is merely correctly determined to be non-halting when the >>>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this >>>>>>>>>>>>>>> input according to the rules of the x86 language.
Nobody is baffled. It halts.
I have no problem with that. And, you said HHH merely rejects >>>>>>>>>>>> it as non-halting. You had denied HHH can decide the halting >>>>>>>>>>>> property of any input, except DDD/DD/D..As long as HHH correctly determines the halt status of a single >>>>>>>>>>> input that has no inputs then HHH is a correct termination >>>>>>>>>>> analyzer for that input.
I have no problem with that, but be noticed that the HHH inside >>>>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise, the >>>>>>>>>> 'HHH'
will be an infinite recursive which cannot make any decision, >>>>>>>>>> which you had agreed)
The original set theory is now called naive set theory after itsTraditional logic (or the part mostly used) that won't cause confusion >>>> is more reliable.
mistake has been corrected. Thus the original halting problem proofs >>>>> can now be called the naive halting problem proofs.
The HP doesn't lead to contradictions.
Unless this is done as an actual simulating termination analyzer in aThe halting problem itself remains the same, yet loses its most
important proof.
HP is based on TM. Proof of any other kind other than TM have to be
cautious.
high level language like C and it operates on a 100% complete exactingly >>> precise input specification such as the x86 language too many details
slip through the cracks of vagueness.
TMs are concrete. What details, what vagueness?
There isn't even a common TM language.
If there was a TM language then examining
the details of a termination analyzer would
be like reverse engineering all of the details
of how an operating system works from its
machine code. Humans really need high level
abstractions or they get totally lost.
For example no one ever even noticed that it is 100% impossible toWrong, DDD calls HHH, which returns "non-halting", *and halts*.
derive an input that actually does the opposite of whatever value that
its termination analyzer reports.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
There is no possible way for DD emulated by HHH
according to the rules of the x86 language to
receive the return value from its call to HHH(DDD).
It has been this way for 90 years.
Am Tue, 13 May 2025 03:17:32 +0100 schrieb Mike Terry:
When his HHH simulates DD, it spots a pattern in the simulation which PO
calls his "infinite recursive simulation" pattern. PO believes that
this pattern "specifies non halting behaviour" but it does not, as it
can match for both halting and non-halting computations. Anyhow, PO has
coded HHH to abort and return non-halting if it sees that pattern. He
really really really believes that pattern "specifies non halting",
despite observing with his own eyes DD halting when called directly!
The rest of his arguments are just attempts to justify why HHH is
"correct" to decide non-halting, despite DD halting. They generally
amount to something like "during simulation my HHH detected non-halting
behaviour, so it is correct to decide non-halting".
Can you remind me how it matches halting computations? IIRC it looks
for invocations of the same function (across simulation levels, mind)
without conditional statements inbetween. Or is the impossibility of recursive simulation the only reason for false positives?
On 5/13/2025 12:46 PM, Mike Terry wrote:
On 13/05/2025 10:01, joes wrote:
Am Tue, 13 May 2025 03:17:32 +0100 schrieb Mike Terry:
When his HHH simulates DD, it spots a pattern in the simulation
which PO
calls his "infinite recursive simulation" pattern. PO believes that
this pattern "specifies non halting behaviour" but it does not, as it
can match for both halting and non-halting computations. Anyhow, PO
has
coded HHH to abort and return non-halting if it sees that pattern. He >>>> really really really believes that pattern "specifies non halting",
despite observing with his own eyes DD halting when called directly!
The rest of his arguments are just attempts to justify why HHH is
"correct" to decide non-halting, despite DD halting. They generally
amount to something like "during simulation my HHH detected non-halting >>>> behaviour, so it is correct to decide non-halting".
Can you remind me how it matches halting computations? IIRC it looks
for invocations of the same function (across simulation levels, mind)
without conditional statements inbetween. Or is the impossibility of
recursive simulation the only reason for false positives?
Recursive simulation is not itself the problem. If we set aside some
design errors like the use of mutable global data to communicate
across simulation levels (making simulations follow a different code
path to directly executed code), then in principle PO's x86utm could
handle nested simulation in an ok way, at least for the purposes PO
needs. His x86utm itself does cater for simulating a simulation of a
simulation and so on, at the instruction level.
Thanks for clearing that up. Everyone else
simply baselessly argued the opposite not
even knowing that they had no basis.
Your description of the matching process is pretty much right - I'll
need to check in halt7.c ...
Right, so the matching process goes like this:
- simulated instructions (from all simulation levels) are added to a
global trace table, but ONLY IF THEY ARE FROM DD, i.e. their address >> puts them physically inside C function DD.
Trace entries from HHH and routines called from HHH are discarded.
- when a call instruction is simulated the trace table is scanned
backwards
looking for a "matching" entry: that is, another call from the same >> address, and to the same target address.
- if one is found, a check is made for whether there were any
conditional
branch instructions in the trace table between the matching calls
[remember, the trace table only includes instructions inside C
function DD]
- if no conditional branches were encountered, the simulation is aborted >> with message "Infinite Recursion Detected Simulation Stopped\n\n",
and the simulating HHH decides non-halting.
- if no match is found, simulation continues as normal.
That is all exactly correct.
The global trace table does not record the simulation level for an
entry, so the matching process is agnostic when it comes to simulation
levels. Also note there are many conditional branch instructions in
HHH which would prevent matches occuring if we were to include HHH
instructions in the examined trace!
Yes that is true. The program-under-test is not the test-program.
When HHH is reporting on the behavior of the finite string of x86
machine code specified by DD, HHH correctly reports that its input
DD cannot possibly reach its own final halt state.
The input being decided by HHH(DD) includes DD
calling its own emulator in recursive simulation.
The input being decided by HHH1(DD) DOES NOT INCLUDE
DD calling its own emulator in recursive simulation.
Everyone here thinks that they can simply ignore
that entirely on the basis that this issue was never
raised in any textbooks.
For completeness, there is also a similar looking test relating to
unconditional branches (jmp and the likes) aimed at detecting loops
rather than recursion. This test does not match for input DD.
Regards,
Mike.
If on a real system an input tried to fool the denial-of-service-attack detector IT WOULD FAIL.No, the goal is not to make HHH run forever. It would not fail at
Prior to my work a denial-of-service-attack detector WOULD FAIL. It
would not know to reject DDD.
On 5/16/2025 10:38 AM, joes wrote:
Am Sun, 11 May 2025 19:51:27 -0500 schrieb olcott:
If on a real system an input tried to fool the denial-of-service-attackNo, the goal is not to make HHH run forever. It would not fail at
detector IT WOULD FAIL.
Prior to my work a denial-of-service-attack detector WOULD FAIL. It
would not know to reject DDD.
terminating contrary to HHH's result.
The goal of the counter-example input to the HP
proofs has always been to make halting undecidable
on this input. A simulating termination analyzer
fixes that.
On 5/16/2025 10:38 AM, joes wrote:
Am Sun, 11 May 2025 19:51:27 -0500 schrieb olcott:
If on a real system an input tried to fool the denial-of-service-attackNo, the goal is not to make HHH run forever. It would not fail at
detector IT WOULD FAIL.
Prior to my work a denial-of-service-attack detector WOULD FAIL. It
would not know to reject DDD.
terminating contrary to HHH's result.
The goal of the counter-example input to the HP
proofs has always been to make halting undecidable
on this input. A simulating termination analyzer
fixes that.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 13:53:47 |
| Calls: | 9,711 |
| Calls today: | 1 |
| Files: | 13,740 |
| Messages: | 6,181,696 |