Re: Can D simulated by H terminate normally?

Op 30.apr.2024 om 20:26 schreef olcott:

On 4/30/2024 12:38 PM, Fred. Zwarts wrote:

Op 30.apr.2024 om 18:27 schreef olcott:

On 4/30/2024 11:24 AM, Fred. Zwarts wrote:

Op 30.apr.2024 om 18:10 schreef olcott:

On 4/30/2024 10:37 AM, Fred. Zwarts wrote:

Op 30.apr.2024 om 17:18 schreef olcott:

On 4/30/2024 3:46 AM, Fred. Zwarts wrote:

Op 29.apr.2024 om 21:04 schreef olcott:

On 4/29/2024 1:19 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 4/29/2024 11:17 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 4/29/2024 10:23 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 4/29/2024 9:37 AM, Alan Mackenzie wrote:

In comp.theory olcott <polcott333@gmail.com> wrote:

On 4/28/2024 1:39 PM, Richard Damon wrote:

On 4/28/24 2:19 PM, olcott wrote:

>

[ .... ]

>

Even the term "halting" is problematic.
For 15 years I thought it means stops running for any reason.

>

[ .... ]

>

Having been aborted (if such were possible) is merely another final
state for a TM.

>

No it definitely is not.

>

In a TM, each state is either a final state or a non-final state. Are
you arguing for a third alternative, or do you think that "having been
aborted" is a non-final state?  If the latter, what state does the TM
change to next?

>

Aborted means completely dead as if you pulled the power cord
on your computer.

>

A turing machine has no power cord to pull.  You didn't answer my point;
you evaded it.

>

When the payroll system crashes 10% of the way through calculating
payroll we cannot say that everyone has been paid.

>

Of course not, but it has nevertheless reached a final state, an
unsatisfactory one, since it is no longer running on the computer.

>

That is not what "theory of computation" {final state} means.

>

I think it is.  What do you think "final state" means, and how is "having
been aborted" not one?

>

Core dump abnormal termination does not count as the program
correctly finished its processing.

>

There is no notion of "correct" in a turing machine.

>

In other words when a TM computes the sum of 2 + 3 and derives
999999999999999999999999999 then that is just fine.

>
Don't be idiotic.  A TM that gets that answer from those starting
conditions isn't calculating their sum; it's doing something else.
>

>
The ONLY way that we can determine if any computation is correct
is when it meets its specification. When a TM is specified to
calculate the sum of a pair of decimal integers and it derives
any decimal integer other than 5 from inputs 2,3 then it is incorrect.
>

>
Changing the subject. The question is not whether it is correct, but whether it halts. Incorrect programs exist and even those program may halt.
>

>
I had to address this:
>
On 4/29/2024 11:17 AM, Alan Mackenzie wrote:
 > There is no notion of "correct" in a turing machine.  It is either
 > running, or has reached a final state.  In the TM equivalent of "core
 > dump", a final state has most definitely been reached.
>

>
Yes, he did that because olcott changed subject from halting to 'halting with a correct result'. Does it mean that olcott is now no longer working on a halting decider, but a '"correct halting" decider', or even a 'correct decider'?

>
Alan changed the subject I addressed that point and then moved on.
If someone does not even know what "correct" means then they can't
know what "halting" means.
>

>
Again an undefined term. There are many contexts where 'correct' is not clear. It is very useful.

>
I have already proven otherwise and you simply ignored this proof.
>

If 'correct' is so easy to define, olcott must be able to provide a 'simulating correct decider', which for any given program returns whether it is correct or not.

>
I only addressed the notion of correct as an aspect of the basis
of the definition of halting
>

>
Does that mean that, according to olcott, the program
>
int main () {
   printf ("Welcom\n");
}
>
does not halt, because it is incorrect? It has a spelling error!
>

>
int H(ptr x, ptr y); // ptr is pointer to int function
>
01 int D(ptr x)
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11   H(D,D);
12 }
>
(a) It is a verified fact that D(D) simulated by H cannot
possibly reach past line 03 of D(D) simulated by H whether H
aborts its simulation or not.
>
Before we can get into the computer science of a simulating
termination analyzer we must first have mutual agreement on
the software engineering of it.
>
ONLY when we mutually agree on the (a) point can we proceed to
the next point. If we don't do it this way then everyone simply
leaps to the conclusion that I must be wrong without ever fully
understanding what I am saying.
>

 Does that mean that, according to olcott, the program
 int main () {
   printf ("Welcom\n");
}
 does not halt, because it is incorrect? It has a spelling error!
 

ONLY if we agree on this point, can we continue to point (a). If we don't do it this way, then everybody can leap to the conclusion that olcott does not understand what 'correct' means and then further discussion is pointless.