[continued from previous message]

but that requires the simulation to follow the rules of a UTM, one of
which REQUIRES that it fully repoduce the behavior of the machine
described to it, and thus it CAN NOT STOP until it reaches a final
state. Since H does stop (or doesn't answer), it isn't doing a
simulation per the definition of a UTM, so its simulation isn't
"Correct" enough to be used.

You like to point out that a deccider must compute its mapping based on
the behavior of its input, which is corrrect, but since this applies to
ALL deciders, not just Halt Decider, this doesn't answer the question,
"What is the behavior of the input?", Since we are talking Hat Deciders,
that obvious means the behavior we are talking about is Halting, which
as you like to quote is a behavior of a MACHINE (not an "input") and is
that the MACHINE reaches a final state. What machine? well the machine described by the input, so H(D,D) is asking about the machine D(D) (not
H's simulation of that input, that has NO correct reasoning connection
to Halting).

Yes, again, we can replace the machine with a UTM simulation of that
machine, but again, by the definition of a UTM, that is a simulation
that NEVER stops until it reaches the final state, so H's simulation
isn't that of a UTM.

It doesn't matter that you might have started with an algorithm for a
UTM, your "modification" have broken its ability to still be a UTM, just
like a hot rod shop might start with a street legal car, but the final
vehicle might well not be street legal (but better suited for its new
purpose).

Again, since we know that D(D) will halt because you have declaired that
H(D,D) will "correctly" return 0, so, we can prove that you don't
understand what the word "Correctly" means, since to be correct it needs
to match the actual answer for the problem.

If the math exam ask you what 1 + 2 is equal, you can't say "12" because
that is what "1" + "2" means in some computer language, that is just the
WRONG answer, because it is to the WRONG question.

You may be able to correctly say that D(D) doesn't POOP, so H(D,D)
returning 0 is a correct answer for a POOP detector, but since you can't
detect that you logic is just shit, we can't really even count on you to
know what POOP is really about.

You are just proving that you are totally incompetent at all the things
you have been talking about, and that you are just a ignorant
pathological lying idiot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[continued from previous message]

simulated by H cannot possibly terminate normally thus conclusively
proving your total lack of any interest in an honest dialogue.

Which is an irrelevent fact, since we aren't asking H about its own
PARTIAL simulation of its input,

You keep disagreeing with the easily verified fact that D correctly
simulated by H cannot possibly EVER terminate normally even if the
simulation could be infinite.

This seems to conclusively prove that your software engineering skills
are not very good or you have no intention on participating in any
honest dialogue.

I don't like to get into a battle of wits with an unarmed opponent, but
it seems you insist.

Please show where you claim has ANY actual significant, and isn't just
the strawman that describes your brains.

A Halt Decider is DEFINED to return an answer based on the behavior of
the machine DESCRIBED by its input, not a PARTIAL simulation done by the decider.

In other words you simply {don't believe in} mathematical induction that correctly infers an infinite sequence from a finite sequence. https://en.wikipedia.org/wiki/Mathematical_induction

Anyone with sufficient software engineering skill can easily determine
that D correctly simulated by H will never terminate normally after N
simulated steps for any value of N.



--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[continued from previous message]

Thus, H(P,d) needs to decide what UTM(P,d) would do with the
exact same input. Note, D calls H, not the machine simulating it, >>>>>>> so UTM(D,D) would see D(D) calling H(D.D) and what H(D,D) does
with that input.

The behavior of the non-input is the behavior that is one
recursive invocation removed from the behavior of its input.

Nope, You are just proving you don't understand a THING about the >>>>>>> problem

I guess this is why you can't understand how Turing Machine
works. They are defined simply enough you can't twist them.

H uses an x86 emulator to correctly simulate D.

No, it partially simulates the execution path o D.

Since you ar equating simulation to direct execution, the only >>>>>>>>> meaning of correct includes being COMPLETE.

01 int D(int (*x)())
02 {
03  int Halt_Status = H(x, x);
04  if (Halt_Status)
05    HERE: goto HERE;
06  return Halt_Status;
07 }
08
09 void main()
10 {
11  H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at >>>>>>>>>> line 03 ...

You keep disagreeing with the easily verified fact that D correctly >>>>>> simulated by H cannot possibly terminate normally thus conclusively >>>>>> proving your total lack of any interest in an honest dialogue.

Which is an irrelevent fact, since we aren't asking H about its own
PARTIAL simulation of its input,

You keep disagreeing with the easily verified fact that D correctly
simulated by H cannot possibly EVER terminate normally even if the
simulation could be infinite.

This seems to conclusively prove that your software engineering skills >>>> are not very good or you have no intention on participating in any
honest dialogue.

I don't like to get into a battle of wits with an unarmed opponent,
but it seems you insist.

Please show where you claim has ANY actual significant, and isn't
just the strawman that describes your brains.

A Halt Decider is DEFINED to return an answer based on the behavior
of the machine DESCRIBED by its input, not a PARTIAL simulation done
by the decider.

So, no answer to any of the questions, I guess you are ADMITTING that
you have no answers.

In other words you simply {don't believe in} mathematical induction that
correctly infers an infinite sequence from a finite sequence.
https://en.wikipedia.org/wiki/Mathematical_induction

SO, provide the VALID induction proof for you assertion.

Remember to include the fact that EVERY H might abort its simulation.

I don't think you know how to do an actual proof by induction.

You are just showing that you are using word salid.

Yes, if you can actualy make a SOUND and VALID proof, from the partial simulation, you can do so.

H doesn't have enough information to make that decision,

You must not have any software engineering skill.

It is probably a good idea that I create an actual inductive proof.
Partial proof of program correctness has always relied on an adaptation
of mathematical induction, thus I can cite sources that this adaptation
is known to be legitimate.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[continued from previous message]

No, it partially simulates the execution path o D.

Since you ar equating simulation to direct execution, the only >>>>>>>> meaning of correct includes being COMPLETE.

01 int D(int (*x)())
02 {
03  int Halt_Status = H(x, x);
04  if (Halt_Status)
05    HERE: goto HERE;
06  return Halt_Status;
07 }
08
09 void main()
10 {
11  H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at >>>>>>>>> line 03 ...

You keep disagreeing with the easily verified fact that D correctly
simulated by H cannot possibly terminate normally thus conclusively
proving your total lack of any interest in an honest dialogue.

Which is an irrelevent fact, since we aren't asking H about its own
PARTIAL simulation of its input,

You keep disagreeing with the easily verified fact that D correctly
simulated by H cannot possibly EVER terminate normally even if the
simulation could be infinite.

This seems to conclusively prove that your software engineering skills
are not very good or you have no intention on participating in any
honest dialogue.

I don't like to get into a battle of wits with an unarmed opponent,
but it seems you insist.

Please show where you claim has ANY actual significant, and isn't just
the strawman that describes your brains.

A Halt Decider is DEFINED to return an answer based on the behavior of
the machine DESCRIBED by its input, not a PARTIAL simulation done by
the decider.

So, no answer to any of the questions, I guess you are ADMITTING that
you have no answers.

In other words you simply {don't believe in} mathematical induction that correctly infers an infinite sequence from a finite sequence. https://en.wikipedia.org/wiki/Mathematical_induction

SO, provide the VALID induction proof for you assertion.

Remember to include the fact that EVERY H might abort its simulation.

I don't think you know how to do an actual proof by induction.

You are just showing that you are using word salid.

Yes, if you can actualy make a SOUND and VALID proof, from the partial simulation, you can do so.

H doesn't have enough information to make that decision, it can't even
know that the machine is the pathological one, as it never say what
happens after the answer. As far as it knows, and it can not
distinguish, between a machine that Always Halts, Never Halt, Agrees
with H, or Disagrees with H.

All H has done is say if the H is D is a different program that the H
that it is actually is (the H that gives the anwer), then it will be non-halting, in other words, you have LIED that D was built by the
rules, or that H is actually examining and reasoning about the input
given to it.

YOU FAIL

Anyone with sufficient software engineering skill can easily determine
that D correctly simulated by H will never terminate normally after N simulated steps for any value of N.

Really?

Since that isn't the question, why does it matter?

Why is it a CORRECT simulation when it doesn't match the definition of
correct needed to make the substitution of the behavior of the machine described by the input with a "Correct Simulatioon"

You got nothing.

You just proved you are unarmed in this battle of wits.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[continued from previous message]

You already know that a decider computes the mapping
*from its input* to its own accept or reject state.

Right, and the "Input" is a description of a machine it is to
decide the behavior of.

In fact, you CAN define the behavior basd on simulation, as long >>>>>>>> as the simulation is of the right sort, that of an UNCONDITION >>>>>>>> COMPLETE SIMULATION.

H needs to answer about what your x86 simulator, if put into
pure simulation mode, would do when simulating the input to H. >>>>>>>>
That is its exact input, just not what it itself would do with >>>>>>>> it. That is the difference between accurately simulating an
input and deciding on it. Accurate simulations of a non-halting >>>>>>>> input take forever, deciding on it must take finite time.

Thus, H(P,d) needs to decide what UTM(P,d) would do with the
exact same input. Note, D calls H, not the machine simulating
it, so UTM(D,D) would see D(D) calling H(D.D) and what H(D,D)
does with that input.

The behavior of the non-input is the behavior that is one
recursive invocation removed from the behavior of its input.

Nope, You are just proving you don't understand a THING about
the problem

I guess this is why you can't understand how Turing Machine
works. They are defined simply enough you can't twist them.

H uses an x86 emulator to correctly simulate D.

No, it partially simulates the execution path o D.

Since you ar equating simulation to direct execution, the only >>>>>>>>>> meaning of correct includes being COMPLETE.

01 int D(int (*x)())
02 {
03  int Halt_Status = H(x, x);
04  if (Halt_Status)
05    HERE: goto HERE;
06  return Halt_Status;
07 }
08
09 void main()
10 {
11  H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at >>>>>>>>>>> line 03 ...

You keep disagreeing with the easily verified fact that D correctly >>>>>>> simulated by H cannot possibly terminate normally thus conclusively >>>>>>> proving your total lack of any interest in an honest dialogue.

Which is an irrelevent fact, since we aren't asking H about its
own PARTIAL simulation of its input,

You keep disagreeing with the easily verified fact that D correctly
simulated by H cannot possibly EVER terminate normally even if the
simulation could be infinite.

This seems to conclusively prove that your software engineering skills >>>>> are not very good or you have no intention on participating in any
honest dialogue.

I don't like to get into a battle of wits with an unarmed opponent,
but it seems you insist.

Please show where you claim has ANY actual significant, and isn't
just the strawman that describes your brains.

A Halt Decider is DEFINED to return an answer based on the behavior
of the machine DESCRIBED by its input, not a PARTIAL simulation done
by the decider.

So, no answer to any of the questions, I guess you are ADMITTING that
you have no answers.

In other words you simply {don't believe in} mathematical induction that >>> correctly infers an infinite sequence from a finite sequence.
https://en.wikipedia.org/wiki/Mathematical_induction

SO, provide the VALID induction proof for you assertion.

Remember to include the fact that EVERY H might abort its simulation.

I don't think you know how to do an actual proof by induction.

You are just showing that you are using word salid.

Yes, if you can actualy make a SOUND and VALID proof, from the partial
simulation, you can do so.

H doesn't have enough information to make that decision,

You must not have any software engineering skill.

It is probably a good idea that I create an actual inductive proof.
Partial proof of program correctness has always relied on an adaptation
of mathematical induction, thus I can cite sources that this adaptation
is known to be legitimate.

No, you seem to lack the basic concepts of requirements

Since you have admitted you are wrong, by not providing answers to any
of the questions, I don't need to go any further,

You arguement is refuted, and you are just admitting you are just a
ignorant pathological lying idiot by repeating them.

You seem incapable of actually proving anything, so you are just going
to go to hell for all your lies, and likely sentenced to just working on
your proof, which can never be completed forever.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[continued from previous message]

The reason that I did this concretely in C is the there >>>>>>>>>>>>>>>> is no wiggle
room of ambiguity to deny what is actually occurring. >>>>>>>>>>>>>>

My way results in a halt decider that recognizes the >>>>>>>>>>>>>> actual behavior of
the actual input so that it doesn't get stuck in recursive >>>>>>>>>>>>>> simulation.

No, becase the ACTUAL BEHAVIOR of the machine in question >>>>>>>>>>>>> is what it does when actually run.

You keep insisting on staying out-of-sync by one recursive >>>>>>>>>>>> invocation.

Can D correctly simulated by H terminate normally?

Why does that matter?

Since H is being asked about the actual execution of D(D). >>>>>>>>>>

*This is factually incorrect*
H is only being asked about the behavior of its input.

Which is DEFINED as the Behavior of the Machine it describes. >>>>>>>>>

H is not being asked about the behavior of a non-input.

So, you think the x86 code of a program isn't a suitable
description of an x86 program?

You already know that a decider computes the mapping
*from its input* to its own accept or reject state.

Right, and the "Input" is a description of a machine it is to >>>>>>>>> decide the behavior of.

In fact, you CAN define the behavior basd on simulation, as
long as the simulation is of the right sort, that of an
UNCONDITION COMPLETE SIMULATION.

H needs to answer about what your x86 simulator, if put into >>>>>>>>> pure simulation mode, would do when simulating the input to H. >>>>>>>>>
That is its exact input, just not what it itself would do with >>>>>>>>> it. That is the difference between accurately simulating an
input and deciding on it. Accurate simulations of a non-halting >>>>>>>>> input take forever, deciding on it must take finite time.

Thus, H(P,d) needs to decide what UTM(P,d) would do with the >>>>>>>>> exact same input. Note, D calls H, not the machine simulating >>>>>>>>> it, so UTM(D,D) would see D(D) calling H(D.D) and what H(D,D) >>>>>>>>> does with that input.

The behavior of the non-input is the behavior that is one
recursive invocation removed from the behavior of its input. >>>>>>>>>

Nope, You are just proving you don't understand a THING about >>>>>>>>> the problem

I guess this is why you can't understand how Turing Machine
works. They are defined simply enough you can't twist them.

H uses an x86 emulator to correctly simulate D.

No, it partially simulates the execution path o D.

Since you ar equating simulation to direct execution, the >>>>>>>>>>> only meaning of correct includes being COMPLETE.

01 int D(int (*x)())
02 {
03  int Halt_Status = H(x, x);
04  if (Halt_Status)
05    HERE: goto HERE;
06  return Halt_Status;
07 }
08
09 void main()
10 {
11  H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at >>>>>>>>>>>> line 03 ...

You keep disagreeing with the easily verified fact that D correctly >>>>>>>> simulated by H cannot possibly terminate normally thus conclusively >>>>>>>> proving your total lack of any interest in an honest dialogue. >>>>>>>>

Which is an irrelevent fact, since we aren't asking H about its
own PARTIAL simulation of its input,

You keep disagreeing with the easily verified fact that D correctly >>>>>> simulated by H cannot possibly EVER terminate normally even if the >>>>>> simulation could be infinite.

This seems to conclusively prove that your software engineering
skills
are not very good or you have no intention on participating in any >>>>>> honest dialogue.

I don't like to get into a battle of wits with an unarmed opponent,
but it seems you insist.

Please show where you claim has ANY actual significant, and isn't
just the strawman that describes your brains.

A Halt Decider is DEFINED to return an answer based on the behavior
of the machine DESCRIBED by its input, not a PARTIAL simulation
done by the decider.

So, no answer to any of the questions, I guess you are ADMITTING that
you have no answers.

In other words you simply {don't believe in} mathematical induction
that
correctly infers an infinite sequence from a finite sequence.
https://en.wikipedia.org/wiki/Mathematical_induction

SO, provide the VALID induction proof for you assertion.

Remember to include the fact that EVERY H might abort its simulation.

I don't think you know how to do an actual proof by induction.

You are just showing that you are using word salid.

Yes, if you can actualy make a SOUND and VALID proof, from the
partial simulation, you can do so.

H doesn't have enough information to make that decision,

You must not have any software engineering skill.

It is probably a good idea that I create an actual inductive proof.
Partial proof of program correctness has always relied on an adaptation
of mathematical induction, thus I can cite sources that this adaptation
is known to be legitimate.

No, you seem to lack the basic concepts of requirements

I still remembered the guy's name that essentially invented proof of
program correctness. I took a course on this and got an A. I have two
textbooks on proof of program correctness. It is all anchored in
mathematical induction.


--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[continued from previous message]

Thus you knew that H is correct to abort its simulation >>>>>>>>>>>>>>>>> of D to prevent
its own infinite execution.

H is allowed to abort its simulation for any reason its >>>>>>>>>>>>>>>> programmer wants. It still needs to give the right >>>>>>>>>>>>>>>> answer to be correct, and that answer needs to describe >>>>>>>>>>>>>>>> the behavior of directly running the machine given an >>>>>>>>>>>>>>>> input.

Since H(D,D) has been said to return 0, we can by simple >>>>>>>>>>>>>>>> inspection, and verify by actually running it, see that >>>>>>>>>>>>>>>> D(D) will Halt, which means that H's answer is just wrong. >>>>>>>>>>>>>>>>
It might be a correct POOP decider, but only you seem >>>>>>>>>>>>>>>> interested in your POOP.

The reason that I did this concretely in C is the there >>>>>>>>>>>>>>>>> is no wiggle
room of ambiguity to deny what is actually occurring. >>>>>>>>>>>>>>>

My way results in a halt decider that recognizes the >>>>>>>>>>>>>>> actual behavior of
the actual input so that it doesn't get stuck in >>>>>>>>>>>>>>> recursive simulation.

No, becase the ACTUAL BEHAVIOR of the machine in question >>>>>>>>>>>>>> is what it does when actually run.

You keep insisting on staying out-of-sync by one recursive >>>>>>>>>>>>> invocation.

Can D correctly simulated by H terminate normally?

Why does that matter?

Since H is being asked about the actual execution of D(D). >>>>>>>>>>>

*This is factually incorrect*
H is only being asked about the behavior of its input.

Which is DEFINED as the Behavior of the Machine it describes. >>>>>>>>>>

H is not being asked about the behavior of a non-input.

So, you think the x86 code of a program isn't a suitable
description of an x86 program?

You already know that a decider computes the mapping
*from its input* to its own accept or reject state.

Right, and the "Input" is a description of a machine it is to >>>>>>>>>> decide the behavior of.

In fact, you CAN define the behavior basd on simulation, as >>>>>>>>>> long as the simulation is of the right sort, that of an
UNCONDITION COMPLETE SIMULATION.

H needs to answer about what your x86 simulator, if put into >>>>>>>>>> pure simulation mode, would do when simulating the input to H. >>>>>>>>>>
That is its exact input, just not what it itself would do with >>>>>>>>>> it. That is the difference between accurately simulating an >>>>>>>>>> input and deciding on it. Accurate simulations of a
non-halting input take forever, deciding on it must take
finite time.

Thus, H(P,d) needs to decide what UTM(P,d) would do with the >>>>>>>>>> exact same input. Note, D calls H, not the machine simulating >>>>>>>>>> it, so UTM(D,D) would see D(D) calling H(D.D) and what H(D,D) >>>>>>>>>> does with that input.

The behavior of the non-input is the behavior that is one >>>>>>>>>>> recursive invocation removed from the behavior of its input. >>>>>>>>>>

Nope, You are just proving you don't understand a THING about >>>>>>>>>> the problem

I guess this is why you can't understand how Turing Machine >>>>>>>>>> works. They are defined simply enough you can't twist them. >>>>>>>>>>

H uses an x86 emulator to correctly simulate D.

No, it partially simulates the execution path o D.

Since you ar equating simulation to direct execution, the >>>>>>>>>>>> only meaning of correct includes being COMPLETE.

01 int D(int (*x)())
02 {
03  int Halt_Status = H(x, x);
04  if (Halt_Status)
05    HERE: goto HERE;
06  return Halt_Status;
07 }
08
09 void main()
10 {
11  H(D,D);
12 }

*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11

*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) >>>>>>>>>>>>> at line 03 ...

You keep disagreeing with the easily verified fact that D
correctly
simulated by H cannot possibly terminate normally thus
conclusively
proving your total lack of any interest in an honest dialogue. >>>>>>>>>

Which is an irrelevent fact, since we aren't asking H about its >>>>>>>> own PARTIAL simulation of its input,

You keep disagreeing with the easily verified fact that D correctly >>>>>>> simulated by H cannot possibly EVER terminate normally even if the >>>>>>> simulation could be infinite.

This seems to conclusively prove that your software engineering
skills
are not very good or you have no intention on participating in any >>>>>>> honest dialogue.

I don't like to get into a battle of wits with an unarmed
opponent, but it seems you insist.

Please show where you claim has ANY actual significant, and isn't
just the strawman that describes your brains.

A Halt Decider is DEFINED to return an answer based on the
behavior of the machine DESCRIBED by its input, not a PARTIAL
simulation done by the decider.

So, no answer to any of the questions, I guess you are ADMITTING
that you have no answers.

In other words you simply {don't believe in} mathematical induction
that
correctly infers an infinite sequence from a finite sequence.
https://en.wikipedia.org/wiki/Mathematical_induction

SO, provide the VALID induction proof for you assertion.

Remember to include the fact that EVERY H might abort its simulation.

I don't think you know how to do an actual proof by induction.

You are just showing that you are using word salid.

Yes, if you can actualy make a SOUND and VALID proof, from the
partial simulation, you can do so.

H doesn't have enough information to make that decision,

You must not have any software engineering skill.

It is probably a good idea that I create an actual inductive proof.
Partial proof of program correctness has always relied on an adaptation
of mathematical induction, thus I can cite sources that this adaptation
is known to be legitimate.

No, you seem to lack the basic concepts of requirements

I still remembered the guy's name that essentially invented proof of
program correctness. I took a course on this and got an A. I have two textbooks on proof of program correctness. It is all anchored in
mathematical induction.

Even so, you are just proving you don't remember any of that materieal
because you still can't answer any of the question, but keep resorting
to the fallacies of things like the Strawmn and Red Herrings.

Your H isn't correct, because D(D) WILL Halt since H(D,D) returns 0.

Since you just refuse to answer the refutations, and provide ANY actual
proof of your claims, you are shown to just be an ignorant pathological
lying idiot, and your precisous "Correct reasoning" to be just a pile of
crap.

You claim to have an "Inductive proof" of your claim, if so, SHOW IT,
just making an unsubstantiated claim tha that you know what induction is because you got an A in a course that used it means nothing. If you
actually can prove it, which you can't, since it is demonstratably
false, show the actual proof by proving the two required facts for the inductiv4 proof.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)