typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
void Infinite_Recursion()
{
 Infinite_Recursion();
 return;
}
void DDD()
{
 HHH(DDD);
 return;
}
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
void Infinite_Recursion()
{
 Infinite_Recursion();
 return;
}
void DDD()
{
 HHH(DDD);
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
void Infinite_Recursion()
{
 Infinite_Recursion();
 return;
}
void DDD()
{
 HHH(DDD);
 return;
}
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Op 11.mrt.2025 om 00:41 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
All competent C programmers see that HHH correctly reports that
it cannot possibly reach the 'return' instruction.
On 3/10/2025 9:21 PM, Richard Damon wrote:
On 3/10/25 7:41 PM, olcott wrote:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Problem: DD Isn't a program, and if you try to compile it, you will get
an undiefined symbol HHH.
HHH need not be a program for this correct thought experiment.
The only detail required to know about HHH is that it correctly
emulates N steps of DD.
Op 11.mrt.2025 om 00:41 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
void Infinite_Recursion()
{
 Infinite_Recursion();
 return;
}
void DDD()
{
 HHH(DDD);
 return;
}
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
All competent C programmers see that HHH correctly reports that it
cannot possibly reach the 'return' instruction.
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
On 3/10/2025 9:21 PM, Richard Damon wrote:
On 3/10/25 7:41 PM, olcott wrote:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Problem: DD Isn't a program, and if you try to compile it, you will
get an undiefined symbol HHH.
HHH need not be a program for this correct thought experiment.
The only detail required to know about HHH is that it correctly
emulates N steps of DD.
On 3/11/2025 5:01 AM, Richard Heathfield wrote:
And yet I can't even /see/ HHH, let alone judge what it does or
does not do correctly. All I see is a call to it.
It is stipulated that HHH correctly emulates N
steps of the x86 machine code of its input functions.
This may or may not include HHH emulating itself
emulating an input.
And ld concurs. It can't see HHH either.
I suggest that Mr Olcott should supply the missing source code
if he wishes to be taken seriously.
Not required for the above thought experience where
every relevant behavior has been fully specified. This
is merely another lame attempt on your part to perpetually
dodge the point.
On 3/11/2025 5:28 AM, Mikko wrote:
On 2025-03-10 23:41:13 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Every competent programmer knows that the information given is
insufficient to determine whether HHH emulates at all, and whether
it emulates correctly if it does.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Whether HHH does see those patterns cannot be inferred from the
information
given. Only about DDD one can see that it halts if HHH returns.
In addition,
the given information does not tell whether HHH can see
patterns that are
not there.
How many competent programmers you have asked?
Two C programmers with masters degrees in computer science
agree that DDD correctly emulated by HHH cannot possibly
reach its own "return" instruction and terminate normally.
On 3/11/2025 5:30 AM, Mikko wrote:
On 2025-03-11 02:27:42 +0000, olcott said:
On 3/10/2025 9:21 PM, Richard Damon wrote:
On 3/10/25 7:41 PM, olcott wrote:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Problem: DD Isn't a program, and if you try to compile it,
you will get an undiefined symbol HHH.
HHH need not be a program for this correct thought experiment.
The only detail required to know about HHH is that it correctly
emulates N steps of DD.
Wrong. One nneds also to know how a call to HHH is interpreted,
in particular
if HHH is not a program.
You are trying to get away with saying that
one C function cannot call another C function
according to the semantics of the C language?
On 3/11/2025 5:30 AM, Mikko wrote:
On 2025-03-11 02:27:42 +0000, olcott said:
On 3/10/2025 9:21 PM, Richard Damon wrote:
On 3/10/25 7:41 PM, olcott wrote:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Problem: DD Isn't a program, and if you try to compile it, you will get >>>> an undiefined symbol HHH.
HHH need not be a program for this correct thought experiment.
The only detail required to know about HHH is that it correctly
emulates N steps of DD.
Wrong. One nneds also to know how a call to HHH is interpreted, in particular
if HHH is not a program.
You are trying to get away with saying that
one C function cannot call another C function
according to the semantics of the C language?
On 3/11/2025 5:36 AM, Mikko wrote:
On 2025-03-11 08:55:22 +0000, Fred. Zwarts said:
Op 11.mrt.2025 om 00:41 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
void Infinite_Recursion()
{
 Infinite_Recursion();
 return;
}
void DDD()
{
 HHH(DDD);
 return;
}
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
All competent C programmers see that HHH correctly reports that it
cannot possibly reach the 'return' instruction.
How may competent C programmers did you ask?
Two C programmers with masters degrees in computer
science both agreed that DDD correctly emulated by HHH
cannot possibly reach its own "return" instruction and
terminate normally.
On 3/11/2025 5:01 AM, Richard Heathfield wrote:
On 11/03/2025 08:55, Fred. Zwarts wrote:
Op 11.mrt.2025 om 00:41 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
All competent C programmers see that HHH correctly reports that it
cannot possibly reach the 'return' instruction.
First, my credentials. I've been programming in C for over 35 years;
I'm told that my book on C has been used on two undergraduate Comp Sci
courses (one in the States and one in the UK); and I have my Knuth
cheque. I don't claim to be any kind of programming guru, but I hope I
do not overstate the case when I suggest that I can be regarded as
competent not just as a programmer but specifically in the C language.
And yet I can't even /see/ HHH, let alone judge what it does or does
not do correctly. All I see is a call to it.
It is stipulated that HHH correctly emulates N
steps of the x86 machine code of its input functions.
This may or may not include HHH emulating itself
emulating an input.
On 3/11/2025 5:28 AM, Mikko wrote:
On 2025-03-10 23:41:13 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Every competent programmer knows that the information given is
insufficient to determine whether HHH emulates at all, and whether
it emulates correctly if it does.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Whether HHH does see those patterns cannot be inferred from the information >> given. Only about DDD one can see that it halts if HHH returns. In addition, >> the given information does not tell whether HHH can see patterns that are
not there.
How many competent programmers you have asked?
Two C programmers with masters degrees in computer science
agree that DDD correctly emulated by HHH cannot possibly
reach its own "return" instruction and terminate normally.
On 2025-03-11 13:26:55 +0000, olcott said:
On 3/11/2025 5:01 AM, Richard Heathfield wrote:
On 11/03/2025 08:55, Fred. Zwarts wrote:
Op 11.mrt.2025 om 00:41 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
All competent C programmers see that HHH correctly reports
that it cannot possibly reach the 'return' instruction.
First, my credentials. I've been programming in C for over 35
years; I'm told that my book on C has been used on two
undergraduate Comp Sci courses (one in the States and one in
the UK); and I have my Knuth cheque. I don't claim to be any
kind of programming guru, but I hope I do not overstate the
case when I suggest that I can be regarded as competent not
just as a programmer but specifically in the C language.
And yet I can't even /see/ HHH, let alone judge what it does
or does not do correctly. All I see is a call to it.
It is stipulated that HHH correctly emulates N
steps of the x86 machine code of its input functions.
This may or may not include HHH emulating itself
emulating an input.
The stipulation does not include the value of N (although a
reasonable
interpretation is that it is finite). Nor does the stipulation
specify
what HHH does after the emulation.
On 3/11/2025 5:28 AM, Mikko wrote:
On 2025-03-10 23:41:13 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Every competent programmer knows that the information given is
insufficient to determine whether HHH emulates at all, and whether
it emulates correctly if it does.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Whether HHH does see those patterns cannot be inferred from the
information
given. Only about DDD one can see that it halts if HHH returns. In
addition,
the given information does not tell whether HHH can see patterns that are
not there.
How many competent programmers you have asked?
Two C programmers with masters degrees in computer science
agree that DDD correctly emulated by HHH cannot possibly
reach its own "return" instruction and terminate normally.
On 3/11/2025 11:41 AM, Fred. Zwarts wrote:
Op 11.mrt.2025 om 14:31 schreef olcott:
On 3/11/2025 5:28 AM, Mikko wrote:
On 2025-03-10 23:41:13 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Every competent programmer knows that the information given is
insufficient to determine whether HHH emulates at all, and whether
it emulates correctly if it does.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Whether HHH does see those patterns cannot be inferred from the
information
given. Only about DDD one can see that it halts if HHH returns. In
addition,
the given information does not tell whether HHH can see patterns
that are
not there.
How many competent programmers you have asked?
Two C programmers with masters degrees in computer science
agree that DDD correctly emulated by HHH cannot possibly
reach its own "return" instruction and terminate normally.
It is clear that that HHH cannot possibly simulate itself up to the end.
I say that the cat is black and you say
No you are wrong because the dog is white.
You still sound like Richard Damon whom is unable to
understand that semantic tautologies are irrefutable.
When N steps of the above the above functions are
correctly emulated by HHH
(this is all that you need to know able HHH) then
none of them reach their "return" instruction and
terminate normally.
HHH can and does emulate itself emulating DDD and DD.
On 3/11/2025 8:42 AM, Richard Heathfield wrote:
On 11/03/2025 13:26, olcott wrote:int HHH(ptr P);
On 3/11/2025 5:01 AM, Richard Heathfield wrote:
<snip>
And yet I can't even /see/ HHH, let alone judge what it does
or does not do correctly. All I see is a call to it.
It is stipulated that HHH correctly emulates N
steps of the x86 machine code of its input functions.
This may or may not include HHH emulating itself
emulating an input.typedef void (*ptr)();
void Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
void Infinite_Recursion()
{
 Infinite_Recursion();
 return;
}
void DDD()
{
 HHH(DDD);
 return;
}
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Not good enough. Show us the code. It may contain a bug that
you haven't spotted.
The above is a semantic tautology thus making bugs
impossible.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
I suggest that Mr Olcott should supply the missing source
code if he wishes to be taken seriously.
Not required for the above thought experience where
every relevant behavior has been fully specified. This
is merely another lame attempt on your part to perpetually
dodge the point.
Dodge what point? You must be confusing me with someone else,
because I have no idea what your point is, unless it's to
demonstrate that you have read up on the Halting Problem. Jolly
good tick VG, but it's a done deal, it's in the literature, and
you're almost a century too late.
If you as not Richard Damon pretending to be someone
else, great!!!
On 11/03/2025 13:31, olcott wrote:
On 3/11/2025 5:28 AM, Mikko wrote:
On 2025-03-10 23:41:13 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Every competent programmer knows that the information given is
insufficient to determine whether HHH emulates at all, and whether
it emulates correctly if it does.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Whether HHH does see those patterns cannot be inferred from the information >>> given. Only about DDD one can see that it halts if HHH returns. In addition,
the given information does not tell whether HHH can see patterns that are >>> not there.
How many competent programmers you have asked?
Two C programmers with masters degrees in computer science
agree that DDD correctly emulated by HHH cannot possibly
reach its own "return" instruction and terminate normally.
Bring 'em on. Perhaps /they/ have the source to HHH, because without it you don't have anything.
(And btw whatever it is you claim to have is far from clear, because all I've seen so far is an
attempt to express the Halting Problem in C and pseuodocode, where the pseudocode reads: HHH(){
magic happens }
Finally, if you really want to see the actual HHH code, its in
the halt7.c file (along with DDD) that PO provides links to from
time to time. However it's not very illuminating due to
bugs/design errors/misunderstandings which only serve to
obfuscate PO's errors in thinking.
On Tue, 2025-03-11 at 18:23 +0000, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in
the halt7.c file (along with DDD) that PO provides links to from
time to time. However it's not very illuminating due to
bugs/design errors/misunderstandings which only serve to
obfuscate PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
Thank you for a spirited attempt to be cogent - or at least as
cogent as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH()
correctly diagnoses some easy functions, such as these:
int rha(unsigned int i)
{
  while(--i > 0)while(--i > 0);
  return 0;
}
int rhb(unsigned int i)
{
  if(i > 0)
  {
    rhb(i/10);
  }
  return putchar(i + '0');
}
int rhc(unsigned int i)
{
  typedef int(*pf)(unsigned int);
  pf arr[3] = {rha, rhb, rhc};
  return arr[i % 3];
}
and other such obvious tests.
HHH(), the procedure that decides whether a program halts, is
required to work for all programs and all inputs. Does it work on
those cited above? I'm guessing it doesn't.
No TM can simulate itself.
Proving HP in this way is dead end.
On Tue, 2025-03-11 at 19:06 +0000, Richard Heathfield wrote:
On 11/03/2025 18:33, wij wrote:
On Tue, 2025-03-11 at 18:23 +0000, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in
the halt7.c file (along with DDD) that PO provides links to from
time to time. However it's not very illuminating due to
bugs/design errors/misunderstandings which only serve to
obfuscate PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
Thank you for a spirited attempt to be cogent - or at least as
cogent as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH()
correctly diagnoses some easy functions, such as these:
int rha(unsigned int i)
{
   while(--i > 0)while(--i > 0);
   return 0;
}
int rhb(unsigned int i)
{
   if(i > 0)
   {
     rhb(i/10);
   }
   return putchar(i + '0');
}
int rhc(unsigned int i)
{
   typedef int(*pf)(unsigned int);
   pf arr[3] = {rha, rhb, rhc};
   return arr[i % 3];
}
and other such obvious tests.
HHH(), the procedure that decides whether a program halts, is
required to work for all programs and all inputs. Does it work on
those cited above? I'm guessing it doesn't.
No TM can simulate itself.
It doesn't have to. For a start, it can take source code as input
and analyse it in much the same way that a compiler does.
SO, what is 'it', the decider?
(note: its input is the source of itself)
there is no need to
see the code.
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in the halt7.c file (along with DDD)
that PO provides links to from time to time. However it's not very illuminating due to
bugs/design errors/misunderstandings which only serve to obfuscate PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
Thank you for a spirited attempt to be cogent - or at least as cogent as it is possible to be in the
circumstances!
I think PO's first step must be to demonstrate that HHH() correctly diagnoses some easy functions,
such as these:
int rha(unsigned int i)
{
while(--i > 0)while(--i > 0);
return 0;
}
int rhb(unsigned int i)
{
if(i > 0)
{
rhb(i/10);
}
return putchar(i + '0');
}
int rhc(unsigned int i)
{
typedef int(*pf)(unsigned int);
pf arr[3] = {rha, rhb, rhc};
return arr[i % 3];
}
and other such obvious tests.
HHH(), the procedure that decides whether a program halts, is required to work for all programs and
all inputs. Does it work on those cited above? I'm guessing it doesn't.
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in
the halt7.c file (along with DDD) that PO provides links to
from time to time. However it's not very illuminating due to
bugs/design errors/misunderstandings which only serve to
obfuscate PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as
cogent as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH()
correctly diagnoses some easy functions, such as these:
Not really necessary - PO is not trying or claiming to have a
(full) halt decider.
Originally his claim was that he had a program which worked for
the counter-example TM used in the common (e.g. Linz book)
proof. Such a program is impossible, as Linz and others prove,
so having a program H and its corresponding "counter-example" D,
such that H correctly decides D, would certainly show that the
Linz proof is wrong. His claim was always that he had "refuted
the HP proof", or sometimes that he had refuted the HP theorem
itself although he's been told dozens of times that there are
many alternative proofs for the result.
[As it turned out, PO's D(D) halted when run under his x86utm
environment, while H(D,D) which is required to return the halting
status of computation D(D) returned 0 (=non-halting). That is
exactly what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one input,
which is the D constructed from H by the usual method (basically
D calls H to see what H claims is the halting behaviour, then
does the opposite - I'm not sure if you're familiar with the
proof, but imagine you would be given your background).
His decider H works (subject to design errors/bugs and so on) by single-stepping a simulation of its input computation, and
monitoring for conditions that PO believes indicate
non-termination. He tests a couple of conditions, and when one
of those matches H aborts and returns non-halting. Alternatively
if the simulation halts normally, H returns halting. The problem
is (at least) one of his non-halting-behaviour tests is invalid,
matching during the simulation of DDD, which is a halting
computation.
It is true that sometimes his tests match and the input is indeed non-halting. PO quotes this as evidence that his tests "work",
so when the decided non-halting for a halting computation they
must be correct and the halting computation in fact is
non-halting because it "exhibited non-halting behaviour"!
int rha(unsigned int i)
{
  while(--i > 0)while(--i > 0);
  return 0;
}
int rhb(unsigned int i)
{
  if(i > 0)
  {
    rhb(i/10);
  }
  return putchar(i + '0');
}
int rhc(unsigned int i)
{
  typedef int(*pf)(unsigned int);
  pf arr[3] = {rha, rhb, rhc};
  return arr[i % 3];
}
and other such obvious tests.
HHH(), the procedure that decides whether a program halts, is
required to work for all programs and all inputs. Does it work
on those cited above? I'm guessing it doesn't.
I would have to think a bit about your examples - or more likely
just try them out (which I'm not motivated to do).
PO's
non-halting tests involve observing loops and conditional
branches in some combination. The major problem for his HHH/DDD
is with the simulation aspect - the tests can match when the same
code address is reached but across completely different
simulation levels. PO does not appreciate that tests which
/might/ work in a non-simulation setting, could go horribly wrong
when simulation is involved... (so your tests aren't especially
relevant for PO's code logic - and as I said there is only the
one case that he really has to handle.)
On 3/11/2025 8:58 AM, Mikko wrote:
On 2025-03-11 13:34:34 +0000, olcott said:
On 3/11/2025 5:30 AM, Mikko wrote:
On 2025-03-11 02:27:42 +0000, olcott said:
On 3/10/2025 9:21 PM, Richard Damon wrote:
On 3/10/25 7:41 PM, olcott wrote:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Problem: DD Isn't a program, and if you try to compile it, you
will get an undiefined symbol HHH.
HHH need not be a program for this correct thought experiment.
The only detail required to know about HHH is that it correctly
emulates N steps of DD.
Wrong. One nneds also to know how a call to HHH is interpreted, in
particular
if HHH is not a program.
You are trying to get away with saying that
one C function cannot call another C function
according to the semantics of the C language?
You are trying to get away with a distraction by lying?
Calling is possible if the functions are in the same file or if they
are linked together and the called function is global.
What is not possible is to determine the consequnces of such call
without knowing enough about the called function. As you would
know if you knew anything about programming.
I specified that the functions are correctly emulated
by HHH (by whatever means) and added that for HHH(DD)
and HHH(DDD) HHH does emulate itself emulating these
inputs to an arbitrary recursive depth.
He won't be interested in your cases. In the end he is just
interested in the one input case which he feels "refutes the Linz
proof".
On 11/03/2025 20:37, Mike Terry wrote:
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in the halt7.c file (along with DDD)
that PO provides links to from time to time. However it's not very illuminating due to
bugs/design errors/misunderstandings which only serve to obfuscate PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as cogent as it is possible to be in
the circumstances!
I think PO's first step must be to demonstrate that HHH() correctly diagnoses some easy
functions, such as these:
Not really necessary - PO is not trying or claiming to have a (full) halt decider.
In which case he has nothing. And I'll stipulate that, so he can't even argue back.
Originally his claim was that he had a program which worked for the counter-example TM used in the
common (e.g. Linz book) proof. Such a program is impossible, as Linz and others prove, so having
a program H and its corresponding "counter-example" D, such that H correctly decides D, would
certainly show that the Linz proof is wrong. His claim was always that he had "refuted the HP
proof", or sometimes that he had refuted the HP theorem itself although he's been told dozens of
times that there are many alternative proofs for the result.
He's beginning to remind me of a few other Usenet characters.
[As it turned out, PO's D(D) halted when run under his x86utm environment, while H(D,D) which is
required to return the halting status of computation D(D) returned 0 (=non-halting). That is
exactly what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one input, which is the D constructed from
H by the usual method (basically D calls H to see what H claims is the halting behaviour, then
does the opposite - I'm not sure if you're familiar with the proof, but imagine you would be given
your background).
It's in GEB, so I first read it roughly a thousand years ago.
I would take issue with one thing though - if his decider doesn't handle arbitrary programs as input
and correctly diagnose them, he is addressing an entirely different problem.
His decider H works (subject to design errors/bugs and so on) by single-stepping a simulation of
its input computation, and monitoring for conditions that PO believes indicate non-termination.
He tests a couple of conditions, and when one of those matches H aborts and returns non-halting.
Alternatively if the simulation halts normally, H returns halting. The problem is (at least) one
of his non-halting-behaviour tests is invalid, matching during the simulation of DDD, which is a
halting computation.
It is true that sometimes his tests match and the input is indeed non-halting. PO quotes this as
evidence that his tests "work", so when the decided non-halting for a halting computation they
must be correct and the halting computation in fact is non-halting because it "exhibited
non-halting behaviour"!
Did he pay out a ball of twine behind him?
int rha(unsigned int i)
{
while(--i > 0)while(--i > 0);
return 0;
}
int rhb(unsigned int i)
{
if(i > 0)
{
rhb(i/10);
}
return putchar(i + '0');
}
int rhc(unsigned int i)
{
typedef int(*pf)(unsigned int);
pf arr[3] = {rha, rhb, rhc};
return arr[i % 3];
}
and other such obvious tests.
HHH(), the procedure that decides whether a program halts, is required to work for all programs
and all inputs. Does it work on those cited above? I'm guessing it doesn't. >>>
I would have to think a bit about your examples - or more likely just try them out (which I'm not
motivated to do).
I knew you were smart. :-)
PO's non-halting tests involve observing loops and conditional branches in some combination. The
major problem for his HHH/DDD is with the simulation aspect - the tests can match when the same
code address is reached but across completely different simulation levels. PO does not appreciate
that tests which /might/ work in a non-simulation setting, could go horribly wrong when simulation
is involved... (so your tests aren't especially relevant for PO's code logic - and as I said
there is only the one case that he really has to handle.)
I must disagree. HP is about detecting whether an ***arbitrary*** program (and to show willing I'll
buy 'function' for 'program') will terminate. Special cases need not apply.
If his decision procedure cannot handle arbitrary functions, he isn't addressing HP.
Those functions I rattled off weren't intended to be particularly hard exercises - just
opportunities for a proof of concept. I don't expect him to avail himself of that opportunity
because I don't believe him to be arguing in good faith.
On 3/11/2025 8:58 AM, Mikko wrote:
On 2025-03-11 13:34:34 +0000, olcott said:
On 3/11/2025 5:30 AM, Mikko wrote:
On 2025-03-11 02:27:42 +0000, olcott said:
On 3/10/2025 9:21 PM, Richard Damon wrote:
On 3/10/25 7:41 PM, olcott wrote:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Problem: DD Isn't a program, and if you try to compile it, you will get >>>>>> an undiefined symbol HHH.
HHH need not be a program for this correct thought experiment.
The only detail required to know about HHH is that it correctly
emulates N steps of DD.
Wrong. One nneds also to know how a call to HHH is interpreted, in particular
if HHH is not a program.
You are trying to get away with saying that
one C function cannot call another C function
according to the semantics of the C language?
You are trying to get away with a distraction by lying?
Calling is possible if the functions are in the same file or if they
are linked together and the called function is global.
What is not possible is to determine the consequnces of such call
without knowing enough about the called function. As you would
know if you knew anything about programming.
I specified that the functions are correctly emulated
by HHH (by whatever means)
and added that for HHH(DD) and HHH(DDD) HHH does emulate itself
emulating these inputs to an arbitrary recursive depth.
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in the
halt7.c file (along with DDD) that PO provides links to from time to
time. However it's not very illuminating due to bugs/design errors/
misunderstandings which only serve to obfuscate PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as cogent
as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH() correctly
diagnoses some easy functions, such as these:
Not really necessary - PO is not trying or claiming to have a (full)
halt decider.
Originally his claim was that he had a program which worked for the counter-example TM used in the common (e.g. Linz book) proof. Such a program is impossible, as Linz and others prove, so having a program H
and its corresponding "counter-example" D, such that H correctly decides
D, would certainly show that the Linz proof is wrong. His claim was
always that he had "refuted the HP proof", or sometimes that he had
refuted the HP theorem itself although he's been told dozens of times
that there are many alternative proofs for the result.
[As it turned out, PO's D(D) halted when run under his x86utm
environment, while H(D,D) which is required to return the halting status
of computation D(D) returned 0 (=non-halting). That is exactly what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one input, which
is the D constructed from H by the usual method (basically D calls H to
see what H claims is the halting behaviour, then does the opposite - I'm
not sure if you're familiar with the proof, but imagine you would be
given your background).
His decider H works (subject to design errors/bugs and so on) by single- stepping a simulation of its input computation, and monitoring for
conditions that PO believes indicate non-termination. He tests a couple
of conditions, and when one of those matches H aborts and returns non- halting. Alternatively if the simulation halts normally, H returns
halting. The problem is (at least) one of his non-halting-behaviour
tests is invalid, matching during the simulation of DDD, which is a
halting computation.
It is true that sometimes his tests match and the input is indeed non- halting. PO quotes this as evidence that his tests "work", so when the decided non-halting for a halting computation they must be correct and
the halting computation in fact is non-halting because it "exhibited non-halting behaviour"!
int rha(unsigned int i)
{
  while(--i > 0)while(--i > 0);
  return 0;
}
int rhb(unsigned int i)
{
  if(i > 0)
  {
    rhb(i/10);
  }
  return putchar(i + '0');
}
int rhc(unsigned int i)
{
  typedef int(*pf)(unsigned int);
  pf arr[3] = {rha, rhb, rhc};
  return arr[i % 3];
}
and other such obvious tests.
HHH(), the procedure that decides whether a program halts, is required
to work for all programs and all inputs. Does it work on those cited
above? I'm guessing it doesn't.
I would have to think a bit about your examples - or more likely just
try them out (which I'm not motivated to do). PO's non-halting tests involve observing loops and conditional branches in some combination.
The major problem for his HHH/DDD is with the simulation aspect - the
tests can match when the same code address is reached but across
completely different simulation levels. PO does not appreciate that
tests which /might/ work in a non-simulation setting, could go horribly
wrong when simulation is involved... (so your tests aren't especially relevant for PO's code logic - and as I said there is only the one case
that he really has to handle.)
Mike.
On 3/11/2025 9:02 AM, Mikko wrote:
On 2025-03-11 13:26:55 +0000, olcott said:
On 3/11/2025 5:01 AM, Richard Heathfield wrote:
On 11/03/2025 08:55, Fred. Zwarts wrote:
Op 11.mrt.2025 om 00:41 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
All competent C programmers see that HHH correctly reports that it
cannot possibly reach the 'return' instruction.
First, my credentials. I've been programming in C for over 35 years;
I'm told that my book on C has been used on two undergraduate Comp Sci >>>> courses (one in the States and one in the UK); and I have my Knuth
cheque. I don't claim to be any kind of programming guru, but I hope I >>>> do not overstate the case when I suggest that I can be regarded as
competent not just as a programmer but specifically in the C language. >>>>
And yet I can't even /see/ HHH, let alone judge what it does or does
not do correctly. All I see is a call to it.
It is stipulated that HHH correctly emulates N
steps of the x86 machine code of its input functions.
This may or may not include HHH emulating itself
emulating an input.
The stipulation does not include the value of N (although a reasonable
interpretation is that it is finite). Nor does the stipulation specify
what HHH does after the emulation.
It need not those are totally
irrelevant to the primary point:
When HHH correctly emulates N steps of the
above functions none of these functions can
possibly reach their own "return" instruction
and terminate normally.
For HHH(DDD) and HHH(DD) it is stipulated that
HHH does correctly emulate itself emulating
these inputs.
On 3/11/2025 8:46 AM, Richard Heathfield wrote:
On 11/03/2025 13:31, olcott wrote:
On 3/11/2025 5:28 AM, Mikko wrote:
On 2025-03-10 23:41:13 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Every competent programmer knows that the information given is
insufficient to determine whether HHH emulates at all, and whether
it emulates correctly if it does.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Whether HHH does see those patterns cannot be inferred from the information
given. Only about DDD one can see that it halts if HHH returns. In addition,
the given information does not tell whether HHH can see patterns that are >>>> not there.
How many competent programmers you have asked?
Two C programmers with masters degrees in computer science
agree that DDD correctly emulated by HHH cannot possibly
reach its own "return" instruction and terminate normally.
Bring 'em on. Perhaps /they/ have the source to HHH, because without it
you don't have anything. (And btw whatever it is you claim to have is
far from clear, because all I've seen so far is an attempt to express
the Halting Problem in C and pseuodocode, where the pseudocode reads:
HHH(){ magic happens }
You still sound like Richard Damon whom is unable to
understand that semantic tautologies are irrefutable.
When N steps of the above the above functions are
correctly emulated by HHH
(this is all that you need to know able HHH) then
none of them reach their "return" instruction and
terminate normally.
HHH can and does emulate itself emulating DDD and DD.
On 2025-03-11 17:07:38 +0000, olcott said:
You still sound like Richard Damon whom is unable to
understand that semantic tautologies are irrefutable.
That a false claim about one person is similar to a false
claim about another is not suffecent ro conclude or even
sustpect that they are the same. A better measure is how meny
indignificant typos each makes.
On Tue, 2025-03-11 at 18:23 +0000, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in> > the
halt7.c file (along with DDD) that PO provides links to from> > time to
time. However it's not very illuminating due to> > bugs/design
errors/misunderstandings which only serve to> > obfuscate PO's errors
in thinking.
[I've now seen the code. Oh deary deary me.]
Thank you for a spirited attempt to be cogent - or at least as> cogent
as it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH()> correctly
diagnoses some easy functions, such as these:
int rha(unsigned int i)
{
  while(--i > 0)while(--i > 0);
  return 0;
}
int rhb(unsigned int i)
{
  if(i > 0)
  {
    rhb(i/10);
  }
  return putchar(i + '0');
}
int rhc(unsigned int i)
{
  typedef int(*pf)(unsigned int);
  pf arr[3] = {rha, rhb, rhc};
  return arr[i % 3];
}
and other such obvious tests.
HHH(), the procedure that decides whether a program halts, is> required
to work for all programs and all inputs. Does it work on> those cited
above? I'm guessing it doesn't.
No TM can simulate itself. Proving HP in this way is dead end.
On 2025-03-11 18:23:24 +0000, Richard Heathfield said:
int rhc(unsigned int i)
{
  typedef int(*pf)(unsigned int);
  pf arr[3] = {rha, rhb, rhc};
  return arr[i % 3];
The return instruction has wrong type.
int rhc(unsigned int i)
{
typedef int(*pf)(unsigned int);
pf arr[3] = {rha, rhb, rhc};
return arr[i % 3];
}
On 3/11/2025 9:10 AM, Mikko wrote:
On 2025-03-11 13:31:21 +0000, olcott said:
On 3/11/2025 5:28 AM, Mikko wrote:
On 2025-03-10 23:41:13 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Every competent programmer knows that the information given is
insufficient to determine whether HHH emulates at all, and whether
it emulates correctly if it does.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Whether HHH does see those patterns cannot be inferred from the information
given. Only about DDD one can see that it halts if HHH returns. In addition,
the given information does not tell whether HHH can see patterns that are >>>> not there.
How many competent programmers you have asked?
Two C programmers with masters degrees in computer science
agree that DDD correctly emulated by HHH cannot possibly
reach its own "return" instruction and terminate normally.
A masters degree in computer science does not guarantee any
competence in C programming.
Two answers, even if similar, is not statistically significant.
Mere competence in C completely proves my point.
When HHH correctly emulates N steps of the
above functions none of these functions can
possibly reach their own "return" instruction
and terminate normally.
For HHH(DDD) and HHH(DD) it is stipulated that
HHH does correctly emulate itself emulating
these inputs.
Op 11.mrt.2025 om 21:37 schreef Mike Terry:
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in the halt7.c file (along with DDD)
that PO provides links to from time to time. However it's not very illuminating due to
bugs/design errors/ misunderstandings which only serve to obfuscate PO's errors in thinking.
[I've now seen the code. Oh deary deary me.]
:)
Thank you for a spirited attempt to be cogent - or at least as cogent as it is possible to be in
the circumstances!
I think PO's first step must be to demonstrate that HHH() correctly diagnoses some easy
functions, such as these:
Not really necessary - PO is not trying or claiming to have a (full) halt decider.
Originally his claim was that he had a program which worked for the counter-example TM used in the
common (e.g. Linz book) proof. Such a program is impossible, as Linz and others prove, so having
a program H and its corresponding "counter-example" D, such that H correctly decides D, would
certainly show that the Linz proof is wrong. His claim was always that he had "refuted the HP
proof", or sometimes that he had refuted the HP theorem itself although he's been told dozens of
times that there are many alternative proofs for the result.
[As it turned out, PO's D(D) halted when run under his x86utm environment, while H(D,D) which is
required to return the halting status of computation D(D) returned 0 (=non-halting). That is
exactly what the Linz proofs claim!]
Anyhow, his decider only /has/ to correctly decide the one input, which is the D constructed from
H by the usual method (basically D calls H to see what H claims is the halting behaviour, then
does the opposite - I'm not sure if you're familiar with the proof, but imagine you would be given
your background).
His decider H works (subject to design errors/bugs and so on) by single- stepping a simulation of
its input computation, and monitoring for conditions that PO believes indicate non-termination.
He tests a couple of conditions, and when one of those matches H aborts and returns non- halting.
Alternatively if the simulation halts normally, H returns halting. The problem is (at least) one
of his non-halting-behaviour tests is invalid, matching during the simulation of DDD, which is a
halting computation.
It seems that he does not understand that the these conditions (that indicate non-termination
behaviour), form exactly the halting problem.
PO claims that simulation is the solution, but he only shifts the problem of non-termination
detection to the detection of these 'special conditions'.
When we realise that, we understand that a finite or infinite simulation is not very relevant. The
discussion should address these conditions. But PO carefully avoids discussions about the detection
of these conditions, although they are the heart of the problem.
On 12/03/2025 09:38, Mikko wrote:
On 2025-03-11 17:07:38 +0000, olcott said:
<snip>
You still sound like Richard Damon whom is unable to
understand that semantic tautologies are irrefutable.
That a false claim about one person is similar to a false
claim about another is not suffecent ro conclude or even
sustpect that they are the same. A better measure is how meny
indignificant typos each makes.
Quite so.
And while we're on the subject of semantics, the OP seems unaware that
he can't use stipulative definitions to define away the difficult parts
of a problem. At best, he can stipulatively define a /new/ problem, but
by redefining terms he steps away from the original problem. He can
argue till he's blue in the face about the Olcott Problem, but he is no longer saying anything meaningful about the Halting Problem or the Linz
proof thereof.
On 12/03/2025 09:49, Mikko wrote:
On 2025-03-11 18:23:24 +0000, Richard Heathfield said:
int rhc(unsigned int i)
{
  typedef int(*pf)(unsigned int);
  pf arr[3] = {rha, rhb, rhc};
  return arr[i % 3];
The return instruction has wrong type.
Good spot, but no, it's fine. The bug is elsewhere. That line should read:
return arr[i % 3](i);
arr is of type int(*)(unsigned int)[3]
arr[i % 3] is of type int(*)(unsigned int)
arr[i % 3](i) is a function call returning int
On 11/03/2025 18:23, Richard Heathfield wrote:
On 11/03/2025 17:42, Mike Terry wrote:
Finally, if you really want to see the actual HHH code, its in the[I've now seen the code. Oh deary deary me.]
halt7.c file (along with DDD) that PO provides links to from time to
time. However it's not very illuminating due to bugs/design
errors/misunderstandings which only serve to obfuscate PO's errors in
thinking.
:)
Thank you for a spirited attempt to be cogent - or at least as cogent as
it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH() correctly
diagnoses some easy functions, such as these:
Not really necessary - PO is not trying or claiming to have a (full)
halt decider.
Originally his claim was that he had a program which worked for the counter-example TM used in the common (e.g. Linz book) proof.
... Such a
program is impossible, as Linz and others prove, so having a program H and its corresponding "counter-example" D, such that H correctly decides D,
would certainly show that the Linz proof is wrong. His claim was always
that he had "refuted the HP proof", or sometimes that he had refuted the HP theorem itself although he's been told dozens of times that there are many alternative proofs for the result.
[As it turned out, PO's D(D) halted when run under his x86utm environment, while H(D,D) which is required to return the halting status of computation D(D) returned 0 (=non-halting). That is exactly what the Linz proofs
claim!]
I hope you forgive me just chipping in with stuff you know perfectly
well, but I thought I'd just give some background as Richard is a new participant and my comments fit better with your post than his.
On 3/11/2025 5:30 AM, Mikko wrote:
On 2025-03-11 02:27:42 +0000, olcott said:
On 3/10/2025 9:21 PM, Richard Damon wrote:
On 3/10/25 7:41 PM, olcott wrote:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}
void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}
void DDD()
{
  HHH(DDD);
  return;
}
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Problem: DD Isn't a program, and if you try to compile it, you will get >>>> an undiefined symbol HHH.
HHH need not be a program for this correct thought experiment.
The only detail required to know about HHH is that it correctly
emulates N steps of DD.
Wrong. One nneds also to know how a call to HHH is interpreted, in particular
if HHH is not a program.
You are trying to get away with saying that
one C function cannot call another C function
according to the semantics of the C language?
False. You didn't say that HHH is a C function. In particular,
the code
shown above does not say so.
On 16/03/2025 10:31, Mikko wrote:
False. You didn't say that HHH is a C function. In particular, the code
shown above does not say so.
It scarcely qualifies as C.
For example, it begins by a goto this code:
__asm__("lea eax, DATA1");
__asm__("mov Aborted, eax");
__asm__("lea eax, DATA2");
__asm__("mov execution_trace, eax");
__asm__("mov eax, END_OF_CODE");
__asm__("mov End_Of_Code, eax");
which any C compiler is free to reject.
C99 introduced the asm keyword, but that's spelled asm, not __asm__,
and of course it's not a magic wand, so it can't make an inherently unportable program work on every platform supported by C compilers.
C/370, for example, would have a fit.
On 2025-03-16 11:17:53 +0000, Richard Heathfield said:
On 16/03/2025 10:31, Mikko wrote:
False. You didn't say that HHH is a C function. In particular,
the code
shown above does not say so.
It scarcely qualifies as C.
A text is a conforming C program if a conforming compiler accepts
and
compiles it.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 16/03/2025 10:31, Mikko wrote:
False. You didn't say that HHH is a C function. In particular, the
code
shown above does not say so.
It scarcely qualifies as C.
For example, it begins by a goto this code:
__asm__("lea eax, DATA1");
__asm__("mov Aborted, eax");
__asm__("lea eax, DATA2");
__asm__("mov execution_trace, eax");
__asm__("mov eax, END_OF_CODE");
__asm__("mov End_Of_Code, eax");
which any C compiler is free to reject.
C99 introduced the asm keyword, but that's spelled asm, not __asm__,
and of course it's not a magic wand, so it can't make an inherently
unportable program work on every platform supported by C
compilers. C/370, for example, would have a fit.
No, C99 didn't introduce the asm keyword.
I don't think Olcott intends HHH to be fully portable C (assuming
he knows what that means).
In any case, his claims about "Every
sufficiently competent C programmer" are ludicrous.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 496 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 60:42:59 |
| Calls: | 9,762 |
| Calls today: | 3 |
| Files: | 13,744 |
| Messages: | 6,185,585 |