Re: Computable Functions --- finite string transformation rules

On 4/24/25 8:03 PM, olcott wrote:

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,

>
*You are technically incompetent on this point*
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.
>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]
>
>
>

Again a lot of text, but no rebuttal.

>
*This rebuttal is over-your-head*
>
All computations must be finite string transformations
to finite string inputs.

>
>
Right

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

Try to show it.
Remember, HHH is DEFINED to do what it does, and thus you can't use induction to make it be something else.
THe input BY DEFINITION calls the origianl HHH, and thus when you imagine a different machine that emulates one step farther, you CAN'T put it at the memory location of HHH, as that has already been defined, so you get effectivel HHH1, which shows the input halts.
Your "proof" is based on LYING by conviently forgetting that HHH is fixed and defined and can't be changed.
Sorry, you are just proving that you are just a stupid pathological liar.
Try to write you your induction that falls within your stipulation that your exist Halt7.c is defined and in the problem.
You don't get to change it, or you are admtting that you are creating a DIFFERENT input, and thus the induction falls appart.
Sorry, you have put yourself in checkmate, and you lying won't get you out, just prove how stupid you are.

 

>
That fact you confuse the partial emulation of HHH with the actual factual definition of the x86 language just shows your ignorance of what you talk about, that you don't understand the nature of logic or truth, and that you are nothing but a pathological liar.