Re: Can D simulated by H terminate normally?

On 5/1/2024 10:56 PM, Richard Damon wrote:

On 5/1/24 11:26 PM, olcott wrote:

On 5/1/2024 7:36 PM, Richard Damon wrote:

On 5/1/24 12:32 PM, olcott wrote:

On 5/1/2024 6:23 AM, Richard Damon wrote:

On 5/1/24 12:28 AM, olcott wrote:

On 4/30/2024 5:46 PM, Richard Damon wrote:

On 4/30/24 12:15 PM, olcott wrote:

On 4/30/2024 10:44 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

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

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

>
[ .... ]
>

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.

>
I would indeed be charmed if you would address it, but you have evaded
it, as you have evaded most of the points I made yesterday.
>
Note that I said there is no correctness _IN_ a turing machine. This is
independent of whether or not that turing machine is useful for some
external purpose.
>
Note also that you wilfully distorted my meaning by trimming. The full
context was:
>

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

>

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.

>
Your use of the word "correctly" in "correctly finished its processing"
is wrong.  A turing machine is either running or it's finished its
processing.  From the point of view of the tm, there is no "correct" or
"incorrect" associated with the latter condition; it's simply reached a
final state.
>
You are thus mistaken in believing "abnormal" termination isn't a final
state.
>

>
When we add the brand new idea of {simulating termination analyzer} to
the existing idea of TM's then we must be careful how we define halting
otherwise every infinite loop will be construed as halting.
>

>
Why?
>
That doesn't mean the machine reached a final state.
>

>
Alan seems to believe that a final state is whatever state that an aborted simulation ends up in.
>
On 4/30/2024 10:44 AM, Alan Mackenzie wrote:
 > You are thus mistaken in believing "abnormal" termination
 > isn't a final state.

>
But if Halting is to be a property of the Machine itself, and not about the decider (and when it decides to abort) then "abnormal termination" needs to be something that the machine itself actually does.
>
As has been pointed out, Turing Machines do not "abnormally terminate"
>

>
Until someone invents the idea of a simulating termination analyzer
that operates on Turing machine Descriptions. Prior to this we only
had halt and loops.
>

>
Which just proves you don't understand what you are talking about. Asking ANY machine to decide on the behavior of a Turing Machine, even a "Simulating Termination Analyzer" can't change the behavior of the actual Turing Machine.
>
You might be able to define some previously undefined properties, but even if you find that H had to "abnormally terminate" (it simulation of the machine), that doesn't change whether that machine actually Halted or Not.
>

>
When the notion of simulating termination analyzer is invented
that notion of abnormal termination comes with it. You are correct
that it only applies to simulated inputs.
>

 And thus, since you divorce the simulaton from the actual behavior of the machine represented by the input, makes it as much, if not more so, a property of the decider than the input.
 

No I do not yet we are not at that point yet.
*We are still on this point*
(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.

This makes it not a very useful property.
 But of course, that seems normal for you, Truths are not true based on themselves to you, but on who knows them, and thus your world is based on subjective truth, not objective truth.
 

What you have defined is simulations having an "abnormal termination" because the 'Termination analyzer" has just decided to abort its simulation there, and thus it is a property of the analyzer applied to the machine, not the machine itself.
>

>
>
>

>

>

Only if you try to define something that is NOT related to Halting, do you get into that issue.
>

>
"The all new ideas are wrong" assessment.
Simulating termination analyzers <are> related to halting.
>
The whole field of *termination analysis* is directly related
to halting.

>
Yes, but related doesn't mean the same as. My first impression of what that workshop was talking about looking at various subclasses of programs, and what can be said about them.
>

>
When a simulating termination analyzer is applied to the halting problem's counter-example input then STA becomes 100% relevant
to the halting problem.
>

>
Nope.
>
HALTING is define on the actual behavior of the ACTUAL MACHINE,
>
All you are doing, at best, is defining a NEW problem to try to answer, your POOP.
>
That doesn't change the answer about actual Halting.
>
It only proves your utter stupidity.

>

 

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer