Re: Computable Functions --- OUTPUTS MUST CORRESPOND TO INPUTS

On 4/23/25 11:40 AM, olcott wrote:

On 4/23/2025 4:05 AM, Fred. Zwarts wrote:

Op 22.apr.2025 om 21:51 schreef olcott:

On 4/22/2025 2:33 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 20:51 schreef olcott:

On 4/22/2025 1:07 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 18:28 schreef olcott:

On 4/22/2025 7:57 AM, joes wrote:

Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:

On 4/15/2025 2:03 PM, dbush wrote:

On 4/15/2025 2:50 PM, olcott wrote:

On 4/15/2025 11:05 AM, dbush wrote:

On 4/15/2025 11:29 AM, olcott wrote:

>

*corresponding output to the input*
Not freaking allowed to look at any damn thing else besides the
freaking input. Must compute whatever mapping ACTUALLY EXISTS FROM
THIS INPUT.
>

So the algorithm HHH that you've implemented computes *some*
computable function, but it does not compute the halting function as
it is not computable.
>

*corresponding output to the input*
>

That doesn't refute anything I said.
>

You continue to stupidly insist that int sum(int x, int y) {return x +
y; }
returns 7 for sum(3,2) because you incorrectly understand how these
things fundamentally work.
>
It is stupidly wrong to expect HHH(DD) report on the direct execution of
DD when you are not telling it one damn thing about this direct
execution.

What else is it missing that the processor uses to execute it?
>

>
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]
>
libx86emu <is> a correct x86 processor and does emulate
its inputs correctly.

>
The key thing here is that Olcott consistently does not understand that HHH is given a finite string input that according to the semantics of the x86 language specifies a halting program,

>
That is stupidly incorrect. The only question that HHH
must answer is the behavior that its input specifies.
>

Yes and the input, a finite string specifies a halting program according to the unique semantics of the x86 language, as proven by direct execution and world-class simulators. HHH's failure to reach the end of the simulation does not show otherwise.

>
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.

>
We have never seen a proof, only your unbased claims. You never showed the first state change that is different for direct execution and the simulation. You only showed a HHH that fails to reach the end of a halting program.

 _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]
 Even the above is complete proof to everyone that
knows the x86 language.
 

Sure, it proves you don't know what you are talking about as the code is incomplete as it doesn't include the code at 000015c3, so has no actually defined behavior.