<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's...
trivial to do for this one case) that correctly determines that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were not halted. That much is a truism.
Ben clearly agrees that the above criteria have been met,
yet feels that professor Sipser was tricked into agreeing
that this means that:
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
I spent two years deriving those words that Professor Sipser
agreed with. It seems to me that every software engineer would
agree that the second part is logically entailed by the first part.
On 7/4/2024 1:17 PM, Richard Damon wrote:
On 7/4/24 2:04 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's...
trivial to do for this one case) that correctly determines that P(P) >>> > *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were not
halted. That much is a truism.
Ben clearly agrees that the above criteria have been met,
yet feels that professor Sipser was tricked into agreeing
that this means that:
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
I spent two years deriving those words that Professor Sipser
agreed with. It seems to me that every software engineer would
agree that the second part is logically entailed by the first part.
You mean you WASTED two years and set a trap for your self that you
fell into.
The problem is that Ben is adopting your definitions that professor
Sipser is not using.
Ben agrees that my criteria have been met according to their
exact words. If you want to lie about that I won't talk to
you again.
On 7/4/2024 5:21 PM, Richard Damon wrote:
On 7/4/24 2:32 PM, olcott wrote:
On 7/4/2024 1:17 PM, Richard Damon wrote:
On 7/4/24 2:04 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D >>>>> until H correctly determines that its simulated D would never >>>>> stop running unless aborted then
H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's >>>>> > trivial to do for this one case) that correctly determines thatP(P)
*would* never stop running *unless* aborted....
But H determines (correctly) that D would not halt if it were not >>>>> > halted. That much is a truism.
Ben clearly agrees that the above criteria have been met,
yet feels that professor Sipser was tricked into agreeing
that this means that:
H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations.
I spent two years deriving those words that Professor Sipser
agreed with. It seems to me that every software engineer would
agree that the second part is logically entailed by the first part.
You mean you WASTED two years and set a trap for your self that you
fell into.
The problem is that Ben is adopting your definitions that professor
Sipser is not using.
Ben agrees that my criteria have been met according to their
exact words. If you want to lie about that I won't talk to
you again.
Which meant different things, so not the same.
The biggest problem is your H/P interlocking program pair is something
outside the normal scope of Computation theory.
The way you have built your Deicder/Decider combination isn't actualy
within the definition of normal Computaiton Theory, as that would have
Decider as a totally independent program from the program it is
deciding on.
Your H and D aren't that sort of thing because they are interwined
into a single memory space, and even share code.
This makes some things possible to do about the pair that can not be
done if they were independent programs, like H being able to detect
that D calls itself (but not copies of itself, which is why you don't
allow those copies, as that breasks your lie).
Ever heard of string comparison?
H can detect that D calls copies of itself.
That merely makes the details more complex.
Another of the big effect of thins, is that the way you defined it, D
actually does have access to the decider that is going to decide it
(if we follow your rule and name the decider H). This can turn what
used to be an independent fully defined program P into a dependent
program template.
The key issue is that by my basis structure that applies equally
to DD correctly simulated by HH as it applies to ⟨Ĥ⟩ correctly
simulated by embedded_H is that the paradoxical decision point
cannot be reached. This converts the "impossible" problem into a
difficult one.
Undet THAT condition, Ben agreed that yoUr H could conclude that no
version of H could simulate the version of D that uses it, to its
final state. Since P is a template, and not a program, it doesn't have
the normal Objective definition of behavior, and thus your subjective
one might need to be used, even with its problems.
The key point that you must acknowledge before continuing is
that the criteria is met for H/D. I can't tolerate one more
reply where you deny this.
When you asked Professor Sipser, The H will be a SPECIFIC decider, and
the D will be a specific input that doesn't change, and thus DOES have
an objective behavior (that of directly running it, or completely
simulating it) and only if H can determine that this OBJECTIVE
definition is met, can it abort. Of course, due the relationship in
the construction of D, the H that it was built from can NEVER make
that correct determination, as if it does, then D will halt and thus H
could not have made the determination.
The fact that you don't understand this just shows how little you
understand the theory, or it seems, programming in general.
On 7/4/2024 6:18 PM, Richard Damon wrote:
On 7/4/24 6:33 PM, olcott wrote:
On 7/4/2024 5:21 PM, Richard Damon wrote:
On 7/4/24 2:32 PM, olcott wrote:
On 7/4/2024 1:17 PM, Richard Damon wrote:
On 7/4/24 2:04 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>> until H correctly determines that its simulated D would never >>>>>>> stop running unless aborted then
H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's >>>>>>> > trivial to do for this one case) that correctly determinesthat P(P)
*would* never stop running *unless* aborted....
But H determines (correctly) that D would not halt if it were not >>>>>>> > halted. That much is a truism.
Ben clearly agrees that the above criteria have been met,
yet feels that professor Sipser was tricked into agreeing
that this means that:
H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations.
I spent two years deriving those words that Professor Sipser
agreed with. It seems to me that every software engineer would
agree that the second part is logically entailed by the first part. >>>>>>
You mean you WASTED two years and set a trap for your self that
you fell into.
The problem is that Ben is adopting your definitions that
professor Sipser is not using.
Ben agrees that my criteria have been met according to their
exact words. If you want to lie about that I won't talk to
you again.
Which meant different things, so not the same.
The biggest problem is your H/P interlocking program pair is
something outside the normal scope of Computation theory.
The way you have built your Deicder/Decider combination isn't
actualy within the definition of normal Computaiton Theory, as that
would have Decider as a totally independent program from the program
it is deciding on.
Your H and D aren't that sort of thing because they are interwined
into a single memory space, and even share code.
This makes some things possible to do about the pair that can not be
done if they were independent programs, like H being able to detect
that D calls itself (but not copies of itself, which is why you
don't allow those copies, as that breasks your lie).
Ever heard of string comparison?
H can detect that D calls copies of itself.
That merely makes the details more complex.
Nope, doesn't work. Particularly for Turing Machines.
The problem is that the seperate compliation and linking with the
resultant different address makes the byte pattern for the code not
necessarily a duplicate.
When you consider that the input is antagonistic, it can also
intentionally make alterations that do not change the outward
behavior, but do change the byte code.
I seem to remember that it has been proven that, in general, the
identification of an equivalent copy of yourself is uncomputable.
We went over this before, and you could never understand it.
Another of the big effect of thins, is that the way you defined it,
D actually does have access to the decider that is going to decide
it (if we follow your rule and name the decider H). This can turn
what used to be an independent fully defined program P into a
dependent program template.
The key issue is that by my basis structure that applies equally
to DD correctly simulated by HH as it applies to ⟨Ĥ⟩ correctly
simulated by embedded_H is that the paradoxical decision point
cannot be reached. This converts the "impossible" problem into a
difficult one.
Nope. Your basic structure can not be converted back into a pair of
Turing Machihes, showing it isn't based on actual Computations.
Undet THAT condition, Ben agreed that yoUr H could conclude that no
version of H could simulate the version of D that uses it, to its
final state. Since P is a template, and not a program, it doesn't
have the normal Objective definition of behavior, and thus your
subjective one might need to be used, even with its problems.
The key point that you must acknowledge before continuing is
that the criteria is met for H/D. I can't tolerate one more
reply where you deny this.
But your criteria isn't a legal critieria. The "Behavior" of the input
must be an objective property of just that input, and thus can not be
something that depends on the decider looking at it.
It must depend on the decider looking at it or we are required
to ignore the actual fact that DDD does call HHH in recursive
simulation. We are certainly not allowed to ignore any actual
facts. If you can't get that then it seems we may be done talking.
Thus, the direct execution of the program the input repreesents is
what is consider the "behavior of an input" that represents a program.
And thus, since DDD() Halts, HHH(DDD) saying "non-halting" can not be
correct.
The question of can HHH simulate its input to a final state is just an
incorrect question, and your logic that looks at different inputs to
try to make you claim is just invalid.
When you asked Professor Sipser, The H will be a SPECIFIC decider,
and the D will be a specific input that doesn't change, and thus
DOES have an objective behavior (that of directly running it, or
completely simulating it) and only if H can determine that this
OBJECTIVE definition is met, can it abort. Of course, due the
relationship in the construction of D, the H that it was built from
can NEVER make that correct determination, as if it does, then D
will halt and thus H could not have made the determination.
The fact that you don't understand this just shows how little you
understand the theory, or it seems, programming in general.
On 7/4/2024 7:33 PM, Richard Damon wrote:
On 7/4/24 8:00 PM, olcott wrote:
On 7/4/2024 6:18 PM, Richard Damon wrote:
On 7/4/24 6:33 PM, olcott wrote:
On 7/4/2024 5:21 PM, Richard Damon wrote:
On 7/4/24 2:32 PM, olcott wrote:
On 7/4/2024 1:17 PM, Richard Damon wrote:
On 7/4/24 2:04 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>> until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D >>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H >>>>>>>>> (it's...
trivial to do for this one case) that correctly determines >>>>>>>>> that P(P)
*would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it >>>>>>>>> were not
halted. That much is a truism.
Ben clearly agrees that the above criteria have been met,
yet feels that professor Sipser was tricked into agreeing
that this means that:
H can abort its simulation of D and correctly report that D >>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>
I spent two years deriving those words that Professor Sipser >>>>>>>>> agreed with. It seems to me that every software engineer would >>>>>>>>> agree that the second part is logically entailed by the first >>>>>>>>> part.
You mean you WASTED two years and set a trap for your self that >>>>>>>> you fell into.
The problem is that Ben is adopting your definitions that
professor Sipser is not using.
Ben agrees that my criteria have been met according to their
exact words. If you want to lie about that I won't talk to
you again.
Which meant different things, so not the same.
The biggest problem is your H/P interlocking program pair is
something outside the normal scope of Computation theory.
The way you have built your Deicder/Decider combination isn't
actualy within the definition of normal Computaiton Theory, as
that would have Decider as a totally independent program from the
program it is deciding on.
Your H and D aren't that sort of thing because they are interwined >>>>>> into a single memory space, and even share code.
This makes some things possible to do about the pair that can not
be done if they were independent programs, like H being able to
detect that D calls itself (but not copies of itself, which is why >>>>>> you don't allow those copies, as that breasks your lie).
Ever heard of string comparison?
H can detect that D calls copies of itself.
That merely makes the details more complex.
Nope, doesn't work. Particularly for Turing Machines.
The problem is that the seperate compliation and linking with the
resultant different address makes the byte pattern for the code not
necessarily a duplicate.
When you consider that the input is antagonistic, it can also
intentionally make alterations that do not change the outward
behavior, but do change the byte code.
I seem to remember that it has been proven that, in general, the
identification of an equivalent copy of yourself is uncomputable.
We went over this before, and you could never understand it.
Another of the big effect of thins, is that the way you defined
it, D actually does have access to the decider that is going to
decide it (if we follow your rule and name the decider H). This
can turn what used to be an independent fully defined program P
into a dependent program template.
The key issue is that by my basis structure that applies equally
to DD correctly simulated by HH as it applies to ⟨Ĥ⟩ correctly
simulated by embedded_H is that the paradoxical decision point
cannot be reached. This converts the "impossible" problem into a
difficult one.
Nope. Your basic structure can not be converted back into a pair of
Turing Machihes, showing it isn't based on actual Computations.
Undet THAT condition, Ben agreed that yoUr H could conclude that
no version of H could simulate the version of D that uses it, to
its final state. Since P is a template, and not a program, it
doesn't have the normal Objective definition of behavior, and thus >>>>>> your subjective one might need to be used, even with its problems. >>>>>>
The key point that you must acknowledge before continuing is
that the criteria is met for H/D. I can't tolerate one more
reply where you deny this.
But your criteria isn't a legal critieria. The "Behavior" of the
input must be an objective property of just that input, and thus can
not be something that depends on the decider looking at it.
It must depend on the decider looking at it or we are required
to ignore the actual fact that DDD does call HHH in recursive
simulation. We are certainly not allowed to ignore any actual
facts. If you can't get that then it seems we may be done talking.
Why do you say that? Yes, it males the problem harder (in fact in some
cases impossible) but that is the rule.
You seem to have a problem with the simple fact that some maps are
just imposisble to compute.
But that MUST be true as there is an order of infinity more maps than
possible deciders, so most maps must not be computable.
It CAN'T depend on the decider, because the maping it is computing is
only based on the input, and that doesn't include the decider.
OK so I quit. You insist that H must ignore the facts and that is
necessarily incorrect. Good bye.
So, it seem you are just ignorant about what deciders are actually
trying to do (not surprising since you have admitted your ignorance of
the basics).
Thus, the direct execution of the program the input repreesents is
what is consider the "behavior of an input" that represents a program. >>>>
And thus, since DDD() Halts, HHH(DDD) saying "non-halting" can not
be correct.
The question of can HHH simulate its input to a final state is just
an incorrect question, and your logic that looks at different inputs
to try to make you claim is just invalid.
When you asked Professor Sipser, The H will be a SPECIFIC decider, >>>>>> and the D will be a specific input that doesn't change, and thus
DOES have an objective behavior (that of directly running it, or
completely simulating it) and only if H can determine that this
OBJECTIVE definition is met, can it abort. Of course, due the
relationship in the construction of D, the H that it was built
from can NEVER make that correct determination, as if it does,
then D will halt and thus H could not have made the determination. >>>>>>
The fact that you don't understand this just shows how little you
understand the theory, or it seems, programming in general.
On 7/4/2024 7:33 PM, Richard Damon wrote:
On 7/4/24 8:00 PM, olcott wrote:
On 7/4/2024 6:18 PM, Richard Damon wrote:
On 7/4/24 6:33 PM, olcott wrote:
On 7/4/2024 5:21 PM, Richard Damon wrote:
On 7/4/24 2:32 PM, olcott wrote:
On 7/4/2024 1:17 PM, Richard Damon wrote:
On 7/4/24 2:04 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>> until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D >>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H >>>>>>>>> (it's...
trivial to do for this one case) that correctly determines >>>>>>>>> that P(P)
*would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it >>>>>>>>> were not
halted. That much is a truism.
Ben clearly agrees that the above criteria have been met,
yet feels that professor Sipser was tricked into agreeing
that this means that:
H can abort its simulation of D and correctly report that D >>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>
I spent two years deriving those words that Professor Sipser >>>>>>>>> agreed with. It seems to me that every software engineer would >>>>>>>>> agree that the second part is logically entailed by the first >>>>>>>>> part.
You mean you WASTED two years and set a trap for your self that >>>>>>>> you fell into.
The problem is that Ben is adopting your definitions that
professor Sipser is not using.
Ben agrees that my criteria have been met according to their
exact words. If you want to lie about that I won't talk to
you again.
Which meant different things, so not the same.
The biggest problem is your H/P interlocking program pair is
something outside the normal scope of Computation theory.
The way you have built your Deicder/Decider combination isn't
actualy within the definition of normal Computaiton Theory, as
that would have Decider as a totally independent program from the
program it is deciding on.
Your H and D aren't that sort of thing because they are interwined >>>>>> into a single memory space, and even share code.
This makes some things possible to do about the pair that can not
be done if they were independent programs, like H being able to
detect that D calls itself (but not copies of itself, which is why >>>>>> you don't allow those copies, as that breasks your lie).
Ever heard of string comparison?
H can detect that D calls copies of itself.
That merely makes the details more complex.
Nope, doesn't work. Particularly for Turing Machines.
The problem is that the seperate compliation and linking with the
resultant different address makes the byte pattern for the code not
necessarily a duplicate.
When you consider that the input is antagonistic, it can also
intentionally make alterations that do not change the outward
behavior, but do change the byte code.
I seem to remember that it has been proven that, in general, the
identification of an equivalent copy of yourself is uncomputable.
We went over this before, and you could never understand it.
Another of the big effect of thins, is that the way you defined
it, D actually does have access to the decider that is going to
decide it (if we follow your rule and name the decider H). This
can turn what used to be an independent fully defined program P
into a dependent program template.
The key issue is that by my basis structure that applies equally
to DD correctly simulated by HH as it applies to ⟨Ĥ⟩ correctly
simulated by embedded_H is that the paradoxical decision point
cannot be reached. This converts the "impossible" problem into a
difficult one.
Nope. Your basic structure can not be converted back into a pair of
Turing Machihes, showing it isn't based on actual Computations.
Undet THAT condition, Ben agreed that yoUr H could conclude that
no version of H could simulate the version of D that uses it, to
its final state. Since P is a template, and not a program, it
doesn't have the normal Objective definition of behavior, and thus >>>>>> your subjective one might need to be used, even with its problems. >>>>>>
The key point that you must acknowledge before continuing is
that the criteria is met for H/D. I can't tolerate one more
reply where you deny this.
But your criteria isn't a legal critieria. The "Behavior" of the
input must be an objective property of just that input, and thus can
not be something that depends on the decider looking at it.
It must depend on the decider looking at it or we are required
to ignore the actual fact that DDD does call HHH in recursive
simulation. We are certainly not allowed to ignore any actual
facts. If you can't get that then it seems we may be done talking.
Why do you say that? Yes, it males the problem harder (in fact in some
cases impossible) but that is the rule.
You seem to have a problem with the simple fact that some maps are
just imposisble to compute.
But that MUST be true as there is an order of infinity more maps than
possible deciders, so most maps must not be computable.
It CAN'T depend on the decider,
It must depend on the decider because that is an aspect
that the execution trace of DDD correctly emulated by
HHH specifies at machine address 0000217a.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
On 7/4/2024 8:56 PM, Richard Damon wrote:
On 7/4/24 9:35 PM, olcott wrote:
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
*In other words you are denying the verified fact*
That when DDD emulated by HHH according to the
semantics of the x86 language calls HHH(DDD) that
this call cannot possibly return.
No, if HHH(DDD) returns, then by the semantics of the x86 language,
and the fact that DDD calls the exact same code sequence as the call
from main calls, the call to HHH will return, just after HHH stops its
emulation.
And by the x86 language, the "behavior" doesn't stop just because the
HHH stopped emulating the bytes, because the x86 langugage the byte
specify doesn't know that will happen.
*By denying this verified fact you are affirming*
That when DDD emulated by HHH according to the
semantics of the x86 language calls HHH(DDD) that
*THIS CALL CAN RETURN*
Yes, just not in the emulation that HHH does.
OK liar I give up.
On 7/4/2024 8:21 PM, Richard Damon wrote:
On 7/4/24 9:12 PM, olcott wrote:
On 7/4/2024 7:33 PM, Richard Damon wrote:
On 7/4/24 8:00 PM, olcott wrote:
On 7/4/2024 6:18 PM, Richard Damon wrote:
On 7/4/24 6:33 PM, olcott wrote:
On 7/4/2024 5:21 PM, Richard Damon wrote:
On 7/4/24 2:32 PM, olcott wrote:
On 7/4/2024 1:17 PM, Richard Damon wrote:
On 7/4/24 2:04 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
If simulating halt decider H correctly simulates its >>>>>>>>>>> input D
until H correctly determines that its simulated D would >>>>>>>>>>> never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations. >>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an >>>>>>>>>>> H (it's...
trivial to do for this one case) that correctly determines >>>>>>>>>>> that P(P)
*would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it >>>>>>>>>>> were not
halted. That much is a truism.
Ben clearly agrees that the above criteria have been met, >>>>>>>>>>> yet feels that professor Sipser was tricked into agreeing >>>>>>>>>>> that this means that:
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations. >>>>>>>>>>>
I spent two years deriving those words that Professor Sipser >>>>>>>>>>> agreed with. It seems to me that every software engineer would >>>>>>>>>>> agree that the second part is logically entailed by the first >>>>>>>>>>> part.
You mean you WASTED two years and set a trap for your self >>>>>>>>>> that you fell into.
The problem is that Ben is adopting your definitions that
professor Sipser is not using.
Ben agrees that my criteria have been met according to their >>>>>>>>> exact words. If you want to lie about that I won't talk to
you again.
Which meant different things, so not the same.
The biggest problem is your H/P interlocking program pair is
something outside the normal scope of Computation theory.
The way you have built your Deicder/Decider combination isn't
actualy within the definition of normal Computaiton Theory, as >>>>>>>> that would have Decider as a totally independent program from
the program it is deciding on.
Your H and D aren't that sort of thing because they are
interwined into a single memory space, and even share code.
This makes some things possible to do about the pair that can
not be done if they were independent programs, like H being able >>>>>>>> to detect that D calls itself (but not copies of itself, which >>>>>>>> is why you don't allow those copies, as that breasks your lie). >>>>>>>>
Ever heard of string comparison?
H can detect that D calls copies of itself.
That merely makes the details more complex.
Nope, doesn't work. Particularly for Turing Machines.
The problem is that the seperate compliation and linking with the
resultant different address makes the byte pattern for the code
not necessarily a duplicate.
When you consider that the input is antagonistic, it can also
intentionally make alterations that do not change the outward
behavior, but do change the byte code.
I seem to remember that it has been proven that, in general, the
identification of an equivalent copy of yourself is uncomputable.
We went over this before, and you could never understand it.
Another of the big effect of thins, is that the way you defined >>>>>>>> it, D actually does have access to the decider that is going to >>>>>>>> decide it (if we follow your rule and name the decider H). This >>>>>>>> can turn what used to be an independent fully defined program P >>>>>>>> into a dependent program template.
The key issue is that by my basis structure that applies equally >>>>>>> to DD correctly simulated by HH as it applies to ⟨Ĥ⟩ correctly >>>>>>> simulated by embedded_H is that the paradoxical decision point
cannot be reached. This converts the "impossible" problem into a >>>>>>> difficult one.
Nope. Your basic structure can not be converted back into a pair
of Turing Machihes, showing it isn't based on actual Computations. >>>>>>
Undet THAT condition, Ben agreed that yoUr H could conclude that >>>>>>>> no version of H could simulate the version of D that uses it, to >>>>>>>> its final state. Since P is a template, and not a program, it
doesn't have the normal Objective definition of behavior, and
thus your subjective one might need to be used, even with its
problems.
The key point that you must acknowledge before continuing is
that the criteria is met for H/D. I can't tolerate one more
reply where you deny this.
But your criteria isn't a legal critieria. The "Behavior" of the
input must be an objective property of just that input, and thus
can not be something that depends on the decider looking at it.
It must depend on the decider looking at it or we are required
to ignore the actual fact that DDD does call HHH in recursive
simulation. We are certainly not allowed to ignore any actual
facts. If you can't get that then it seems we may be done talking.
Why do you say that? Yes, it males the problem harder (in fact in
some cases impossible) but that is the rule.
You seem to have a problem with the simple fact that some maps are
just imposisble to compute.
But that MUST be true as there is an order of infinity more maps
than possible deciders, so most maps must not be computable.
It CAN'T depend on the decider,
It must depend on the decider because that is an aspect
that the execution trace of DDD correctly emulated by
HHH specifies at machine address 0000217a.
Nope, the correct answer depend on if DDD Halts or not, as determined
by the direct execution of DDD, since that IS the behavior defined for
DDD.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
*In other words you are denying the verified fact*
That when DDD emulated by HHH according to the
semantics of the x86 language calls HHH(DDD) that
this call cannot possibly return.
*By denying this verified fact you are affirming*
That when DDD emulated by HHH according to the
semantics of the x86 language calls HHH(DDD) that
*THIS CALL CAN RETURN*
*THUS PROVING THAT YOU ARE DENYING VERIFIED FACTS*
*THUS PROVING THAT YOU ARE DENYING VERIFIED FACTS*
*THUS PROVING THAT YOU ARE DENYING VERIFIED FACTS*
If DDD Halts, then HHH(DDD) needs to say YES, even though it can't
prove it.
If DDD doens't Halt, then HHH(DDD) Needs to say No, but if it returns
No, them DDD doesn't halt, so HHH can not correctly do that.
So, for THIS DDD, HHH needs to answer True, but it can't tell the
difference between THIS DDD, and a modified version of DDD that has an
infinte loop after the call to HHH, so HHH is stuck not being able to
know what to do.
This shows the inherent weakness of trying to do just simple emulation
as your method for deciding. You fall prey to any machine that has in
it an asking of your decider about themselves, even if you don't do
anything contraryi with the answer.
And such behavior is definitely allowed in the input under the "for
any machine" part of the problem.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
On 7/4/2024 6:18 PM, Richard Damon wrote:It is an accident that we try to decide DDD with the same program it is
On 7/4/24 6:33 PM, olcott wrote:
On 7/4/2024 5:21 PM, Richard Damon wrote:
On 7/4/24 2:32 PM, olcott wrote:
On 7/4/2024 1:17 PM, Richard Damon wrote:
On 7/4/24 2:04 PM, olcott wrote:
It must depend on the decider looking at it or we are required to ignoreEver heard of string comparison?Which meant different things, so not the same.Ben agrees that my criteria have been met according to their exactBen clearly agrees that the above criteria have been met,
yet feels that professor Sipser was tricked into agreeing that
this means that:
H can abort its simulation of D and correctly report that >>>>>>> D specifies a non-halting sequence of configurations.
I spent two years deriving those words that Professor Sipser
agreed with. It seems to me that every software engineer would
agree that the second part is logically entailed by the first
part.
You mean you WASTED two years and set a trap for your self that you >>>>>> fell into.
The problem is that Ben is adopting your definitions that professor >>>>>> Sipser is not using.
words. If you want to lie about that I won't talk to you again.
The biggest problem is your H/P interlocking program pair is
something outside the normal scope of Computation theory.
The way you have built your Deicder/Decider combination isn't actualy
within the definition of normal Computaiton Theory, as that would
have Decider as a totally independent program from the program it is
deciding on.
Your H and D aren't that sort of thing because they are interwined
into a single memory space, and even share code.
This makes some things possible to do about the pair that can not be
done if they were independent programs, like H being able to detect
that D calls itself (but not copies of itself, which is why you don't
allow those copies, as that breasks your lie).
H can detect that D calls copies of itself.
That merely makes the details more complex.
Nope, doesn't work. Particularly for Turing Machines.
The problem is that the seperate compliation and linking with the
resultant different address makes the byte pattern for the code not
necessarily a duplicate.
When you consider that the input is antagonistic, it can also
intentionally make alterations that do not change the outward behavior,
but do change the byte code.
I seem to remember that it has been proven that, in general, the
identification of an equivalent copy of yourself is uncomputable.
We went over this before, and you could never understand it.
Another of the big effect of thins, is that the way you defined it, DThe key issue is that by my basis structure that applies equally to DD
actually does have access to the decider that is going to decide it
(if we follow your rule and name the decider H). This can turn what
used to be an independent fully defined program P into a dependent
program template.
correctly simulated by HH as it applies to ⟨Ĥ⟩ correctly simulated by >>> embedded_H is that the paradoxical decision point cannot be reached.
This converts the "impossible" problem into a difficult one.
Nope. Your basic structure can not be converted back into a pair of
Turing Machihes, showing it isn't based on actual Computations.
Undet THAT condition, Ben agreed that yoUr H could conclude that noThe key point that you must acknowledge before continuing is that the
version of H could simulate the version of D that uses it, to its
final state. Since P is a template, and not a program, it doesn't
have the normal Objective definition of behavior, and thus your
subjective one might need to be used, even with its problems.
criteria is met for H/D. I can't tolerate one more reply where you
deny this.
But your criteria isn't a legal critieria. The "Behavior" of the input
must be an objective property of just that input, and thus can not be
something that depends on the decider looking at it.
the actual fact that DDD does call HHH in recursive simulation.
Thus, the direct execution of the program the input repreesents is what
is consider the "behavior of an input" that represents a program.
And thus, since DDD() Halts, HHH(DDD) saying "non-halting" can not be
correct.
The question of can HHH simulate its input to a final state is just an
incorrect question, and your logic that looks at different inputs to
try to make you claim is just invalid.
On 7/5/2024 5:11 AM, joes wrote:
Am Thu, 04 Jul 2024 19:00:28 -0500 schrieb olcott:
On 7/4/2024 6:18 PM, Richard Damon wrote:
On 7/4/24 6:33 PM, olcott wrote:
On 7/4/2024 5:21 PM, Richard Damon wrote:
On 7/4/24 2:32 PM, olcott wrote:
On 7/4/2024 1:17 PM, Richard Damon wrote:
On 7/4/24 2:04 PM, olcott wrote:
It must depend on the decider looking at it or we are required to ignore >>> the actual fact that DDD does call HHH in recursive simulation.Ever heard of string comparison?Which meant different things, so not the same.Ben agrees that my criteria have been met according to their exact >>>>>>> words. If you want to lie about that I won't talk to you again.Ben clearly agrees that the above criteria have been met,
yet feels that professor Sipser was tricked into agreeing that >>>>>>>>> this means that:
H can abort its simulation of D and correctly report that >>>>>>>>> D specifies a non-halting sequence of configurations. >>>>>>>>> I spent two years deriving those words that Professor Sipser >>>>>>>>> agreed with. It seems to me that every software engineer would >>>>>>>>> agree that the second part is logically entailed by the first >>>>>>>>> part.
You mean you WASTED two years and set a trap for your self that you >>>>>>>> fell into.
The problem is that Ben is adopting your definitions that professor >>>>>>>> Sipser is not using.
The biggest problem is your H/P interlocking program pair is
something outside the normal scope of Computation theory.
The way you have built your Deicder/Decider combination isn't actualy >>>>>> within the definition of normal Computaiton Theory, as that would
have Decider as a totally independent program from the program it is >>>>>> deciding on.
Your H and D aren't that sort of thing because they are interwined >>>>>> into a single memory space, and even share code.
This makes some things possible to do about the pair that can not be >>>>>> done if they were independent programs, like H being able to detect >>>>>> that D calls itself (but not copies of itself, which is why you don't >>>>>> allow those copies, as that breasks your lie).
H can detect that D calls copies of itself.
That merely makes the details more complex.
Nope, doesn't work. Particularly for Turing Machines.
The problem is that the seperate compliation and linking with the
resultant different address makes the byte pattern for the code not
necessarily a duplicate.
When you consider that the input is antagonistic, it can also
intentionally make alterations that do not change the outward behavior, >>>> but do change the byte code.
I seem to remember that it has been proven that, in general, the
identification of an equivalent copy of yourself is uncomputable.
We went over this before, and you could never understand it.
Another of the big effect of thins, is that the way you defined it, D >>>>>> actually does have access to the decider that is going to decide it >>>>>> (if we follow your rule and name the decider H). This can turn what >>>>>> used to be an independent fully defined program P into a dependent >>>>>> program template.The key issue is that by my basis structure that applies equally to DD >>>>> correctly simulated by HH as it applies to ⟨Ĥ⟩ correctly simulated by
embedded_H is that the paradoxical decision point cannot be reached. >>>>> This converts the "impossible" problem into a difficult one.
Nope. Your basic structure can not be converted back into a pair of
Turing Machihes, showing it isn't based on actual Computations.
Undet THAT condition, Ben agreed that yoUr H could conclude that no >>>>>> version of H could simulate the version of D that uses it, to itsThe key point that you must acknowledge before continuing is that the >>>>> criteria is met for H/D. I can't tolerate one more reply where you
final state. Since P is a template, and not a program, it doesn't
have the normal Objective definition of behavior, and thus your
subjective one might need to be used, even with its problems.
deny this.
But your criteria isn't a legal critieria. The "Behavior" of the input >>>> must be an objective property of just that input, and thus can not be
something that depends on the decider looking at it.
It is an accident that we try to decide DDD with the same program it is
calling (well, it was engineered, but there is nothing special about it).
HHH came first, and DDD is constructed on it.
DDD has an independent behaviour when run directly/simulated correctly.
Of course it calls HHH, but HHH has no power over it; it is bound to
the behaviour of DDD.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Thus, the direct execution of the program the input repreesents is what >>>> is consider the "behavior of an input" that represents a program.
And thus, since DDD() Halts, HHH(DDD) saying "non-halting" can not be
correct.
The question of can HHH simulate its input to a final state is just an >>>> incorrect question, and your logic that looks at different inputs to
try to make you claim is just invalid.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 170:32:21 |
| Calls: | 9,704 |
| Calls today: | 4 |
| Files: | 13,736 |
| Messages: | 6,178,354 |