Re: Computable Functions --- finite string transformation rules

On 4/25/25 5:21 PM, olcott wrote:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

On 4/24/2025 6:10 PM, Richard Damon wrote:

On 4/24/25 5:01 PM, olcott wrote:

On 4/24/2025 2:59 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 21:41 schreef olcott:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

>
HHH correctly determines through mathematical induction that DD
emulated by HHH (according to the finite string transformations
specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

>

No, HHH has a bug which makes that it fails to see that there is
only a finite recursion,

>
When the finite string transformation rules of the x86 language are
applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE not even after an
infinite number of emulated steps.
>

Again a lot of text, but no rebuttal.

>

When the finite string transformation rules of the x86 language are
applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE not even after an
infinite number of emulated steps.
>

No, HHH just stops performing those before it get to the end.
The transformation, which by definition of the x86 language, don't just
stop in the middle, continue to the point where the emulated HHH aborts
its emulation and returns 0 to the emulated DD which the halts.

>
Mathematical induction proves that DD emulated by HHH cannot possibly
reach its own final state in an infinite number of steps and it does
this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

 

Like Fred wrote months ago, that has nothing to do with the contradictory
part of DD,

 Sure it does. The contradictory part of DD has always
been unreachable thus only a ruse.

But it *IS* reachable, just not by HHH, as it gives up simulating too soon.

 

only with it being simulated by the same simulator it calls.

 That <is> the Halting Problem counter-example input.

No, the Halting Problem counter-example calls the Halt Decider that this particular Input is designed to prove wrong.
You can't make a computation that calls the decider that is deciding on it.

 

The program EE(){ HHH(EE); } also halts and cannot be simulated by HHH.
>

 HHH cannot possibly do this without violating the rules of
the x86 language.

Sure it can, as shown by HHH1. It is just that it doesn't, and this input exploits that error.

 The finite string transformation rules of the x86 language
applied to the input to HHH(DD) only correctly derive not halting.
*It is like you are trying to get away with disagreeing with arithmetic*
 

Really, then why does running it make it halt, as they both do the EXACT SAME transformation, that *IS* what correct simulation is defined by. The problem is that HHH doesn't actually follow all the x86 transformation rules, but deviates by choosing to abort its operation becuase it is afraid that it will get stuck.
But, since the input is defined to use the version of HHH that is in Halt7.c that does this abort, the decider looking at it doesn't need to abort, but of course, HHH does since that was what its code said to do, even though that was the wrong thing to do.