Re: Proof that H(D,D) meets its abort criteria --self-evident truth--

On 3/16/24 10:08 PM, olcott wrote:

On 3/17/2024 12:05 AM, Richard Damon wrote:

On 3/16/24 9:59 PM, olcott wrote:

On 3/16/2024 11:56 PM, Richard Damon wrote:

On 3/16/24 9:44 PM, olcott wrote:

On 3/16/2024 11:33 PM, Richard Damon wrote:

On 3/16/24 9:26 PM, olcott wrote:

On 3/16/2024 11:21 PM, Richard Damon wrote:

On 3/16/24 9:14 PM, olcott wrote:

On 3/16/2024 11:12 PM, Richard Damon wrote:

On 3/16/24 9:08 PM, olcott wrote:

On 3/16/2024 10:50 PM, Richard Damon wrote:

On 3/16/24 7:54 PM, olcott wrote:

On 3/16/2024 9:50 PM, Richard Damon wrote:

>

So, are you admitting that you "Halt Deciders" are

>
Not being discussed. We are only looking at this:
[Proof that H(D,D) meets its abort criteria]
>
>

>
Then why do you call them Halt Deciders?

>
In this thread we must focus on the single point
[Proof that H(D,D) meets its abort criteria]
Or we will never ever get closure on this single point.
>

>
So, is this criteria supposed to be a Halt Deciding criteria?
>

>
H is an algorithm that simulates its input and correctly
determines whether or not it needs to abort this simulation.
That is all that this thread's H does.
>
>

>
And what defines "Need"?
>
Note, if H is an algorithm, we can't talk of "changing" it, or it looses its identity.
>

>
It is the set of every implementation of its spec:

>
But it was an algorithm, not a set. Make up your mind.
>

(a) H(D,D) Simulate input.
(b) Determine if it needs to stop simulating its input to prevent
the simulated D(D) from never halting.

>
And how do you determine NEED.
>

>
Determine if it needs to stop simulating its input
*to prevent the simulated D(D) from never halting*
>

>
But H already does what it does.
>

We never validated that it is definitely correct.
>

>
How do we know?
>

 (a) If simulating abort decider H correctly simulates its input D until H correctly determines that its simulated D would never stop running unless aborted then
 Do you understand that spec?

Yes, but you don't seem to agree with my understanding, and can not actualy define it in any other way.
(a) is NOT a algorithm, but a specification, so something we need to check AFTER we have defined H.
because, it include words requiring it to know the right answer before it can act on them.
You have shown he algorithm you THINK meets this spec, but it fails the test.
To test if a given machine needed to abort a simulation that it aborted, you give that input to an actual pure simulator and see if it stop. If it does, then the machine did not NEED to abort its simulation, and thus failed to meet the specification.
We can't "change" H to test it, as that changes the question being asked of it, we can only give its input to something else related, that by doing so we don't change the input, or the H itself.
Remember, Machines do what they do and only what they do and don't do anything else.
And, Get the right answer is not an algorithmic step.

 

Your "algorithm" included a non-algorithmic step, so how do you intend to perform that step?
>
Best you can do is try all possiblities are remove those that fail.
>
Which removes them all.
>
You need to define how to determine NEED as an algorithm.
>
That mean the decision is based just on what it knows already.
>
Then the results can be compared to the specification to determine it is correct.
>
You can't just "assume" a given algorithm meets a specificaiton, unless the specification is itself an algorithm, which this isnt.
>
As you said, we can't ask H to look into the future, so it can't base its actions on what WILL (or will not) happen in the future.
>
We also can't imagine CHANGING H, as it is what it is, we can imagine something else acting in its stead (but that doesn't affect the definition of H) and H can't act on the imagining, we can only use that to show if it was correct or not.