Re: Every HHH(DDD) is correct to reject its input --- Proof by MI

On 6/3/25 2:27 AM, olcott wrote:

On 6/2/2025 9:13 PM, Richard Damon wrote:

On 6/2/25 11:57 AM, olcott wrote:

On 6/2/2025 6:04 AM, Richard Damon wrote:

On 6/2/25 1:12 AM, olcott wrote:

On 6/1/2025 6:20 AM, Mikko wrote:

On 2025-05-31 19:21:10 +0000, olcott said:
>

On 5/31/2025 2:11 PM, Mr Flibble wrote:

Olcott is doing this:
>
int main()
{
DDD(); // DDD calls HHH
}
>
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
>
Olcott should be doing this:
>
int main()
{
HHH(DDD);
}

>
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.

>
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
>
*Every rebuttal to this changes the words*
>
>

>
No, it specifies FINITE recursive simulation, as HHH is defined to be a DECIDER, that must always  return after finite time.
>

>
Unlike most people here I do understand that not
possibly reaching a final halt state *is* non-halting behavior.

>
No, it is not reaching a final halt state after an unbounded number of steps.
>

 Not possibly ever reaching the finite state
could possibly be a paraphase of that.

But only if the context is the execution of the program.
When you start with that category error of talking about partial simulation, it doesn't

 Yet the trick is encoding that into a formal
proof using mathematical induction.

Which you can't do.
The problem is each of your DDDs used by each of your different HHHs are actually DIFFERENT, and thus you can't use the behavior of DDD[n] to tell you anything about DDD[n+1], and thus no induction is possible for your goal.
Sorry, all you are doing is proving you are just a stupid and ignorant liar that misuses words because he ignores what they actually mean.

 

A partial simulation not reaching a final state in its simulation is *NOT* evidence of non-halting behavior.
>
The problem is that "Halting" is a property of EXECUTION of a program, and just the execution of a program. It is NOT defined by simulation.
>
Note, simulation is defined by its replciation of execution, and partial simulation isn't really given a position in that definition. The only definition of "simulation" is from the definition of a UTM, which by definition, won't stop until it reaches a final state.
>
And thus, the fact that a partial simulation doesn't reach a final state is meaningless, unless you can show a proof that the complete simulation of this exact input (and thus DDD calling the aborting simulator) would never halt.
>
All you are doing is proving that you are just a pathetic pathological liar that is intentionally be obtuse about what he is talking about and reckless ignoring the truth.
>

Your world is just filled with contradictions and lies.
>
The problem is your words are just meaningless, as you admit you don't use there actual meaning as terms-of-art.
>
Sorry, but you are just showing how stupid you are.

>
>

>