Re: DD specifies non-terminating behavior to HHH --- RECURSIVE CHAIN --- Saving Democracy

Am Sun, 23 Feb 2025 22:42:10 -0600 schrieb olcott:

On 2/23/2025 10:09 PM, dbush wrote:

On 2/23/2025 10:20 PM, olcott wrote:

On 2/23/2025 9:15 PM, dbush wrote:

On 2/23/2025 9:04 PM, olcott wrote:

On 2/23/2025 7:22 PM, dbush wrote:

On 2/23/2025 8:13 PM, olcott wrote:

On 2/23/2025 6:15 PM, dbush wrote:

On 2/23/2025 7:10 PM, olcott wrote:

On 2/23/2025 11:57 AM, dbush wrote:

On 2/23/2025 12:30 PM, olcott wrote:

On 2/22/2025 8:34 PM, dbush wrote:

On 2/22/2025 7:33 PM, olcott wrote:

On 2/22/2025 4:59 PM, dbush wrote:

On 2/22/2025 5:53 PM, olcott wrote:

On 2/22/2025 2:59 PM, dbush wrote:

On 2/22/2025 3:53 PM, olcott wrote:

On 2/22/2025 2:09 PM, dbush wrote:

On 2/22/2025 3:03 PM, olcott wrote:

>
01 int F(int i)
02 {
03   if (i > 10)
04     return 0;
05   else 06     return F(i+1);
07 }
08 09 int no_numbers_greater_than_10()
10 {
11   return F(0);
12 }
13 14 int main()
15 {
16   F((int)no_numbers_greater_than_10);
17   return 0;
18 }
>

So if the address of no_numbers_greater_than_10 is
greater than 10 then 0 is returned right away,
otherwise as most 10 recursive calls will be made
before the condition is matched and 0 is returned.
This doesn't change the fact that
no_numbers_greater_than_10 correctly simulated by F
cannot possibly return so F(no_numbers_greater_than_10)
is correct to report non-halting, which means that
there is no natural number greater than 10.
Agreed?

>
I think that you will find more bugs when you try to
provide the line number by line number execution trace.
#1 bug F never simulates anything.
>

It is a verified fact that

F never simulates anything when i > 10.
>

Remember, you agreed that the behavior of X simulated by Y
is defined by replacing the code of Y with an unconditional
simulator and running Y(X):
>
On 2/22/2025 1:02 PM, olcott wrote:
  > On 2/22/2025 11:10 AM, dbush wrote:
  >> On 2/22/2025 11:43 AM, olcott wrote:
  >>> The first point is DD correctly simulated by HHH
  >>> cannot possibly terminate normally by reaching its
  >>> own "return" instruction.
  >>
  >> In other words, if the code of HHH is replaced with an
unconditional simulator then it can be shown that DD is
non- halting and therefore HHH(DD)==0 is correct.
  >>
  > Wow finally someone that totally gets it.
>
So the behavior of no_numbers_greater_than_10 simulated by
F is defined by replacing the code of F with an
unconditional simulated and running
F(no_numbers_greater_than_10).
The finite string input to F proves that there are no
instructions in no_numbers_greater_than_10 that can break
the recursive simulation.
Try to show how no_numbers_greater_than_10 correctly
simulated by F can possibly halt.

>
Then is ceases to be analogous to HHH(DD) because
no_numbers_greater_than_10() always terminates normally by
reaching its own "return" instruction.

>
In other words, when we actually run
no_numbers_greater_than_10() it reaches its own "return"
instruction.
That means we've now established that the direct execution of
a program (which includes all the functions it calls
UNMODIFIED) defines whether or not it halts.
Likewise, when we actually run DD() unmodified it also
reaches its own "return" instruction.
Therefore HHH(DD)==0 is wrong.
>

When DD is correctly simulated by HHH according to the
behavior that the above machine code specifies then the call
from DD to HHH(DD) cannot possibly return and this correctly
simulated DD cannot possibly terminate  normally by reaching
its own machine address 00002155.
>

Similarly:
0000000000400534 <no_numbers_greater_than_10>:
    400534:    55                       push   %rbp 400535:
    48 89 e5                 mov    %rsp,%rbp 400538:    b8 34
    05 40 00           mov    $0x400534,%eax 40053d:    48 89
    c7                 mov    %rax,%rdi 400540:    e8 a8 ff ff
    ff           callq  4004ed <F> 400545:
    5d                       pop    %rbp 400546:
    c3                       retq
>
When no_numbers_greater_than_10 is correctly simulated by F
according to the behavior that the above machine code specifies
then the call from no_numbers_greater_than_10  to
F(no_numbers_greater_than_10) cannot possibly terminate
normally by reaching its own machine address 400545
So F(no_numbers_greater_than_10)==0 is correct, and therefore
no natural number exists that is greater than 10
Agreed?

>
I Only understand Intel format assembly language.
>

It corresponds to the following C code:
>
int no_numbers_greater_than_10()
{
    return F((uintptr_t)no_numbers_greater_than_10);
}
So if DD is non halting, then by the same criteria
no_numbers_greater_than_10 is non-halting
Agreed?

>
I cannot see any way that you explained that the above invocation
does not always halt. Because of the huge bug in earlier code it
seems that you may be simply.

>
no_numbers_greater_than_10 is structured exactly the same way as
DD. What the code of the function F does isn't really relevant
because your halting criteria replaces all of it with an
unconditional simulator as the basis for a decision.  What matters
is that it returns 0.

>
I am not going to talk about your example any more.

I'll take that as your admission that you know my example proves you
wrong.

With such a major bug initially in your example I am assuming that you
don't understand it.

You don't seem to understand that it doesn't matter what the code of F
is.  As you yourself said:
>
On 9/17/22 6:46 PM, olcott wrote:
  > A halt decider must predict what the behavior of its input would be
  > in the hypothetical case that it directly executed its input. The
  > means for it to do this are unspecified, thus unconstrained:
  > (a) Static analysis (b) Partial simulation (c) Wild guess
>

Don't freaking quote what I said in 2022.

Do you renounce it?