Op 10.mei.2025 om 17:13 schreef olcott:

On 5/10/2025 2:15 AM, Mikko wrote:

On 2025-05-09 03:01:40 +0000, olcott said:

On 5/8/2025 9:23 PM, 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?

*****
Now you are seeing what I was talking about.
Now you are seeing why I needed to cross post
to comp.lang.c

What were you told in comp.lang.c that you were not told in comp.theory?

void DDD()
{
  HHH(DDD);
  return;
}

People quickly realize that when DDD is correctly
simulated by HHH that DDD cannot possibly reach
its "return" statement (final halt state).

Once you know this then you can see that the
same thing applies to DD.

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

Once you know this then you know that the halting
problem's otherwise "impossible" input is non-halting.

Once you know this then you know that the halting
problem proof has been correctly refuted.

Your memory seems bad. You said this before and it was shown to be
irrelevant.
HHH does not correctly simulate DDD, because it halts the simulation
before its gets to the most important part of the input, where it
specifies a conditional abort. This bug makes that HHH misses the fact
that this input specifies a buggy halting program and that it does not
reach the reachable end of the simulation.
IT seems that you forget all easily verifiable facts when they disturb
your dreams.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/10/25 11:13 AM, olcott wrote:

On 5/10/2025 2:15 AM, Mikko wrote:

On 2025-05-09 03:01:40 +0000, olcott said:

On 5/8/2025 9:23 PM, 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?

*****
Now you are seeing what I was talking about.
Now you are seeing why I needed to cross post
to comp.lang.c

What were you told in comp.lang.c that you were not told in comp.theory?

void DDD()
{
  HHH(DDD);
  return;
}

People quickly realize that when DDD is correctly
simulated by HHH that DDD cannot possibly reach
its "return" statement (final halt state).

But you are just showing your stupidity, as your DDD is IMPOSSIBLE to correcctly emulate, as what you define as the repesentation of DDD, amd
your own descirption of it, excludes the code for HHH, so you can not
use that, and thus it just doesn't HAVE behavior beyond the call
instruction, is it just isn't a program to HAVE behavior.

Until you actually define that HHH has been added as part of the DDD in
the input to make it actually be a program, it just can not be
"correctly emulated"

Of course, once you do that, every different pairing of DDD to an HHH is
a different input, and thus none of your HHH's are paired to the same
DDD, so you can't translate behavior from one DDD/HHH pair to another.

Once you know this then you can see that the
same thing applies to DD.

Right, it isn't a program either, not until you ADD the code of HHH to
it, and thus each HHH gets a different DD/HHH pairing,

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

Once you know this then you know that the halting
problem's otherwise "impossible" input is non-halting.

Nope. Just that you are showing yourself to be non-thinking.
Your HHH can not correctly emulate an input that is not actualy the representation of a program.

Once you know this then you know that the halting
problem proof has been correctly refuted.

Nope, just that you have proved yourself to be a liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-10 15:13:32 +0000, olcott said:

On 5/10/2025 2:15 AM, Mikko wrote:

On 2025-05-09 03:01:40 +0000, olcott said:

On 5/8/2025 9:23 PM, 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?

*****
Now you are seeing what I was talking about.
Now you are seeing why I needed to cross post
to comp.lang.c

What were you told in comp.lang.c that you were not told in comp.theory?

void DDD()
{
HHH(DDD);
return;
}

People quickly realize that when DDD is correctly
simulated by HHH that DDD cannot possibly reach
its "return" statement (final halt state).

Once you know this then you can see that the
same thing applies to DD.

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

Once you know this then you know that the halting
problem's otherwise "impossible" input is non-halting.

Once you know this then you know that the halting
problem proof has been correctly refuted.

You are lying again. Nothing above was told you in comp.lang.c.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/11/25 12:03 PM, olcott wrote:

On 5/11/2025 4:12 AM, Mikko wrote:

On 2025-05-10 15:13:32 +0000, olcott said:

On 5/10/2025 2:15 AM, Mikko wrote:

On 2025-05-09 03:01:40 +0000, olcott said:

On 5/8/2025 9:23 PM, 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?

*****
Now you are seeing what I was talking about.
Now you are seeing why I needed to cross post
to comp.lang.c

What were you told in comp.lang.c that you were not told in
comp.theory?

void DDD()
{
   HHH(DDD);
   return;
}

People quickly realize that when DDD is correctly
simulated by HHH that DDD cannot possibly reach
its "return" statement (final halt state).

Once you know this then you can see that the
same thing applies to DD.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Once you know this then you know that the halting
problem's otherwise "impossible" input is non-halting.

Once you know this then you know that the halting
problem proof has been correctly refuted.

You are lying again. Nothing above was told you in comp.lang.c.

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.

Right, if HHH is a correct emulator, and thus not a decideer, then DDD
is non-halting.

Of course, the definition of DDD includes the HHH that it calls, so
changing HHH to be the one that is a decider and not a correct simulator
means we have a different DDD, and thus you can't apply that result.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/12/25 10:47 AM, olcott wrote:

On 5/12/2025 2:45 AM, Mikko wrote:

On 2025-05-11 16:03:29 +0000, olcott said:

On 5/11/2025 4:12 AM, Mikko wrote:

On 2025-05-10 15:13:32 +0000, olcott said:

On 5/10/2025 2:15 AM, Mikko wrote:

On 2025-05-09 03:01:40 +0000, olcott said:

On 5/8/2025 9:23 PM, 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?

*****
Now you are seeing what I was talking about.
Now you are seeing why I needed to cross post
to comp.lang.c

What were you told in comp.lang.c that you were not told in
comp.theory?

void DDD()
{
   HHH(DDD);
   return;
}

People quickly realize that when DDD is correctly
simulated by HHH that DDD cannot possibly reach
its "return" statement (final halt state).

Once you know this then you can see that the
same thing applies to DD.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Once you know this then you know that the halting
problem's otherwise "impossible" input is non-halting.

Once you know this then you know that the halting
problem proof has been correctly refuted.

You are lying again. Nothing above was told you in comp.lang.c.

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.
;

What he says is true. However, the assumptions that HHH does a correct
simulation and that it does nothing else are not.

_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]

Which isn't a valid input without adding in explicitly the code of the
HHH that it will call (which for your system will also be the HHH that
is deciding it) This makes each HHH's DDD that it is paired with
different from all the others.

We make an infinite set of purely hypothetical HHH pure
x86 emulators each one is at machine address 000015d2
thus called by DDD.

So, HHH is defined to be a pure emulator, I guess you are stipulating
that you HHH can not abort its emulation.

That or you are just lying about what is actually at that address.

Remember, you can't stipulate a lie.

> The first HHH emulates one step the Nth HHH emulates N steps.

No DDD of any HHH/DDD pair every reaches its own "ret"
instruction final halt state.

Then you are admitting that you lied, as HHH can't be two different things.,

Since every DDD element of every every HHH/DDD
pair fails to halt therefore every HHH would be
correct to reject its input as non-halting.

Np, because none of your HHH can exist as a machine that both is a pure emulator and a partial emulatior.

You are just demonstrating that you "logic" is based on just being a
blantant liar that lives in a fantasy fairy tale world that you believe
has a Truth Fairy that can make the impossible happpen.

Sorry, you just proved that you are just a pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/12/25 12:24 PM, olcott wrote:

On 5/12/2025 9:53 AM, dbush wrote:

On 5/12/2025 10:47 AM, olcott wrote:

On 5/12/2025 2:45 AM, Mikko wrote:

On 2025-05-11 16:03:29 +0000, olcott said:

On 5/11/2025 4:12 AM, Mikko wrote:

On 2025-05-10 15:13:32 +0000, olcott said:

On 5/10/2025 2:15 AM, Mikko wrote:

On 2025-05-09 03:01:40 +0000, olcott said:

On 5/8/2025 9:23 PM, 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?

*****
Now you are seeing what I was talking about.
Now you are seeing why I needed to cross post
to comp.lang.c

What were you told in comp.lang.c that you were not told in
comp.theory?

void DDD()
{
   HHH(DDD);
   return;
}

People quickly realize that when DDD is correctly
simulated by HHH that DDD cannot possibly reach
its "return" statement (final halt state).

Once you know this then you can see that the
same thing applies to DD.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Once you know this then you know that the halting
problem's otherwise "impossible" input is non-halting.

Once you know this then you know that the halting
problem proof has been correctly refuted.

You are lying again. Nothing above was told you in comp.lang.c.

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.
;

What he says is true. However, the assumptions that HHH does a correct >>>> simulation and that it does nothing else are not.

_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]

We make an infinite set of purely hypothetical HHH pure
x86 emulators each one is at machine address 000015d2
thus called by DDD.

And each DDD is a distinct algorithm.

Such that none of them halt.
The only difference is the number of steps of DDD
emulated by HHH.

And none are non-halting and correctly reported as such.

This proves that each element of the infinite
set of HHH/DDD pairs never halts. This proves
the the specific element of the encoded HHH
that emulates 7 steps of DDD is correct to reject
DDD as non-halting.

NO, since every DD waa a different input, you can't use the non-aborting
HHH to show that the aborting HHH have a non-halting input.

The non-aborting HHH doesn't answer.

The actual correct emulation of the input to the aborting HHH's is the
DDD that calls that aborting HHH, so the correct emulation of that DDD
WILL see that HHH return 0 to DDD (after that HHH gave up on its
emulation of the input, leading to its ignorance) and that DDD halting.

Since this has been explained to you many times, this just shows that
you don't care about what is actually true, but are just a pathological
liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-12 14:47:04 +0000, olcott said:

On 5/12/2025 2:45 AM, Mikko wrote:

On 2025-05-11 16:03:29 +0000, olcott said:

On 5/11/2025 4:12 AM, Mikko wrote:

On 2025-05-10 15:13:32 +0000, olcott said:

On 5/10/2025 2:15 AM, Mikko wrote:

On 2025-05-09 03:01:40 +0000, olcott said:

On 5/8/2025 9:23 PM, 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?

*****
Now you are seeing what I was talking about.
Now you are seeing why I needed to cross post
to comp.lang.c

What were you told in comp.lang.c that you were not told in comp.theory? >>>>>

void DDD()
{
   HHH(DDD);
   return;
}

People quickly realize that when DDD is correctly
simulated by HHH that DDD cannot possibly reach
its "return" statement (final halt state).

Once you know this then you can see that the
same thing applies to DD.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Once you know this then you know that the halting
problem's otherwise "impossible" input is non-halting.

Once you know this then you know that the halting
problem proof has been correctly refuted.

You are lying again. Nothing above was told you in comp.lang.c.

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.
;

What he says is true. However, the assumptions that HHH does a correct
simulation and that it does nothing else are not.

_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]

We make an infinite set of purely hypothetical HHH pure
x86 emulators each one is at machine address 000015d2
thus called by DDD.

You can't do that without violating your earlier statement that
HHH always means the code in halt7.c on your Github repository.

The first HHH emulates one step the Nth HHH emulates N steps.
No DDD of any HHH/DDD pair every reaches its own "ret"
instruction final halt state.

They do. The HHH jsut does do that for the pair containing that
particular HHH. That you don't try another HHH does not mean
that it cannot be dane.

Since every DDD element of every every HHH/DDD
pair fails to halt therefore every HHH would be
correct to reject its input as non-halting.

No, it is not correct to reject an input just because other deciders
reject other inputs.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-12 17:19:52 +0000, olcott said:

On 5/12/2025 12:08 PM, dbush wrote:

On 5/12/2025 12:59 PM, olcott wrote:

On 5/12/2025 11:42 AM, dbush wrote:

On 5/12/2025 12:24 PM, olcott wrote:

On 5/12/2025 9:53 AM, dbush wrote:

On 5/12/2025 10:47 AM, olcott wrote:

On 5/12/2025 2:45 AM, Mikko wrote:

On 2025-05-11 16:03:29 +0000, olcott said:

On 5/11/2025 4:12 AM, Mikko wrote:

On 2025-05-10 15:13:32 +0000, olcott said:

On 5/10/2025 2:15 AM, Mikko wrote:

On 2025-05-09 03:01:40 +0000, olcott said:

On 5/8/2025 9:23 PM, 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?

*****
Now you are seeing what I was talking about.
Now you are seeing why I needed to cross post
to comp.lang.c

What were you told in comp.lang.c that you were not told in comp.theory?

void DDD()
{
   HHH(DDD);
   return;
}

People quickly realize that when DDD is correctly
simulated by HHH that DDD cannot possibly reach
its "return" statement (final halt state).

Once you know this then you can see that the
same thing applies to DD.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Once you know this then you know that the halting
problem's otherwise "impossible" input is non-halting.

Once you know this then you know that the halting
problem proof has been correctly refuted.

You are lying again. Nothing above was told you in comp.lang.c. >>>>>>>>>

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.
;

What he says is true. However, the assumptions that HHH does a correct >>>>>>>> simulation and that it does nothing else are not.

_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]

We make an infinite set of purely hypothetical HHH pure
x86 emulators each one is at machine address 000015d2
thus called by DDD.

And each DDD is a distinct algorithm.

Such that none of them halt.
The only difference is the number of steps of DDD
emulated by HHH.

And the halt status of algorithm DDD has nothing to do with the halt
status of algorithm DDD1, DDD2, etc.

When the only difference between HHH/DDD pairs is that

They are different algorithms and therefore the halt status of one has
nothing to do with the halt status of another.

That is not true, this difference is not
the kind that can possibly change the halt status.

The difference is merely applying mathematical
induction to the exact same algorithm of HHH
emulating N steps of DDD.

It is not the exact same algorithm if the number of the emulated steps
is not the same. N is not an input HHH but a part of or a consequence
of the algorthm.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)