Re: Computable Functions --- finite string transformation rules

Liste des GroupesRevenir à cl c 
Sujet : Re: Computable Functions --- finite string transformation rules
De : F.Zwarts (at) *nospam* HetNet.nl (Fred. Zwarts)
Groupes : comp.theory
Date : 24. Apr 2025, 20:12:43
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vue2fb$27hl3$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
User-Agent : Mozilla Thunderbird
Op 24.apr.2025 om 19:13 schreef olcott:
On 4/24/2025 11:32 AM, Fred. Zwarts wrote:
Op 24.apr.2025 om 17:21 schreef olcott:
On 4/24/2025 3:07 AM, Fred. Zwarts wrote:
Op 24.apr.2025 om 05:22 schreef polcott333:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb 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:
>
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?
>
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.
No, DD halts (when executed directly). HHH is not a halt decider, not even
for DD only.
>
People here stupidly assume that the outputs are not required to
correspond to the inputs.
But the direct execution of DD is computable from its description.
>
>
Not as an input to HHH.
>
But neither the "direct execution" or the "simulation by HHH" are "inputs" to HHH. What is the input is the representation of the program to be decided on.
>
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.
>
It is only ABLE to apply them.
>
>
The input to HHH(DD) does specify the
>
*finite*
>
 > recursive emulation> of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).
>
You can't pop any other execution trace from the input
to HHH(DD) than that.
>
>
You can't abort a halting sequence and claim that it does not halt.
>
Halting means reaching its own final halt state
>
when not prevented to reach its final state by an abort.
 *It is not prevented from reaching its own final state by abort*
 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, so that no abort is needed to reach the end of the halting program.
Mathematical induction shows that each HHH simulating N steps fails to see that there is only a finite recursion, so it is proven that all HHH that abort have the same failure.
But we agree that no algorithm exists that can determine for all possible inputs whether the input specifies a program that (according to the semantics of the machine language) halts when directly executed.
Correct?

Date Sujet#  Auteur
22 Jul 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal