Re: At least 100 people kept denying the easily verified fact --- last communication with Richard

On 6/8/24 10:59 AM, olcott wrote:

On 6/8/2024 9:36 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 16:25 schreef olcott:

>
DD correctly determines that its own input DD would never
stop running unless aborted.

>
But it is aborted. We can not base conclusions on things that do not happen.
>

 We use a kind of backwards mathematical induction to prove
that a simulated input cannot possibly stop running.
 We start with looking as what the behavior would be
when an infinite number of steps are correctly simulated.
 We do this in a finite number of steps by matching
non-halting behavior patterns.
 void Infinite_Recursion(u32 N)
{
   Infinite_Recursion(N);
}
 When we verify in a finite number of steps of correct
simulation that Infinite_Recursion cannot possibly
stop running without having its simulation aborted
then HH(Infinite_Recursion, (ptr)5); correctly reports
that Infinite_Recursion never halts.
 Infinite_Recursion matches one of the non-halting
behavior patterns that HH has.

But you can't do induction back from infinity.
Please try to show a repected source that talks about doing it that way.
You need to do induction FORWARDS for it to be valid.

 

It has no idea that the inner
HH is an instance of itself. HH merely recognizes the infinite
recursion behavior pattern.
>

There is no infinite recursion behavior pattern, because HH aborts.

 Whenever the input would never stop running unless aborted
then HH is correct to report that and ignore everything else
in the universe.

Nope, using the wrong definition.
Note, the input needs to be a PROGRAM, and thus a specific instance. If that instance is based on an decider that aborts and returns 0, then that instance, when examained properly, will be seen to eventually halt when run, which is what Halting is DEFINED to look at.

 Most computer scientists don't pay enough attention to know
that halt deciders only compute the mapping from their inputs
on the basis of the behavior specified by these inputs.

And you fail to notice that the "behavior specified by these inputs", for a Halt Decider, is DEFINED by the behavior of the actual machine the input represents, or equivalently, but the behavior of a UTM simulation, which by definition, doesn't stop simulating until it gets to a final state. This is the criteria even if the decider doesn't simulate that far, the criteria does.
Since, given an HH(DD,DD) that returns 0, we have DD(DD) Halts, as will UTM(DD,DD) we se that the answer for HH is just incorrect.
Your other opetion, that HH(DD,DD) doesn't abort its simulation, just ends up with an HH that isn't a decider, so the behavior of DD doesn't matter, it just did its job by breaking HH.

 I have never heard of any computer scientist that did not make
this mistake. Professor's Hehner and Stoddart are the only
one's in the whole world that I know of that have an actual
clue that something is wrong with the halting problem.

Because you are stuck in a mistake of understanding the problem, and you found a couple of people who did the same mistake.

 I found out about them on my phone when I was getting
chemotherapy on my birthday in 2022.
 [1] E C R Hehner. Problems with the Halting Problem, COMPUTING2011
Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe
Germany, invited, 2011 October 20-21; Advances in Computer Science and
Engineering v.10 n.1 p.31-60, 2013
https://www.cs.toronto.edu/~hehner/PHP.pdf
 [2] E C R Hehner. Objective and Subjective Specifications
WST Workshop on Termination, Oxford.  2018 July 18.
See https://www.cs.toronto.edu/~hehner/OSS.pdf
 [3] Bill Stoddart. The Halting Paradox
20 December 2017
https://arxiv.org/abs/1906.05340
arXiv:1906.05340 [cs.LO]
  

If there would be an infinite recursion behavior pattern that would prove that HH would not meet its requirement that it must halt.