A single H can consistently correctly determine whether or not its input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological relative to itself this enables a batch file to invoke H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is identical to H except for
the pathological relationship to H.
A single H can consistently correctly determine whether or not its input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological relative to itself this enables a batch file to invoke H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is identical to H except for
the pathological relationship to H.
A single H can consistently correctly determine whether or not its input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological relative to itself this enables a batch file to invoke H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is identical to H except for
the pathological relationship to H.
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological relative to
itself this enables a batch file to invoke H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is identical to H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your algorithm problems?
Since H(D,D) will (apparently) determine that the input is pathological,
and thus defer to H1(D,D), then when we actually run D, appearently it
will get that same answer from H1 and do the opposite of it, and thus H1
will be wrong.
Remember, the "Pathological" program is built on a copy of the ACTUAL
program that you ask to decide on it, including ALL of its "tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System" outside
the Decider - Input structure, but there isn't, at least not one that
can affect the answer of the problem.
...
This solution does seem to work correctly on every conventional proof in every textbook.
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its input >>> is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological relative to
itself this enables a batch file to invoke H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is identical to H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your algorithm
problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run D,
appearently it will get that same answer from H1 and do the opposite
of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the ACTUAL
program that you ask to decide on it, including ALL of its "tricks",
including things like this "batch processing".
You seem to be assuming that there is some "Operationg System" outside
the Decider - Input structure, but there isn't, at least not one that
can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0 indicating that its input is undecidable. The batch file that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional proof in every textbook.
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its
input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological relative to >>>> itself this enables a batch file to invoke H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is identical to H except for >>>> the pathological relationship to H.
And does an input D that uses this FULL algorithm give your algorithm
problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run D,
appearently it will get that same answer from H1 and do the opposite
of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the ACTUAL
program that you ask to decide on it, including ALL of its "tricks",
including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least not
one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input
working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0
indicating that its input is undecidable. The batch file that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional proof in
every textbook.
So, did you make your "conventional proof" template actually use a copy
of your ACTUAL decider (which seems to be your "batch file" not the C funciton H), or are you just admitting that you wasted 120 hours looking
at the wrong thing because you have made yourself intentionally ignorant
of the subject so you don't understand what you are trying to do.
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its
input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological relative to >>>> itself this enables a batch file to invoke H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is identical to H except for >>>> the pathological relationship to H.
And does an input D that uses this FULL algorithm give your algorithm
problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run D,
appearently it will get that same answer from H1 and do the opposite
of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the ACTUAL
program that you ask to decide on it, including ALL of its "tricks",
including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least not
one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input
working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0
indicating that its input is undecidable. The batch file that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional proof in
every textbook.
So, what is the definition of that "Well Definde Set"? or is this just another of your moronic oxymorons.
Note, H can't have "Modes" that are externally controlled, as it has no
input to control that, it is just a decider that is given an input to
decide on.
If you have some "fuller" algorithm you use to decide that uses the sub-function H to do a step, then D needs to be built on that fuller algorithm, as THAT is what you are actually claiming to be your halt
decider.
I guess you are just making it painfully obvious that you don't
understand the nature of the problem you claim to be working on.
So, since it seems that you have some sort of "batch file" that is your actual decider, you need to show how you have a program invoke that and
do tha tin D. If you can't, you are just admitting that you are not
working on the actual problem defined, but are playing games in the sub-Turing Complete versions of the problem, which has many known
solutions.
It seems that you just wasted 120 hours of work and just proved that you
are totally ignorant of the problem and don't know what you are talking aobut.
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its input >>> is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological relative to
itself this enables a batch file to invoke H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is identical to H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your algorithm
problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run D,
appearently it will get that same answer from H1 and do the opposite
of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the ACTUAL
program that you ask to decide on it, including ALL of its "tricks",
including things like this "batch processing".
You seem to be assuming that there is some "Operationg System" outside
the Decider - Input structure, but there isn't, at least not one that
can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0 indicating that its input is undecidable. The batch file that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional proof in every textbook.
On 7/2/2023 9:37 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its
input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological
relative to
itself this enables a batch file to invoke H1(D,D) to get the actual >>>>> behavior of the directly executed D(D). H1 is identical to H except
for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run
D, appearently it will get that same answer from H1 and do the
opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the
ACTUAL program that you ask to decide on it, including ALL of its
"tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least not
one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input
working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0
indicating that its input is undecidable. The batch file that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional proof in >>> every textbook.
So, what is the definition of that "Well Definde Set"? or is this just
another of your moronic oxymorons.
A set is a well-defined collection of objects called elements or members
of the set. If x is a member of the set S, we write x ∈ S, and if x is a not member of the set S, we write x ∈ S Here, well-defined means that
any given object must either be an element of the set, or not be an
element of the set.
https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf
My definition of well-defined set is that it includes and excludes a
body of finite string pairs such that the second element of this pair
that can be encoded in an infinite number of different ways that cannot
even be foreseen in advance, all of which have the property of a
pathological relationship to their decider.
Since my system requires that the behavior of the input must be
considered in making this assessment it is a semantic property.
Note, H can't have "Modes" that are externally controlled, as it has
no input to control that, it is just a decider that is given an input
to decide on.
Technically you are correct on this when construed as computable
functions.
If you have some "fuller" algorithm you use to decide that uses the
sub-function H to do a step, then D needs to be built on that fuller
algorithm, as THAT is what you are actually claiming to be your halt
decider.
It is only a matter of returning 1 for non-halting and halting inputs
and returning 0 for pathological inputs, thus the actual computation is identical except for a single bit of the return value.
We could also simply run the input where H(D,D) != H1(D,D) means
pathological input, thus accept the H1(D,D) value as correct.
I guess you are just making it painfully obvious that you don't
understand the nature of the problem you claim to be working on.
I foresaw this objection before you made it.
So, since it seems that you have some sort of "batch file" that is
your actual decider, you need to show how you have a program invoke
that and do tha tin D. If you can't, you are just admitting that you
are not working on the actual problem defined, but are playing games
in the sub-Turing Complete versions of the problem, which has many
known solutions.
Batch files and Bash scripts can take different paths depending on the
return value of their executable.
It seems that you just wasted 120 hours of work and just proved that
you are totally ignorant of the problem and don't know what you are
talking aobut.
You will say that no matter how correct that I prove to be.
On 7/2/2023 9:37 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its
input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological
relative to
itself this enables a batch file to invoke H1(D,D) to get the actual >>>>> behavior of the directly executed D(D). H1 is identical to H except
for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run
D, appearently it will get that same answer from H1 and do the
opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the
ACTUAL program that you ask to decide on it, including ALL of its
"tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least not
one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input
working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0
indicating that its input is undecidable. The batch file that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional proof in >>> every textbook.
So, what is the definition of that "Well Definde Set"? or is this just
another of your moronic oxymorons.
A set is a well-defined collection of objects called elements or members
of the set. If x is a member of the set S, we write x ∈ S, and if x is a not member of the set S, we write x ∈ S Here, well-defined means that
any given object must either be an element of the set, or not be an
element of the set.
https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf
My definition of well-defined set is that it includes and excludes a
body of finite string pairs such that the second element of this pair
that can be encoded in an infinite number of different ways that cannot
even be foreseen in advance, all of which have the property of a
pathological relationship to their decider.
Since my system requires that the behavior of the input must be
considered in making this assessment it is a semantic property.
Note, H can't have "Modes" that are externally controlled, as it has
no input to control that, it is just a decider that is given an input
to decide on.
Technically you are correct on this when construed as computable
functions.
If you have some "fuller" algorithm you use to decide that uses the
sub-function H to do a step, then D needs to be built on that fuller
algorithm, as THAT is what you are actually claiming to be your halt
decider.
It is only a matter of returning 1 for non-halting and halting inputs
and returning 0 for pathological inputs, thus the actual computation is identical except for a single bit of the return value.
We could also simply run the input where H(D,D) != H1(D,D) means
pathological input, thus accept the H1(D,D) value as correct.
I guess you are just making it painfully obvious that you don't
understand the nature of the problem you claim to be working on.
I foresaw this objection before you made it.
So, since it seems that you have some sort of "batch file" that is
your actual decider, you need to show how you have a program invoke
that and do tha tin D. If you can't, you are just admitting that you
are not working on the actual problem defined, but are playing games
in the sub-Turing Complete versions of the problem, which has many
known solutions.
Batch files and Bash scripts can take different paths depending on the
return value of their executable.
It seems that you just wasted 120 hours of work and just proved that
you are totally ignorant of the problem and don't know what you are
talking aobut.
You will say that no matter how correct that I prove to be.
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its
input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological
relative to
itself this enables a batch file to invoke H1(D,D) to get the actual >>>>> behavior of the directly executed D(D). H1 is identical to H except
for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run
D, appearently it will get that same answer from H1 and do the
opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the
ACTUAL program that you ask to decide on it, including ALL of its
"tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least not
one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input
working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0
indicating that its input is undecidable. The batch file that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional proof in >>> every textbook.
So, did you make your "conventional proof" template actually use a
copy of your ACTUAL decider (which seems to be your "batch file" not
the C funciton H), or are you just admitting that you wasted 120 hours
looking at the wrong thing because you have made yourself
intentionally ignorant of the subject so you don't understand what you
are trying to do.
New_D copies its input and simulates its input with its input.
It never sees New_H.
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its >>>>>> input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological
relative to
itself this enables a batch file to invoke H1(D,D) to get the actual >>>>>> behavior of the directly executed D(D). H1 is identical to H
except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run
D, appearently it will get that same answer from H1 and do the
opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the
ACTUAL program that you ask to decide on it, including ALL of its
"tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least
not one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input >>>> working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0
indicating that its input is undecidable. The batch file that invoked H >>>> then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional
proof in
every textbook.
So, did you make your "conventional proof" template actually use a
copy of your ACTUAL decider (which seems to be your "batch file" not
the C funciton H), or are you just admitting that you wasted 120
hours looking at the wrong thing because you have made yourself
intentionally ignorant of the subject so you don't understand what
you are trying to do.
New_D copies its input and simulates its input with its input.
It never sees New_H.
Why not? Since New_H is the thing that is considered the "Correct Halt Decider", New_D needs to be built on it.
You keep on forgetting that the proof says we create a specific input
for the given halt decider claimed to be correct, and the only halt
decider that input is claimed to not be decidable with is that one.
SHowing that New_H can answer for the input designed on H means nothing,
you need to show that it can handle the input designed for itself.
THAT is where the actual self-reference occurs, that there exists within
the set of "any program" a program built on the decider in this manner.
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not
its input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological
relative to
itself this enables a batch file to invoke H1(D,D) to get the actual >>>>>>> behavior of the directly executed D(D). H1 is identical to H
except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run >>>>>> D, appearently it will get that same answer from H1 and do the
opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the
ACTUAL program that you ask to decide on it, including ALL of its
"tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least
not one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input >>>>> working. When H(D,D) (in decidability decider mode) detects that its >>>>> input is in the well defined set of pathological inputs it returns 0 >>>>> indicating that its input is undecidable. The batch file that
invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional
proof in
every textbook.
So, did you make your "conventional proof" template actually use a
copy of your ACTUAL decider (which seems to be your "batch file" not
the C funciton H), or are you just admitting that you wasted 120
hours looking at the wrong thing because you have made yourself
intentionally ignorant of the subject so you don't understand what
you are trying to do.
New_D copies its input and simulates its input with its input.
It never sees New_H.
Why not? Since New_H is the thing that is considered the "Correct Halt
Decider", New_D needs to be built on it.
New_H is embedded within New_D (as its middle states) just the
way it is supposed to be. The question is: Does New_H(New_H) halt?
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
You keep on forgetting that the proof says we create a specific input
for the given halt decider claimed to be correct, and the only halt
decider that input is claimed to not be decidable with is that one.
SHowing that New_H can answer for the input designed on H means
nothing, you need to show that it can handle the input designed for
itself.
THAT is where the actual self-reference occurs, that there exists
within the set of "any program" a program built on the decider in this
manner.
On 7/2/23 11:10 PM, olcott wrote:
On 7/2/2023 9:37 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not its >>>>>> input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological
relative to
itself this enables a batch file to invoke H1(D,D) to get the actual >>>>>> behavior of the directly executed D(D). H1 is identical to H
except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run
D, appearently it will get that same answer from H1 and do the
opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the
ACTUAL program that you ask to decide on it, including ALL of its
"tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least
not one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input >>>> working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0
indicating that its input is undecidable. The batch file that invoked H >>>> then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional
proof in
every textbook.
So, what is the definition of that "Well Definde Set"? or is this
just another of your moronic oxymorons.
A set is a well-defined collection of objects called elements or
members of the set. If x is a member of the set S, we write x ∈ S, and
if x is a not member of the set S, we write x ∈ S Here, well-defined
means that any given object must either be an element of the set, or
not be an element of the set.
https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf
My definition of well-defined set is that it includes and excludes a
body of finite string pairs such that the second element of this pair
that can be encoded in an infinite number of different ways that cannot
even be foreseen in advance, all of which have the property of a
pathological relationship to their decider.
And how do you detect this? You just admitted that there are an infinite number of them, so you can't just string compare to detect it.
Since my system requires that the behavior of the input must be
considered in making this assessment it is a semantic property.
But you still haven't described how you detect it.
Note, H can't have "Modes" that are externally controlled, as it has
no input to control that, it is just a decider that is given an input
to decide on.
Technically you are correct on this when construed as computable
functions.
And computations are computable functions. If the function isn't
computable, by definition no program exists that computes it.
Deciders are, by definition, Computations, so again, by definition,
don't have "modes" (except as defined by an actual input).
All this shows is that you ar playing games with words, and have
deceived yourself.
If H has "Modes", it isn't the Decider, so showing that you can get the correct answer for the D built on IT is meaningless, you need to show
you can get the correct answer for the D built on your actual decider,
not just a piece of it.
If you have some "fuller" algorithm you use to decide that uses the
sub-function H to do a step, then D needs to be built on that fuller
algorithm, as THAT is what you are actually claiming to be your halt
decider.
It is only a matter of returning 1 for non-halting and halting inputs
and returning 0 for pathological inputs, thus the actual computation is
identical except for a single bit of the return value.
We could also simply run the input where H(D,D) != H1(D,D) means
pathological input, thus accept the H1(D,D) value as correct.
You need to make clear what type of decider you are defining. If a Halt Decider, then there is no allowed change of answer.
IF you are trying to refute Rice, then you need to clearly define the property that you are going to use, which your above definition requires
a FIXED H/H1 to be defined, and that the property is actually Semantic.
The fact that it is defined by executing your deciders is NOT enough.
One important thing that you seem to be missing is that Rice's Theorem
is NOT about "Programs" and their behavior, but about Functions and languages, and their ability to be recognized by a program.
You still need to show that your property is semantic, and the fact that
you can determine that value without needing to actually run the input
shows that it isn't.
I guess you are just making it painfully obvious that you don't
understand the nature of the problem you claim to be working on.
I foresaw this objection before you made it.
But didn't answer it.
So, since it seems that you have some sort of "batch file" that is
your actual decider, you need to show how you have a program invoke
that and do tha tin D. If you can't, you are just admitting that you
are not working on the actual problem defined, but are playing games
in the sub-Turing Complete versions of the problem, which has many
known solutions.
Batch files and Bash scripts can take different paths depending on the
return value of their executable.
Right, but now the "Decider" is a "Batch Script" so the program D must
be able to do the equivalent of that batch script, or you system doesn't acccept a Turing Complete set.
It seems that you just wasted 120 hours of work and just proved that
you are totally ignorant of the problem and don't know what you are
talking aobut.
You will say that no matter how correct that I prove to be.
Only when I show you are wrong. Actually try to answer my objections
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not >>>>>>>> its input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological
relative to
itself this enables a batch file to invoke H1(D,D) to get the
actual
behavior of the directly executed D(D). H1 is identical to H
except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually
run D, appearently it will get that same answer from H1 and do
the opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the
ACTUAL program that you ask to decide on it, including ALL of its >>>>>>> "tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least >>>>>>> not one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the
input
working. When H(D,D) (in decidability decider mode) detects that its >>>>>> input is in the well defined set of pathological inputs it returns 0 >>>>>> indicating that its input is undecidable. The batch file that
invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional
proof in
every textbook.
So, did you make your "conventional proof" template actually use a
copy of your ACTUAL decider (which seems to be your "batch file"
not the C funciton H), or are you just admitting that you wasted
120 hours looking at the wrong thing because you have made yourself
intentionally ignorant of the subject so you don't understand what
you are trying to do.
New_D copies its input and simulates its input with its input.
It never sees New_H.
Why not? Since New_H is the thing that is considered the "Correct
Halt Decider", New_D needs to be built on it.
New_H is embedded within New_D (as its middle states) just the
way it is supposed to be. The question is: Does New_H(New_H) halt?
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
On 7/2/23 11:54 PM, olcott wrote:
On 7/2/2023 10:10 PM, olcott wrote:
On 7/2/2023 9:37 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not
its input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological
relative to
itself this enables a batch file to invoke H1(D,D) to get the actual >>>>>>> behavior of the directly executed D(D). H1 is identical to H
except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually run >>>>>> D, appearently it will get that same answer from H1 and do the
opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the
ACTUAL program that you ask to decide on it, including ALL of its
"tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System"
outside the Decider - Input structure, but there isn't, at least
not one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the input >>>>> working. When H(D,D) (in decidability decider mode) detects that its >>>>> input is in the well defined set of pathological inputs it returns 0 >>>>> indicating that its input is undecidable. The batch file that
invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.
This solution does seem to work correctly on every conventional
proof in
every textbook.
So, what is the definition of that "Well Definde Set"? or is this
just another of your moronic oxymorons.
A set is a well-defined collection of objects called elements or
members of the set. If x is a member of the set S, we write x ∈ S,
and if x is a not member of the set S, we write x ∈ S Here,
well-defined means that any given object must either be an element of
the set, or not be an element of the set.
https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf
My definition of well-defined set is that it includes and excludes a
body of finite string pairs such that the second element of this pair
that can be encoded in an infinite number of different ways that cannot
even be foreseen in advance, all of which have the property of a
pathological relationship to their decider.
Since my system requires that the behavior of the input must be
considered in making this assessment it is a semantic property.
Note, H can't have "Modes" that are externally controlled, as it has
no input to control that, it is just a decider that is given an
input to decide on.
Technically you are correct on this when construed as computable
functions.
If you have some "fuller" algorithm you use to decide that uses the
sub-function H to do a step, then D needs to be built on that fuller
algorithm, as THAT is what you are actually claiming to be your halt
decider.
It is only a matter of returning 1 for non-halting and halting inputs
and returning 0 for pathological inputs, thus the actual computation is
identical except for a single bit of the return value.
We could also simply run the input where H(D,D) != H1(D,D) means
pathological input, thus accept the H1(D,D) value as correct.
u32 H_DD = H(D,D);
u32 H1_DD = H1(D,D);
if (H_DD != H1_DD)
Output("H1(D,D) correct halt status is:", H1_DD);
H1(D,D) correct halt status is:1
So, what returns the actual results of the Halt decision?
Remember, THAT is what D will call, not H or H1, since neither, by themselves, is a halt decider.
That seems to mean that your ACTUAL Halt Decider HD(P, m) would be
something like:
HD(P, m) {
u32 H_DD = H(P, m);
u32 H1_DD = H1(P, m);
return (H_DD == H1_DD) ? H_DD : H1_DD;
}
and
D is defined something like:
D(P) {
if(HD(P,P)) {
while(1) ;
}
}
Which still gives the wrong answer.
You seem to be forgetting what a Halt Decider needs to be.
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
On 7/3/23 11:10 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 11:54 PM, olcott wrote:
On 7/2/2023 10:10 PM, olcott wrote:
On 7/2/2023 9:37 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not >>>>>>>>> its input
is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>> decidability decider mode determines that D is pathological
relative to
itself this enables a batch file to invoke H1(D,D) to get the >>>>>>>>> actual
behavior of the directly executed D(D). H1 is identical to H >>>>>>>>> except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually >>>>>>>> run D, appearently it will get that same answer from H1 and do >>>>>>>> the opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the >>>>>>>> ACTUAL program that you ask to decide on it, including ALL of
its "tricks", including things like this "batch processing".
You seem to be assuming that there is some "Operationg System" >>>>>>>> outside the Decider - Input structure, but there isn't, at least >>>>>>>> not one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the >>>>>>> input
working. When H(D,D) (in decidability decider mode) detects that its >>>>>>> input is in the well defined set of pathological inputs it returns 0 >>>>>>> indicating that its input is undecidable. The batch file that
invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts. >>>>>>>
This solution does seem to work correctly on every conventional
proof in
every textbook.
So, what is the definition of that "Well Definde Set"? or is this
just another of your moronic oxymorons.
A set is a well-defined collection of objects called elements or
members of the set. If x is a member of the set S, we write x ∈ S, >>>>> and if x is a not member of the set S, we write x ∈ S Here,
well-defined means that any given object must either be an element
of the set, or not be an element of the set.
https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf
My definition of well-defined set is that it includes and excludes a >>>>> body of finite string pairs such that the second element of this pair >>>>> that can be encoded in an infinite number of different ways that
cannot
even be foreseen in advance, all of which have the property of a
pathological relationship to their decider.
Since my system requires that the behavior of the input must be
considered in making this assessment it is a semantic property.
Note, H can't have "Modes" that are externally controlled, as it
has no input to control that, it is just a decider that is given
an input to decide on.
Technically you are correct on this when construed as computable
functions.
If you have some "fuller" algorithm you use to decide that uses
the sub-function H to do a step, then D needs to be built on that
fuller algorithm, as THAT is what you are actually claiming to be
your halt decider.
It is only a matter of returning 1 for non-halting and halting inputs >>>>> and returning 0 for pathological inputs, thus the actual
computation is
identical except for a single bit of the return value.
We could also simply run the input where H(D,D) != H1(D,D) means
pathological input, thus accept the H1(D,D) value as correct.
u32 H_DD = H(D,D);
u32 H1_DD = H1(D,D);
if (H_DD != H1_DD)
Output("H1(D,D) correct halt status is:", H1_DD);
H1(D,D) correct halt status is:1
So, what returns the actual results of the Halt decision?
Remember, THAT is what D will call, not H or H1, since neither, by
themselves, is a halt decider.
That seems to mean that your ACTUAL Halt Decider HD(P, m) would be
something like:
HD(P, m) {
u32 H_DD = H(P, m);
u32 H1_DD = H1(P, m);
return (H_DD == H1_DD) ? H_DD : H1_DD;
}
and
D is defined something like:
D(P) {
if(HD(P,P)) {
while(1) ;
}
}
Which still gives the wrong answer.
You seem to be forgetting what a Halt Decider needs to be.
At the Turing machine level any D can make it impossible for a
particular H to be unable to correctly report on the behavior of the
directly executed D(D). Because D is a fixed constant finite string it
cannot dynamically reconfigure itself to fool a different H.
So, you don't understand the problem.
D doesn't even exist as an input until you define the H
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
After all, ALL inputs to H represent a computation that either Halts or
Not, so "Undecidable" isn't a correct answer for the behavior of that machine.
So, all you are doing is showing that you don't understand that actual problem you claim to be solving.
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or not >>>>>>>>>> its input
is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>> decidability decider mode determines that D is pathological >>>>>>>>>> relative to
itself this enables a batch file to invoke H1(D,D) to get the >>>>>>>>>> actual
behavior of the directly executed D(D). H1 is identical to H >>>>>>>>>> except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your
algorithm problems?
Since H(D,D) will (apparently) determine that the input is
pathological, and thus defer to H1(D,D), then when we actually >>>>>>>>> run D, appearently it will get that same answer from H1 and do >>>>>>>>> the opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the >>>>>>>>> ACTUAL program that you ask to decide on it, including ALL of >>>>>>>>> its "tricks", including things like this "batch processing". >>>>>>>>>
You seem to be assuming that there is some "Operationg System" >>>>>>>>> outside the Decider - Input structure, but there isn't, at
least not one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy the >>>>>>>> input
working. When H(D,D) (in decidability decider mode) detects that >>>>>>>> its
input is in the well defined set of pathological inputs it
returns 0
indicating that its input is undecidable. The batch file that
invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts. >>>>>>>>
This solution does seem to work correctly on every conventional >>>>>>>> proof in
every textbook.
So, did you make your "conventional proof" template actually use >>>>>>> a copy of your ACTUAL decider (which seems to be your "batch
file" not the C funciton H), or are you just admitting that you
wasted 120 hours looking at the wrong thing because you have made >>>>>>> yourself intentionally ignorant of the subject so you don't
understand what you are trying to do.
New_D copies its input and simulates its input with its input.
It never sees New_H.
Why not? Since New_H is the thing that is considered the "Correct
Halt Decider", New_D needs to be built on it.
New_H is embedded within New_D (as its middle states) just the
way it is supposed to be. The question is: Does New_H(New_H) halt?
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly New_H
But New_D needs to call New_H,
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 11:10 AM, olcott wrote:
At the Turing machine level any D can make it impossible for a
particular H to be unable to correctly report on the behavior of the
directly executed D(D). Because D is a fixed constant finite string it
cannot dynamically reconfigure itself to fool a different H.
So, you don't understand the problem.
D doesn't even exist as an input until you define the H
So you want a TM to decide halting for an imaginary input?
That is not the way that computation actually works.
In computability theory and computational complexity theory, a decision problem is a computational problem that can be posed as a yes–no
question of the input values.
https://en.wikipedia.org/wiki/Decision_problem
TM's do not take ideas held within the mind as their inputs, they only
take fixed constant finite strings as inputs.
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
After all, ALL inputs to H represent a computation that either Halts or
Not, so "Undecidable" isn't a correct answer for the behavior of that machine.
So, all you are doing is showing that you don't understand that actual problem you claim to be solving.
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or >>>>>>>>>>> not its input
is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>>> decidability decider mode determines that D is pathological >>>>>>>>>>> relative to
itself this enables a batch file to invoke H1(D,D) to get the >>>>>>>>>>> actual
behavior of the directly executed D(D). H1 is identical to H >>>>>>>>>>> except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your >>>>>>>>>> algorithm problems?
Since H(D,D) will (apparently) determine that the input is >>>>>>>>>> pathological, and thus defer to H1(D,D), then when we actually >>>>>>>>>> run D, appearently it will get that same answer from H1 and do >>>>>>>>>> the opposite of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a copy of the >>>>>>>>>> ACTUAL program that you ask to decide on it, including ALL of >>>>>>>>>> its "tricks", including things like this "batch processing". >>>>>>>>>>
You seem to be assuming that there is some "Operationg System" >>>>>>>>>> outside the Decider - Input structure, but there isn't, at >>>>>>>>>> least not one that can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting the copy >>>>>>>>> the input
working. When H(D,D) (in decidability decider mode) detects
that its
input is in the well defined set of pathological inputs it
returns 0
indicating that its input is undecidable. The batch file that >>>>>>>>> invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts. >>>>>>>>>
This solution does seem to work correctly on every conventional >>>>>>>>> proof in
every textbook.
So, did you make your "conventional proof" template actually use >>>>>>>> a copy of your ACTUAL decider (which seems to be your "batch
file" not the C funciton H), or are you just admitting that you >>>>>>>> wasted 120 hours looking at the wrong thing because you have
made yourself intentionally ignorant of the subject so you don't >>>>>>>> understand what you are trying to do.
New_D copies its input and simulates its input with its input.
It never sees New_H.
Why not? Since New_H is the thing that is considered the "Correct
Halt Decider", New_D needs to be built on it.
New_H is embedded within New_D (as its middle states) just the
way it is supposed to be. The question is: Does New_H(New_H) halt?
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about
inserting bugs into a halt decider to make it cease to function.
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or >>>>>>>>>>>> not its input
is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>>>> decidability decider mode determines that D is pathological >>>>>>>>>>>> relative to
itself this enables a batch file to invoke H1(D,D) to get >>>>>>>>>>>> the actual
behavior of the directly executed D(D). H1 is identical to H >>>>>>>>>>>> except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your >>>>>>>>>>> algorithm problems?
Since H(D,D) will (apparently) determine that the input is >>>>>>>>>>> pathological, and thus defer to H1(D,D), then when we
actually run D, appearently it will get that same answer from >>>>>>>>>>> H1 and do the opposite of it, and thus H1 will be wrong. >>>>>>>>>>>
Remember, the "Pathological" program is built on a copy of >>>>>>>>>>> the ACTUAL program that you ask to decide on it, including >>>>>>>>>>> ALL of its "tricks", including things like this "batch
processing".
You seem to be assuming that there is some "Operationg
System" outside the Decider - Input structure, but there >>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>> problem.
I spent 12 hours a day for the last 10 days getting the copy >>>>>>>>>> the input
working. When H(D,D) (in decidability decider mode) detects >>>>>>>>>> that its
input is in the well defined set of pathological inputs it >>>>>>>>>> returns 0
indicating that its input is undecidable. The batch file that >>>>>>>>>> invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts. >>>>>>>>>>
This solution does seem to work correctly on every
conventional proof in
every textbook.
So, did you make your "conventional proof" template actually >>>>>>>>> use a copy of your ACTUAL decider (which seems to be your
"batch file" not the C funciton H), or are you just admitting >>>>>>>>> that you wasted 120 hours looking at the wrong thing because >>>>>>>>> you have made yourself intentionally ignorant of the subject so >>>>>>>>> you don't understand what you are trying to do.
New_D copies its input and simulates its input with its input. >>>>>>>> It never sees New_H.
Why not? Since New_H is the thing that is considered the "Correct >>>>>>> Halt Decider", New_D needs to be built on it.
New_H is embedded within New_D (as its middle states) just the
way it is supposed to be. The question is: Does New_H(New_H) halt? >>>>>>
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about
inserting bugs into a halt decider to make it cease to function.
Right, and in Linz, H is the decider that is claimed to give the right answer.
That isn't 'H' in your system, but the script that decides whether to
use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name for things.
On 7/3/23 11:41 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 11:10 AM, olcott wrote:
At the Turing machine level any D can make it impossible for a
particular H to be unable to correctly report on the behavior of the
directly executed D(D). Because D is a fixed constant finite string it >>>> cannot dynamically reconfigure itself to fool a different H.
So, you don't understand the problem.
D doesn't even exist as an input until you define the H
So you want a TM to decide halting for an imaginary input?
That is not the way that computation actually works.
Nope, it must decide for ALL inputs, even those that haven't been
'created' yet.
Once you create H, you can create D. That will be one of the infinite
set of possible inputs that H was designed to decide on.
When we RUN H, the input exists. Until you decide on what H will be, we
don't know which of all the possible inputs D will be.
In computability theory and computational complexity theory, a decision
problem is a computational problem that can be posed as a yes–no
question of the input values.
https://en.wikipedia.org/wiki/Decision_problem
Right, and it must accept ALL inputs, it can take the input based on
itself, which we don't know which one it will be until we define the
decider.
TM's do not take ideas held within the mind as their inputs, they only
take fixed constant finite strings as inputs.
Right, but since it takes ALL inputs, it can take an input based on
itself,
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of
the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' output state
either.
Either the input is or is not something that is in the set defined by
the function/language defined.
Undecidable is just admitting that Rice is true.
After all, ALL inputs to H represent a computation that either Halts
or Not, so "Undecidable" isn't a correct answer for the behavior of
that machine.
So, all you are doing is showing that you don't understand that
actual problem you claim to be solving.
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or >>>>>>>>>>>>> not its input
is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>>>>> decidability decider mode determines that D is pathological >>>>>>>>>>>>> relative to
itself this enables a batch file to invoke H1(D,D) to get >>>>>>>>>>>>> the actual
behavior of the directly executed D(D). H1 is identical to >>>>>>>>>>>>> H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your >>>>>>>>>>>> algorithm problems?
Since H(D,D) will (apparently) determine that the input is >>>>>>>>>>>> pathological, and thus defer to H1(D,D), then when we
actually run D, appearently it will get that same answer >>>>>>>>>>>> from H1 and do the opposite of it, and thus H1 will be wrong. >>>>>>>>>>>>
Remember, the "Pathological" program is built on a copy of >>>>>>>>>>>> the ACTUAL program that you ask to decide on it, including >>>>>>>>>>>> ALL of its "tricks", including things like this "batch >>>>>>>>>>>> processing".
You seem to be assuming that there is some "Operationg >>>>>>>>>>>> System" outside the Decider - Input structure, but there >>>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>>> problem.
I spent 12 hours a day for the last 10 days getting the copy >>>>>>>>>>> the input
working. When H(D,D) (in decidability decider mode) detects >>>>>>>>>>> that its
input is in the well defined set of pathological inputs it >>>>>>>>>>> returns 0
indicating that its input is undecidable. The batch file that >>>>>>>>>>> invoked H
then knows to invoke H1(D,D) to correctly report that D(D) >>>>>>>>>>> halts.
This solution does seem to work correctly on every
conventional proof in
every textbook.
So, did you make your "conventional proof" template actually >>>>>>>>>> use a copy of your ACTUAL decider (which seems to be your
"batch file" not the C funciton H), or are you just admitting >>>>>>>>>> that you wasted 120 hours looking at the wrong thing because >>>>>>>>>> you have made yourself intentionally ignorant of the subject >>>>>>>>>> so you don't understand what you are trying to do.
New_D copies its input and simulates its input with its input. >>>>>>>>> It never sees New_H.
Why not? Since New_H is the thing that is considered the
"Correct Halt Decider", New_D needs to be built on it.
New_H is embedded within New_D (as its middle states) just the
way it is supposed to be. The question is: Does New_H(New_H) halt? >>>>>>>
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about
inserting bugs into a halt decider to make it cease to function.
Right, and in Linz, H is the decider that is claimed to give the right
answer.
That isn't 'H' in your system, but the script that decides whether to
use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name for things.
You are using double-talk in a lame attempt to show that
Linz H cannot correctly determine the halt status of Linz Ĥ.
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether or >>>>>>>>>>>>>> not its input
is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>>>>>> decidability decider mode determines that D is
pathological relative to
itself this enables a batch file to invoke H1(D,D) to get >>>>>>>>>>>>>> the actual
behavior of the directly executed D(D). H1 is identical to >>>>>>>>>>>>>> H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give your >>>>>>>>>>>>> algorithm problems?
Since H(D,D) will (apparently) determine that the input is >>>>>>>>>>>>> pathological, and thus defer to H1(D,D), then when we >>>>>>>>>>>>> actually run D, appearently it will get that same answer >>>>>>>>>>>>> from H1 and do the opposite of it, and thus H1 will be wrong. >>>>>>>>>>>>>
Remember, the "Pathological" program is built on a copy of >>>>>>>>>>>>> the ACTUAL program that you ask to decide on it, including >>>>>>>>>>>>> ALL of its "tricks", including things like this "batch >>>>>>>>>>>>> processing".
You seem to be assuming that there is some "Operationg >>>>>>>>>>>>> System" outside the Decider - Input structure, but there >>>>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>>>> problem.
I spent 12 hours a day for the last 10 days getting the copy >>>>>>>>>>>> the input
working. When H(D,D) (in decidability decider mode) detects >>>>>>>>>>>> that its
input is in the well defined set of pathological inputs it >>>>>>>>>>>> returns 0
indicating that its input is undecidable. The batch file >>>>>>>>>>>> that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) >>>>>>>>>>>> halts.
This solution does seem to work correctly on every
conventional proof in
every textbook.
So, did you make your "conventional proof" template actually >>>>>>>>>>> use a copy of your ACTUAL decider (which seems to be your >>>>>>>>>>> "batch file" not the C funciton H), or are you just admitting >>>>>>>>>>> that you wasted 120 hours looking at the wrong thing because >>>>>>>>>>> you have made yourself intentionally ignorant of the subject >>>>>>>>>>> so you don't understand what you are trying to do.
New_D copies its input and simulates its input with its input. >>>>>>>>>> It never sees New_H.
Why not? Since New_H is the thing that is considered the
"Correct Halt Decider", New_D needs to be built on it.
New_H is embedded within New_D (as its middle states) just the >>>>>>>> way it is supposed to be. The question is: Does New_H(New_H) halt? >>>>>>>>
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about
inserting bugs into a halt decider to make it cease to function.
Right, and in Linz, H is the decider that is claimed to give the
right answer.
That isn't 'H' in your system, but the script that decides whether to
use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name for things.
You are using double-talk in a lame attempt to show that
Linz H cannot correctly determine the halt status of Linz Ĥ.
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status of Linz Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the results of the
'Linz Ĥ' built on it. You keep on changing H and trying to use the old Ĥ which just fails to meet the requirement of the proof, likely because
you just don't understand the theory involved.
On 7/3/23 12:09 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:41 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 11:10 AM, olcott wrote:
At the Turing machine level any D can make it impossible for a
particular H to be unable to correctly report on the behavior of the >>>>>> directly executed D(D). Because D is a fixed constant finite
string it
cannot dynamically reconfigure itself to fool a different H.
So, you don't understand the problem.
D doesn't even exist as an input until you define the H
So you want a TM to decide halting for an imaginary input?
That is not the way that computation actually works.
Nope, it must decide for ALL inputs, even those that haven't been
'created' yet.
Once you create H, you can create D. That will be one of the infinite
set of possible inputs that H was designed to decide on.
When we RUN H, the input exists. Until you decide on what H will be,
we don't know which of all the possible inputs D will be.
In computability theory and computational complexity theory, a decision >>>> problem is a computational problem that can be posed as a yes–no
question of the input values.
https://en.wikipedia.org/wiki/Decision_problem
Right, and it must accept ALL inputs, it can take the input based on
itself, which we don't know which one it will be until we define the
decider.
TM's do not take ideas held within the mind as their inputs, they only >>>> take fixed constant finite strings as inputs.
Right, but since it takes ALL inputs, it can take an input based on
itself,
None-the-less you continue to assert that it must take ideas as inputs.
It just doesn't work that way.
Nope, Where did I say THAT.
Nope, it must decide for ALL inputs, even those that haven't been
'created' yet.
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my objections >>>>>>
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of
the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' output state
either.
Either the input is or is not something that is in the set defined by
the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic property, but is
an answer for if an input <HAS> some specific semantic property.
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether >>>>>>>>>>>>>>> or not its input
is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>> invoked in
decidability decider mode determines that D is
pathological relative to
itself this enables a batch file to invoke H1(D,D) to get >>>>>>>>>>>>>>> the actual
behavior of the directly executed D(D). H1 is identical >>>>>>>>>>>>>>> to H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give >>>>>>>>>>>>>> your algorithm problems?
Since H(D,D) will (apparently) determine that the input is >>>>>>>>>>>>>> pathological, and thus defer to H1(D,D), then when we >>>>>>>>>>>>>> actually run D, appearently it will get that same answer >>>>>>>>>>>>>> from H1 and do the opposite of it, and thus H1 will be wrong. >>>>>>>>>>>>>>
Remember, the "Pathological" program is built on a copy of >>>>>>>>>>>>>> the ACTUAL program that you ask to decide on it, including >>>>>>>>>>>>>> ALL of its "tricks", including things like this "batch >>>>>>>>>>>>>> processing".
You seem to be assuming that there is some "Operationg >>>>>>>>>>>>>> System" outside the Decider - Input structure, but there >>>>>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>>>>> problem.
I spent 12 hours a day for the last 10 days getting the >>>>>>>>>>>>> copy the input
working. When H(D,D) (in decidability decider mode) detects >>>>>>>>>>>>> that its
input is in the well defined set of pathological inputs it >>>>>>>>>>>>> returns 0
indicating that its input is undecidable. The batch file >>>>>>>>>>>>> that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) >>>>>>>>>>>>> halts.
This solution does seem to work correctly on every
conventional proof in
every textbook.
So, did you make your "conventional proof" template actually >>>>>>>>>>>> use a copy of your ACTUAL decider (which seems to be your >>>>>>>>>>>> "batch file" not the C funciton H), or are you just
admitting that you wasted 120 hours looking at the wrong >>>>>>>>>>>> thing because you have made yourself intentionally ignorant >>>>>>>>>>>> of the subject so you don't understand what you are trying >>>>>>>>>>>> to do.
New_D copies its input and simulates its input with its input. >>>>>>>>>>> It never sees New_H.
Why not? Since New_H is the thing that is considered the
"Correct Halt Decider", New_D needs to be built on it.
New_H is embedded within New_D (as its middle states) just the >>>>>>>>> way it is supposed to be. The question is: Does New_H(New_H) halt? >>>>>>>>>
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly New_H >>>>>>>
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about
inserting bugs into a halt decider to make it cease to function.
Right, and in Linz, H is the decider that is claimed to give the
right answer.
That isn't 'H' in your system, but the script that decides whether
to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name for things.
You are using double-talk in a lame attempt to show that
Linz H cannot correctly determine the halt status of Linz Ĥ.
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status of Linz Ĥ
applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the results of the
'Linz Ĥ' built on it. You keep on changing H and trying to use the old
Ĥ which just fails to meet the requirement of the proof, likely
because you just don't understand the theory involved.
It took me two years to figure out a clean way to copy the input to Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
Linz_H is H1. Now Linz_H_Hat only contradicts itself.
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:You are using double-talk in a lame attempt to show that
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine whether >>>>>>>>>>>>>>>> or not its input
is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>> invoked in
decidability decider mode determines that D is >>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke H1(D,D) to >>>>>>>>>>>>>>>> get the actual
behavior of the directly executed D(D). H1 is identical >>>>>>>>>>>>>>>> to H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give >>>>>>>>>>>>>>> your algorithm problems?
Since H(D,D) will (apparently) determine that the input >>>>>>>>>>>>>>> is pathological, and thus defer to H1(D,D), then when we >>>>>>>>>>>>>>> actually run D, appearently it will get that same answer >>>>>>>>>>>>>>> from H1 and do the opposite of it, and thus H1 will be >>>>>>>>>>>>>>> wrong.
Remember, the "Pathological" program is built on a copy >>>>>>>>>>>>>>> of the ACTUAL program that you ask to decide on it, >>>>>>>>>>>>>>> including ALL of its "tricks", including things like this >>>>>>>>>>>>>>> "batch processing".
You seem to be assuming that there is some "Operationg >>>>>>>>>>>>>>> System" outside the Decider - Input structure, but there >>>>>>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>>>>>> problem.
I spent 12 hours a day for the last 10 days getting the >>>>>>>>>>>>>> copy the input
working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>> detects that its
input is in the well defined set of pathological inputs it >>>>>>>>>>>>>> returns 0
indicating that its input is undecidable. The batch file >>>>>>>>>>>>>> that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) >>>>>>>>>>>>>> halts.
This solution does seem to work correctly on every >>>>>>>>>>>>>> conventional proof in
every textbook.
So, did you make your "conventional proof" template
actually use a copy of your ACTUAL decider (which seems to >>>>>>>>>>>>> be your "batch file" not the C funciton H), or are you just >>>>>>>>>>>>> admitting that you wasted 120 hours looking at the wrong >>>>>>>>>>>>> thing because you have made yourself intentionally ignorant >>>>>>>>>>>>> of the subject so you don't understand what you are trying >>>>>>>>>>>>> to do.
New_D copies its input and simulates its input with its input. >>>>>>>>>>>> It never sees New_H.
Why not? Since New_H is the thing that is considered the >>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it.
New_H is embedded within New_D (as its middle states) just the >>>>>>>>>> way it is supposed to be. The question is: Does New_H(New_H) >>>>>>>>>> halt?
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly New_H >>>>>>>>
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about
inserting bugs into a halt decider to make it cease to function.
Right, and in Linz, H is the decider that is claimed to give the
right answer.
That isn't 'H' in your system, but the script that decides whether
to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name for things. >>>>
Linz H cannot correctly determine the halt status of Linz Ĥ.
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status of Linz
Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the results of the
'Linz Ĥ' built on it. You keep on changing H and trying to use the
old Ĥ which just fails to meet the requirement of the proof, likely
because you just don't understand the theory involved.
It took me two years to figure out a clean way to copy the input to
Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is required?
Copying the input should be trivial,
as the input should be a
representation that packages a full program in its own virtual
environment, so a simple bit by bit copy to empty ram will work. Your
problem is that you don't put the input into its own virtual address
space, so you have pathological interactions.
Linz_H_Hat must be built on the exact code base that is deciding on it,
in this case H, since you just said it isn't, your proof is invalid.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
truth values, only behavior. You are just showing that you don't
understand the basics of the requirements, and seem to think that
"close" is good enough for proofs.
On 7/3/23 2:00 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:09 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:41 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 11:10 AM, olcott wrote:
At the Turing machine level any D can make it impossible for a >>>>>>>> particular H to be unable to correctly report on the behavior of >>>>>>>> the
directly executed D(D). Because D is a fixed constant finite
string it
cannot dynamically reconfigure itself to fool a different H.
So, you don't understand the problem.
D doesn't even exist as an input until you define the H
So you want a TM to decide halting for an imaginary input?
That is not the way that computation actually works.
Nope, it must decide for ALL inputs, even those that haven't been
'created' yet.
Once you create H, you can create D. That will be one of the
infinite set of possible inputs that H was designed to decide on.
When we RUN H, the input exists. Until you decide on what H will
be, we don't know which of all the possible inputs D will be.
In computability theory and computational complexity theory, a
decision
problem is a computational problem that can be posed as a yes–no >>>>>> question of the input values.
https://en.wikipedia.org/wiki/Decision_problem
Right, and it must accept ALL inputs, it can take the input based
on itself, which we don't know which one it will be until we define
the decider.
TM's do not take ideas held within the mind as their inputs, they
only
take fixed constant finite strings as inputs.
Right, but since it takes ALL inputs, it can take an input based on
itself,
None-the-less you continue to assert that it must take ideas as inputs. >>>> It just doesn't work that way.
Nope, Where did I say THAT.
On 7/3/2023 10:58 AM, Richard Damon wrote:
Nope, it must decide for ALL inputs, even those that haven't been
'created' yet.
Right, haven't been created at the time the decider is created, but will
have been when it is run.
On 7/3/23 2:03 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my
objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of
the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' output
state either.
Either the input is or is not something that is in the set defined
by the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic property, but
is an answer for if an input <HAS> some specific semantic property.
In computability theory, Rice's theorem states that all non-trivial
semantic properties of programs are undecidable. A semantic property is
one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Undecidable <is> a semantic property of the finite string pair: {H,D}.
As I mentioned, many simple descriptions get it wrong. Note, later in
the same page it says:
It is important to note that Rice's theorem does not concern the
properties of machines or programs; it concerns properties of functions
and languages.
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:00 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:09 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:41 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 11:10 AM, olcott wrote:
At the Turing machine level any D can make it impossible for a >>>>>>>>> particular H to be unable to correctly report on the behavior >>>>>>>>> of the
directly executed D(D). Because D is a fixed constant finite >>>>>>>>> string it
cannot dynamically reconfigure itself to fool a different H. >>>>>>>>>
So, you don't understand the problem.
D doesn't even exist as an input until you define the H
So you want a TM to decide halting for an imaginary input?
That is not the way that computation actually works.
Nope, it must decide for ALL inputs, even those that haven't been
'created' yet.
Once you create H, you can create D. That will be one of the
infinite set of possible inputs that H was designed to decide on.
When we RUN H, the input exists. Until you decide on what H will
be, we don't know which of all the possible inputs D will be.
In computability theory and computational complexity theory, a
decision
problem is a computational problem that can be posed as a yes–no >>>>>>> question of the input values.
https://en.wikipedia.org/wiki/Decision_problem
Right, and it must accept ALL inputs, it can take the input based
on itself, which we don't know which one it will be until we
define the decider.
TM's do not take ideas held within the mind as their inputs, they >>>>>>> only
take fixed constant finite strings as inputs.
Right, but since it takes ALL inputs, it can take an input based
on itself,
None-the-less you continue to assert that it must take ideas as
inputs.
It just doesn't work that way.
Nope, Where did I say THAT.
On 7/3/2023 10:58 AM, Richard Damon wrote:
Nope, it must decide for ALL inputs, even those that haven't been
'created' yet.
Right, haven't been created at the time the decider is created, but
will have been when it is run.
Not unless the guy that wrote the decider also wrote its input.
Until then the input you refer to is only imaginary.
On 7/3/23 2:49 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:00 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:09 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:41 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 11:10 AM, olcott wrote:
At the Turing machine level any D can make it impossible for a >>>>>>>>>> particular H to be unable to correctly report on the behavior >>>>>>>>>> of the
directly executed D(D). Because D is a fixed constant finite >>>>>>>>>> string it
cannot dynamically reconfigure itself to fool a different H. >>>>>>>>>>
So, you don't understand the problem.
D doesn't even exist as an input until you define the H
So you want a TM to decide halting for an imaginary input?
That is not the way that computation actually works.
Nope, it must decide for ALL inputs, even those that haven't been >>>>>>> 'created' yet.
Once you create H, you can create D. That will be one of the
infinite set of possible inputs that H was designed to decide on. >>>>>>>
When we RUN H, the input exists. Until you decide on what H will >>>>>>> be, we don't know which of all the possible inputs D will be.
In computability theory and computational complexity theory, a >>>>>>>> decision
problem is a computational problem that can be posed as a yes–no >>>>>>>> question of the input values.
https://en.wikipedia.org/wiki/Decision_problem
Right, and it must accept ALL inputs, it can take the input based >>>>>>> on itself, which we don't know which one it will be until we
define the decider.
TM's do not take ideas held within the mind as their inputs,
they only
take fixed constant finite strings as inputs.
Right, but since it takes ALL inputs, it can take an input based >>>>>>> on itself,
None-the-less you continue to assert that it must take ideas as
inputs.
It just doesn't work that way.
Nope, Where did I say THAT.
On 7/3/2023 10:58 AM, Richard Damon wrote:
Nope, it must decide for ALL inputs, even those that haven't been
'created' yet.
Right, haven't been created at the time the decider is created, but
will have been when it is run.
Not unless the guy that wrote the decider also wrote its input.
Until then the input you refer to is only imaginary.
Why do you say that? As I said, it actually exist when we run the
decider on it.
On 7/3/23 2:56 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:03 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my >>>>>>>>>>> objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of >>>>>>>> the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' output
state either.
Either the input is or is not something that is in the set
defined by the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic property, but
is an answer for if an input <HAS> some specific semantic property.
In computability theory, Rice's theorem states that all non-trivial
semantic properties of programs are undecidable. A semantic property is >>>> one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Undecidable <is> a semantic property of the finite string pair: {H,D}. >>>>
As I mentioned, many simple descriptions get it wrong. Note, later in
the same page it says:
It is important to note that Rice's theorem does not concern the
properties of machines or programs; it concerns properties of
functions and languages.
H correctly accepts every language specified by the pair: {H, *}
(where the first element is the machine description of H and the
second element is any other machine description) or rejects this
pair as undecidable.
So, you are admitting you don't understand what you are saying.
D isn't "undecidable" but always has definite behavior based on the
behavior of the definite machine H that it was based on (and thus you
are being INTENTIONALLY dupicious by now calling H to be a some sort of
other decider).
Since you claim that Halt-Decider-H "Correctly" returned false for
H(D,D) we know that D(D) Halts, so D the problem of D has an answer so
hard to call "undecidable"
Again, what is the definition of your "Language", and why do you call
{H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider that is
just WRONG about its input, that isn't "undecidable".
On 7/3/23 2:56 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:03 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my >>>>>>>>>>> objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of >>>>>>>> the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' output
state either.
Either the input is or is not something that is in the set
defined by the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic property, but
is an answer for if an input <HAS> some specific semantic property.
In computability theory, Rice's theorem states that all non-trivial
semantic properties of programs are undecidable. A semantic property is >>>> one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Undecidable <is> a semantic property of the finite string pair: {H,D}. >>>>
As I mentioned, many simple descriptions get it wrong. Note, later in
the same page it says:
It is important to note that Rice's theorem does not concern the
properties of machines or programs; it concerns properties of
functions and languages.
H correctly accepts every language specified by the pair: {H, *}
(where the first element is the machine description of H and the
second element is any other machine description) or rejects this
pair as undecidable.
So, you are admitting you don't understand what you are saying.
D isn't "undecidable" but always has definite behavior based on the
behavior of the definite machine H that it was based on (and thus you
are being INTENTIONALLY dupicious by now calling H to be a some sort of
other decider).
Since you claim that Halt-Decider-H "Correctly" returned false for
H(D,D) we know that D(D) Halts, so D the problem of D has an answer so
hard to call "undecidable"
Again, what is the definition of your "Language", and why do you call
{H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider that is
just WRONG about its input, that isn't "undecidable".
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine >>>>>>>>>>>>>>>>>> whether or not its input
is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>> invoked in
decidability decider mode determines that D is >>>>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke H1(D,D) to >>>>>>>>>>>>>>>>>> get the actual
behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>> identical to H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give >>>>>>>>>>>>>>>>> your algorithm problems?
Since H(D,D) will (apparently) determine that the input >>>>>>>>>>>>>>>>> is pathological, and thus defer to H1(D,D), then when >>>>>>>>>>>>>>>>> we actually run D, appearently it will get that same >>>>>>>>>>>>>>>>> answer from H1 and do the opposite of it, and thus H1 >>>>>>>>>>>>>>>>> will be wrong.
Remember, the "Pathological" program is built on a copy >>>>>>>>>>>>>>>>> of the ACTUAL program that you ask to decide on it, >>>>>>>>>>>>>>>>> including ALL of its "tricks", including things like >>>>>>>>>>>>>>>>> this "batch processing".
You seem to be assuming that there is some "Operationg >>>>>>>>>>>>>>>>> System" outside the Decider - Input structure, but >>>>>>>>>>>>>>>>> there isn't, at least not one that can affect the >>>>>>>>>>>>>>>>> answer of the problem.
I spent 12 hours a day for the last 10 days getting the >>>>>>>>>>>>>>>> copy the input
working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>> detects that its
input is in the well defined set of pathological inputs >>>>>>>>>>>>>>>> it returns 0
indicating that its input is undecidable. The batch file >>>>>>>>>>>>>>>> that invoked H
then knows to invoke H1(D,D) to correctly report that >>>>>>>>>>>>>>>> D(D) halts.
This solution does seem to work correctly on every >>>>>>>>>>>>>>>> conventional proof in
every textbook.
So, did you make your "conventional proof" template >>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which seems >>>>>>>>>>>>>>> to be your "batch file" not the C funciton H), or are you >>>>>>>>>>>>>>> just admitting that you wasted 120 hours looking at the >>>>>>>>>>>>>>> wrong thing because you have made yourself intentionally >>>>>>>>>>>>>>> ignorant of the subject so you don't understand what you >>>>>>>>>>>>>>> are trying to do.
New_D copies its input and simulates its input with its >>>>>>>>>>>>>> input.
It never sees New_H.
Why not? Since New_H is the thing that is considered the >>>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>
New_H is embedded within New_D (as its middle states) just the >>>>>>>>>>>> way it is supposed to be. The question is: Does New_H(New_H) >>>>>>>>>>>> halt?
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly New_H >>>>>>>>>>
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about >>>>>>>> inserting bugs into a halt decider to make it cease to function. >>>>>>>>
Right, and in Linz, H is the decider that is claimed to give the >>>>>>> right answer.
That isn't 'H' in your system, but the script that decides
whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name for
things.
You are using double-talk in a lame attempt to show that
Linz H cannot correctly determine the halt status of Linz Ĥ.
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status of
Linz Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the results of
the 'Linz Ĥ' built on it. You keep on changing H and trying to use
the old Ĥ which just fails to meet the requirement of the proof,
likely because you just don't understand the theory involved.
It took me two years to figure out a clean way to copy the input to
Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is required?
Copying the input should be trivial,
The relative addressing of the x86 language causes all function
calls to call the wrong address.
Only because you aren't interpreting the input properly, but in a
non-Turing Complete manner.
As I said, the input description should be a chunck of code in a virtual address space with a header that tells where that code is supposed to be considered to be located at.
as the input should be a representation that packages a full program
in its own virtual environment, so a simple bit by bit copy to empty
ram will work. Your problem is that you don't put the input into its
own virtual address space, so you have pathological interactions.
Linz_H_Hat must be built on the exact code base that is deciding on
it, in this case H, since you just said it isn't, your proof is invalid. >>>
Linz_Hat <is> Linz_H that takes one param and copies it instead of
two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
You don't seem to understand what you are doing.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined behavior.
That behavior is a function of its input, but hasn't been assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that has a defined meaning/requirement for its final states. Linz_H, to meet its
requirements, MUST go to Qy if the input represents a Halting
Computation, and MUST go to Qn if the input represents a non-halting computation.
Since Linz_H has actual requirements, a claimed implementation of it can
be checked to see if it actually meets the requirements, and perhaps we
can determine if it is possible to meet them.
defined meaning for Linz_H_Hat as it isn't defined to be a decider.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
truth values, only behavior. You are just showing that you don't
understand the basics of the requirements, and seem to think that
"close" is good enough for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:49 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:00 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:09 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:41 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 11:10 AM, olcott wrote:
At the Turing machine level any D can make it impossible for a >>>>>>>>>>> particular H to be unable to correctly report on the behavior >>>>>>>>>>> of the
directly executed D(D). Because D is a fixed constant finite >>>>>>>>>>> string it
cannot dynamically reconfigure itself to fool a different H. >>>>>>>>>>>
So, you don't understand the problem.
D doesn't even exist as an input until you define the H
So you want a TM to decide halting for an imaginary input?
That is not the way that computation actually works.
Nope, it must decide for ALL inputs, even those that haven't
been 'created' yet.
Once you create H, you can create D. That will be one of the
infinite set of possible inputs that H was designed to decide on. >>>>>>>>
When we RUN H, the input exists. Until you decide on what H will >>>>>>>> be, we don't know which of all the possible inputs D will be.
In computability theory and computational complexity theory, a >>>>>>>>> decision
problem is a computational problem that can be posed as a yes–no >>>>>>>>> question of the input values.
https://en.wikipedia.org/wiki/Decision_problem
Right, and it must accept ALL inputs, it can take the input
based on itself, which we don't know which one it will be until >>>>>>>> we define the decider.
TM's do not take ideas held within the mind as their inputs, >>>>>>>>> they only
take fixed constant finite strings as inputs.
Right, but since it takes ALL inputs, it can take an input based >>>>>>>> on itself,
None-the-less you continue to assert that it must take ideas as
inputs.
It just doesn't work that way.
Nope, Where did I say THAT.
On 7/3/2023 10:58 AM, Richard Damon wrote:
Nope, it must decide for ALL inputs, even those that haven't been >>>>> > 'created' yet.
Right, haven't been created at the time the decider is created, but
will have been when it is run.
Not unless the guy that wrote the decider also wrote its input.
Until then the input you refer to is only imaginary.
Why do you say that? As I said, it actually exist when we run the
decider on it.
It only exists in the imagination until someone actually creates the
finite string.
On 7/3/23 4:45 PM, olcott wrote:
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:56 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:03 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>> objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of >>>>>>>>>> the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' output >>>>>>>>> state either.
Either the input is or is not something that is in the set
defined by the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic property,
but is an answer for if an input <HAS> some specific semantic
property.
In computability theory, Rice's theorem states that all non-trivial >>>>>> semantic properties of programs are undecidable. A semantic
property is
one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Undecidable <is> a semantic property of the finite string pair:
{H,D}.
As I mentioned, many simple descriptions get it wrong. Note, later
in the same page it says:
It is important to note that Rice's theorem does not concern the
properties of machines or programs; it concerns properties of
functions and languages.
H correctly accepts every language specified by the pair: {H, *}
(where the first element is the machine description of H and the
second element is any other machine description) or rejects this
pair as undecidable.
So, you are admitting you don't understand what you are saying.
D isn't "undecidable" but always has definite behavior based on the
behavior of the definite machine H that it was based on (and thus you
are being INTENTIONALLY dupicious by now calling H to be a some sort
of other decider).
Since you claim that Halt-Decider-H "Correctly" returned false for
H(D,D) we know that D(D) Halts, so D the problem of D has an answer
so hard to call "undecidable"
Again, what is the definition of your "Language", and why do you call
{H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider that is
just WRONG about its input, that isn't "undecidable".
Using Rogers' characterization of acceptable programming systems, Rice's
theorem may essentially be generalized from Turing machines to most
computer programming languages: there exists no automatic method that
decides with generality non-trivial questions on the behavior of
computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem
H correctly divides inputs into
(a) Halting
(b) Not halting
(c) Cannot be decided by H
And where do you see anything that allows H to be "correct" in giving
answer (c)?
The specific input either represents a machine that does (a) or does
(b), so in no case is the results of "it can not be decided" be correct.
You are just showing that you fundamentally don't understand what you
are talking about.
The question follows the rule of the excluded middle, so there is no
valid answer (c).
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote:
On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>> whether or not its input
is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>>> invoked in
decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke H1(D,D) to >>>>>>>>>>>>>>>>>>> get the actual
behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>> identical to H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm give >>>>>>>>>>>>>>>>>> your algorithm problems?
Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), then >>>>>>>>>>>>>>>>>> when we actually run D, appearently it will get that >>>>>>>>>>>>>>>>>> same answer from H1 and do the opposite of it, and >>>>>>>>>>>>>>>>>> thus H1 will be wrong.
Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide on >>>>>>>>>>>>>>>>>> it, including ALL of its "tricks", including things >>>>>>>>>>>>>>>>>> like this "batch processing".
You seem to be assuming that there is some "Operationg >>>>>>>>>>>>>>>>>> System" outside the Decider - Input structure, but >>>>>>>>>>>>>>>>>> there isn't, at least not one that can affect the >>>>>>>>>>>>>>>>>> answer of the problem.
I spent 12 hours a day for the last 10 days getting the >>>>>>>>>>>>>>>>> copy the input
working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>> detects that its
input is in the well defined set of pathological inputs >>>>>>>>>>>>>>>>> it returns 0
indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>> file that invoked H
then knows to invoke H1(D,D) to correctly report that >>>>>>>>>>>>>>>>> D(D) halts.
This solution does seem to work correctly on every >>>>>>>>>>>>>>>>> conventional proof in
every textbook.
So, did you make your "conventional proof" template >>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which seems >>>>>>>>>>>>>>>> to be your "batch file" not the C funciton H), or are >>>>>>>>>>>>>>>> you just admitting that you wasted 120 hours looking at >>>>>>>>>>>>>>>> the wrong thing because you have made yourself >>>>>>>>>>>>>>>> intentionally ignorant of the subject so you don't >>>>>>>>>>>>>>>> understand what you are trying to do.
New_D copies its input and simulates its input with its >>>>>>>>>>>>>>> input.
It never sees New_H.
Why not? Since New_H is the thing that is considered the >>>>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>>
New_H is embedded within New_D (as its middle states) just the >>>>>>>>>>>>> way it is supposed to be. The question is: Does
New_H(New_H) halt?
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.
So, how is New_H a halt decider then?
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly >>>>>>>>>>> New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about >>>>>>>>> inserting bugs into a halt decider to make it cease to function. >>>>>>>>>
Right, and in Linz, H is the decider that is claimed to give the >>>>>>>> right answer.
That isn't 'H' in your system, but the script that decides
whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name for >>>>>>>> things.
You are using double-talk in a lame attempt to show that
Linz H cannot correctly determine the halt status of Linz Ĥ.
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status of
Linz Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the results of
the 'Linz Ĥ' built on it. You keep on changing H and trying to use >>>>>> the old Ĥ which just fails to meet the requirement of the proof,
likely because you just don't understand the theory involved.
It took me two years to figure out a clean way to copy the input to
Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is required?
Copying the input should be trivial,
The relative addressing of the x86 language causes all function
calls to call the wrong address.
Only because you aren't interpreting the input properly, but in a
non-Turing Complete manner.
As I said, the input description should be a chunck of code in a
virtual address space with a header that tells where that code is
supposed to be considered to be located at.
as the input should be a representation that packages a full program
in its own virtual environment, so a simple bit by bit copy to empty
ram will work. Your problem is that you don't put the input into its
own virtual address space, so you have pathological interactions.
Linz_H_Hat must be built on the exact code base that is deciding on
it, in this case H, since you just said it isn't, your proof is
invalid.
Linz_Hat <is> Linz_H that takes one param and copies it instead of
two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
It exactly matches the Linz spec.
You don't seem to understand what you are doing.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined behavior.
That behavior is a function of its input, but hasn't been assigned any
"meaning".
Linz_H is a Turing Machine (if it actually can exist) that has a
defined meaning/requirement for its final states. Linz_H, to meet its
requirements, MUST go to Qy if the input represents a Halting
Computation, and MUST go to Qn if the input represents a non-halting
computation.
Since Linz_H has actual requirements, a claimed implementation of it
can be checked to see if it actually meets the requirements, and
perhaps we can determine if it is possible to meet them.
defined meaning for Linz_H_Hat as it isn't defined to be a decider.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
truth values, only behavior. You are just showing that you don't
understand the basics of the requirements, and seem to think that
"close" is good enough for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
Linz_H and Linz_H_Hat are C functions.
Linz:H and Linz:Ĥ are Turing machines.
Linz_H and Linz:H are both directly embedded within a copy of
Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
to Ĥ.qn still means not halting.
This allows Linz_H and Linz:H correctly report on the actual
behavior of their input.
On 7/3/2023 4:07 PM, Richard Damon wrote:
On 7/3/23 4:08 PM, olcott wrote:
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:56 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:03 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>>> objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of >>>>>>>>>>> the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' output >>>>>>>>>> state either.
Either the input is or is not something that is in the set >>>>>>>>>> defined by the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic property, >>>>>>>> but is an answer for if an input <HAS> some specific semantic
property.
In computability theory, Rice's theorem states that all non-trivial >>>>>>> semantic properties of programs are undecidable. A semantic
property is
one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Undecidable <is> a semantic property of the finite string pair:
{H,D}.
As I mentioned, many simple descriptions get it wrong. Note, later >>>>>> in the same page it says:
It is important to note that Rice's theorem does not concern the
properties of machines or programs; it concerns properties of
functions and languages.
H correctly accepts every language specified by the pair: {H, *}
(where the first element is the machine description of H and the
second element is any other machine description) or rejects this
pair as undecidable.
So, you are admitting you don't understand what you are saying.
D isn't "undecidable" but always has definite behavior based on the
behavior of the definite machine H that it was based on (and thus
you are being INTENTIONALLY dupicious by now calling H to be a some
sort of other decider).
Since you claim that Halt-Decider-H "Correctly" returned false for
H(D,D) we know that D(D) Halts, so D the problem of D has an answer
so hard to call "undecidable"
Again, what is the definition of your "Language", and why do you
call {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider
that is just WRONG about its input, that isn't "undecidable".
{H,D} undecidable means that D is undecidable for H, which is an
verified fact. The set of {H,*} finite string pairs do define a
language. Decidability <is> a semantic property because it
can only be correctly decided on the basis of behavior.
What do you mean by "Undecidable by H?"
H correctly determines that it cannot provide a halt status
consistent with the behavior of the directly executed D(D).
H is a decidability decider for itself, thus determining the
semantic property of finite string pairs: {H,*}.
0==Undecidable
1==Decidable
2==Decidable
On 7/3/23 4:22 PM, olcott wrote:*I never said that you are confused*
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:It took me two years to figure out a clean way to copy the input to >>>>>> Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:So, how is New_H a halt decider then?
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:
On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>> whether or not its input
is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>>>> invoked in
decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke H1(D,D) >>>>>>>>>>>>>>>>>>>> to get the actual
behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>> identical to H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>> give your algorithm problems?
Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will get >>>>>>>>>>>>>>>>>>> that same answer from H1 and do the opposite of it, >>>>>>>>>>>>>>>>>>> and thus H1 will be wrong.
Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide on >>>>>>>>>>>>>>>>>>> it, including ALL of its "tricks", including things >>>>>>>>>>>>>>>>>>> like this "batch processing".
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that can >>>>>>>>>>>>>>>>>>> affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting >>>>>>>>>>>>>>>>>> the copy the input
working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>>> detects that its
input is in the well defined set of pathological >>>>>>>>>>>>>>>>>> inputs it returns 0
indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>>> file that invoked H
then knows to invoke H1(D,D) to correctly report that >>>>>>>>>>>>>>>>>> D(D) halts.
This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>> conventional proof in
every textbook.
So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which seems >>>>>>>>>>>>>>>>> to be your "batch file" not the C funciton H), or are >>>>>>>>>>>>>>>>> you just admitting that you wasted 120 hours looking at >>>>>>>>>>>>>>>>> the wrong thing because you have made yourself >>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you don't >>>>>>>>>>>>>>>>> understand what you are trying to do.
New_D copies its input and simulates its input with its >>>>>>>>>>>>>>>> input.
It never sees New_H.
Why not? Since New_H is the thing that is considered the >>>>>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>>>
New_H is embedded within New_D (as its middle states) just >>>>>>>>>>>>>> the
way it is supposed to be. The question is: Does
New_H(New_H) halt?
The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly >>>>>>>>>>>> New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about >>>>>>>>>> inserting bugs into a halt decider to make it cease to function. >>>>>>>>>>
Right, and in Linz, H is the decider that is claimed to give >>>>>>>>> the right answer.
That isn't 'H' in your system, but the script that decides
whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name for >>>>>>>>> things.
You are using double-talk in a lame attempt to show that
Linz H cannot correctly determine the halt status of Linz Ĥ.
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status of
Linz Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the results of >>>>>>> the 'Linz Ĥ' built on it. You keep on changing H and trying to
use the old Ĥ which just fails to meet the requirement of the
proof, likely because you just don't understand the theory involved. >>>>>>
Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is required?
Copying the input should be trivial,
The relative addressing of the x86 language causes all function
calls to call the wrong address.
Only because you aren't interpreting the input properly, but in a
non-Turing Complete manner.
As I said, the input description should be a chunck of code in a
virtual address space with a header that tells where that code is
supposed to be considered to be located at.
as the input should be a representation that packages a full
program in its own virtual environment, so a simple bit by bit copy
to empty ram will work. Your problem is that you don't put the
input into its own virtual address space, so you have pathological
interactions.
Linz_H_Hat must be built on the exact code base that is deciding on
it, in this case H, since you just said it isn't, your proof is
invalid.
Linz_Hat <is> Linz_H that takes one param and copies it instead of
two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
It exactly matches the Linz spec.
You don't seem to understand what you are doing.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
behavior. That behavior is a function of its input, but hasn't been
assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that has a
defined meaning/requirement for its final states. Linz_H, to meet its
requirements, MUST go to Qy if the input represents a Halting
Computation, and MUST go to Qn if the input represents a non-halting
computation.
Since Linz_H has actual requirements, a claimed implementation of it
can be checked to see if it actually meets the requirements, and
perhaps we can determine if it is possible to meet them.
defined meaning for Linz_H_Hat as it isn't defined to be a decider.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
truth values, only behavior. You are just showing that you don't
understand the basics of the requirements, and seem to think that
"close" is good enough for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
Linz_H and Linz_H_Hat are C functions.
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus showing you are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of
Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted.
This allows Linz_H and Linz:H correctly report on the actual
behavior of their input.
No, since BOTH have an input that when run will HALT, and both report
that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
On 7/3/2023 4:07 PM, Richard Damon wrote:
On 7/3/23 4:45 PM, olcott wrote:
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:56 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:03 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>>> objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of >>>>>>>>>>> the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' output >>>>>>>>>> state either.
Either the input is or is not something that is in the set >>>>>>>>>> defined by the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic property, >>>>>>>> but is an answer for if an input <HAS> some specific semantic
property.
In computability theory, Rice's theorem states that all non-trivial >>>>>>> semantic properties of programs are undecidable. A semantic
property is
one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Undecidable <is> a semantic property of the finite string pair:
{H,D}.
As I mentioned, many simple descriptions get it wrong. Note, later >>>>>> in the same page it says:
It is important to note that Rice's theorem does not concern the
properties of machines or programs; it concerns properties of
functions and languages.
H correctly accepts every language specified by the pair: {H, *}
(where the first element is the machine description of H and the
second element is any other machine description) or rejects this
pair as undecidable.
So, you are admitting you don't understand what you are saying.
D isn't "undecidable" but always has definite behavior based on the
behavior of the definite machine H that it was based on (and thus
you are being INTENTIONALLY dupicious by now calling H to be a some
sort of other decider).
Since you claim that Halt-Decider-H "Correctly" returned false for
H(D,D) we know that D(D) Halts, so D the problem of D has an answer
so hard to call "undecidable"
Again, what is the definition of your "Language", and why do you
call {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider
that is just WRONG about its input, that isn't "undecidable".
Using Rogers' characterization of acceptable programming systems, Rice's >>> theorem may essentially be generalized from Turing machines to most
computer programming languages: there exists no automatic method that
decides with generality non-trivial questions on the behavior of
computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem
H correctly divides inputs into
(a) Halting
(b) Not halting
(c) Cannot be decided by H
And where do you see anything that allows H to be "correct" in giving
answer (c)?
The specific input either represents a machine that does (a) or does
(b), so in no case is the results of "it can not be decided" be correct.
You are just showing that you fundamentally don't understand what you
are talking about.
The question follows the rule of the excluded middle, so there is no
valid answer (c).
H is a correct halting decidability decider for itself.
Rice says that is impossible, thus Rice is wrong.
On 7/3/23 4:08 PM, olcott wrote:
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:56 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:03 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>> objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of >>>>>>>>>> the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' output >>>>>>>>> state either.
Either the input is or is not something that is in the set
defined by the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic property,
but is an answer for if an input <HAS> some specific semantic
property.
In computability theory, Rice's theorem states that all non-trivial >>>>>> semantic properties of programs are undecidable. A semantic
property is
one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Undecidable <is> a semantic property of the finite string pair:
{H,D}.
As I mentioned, many simple descriptions get it wrong. Note, later
in the same page it says:
It is important to note that Rice's theorem does not concern the
properties of machines or programs; it concerns properties of
functions and languages.
H correctly accepts every language specified by the pair: {H, *}
(where the first element is the machine description of H and the
second element is any other machine description) or rejects this
pair as undecidable.
So, you are admitting you don't understand what you are saying.
D isn't "undecidable" but always has definite behavior based on the
behavior of the definite machine H that it was based on (and thus you
are being INTENTIONALLY dupicious by now calling H to be a some sort
of other decider).
Since you claim that Halt-Decider-H "Correctly" returned false for
H(D,D) we know that D(D) Halts, so D the problem of D has an answer
so hard to call "undecidable"
Again, what is the definition of your "Language", and why do you call
{H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider that is
just WRONG about its input, that isn't "undecidable".
{H,D} undecidable means that D is undecidable for H, which is an
verified fact. The set of {H,*} finite string pairs do define a
language. Decidability <is> a semantic property because it
can only be correctly decided on the basis of behavior.
What do you mean by "Undecidable by H?"
On 7/3/23 5:19 PM, olcott wrote:
On 7/3/2023 4:07 PM, Richard Damon wrote:
On 7/3/23 4:45 PM, olcott wrote:
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:56 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:03 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>>>> objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the behavior of >>>>>>>>>>>> the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable'
output state either.
Either the input is or is not something that is in the set >>>>>>>>>>> defined by the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic property, >>>>>>>>> but is an answer for if an input <HAS> some specific semantic >>>>>>>>> property.
In computability theory, Rice's theorem states that all non-trivial >>>>>>>> semantic properties of programs are undecidable. A semantic
property is
one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Undecidable <is> a semantic property of the finite string pair: >>>>>>>> {H,D}.
As I mentioned, many simple descriptions get it wrong. Note,
later in the same page it says:
It is important to note that Rice's theorem does not concern the >>>>>>> properties of machines or programs; it concerns properties of
functions and languages.
H correctly accepts every language specified by the pair: {H, *}
(where the first element is the machine description of H and the
second element is any other machine description) or rejects this
pair as undecidable.
So, you are admitting you don't understand what you are saying.
D isn't "undecidable" but always has definite behavior based on the
behavior of the definite machine H that it was based on (and thus
you are being INTENTIONALLY dupicious by now calling H to be a some
sort of other decider).
Since you claim that Halt-Decider-H "Correctly" returned false for
H(D,D) we know that D(D) Halts, so D the problem of D has an answer
so hard to call "undecidable"
Again, what is the definition of your "Language", and why do you
call {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider
that is just WRONG about its input, that isn't "undecidable".
Using Rogers' characterization of acceptable programming systems,
Rice's
theorem may essentially be generalized from Turing machines to most
computer programming languages: there exists no automatic method that
decides with generality non-trivial questions on the behavior of
computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem
H correctly divides inputs into
(a) Halting
(b) Not halting
(c) Cannot be decided by H
And where do you see anything that allows H to be "correct" in giving
answer (c)?
The specific input either represents a machine that does (a) or does
(b), so in no case is the results of "it can not be decided" be correct. >>>
You are just showing that you fundamentally don't understand what you
are talking about.
The question follows the rule of the excluded middle, so there is no
valid answer (c).
H is a correct halting decidability decider for itself.
Rice says that is impossible, thus Rice is wrong.
What you do mean by a "Decidability Decider"? As I have pointed out, Decidability isn't a property of an input, but of a whole problem.
On 7/3/2023 4:17 PM, Richard Damon wrote:
On 7/3/23 4:22 PM, olcott wrote:*I never said that you are confused*
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:So, how is New_H a halt decider then?
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote:
On 7/2/23 10:01 PM, olcott wrote:New_D copies its input and simulates its input with its >>>>>>>>>>>>>>>>> input.
On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote:
A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>> whether or not its input
is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>>>>> invoked in
decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke H1(D,D) >>>>>>>>>>>>>>>>>>>>> to get the actual
behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>> identical to H except for
the pathological relationship to H.
And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>>> give your algorithm problems?
Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will get >>>>>>>>>>>>>>>>>>>> that same answer from H1 and do the opposite of it, >>>>>>>>>>>>>>>>>>>> and thus H1 will be wrong.
Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide on >>>>>>>>>>>>>>>>>>>> it, including ALL of its "tricks", including things >>>>>>>>>>>>>>>>>>>> like this "batch processing".
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that >>>>>>>>>>>>>>>>>>>> can affect the answer of the problem.
I spent 12 hours a day for the last 10 days getting >>>>>>>>>>>>>>>>>>> the copy the input
working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>>>> detects that its
input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>> inputs it returns 0
indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>>>> file that invoked H
then knows to invoke H1(D,D) to correctly report that >>>>>>>>>>>>>>>>>>> D(D) halts.
This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>>> conventional proof in
every textbook.
So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which >>>>>>>>>>>>>>>>>> seems to be your "batch file" not the C funciton H), >>>>>>>>>>>>>>>>>> or are you just admitting that you wasted 120 hours >>>>>>>>>>>>>>>>>> looking at the wrong thing because you have made >>>>>>>>>>>>>>>>>> yourself intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>
It never sees New_H.
Why not? Since New_H is the thing that is considered the >>>>>>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>>>>
New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>> just the
way it is supposed to be. The question is: Does
New_H(New_H) halt?
The only difference at the source code level is: >>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly >>>>>>>>>>>>> New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not about >>>>>>>>>>> inserting bugs into a halt decider to make it cease to function. >>>>>>>>>>>
Right, and in Linz, H is the decider that is claimed to give >>>>>>>>>> the right answer.
That isn't 'H' in your system, but the script that decides >>>>>>>>>> whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name for >>>>>>>>>> things.
You are using double-talk in a lame attempt to show that
Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status of >>>>>>>> Linz Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the results >>>>>>>> of the 'Linz Ĥ' built on it. You keep on changing H and trying >>>>>>>> to use the old Ĥ which just fails to meet the requirement of the >>>>>>>> proof, likely because you just don't understand the theory
involved.
It took me two years to figure out a clean way to copy the input to >>>>>>> Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is required? >>>>>>
Copying the input should be trivial,
The relative addressing of the x86 language causes all function
calls to call the wrong address.
Only because you aren't interpreting the input properly, but in a
non-Turing Complete manner.
As I said, the input description should be a chunck of code in a
virtual address space with a header that tells where that code is
supposed to be considered to be located at.
as the input should be a representation that packages a full
program in its own virtual environment, so a simple bit by bit
copy to empty ram will work. Your problem is that you don't put
the input into its own virtual address space, so you have
pathological interactions.
Linz_H_Hat must be built on the exact code base that is deciding
on it, in this case H, since you just said it isn't, your proof is >>>>>> invalid.
Linz_Hat <is> Linz_H that takes one param and copies it instead of >>>>> two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
It exactly matches the Linz spec.
You don't seem to understand what you are doing.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
behavior. That behavior is a function of its input, but hasn't been
assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that has a
defined meaning/requirement for its final states. Linz_H, to meet
its requirements, MUST go to Qy if the input represents a Halting
Computation, and MUST go to Qn if the input represents a non-halting
computation.
Since Linz_H has actual requirements, a claimed implementation of it
can be checked to see if it actually meets the requirements, and
perhaps we can determine if it is possible to meet them.
defined meaning for Linz_H_Hat as it isn't defined to be a decider.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate
any truth values, only behavior. You are just showing that you
don't understand the basics of the requirements, and seem to think >>>>>> that "close" is good enough for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
Linz_H and Linz_H_Hat are C functions.
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus showing you
are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of
Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted.
This allows Linz_H and Linz:H correctly report on the actual
behavior of their input.
No, since BOTH have an input that when run will HALT, and both report
that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
On 7/3/23 5:36 PM, olcott wrote:
On 7/3/2023 4:31 PM, Richard Damon wrote:
On 7/3/23 5:19 PM, olcott wrote:H correctly divides finite string pairs {H,*} into decidable by H and
On 7/3/2023 4:07 PM, Richard Damon wrote:
On 7/3/23 4:45 PM, olcott wrote:
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:56 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 2:03 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:05 PM, olcott wrote:
On 7/3/2023 10:58 AM, Richard Damon wrote:
On 7/3/23 11:44 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:42 AM, olcott wrote:
On 7/3/2023 8:13 AM, Richard Damon wrote:
On 7/2/23 11:10 PM, olcott wrote:
Only when I show you are wrong. Actually try to answer >>>>>>>>>>>>>>>>> my objections
What about a three valued decider?
0=undecidable
1=halting
2=not halting
Doesn't meet the definition of a Halt Decider.
Because these are semantic properties based on the >>>>>>>>>>>>>> behavior of
the input it does refute Rice.
Nope. Rice's theorem doesn't allow for an 'undecidable' >>>>>>>>>>>>> output state either.
Either the input is or is not something that is in the set >>>>>>>>>>>>> defined by the function/language defined.
Undecidable is just admitting that Rice is true.
Undecidable <is> a semantic property.
Source of that Claim?
And you aren't saying the Undecidable <IS> a semantic
property, but is an answer for if an input <HAS> some
specific semantic property.
In computability theory, Rice's theorem states that all
non-trivial
semantic properties of programs are undecidable. A semantic >>>>>>>>>> property is
one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Undecidable <is> a semantic property of the finite string
pair: {H,D}.
As I mentioned, many simple descriptions get it wrong. Note, >>>>>>>>> later in the same page it says:
It is important to note that Rice's theorem does not concern >>>>>>>>> the properties of machines or programs; it concerns properties >>>>>>>>> of functions and languages.
H correctly accepts every language specified by the pair: {H, *} >>>>>>>> (where the first element is the machine description of H and the >>>>>>>> second element is any other machine description) or rejects this >>>>>>>> pair as undecidable.
So, you are admitting you don't understand what you are saying.
D isn't "undecidable" but always has definite behavior based on
the behavior of the definite machine H that it was based on (and >>>>>>> thus you are being INTENTIONALLY dupicious by now calling H to be >>>>>>> a some sort of other decider).
Since you claim that Halt-Decider-H "Correctly" returned false
for H(D,D) we know that D(D) Halts, so D the problem of D has an >>>>>>> answer so hard to call "undecidable"
Again, what is the definition of your "Language", and why do you >>>>>>> call {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED
decider that is just WRONG about its input, that isn't
"undecidable".
Using Rogers' characterization of acceptable programming systems,
Rice's
theorem may essentially be generalized from Turing machines to most >>>>>> computer programming languages: there exists no automatic method that >>>>>> decides with generality non-trivial questions on the behavior of
computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem
H correctly divides inputs into
(a) Halting
(b) Not halting
(c) Cannot be decided by H
And where do you see anything that allows H to be "correct" in
giving answer (c)?
The specific input either represents a machine that does (a) or
does (b), so in no case is the results of "it can not be decided"
be correct.
You are just showing that you fundamentally don't understand what
you are talking about.
The question follows the rule of the excluded middle, so there is
no valid answer (c).
H is a correct halting decidability decider for itself.
Rice says that is impossible, thus Rice is wrong.
What you do mean by a "Decidability Decider"? As I have pointed out,
Decidability isn't a property of an input, but of a whole problem.
undecidable by H, a semantic property of these finite string pairs.
No such property. Inputs are not "Decidable", problems are.
You are just showing your stupidity.
And that you just don't know what Truth means, as you are just a
pathological liar.
On 7/3/23 5:34 PM, olcott wrote:
On 7/3/2023 4:17 PM, Richard Damon wrote:
On 7/3/23 4:22 PM, olcott wrote:*I never said that you are confused*
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:So, how is New_H a halt decider then?
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
New_D copies its input and simulates its input with >>>>>>>>>>>>>>>>>> its input.On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote:
I spent 12 hours a day for the last 10 days getting >>>>>>>>>>>>>>>>>>>> the copy the inputA single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>>> whether or not its input
is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>>>>>> invoked in
decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke H1(D,D) >>>>>>>>>>>>>>>>>>>>>> to get the actual
behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>> identical to H except for
the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>
And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>>>> give your algorithm problems?
Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will >>>>>>>>>>>>>>>>>>>>> get that same answer from H1 and do the opposite of >>>>>>>>>>>>>>>>>>>>> it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide >>>>>>>>>>>>>>>>>>>>> on it, including ALL of its "tricks", including >>>>>>>>>>>>>>>>>>>>> things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that >>>>>>>>>>>>>>>>>>>>> can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>
working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>>>>> detects that its
input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>> inputs it returns 0
indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>>>>> file that invoked H
then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>> that D(D) halts.
This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>>>> conventional proof in
every textbook.
So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which >>>>>>>>>>>>>>>>>>> seems to be your "batch file" not the C funciton H), >>>>>>>>>>>>>>>>>>> or are you just admitting that you wasted 120 hours >>>>>>>>>>>>>>>>>>> looking at the wrong thing because you have made >>>>>>>>>>>>>>>>>>> yourself intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>
It never sees New_H.
Why not? Since New_H is the thing that is considered >>>>>>>>>>>>>>>>> the "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>>>>>
New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>>> just the
way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>> New_H(New_H) halt?
The only difference at the source code level is: >>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>
typo
The only difference at the source code level is:
(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>> exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not >>>>>>>>>>>> about
inserting bugs into a halt decider to make it cease to >>>>>>>>>>>> function.
Right, and in Linz, H is the decider that is claimed to give >>>>>>>>>>> the right answer.
That isn't 'H' in your system, but the script that decides >>>>>>>>>>> whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name >>>>>>>>>>> for things.
You are using double-talk in a lame attempt to show that
Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status of >>>>>>>>> Linz Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the results >>>>>>>>> of the 'Linz Ĥ' built on it. You keep on changing H and trying >>>>>>>>> to use the old Ĥ which just fails to meet the requirement of >>>>>>>>> the proof, likely because you just don't understand the theory >>>>>>>>> involved.
It took me two years to figure out a clean way to copy the input to >>>>>>>> Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is required? >>>>>>>
Copying the input should be trivial,
The relative addressing of the x86 language causes all function
calls to call the wrong address.
Only because you aren't interpreting the input properly, but in a
non-Turing Complete manner.
As I said, the input description should be a chunck of code in a
virtual address space with a header that tells where that code is
supposed to be considered to be located at.
as the input should be a representation that packages a full
program in its own virtual environment, so a simple bit by bit
copy to empty ram will work. Your problem is that you don't put
the input into its own virtual address space, so you have
pathological interactions.
Linz_H_Hat must be built on the exact code base that is deciding >>>>>>> on it, in this case H, since you just said it isn't, your proof
is invalid.
Linz_Hat <is> Linz_H that takes one param and copies it instead of >>>>>> two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
It exactly matches the Linz spec.
You don't seem to understand what you are doing.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
behavior. That behavior is a function of its input, but hasn't been
assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that has a
defined meaning/requirement for its final states. Linz_H, to meet
its requirements, MUST go to Qy if the input represents a Halting
Computation, and MUST go to Qn if the input represents a
non-halting computation.
Since Linz_H has actual requirements, a claimed implementation of
it can be checked to see if it actually meets the requirements, and
perhaps we can determine if it is possible to meet them.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate
any truth values, only behavior. You are just showing that you
don't understand the basics of the requirements, and seem to
think that "close" is good enough for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO >>>>> defined meaning for Linz_H_Hat as it isn't defined to be a decider.
Linz_H and Linz_H_Hat are C functions.
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus showing you
are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of
Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted.
This allows Linz_H and Linz:H correctly report on the actual
behavior of their input.
No, since BOTH have an input that when run will HALT, and both report
that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
You always claim that your H by its various names is "Correct" to return
0 as the input is non-halting because its "correct simulation" will
never reach a final state.
I think your brain is turning into mush, or is your pathology
overloading and trying to reverse the argument.
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting,
it
means that Linz_H_Hat will go into the infinte loop on the Qy leg.
Did you miss that parto of the design in Linz's proof. H^ has modified
the end of H so that Qy becomes a non-terminal state.
Linz_H_Hat doesn't actually "return" a value, it just goes to Qn and
halt or never halts.
On 7/3/2023 4:55 PM, Richard Damon wrote:
On 7/3/23 5:34 PM, olcott wrote:
On 7/3/2023 4:17 PM, Richard Damon wrote:
On 7/3/23 4:22 PM, olcott wrote:*I never said that you are confused*
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote:So, how is New_H a halt decider then?
On 7/2/23 10:48 PM, olcott wrote:
On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
New_D copies its input and simulates its input with >>>>>>>>>>>>>>>>>>> its input.On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote:
I spent 12 hours a day for the last 10 days getting >>>>>>>>>>>>>>>>>>>>> the copy the inputA single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>>>> whether or not its input
is pathological relative to itself. When H(D,D) >>>>>>>>>>>>>>>>>>>>>>> is invoked in
decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>> identical to H except for
the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>
And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>>>>> give your algorithm problems?
Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will >>>>>>>>>>>>>>>>>>>>>> get that same answer from H1 and do the opposite >>>>>>>>>>>>>>>>>>>>>> of it, and thus H1 will be wrong.
Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide >>>>>>>>>>>>>>>>>>>>>> on it, including ALL of its "tricks", including >>>>>>>>>>>>>>>>>>>>>> things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>>
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that >>>>>>>>>>>>>>>>>>>>>> can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>
working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>>>>>> detects that its
input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>>> inputs it returns 0
indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>>>>>> file that invoked H
then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>>> that D(D) halts.
This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>>>>> conventional proof in
every textbook.
So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which >>>>>>>>>>>>>>>>>>>> seems to be your "batch file" not the C funciton H), >>>>>>>>>>>>>>>>>>>> or are you just admitting that you wasted 120 hours >>>>>>>>>>>>>>>>>>>> looking at the wrong thing because you have made >>>>>>>>>>>>>>>>>>>> yourself intentionally ignorant of the subject so >>>>>>>>>>>>>>>>>>>> you don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>
It never sees New_H.
Why not? Since New_H is the thing that is considered >>>>>>>>>>>>>>>>>> the "Correct Halt Decider", New_D needs to be built on >>>>>>>>>>>>>>>>>> it.
New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>>>> just the
way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>> New_H(New_H) halt?
The only difference at the source code level is: >>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>
typo
The only difference at the source code level is: >>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>> exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not >>>>>>>>>>>>> about
inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>> function.
Right, and in Linz, H is the decider that is claimed to give >>>>>>>>>>>> the right answer.
That isn't 'H' in your system, but the script that decides >>>>>>>>>>>> whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name >>>>>>>>>>>> for things.
You are using double-talk in a lame attempt to show that >>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status >>>>>>>>>> of Linz Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the results >>>>>>>>>> of the 'Linz Ĥ' built on it. You keep on changing H and trying >>>>>>>>>> to use the old Ĥ which just fails to meet the requirement of >>>>>>>>>> the proof, likely because you just don't understand the theory >>>>>>>>>> involved.
It took me two years to figure out a clean way to copy the
input to
Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is required? >>>>>>>>
Copying the input should be trivial,
The relative addressing of the x86 language causes all function
calls to call the wrong address.
Only because you aren't interpreting the input properly, but in a
non-Turing Complete manner.
As I said, the input description should be a chunck of code in a
virtual address space with a header that tells where that code is
supposed to be considered to be located at.
as the input should be a representation that packages a full
program in its own virtual environment, so a simple bit by bit >>>>>>>> copy to empty ram will work. Your problem is that you don't put >>>>>>>> the input into its own virtual address space, so you have
pathological interactions.
Linz_H_Hat must be built on the exact code base that is deciding >>>>>>>> on it, in this case H, since you just said it isn't, your proof >>>>>>>> is invalid.
Linz_Hat <is> Linz_H that takes one param and copies it instead of >>>>>>> two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
It exactly matches the Linz spec.
You don't seem to understand what you are doing.Linz_H and Linz_H_Hat are C functions.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
behavior. That behavior is a function of its input, but hasn't
been assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that has a
defined meaning/requirement for its final states. Linz_H, to meet
its requirements, MUST go to Qy if the input represents a Halting
Computation, and MUST go to Qn if the input represents a
non-halting computation.
Since Linz_H has actual requirements, a claimed implementation of
it can be checked to see if it actually meets the requirements,
and perhaps we can determine if it is possible to meet them.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate >>>>>>>> any truth values, only behavior. You are just showing that you >>>>>>>> don't understand the basics of the requirements, and seem to
think that "close" is good enough for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO >>>>>> defined meaning for Linz_H_Hat as it isn't defined to be a decider. >>>>>
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus showing you
are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of
Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted.
This allows Linz_H and Linz:H correctly report on the actual
behavior of their input.
No, since BOTH have an input that when run will HALT, and both
report that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
You always claim that your H by its various names is "Correct" to
return 0 as the input is non-halting because its "correct simulation"
will never reach a final state.
I think your brain is turning into mush, or is your pathology
overloading and trying to reverse the argument.
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting,
Linz_H_Hat has its own embedded_H that returns 0.
Linz_H_Hat has no access to Linz_H, only to its own embedded copy.
Linz_H simply simulates Linz_H_Hat until it terminates.
it means that Linz_H_Hat will go into the infinte loop on the Qy leg.
Did you miss that parto of the design in Linz's proof. H^ has modified
the end of H so that Qy becomes a non-terminal state.
Linz_H_Hat doesn't actually "return" a value, it just goes to Qn and
Linz_H_Hat is a C function Linz:Ĥ is a Turing machine.
They use the exact same algorithm.
halt or never halts.
On 7/3/23 10:20 PM, olcott wrote:
On 7/3/2023 4:55 PM, Richard Damon wrote:
On 7/3/23 5:34 PM, olcott wrote:
On 7/3/2023 4:17 PM, Richard Damon wrote:
On 7/3/23 4:22 PM, olcott wrote:*I never said that you are confused*
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:So, how is New_H a halt decider then?
On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
New_D copies its input and simulates its input with >>>>>>>>>>>>>>>>>>>> its input.On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>>>>> whether or not its input
I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>> getting the copy the inputis pathological relative to itself. When H(D,D) >>>>>>>>>>>>>>>>>>>>>>>> is invoked in
decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>>> identical to H except for
the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>
And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>>>>>> give your algorithm problems?
Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will >>>>>>>>>>>>>>>>>>>>>>> get that same answer from H1 and do the opposite >>>>>>>>>>>>>>>>>>>>>>> of it, and thus H1 will be wrong. >>>>>>>>>>>>>>>>>>>>>>>
Remember, the "Pathological" program is built on >>>>>>>>>>>>>>>>>>>>>>> a copy of the ACTUAL program that you ask to >>>>>>>>>>>>>>>>>>>>>>> decide on it, including ALL of its "tricks", >>>>>>>>>>>>>>>>>>>>>>> including things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>>>
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that >>>>>>>>>>>>>>>>>>>>>>> can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>>
working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>> mode) detects that its
input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>>>> inputs it returns 0
indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>>>> that D(D) halts.
This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>>>>>> conventional proof in
every textbook.
So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which >>>>>>>>>>>>>>>>>>>>> seems to be your "batch file" not the C funciton >>>>>>>>>>>>>>>>>>>>> H), or are you just admitting that you wasted 120 >>>>>>>>>>>>>>>>>>>>> hours looking at the wrong thing because you have >>>>>>>>>>>>>>>>>>>>> made yourself intentionally ignorant of the subject >>>>>>>>>>>>>>>>>>>>> so you don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>>
It never sees New_H.
Why not? Since New_H is the thing that is considered >>>>>>>>>>>>>>>>>>> the "Correct Halt Decider", New_D needs to be built >>>>>>>>>>>>>>>>>>> on it.
New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>>>>> just the
way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>> New_H(New_H) halt?
The only difference at the source code level is: >>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>
typo
The only difference at the source code level is: >>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>> exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is not >>>>>>>>>>>>>> about
inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>> function.
Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>> give the right answer.
That isn't 'H' in your system, but the script that decides >>>>>>>>>>>>> whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name >>>>>>>>>>>>> for things.
You are using double-talk in a lame attempt to show that >>>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>>
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status >>>>>>>>>>> of Linz Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem.
Please show an ACTUAL 'Linz H' that correctly gets the
results of the 'Linz Ĥ' built on it. You keep on changing H >>>>>>>>>>> and trying to use the old Ĥ which just fails to meet the >>>>>>>>>>> requirement of the proof, likely because you just don't
understand the theory involved.
It took me two years to figure out a clean way to copy the >>>>>>>>>> input to
Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is required? >>>>>>>>>
Copying the input should be trivial,
The relative addressing of the x86 language causes all function >>>>>>>> calls to call the wrong address.
Only because you aren't interpreting the input properly, but in a >>>>>>> non-Turing Complete manner.
As I said, the input description should be a chunck of code in a >>>>>>> virtual address space with a header that tells where that code is >>>>>>> supposed to be considered to be located at.
as the input should be a representation that packages a full >>>>>>>>> program in its own virtual environment, so a simple bit by bit >>>>>>>>> copy to empty ram will work. Your problem is that you don't put >>>>>>>>> the input into its own virtual address space, so you have
pathological interactions.
Linz_H_Hat must be built on the exact code base that is
deciding on it, in this case H, since you just said it isn't, >>>>>>>>> your proof is invalid.
Linz_Hat <is> Linz_H that takes one param and copies it instead of >>>>>>>> two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
It exactly matches the Linz spec.
You don't seem to understand what you are doing.Linz_H and Linz_H_Hat are C functions.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
behavior. That behavior is a function of its input, but hasn't
been assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that has a >>>>>>> defined meaning/requirement for its final states. Linz_H, to meet >>>>>>> its requirements, MUST go to Qy if the input represents a Halting >>>>>>> Computation, and MUST go to Qn if the input represents a
non-halting computation.
Since Linz_H has actual requirements, a claimed implementation of >>>>>>> it can be checked to see if it actually meets the requirements,
and perhaps we can determine if it is possible to meet them.
has NO
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate >>>>>>>>> any truth values, only behavior. You are just showing that you >>>>>>>>> don't understand the basics of the requirements, and seem to >>>>>>>>> think that "close" is good enough for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which
defined meaning for Linz_H_Hat as it isn't defined to be a decider. >>>>>>
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus showing
you are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of
Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted.
This allows Linz_H and Linz:H correctly report on the actual
behavior of their input.
No, since BOTH have an input that when run will HALT, and both
report that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
You always claim that your H by its various names is "Correct" to
return 0 as the input is non-halting because its "correct simulation"
will never reach a final state.
I think your brain is turning into mush, or is your pathology
overloading and trying to reverse the argument.
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting,
Linz_H_Hat has its own embedded_H that returns 0.
Linz_H_Hat has no access to Linz_H, only to its own embedded copy.
But embedded_H is an identical copy to Linz_H, so if embedded_H returns
0, so does Lin
Linz_H simply simulates Linz_H_Hat until it terminates.
Then so must embedded_H, since it is an identical copy, and as you have
shown before, if H is defined that way, the H_Hat will never halt, and
thus H, since for this case you said it doesn't abort, will also never
halt and fail to be a decider.
Now, since you are claiming that the embedded_H and Linz_H are IDENTICAL machines, but the also produce DIFFERENT results when given identical
inputs, you have just proven that you are a LIAR.
On 7/3/2023 10:22 PM, Richard Damon wrote:
On 7/3/23 10:20 PM, olcott wrote:
On 7/3/2023 4:55 PM, Richard Damon wrote:
On 7/3/23 5:34 PM, olcott wrote:
On 7/3/2023 4:17 PM, Richard Damon wrote:
On 7/3/23 4:22 PM, olcott wrote:*I never said that you are confused*
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote:
On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:So, how is New_H a halt decider then?
On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>>>>>> whether or not its input
I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>> getting the copy the inputis pathological relative to itself. When H(D,D) >>>>>>>>>>>>>>>>>>>>>>>>> is invoked in
decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>>>> identical to H except for
the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>
And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>
Since H(D,D) will (apparently) determine that >>>>>>>>>>>>>>>>>>>>>>>> the input is pathological, and thus defer to >>>>>>>>>>>>>>>>>>>>>>>> H1(D,D), then when we actually run D, >>>>>>>>>>>>>>>>>>>>>>>> appearently it will get that same answer from H1 >>>>>>>>>>>>>>>>>>>>>>>> and do the opposite of it, and thus H1 will be >>>>>>>>>>>>>>>>>>>>>>>> wrong.
Remember, the "Pathological" program is built on >>>>>>>>>>>>>>>>>>>>>>>> a copy of the ACTUAL program that you ask to >>>>>>>>>>>>>>>>>>>>>>>> decide on it, including ALL of its "tricks", >>>>>>>>>>>>>>>>>>>>>>>> including things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>>>>
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one >>>>>>>>>>>>>>>>>>>>>>>> that can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>>>
working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>>>>> inputs it returns 0
indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>>>>> that D(D) halts.
This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>> every conventional proof in
every textbook.
So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" not >>>>>>>>>>>>>>>>>>>>>> the C funciton H), or are you just admitting that >>>>>>>>>>>>>>>>>>>>>> you wasted 120 hours looking at the wrong thing >>>>>>>>>>>>>>>>>>>>>> because you have made yourself intentionally >>>>>>>>>>>>>>>>>>>>>> ignorant of the subject so you don't understand >>>>>>>>>>>>>>>>>>>>>> what you are trying to do.
New_D copies its input and simulates its input with >>>>>>>>>>>>>>>>>>>>> its input.
It never sees New_H.
Why not? Since New_H is the thing that is considered >>>>>>>>>>>>>>>>>>>> the "Correct Halt Decider", New_D needs to be built >>>>>>>>>>>>>>>>>>>> on it.
New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>>>>>> just the
way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>> New_H(New_H) halt?
The only difference at the source code level is: >>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>
typo
The only difference at the source code level is: >>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>> exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is >>>>>>>>>>>>>>> not about
inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>>> function.
Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>>> give the right answer.
That isn't 'H' in your system, but the script that decides >>>>>>>>>>>>>> whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong name >>>>>>>>>>>>>> for things.
You are using double-talk in a lame attempt to show that >>>>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>>>
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt status >>>>>>>>>>>> of Linz Ĥ applied to the description of Linz Ĥ.
That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>
Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on changing H >>>>>>>>>>>> and trying to use the old Ĥ which just fails to meet the >>>>>>>>>>>> requirement of the proof, likely because you just don't >>>>>>>>>>>> understand the theory involved.
It took me two years to figure out a clean way to copy the >>>>>>>>>>> input to
Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is
required?
Copying the input should be trivial,
The relative addressing of the x86 language causes all function >>>>>>>>> calls to call the wrong address.
Only because you aren't interpreting the input properly, but in >>>>>>>> a non-Turing Complete manner.
As I said, the input description should be a chunck of code in a >>>>>>>> virtual address space with a header that tells where that code >>>>>>>> is supposed to be considered to be located at.
as the input should be a representation that packages a full >>>>>>>>>> program in its own virtual environment, so a simple bit by bit >>>>>>>>>> copy to empty ram will work. Your problem is that you don't >>>>>>>>>> put the input into its own virtual address space, so you have >>>>>>>>>> pathological interactions.
Linz_H_Hat must be built on the exact code base that is
deciding on it, in this case H, since you just said it isn't, >>>>>>>>>> your proof is invalid.
Linz_Hat <is> Linz_H that takes one param and copies it
instead of
two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
It exactly matches the Linz spec.
You don't seem to understand what you are doing.Linz_H and Linz_H_Hat are C functions.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
behavior. That behavior is a function of its input, but hasn't >>>>>>>> been assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that has a >>>>>>>> defined meaning/requirement for its final states. Linz_H, to
meet its requirements, MUST go to Qy if the input represents a >>>>>>>> Halting Computation, and MUST go to Qn if the input represents a >>>>>>>> non-halting computation.
Since Linz_H has actual requirements, a claimed implementation >>>>>>>> of it can be checked to see if it actually meets the
requirements, and perhaps we can determine if it is possible to >>>>>>>> meet them.
defined meaning for Linz_H_Hat as it isn't defined to be a decider. >>>>>>>
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't
generate any truth values, only behavior. You are just showing >>>>>>>>>> that you don't understand the basics of the requirements, and >>>>>>>>>> seem to think that "close" is good enough for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which >>>>>>>> has NO
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus showing
you are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of
Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted.
This allows Linz_H and Linz:H correctly report on the actual
behavior of their input.
No, since BOTH have an input that when run will HALT, and both
report that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
You always claim that your H by its various names is "Correct" to
return 0 as the input is non-halting because its "correct
simulation" will never reach a final state.
I think your brain is turning into mush, or is your pathology
overloading and trying to reverse the argument.
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting,
Linz_H_Hat has its own embedded_H that returns 0.
Linz_H_Hat has no access to Linz_H, only to its own embedded copy.
But embedded_H is an identical copy to Linz_H, so if embedded_H
returns 0, so does Lin
Linz_H simply simulates Linz_H_Hat until it terminates.
Then so must embedded_H, since it is an identical copy, and as you
have shown before, if H is defined that way, the H_Hat will never
halt, and thus H, since for this case you said it doesn't abort, will
also never halt and fail to be a decider.
We have gone through this many hundreds of times.
It is the exact same H(D,D) versus H1(D,D) thing.
Linz_H_Hat now has a pathological relationship to itself
this frees Linz_H from such a pathological relationship.
So Linz_H becomes H1, and Linz_H_Hat becomes H.
Now, since you are claiming that the embedded_H and Linz_H are
IDENTICAL machines, but the also produce DIFFERENT results when given
identical inputs, you have just proven that you are a LIAR.
*So you are back to rejecting verified facts out-of-hand*
It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
1 and the only difference is that H1 does not have a pathological relationship to H and it is otherwise identical to H.
On 7/3/23 11:56 PM, olcott wrote:
On 7/3/2023 10:22 PM, Richard Damon wrote:
On 7/3/23 10:20 PM, olcott wrote:
On 7/3/2023 4:55 PM, Richard Damon wrote:
On 7/3/23 5:34 PM, olcott wrote:Linz_H_Hat has its own embedded_H that returns 0.
On 7/3/2023 4:17 PM, Richard Damon wrote:
On 7/3/23 4:22 PM, olcott wrote:
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:So, how is New_H a halt decider then?
On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly >>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input >>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When >>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked in
I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>>> getting the copy the inputdecidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>>>>>> pathological relative to
itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>>>>> identical to H except for
the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>>
And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>>
Since H(D,D) will (apparently) determine that >>>>>>>>>>>>>>>>>>>>>>>>> the input is pathological, and thus defer to >>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D), then when we actually run D, >>>>>>>>>>>>>>>>>>>>>>>>> appearently it will get that same answer from >>>>>>>>>>>>>>>>>>>>>>>>> H1 and do the opposite of it, and thus H1 will >>>>>>>>>>>>>>>>>>>>>>>>> be wrong.
Remember, the "Pathological" program is built >>>>>>>>>>>>>>>>>>>>>>>>> on a copy of the ACTUAL program that you ask to >>>>>>>>>>>>>>>>>>>>>>>>> decide on it, including ALL of its "tricks", >>>>>>>>>>>>>>>>>>>>>>>>> including things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>>>>>
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one >>>>>>>>>>>>>>>>>>>>>>>>> that can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>>>>
working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>>>>>> inputs it returns 0
indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>>>>>> that D(D) halts.
This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in
every textbook.
So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" not >>>>>>>>>>>>>>>>>>>>>>> the C funciton H), or are you just admitting that >>>>>>>>>>>>>>>>>>>>>>> you wasted 120 hours looking at the wrong thing >>>>>>>>>>>>>>>>>>>>>>> because you have made yourself intentionally >>>>>>>>>>>>>>>>>>>>>>> ignorant of the subject so you don't understand >>>>>>>>>>>>>>>>>>>>>>> what you are trying to do.
New_D copies its input and simulates its input >>>>>>>>>>>>>>>>>>>>>> with its input.
It never sees New_H.
Why not? Since New_H is the thing that is >>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D needs >>>>>>>>>>>>>>>>>>>>> to be built on it.
New_H is embedded within New_D (as its middle >>>>>>>>>>>>>>>>>>>> states) just the
way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>>> New_H(New_H) halt?
The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>
typo
The only difference at the source code level is: >>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>>> exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is >>>>>>>>>>>>>>>> not about
inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>>>> function.
Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>>>> give the right answer.
That isn't 'H' in your system, but the script that >>>>>>>>>>>>>>> decides whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong >>>>>>>>>>>>>>> name for things.
You are using double-talk in a lame attempt to show that >>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>>>>
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt >>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ. >>>>>>>>>>>>>
That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>>
Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on changing H >>>>>>>>>>>>> and trying to use the old Ĥ which just fails to meet the >>>>>>>>>>>>> requirement of the proof, likely because you just don't >>>>>>>>>>>>> understand the theory involved.
It took me two years to figure out a clean way to copy the >>>>>>>>>>>> input to
Linz_H_Hat and not have the system crash. Relative to
Linz_H_Hat
Linz_H is H1. Now Linz_H_Hat only contradicts itself.
So, you are admitting that you actually can't do what is >>>>>>>>>>> required?
Copying the input should be trivial,
The relative addressing of the x86 language causes all function >>>>>>>>>> calls to call the wrong address.
Only because you aren't interpreting the input properly, but in >>>>>>>>> a non-Turing Complete manner.
As I said, the input description should be a chunck of code in >>>>>>>>> a virtual address space with a header that tells where that
code is supposed to be considered to be located at.
as the input should be a representation that packages a full >>>>>>>>>>> program in its own virtual environment, so a simple bit by >>>>>>>>>>> bit copy to empty ram will work. Your problem is that you >>>>>>>>>>> don't put the input into its own virtual address space, so >>>>>>>>>>> you have pathological interactions.
Linz_H_Hat must be built on the exact code base that is
deciding on it, in this case H, since you just said it isn't, >>>>>>>>>>> your proof is invalid.
Linz_Hat <is> Linz_H that takes one param and copies it
instead of
two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
It exactly matches the Linz spec.
You don't seem to understand what you are doing.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined >>>>>>>>> behavior. That behavior is a function of its input, but hasn't >>>>>>>>> been assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that has >>>>>>>>> a defined meaning/requirement for its final states. Linz_H, to >>>>>>>>> meet its requirements, MUST go to Qy if the input represents a >>>>>>>>> Halting Computation, and MUST go to Qn if the input represents >>>>>>>>> a non-halting computation.
Since Linz_H has actual requirements, a claimed implementation >>>>>>>>> of it can be checked to see if it actually meets the
requirements, and perhaps we can determine if it is possible to >>>>>>>>> meet them.
defined meaning for Linz_H_Hat as it isn't defined to be a
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't
generate any truth values, only behavior. You are just
showing that you don't understand the basics of the
requirements, and seem to think that "close" is good enough >>>>>>>>>>> for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which >>>>>>>>> has NO
decider.
Linz_H and Linz_H_Hat are C functions.
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus showing >>>>>>> you are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of
Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition >>>>>>>> to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there >>>>>>> return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted.
This allows Linz_H and Linz:H correctly report on the actual
behavior of their input.
No, since BOTH have an input that when run will HALT, and both
report that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0, >>>>>> *I never said that you are confused*
You always claim that your H by its various names is "Correct" to
return 0 as the input is non-halting because its "correct
simulation" will never reach a final state.
I think your brain is turning into mush, or is your pathology
overloading and trying to reverse the argument.
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting, >>>>
Linz_H_Hat has no access to Linz_H, only to its own embedded copy.
But embedded_H is an identical copy to Linz_H, so if embedded_H
returns 0, so does Lin
Linz_H simply simulates Linz_H_Hat until it terminates.
Then so must embedded_H, since it is an identical copy, and as you
have shown before, if H is defined that way, the H_Hat will never
halt, and thus H, since for this case you said it doesn't abort, will
also never halt and fail to be a decider.
We have gone through this many hundreds of times.
It is the exact same H(D,D) versus H1(D,D) thing.
Linz_H_Hat now has a pathological relationship to itself
this frees Linz_H from such a pathological relationship.
So Linz_H becomes H1, and Linz_H_Hat becomes H.
Nope, just shows you are not working in a Turing Equivalent system, and
thus NOTHING you say matters.
Now, since you are claiming that the embedded_H and Linz_H are
IDENTICAL machines, but the also produce DIFFERENT results when given
identical inputs, you have just proven that you are a LIAR.
*So you are back to rejecting verified facts out-of-hand*
It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
1 and the only difference is that H1 does not have a pathological
relationship to H and it is otherwise identical to H.
Since youy refuse to provide the verification fact about where the paths
of H(D,D) and D(D) differ, you don't HAVE a "verified fact".
You are just proving that you are just a LIAR and an IDIOT.
What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
DEFINITION WRONG and you claim tha tit is right is a verified LIE.
On 7/3/2023 11:06 PM, Richard Damon wrote:
On 7/3/23 11:56 PM, olcott wrote:
On 7/3/2023 10:22 PM, Richard Damon wrote:
On 7/3/23 10:20 PM, olcott wrote:
On 7/3/2023 4:55 PM, Richard Damon wrote:
On 7/3/23 5:34 PM, olcott wrote:Linz_H_Hat has its own embedded_H that returns 0.
On 7/3/2023 4:17 PM, Richard Damon wrote:
On 7/3/23 4:22 PM, olcott wrote:
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote:
On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly >>>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input >>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When >>>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked inSo, how is New_H a halt decider then?
New_D copies its input and simulates its input >>>>>>>>>>>>>>>>>>>>>>> with its input.I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>>>> getting the copy the inputdecidability decider mode determines that D >>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to >>>>>>>>>>>>>>>>>>>>>>>>>>> itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual >>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>>>>>> identical to H except for >>>>>>>>>>>>>>>>>>>>>>>>>>> the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>>>
And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>>>
Since H(D,D) will (apparently) determine that >>>>>>>>>>>>>>>>>>>>>>>>>> the input is pathological, and thus defer to >>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D), then when we actually run D, >>>>>>>>>>>>>>>>>>>>>>>>>> appearently it will get that same answer from >>>>>>>>>>>>>>>>>>>>>>>>>> H1 and do the opposite of it, and thus H1 will >>>>>>>>>>>>>>>>>>>>>>>>>> be wrong.
Remember, the "Pathological" program is built >>>>>>>>>>>>>>>>>>>>>>>>>> on a copy of the ACTUAL program that you ask >>>>>>>>>>>>>>>>>>>>>>>>>> to decide on it, including ALL of its >>>>>>>>>>>>>>>>>>>>>>>>>> "tricks", including things like this "batch >>>>>>>>>>>>>>>>>>>>>>>>>> processing".
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - >>>>>>>>>>>>>>>>>>>>>>>>>> Input structure, but there isn't, at least not >>>>>>>>>>>>>>>>>>>>>>>>>> one that can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>>>>>
working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
input is in the well defined set of >>>>>>>>>>>>>>>>>>>>>>>>> pathological inputs it returns 0 >>>>>>>>>>>>>>>>>>>>>>>>> indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
then knows to invoke H1(D,D) to correctly >>>>>>>>>>>>>>>>>>>>>>>>> report that D(D) halts.
This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in
every textbook.
So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" not >>>>>>>>>>>>>>>>>>>>>>>> the C funciton H), or are you just admitting >>>>>>>>>>>>>>>>>>>>>>>> that you wasted 120 hours looking at the wrong >>>>>>>>>>>>>>>>>>>>>>>> thing because you have made yourself >>>>>>>>>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>>>>>
It never sees New_H.
Why not? Since New_H is the thing that is >>>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D needs >>>>>>>>>>>>>>>>>>>>>> to be built on it.
New_H is embedded within New_D (as its middle >>>>>>>>>>>>>>>>>>>>> states) just the
way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>>>> New_H(New_H) halt?
The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>>
typo
The only difference at the source code level is: >>>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>>>> exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf
In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is >>>>>>>>>>>>>>>>> not about
inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>>>>> function.
Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>>>>> give the right answer.
That isn't 'H' in your system, but the script that >>>>>>>>>>>>>>>> decides whether to use H or H1.
Your error is in calling the wrong thing 'H'
You are just showing you are lying by using the wrong >>>>>>>>>>>>>>>> name for things.
You are using double-talk in a lame attempt to show that >>>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>>>>>
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt >>>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ. >>>>>>>>>>>>>>
That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>>>
Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on changing >>>>>>>>>>>>>> H and trying to use the old Ĥ which just fails to meet the >>>>>>>>>>>>>> requirement of the proof, likely because you just don't >>>>>>>>>>>>>> understand the theory involved.
It took me two years to figure out a clean way to copy the >>>>>>>>>>>>> input to
Linz_H_Hat and not have the system crash. Relative to >>>>>>>>>>>>> Linz_H_Hat
Linz_H is H1. Now Linz_H_Hat only contradicts itself. >>>>>>>>>>>>>
So, you are admitting that you actually can't do what is >>>>>>>>>>>> required?
Copying the input should be trivial,
The relative addressing of the x86 language causes all function >>>>>>>>>>> calls to call the wrong address.
Only because you aren't interpreting the input properly, but >>>>>>>>>> in a non-Turing Complete manner.
As I said, the input description should be a chunck of code in >>>>>>>>>> a virtual address space with a header that tells where that >>>>>>>>>> code is supposed to be considered to be located at.
as the input should be a representation that packages a full >>>>>>>>>>>> program in its own virtual environment, so a simple bit by >>>>>>>>>>>> bit copy to empty ram will work. Your problem is that you >>>>>>>>>>>> don't put the input into its own virtual address space, so >>>>>>>>>>>> you have pathological interactions.
Linz_H_Hat must be built on the exact code base that is >>>>>>>>>>>> deciding on it, in this case H, since you just said it >>>>>>>>>>>> isn't, your proof is invalid.
Linz_Hat <is> Linz_H that takes one param and copies it >>>>>>>>>>> instead of
two params and has an infinite loop at its accept state.
So, Two things that are different are exactly the same?
It exactly matches the Linz spec.
You don't seem to understand what you are doing.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined >>>>>>>>>> behavior. That behavior is a function of its input, but hasn't >>>>>>>>>> been assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that has >>>>>>>>>> a defined meaning/requirement for its final states. Linz_H, to >>>>>>>>>> meet its requirements, MUST go to Qy if the input represents a >>>>>>>>>> Halting Computation, and MUST go to Qn if the input represents >>>>>>>>>> a non-halting computation.
Since Linz_H has actual requirements, a claimed implementation >>>>>>>>>> of it can be checked to see if it actually meets the
requirements, and perhaps we can determine if it is possible >>>>>>>>>> to meet them.
defined meaning for Linz_H_Hat as it isn't defined to be a >>>>>>>>>> decider.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't >>>>>>>>>>>> generate any truth values, only behavior. You are just >>>>>>>>>>>> showing that you don't understand the basics of the
requirements, and seem to think that "close" is good enough >>>>>>>>>>>> for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which >>>>>>>>>> has NO
Linz_H and Linz_H_Hat are C functions.
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus showing >>>>>>>> you are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of >>>>>>>>> Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition >>>>>>>>> to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there >>>>>>>> return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted. >>>>>>>>
This allows Linz_H and Linz:H correctly report on the actual >>>>>>>>> behavior of their input.
No, since BOTH have an input that when run will HALT, and both >>>>>>>> report that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0, >>>>>>> *I never said that you are confused*
You always claim that your H by its various names is "Correct" to
return 0 as the input is non-halting because its "correct
simulation" will never reach a final state.
I think your brain is turning into mush, or is your pathology
overloading and trying to reverse the argument.
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting, >>>>>
Linz_H_Hat has no access to Linz_H, only to its own embedded copy.
But embedded_H is an identical copy to Linz_H, so if embedded_H
returns 0, so does Lin
Linz_H simply simulates Linz_H_Hat until it terminates.
Then so must embedded_H, since it is an identical copy, and as you
have shown before, if H is defined that way, the H_Hat will never
halt, and thus H, since for this case you said it doesn't abort,
will also never halt and fail to be a decider.
We have gone through this many hundreds of times.
It is the exact same H(D,D) versus H1(D,D) thing.
Linz_H_Hat now has a pathological relationship to itself
this frees Linz_H from such a pathological relationship.
So Linz_H becomes H1, and Linz_H_Hat becomes H.
Nope, just shows you are not working in a Turing Equivalent system,
and thus NOTHING you say matters.
You can make such claims with bluster finding a source that actually
supports them is a whole different matter.
It is the case that when embedded_H is a simulating termination analyzer applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
normally and must have its simulation aborted.
It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
have its simulation terminated.
Now, since you are claiming that the embedded_H and Linz_H are
IDENTICAL machines, but the also produce DIFFERENT results when
given identical inputs, you have just proven that you are a LIAR.
*So you are back to rejecting verified facts out-of-hand*
It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
1 and the only difference is that H1 does not have a pathological
relationship to H and it is otherwise identical to H.
Since youy refuse to provide the verification fact about where the
paths of H(D,D) and D(D) differ, you don't HAVE a "verified fact".
The source code and execution trace have been available for a year.
I have explained this many times the problem seems to be that you simply don't believe the facts. You say that a simulation is incorrect yet
cannot point to the instruction that was simulated incorrectly only
because the simulation is actually correct.
You are just proving that you are just a LIAR and an IDIOT.
What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
DEFINITION WRONG and you claim tha tit is right is a verified LIE.
It depends on how you frame the problem.
If you frame the problem in that a halt decider must divide up finite
strings pairs into those that halt when directly executed and those that
do not, then no single program can do this. A pair of programs might do
this.
If you frame the problem in that a halt decider must divide up finite
stings into those that must have their simulation aborted to prevent
their infinite execution, then from H's point of view D does not halt.
On 7/4/23 12:57 AM, olcott wrote:
On 7/3/2023 11:06 PM, Richard Damon wrote:
On 7/3/23 11:56 PM, olcott wrote:
On 7/3/2023 10:22 PM, Richard Damon wrote:
On 7/3/23 10:20 PM, olcott wrote:
On 7/3/2023 4:55 PM, Richard Damon wrote:
On 7/3/23 5:34 PM, olcott wrote:
On 7/3/2023 4:17 PM, Richard Damon wrote:
On 7/3/23 4:22 PM, olcott wrote:
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
typoOn 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input >>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When >>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked inSo, how is New_H a halt decider then? >>>>>>>>>>>>>>>>>>>>
New_D copies its input and simulates its input >>>>>>>>>>>>>>>>>>>>>>>> with its input.decidability decider mode determines that D >>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to >>>>>>>>>>>>>>>>>>>>>>>>>>>> itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual >>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the directly executed D(D). H1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> is identical to H except for >>>>>>>>>>>>>>>>>>>>>>>>>>>> the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>>>>
Since H(D,D) will (apparently) determine that >>>>>>>>>>>>>>>>>>>>>>>>>>> the input is pathological, and thus defer to >>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D), then when we actually run D, >>>>>>>>>>>>>>>>>>>>>>>>>>> appearently it will get that same answer from >>>>>>>>>>>>>>>>>>>>>>>>>>> H1 and do the opposite of it, and thus H1 >>>>>>>>>>>>>>>>>>>>>>>>>>> will be wrong.
Remember, the "Pathological" program is built >>>>>>>>>>>>>>>>>>>>>>>>>>> on a copy of the ACTUAL program that you ask >>>>>>>>>>>>>>>>>>>>>>>>>>> to decide on it, including ALL of its >>>>>>>>>>>>>>>>>>>>>>>>>>> "tricks", including things like this "batch >>>>>>>>>>>>>>>>>>>>>>>>>>> processing".
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - >>>>>>>>>>>>>>>>>>>>>>>>>>> Input structure, but there isn't, at least >>>>>>>>>>>>>>>>>>>>>>>>>>> not one that can affect the answer of the >>>>>>>>>>>>>>>>>>>>>>>>>>> problem.
I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>>>>> getting the copy the input >>>>>>>>>>>>>>>>>>>>>>>>>> working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
input is in the well defined set of >>>>>>>>>>>>>>>>>>>>>>>>>> pathological inputs it returns 0 >>>>>>>>>>>>>>>>>>>>>>>>>> indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
then knows to invoke H1(D,D) to correctly >>>>>>>>>>>>>>>>>>>>>>>>>> report that D(D) halts.
This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in >>>>>>>>>>>>>>>>>>>>>>>>>> every textbook.
So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" >>>>>>>>>>>>>>>>>>>>>>>>> not the C funciton H), or are you just >>>>>>>>>>>>>>>>>>>>>>>>> admitting that you wasted 120 hours looking at >>>>>>>>>>>>>>>>>>>>>>>>> the wrong thing because you have made yourself >>>>>>>>>>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>>>>>>
It never sees New_H.
Why not? Since New_H is the thing that is >>>>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D >>>>>>>>>>>>>>>>>>>>>>> needs to be built on it.
New_H is embedded within New_D (as its middle >>>>>>>>>>>>>>>>>>>>>> states) just the
way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>>>>> New_H(New_H) halt?
The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>>>
The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>>>>> exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>
In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it is >>>>>>>>>>>>>>>>>> not about
inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>>>>>> function.
Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>>>>>> give the right answer.
That isn't 'H' in your system, but the script that >>>>>>>>>>>>>>>>> decides whether to use H or H1.
Your error is in calling the wrong thing 'H' >>>>>>>>>>>>>>>>>
You are just showing you are lying by using the wrong >>>>>>>>>>>>>>>>> name for things.
You are using double-talk in a lame attempt to show that >>>>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of >>>>>>>>>>>>>>>> Linz Ĥ.
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt >>>>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ. >>>>>>>>>>>>>>>
That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>>>>
Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on changing >>>>>>>>>>>>>>> H and trying to use the old Ĥ which just fails to meet >>>>>>>>>>>>>>> the requirement of the proof, likely because you just >>>>>>>>>>>>>>> don't understand the theory involved.
It took me two years to figure out a clean way to copy the >>>>>>>>>>>>>> input to
Linz_H_Hat and not have the system crash. Relative to >>>>>>>>>>>>>> Linz_H_Hat
Linz_H is H1. Now Linz_H_Hat only contradicts itself. >>>>>>>>>>>>>>
So, you are admitting that you actually can't do what is >>>>>>>>>>>>> required?
Copying the input should be trivial,
The relative addressing of the x86 language causes all function >>>>>>>>>>>> calls to call the wrong address.
Only because you aren't interpreting the input properly, but >>>>>>>>>>> in a non-Turing Complete manner.
As I said, the input description should be a chunck of code >>>>>>>>>>> in a virtual address space with a header that tells where >>>>>>>>>>> that code is supposed to be considered to be located at. >>>>>>>>>>>
So, Two things that are different are exactly the same?
as the input should be a representation that packages a >>>>>>>>>>>>> full program in its own virtual environment, so a simple >>>>>>>>>>>>> bit by bit copy to empty ram will work. Your problem is >>>>>>>>>>>>> that you don't put the input into its own virtual address >>>>>>>>>>>>> space, so you have pathological interactions.
Linz_H_Hat must be built on the exact code base that is >>>>>>>>>>>>> deciding on it, in this case H, since you just said it >>>>>>>>>>>>> isn't, your proof is invalid.
Linz_Hat <is> Linz_H that takes one param and copies it >>>>>>>>>>>> instead of
two params and has an infinite loop at its accept state. >>>>>>>>>>>
It exactly matches the Linz spec.
You don't seem to understand what you are doing.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined >>>>>>>>>>> behavior. That behavior is a function of its input, but
hasn't been assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that >>>>>>>>>>> has a defined meaning/requirement for its final states.
Linz_H, to meet its requirements, MUST go to Qy if the input >>>>>>>>>>> represents a Halting Computation, and MUST go to Qn if the >>>>>>>>>>> input represents a non-halting computation.
Since Linz_H has actual requirements, a claimed
implementation of it can be checked to see if it actually >>>>>>>>>>> meets the requirements, and perhaps we can determine if it is >>>>>>>>>>> possible to meet them.
defined meaning for Linz_H_Hat as it isn't defined to be a >>>>>>>>>>> decider.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't >>>>>>>>>>>>> generate any truth values, only behavior. You are just >>>>>>>>>>>>> showing that you don't understand the basics of the
requirements, and seem to think that "close" is good enough >>>>>>>>>>>>> for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, >>>>>>>>>>> which has NO
Linz_H and Linz_H_Hat are C functions.
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus
showing you are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of >>>>>>>>>> Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition >>>>>>>>>> to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so
there return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted. >>>>>>>>>
This allows Linz_H and Linz:H correctly report on the actual >>>>>>>>>> behavior of their input.
No, since BOTH have an input that when run will HALT, and both >>>>>>>>> report that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0, >>>>>>>> *I never said that you are confused*
You always claim that your H by its various names is "Correct" to >>>>>>> return 0 as the input is non-halting because its "correct
simulation" will never reach a final state.
I think your brain is turning into mush, or is your pathology
overloading and trying to reverse the argument.
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means
Halting,
Linz_H_Hat has its own embedded_H that returns 0.
Linz_H_Hat has no access to Linz_H, only to its own embedded copy.
But embedded_H is an identical copy to Linz_H, so if embedded_H
returns 0, so does Lin
Linz_H simply simulates Linz_H_Hat until it terminates.
Then so must embedded_H, since it is an identical copy, and as you
have shown before, if H is defined that way, the H_Hat will never
halt, and thus H, since for this case you said it doesn't abort,
will also never halt and fail to be a decider.
We have gone through this many hundreds of times.
It is the exact same H(D,D) versus H1(D,D) thing.
Linz_H_Hat now has a pathological relationship to itself
this frees Linz_H from such a pathological relationship.
So Linz_H becomes H1, and Linz_H_Hat becomes H.
Nope, just shows you are not working in a Turing Equivalent system,
and thus NOTHING you say matters.
You can make such claims with bluster finding a source that actually
supports them is a whole different matter.
No, you are just showing that you believe Russell's Teapot actually
exists. YOU are the one making claims, so YOU are the one that needs to
make a actual proof of correctness, and show the error in the counter
claims.
It is a PROVEN fact that two computation machines with the exact same algorithm and the exact same input will always produce the same result.
You are claiming differently, WITHOUT PROOF, so you are shown to be a LIAR.
Either H and H1 are claimed to be the same machine, or they are not. If
they are the same machine, they need to give the same answer, or they
are not, and thus H1 getting the right answer to the H^ built on H
doesn't matter.
It is the case that when embedded_H is a simulating termination analyzer
applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
normally and must have its simulation aborted.
So?
It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
have its simulation terminated.
Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus
showing that you hav just been LYING for decades.
Now, since you are claiming that the embedded_H and Linz_H are
IDENTICAL machines, but the also produce DIFFERENT results when
given identical inputs, you have just proven that you are a LIAR.
*So you are back to rejecting verified facts out-of-hand*
It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
1 and the only difference is that H1 does not have a pathological
relationship to H and it is otherwise identical to H.
Since youy refuse to provide the verification fact about where the
paths of H(D,D) and D(D) differ, you don't HAVE a "verified fact".
The source code and execution trace have been available for a year.
I have explained this many times the problem seems to be that you simply
don't believe the facts. You say that a simulation is incorrect yet
cannot point to the instruction that was simulated incorrectly only
because the simulation is actually correct.
No, YOU LIE. The "Call H" instruction has been simulated incorrectly (or
not simulated at all an false presumptions about what it does used).
You are just proving that you are just a LIAR and an IDIOT.
What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
DEFINITION WRONG and you claim tha tit is right is a verified LIE.
It depends on how you frame the problem.
If you frame the problem in that a halt decider must divide up finite
strings pairs into those that halt when directly executed and those that
do not, then no single program can do this. A pair of programs might do
this.
So, you agree with the Halting Theorem, as that it is the precise
problem being asked about.
If you frame the problem in that a halt decider must divide up finite
stings into those that must have their simulation aborted to prevent
their infinite execution, then from H's point of view D does not halt.
So, you are admitting to using a Strawman, and nothing you say applies
to the ACTUAL Halting Problem.
You have maybe shown that POOP might be decidable, it at least can't use
the simple pathological example to show it, but POOP isn't about Halting
but partial simulation, so who cares about it.
This shows your mental instability as we don't care about what H sees,
which is just something of its imagination, we care about the reality of
what D actually does. Just like we care about what is ACTUALLY true,
verses what you think must be true without actually trying to prove it logically.
On 7/4/2023 8:27 AM, Richard Damon wrote:
On 7/4/23 12:57 AM, olcott wrote:
On 7/3/2023 11:06 PM, Richard Damon wrote:
On 7/3/23 11:56 PM, olcott wrote:
On 7/3/2023 10:22 PM, Richard Damon wrote:
On 7/3/23 10:20 PM, olcott wrote:
On 7/3/2023 4:55 PM, Richard Damon wrote:But embedded_H is an identical copy to Linz_H, so if embedded_H
On 7/3/23 5:34 PM, olcott wrote:
On 7/3/2023 4:17 PM, Richard Damon wrote:
On 7/3/23 4:22 PM, olcott wrote:*I never said that you are confused*
On 7/3/2023 2:58 PM, Richard Damon wrote:
On 7/3/23 2:48 PM, olcott wrote:
On 7/3/2023 1:25 PM, Richard Damon wrote:
On 7/3/23 1:57 PM, olcott wrote:
On 7/3/2023 11:26 AM, Richard Damon wrote:
On 7/3/23 12:11 PM, olcott wrote:
On 7/3/2023 11:01 AM, Richard Damon wrote:
On 7/3/23 11:56 AM, olcott wrote:
On 7/3/2023 10:35 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/3/23 10:45 AM, olcott wrote:
On 7/3/2023 9:24 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
typoOn 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When >>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> decidability decider mode determines that D >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual >>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the directly executed D(D). H1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is identical to H except for >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>So, how is New_H a halt decider then? >>>>>>>>>>>>>>>>>>>>>
New_D copies its input and simulates its input >>>>>>>>>>>>>>>>>>>>>>>>> with its input.
And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>>>>>
Since H(D,D) will (apparently) determine >>>>>>>>>>>>>>>>>>>>>>>>>>>> that the input is pathological, and thus >>>>>>>>>>>>>>>>>>>>>>>>>>>> defer to H1(D,D), then when we actually run >>>>>>>>>>>>>>>>>>>>>>>>>>>> D, appearently it will get that same answer >>>>>>>>>>>>>>>>>>>>>>>>>>>> from H1 and do the opposite of it, and thus >>>>>>>>>>>>>>>>>>>>>>>>>>>> H1 will be wrong.
Remember, the "Pathological" program is >>>>>>>>>>>>>>>>>>>>>>>>>>>> built on a copy of the ACTUAL program that >>>>>>>>>>>>>>>>>>>>>>>>>>>> you ask to decide on it, including ALL of >>>>>>>>>>>>>>>>>>>>>>>>>>>> its "tricks", including things like this >>>>>>>>>>>>>>>>>>>>>>>>>>>> "batch processing".
You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - >>>>>>>>>>>>>>>>>>>>>>>>>>>> Input structure, but there isn't, at least >>>>>>>>>>>>>>>>>>>>>>>>>>>> not one that can affect the answer of the >>>>>>>>>>>>>>>>>>>>>>>>>>>> problem.
I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>>>>>> getting the copy the input >>>>>>>>>>>>>>>>>>>>>>>>>>> working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
input is in the well defined set of >>>>>>>>>>>>>>>>>>>>>>>>>>> pathological inputs it returns 0 >>>>>>>>>>>>>>>>>>>>>>>>>>> indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H >>>>>>>>>>>>>>>>>>>>>>>>>>> then knows to invoke H1(D,D) to correctly >>>>>>>>>>>>>>>>>>>>>>>>>>> report that D(D) halts.
This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in >>>>>>>>>>>>>>>>>>>>>>>>>>> every textbook.
So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" >>>>>>>>>>>>>>>>>>>>>>>>>> not the C funciton H), or are you just >>>>>>>>>>>>>>>>>>>>>>>>>> admitting that you wasted 120 hours looking at >>>>>>>>>>>>>>>>>>>>>>>>>> the wrong thing because you have made yourself >>>>>>>>>>>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>>>>>>>
It never sees New_H.
Why not? Since New_H is the thing that is >>>>>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D >>>>>>>>>>>>>>>>>>>>>>>> needs to be built on it.
New_H is embedded within New_D (as its middle >>>>>>>>>>>>>>>>>>>>>>> states) just the
way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>>>>>> New_H(New_H) halt?
The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>>>>
The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>>>>>> exactly New_H
But New_D needs to call New_H,
Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>
In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.
The halting problem is about undecidable inputs, it >>>>>>>>>>>>>>>>>>> is not about
inserting bugs into a halt decider to make it cease >>>>>>>>>>>>>>>>>>> to function.
Right, and in Linz, H is the decider that is claimed >>>>>>>>>>>>>>>>>> to give the right answer.
That isn't 'H' in your system, but the script that >>>>>>>>>>>>>>>>>> decides whether to use H or H1.
Your error is in calling the wrong thing 'H' >>>>>>>>>>>>>>>>>>
You are just showing you are lying by using the wrong >>>>>>>>>>>>>>>>>> name for things.
You are using double-talk in a lame attempt to show that >>>>>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of >>>>>>>>>>>>>>>>> Linz Ĥ.
So you agree with the Theorem.
No 'Linz H' can exist that correctly decides the halt >>>>>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ. >>>>>>>>>>>>>>>>
That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>>>>>
Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on >>>>>>>>>>>>>>>> changing H and trying to use the old Ĥ which just fails >>>>>>>>>>>>>>>> to meet the requirement of the proof, likely because you >>>>>>>>>>>>>>>> just don't understand the theory involved.
It took me two years to figure out a clean way to copy >>>>>>>>>>>>>>> the input to
Linz_H_Hat and not have the system crash. Relative to >>>>>>>>>>>>>>> Linz_H_Hat
Linz_H is H1. Now Linz_H_Hat only contradicts itself. >>>>>>>>>>>>>>>
So, you are admitting that you actually can't do what is >>>>>>>>>>>>>> required?
Copying the input should be trivial,
The relative addressing of the x86 language causes all >>>>>>>>>>>>> function
calls to call the wrong address.
Only because you aren't interpreting the input properly, but >>>>>>>>>>>> in a non-Turing Complete manner.
As I said, the input description should be a chunck of code >>>>>>>>>>>> in a virtual address space with a header that tells where >>>>>>>>>>>> that code is supposed to be considered to be located at. >>>>>>>>>>>>
So, Two things that are different are exactly the same? >>>>>>>>>>>>
as the input should be a representation that packages a >>>>>>>>>>>>>> full program in its own virtual environment, so a simple >>>>>>>>>>>>>> bit by bit copy to empty ram will work. Your problem is >>>>>>>>>>>>>> that you don't put the input into its own virtual address >>>>>>>>>>>>>> space, so you have pathological interactions.
Linz_H_Hat must be built on the exact code base that is >>>>>>>>>>>>>> deciding on it, in this case H, since you just said it >>>>>>>>>>>>>> isn't, your proof is invalid.
Linz_Hat <is> Linz_H that takes one param and copies it >>>>>>>>>>>>> instead of
two params and has an infinite loop at its accept state. >>>>>>>>>>>>
It exactly matches the Linz spec.
You don't seem to understand what you are doing.
Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined >>>>>>>>>>>> behavior. That behavior is a function of its input, but >>>>>>>>>>>> hasn't been assigned any "meaning".
Linz_H is a Turing Machine (if it actually can exist) that >>>>>>>>>>>> has a defined meaning/requirement for its final states. >>>>>>>>>>>> Linz_H, to meet its requirements, MUST go to Qy if the input >>>>>>>>>>>> represents a Halting Computation, and MUST go to Qn if the >>>>>>>>>>>> input represents a non-halting computation.
Since Linz_H has actual requirements, a claimed
implementation of it can be checked to see if it actually >>>>>>>>>>>> meets the requirements, and perhaps we can determine if it >>>>>>>>>>>> is possible to meet them.
defined meaning for Linz_H_Hat as it isn't defined to be a >>>>>>>>>>>> decider.
Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't >>>>>>>>>>>>>> generate any truth values, only behavior. You are just >>>>>>>>>>>>>> showing that you don't understand the basics of the >>>>>>>>>>>>>> requirements, and seem to think that "close" is good >>>>>>>>>>>>>> enough for proofs.
Linz_H_Hat(Linz_H_Hat) returns 0.
Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, >>>>>>>>>>>> which has NO
Linz_H and Linz_H_Hat are C functions.
Linz:H and Linz:Ĥ are Turing machines.
So, inventing new terminology without introduction, thus
showing you are being intentionally deceptive.
Linz_H and Linz:H are both directly embedded within a copy of >>>>>>>>>>> Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition >>>>>>>>>>> to Ĥ.qn still means not halting.
No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so >>>>>>>>>> there return value has no meaning.
Ĥ has no meaning, so it can't be "incorrect" or contradicted. >>>>>>>>>>
This allows Linz_H and Linz:H correctly report on the actual >>>>>>>>>>> behavior of their input.
No, since BOTH have an input that when run will HALT, and both >>>>>>>>>> report that it will not, both are just wrong.
Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly"
return 0,
You always claim that your H by its various names is "Correct" >>>>>>>> to return 0 as the input is non-halting because its "correct
simulation" will never reach a final state.
I think your brain is turning into mush, or is your pathology
overloading and trying to reverse the argument.
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means
Halting,
Linz_H_Hat has its own embedded_H that returns 0.
Linz_H_Hat has no access to Linz_H, only to its own embedded copy. >>>>>>
returns 0, so does Lin
Linz_H simply simulates Linz_H_Hat until it terminates.
Then so must embedded_H, since it is an identical copy, and as you >>>>>> have shown before, if H is defined that way, the H_Hat will never
halt, and thus H, since for this case you said it doesn't abort,
will also never halt and fail to be a decider.
We have gone through this many hundreds of times.
It is the exact same H(D,D) versus H1(D,D) thing.
Linz_H_Hat now has a pathological relationship to itself
this frees Linz_H from such a pathological relationship.
So Linz_H becomes H1, and Linz_H_Hat becomes H.
Nope, just shows you are not working in a Turing Equivalent system,
and thus NOTHING you say matters.
You can make such claims with bluster finding a source that actually
supports them is a whole different matter.
No, you are just showing that you believe Russell's Teapot actually
exists. YOU are the one making claims, so YOU are the one that needs
to make a actual proof of correctness, and show the error in the
counter claims.
If you believe that I am incorrect you need much more than your own presumption as a basis for an actual rebuttal. You might not have
much more than this mere presumption.
It is a PROVEN fact that two computation machines with the exact same
algorithm and the exact same input will always produce the same result.
You are claiming differently, WITHOUT PROOF, so you are shown to be a
LIAR.
H1(D,D) and H(D,D) have different execution traces because D calls H and
D does not call H1. A not very bright software engineer could understand this.
Either H and H1 are claimed to be the same machine, or they are not.
If they are the same machine, they need to give the same answer, or
they are not, and thus H1 getting the right answer to the H^ built on
H doesn't matter.
It is the case that when embedded_H is a simulating termination analyzer >>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
normally and must have its simulation aborted.
So?
It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
have its simulation terminated.
Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus
showing that you hav just been LYING for decades.
It is a simple execution trace that even a bright high school student
can understand now that I have shown it at the C source code level.
Now, since you are claiming that the embedded_H and Linz_H are
IDENTICAL machines, but the also produce DIFFERENT results when
given identical inputs, you have just proven that you are a LIAR.
*So you are back to rejecting verified facts out-of-hand*
It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
1 and the only difference is that H1 does not have a pathological
relationship to H and it is otherwise identical to H.
Since youy refuse to provide the verification fact about where the
paths of H(D,D) and D(D) differ, you don't HAVE a "verified fact".
The source code and execution trace have been available for a year.
I have explained this many times the problem seems to be that you simply >>> don't believe the facts. You say that a simulation is incorrect yet
cannot point to the instruction that was simulated incorrectly only
because the simulation is actually correct.
No, YOU LIE. The "Call H" instruction has been simulated incorrectly
(or not simulated at all an false presumptions about what it does used).
You are just proving that you are just a LIAR and an IDIOT.
What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
DEFINITION WRONG and you claim tha tit is right is a verified LIE.
It depends on how you frame the problem.
If you frame the problem in that a halt decider must divide up finite
strings pairs into those that halt when directly executed and those that >>> do not, then no single program can do this. A pair of programs might do
this.
So, you agree with the Halting Theorem, as that it is the precise
problem being asked about.
If you frame the problem in that a halt decider must divide up finite
stings into those that must have their simulation aborted to prevent
their infinite execution, then from H's point of view D does not halt.
So, you are admitting to using a Strawman, and nothing you say applies
to the ACTUAL Halting Problem.
You have maybe shown that POOP might be decidable, it at least can't
use the simple pathological example to show it, but POOP isn't about
Halting but partial simulation, so who cares about it.
This shows your mental instability as we don't care about what H sees,
which is just something of its imagination, we care about the reality
of what D actually does. Just like we care about what is ACTUALLY
true, verses what you think must be true without actually trying to
prove it logically.
It turns out that Linz_H(Linz_H_Hat, Linz_H_Hat) == 1
because Linz_H_Hat(Linz_H_Hat) == 0
This translates into Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to Linz:H.qy because Linz:Ĥ applied to ⟨Ĥ⟩
transitions to Linz:Ĥ.qn
So I have overcome the issue of H(D,D) reporting non-halting and
the directly executed D(D) then halting in two different ways:
(1) Linz_H(Linz_H_Hat, Linz_H_Hat) reports halting and
Linz_H_Hat(Linz_H_Hat) halts.
(2) With the three value return of H(D,D) H only reports halting
when its directly executed input actually halts and seems to
defeat Rice by separately reporting all conventional halting
problem proof pathological inputs.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 106:48:26 |
| Calls: | 6,662 |
| Calls today: | 4 |
| Files: | 12,209 |
| Messages: | 5,335,410 |