Re: No one can correctly refute that simulating abort decider A(D,D) is correct

Op 28.mrt.2024 om 20:20 schreef olcott:

On 3/28/2024 2:09 PM, Fred. Zwarts wrote:

Op 28.mrt.2024 om 15:49 schreef olcott:

On 3/28/2024 7:01 AM, Richard Damon wrote:

On 3/27/24 11:32 PM, olcott wrote:

On 3/27/2024 10:25 PM, Richard Damon wrote:

On 3/27/24 11:09 PM, olcott wrote:

On 3/27/2024 9:43 PM, Richard Damon wrote:

On 3/27/24 10:13 PM, olcott wrote:

On 3/27/2024 8:39 PM, Richard Damon wrote:

On 3/27/24 9:10 PM, olcott wrote:

On 3/27/2024 7:48 PM, Richard Damon wrote:

On 3/27/24 4:10 PM, olcott wrote:

On 3/27/2024 2:57 PM, Fred. Zwarts wrote:

Op 27.mrt.2024 om 20:04 schreef olcott:

01 void B(ptr x) // ptr is pointer to void function
02 {
03   A(x, x);
04   return;
05 }
06
07 void main()
08 {
09   A(B,B);
10 }
>
*Execution Trace*
Line 09: main() invokes A(B,B);
>
*keeps repeating* (unless aborted)

That is a premature conclusion when A is not specified.

>
*simulating abort decider* A(D,D)
*simulating abort decider* A(D,D)
*simulating abort decider* A(D,D)
*simulating abort decider* A(D,D)

>
Which just shows your ignorance as that doesn't define what A actually is, or needs to do.
>
You are just demonstrating that you don't know what you are talking about.
>

>

It holds if A does not halt. If A returns, then B will halt (unless aborted).

>
If you honestly don't see that no A can possible return to
any simulated B then you lied about your programming skill.
Otherwise you can see this and are lying about it.

>
It may not be able to simulate a B to the point of seeing an A return to it,

>
*That is the behavior that an abort decider must report on*
*That is the behavior that an abort decider must report on*
*That is the behavior that an abort decider must report on*
>
It is not possible to CORRECTLY simulate a B to the point of seeing
an A return to it because A calls B in recursive simulation.
>

>
Nope, it IS possible to simulate any B to the point of seeing A return,

>
It is impossible for A(B,B) to simulate its input such that any
A ever returns to any B simulated by A because B calls A in recursive
simulation.
>

>
And if the "Definition" of the answer is based on it "Correctly Simulating its input", which it can not do, then you have a problem with your definitions.
>

>
Every A(B,B) simulates its input until it sees the same thing
that you an I have seen for two years.

>
Which is an INCORECT condition for aborting, as it matches some machines that do not need there simulation to be aborted.
>

>

Your problem is you keep on forgetting that at any given time and example, A is a SPECIFIC program, with SPECIFIC behavior and it will either simulate and not abort and not answer, or abort and not show what its input does.

>
I never forget that.
I KNOW THAT IRRELEVANT DIFFERENCES ARE IRRELEVANT
I KNOW THAT IRRELEVANT DIFFERENCES ARE IRRELEVANT
I KNOW THAT IRRELEVANT DIFFERENCES ARE IRRELEVANT

>
But you seem to think that some RELEVERNT differences are IRrelevant, showing you are just stupid.
>
If it makes a difference to the answer, it is relevent.
>

>

>
We can use ANOTHER simulator (perhaps a different version of A, and give it THIS B, connect with that original A, and not itself) to see the right answer.
>

>
Every H(D,D) that simulates its input and does not abort
that simulation is wrong.
>
Every H(D,D) that simulates its input and does abort
that simulation is correct about this abort decision.

>
Nope.
>
Just more of your LIES.
>

>
Yet you cannot point out any mistake because you are lying about there
being any mistake. Every time you try to explain your reasoning about
this it always comes down to this:
>
*Every H(D,D) that needs to abort its input never needed to abort*
*its input because some other H somewhere else that did not abort*
*its input already aborted its input that it never aborted*
>

>
Nope, the fact that you can't even summarize what I said, just shows it is beyound your ability to comprehend.
>
You look at the workd through Olcott glasses, and only see what you want.
>
This makes you blind to the truth, and the truth will crush you.
>
I have explained why you are wrong already elsewhere, and don't need to repeat it.

>
Yes you are great at dogmatically saying that I am wrong.
What you are terrible at is showing any mistake because there are
no mistakes.
>
This is the machine code of D that every H examines.
83c4088945fc837dfc007402ebfe8b45fc8be55dc3
This finite string of bytes never changes.
>

>
This string is incomplete. There is a call to an undefined function in it. Therefore, it is not a program, so no decision can be given for it. A decision can be made only, if the code of the missing function is added as well. This will make the string longer. But only then we know the D for which a decision is required. So, olcott should give the string of (not an incomplete program, but of) the complete program, that includes the H.
It is very cheating to place all the different H functions at the same address and pretend that we are still speaking of the same program.
Therefore, we need a string that describes the full program including H.
>

>
01 int D(ptr x) // ptr is pointer to int function
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 }
>
The question has always been:
Of every element of the infinite set of H/D pairs where H simulates
the above input can any implementation of the above H(D,D) ever stop
running without aborting its simulation of D?
>
>
>

 This is not the answer to the question, but a side track with another question.

Please, give the string of the full program for which a decision has to be made. Even a beginner sees that the behaviour of D depends on the behaviour of H. So a string that does not include H is not a program for which a decision can be made.
Olcott has the code of H, so it must be easy for him to give the string of the full program D that includes H. Why refusing?