Re: Can D simulated by H terminate normally?

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!