Re: Olcott IS a Liar!

On 7/7/24 9:11 AM, olcott wrote:

On 7/7/2024 6:13 AM, Richard Damon wrote:

On 7/6/24 11:36 PM, olcott wrote:

On 7/6/2024 10:07 PM, Richard Damon wrote:

On 7/6/24 10:44 PM, olcott wrote:

>
When there is a mandatory sequence you cannot avoid it.
Trying to lie about this proves that you are a liar.
>

>
What What made them mandatory?

>
Reality makes them mandatory.

>
No it doesnnt.
>

I need to find a better example that is airtight.

>
You need to stop lying and thinking your made up examples are real.
>

 Try taking a crap and then pulling your pants
down and sitting on the toilet.
 Try eating some eggs and then taking them out of the
refrigerator and cooking them.

Which are mostly Red Herrings, but do show that you understand some details of determinism. We are willful, but not all powerful, so we are constrained by the determinism of the universe around us.
Just as HHH is stuck in the fact that if it aborts its simulation and returns 0, it does so to ALL callers, even the instance it was simulating and that instance's behavior will continue and do the same thing and get the return value and halt.
Simulating a program is like taking a video of something happening, Just because you turn off the camera, doesn't make what it was recording stop.
Remember, the x86 instruction set defines that instructions DO continuel one after the other.

 

And since the actual topic is the determinism of the program, irrelevant. (But you dare not admit that or you have to face your ignorance)
>

The actual topic is that actions must be taken
in a specific order for the same result to be derived.

No, the topic was that the deterministic behavior of a program

 When you need groceries you cannot truthfully report that
you don't need groceries before you got more groceries.
 Likewise for HHH.

But, if ONE HHH decides to abort its simulaiton of HHH, then ALL

 HHH cannot report that its input would halt
because its input would never halt.

But HHH DOES abort its simulation, becuase that is how it is programmed.
IT GETS NO CHOICE!!!
Yes, you can choose which HHH you are going to enter, but you get no substitutions.
If you put in an HHH that will abort, then its input will halt, and it will be wrong.
If you put in an HHH that doesn't abort, then it will never give an answer.
Basically, you are stuck in a game of NIM where the second player wins, but you are the first player. (As since the decider must handle all input, the input gets chosen second)

 HHH cannot report that the DDD that invoked HHH
will halt because that DDD is not its input.

But it is. The input is the representation of the program, which is the representation of ALL copies of it.
We know that by the fact that all copies of compuations act the same, so HHH needs to take into account its own behavior to figure out what the DDD it is simulating will do. That means, to get a right answer, it needs to have been able to FULLY KNOW what will happen after it aborts if it is to be able to get the right answer.
It can do that for infinite_loop or infinite_recursion (self-recursion) but it can't just brute force the recusive decision loop of DDD calling HHH(DDD).
That doesn't make the problem "wrong", only not solvable by your method. (and in fact, not solvalbe at all, but even that is ok).

 HHH is only the guard of the front gate, its input.
HHH is not the guard of any other gate. HHH cannot
see the program that invokes it.
 

Then HHH isn't doing its job, becuase its programmer is being stupid, and lied on the job application form.
HHH is asked about the program its input represents, not about its own simulation of that input.
The latter question is worthless and invalid, as it is subjective, and mappings are objective (since they don't include the decider as an input).
This is because subjective answers are worthless unless you are that decider, becuase its answer doesn't matter to you. And, with your subjective criteria, we can make a trival version that always answers non-halting, as it can just as correctly determine that it can't simulate the input to a final state as your HHH without doing a single step.
Remember, the input is a FIXED program, and thus THIS DDD calls the HHH that DOES abort and return, so if we change HHH to not abort, but still give it the same input, that input will be able to be simulated to the return, thus, HHH does not need to abort, just that the ones that do get the answer to the input built on them wrong.
That is a result of the determinism that you don't seem to understand.