Re: Undecidability based on epistemological antinomies V2 --H(D,D)--

On 4/24/24 11:53 PM, olcott wrote:

On 4/24/2024 10:38 PM, Richard Damon wrote:

On 4/24/24 10:16 PM, olcott wrote:

On 4/24/2024 9:00 PM, Richard Damon wrote:

On 4/24/24 8:57 PM, olcott wrote:

On 4/24/2024 7:49 PM, Richard Damon wrote:

On 4/24/24 8:17 PM, olcott wrote:

On 4/24/2024 6:01 PM, Richard Damon wrote:

On 4/24/24 11:33 AM, olcott wrote:

On 4/24/2024 3:35 AM, Mikko wrote:

On 2024-04-23 14:31:00 +0000, olcott said:
>

On 4/23/2024 3:21 AM, Mikko wrote:

On 2024-04-22 17:37:55 +0000, olcott said:
>

On 4/22/2024 10:27 AM, Mikko wrote:

On 2024-04-22 14:10:54 +0000, olcott said:
>

On 4/22/2024 4:35 AM, Mikko wrote:

On 2024-04-21 14:44:37 +0000, olcott said:
>

On 4/21/2024 2:57 AM, Mikko wrote:

On 2024-04-20 15:20:05 +0000, olcott said:
>

On 4/20/2024 2:54 AM, Mikko wrote:

On 2024-04-19 18:04:48 +0000, olcott said:
>

When we create a three-valued logic system that has these
three values: {True, False, Nonsense}
https://en.wikipedia.org/wiki/Three-valued_logic

>
Such three valued logic has the problem that a tautology of the
ordinary propositional logic cannot be trusted to be true. For
example, in ordinary logic A ∨ ¬A is always true. This means that
some ordinary proofs of ordinary theorems are no longer valid and
you need to accept the possibility that a theory that is complete
in ordinary logic is incomplete in your logic.
>

>
I only used three-valued logic as a teaching device. Whenever an
expression of language has the value of {Nonsense} then it is
rejected and not allowed to be used in any logical operations. It
is basically invalid input.

>
You cannot teach because you lack necessary skills. Therefore you
don't need any teaching device.
>

>
That is too close to ad homimen.
If you think my reasoning is incorrect then point to the error
in my reasoning. Saying that in your opinion I am a bad teacher
is too close to ad hominem because it refers to your opinion of
me and utterly bypasses any of my reasoning.

>
No, it isn't. You introduced youtself as a topic of discussion so
you are a legitimate topic of discussion.
>
I didn't claim that there be any reasoning, incorrect or otherwise.
>

>
If you claim I am a bad teacher you must point out what is wrong with
the lesson otherwise your claim that I am a bad teacher is essentially
an as hominem attack.

>
You are not a teacher, bad or otherwise. That you lack skills that
happen to be necessary for teaching is obvious from you postings
here. A teacher needs to understand human psychology but you don't.
>

>
You may be correct that I am a terrible teacher.
None-the-less Mathematicians might not have very much understanding
of the link between proof theory and computability.

>
Sume mathematicians do have very much understanding of that. But that
link is not needed for understanding and solving problems separately
in the two areas.
>

When I refer to rejecting an invalid input math would seem to construe
this as nonsense, where as computability theory would totally understand.

>
People working on computability theory do not understand "invalid input"
as "impossible input".

>
The proof then shows, for any program f that might determine whether
programs halt, that a "pathological" program g, called with some input,
can pass its own source and its input to f and then specifically do the
opposite of what f predicts g will do. No f can exist that handles this
case, thus showing undecidability.
https://en.wikipedia.org/wiki/Halting_problem#
>
So then they must believe that there exists an H that does correctly
determine the halt status of every input, some inputs are simply
more difficult than others, no inputs are impossible.

>
That "must" is false as it does not follow from anything.
>

>
Sure it does. If there are no "impossible" inputs that entails
that all inputs are possible. When all inputs are possible then
the halting problem proof is wrong.
>
*Termination Analyzer H is Not Fooled by Pathological Input D*
https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>
Everyone that objects to the statement that H(D,D) correctly determines the halt status of its inputs say that believe that H(D,D) must report on the behavior of the D(D) that invokes H(D,D).

>
Right, because that IS the definition of a Halt Decider.
>

>
Everyone here takes the definition of a halt decider to be
required to determine the halt status of the program that
invokes this halt decider, knowing full well that the program
that invokes this halt decider IS NOT ITS INPUT.

>
And what you don't seem to understand is that it *IS*.
>
The DEFINITION of a Halt Decider is to decide on the program described by it input.
>
What else could that mean but the program described by the input?
>

>
All these same people also know the computable functions only
operate on their inputs and are not allowed to consider anything
else.

>
First, we don't know that a Halt Decider is a "Computable Function" and in fact, that is the question, is the Halting Function computable?
>
Second, the input IS a "Description of the program" to be decided on, so that IS the input.
>
You don't seem to understand the meaning of the word "description"
>

>
Everyone else is wrong about this when they allow a description
to include the program that invokes the halt decider.

>
>
Why?
>
Why can't you describe that program?
>

>
The x86 code is the only description finite string input that H is
allowed to have.

>
And either that can describe the full program D(D), or you are just admitting that H fails to be a Halt Decider by its own limitations.
>
Remember, the REQUIREMENTS prevail, if you somehow restrict H so you can not describe some programs to it, then H BY DEFINITION fails to be the needed decider.
>
>

>

If you can't, then you have just admitted that you decider can't handle ALL possible inputs.
>

>
The D(D) that invokes H(D,D) IS NOT ITS INPUT AND YOU KNOW THAT!

>
Why not? The x86 code given to H it the code for it, at least if you include ALL the x86 code of the full program D.
>
If YOU decided to not give it enough of the description, then you are just admitting to LYING about what you are doing.
>

>

>
These same people already know that the program that invokes
the decider is definitely not its input.

>
But it IS, as that is PRECISELY the program described by the input.
>

>
The D(D) that invokes H(D,D) IS NOT ITS INPUT AND HAS DIFFERENT BEHAVIOR

>
Nope. If H is the required computation, then D is also a computation, and all copies of it behave the same.

  The D(D) that invokes H(D,D) IS NOT ITS INPUT AND HAS DIFFERENT BEHAVIOR
The D(D) that invokes H(D,D) IS NOT ITS INPUT AND HAS DIFFERENT BEHAVIOR
The D(D) that invokes H(D,D) IS NOT ITS INPUT AND HAS DIFFERENT BEHAVIOR

How? The DEFINITION of the question asked by H(D,D) is what is the behavior of the computation D(D).
Remember, the question is: "Does the program represented by the input halt?"
The program represented by the input D,D is the direct execution of D(D).

 The behavior of the simulated D(D) before H aborts its simulation is
The behavior of the simulated D(D) before H aborts its simulation is
The behavior of the simulated D(D) before H aborts its simulation is
 different than the behavior of the executed D(D) after H has aborted its simulation.

Hpw?
What instruction CORRECTLY simulated in the whole program D differs from the actual behavior,
Note, that means the Call H instruction must end up doing exactly the same thing in the simulation as in the actual execution, something your H doesn't do.
Your H's simulation is NOT "correct" as it doesn't actually simulate the call to H, but tries to "deduce" the behavior, and that deduction is incorrect.
Part of your problem is you are not looking at the PROGRAM D as given, which includes the H it is calling, but the template used to build program D, with a funny link to whatever H is trying to decide on it, which ISN'T even a valid program, as a real computation doesn't know the context it is being used in.
You just fail to understand the whole concept of Computation Theory.

different than the behavior of the executed D(D) after H has aborted its simulation.
different than the behavior of the executed D(D) after H has aborted its simulation.
 H(D,D) must report on the behavior that it actually sees.
H(D,D) must report on the behavior that it actually sees.
H(D,D) must report on the behavior that it actually sees.

No, it must report on the behavior of the program described by its input, which is D(D)
Your problem is you don't understnad the meaning of Truth or Requirements.