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

On 2/9/25 12:00 PM, olcott wrote:

On 2/9/2025 10:50 AM, Fred. Zwarts wrote:

Op 09.feb.2025 om 16:18 schreef olcott:

On 2/9/2025 2:13 AM, Fred. Zwarts wrote:

Op 09.feb.2025 om 07:10 schreef olcott:

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...

>
The execution trace only shows that HHH is unable to complete its simulation, because HHH is unable to simulate itself.
>

>
https://github.com/plolcott/x86utm/blob/master/Halt7.c
The above code proves that HHH does simulate itself simulating DD.
>
That you can't understand this code proves that you lack the
technical basis to review my work.
>

>
It turns out that Olcott does not even understand this simple proof that HHH produces false negatives. HHH is unable to simulate itself up to the normal termination.

 If you try to explain your view in terms of a line-by-line
execution trace of DD simulated by HHH everyone will see that
your claim has no actual basis what-so-ever and is merely
utterly baseless rhetoric totally bereft of any supporting
reasoning.
 

You mean like the fact that when HHH simulates the Call HHH instuction, the normal trace you present doesn't show the instructions in HHH.
And when you do, it shows that there all the conditional instructions within HHH that HHH ignores, so its logic is invalid.
Sorry, you are just proved to be a liar.