Re: Ben thinks the professor Sipser is wrong

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:

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.

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.

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.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.