Re: Computable Functions --- finite string transformation rules

On 4/25/25 2:51 PM, olcott wrote:

On 4/25/2025 1:39 PM, dbush wrote:

On 4/25/2025 2:31 PM, olcott wrote:

On 4/25/2025 7:02 AM, dbush wrote:

On 4/25/2025 12:53 AM, olcott wrote:

On 4/24/2025 10:00 PM, dbush wrote:

On 4/24/2025 10:50 PM, olcott wrote:

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

On 4/24/25 3:41 PM, olcott wrote:

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.

>

>
>

When the defined finite string trasnsformation rules, thos of the x86 language, are applied to this input, completed with the definitions from Halt7.c as stipulated, we see that DD calls HHH(DD), that it will spend some time emulating DDm then it will

>
Correctly determine that DD emulated by HHH can never possibly
reach its final halt state even after an infinite number of
steps are emulated.

>
Category error.  The fixed code of algorithm HHH, which is part of the input as you agreed, emulates for a fixed number of steps. Therefore there is no infinite number of steps emulated by algorithm HHH.
>

>
You are flat out stupid about hypothetical possibilities.
Of every possible HHH/DD pair where DD calls HHH(DD) and
DD is emulated by HHH according to the finite string transformation
rules of the x86 language no DD ever reaches its own final halt state.
>

>
In other words, you're hypothesizing changing the input.
>
Changing the input, hypothetically or otherwise, is not allowed.
>
>

>
I am only saying the ALL X are Y.
Only Trolls would have difficulty with this.

>
No, you're saying that

 For every possible HHH/DD pair where HHH emulates 0 to ∞

But those don't exist, because HHH has been stipulated to be the ONE machine defined in Halt7.c
Sorry, you are not allowed to change it without giving up that stipulation, and if you do then you hit the problem that DD now isn't defined, as you don't have a single definition of the HHH that it calls.

instructions of DD (according to the finite string
transformation rules specified by the x86 language)
no DD ever reaches its final halt state.

But since you have retracted you definition of Halt7.c, then either your definition of DD changes for every different HHH you are thinking of, and thus you argument breaks as it isn't trying to look at the same input, or the input just doesn't have behavior.
You can't do induction on a criteria that changes for each n.
Sorry, you are just proving your ignorance of what you are talking about.

 When ALL X are Y then zero X are not Y, Trolls may disagree.

But if there is only 1 X, then there is only 1 Y, and X's claim that it is correctly emulating its input is a lie, as no induction has been done.

 int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 

It is still a FACT that if HHH has been defined to do what you say, DD will halt. and the correect emulation of DD by a emulator that actually does a complete emulation will halt, and it is a fact that NONE of your HHH's in the full infinte set ever did that emulation.
Your arguement is basically like saying if we define M to be N+1, that M must be infinite, because there is no finte number N where N > M.
The problme is you can't do the induction over N to look at the changing M.
You are just showing your utter stupidity,