Re: Sufficient knowledge of C proves that DD specifies non-terminating behavior to HHH

On 2/9/25 10:33 AM, olcott wrote:

On 2/9/2025 7:08 AM, Richard Damon wrote:

On 2/9/25 1:10 AM, olcott wrote:

On 2/8/2025 3:54 PM, Fred. Zwarts wrote:

Op 08.feb.2025 om 15:47 schreef olcott:

On 2/8/2025 3:57 AM, Fred. Zwarts wrote:

Op 08.feb.2025 om 06:53 schreef olcott:

On 2/7/2025 7:27 PM, Richard Damon wrote:

On 2/7/25 8:12 PM, olcott wrote:

On 2/7/2025 5:56 PM, Richard Damon wrote:

On 2/7/25 11:26 AM, olcott wrote:

On 2/7/2025 6:20 AM, Richard Damon wrote:

On 2/6/25 10:02 PM, olcott wrote:

On 2/6/2025 8:21 PM, Richard Damon wrote:

On 2/6/25 5:18 PM, olcott wrote:

On 2/6/2025 1:51 PM, Richard Damon wrote:

On 2/6/25 1:26 PM, olcott wrote:

On 2/6/2025 10:52 AM, Bonita Montero wrote:

Am 05.02.2025 um 16:11 schrieb olcott:

On 2/5/2025 1:44 AM, Bonita Montero wrote:

Am 05.02.2025 um 04:38 schrieb olcott:

This treatment does not typically last very long and
will be immediately followed by a riskier fourth line
of treatment that has an initial success rate much higher
than its non progression mortality rate.
>

>
Halting problem solved !
>

>
The halting problem proof input does specify non-halting
behavior to its decider.
>
https://www.researchgate.net/ publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

>
LOOOOOOOOL

>
Anyone that understands the C programming language
sufficiently well (thus not confused by the unreachable
"if" statement) correctly understands that DD simulated
by HHH cannot possibly reach its own return instruction.
>

>
And anyone that understand the halting problem knows that isn't the question being asked. The quesiton you NEED to ask is will the program described by the input halt when run?
>
Since you start off with the wrong question, you logic is just faulty.
>

>
Everyone that thinks my question is incorrect is wrong.
It has always been a mathematical mapping from finite
strings to behaviors. That people do not comprehend this
shows the shallowness of the depth of the learned-by-rote
(lack of) understanding.
>

>
No, you are just incorreect as you don't know what you are talking about.
>
Yes, it is a mapping of the string to the behavior, and that mapping is DEFINED to be the halting behavior of the program the string describes.
>

>
No this is incorrect. The input finite string specifies
(not merely describes) non halting behavior to its decider.
>

>
No, since the definition of "Halting Behavior" is the behavior of the progran being run.
>

>
It may seem that way to people that have learned-by-rote
as their only basis. It is actually nothing like that.

>
No, that *IS* the definition.
>

>
A termination analyzer computes the mapping from finite
strings to the actual behavior that these finite strings
specify. That this is not dead obvious to everyone here
merely proves that learned-by-rote does not involve any
actual comprehension.
>
>

>
And the behavior the finite string specifies is the behavior of running the program.

>
That is verifiably factually incorrect.
The running program has a different execution trace
than the behavior that DD specifies to HHH.
>

>
If so, then it proves the failure of the simulation. The simulation aborts too soon on unsound grounds, one cycle before the normal termination of the program.
>

>
This proves that you simply don't have sufficient
understanding of the C programming language.
DD simulated by HHH cannot possibly terminate normally
is a verified fact.
>

>
Which proves that HHH fails to make a correct decision about DD's halting behaviour. All other methods (direct execution, simulation by a world class simulator, etc.) show that DD halts. But HHH fails to see it. Everyone with sufficient understanding of programming sees that HHH is not correctly programmed when it aborts one cycle before the simulation would end normally.

>
typedef void (*ptr)();
int HHH(ptr P);
>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
int main()
{
   HHH(DD);
}
>
You lack the ability to do the execution trace
of HHH simulating DD calling HHH(DD) simulating DD...
>
If you have no idea what recursion is you will not be
able to understand what I am saying.
>

>
No, YOU lack the understanding of what a program is.
>
Your first problem is that function "DD" isn't a "program" by itself, but only becomes one when you include as part of it the code for HHH. And thus, the specific HHH that exists at this exact point IS HHH, and it can not be changed.
>

 It is this same way for every halting problem instance.
It is an easily verified fact that DD cannot possibly reach
its own "if" statement when-so-ever HHH is a simulating
termination analyzer.

Which doesn't exist as any program that is a correct simulator, will not be a decider, and no program that is a decider can be a correct simulator.

 The only reason that the halting problem proof has never
been refuted before is that everyone always rejected
simulation as a basis out-of-hand without review. They
simply did not bother to think things all-the-way through.
 

No, simulation has not been rejected out of hand, but proven to have limitations. You get to a chicken and egg problem, the simulator needs to have a halt decider to decide when it is ok to abort the simulation to answer, so you need to presume that you have the halt decider first, at which point you don't need the simulator.
Simulation can handle MANY cases, but not all. You always will have cases where you can't decide in finite time the answer, just like you have with any attempt at a halt decider.
As I have mentioned, The use of simulation as an attempt to solve it has a long history, which you just deny because you don't understand what truth actually is.
Sorry, but the fact that you make such a blatant LIE as this just proves your ignorance of the facts of the problem.