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

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, if A does return, which means it has decided to abort its simulation (and thus did so incorrectly).
It just isn't possible for the A that B calls to do that.
It IS possible for some other A to do that, but then we need to give them different names, as we have two different "A"s in the same program address space, so we need to quallify the name.
Your problem seems to be that you just don't know the language of Computation Theory well enough to know how to properly describe thinks, and what you need to do in order to try to do so.
The biggest problem seems to be that you don't understand that a program is ONE SPECIFIC SET OF CODE, that FULL describes the steps the program will take. And THAT is the soert of thng that it talks about.
Your "B" as you try to define it, just isn't something in the domain of Computation Theory, as its behavior changes based on something different than it, so asking what "it" does is an improper question.
Thats like asking how much will a box weigh when you fill it, but leave what you will fill it undefined. It could be feathers, or it could be lead, these give different answers.