On 9/5/22 3:34 AM, Skep Dick wrote:
> On Monday, 5 September 2022 at 04:23:04 UTC+2, richar...@gmail.com wrote:
>> On 9/4/22 9:50 PM, Skep Dick wrote:
>>> On Monday, 5 September 2022 at 02:44:04 UTC+2, richar...@gmail.com wrote:
>>>> On 9/4/22 8:24 PM, Skep Dick wrote:
>>>>> On Monday, 5 September 2022 at 01:45:53 UTC+2, richar...@gmail.com wrote:
>>>>>> On 9/4/22 7:35 PM, Skep Dick wrote:
>>>>>>> On Monday, 5 September 2022 at 00:58:13 UTC+2, richar...@gmail.com wrote:
>>>>>>>> On 9/4/22 6:02 PM, Skep Dick wrote:
>>>>>>>>> On Sunday, 4 September 2022 at 22:46:44 UTC+2, richar...@gmail.com wrote:
>>>>>>>>>> On 9/4/22 4:33 PM, Skep Dick wrote:
>>>>>>>>>>> On Sunday, 4 September 2022 at 22:24:14 UTC+2, richar...@gmail.com wrote:
>>>>>>>>>>>> On 9/4/22 4:01 PM, Skep Dick wrote:
>>>>>>>>>>>>> On Sunday, 4 September 2022 at 21:52:16 UTC+2, richar...@gmail.com wrote:
>>>>>>>>>>>>>> On 9/4/22 3:30 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/4/2022 2:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/4/22 3:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/4/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/4/22 2:35 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/4/2022 1:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/4/22 1:50 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/4/2022 12:14 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 9/4/22 12:33 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 12:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 1:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 12:08 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 12:56 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 11:47 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 12:32 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 11:14 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 12:05 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 11:00 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 11:53 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 10:31 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 11:20 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:33 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 10:28 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:26 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 10:14 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:06 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 2:03:48 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC+1, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 7:50 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 1:43:43 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC+1, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 7:00 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 2:54:54
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AM UTC+1, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you won't go by the oficial
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definitions, your H just isn't a Halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the official definitions are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory then at least one of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> them must be rejected as incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you are wrong here. The official
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of a halt decider is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory, in that it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> impossible to build anything which meets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the definition. This has been proved.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is not the way truth works mate. If
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the official definitions are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory then I have also had new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> insight on that another
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aspect of computer science is incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you are not disputing that official
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of a halt decider is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The correct and complete simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is guaranteed to derive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the actual behavior of this input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> must abort the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of its input to prevent the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution of this input is merely
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> another way of saying the the correct and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> complete simulation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input by this SHD would never stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When computer science textbooks say that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior that a halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider must report on is the behavior of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> direct execution of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine represented by this input and this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior is not the same as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the correct and complete simulation of this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input then the computer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> science textbooks are wrong because they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject the definition of a UTM.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (simulator).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I was hoping for more of a yes-or-no type answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I provide a complete explanation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reasoning behind the answer all those not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understanding these things cannot simply
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baselessly disagree. All disagreement is thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required to have a basis. This way people are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not lead astray by a bunch of baseless
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreement, they see that the disagreement
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has no basis and reject it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So, you need to try to actually provide VALID
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reasoning, starting from ACCEPTED definition.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You just make wild claims based on your own
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understanding of the words.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since you don't even attempt to actually DEFINE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the words, no one can help you with your logic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, Most of the things you are talking about
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HAVE well defined meanings, so you either need
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to use that meaning, or you really need to give
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your idea a new name (maybe basd on the common
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name with a modifier).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thus, if you definition of "Halting" isn't the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same as the accepted definition, you can call it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PO-Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Of course the problem with this is it makes it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clear that you are talking about the PO-Halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Problem, with a PO-Halting Decider, so you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> counter example doesn't affect the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting Problem, so it is clear you haven't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proven what you claim to have proven.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It's not immediately obvious, but it can be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proved that the definition is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory. You're not disputing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that proof?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You haven't actually given a proof, since you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are clearly using altered definition that you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aren't providing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You reject the notion of a UTM so you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> starting with an incorrect basis.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have done no such thing. UTM's exist, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTM(P,d) by DEFINITION gives the exact same result
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as P(d).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When you get a glass of water and dump it on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> floor you cannot truthfully deny that the floor is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wet.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And I haven't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When the correct and complete simulation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input by H(P,P) would have different behavior than
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the direct execution of P(P) this cannot simply be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ignored.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And the correct and complete simulation of the input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H(P,P) Halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fact that the simulation by H(P,P) of its input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never stops running unless H aborts the simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this input is merely another way of saying that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct and complete simulation of this input by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have bad logic there.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is a tautology:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H0((u32)Infinite_Loop));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001102](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001103](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001105](02) ebfe jmp 00001105
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001107](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001108](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00001108]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fact that the simulation by H0(Infinite_Loop) of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its input would never stop running unless H0 aborts the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of this input is merely another way of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> saying that the correct and complete simulation of this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input by H0 never halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Strawman.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fallacy of Proof by Example.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is only a fallacy by proof of example when a single
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> example is not representative of the entire class of all
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such examples.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which it isn't, so FAIL.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You are confusing existential quantification with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universal quantification.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> No you are, since you are claiming the rule works for ALL
>>>>>>>>>>>>>>>>>>>>>>>>>>>> inputs (or at least P, which isn't the input you showed it
>>>>>>>>>>>>>>>>>>>>>>>>>>>> worked for).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ∀ simulating halt decider H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ∀ machine description P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Right. ∀, so UNIVERSAL, not EXISTENTIAL, so FAIL.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't seem to know what those words mean.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fact that the correct simulation of any input P to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any simulating halt decider (SHD) H would never stop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running unless this simulation was aborted by this SHD is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely another way of saying that the correct and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> complete simulation of this input by this SHD would never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, not when the input depends on the behavior of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider in the way you are doing it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> P was intentionally defined to depend on the behavior of
>>>>>>>>>>>>>>>>>>>>>>>>>>> its decider *NITWIT*
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Right, but your "example" didn't, and this dependency is the
>>>>>>>>>>>>>>>>>>>>>>>>>> case that breaks your "proof" and definitions.
>>>>>>>>>>>>>>>>>>>>>>>>> The correct simulation of the input by H(P,P) is the
>>>>>>>>>>>>>>>>>>>>>>>>> simulation of this input at the same point in the execution
>>>>>>>>>>>>>>>>>>>>>>>>> trace where H is invoked.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> (2 + 3) * 5 != 2 + (3 * 5) // order matters.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Red Herring. Simulate(P,P) is ALWAYS the same (for a given P)
>>>>>>>>>>>>>>>>>>>>>>>> irrespective of "where" that simulation is done, at least if H
>>>>>>>>>>>>>>>>>>>>>>>> is a computation, and if it isn't it can't be a decider.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Although H must be a computation all sequences of
>>>>>>>>>>>>>>>>>>>>>>> configurations that do not halt are not computations**. The
>>>>>>>>>>>>>>>>>>>>>>> behavior of H is the same no matter where it is invoked.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Yes, so H(P,P) is ALWAYS the same, to return a 0 in finite time,
>>>>>>>>>>>>>>>>>>>>>> by the H you claim to be correct.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The behavior of P need not be (and indeed is not) the same.
>>>>>>>>>>>>>>>>>>>>>>> When P is invoked from main its behavior depends on the return
>>>>>>>>>>>>>>>>>>>>>>> value of H. When P is correctly simulated by H the return value
>>>>>>>>>>>>>>>>>>>>>>> from H is unreachable from every simulated P. This conclusively
>>>>>>>>>>>>>>>>>>>>>>> proves that the execution of P from main() and the correct
>>>>>>>>>>>>>>>>>>>>>>> simulation of P by H are not computationally equivalent.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope, by the construction of P, P will ALWAYS behave the same.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> All of your rebuttals are simply false assumptions and nothing more.
>>>>>>>>>>>>>>>>>>>>> I claim that
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> "When P is correctly simulated by H the return value from
>>>>>>>>>>>>>>>>>>>>> H is unreachable from every simulated P."
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> SO? There is no requirement that H is able to see the resuts of
>>>>>>>>>>>>>>>>>>>> the call inside the input it is simulating.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The ACTUAL behavior of the input to H(P,P) is DEFINED as the
>>>>>>>>>>>>>>>>>>>> behavior of P(P) or Simulate(P,P). The fact that H can't determine
>>>>>>>>>>>>>>>>>>>> that is H's fault.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Do you disagree that the CORRECT answer is based on the ACTUAL
>>>>>>>>>>>>>>>>>>>> BEHAVIOR of the ACUTAL INPUT?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H's inability to determine that is WHY it gets the wrong answer,
>>>>>>>>>>>>>>>>>>>> not an excuse for it to do so.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When you claim that I am incorrect it is merely an empty
>>>>>>>>>>>>>>>>>>>>> assertion utterly bereft of supporting reasoning.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, you LITERALLY are making an empty assertion, as you are
>>>>>>>>>>>>>>>>>>>> asserting something that never occurs.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> There is NO H that does a complete and correct simulation and
>>>>>>>>>>>>>>>>>>>> returns an answer. We can even argue that it doesn't do a correct
>>>>>>>>>>>>>>>>>>>> simulation since the last step of the simulation has an error as
>>>>>>>>>>>>>>>>>>>> it presumes the wrong behavior of the call to H that it encounter
>>>>>>>>>>>>>>>>>>>> (you can debate if this is an incorrect simulation or just unsound
>>>>>>>>>>>>>>>>>>>> logic).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A simulating halt decider continues to simulate its input until
>>>>>>>>>>>>>>>>>>>>> it correctly matches a correct infinite behavior pattern.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Then why does you H abort too soon, as shown by the fact that the
>>>>>>>>>>>>>>>>>>>> complete simulation Simualte(P,P) does halt when H(P,P) returns 0?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Just says that your H doesn't even meet your own definition.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> int Halt_Status = Hx(x, x);
>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", Hx(Px, Px));
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In order for me to actually be wrong you must be able to show
>>>>>>>>>>>>>>>>>>>>> that some simulating halt decider Hx could be defined such that
>>>>>>>>>>>>>>>>>>>>> its correct simulation of its input Px reaches the final state of
>>>>>>>>>>>>>>>>>>>>> Px in a finite number of steps.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope. H(P,P) is wrong
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ..then a mistake could be shown, if no mistake can be shown then it
>>>>>>>>>>>>>>>>>>> is not wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And it has been.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Even YOU hav published the correct and complete simuliaton of the
>>>>>>>>>>>>>>>>>> input to H(P,P) being the trace of P(P) and Simulate(P,P)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I contend that that no simulating halt decider Hx can be defined
>>>>>>>>>>>>>>>>>>> such that its correctly simulated input Px could reach the final
>>>>>>>>>>>>>>>>>>> state of this simulated Px in any finite number of steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, that isn't the question.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *I STIPULATE FOR THIS THREAD THAT IS THE QUESTION*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any rebuttal must show all of the steps of exactly how the input to
>>>>>>>>>>>>>>>>> Hx(Px,Px) correctly simulated by Hx reaches the final state of Px in
>>>>>>>>>>>>>>>>> a finite number of steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ALTERNATIVELY YOU COULD SIMPLY ADMIT THE TRUTH
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You don't get to stipulate the test,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In other words you know that my statement is correct and you are too
>>>>>>>>>>>>>>> dishonest to admit it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, shows you don't understand about requirements.
>>>>>>>>>>>>> Ultimately, you are a shit for brains fucking idiot because you have admitted unsatisfiable requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is precisely because the requirements are unsatisfiable they amount to nothing other than The bottom/uninhabited type. Falsity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Bottom_type
>>>>>>>>>>>> Nope, given an H, the answer is defined , and computabe if we know that
>>>>>>>>>>>> H does return an answer.
>>>>>>>>>>> How? There is no H for the pathological P.
>>>>>>>>>>> Furthermore because the dependencies of P are unsatisfiable (P requires H) there is also no P.
>>>>>>>>>> Because Olcott has defined what he calls H.
>>>>>>>>>>
>>>>>>>>>> Yes, H doesn't meet the requirements, but he claims it does and we are
>>>>>>>>>> showing that H is incorrect.
>>>>>>>>> But why are you so concerned with showing that H is incorrect; while being so unconcerned by the fact that the requirements are incorrect?
>>>>>>>>>
>>>>>>>>> The requirements amount to falsify!
>>>>>>>> The requirements are correct, BY DEFINITION, they require what they require.
>>>>>>> But the requirements require you to violate the principle you cherish so dearly!
>>>>>>>
>>>>>>> The requirements clash with YOUR principle!
>>>>>> What clash?
>>>>>>
>>>>>> Remember, H isn't a Halt Decider, it is something some CLAIMS
>>>>>> (incorrectly) to be a Halt Decider.
>>>>> Obviously! Because YOU admitted that Halt Deciders don’t exist!
>>>>>
>>>>> So what are YOU talking about when you are talking about non-existing entities?!?
>>>> Where did I actually talk about a non-existant entity exist?
>>> Oracles!
>>>
>>> Is the set of “correct halting deciders” empty, or do oracles belong to that set ?!?
>> Oracles, as I think you are defining it, do not meet the requirement of
>> a Correct Halting Decider, because the definition of that says it is a
>> Computation, but an Oracle isn't a Computation.
> But then your requirements are incoherent!
>
> The extensional properties of a computational and a non-computational function are indistinguishable!
>
>> You don't understand that there can be things that we can get answer
>> from (but programs can not?)
> You don’t understand that any answers we can get - we can also pass onto any program?

On 9/4/22 11:16 PM, olcott wrote:
> On 9/4/2022 1:07 PM, Richard Damon wrote:
>> On 9/4/22 1:50 PM, olcott wrote:
>>> On 9/4/2022 12:14 PM, Richard Damon wrote:
>>>>
>>>> On 9/4/22 12:33 PM, olcott wrote:
>>>>> On 9/3/2022 12:24 PM, Richard Damon wrote:
>>>>>> On 9/3/22 1:18 PM, olcott wrote:
>>>>>>> On 9/3/2022 12:08 PM, Richard Damon wrote:
>>>>>>>> On 9/3/22 12:56 PM, olcott wrote:
>>>>>>>>> On 9/3/2022 11:47 AM, Richard Damon wrote:
>>>>>>>>>> On 9/3/22 12:32 PM, olcott wrote:
>>>>>>>>>>> On 9/3/2022 11:14 AM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/3/22 12:05 PM, olcott wrote:
>>>>>>>>>>>>> On 9/3/2022 11:00 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/3/22 11:53 AM, olcott wrote:
>>>>>>>>>>>>>>> On 9/3/2022 10:31 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/3/22 11:20 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/3/2022 9:33 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/3/22 10:28 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:26 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9/3/22 10:14 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:06 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 2:03:48 PM
>>>>>>>>>>>>>>>>>>>>>> UTC+1, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 7:50 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 1:43:43 PM
>>>>>>>>>>>>>>>>>>>>>>>> UTC+1, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 7:00 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 2:54:54 AM
>>>>>>>>>>>>>>>>>>>>>>>>>> UTC+1, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you won't go by the oficial definitions,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> your H just isn't a Halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If the official definitions are
>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory then at least one of
>>>>>>>>>>>>>>>>>>>>>>>>>>> them must be rejected as incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> No, you are wrong here. The official
>>>>>>>>>>>>>>>>>>>>>>>>>> definition of a halt decider is
>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory, in that it is impossible
>>>>>>>>>>>>>>>>>>>>>>>>>> to build anything which meets the definition.
>>>>>>>>>>>>>>>>>>>>>>>>>> This has been proved.
>>>>>>>>>>>>>>>>>>>>>>>>> That is not the way truth works mate. If the
>>>>>>>>>>>>>>>>>>>>>>>>> official definitions are
>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory then I have also had new
>>>>>>>>>>>>>>>>>>>>>>>>> insight on that another
>>>>>>>>>>>>>>>>>>>>>>>>> aspect of computer science is incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> So you are not disputing that official
>>>>>>>>>>>>>>>>>>>>>>>> definition of a halt decider is self-contradictory?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The correct and complete simulation of an input
>>>>>>>>>>>>>>>>>>>>>>> is guaranteed to derive
>>>>>>>>>>>>>>>>>>>>>>> the actual behavior of this input.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) must
>>>>>>>>>>>>>>>>>>>>>>> abort the simulation
>>>>>>>>>>>>>>>>>>>>>>> of its input to prevent the infinite execution of
>>>>>>>>>>>>>>>>>>>>>>> this input is merely
>>>>>>>>>>>>>>>>>>>>>>> another way of saying the the correct and
>>>>>>>>>>>>>>>>>>>>>>> complete simulation of the
>>>>>>>>>>>>>>>>>>>>>>> input by this SHD would never stop running.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When computer science textbooks say that the
>>>>>>>>>>>>>>>>>>>>>>> behavior that a halt
>>>>>>>>>>>>>>>>>>>>>>> decider must report on is the behavior of the
>>>>>>>>>>>>>>>>>>>>>>> direct execution of the
>>>>>>>>>>>>>>>>>>>>>>> machine represented by this input and this
>>>>>>>>>>>>>>>>>>>>>>> behavior is not the same as
>>>>>>>>>>>>>>>>>>>>>>> the correct and complete simulation of this input
>>>>>>>>>>>>>>>>>>>>>>> then the computer
>>>>>>>>>>>>>>>>>>>>>>> science textbooks are wrong because they reject
>>>>>>>>>>>>>>>>>>>>>>> the definition of a UTM.
>>>>>>>>>>>>>>>>>>>>>>> (simulator).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I was hoping for more of a yes-or-no type answer.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When I provide a complete explanation of the
>>>>>>>>>>>>>>>>>>>>> reasoning behind the answer all those not
>>>>>>>>>>>>>>>>>>>>> understanding these things cannot simply baselessly
>>>>>>>>>>>>>>>>>>>>> disagree. All disagreement is thus required to have
>>>>>>>>>>>>>>>>>>>>> a basis. This way people are not lead astray by a
>>>>>>>>>>>>>>>>>>>>> bunch of baseless disagreement, they see that the
>>>>>>>>>>>>>>>>>>>>> disagreement has no basis and reject it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So, you need to try to actually provide VALID
>>>>>>>>>>>>>>>>>>>> reasoning, starting from ACCEPTED definition.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You just make wild claims based on your own
>>>>>>>>>>>>>>>>>>>> understanding of the words.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Since you don't even attempt to actually DEFINE the
>>>>>>>>>>>>>>>>>>>> words, no one can help you with your logic.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Note, Most of the things you are talking about HAVE
>>>>>>>>>>>>>>>>>>>> well defined meanings, so you either need to use
>>>>>>>>>>>>>>>>>>>> that meaning, or you really need to give your idea a
>>>>>>>>>>>>>>>>>>>> new name (maybe basd on the common name with a
>>>>>>>>>>>>>>>>>>>> modifier).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thus, if you definition of "Halting" isn't the same
>>>>>>>>>>>>>>>>>>>> as the accepted definition, you can call it PO-Halting.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Of course the problem with this is it makes it clear
>>>>>>>>>>>>>>>>>>>> that you are talking about the PO-Halting Problem,
>>>>>>>>>>>>>>>>>>>> with a PO-Halting Decider, so you counter example
>>>>>>>>>>>>>>>>>>>> doesn't affect the actual Halting Problem, so it is
>>>>>>>>>>>>>>>>>>>> clear you haven't proven what you claim to have proven.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It's not immediately obvious, but it can be
>>>>>>>>>>>>>>>>>>>>>>>> proved that the definition is
>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory. You're not disputing that
>>>>>>>>>>>>>>>>>>>>>>>> proof?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You haven't actually given a proof, since you are
>>>>>>>>>>>>>>>>>>>> clearly using altered definition that you aren't
>>>>>>>>>>>>>>>>>>>> providing.
>>>>>>>>>>>>>>>>>>> You reject the notion of a UTM so you are starting
>>>>>>>>>>>>>>>>>>> with an incorrect basis.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I have done no such thing. UTM's exist, and UTM(P,d)
>>>>>>>>>>>>>>>>>> by DEFINITION gives the exact same result as P(d).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When you get a glass of water and dump it on the floor
>>>>>>>>>>>>>>>>> you cannot truthfully deny that the floor is wet.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And I haven't
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When the correct and complete simulation of the input
>>>>>>>>>>>>>>>>> by H(P,P) would have different behavior than the direct
>>>>>>>>>>>>>>>>> execution of P(P) this cannot simply be ignored.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And the correct and complete simulation of the input to
>>>>>>>>>>>>>>>> H(P,P) Halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The fact that the simulation by H(P,P) of its input never
>>>>>>>>>>>>>>> stops running unless H aborts the simulation of this
>>>>>>>>>>>>>>> input is merely another way of saying that the correct
>>>>>>>>>>>>>>> and complete simulation of this input by H never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You have bad logic there.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is a tautology:
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    HERE: goto HERE;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    Output("Input_Halts = ", H0((u32)Infinite_Loop));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>> [00001102](01)  55         push ebp
>>>>>>>>>>>>> [00001103](02)  8bec       mov ebp,esp
>>>>>>>>>>>>> [00001105](02)  ebfe       jmp 00001105
>>>>>>>>>>>>> [00001107](01)  5d         pop ebp
>>>>>>>>>>>>> [00001108](01)  c3         ret
>>>>>>>>>>>>> Size in bytes:(0007) [00001108]
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fact that the simulation by H0(Infinite_Loop) of its
>>>>>>>>>>>>> input would never stop running unless H0 aborts the
>>>>>>>>>>>>> simulation of this input is merely another way of saying
>>>>>>>>>>>>> that the correct and complete simulation of this input by
>>>>>>>>>>>>> H0 never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Strawman.
>>>>>>>>>>>>
>>>>>>>>>>>> Fallacy of Proof by Example.
>>>>>>>>>>>
>>>>>>>>>>> It is only a fallacy by proof of example when a single
>>>>>>>>>>> example is not representative of the entire class of all such
>>>>>>>>>>> examples.
>>>>>>>>>>
>>>>>>>>>> Which it isn't, so FAIL.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You are confusing existential quantification with universal
>>>>>>>>>>> quantification.
>>>>>>>>>>
>>>>>>>>>> No you are, since you are claiming the rule works for ALL
>>>>>>>>>> inputs (or at least P, which isn't the input you showed it
>>>>>>>>>> worked for).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ∀ simulating halt decider H
>>>>>>>>>>> ∀ machine description P
>>>>>>>>>>
>>>>>>>>>> Right. ∀, so UNIVERSAL, not EXISTENTIAL, so FAIL.
>>>>>>>>>>
>>>>>>>>>> You don't seem to know what those words mean.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The fact that the correct simulation of any input P to any
>>>>>>>>>>> simulating halt decider (SHD) H would never stop running
>>>>>>>>>>> unless this simulation was aborted by this SHD is merely
>>>>>>>>>>> another way of saying that the correct and complete
>>>>>>>>>>> simulation of this input by this SHD would never stop running.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope, not when the input depends on the behavior of the
>>>>>>>>>> decider in the way you are doing it.
>>>>>>>>>
>>>>>>>>> P was intentionally defined to depend on the behavior of its
>>>>>>>>> decider *NITWIT*
>>>>>>>>
>>>>>>>> Right, but your "example" didn't, and this dependency is the
>>>>>>>> case that breaks your "proof" and definitions.
>>>>>>> The correct simulation of the input by H(P,P) is the simulation
>>>>>>> of this input at the same point in the execution trace where H is
>>>>>>> invoked.
>>>>>>>
>>>>>>> (2 + 3) * 5   !=   2 + (3 * 5) // order matters.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Red Herring. Simulate(P,P) is ALWAYS the same (for a given P)
>>>>>> irrespective of "where" that simulation is done, at least if H is
>>>>>> a computation, and if it isn't it can't be a decider.
>>>>>>
>>>>> Although H must be a computation all sequences of configurations
>>>>> that do not halt are not computations**. The behavior of H is the
>>>>> same no matter where it is invoked.
>>>>>
>>>>
>>>> Yes, so H(P,P) is ALWAYS the same, to return a 0 in finite time, by
>>>> the H you claim to be correct.
>>>>
>>>>> The behavior of P need not be (and indeed is not) the same. When P
>>>>> is invoked from main its behavior depends on the return value of H.
>>>>> When P is correctly simulated by H the return value from H is
>>>>> unreachable from every simulated P. This conclusively proves that
>>>>> the execution of P from main() and the correct simulation of P by H
>>>>> are not computationally equivalent.
>>>>
>>>>
>>>> Nope, by the construction of P, P will ALWAYS behave the same.
>>>>
>>> All of your rebuttals are simply false assumptions and nothing more.
>>> I claim that
>>>
>>>     "When P is correctly simulated by H the return value from
>>>      H is unreachable from every simulated P."
>>
>> SO? There is no requirement that H is able to see the resuts of the
>> call inside the input it is simulating.
>>
>> The ACTUAL behavior of the input to H(P,P) is DEFINED as the behavior
>> of P(P) or Simulate(P,P). The fact that H can't determine that is H's
>> fault.
>>
>> Do you disagree that the CORRECT answer is based on the ACTUAL
>> BEHAVIOR of the ACUTAL INPUT?
>>
>> H's inability to determine that is WHY it gets the wrong answer, not
>> an excuse for it to do so.
>>
>>>
>>> When you claim that I am incorrect it is merely an empty assertion
>>> utterly bereft of supporting reasoning.
>>
>> No, you LITERALLY are making an empty assertion, as you are asserting
>> something that never occurs.
>>
>> There is NO H that does a complete and correct simulation and returns
>> an answer. We can even argue that it doesn't do a correct simulation
>> since the last step of the simulation has an error as it presumes the
>> wrong behavior of the call to H that it encounter (you can debate if
>> this is an incorrect simulation or just unsound logic).
>>
>>>
>>> A simulating halt decider continues to simulate its input until it
>>> correctly matches a correct infinite behavior pattern.
>>
>> Then why does you H abort too soon, as shown by the fact that the
>> complete simulation Simualte(P,P) does halt when H(P,P) returns 0?
>>
>> Just says that your H doesn't even meet your own definition.
>>
>>>
>>> void Px(ptr x)
>>> {
>>>    int Halt_Status = Hx(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", Hx(Px, Px));
>>> }
>>>
>>> In order for me to actually be wrong you must be able to show that
>>> some simulating halt decider Hx could be defined such that its
>>> correct simulation of its input Px reaches the final state of Px in a
>>> finite number of steps.
>>>
>>
>> Nope. H(P,P) is wrong if its answer doesn't match the REQURIED
>> definition of a Halting Decider.
>>
>> Since P(P) Halts, when H(P,P) returns 0, that means that answer is
>> WRONG, BY DEFINITION.
>>
>> You are just showing that you aren't (and likely never have actually
>> been) working on the Halting Problem.
>>
>> There is no requirement that some decider is able to see the right
>> answer. In fact, the proof shows that such a thing is IMPOSSIBLE.
>>
>> FAIL.
>>
>> Just showing how ignorant you are.
>>
>
>
> void Px(ptr x)
> {
>  int Halt_Status = Hx(x, x);
>  if (Halt_Status)
>    HERE: goto HERE;
>  return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", Hx(Px, Px));
> }
>
> I contend that that no function Hx can be defined such that its
> correctly simulated input Px could reach the final state of this
> simulated Px in any finite number of steps.
>
>

On 9/5/22 3:54 AM, Skep Dick wrote:
> On Monday, 5 September 2022 at 04:38:50 UTC+2, richar...@gmail.com wrote:

>> Does Realizability handle ALL the properties of the normal Natural Numbers?
> I have absolutely no idea what that question means.
>
>

Then I guess it probably doesn't.

That means we can't apply it to Computation Theory which does.

On Monday, 5 September 2022 at 15:54:02 UTC+2, richar...@gmail.com wrote:
> On 9/5/22 3:34 AM, Skep Dick wrote:
> > On Monday, 5 September 2022 at 04:23:04 UTC+2, richar...@gmail.com wrote:
> >> On 9/4/22 9:50 PM, Skep Dick wrote:
> >>> On Monday, 5 September 2022 at 02:44:04 UTC+2, richar...@gmail.com wrote:
> >>>> On 9/4/22 8:24 PM, Skep Dick wrote:
> >>>>> On Monday, 5 September 2022 at 01:45:53 UTC+2, richar...@gmail.com wrote:
> >>>>>> On 9/4/22 7:35 PM, Skep Dick wrote:
> >>>>>>> On Monday, 5 September 2022 at 00:58:13 UTC+2, richar...@gmail.com wrote:
> >>>>>>>> On 9/4/22 6:02 PM, Skep Dick wrote:
> >>>>>>>>> On Sunday, 4 September 2022 at 22:46:44 UTC+2, richar...@gmail.com wrote:
> >>>>>>>>>> On 9/4/22 4:33 PM, Skep Dick wrote:
> >>>>>>>>>>> On Sunday, 4 September 2022 at 22:24:14 UTC+2, richar...@gmail.com wrote:
> >>>>>>>>>>>> On 9/4/22 4:01 PM, Skep Dick wrote:
> >>>>>>>>>>>>> On Sunday, 4 September 2022 at 21:52:16 UTC+2, richar...@gmail.com wrote:
> >>>>>>>>>>>>>> On 9/4/22 3:30 PM, olcott wrote:
> >>>>>>>>>>>>>>> On 9/4/2022 2:21 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>> On 9/4/22 3:16 PM, olcott wrote:
> >>>>>>>>>>>>>>>>> On 9/4/2022 2:04 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>> On 9/4/22 2:35 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>> On 9/4/2022 1:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>> On 9/4/22 1:50 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>> On 9/4/2022 12:14 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 9/4/22 12:33 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 12:24 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 1:18 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 12:08 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 12:56 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 11:47 AM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 12:32 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 11:14 AM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 12:05 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 11:00 AM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 11:53 AM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 10:31 AM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 11:20 AM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:33 AM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 10:28 AM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:26 AM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 10:14 AM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:06 AM, Paul N wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 2:03:48 PM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC+1, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 7:50 AM, Paul N wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 1:43:43 PM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC+1, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 7:00 AM, Paul N wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 2:54:54
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AM UTC+1, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:46 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you won't go by the oficial
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definitions, your H just isn't a Halt
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Decider.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the official definitions are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory then at least one of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> them must be rejected as incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you are wrong here. The official
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of a halt decider is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory, in that it is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> impossible to build anything which meets
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the definition. This has been proved.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is not the way truth works mate. If
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the official definitions are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory then I have also had new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> insight on that another
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aspect of computer science is incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you are not disputing that official
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of a halt decider is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The correct and complete simulation of an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is guaranteed to derive
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the actual behavior of this input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> must abort the simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of its input to prevent the infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution of this input is merely
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> another way of saying the the correct and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> complete simulation of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input by this SHD would never stop running.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When computer science textbooks say that the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior that a halt
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider must report on is the behavior of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> direct execution of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine represented by this input and this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior is not the same as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the correct and complete simulation of this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input then the computer
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> science textbooks are wrong because they
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject the definition of a UTM.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (simulator).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I was hoping for more of a yes-or-no type answer.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I provide a complete explanation of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reasoning behind the answer all those not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understanding these things cannot simply
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baselessly disagree. All disagreement is thus
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required to have a basis. This way people are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not lead astray by a bunch of baseless
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreement, they see that the disagreement
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has no basis and reject it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So, you need to try to actually provide VALID
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reasoning, starting from ACCEPTED definition.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You just make wild claims based on your own
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understanding of the words.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since you don't even attempt to actually DEFINE
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the words, no one can help you with your logic.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, Most of the things you are talking about
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HAVE well defined meanings, so you either need
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to use that meaning, or you really need to give
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your idea a new name (maybe basd on the common
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name with a modifier).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thus, if you definition of "Halting" isn't the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same as the accepted definition, you can call it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PO-Halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Of course the problem with this is it makes it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clear that you are talking about the PO-Halting
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Problem, with a PO-Halting Decider, so you
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> counter example doesn't affect the actual
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting Problem, so it is clear you haven't
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proven what you claim to have proven.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It's not immediately obvious, but it can be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proved that the definition is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory. You're not disputing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that proof?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You haven't actually given a proof, since you
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are clearly using altered definition that you
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aren't providing.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You reject the notion of a UTM so you are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> starting with an incorrect basis.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have done no such thing. UTM's exist, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTM(P,d) by DEFINITION gives the exact same result
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as P(d).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When you get a glass of water and dump it on the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> floor you cannot truthfully deny that the floor is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wet.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And I haven't
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When the correct and complete simulation of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input by H(P,P) would have different behavior than
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the direct execution of P(P) this cannot simply be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ignored.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And the correct and complete simulation of the input
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H(P,P) Halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fact that the simulation by H(P,P) of its input
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never stops running unless H aborts the simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this input is merely another way of saying that the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct and complete simulation of this input by H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have bad logic there.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is a tautology:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H0((u32)Infinite_Loop));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001102](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001103](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001105](02) ebfe jmp 00001105
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001107](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001108](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00001108]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fact that the simulation by H0(Infinite_Loop) of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its input would never stop running unless H0 aborts the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of this input is merely another way of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> saying that the correct and complete simulation of this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input by H0 never halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Strawman.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fallacy of Proof by Example.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is only a fallacy by proof of example when a single
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> example is not representative of the entire class of all
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> such examples.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Which it isn't, so FAIL.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> You are confusing existential quantification with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> universal quantification.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> No you are, since you are claiming the rule works for ALL
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> inputs (or at least P, which isn't the input you showed it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> worked for).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ∀ simulating halt decider H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ∀ machine description P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Right. ∀, so UNIVERSAL, not EXISTENTIAL, so FAIL.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't seem to know what those words mean..
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fact that the correct simulation of any input P to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> any simulating halt decider (SHD) H would never stop
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> running unless this simulation was aborted by this SHD is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely another way of saying that the correct and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> complete simulation of this input by this SHD would never
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, not when the input depends on the behavior of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> decider in the way you are doing it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> P was intentionally defined to depend on the behavior of
> >>>>>>>>>>>>>>>>>>>>>>>>>>> its decider *NITWIT*
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Right, but your "example" didn't, and this dependency is the
> >>>>>>>>>>>>>>>>>>>>>>>>>> case that breaks your "proof" and definitions.
> >>>>>>>>>>>>>>>>>>>>>>>>> The correct simulation of the input by H(P,P) is the
> >>>>>>>>>>>>>>>>>>>>>>>>> simulation of this input at the same point in the execution
> >>>>>>>>>>>>>>>>>>>>>>>>> trace where H is invoked.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> (2 + 3) * 5 != 2 + (3 * 5) // order matters.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Red Herring. Simulate(P,P) is ALWAYS the same (for a given P)
> >>>>>>>>>>>>>>>>>>>>>>>> irrespective of "where" that simulation is done, at least if H
> >>>>>>>>>>>>>>>>>>>>>>>> is a computation, and if it isn't it can't be a decider.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Although H must be a computation all sequences of
> >>>>>>>>>>>>>>>>>>>>>>> configurations that do not halt are not computations**. The
> >>>>>>>>>>>>>>>>>>>>>>> behavior of H is the same no matter where it is invoked.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Yes, so H(P,P) is ALWAYS the same, to return a 0 in finite time,
> >>>>>>>>>>>>>>>>>>>>>> by the H you claim to be correct.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The behavior of P need not be (and indeed is not) the same.
> >>>>>>>>>>>>>>>>>>>>>>> When P is invoked from main its behavior depends on the return
> >>>>>>>>>>>>>>>>>>>>>>> value of H. When P is correctly simulated by H the return value
> >>>>>>>>>>>>>>>>>>>>>>> from H is unreachable from every simulated P. This conclusively
> >>>>>>>>>>>>>>>>>>>>>>> proves that the execution of P from main() and the correct
> >>>>>>>>>>>>>>>>>>>>>>> simulation of P by H are not computationally equivalent.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Nope, by the construction of P, P will ALWAYS behave the same.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> All of your rebuttals are simply false assumptions and nothing more.
> >>>>>>>>>>>>>>>>>>>>> I claim that
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> "When P is correctly simulated by H the return value from
> >>>>>>>>>>>>>>>>>>>>> H is unreachable from every simulated P."
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> SO? There is no requirement that H is able to see the resuts of
> >>>>>>>>>>>>>>>>>>>> the call inside the input it is simulating.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The ACTUAL behavior of the input to H(P,P) is DEFINED as the
> >>>>>>>>>>>>>>>>>>>> behavior of P(P) or Simulate(P,P). The fact that H can't determine
> >>>>>>>>>>>>>>>>>>>> that is H's fault.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Do you disagree that the CORRECT answer is based on the ACTUAL
> >>>>>>>>>>>>>>>>>>>> BEHAVIOR of the ACUTAL INPUT?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> H's inability to determine that is WHY it gets the wrong answer,
> >>>>>>>>>>>>>>>>>>>> not an excuse for it to do so.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> When you claim that I am incorrect it is merely an empty
> >>>>>>>>>>>>>>>>>>>>> assertion utterly bereft of supporting reasoning.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> No, you LITERALLY are making an empty assertion, as you are
> >>>>>>>>>>>>>>>>>>>> asserting something that never occurs.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> There is NO H that does a complete and correct simulation and
> >>>>>>>>>>>>>>>>>>>> returns an answer. We can even argue that it doesn't do a correct
> >>>>>>>>>>>>>>>>>>>> simulation since the last step of the simulation has an error as
> >>>>>>>>>>>>>>>>>>>> it presumes the wrong behavior of the call to H that it encounter
> >>>>>>>>>>>>>>>>>>>> (you can debate if this is an incorrect simulation or just unsound
> >>>>>>>>>>>>>>>>>>>> logic).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> A simulating halt decider continues to simulate its input until
> >>>>>>>>>>>>>>>>>>>>> it correctly matches a correct infinite behavior pattern.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Then why does you H abort too soon, as shown by the fact that the
> >>>>>>>>>>>>>>>>>>>> complete simulation Simualte(P,P) does halt when H(P,P) returns 0?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Just says that your H doesn't even meet your own definition.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> void Px(ptr x)
> >>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>> int Halt_Status = Hx(x, x);
> >>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", Hx(Px, Px));
> >>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> In order for me to actually be wrong you must be able to show
> >>>>>>>>>>>>>>>>>>>>> that some simulating halt decider Hx could be defined such that
> >>>>>>>>>>>>>>>>>>>>> its correct simulation of its input Px reaches the final state of
> >>>>>>>>>>>>>>>>>>>>> Px in a finite number of steps.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Nope. H(P,P) is wrong
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ..then a mistake could be shown, if no mistake can be shown then it
> >>>>>>>>>>>>>>>>>>> is not wrong.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> And it has been.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Even YOU hav published the correct and complete simuliaton of the
> >>>>>>>>>>>>>>>>>> input to H(P,P) being the trace of P(P) and Simulate(P,P)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I contend that that no simulating halt decider Hx can be defined
> >>>>>>>>>>>>>>>>>>> such that its correctly simulated input Px could reach the final
> >>>>>>>>>>>>>>>>>>> state of this simulated Px in any finite number of steps.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> So, that isn't the question.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> *I STIPULATE FOR THIS THREAD THAT IS THE QUESTION*
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Any rebuttal must show all of the steps of exactly how the input to
> >>>>>>>>>>>>>>>>> Hx(Px,Px) correctly simulated by Hx reaches the final state of Px in
> >>>>>>>>>>>>>>>>> a finite number of steps.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ALTERNATIVELY YOU COULD SIMPLY ADMIT THE TRUTH
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You don't get to stipulate the test,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In other words you know that my statement is correct and you are too
> >>>>>>>>>>>>>>> dishonest to admit it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Nope, shows you don't understand about requirements.
> >>>>>>>>>>>>> Ultimately, you are a shit for brains fucking idiot because you have admitted unsatisfiable requirements.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It is precisely because the requirements are unsatisfiable they amount to nothing other than The bottom/uninhabited type. Falsity.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> https://en.wikipedia.org/wiki/Bottom_type
> >>>>>>>>>>>> Nope, given an H, the answer is defined , and computabe if we know that
> >>>>>>>>>>>> H does return an answer.
> >>>>>>>>>>> How? There is no H for the pathological P.
> >>>>>>>>>>> Furthermore because the dependencies of P are unsatisfiable (P requires H) there is also no P.
> >>>>>>>>>> Because Olcott has defined what he calls H.
> >>>>>>>>>>
> >>>>>>>>>> Yes, H doesn't meet the requirements, but he claims it does and we are
> >>>>>>>>>> showing that H is incorrect.
> >>>>>>>>> But why are you so concerned with showing that H is incorrect; while being so unconcerned by the fact that the requirements are incorrect?
> >>>>>>>>>
> >>>>>>>>> The requirements amount to falsify!
> >>>>>>>> The requirements are correct, BY DEFINITION, they require what they require.
> >>>>>>> But the requirements require you to violate the principle you cherish so dearly!
> >>>>>>>
> >>>>>>> The requirements clash with YOUR principle!
> >>>>>> What clash?
> >>>>>>
> >>>>>> Remember, H isn't a Halt Decider, it is something some CLAIMS
> >>>>>> (incorrectly) to be a Halt Decider.
> >>>>> Obviously! Because YOU admitted that Halt Deciders don’t exist!
> >>>>>
> >>>>> So what are YOU talking about when you are talking about non-existing entities?!?
> >>>> Where did I actually talk about a non-existant entity exist?
> >>> Oracles!
> >>>
> >>> Is the set of “correct halting deciders” empty, or do oracles belong to that set ?!?
> >> Oracles, as I think you are defining it, do not meet the requirement of
> >> a Correct Halting Decider, because the definition of that says it is a
> >> Computation, but an Oracle isn't a Computation.
> > But then your requirements are incoherent!
> >
> > The extensional properties of a computational and a non-computational function are indistinguishable!
> >
> >> You don't understand that there can be things that we can get answer
> >> from (but programs can not?)
> > You don’t understand that any answers we can get - we can also pass onto any program?
> Nope, not if you aren't a progran, and Oracles aren't programs in the
> class of programs we are considering.
We who? I am considering them,

On 9/5/2022 5:49 AM, Otto J. Makela wrote:
> olcott <polcott2@gmail.com> wrote:
>
>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>> olcott <polcott2@gmail.com> wrote:
>>>> In every case where the simulation of the input by H would never
>>>> stop running H aborts its simulation and returns 0.
>>> Why would a simulation of H() not return a value, once it had done
>>> the same kind of deduction?
>>
>> A simulating halt decider must abort the simulation of every otherwise
>> non-terminating input. It does this by correctly recognizing
>> non-terminating behavior patterns.
>
> You did not answer my question: if H() always returns a value, why would
> a simulated H() also not always return a value in the simulation?

I will give you the short answer, the simulated H is never invoked.

> "Because I defined it so" is not a sufficient answer here.

A simulating halt decider (SHD) always bases its halt status decision on
correctly predicting whether or not it must abort the correct simulation
of its input to prevent the infinite execution of this input.

A simulating halt decider that does not abort its simulation of its
input performs a correct and complete simulation of this input.

The definition of a UTM says that any correct and complete simulation of
an input derives the actual behavior of this simulated input.

Thus if the correct and complete simulation of an input never reaches
the final state of this input this means that this input specifies a
non-halting sequence of instructions.

The fact that the simulation of this input is aborted does not change
the fact that this correctly simulated input cannot possibly reach its
own final state.

Once we know that the correctly simulated cannot possibly reach its own
final state this input can be rejected as non-halting on the basis of
the definition of non-halting: *never reaches its final state*

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

_P()
[000010f2](01) 55 push ebp
[000010f3](02) 8bec mov ebp,esp
[000010f5](01) 51 push ecx
[000010f6](03) 8b4508 mov eax,[ebp+08]
[000010f9](01) 50 push eax // push P
[000010fa](03) 8b4d08 mov ecx,[ebp+08]
[000010fd](01) 51 push ecx // push P
[000010fe](05) e88ffdffff call 00000e92 // call H
[00001103](03) 83c408 add esp,+08
[00001106](03) 8945fc mov [ebp-04],eax
[00001109](04) 837dfc00 cmp dword [ebp-04],+00
[0000110d](02) 7402 jz 00001111
[0000110f](02) ebfe jmp 0000110f
[00001111](02) 8be5 mov esp,ebp
[00001113](01) 5d pop ebp
[00001114](01) c3 ret
Size in bytes:(0035) [00001114]

int main()
{ Output("Input_Halts = ", H(P, P));
}

This is what happens if H never aborts the simulation of its input:
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...

When P is correctly simulated by H and H does not abort its simulation
of P the first 8 instructions of P are simulated endlessly.

Because a decider must always halt and a decider must always return that
same value for the same input every time it is invoked H correctly
recognizes the infinite behavior pattern of P before P invokes H(P,P)
for the first time. At this point H aborts its simulation of P and
rejects p as non-halting.

*Halting problem proofs refuted on the basis of software engineering* ?
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
Copyright 2022 Pete Olcott

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

On 9/5/22 10:46 AM, Skep Dick wrote:
> On Monday, 5 September 2022 at 15:54:02 UTC+2, richar...@gmail.com wrote:
>> On 9/5/22 3:34 AM, Skep Dick wrote:
>>> On Monday, 5 September 2022 at 04:23:04 UTC+2, richar...@gmail.com wrote:
>>>> On 9/4/22 9:50 PM, Skep Dick wrote:
>>>>> On Monday, 5 September 2022 at 02:44:04 UTC+2, richar...@gmail.com wrote:
>>>>>> On 9/4/22 8:24 PM, Skep Dick wrote:
>>>>>>> On Monday, 5 September 2022 at 01:45:53 UTC+2, richar...@gmail.com wrote:
>>>>>>>> On 9/4/22 7:35 PM, Skep Dick wrote:
>>>>>>>>> On Monday, 5 September 2022 at 00:58:13 UTC+2, richar...@gmail.com wrote:
>>>>>>>>>> On 9/4/22 6:02 PM, Skep Dick wrote:
>>>>>>>>>>> On Sunday, 4 September 2022 at 22:46:44 UTC+2, richar...@gmail.com wrote:
>>>>>>>>>>>> On 9/4/22 4:33 PM, Skep Dick wrote:
>>>>>>>>>>>>> On Sunday, 4 September 2022 at 22:24:14 UTC+2, richar...@gmail.com wrote:
>>>>>>>>>>>>>> On 9/4/22 4:01 PM, Skep Dick wrote:
>>>>>>>>>>>>>>> On Sunday, 4 September 2022 at 21:52:16 UTC+2, richar...@gmail.com wrote:
>>>>>>>>>>>>>>>> On 9/4/22 3:30 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/4/2022 2:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/4/22 3:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/4/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/4/22 2:35 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/4/2022 1:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/4/22 1:50 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/4/2022 12:14 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 9/4/22 12:33 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 12:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 1:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 12:08 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 12:56 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 11:47 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 12:32 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 11:14 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 12:05 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 11:00 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 11:53 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 10:31 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 11:20 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:33 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 10:28 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:26 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/22 10:14 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 9:06 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 2:03:48 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC+1, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 7:50 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 1:43:43 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC+1, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2022 7:00 AM, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, September 3, 2022 at 2:54:54
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AM UTC+1, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you won't go by the oficial
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definitions, your H just isn't a Halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the official definitions are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory then at least one of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> them must be rejected as incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you are wrong here. The official
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of a halt decider is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory, in that it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> impossible to build anything which meets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the definition. This has been proved.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is not the way truth works mate. If
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the official definitions are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory then I have also had new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> insight on that another
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aspect of computer science is incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you are not disputing that official
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definition of a halt decider is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The correct and complete simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is guaranteed to derive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the actual behavior of this input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> must abort the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of its input to prevent the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution of this input is merely
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> another way of saying the the correct and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> complete simulation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input by this SHD would never stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When computer science textbooks say that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior that a halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider must report on is the behavior of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> direct execution of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine represented by this input and this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior is not the same as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the correct and complete simulation of this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input then the computer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> science textbooks are wrong because they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject the definition of a UTM.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (simulator).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I was hoping for more of a yes-or-no type answer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I provide a complete explanation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reasoning behind the answer all those not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understanding these things cannot simply
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baselessly disagree. All disagreement is thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required to have a basis. This way people are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not lead astray by a bunch of baseless
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreement, they see that the disagreement
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has no basis and reject it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So, you need to try to actually provide VALID
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reasoning, starting from ACCEPTED definition.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You just make wild claims based on your own
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understanding of the words.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since you don't even attempt to actually DEFINE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the words, no one can help you with your logic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, Most of the things you are talking about
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HAVE well defined meanings, so you either need
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to use that meaning, or you really need to give
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your idea a new name (maybe basd on the common
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name with a modifier).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thus, if you definition of "Halting" isn't the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same as the accepted definition, you can call it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PO-Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Of course the problem with this is it makes it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clear that you are talking about the PO-Halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Problem, with a PO-Halting Decider, so you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> counter example doesn't affect the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting Problem, so it is clear you haven't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proven what you claim to have proven.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It's not immediately obvious, but it can be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proved that the definition is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-contradictory. You're not disputing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that proof?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You haven't actually given a proof, since you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are clearly using altered definition that you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aren't providing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You reject the notion of a UTM so you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> starting with an incorrect basis.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have done no such thing. UTM's exist, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTM(P,d) by DEFINITION gives the exact same result
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as P(d).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When you get a glass of water and dump it on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> floor you cannot truthfully deny that the floor is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wet.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And I haven't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When the correct and complete simulation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input by H(P,P) would have different behavior than
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the direct execution of P(P) this cannot simply be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ignored.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And the correct and complete simulation of the input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H(P,P) Halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fact that the simulation by H(P,P) of its input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never stops running unless H aborts the simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this input is merely another way of saying that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct and complete simulation of this input by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have bad logic there.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is a tautology:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H0((u32)Infinite_Loop));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001102](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001103](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001105](02) ebfe jmp 00001105
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001107](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001108](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00001108]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fact that the simulation by H0(Infinite_Loop) of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its input would never stop running unless H0 aborts the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of this input is merely another way of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> saying that the correct and complete simulation of this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input by H0 never halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Strawman.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fallacy of Proof by Example.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is only a fallacy by proof of example when a single
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> example is not representative of the entire class of all
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such examples.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which it isn't, so FAIL.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You are confusing existential quantification with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universal quantification.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No you are, since you are claiming the rule works for ALL
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inputs (or at least P, which isn't the input you showed it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> worked for).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ∀ simulating halt decider H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ∀ machine description P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Right. ∀, so UNIVERSAL, not EXISTENTIAL, so FAIL.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't seem to know what those words mean.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fact that the correct simulation of any input P to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any simulating halt decider (SHD) H would never stop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running unless this simulation was aborted by this SHD is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely another way of saying that the correct and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> complete simulation of this input by this SHD would never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, not when the input depends on the behavior of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider in the way you are doing it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P was intentionally defined to depend on the behavior of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its decider *NITWIT*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Right, but your "example" didn't, and this dependency is the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> case that breaks your "proof" and definitions.
>>>>>>>>>>>>>>>>>>>>>>>>>>> The correct simulation of the input by H(P,P) is the
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of this input at the same point in the execution
>>>>>>>>>>>>>>>>>>>>>>>>>>> trace where H is invoked.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> (2 + 3) * 5 != 2 + (3 * 5) // order matters.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Red Herring. Simulate(P,P) is ALWAYS the same (for a given P)
>>>>>>>>>>>>>>>>>>>>>>>>>> irrespective of "where" that simulation is done, at least if H
>>>>>>>>>>>>>>>>>>>>>>>>>> is a computation, and if it isn't it can't be a decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Although H must be a computation all sequences of
>>>>>>>>>>>>>>>>>>>>>>>>> configurations that do not halt are not computations**. The
>>>>>>>>>>>>>>>>>>>>>>>>> behavior of H is the same no matter where it is invoked.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Yes, so H(P,P) is ALWAYS the same, to return a 0 in finite time,
>>>>>>>>>>>>>>>>>>>>>>>> by the H you claim to be correct.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The behavior of P need not be (and indeed is not) the same.
>>>>>>>>>>>>>>>>>>>>>>>>> When P is invoked from main its behavior depends on the return
>>>>>>>>>>>>>>>>>>>>>>>>> value of H. When P is correctly simulated by H the return value
>>>>>>>>>>>>>>>>>>>>>>>>> from H is unreachable from every simulated P. This conclusively
>>>>>>>>>>>>>>>>>>>>>>>>> proves that the execution of P from main() and the correct
>>>>>>>>>>>>>>>>>>>>>>>>> simulation of P by H are not computationally equivalent.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Nope, by the construction of P, P will ALWAYS behave the same.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> All of your rebuttals are simply false assumptions and nothing more.
>>>>>>>>>>>>>>>>>>>>>>> I claim that
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> "When P is correctly simulated by H the return value from
>>>>>>>>>>>>>>>>>>>>>>> H is unreachable from every simulated P."
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> SO? There is no requirement that H is able to see the resuts of
>>>>>>>>>>>>>>>>>>>>>> the call inside the input it is simulating.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The ACTUAL behavior of the input to H(P,P) is DEFINED as the
>>>>>>>>>>>>>>>>>>>>>> behavior of P(P) or Simulate(P,P). The fact that H can't determine
>>>>>>>>>>>>>>>>>>>>>> that is H's fault.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Do you disagree that the CORRECT answer is based on the ACTUAL
>>>>>>>>>>>>>>>>>>>>>> BEHAVIOR of the ACUTAL INPUT?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H's inability to determine that is WHY it gets the wrong answer,
>>>>>>>>>>>>>>>>>>>>>> not an excuse for it to do so.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When you claim that I am incorrect it is merely an empty
>>>>>>>>>>>>>>>>>>>>>>> assertion utterly bereft of supporting reasoning.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No, you LITERALLY are making an empty assertion, as you are
>>>>>>>>>>>>>>>>>>>>>> asserting something that never occurs.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> There is NO H that does a complete and correct simulation and
>>>>>>>>>>>>>>>>>>>>>> returns an answer. We can even argue that it doesn't do a correct
>>>>>>>>>>>>>>>>>>>>>> simulation since the last step of the simulation has an error as
>>>>>>>>>>>>>>>>>>>>>> it presumes the wrong behavior of the call to H that it encounter
>>>>>>>>>>>>>>>>>>>>>> (you can debate if this is an incorrect simulation or just unsound
>>>>>>>>>>>>>>>>>>>>>> logic).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A simulating halt decider continues to simulate its input until
>>>>>>>>>>>>>>>>>>>>>>> it correctly matches a correct infinite behavior pattern.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Then why does you H abort too soon, as shown by the fact that the
>>>>>>>>>>>>>>>>>>>>>> complete simulation Simualte(P,P) does halt when H(P,P) returns 0?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Just says that your H doesn't even meet your own definition.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = Hx(x, x);
>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", Hx(Px, Px));
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> In order for me to actually be wrong you must be able to show
>>>>>>>>>>>>>>>>>>>>>>> that some simulating halt decider Hx could be defined such that
>>>>>>>>>>>>>>>>>>>>>>> its correct simulation of its input Px reaches the final state of
>>>>>>>>>>>>>>>>>>>>>>> Px in a finite number of steps.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope. H(P,P) is wrong
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ..then a mistake could be shown, if no mistake can be shown then it
>>>>>>>>>>>>>>>>>>>>> is not wrong.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> And it has been.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Even YOU hav published the correct and complete simuliaton of the
>>>>>>>>>>>>>>>>>>>> input to H(P,P) being the trace of P(P) and Simulate(P,P)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I contend that that no simulating halt decider Hx can be defined
>>>>>>>>>>>>>>>>>>>>> such that its correctly simulated input Px could reach the final
>>>>>>>>>>>>>>>>>>>>> state of this simulated Px in any finite number of steps.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So, that isn't the question.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *I STIPULATE FOR THIS THREAD THAT IS THE QUESTION*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any rebuttal must show all of the steps of exactly how the input to
>>>>>>>>>>>>>>>>>>> Hx(Px,Px) correctly simulated by Hx reaches the final state of Px in
>>>>>>>>>>>>>>>>>>> a finite number of steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ALTERNATIVELY YOU COULD SIMPLY ADMIT THE TRUTH
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You don't get to stipulate the test,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In other words you know that my statement is correct and you are too
>>>>>>>>>>>>>>>>> dishonest to admit it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, shows you don't understand about requirements.
>>>>>>>>>>>>>>> Ultimately, you are a shit for brains fucking idiot because you have admitted unsatisfiable requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is precisely because the requirements are unsatisfiable they amount to nothing other than The bottom/uninhabited type. Falsity.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Bottom_type
>>>>>>>>>>>>>> Nope, given an H, the answer is defined , and computabe if we know that
>>>>>>>>>>>>>> H does return an answer.
>>>>>>>>>>>>> How? There is no H for the pathological P.
>>>>>>>>>>>>> Furthermore because the dependencies of P are unsatisfiable (P requires H) there is also no P.
>>>>>>>>>>>> Because Olcott has defined what he calls H.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, H doesn't meet the requirements, but he claims it does and we are
>>>>>>>>>>>> showing that H is incorrect.
>>>>>>>>>>> But why are you so concerned with showing that H is incorrect; while being so unconcerned by the fact that the requirements are incorrect?
>>>>>>>>>>>
>>>>>>>>>>> The requirements amount to falsify!
>>>>>>>>>> The requirements are correct, BY DEFINITION, they require what they require.
>>>>>>>>> But the requirements require you to violate the principle you cherish so dearly!
>>>>>>>>>
>>>>>>>>> The requirements clash with YOUR principle!
>>>>>>>> What clash?
>>>>>>>>
>>>>>>>> Remember, H isn't a Halt Decider, it is something some CLAIMS
>>>>>>>> (incorrectly) to be a Halt Decider.
>>>>>>> Obviously! Because YOU admitted that Halt Deciders don’t exist!
>>>>>>>
>>>>>>> So what are YOU talking about when you are talking about non-existing entities?!?
>>>>>> Where did I actually talk about a non-existant entity exist?
>>>>> Oracles!
>>>>>
>>>>> Is the set of “correct halting deciders” empty, or do oracles belong to that set ?!?
>>>> Oracles, as I think you are defining it, do not meet the requirement of
>>>> a Correct Halting Decider, because the definition of that says it is a
>>>> Computation, but an Oracle isn't a Computation.
>>> But then your requirements are incoherent!
>>>
>>> The extensional properties of a computational and a non-computational function are indistinguishable!
>>>
>>>> You don't understand that there can be things that we can get answer
>>>> from (but programs can not?)
>>> You don’t understand that any answers we can get - we can also pass onto any program?
>> Nope, not if you aren't a progran, and Oracles aren't programs in the
>> class of programs we are considering.
> We who? I am considering them,
>
>> THis sems to be your fundamental issue, (besides just being an idiot)
>> tnat you system doesn't seem to be able to handle classifiactions correctly.
> You shirt for brains fucking idiot. The whole point of this exercise is to synthesise a classification scheme! From first principles.
>
> Categories don’t exist. Until invented.
>
>> The Halting Problem lives in a Field Called Computation Theory which
>> DEFINES a computation to be based on a finite set of instructions, each
>> of which has a definite defined deterministic operation, and has been
>> applied to a finite set of data.
> If everything was finite all programs would halt. By definition.
>
> You are missing something…

On 9/5/22 10:51 AM, olcott wrote:
> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>> olcott <polcott2@gmail.com> wrote:
>>
>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>> olcott <polcott2@gmail.com> wrote:
>>>>> In every case where the simulation of the input by H would never
>>>>> stop running H aborts its simulation and returns 0.
>>>> Why would a simulation of H() not return a value, once it had done
>>>> the same kind of deduction?
>>>
>>> A simulating halt decider must abort the simulation of every otherwise
>>> non-terminating input. It does this by correctly recognizing
>>> non-terminating behavior patterns.
>>
>> You did not answer my question: if H() always returns a value, why would
>> a simulated H() also not always return a value in the simulation?
>
> I will give you the short answer, the simulated H is never invoked.
>
>> "Because I defined it so" is not a sufficient answer here.
>
>
> A simulating halt decider (SHD) always bases its halt status decision on
> correctly predicting whether or not it must abort the correct simulation
> of its input to prevent the infinite execution of this input.

And thus isn't a correct halt decider as its criterion is different from
the Halting Criteria.

>
> A simulating halt decider that does not abort its simulation of its
> input performs a correct and complete simulation of this input.

Right, and never gives a non-halting answer.

>
> The definition of a UTM says that any correct and complete simulation of
> an input derives the actual behavior of this simulated input.

Right, so a UTM never aborts.

>
> Thus if the correct and complete simulation of an input never reaches
> the final state of this input this means that this input specifies a
> non-halting sequence of instructions.

Right.

>
> The fact that the simulation of this input is aborted does not change
> the fact that this correctly simulated input cannot possibly reach its
> own final state.

Right, but note, your arguments above were looking at a P(P) that called
an H(P,P) that doesn't abort. Once you CHANGE the behavior of H, you
have changed the input, and thus need to re-evaluate.

>
> Once we know that the correctly simulated cannot possibly reach its own
> final state this input can be rejected as non-halting on the basis of
> the definition of non-halting: *never reaches its final state*

Except you did your logic wrong, because you intial assumption that the
simulation never reached a final state was based on assuming that H
never aborts its simulation.

Since it does, the logic is unsound.

When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and thus your
arguement that it doesn't is untrue.

>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> _P()
> [000010f2](01)  55             push ebp
> [000010f3](02)  8bec           mov ebp,esp
> [000010f5](01)  51             push ecx
> [000010f6](03)  8b4508         mov eax,[ebp+08]
> [000010f9](01)  50             push eax       // push P
> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
> [000010fd](01)  51             push ecx       // push P
> [000010fe](05)  e88ffdffff     call 00000e92  // call H
> [00001103](03)  83c408         add esp,+08
> [00001106](03)  8945fc         mov [ebp-04],eax
> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
> [0000110d](02)  7402           jz 00001111
> [0000110f](02)  ebfe           jmp 0000110f
> [00001111](02)  8be5           mov esp,ebp
> [00001113](01)  5d             pop ebp
> [00001114](01)  c3             ret
> Size in bytes:(0035) [00001114]
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> This is what happens if H never aborts the simulation of its input:
> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...

Right, if H never aborts.

>
> When P is correctly simulated by H and H does not abort its simulation
> of P the first 8 instructions of P are simulated endlessly.

Nope, you built that logic on the assumption that H doesn't abort, thus
you can't have H abort.

>
> Because a decider must always halt and a decider must always return that
> same value for the same input every time it is invoked H correctly
> recognizes the infinite behavior pattern of P before P invokes H(P,P)
> for the first time. At this point H aborts its simulation of P and
> rejects p as non-halting.

Nope, unsound logic. You proved that if H doesn't abort the input is
non-halting, but since the input depend on the results of H, changing H
changes the input, thus you can't use the assumption to show what P does
when H aborts and return 0.

>
> *Halting problem proofs refuted on the basis of software engineering* ?
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>
>

Nope You are just proving your stupidity and ignorance, and the fact
that you are a pathological liar.

It will be a good riddance when you go.

On 9/5/2022 10:21 AM, Richard Damon wrote:
>
> On 9/5/22 10:51 AM, olcott wrote:
>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>> olcott <polcott2@gmail.com> wrote:
>>>
>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>> In every case where the simulation of the input by H would never
>>>>>> stop running H aborts its simulation and returns 0.
>>>>> Why would a simulation of H() not return a value, once it had done
>>>>> the same kind of deduction?
>>>>
>>>> A simulating halt decider must abort the simulation of every otherwise
>>>> non-terminating input. It does this by correctly recognizing
>>>> non-terminating behavior patterns.
>>>
>>> You did not answer my question: if H() always returns a value, why would
>>> a simulated H() also not always return a value in the simulation?
>>
>> I will give you the short answer, the simulated H is never invoked.
>>
>>> "Because I defined it so" is not a sufficient answer here.
>>
>>
>> A simulating halt decider (SHD) always bases its halt status decision
>> on correctly predicting whether or not it must abort the correct
>> simulation of its input to prevent the infinite execution of this input.
>
> And thus isn't a correct halt decider as its criterion is different from
> the Halting Criteria.
>
>>
>> A simulating halt decider that does not abort its simulation of its
>> input performs a correct and complete simulation of this input.
>
> Right, and never gives a non-halting answer.
>
>>
>> The definition of a UTM says that any correct and complete simulation
>> of an input derives the actual behavior of this simulated input.
>
> Right, so a UTM never aborts.
>
>>
>> Thus if the correct and complete simulation of an input never reaches
>> the final state of this input this means that this input specifies a
>> non-halting sequence of instructions.
>
> Right.
>
>>
>> The fact that the simulation of this input is aborted does not change
>> the fact that this correctly simulated input cannot possibly reach its
>> own final state.
>
> Right, but note, your arguments above were looking at a P(P) that called
> an H(P,P) that doesn't abort. Once you CHANGE the behavior of H, you
> have changed the input, and thus need to re-evaluate.
>
>>
>> Once we know that the correctly simulated cannot possibly reach its
>> own final state this input can be rejected as non-halting on the basis
>> of the definition of non-halting: *never reaches its final state*
>
> Except you did your logic wrong, because you intial assumption that the
> simulation never reached a final state was based on assuming that H
> never aborts its simulation.
>
> Since it does, the logic is unsound.
>
> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and thus your
> arguement that it doesn't is untrue.
>
>>
>> void P(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> _P()
>> [000010f2](01)  55             push ebp
>> [000010f3](02)  8bec           mov ebp,esp
>> [000010f5](01)  51             push ecx
>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>> [000010f9](01)  50             push eax       // push P
>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>> [000010fd](01)  51             push ecx       // push P
>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>> [00001103](03)  83c408         add esp,+08
>> [00001106](03)  8945fc         mov [ebp-04],eax
>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>> [0000110d](02)  7402           jz 00001111
>> [0000110f](02)  ebfe           jmp 0000110f
>> [00001111](02)  8be5           mov esp,ebp
>> [00001113](01)  5d             pop ebp
>> [00001114](01)  c3             ret
>> Size in bytes:(0035) [00001114]
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(P, P));
>> }
>>
>> This is what happens if H never aborts the simulation of its input:
>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>> (b) that simulates P(P) that calls a simulated H(P,P)
>> (c) that simulates P(P) that calls a simulated H(P,P)
>> (d) that simulates P(P) that calls a simulated H(P,P)...
>
> Right, if H never aborts.
>
>>
>> When P is correctly simulated by H and H does not abort its simulation
>> of P the first 8 instructions of P are simulated endlessly.
>
> Nope, you built that logic on the assumption that H doesn't abort, thus
> you can't have H abort.

The only job of H is to correctly determine whether or not its correctly
simulated input can possibly reach the final state of this input.

void Px(ptr x)
{ int Halt_Status = Hx(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", Hx(Px, Px));
}

*EXISTENTIAL QUANTIFICATION PROVES MY POINT*
No function Hx can be defined such that its correct simulation of its
input Px would reach the final state of this simulated Px in any finite
number of steps.

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

On 9/5/22 11:56 AM, olcott wrote:
> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>
>> On 9/5/22 10:51 AM, olcott wrote:
>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>> olcott <polcott2@gmail.com> wrote:
>>>>
>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>> In every case where the simulation of the input by H would never
>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>> Why would a simulation of H() not return a value, once it had done
>>>>>> the same kind of deduction?
>>>>>
>>>>> A simulating halt decider must abort the simulation of every otherwise
>>>>> non-terminating input. It does this by correctly recognizing
>>>>> non-terminating behavior patterns.
>>>>
>>>> You did not answer my question: if H() always returns a value, why
>>>> would
>>>> a simulated H() also not always return a value in the simulation?
>>>
>>> I will give you the short answer, the simulated H is never invoked.
>>>
>>>> "Because I defined it so" is not a sufficient answer here.
>>>
>>>
>>> A simulating halt decider (SHD) always bases its halt status decision
>>> on correctly predicting whether or not it must abort the correct
>>> simulation of its input to prevent the infinite execution of this input.
>>
>> And thus isn't a correct halt decider as its criterion is different
>> from the Halting Criteria.
>>
>>>
>>> A simulating halt decider that does not abort its simulation of its
>>> input performs a correct and complete simulation of this input.
>>
>> Right, and never gives a non-halting answer.
>>
>>>
>>> The definition of a UTM says that any correct and complete simulation
>>> of an input derives the actual behavior of this simulated input.
>>
>> Right, so a UTM never aborts.
>>
>>>
>>> Thus if the correct and complete simulation of an input never reaches
>>> the final state of this input this means that this input specifies a
>>> non-halting sequence of instructions.
>>
>> Right.
>>
>>>
>>> The fact that the simulation of this input is aborted does not change
>>> the fact that this correctly simulated input cannot possibly reach
>>> its own final state.
>>
>> Right, but note, your arguments above were looking at a P(P) that
>> called an H(P,P) that doesn't abort. Once you CHANGE the behavior of
>> H, you have changed the input, and thus need to re-evaluate.
>>
>>>
>>> Once we know that the correctly simulated cannot possibly reach its
>>> own final state this input can be rejected as non-halting on the
>>> basis of the definition of non-halting: *never reaches its final state*
>>
>> Except you did your logic wrong, because you intial assumption that
>> the simulation never reached a final state was based on assuming that
>> H never aborts its simulation.
>>
>> Since it does, the logic is unsound.
>>
>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and thus
>> your arguement that it doesn't is untrue.
>>
>>>
>>> void P(ptr x)
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> _P()
>>> [000010f2](01)  55             push ebp
>>> [000010f3](02)  8bec           mov ebp,esp
>>> [000010f5](01)  51             push ecx
>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>> [000010f9](01)  50             push eax       // push P
>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>> [000010fd](01)  51             push ecx       // push P
>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>> [00001103](03)  83c408         add esp,+08
>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>> [0000110d](02)  7402           jz 00001111
>>> [0000110f](02)  ebfe           jmp 0000110f
>>> [00001111](02)  8be5           mov esp,ebp
>>> [00001113](01)  5d             pop ebp
>>> [00001114](01)  c3             ret
>>> Size in bytes:(0035) [00001114]
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> This is what happens if H never aborts the simulation of its input:
>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>
>> Right, if H never aborts.
>>
>>>
>>> When P is correctly simulated by H and H does not abort its
>>> simulation of P the first 8 instructions of P are simulated endlessly.
>>
>> Nope, you built that logic on the assumption that H doesn't abort,
>> thus you can't have H abort.
>
> The only job of H is to correctly determine whether or not its correctly
> simulated input can possibly reach the final state of this input.

Nope, it is to determine if *THE* correctly and completely simulated
input will reach a final state or not. Not *ITS*, because if H aborts
its simulation, that definition is INCORRECT because it doesn't match
the ACTAUL defintion of Halting.

That is because it is different than determining if a DIFFERENT version
of the decider, when that difference changes the input, would be halting
or not.

Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear meaning of
your words says that Hx was wrong.

>
> void Px(ptr x)
> {
>  int Halt_Status = Hx(x, x);
>  if (Halt_Status)
>    HERE: goto HERE;
>  return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", Hx(Px, Px));
> }
>
> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
> No function Hx can be defined such that its correct simulation of its
> input Px would reach the final state of this simulated Px in any finite
> number of steps.
>

So. UTM(Hx,Hx) does Halt, so the correct and complete simulation halts,
so the correct answer is Halting.

PERIOD.

All you have done is shown that Hx is a correct POOP decider.

On 9/5/2022 11:01 AM, Richard Damon wrote:
> On 9/5/22 11:56 AM, olcott wrote:
>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>
>>> On 9/5/22 10:51 AM, olcott wrote:
>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>
>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>> In every case where the simulation of the input by H would never
>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>> Why would a simulation of H() not return a value, once it had done
>>>>>>> the same kind of deduction?
>>>>>>
>>>>>> A simulating halt decider must abort the simulation of every
>>>>>> otherwise
>>>>>> non-terminating input. It does this by correctly recognizing
>>>>>> non-terminating behavior patterns.
>>>>>
>>>>> You did not answer my question: if H() always returns a value, why
>>>>> would
>>>>> a simulated H() also not always return a value in the simulation?
>>>>
>>>> I will give you the short answer, the simulated H is never invoked.
>>>>
>>>>> "Because I defined it so" is not a sufficient answer here.
>>>>
>>>>
>>>> A simulating halt decider (SHD) always bases its halt status
>>>> decision on correctly predicting whether or not it must abort the
>>>> correct simulation of its input to prevent the infinite execution of
>>>> this input.
>>>
>>> And thus isn't a correct halt decider as its criterion is different
>>> from the Halting Criteria.
>>>
>>>>
>>>> A simulating halt decider that does not abort its simulation of its
>>>> input performs a correct and complete simulation of this input.
>>>
>>> Right, and never gives a non-halting answer.
>>>
>>>>
>>>> The definition of a UTM says that any correct and complete
>>>> simulation of an input derives the actual behavior of this simulated
>>>> input.
>>>
>>> Right, so a UTM never aborts.
>>>
>>>>
>>>> Thus if the correct and complete simulation of an input never
>>>> reaches the final state of this input this means that this input
>>>> specifies a non-halting sequence of instructions.
>>>
>>> Right.
>>>
>>>>
>>>> The fact that the simulation of this input is aborted does not
>>>> change the fact that this correctly simulated input cannot possibly
>>>> reach its own final state.
>>>
>>> Right, but note, your arguments above were looking at a P(P) that
>>> called an H(P,P) that doesn't abort. Once you CHANGE the behavior of
>>> H, you have changed the input, and thus need to re-evaluate.
>>>
>>>>
>>>> Once we know that the correctly simulated cannot possibly reach its
>>>> own final state this input can be rejected as non-halting on the
>>>> basis of the definition of non-halting: *never reaches its final state*
>>>
>>> Except you did your logic wrong, because you intial assumption that
>>> the simulation never reached a final state was based on assuming that
>>> H never aborts its simulation.
>>>
>>> Since it does, the logic is unsound.
>>>
>>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and thus
>>> your arguement that it doesn't is untrue.
>>>
>>>>
>>>> void P(ptr x)
>>>> {
>>>>    int Halt_Status = H(x, x);
>>>>    if (Halt_Status)
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> _P()
>>>> [000010f2](01)  55             push ebp
>>>> [000010f3](02)  8bec           mov ebp,esp
>>>> [000010f5](01)  51             push ecx
>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>> [000010f9](01)  50             push eax       // push P
>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>> [000010fd](01)  51             push ecx       // push P
>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>> [00001103](03)  83c408         add esp,+08
>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>> [0000110d](02)  7402           jz 00001111
>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>> [00001111](02)  8be5           mov esp,ebp
>>>> [00001113](01)  5d             pop ebp
>>>> [00001114](01)  c3             ret
>>>> Size in bytes:(0035) [00001114]
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> This is what happens if H never aborts the simulation of its input:
>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>
>>> Right, if H never aborts.
>>>
>>>>
>>>> When P is correctly simulated by H and H does not abort its
>>>> simulation of P the first 8 instructions of P are simulated endlessly.
>>>
>>> Nope, you built that logic on the assumption that H doesn't abort,
>>> thus you can't have H abort.
>>
>> The only job of H is to correctly determine whether or not its
>> correctly simulated input can possibly reach the final state of this
>> input.
>
> Nope, it is to determine if *THE* correctly and completely simulated
> input will reach a final state or not. Not *ITS*, because if H aborts
> its simulation, that definition is INCORRECT because it doesn't match
> the ACTAUL defintion of Halting.
>
> That is because it is different than determining if a DIFFERENT version
> of the decider, when that difference changes the input, would be halting
> or not.
>
> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear meaning of
> your words says that Hx was wrong.
>
>>
>> void Px(ptr x)
>> {
>>   int Halt_Status = Hx(x, x);
>>   if (Halt_Status)
>>     HERE: goto HERE;
>>   return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", Hx(Px, Px));
>> }
>>
>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>> No function Hx can be defined such that its correct simulation of its
>> input Px would reach the final state of this simulated Px in any
>> finite number of steps.
>>
>
> So. UTM(Hx,Hx) does Halt, so the correct and complete simulation halts,
> so the correct answer is Halting.

*You are not paying attention*
*Your boiler plate reply does not apply to what I just said*

*The above refers to the infinite set of Hx/Px pairs where Hx*
*correctly simulates its input Px, some halt others do not*

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

On 9/5/22 3:34 PM, olcott wrote:
> On 9/5/2022 11:01 AM, Richard Damon wrote:
>> On 9/5/22 11:56 AM, olcott wrote:
>>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>>
>>>> On 9/5/22 10:51 AM, olcott wrote:
>>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>
>>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>> In every case where the simulation of the input by H would never
>>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>>> Why would a simulation of H() not return a value, once it had done
>>>>>>>> the same kind of deduction?
>>>>>>>
>>>>>>> A simulating halt decider must abort the simulation of every
>>>>>>> otherwise
>>>>>>> non-terminating input. It does this by correctly recognizing
>>>>>>> non-terminating behavior patterns.
>>>>>>
>>>>>> You did not answer my question: if H() always returns a value, why
>>>>>> would
>>>>>> a simulated H() also not always return a value in the simulation?
>>>>>
>>>>> I will give you the short answer, the simulated H is never invoked.
>>>>>
>>>>>> "Because I defined it so" is not a sufficient answer here.
>>>>>
>>>>>
>>>>> A simulating halt decider (SHD) always bases its halt status
>>>>> decision on correctly predicting whether or not it must abort the
>>>>> correct simulation of its input to prevent the infinite execution
>>>>> of this input.
>>>>
>>>> And thus isn't a correct halt decider as its criterion is different
>>>> from the Halting Criteria.
>>>>
>>>>>
>>>>> A simulating halt decider that does not abort its simulation of its
>>>>> input performs a correct and complete simulation of this input.
>>>>
>>>> Right, and never gives a non-halting answer.
>>>>
>>>>>
>>>>> The definition of a UTM says that any correct and complete
>>>>> simulation of an input derives the actual behavior of this
>>>>> simulated input.
>>>>
>>>> Right, so a UTM never aborts.
>>>>
>>>>>
>>>>> Thus if the correct and complete simulation of an input never
>>>>> reaches the final state of this input this means that this input
>>>>> specifies a non-halting sequence of instructions.
>>>>
>>>> Right.
>>>>
>>>>>
>>>>> The fact that the simulation of this input is aborted does not
>>>>> change the fact that this correctly simulated input cannot possibly
>>>>> reach its own final state.
>>>>
>>>> Right, but note, your arguments above were looking at a P(P) that
>>>> called an H(P,P) that doesn't abort. Once you CHANGE the behavior of
>>>> H, you have changed the input, and thus need to re-evaluate.
>>>>
>>>>>
>>>>> Once we know that the correctly simulated cannot possibly reach its
>>>>> own final state this input can be rejected as non-halting on the
>>>>> basis of the definition of non-halting: *never reaches its final
>>>>> state*
>>>>
>>>> Except you did your logic wrong, because you intial assumption that
>>>> the simulation never reached a final state was based on assuming
>>>> that H never aborts its simulation.
>>>>
>>>> Since it does, the logic is unsound.
>>>>
>>>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and thus
>>>> your arguement that it doesn't is untrue.
>>>>
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    int Halt_Status = H(x, x);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> _P()
>>>>> [000010f2](01)  55             push ebp
>>>>> [000010f3](02)  8bec           mov ebp,esp
>>>>> [000010f5](01)  51             push ecx
>>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>>> [000010f9](01)  50             push eax       // push P
>>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>>> [000010fd](01)  51             push ecx       // push P
>>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>>> [00001103](03)  83c408         add esp,+08
>>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>>> [0000110d](02)  7402           jz 00001111
>>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>>> [00001111](02)  8be5           mov esp,ebp
>>>>> [00001113](01)  5d             pop ebp
>>>>> [00001114](01)  c3             ret
>>>>> Size in bytes:(0035) [00001114]
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> This is what happens if H never aborts the simulation of its input:
>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>
>>>> Right, if H never aborts.
>>>>
>>>>>
>>>>> When P is correctly simulated by H and H does not abort its
>>>>> simulation of P the first 8 instructions of P are simulated endlessly.
>>>>
>>>> Nope, you built that logic on the assumption that H doesn't abort,
>>>> thus you can't have H abort.
>>>
>>> The only job of H is to correctly determine whether or not its
>>> correctly simulated input can possibly reach the final state of this
>>> input.
>>
>> Nope, it is to determine if *THE* correctly and completely simulated
>> input will reach a final state or not. Not *ITS*, because if H aborts
>> its simulation, that definition is INCORRECT because it doesn't match
>> the ACTAUL defintion of Halting.
>>
>> That is because it is different than determining if a DIFFERENT
>> version of the decider, when that difference changes the input, would
>> be halting or not.
>>
>> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear meaning of
>> your words says that Hx was wrong.
>>
>>>
>>> void Px(ptr x)
>>> {
>>>   int Halt_Status = Hx(x, x);
>>>   if (Halt_Status)
>>>     HERE: goto HERE;
>>>   return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", Hx(Px, Px));
>>> }
>>>
>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>> No function Hx can be defined such that its correct simulation of its
>>> input Px would reach the final state of this simulated Px in any
>>> finite number of steps.
>>>
>>
>> So. UTM(Hx,Hx) does Halt, so the correct and complete simulation
>> halts, so the correct answer is Halting.
>
> *You are not paying attention*
> *Your boiler plate reply does not apply to what I just said*
>
> *The above refers to the infinite set of Hx/Px pairs where Hx*
> *correctly simulates its input Px, some halt others do not*
>

So, are you saying that UTM(Px,Px) doesn't ever halt when Hx(Px,Px)
returns 0?

If so, what is the rules that Hx actually uses, and then show a trace of
what the UTM woule do.

On 9/5/2022 2:48 PM, Richard Damon wrote:
>
> On 9/5/22 3:34 PM, olcott wrote:
>> On 9/5/2022 11:01 AM, Richard Damon wrote:
>>> On 9/5/22 11:56 AM, olcott wrote:
>>>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>>>
>>>>> On 9/5/22 10:51 AM, olcott wrote:
>>>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>> In every case where the simulation of the input by H would never
>>>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>>>> Why would a simulation of H() not return a value, once it had done
>>>>>>>>> the same kind of deduction?
>>>>>>>>
>>>>>>>> A simulating halt decider must abort the simulation of every
>>>>>>>> otherwise
>>>>>>>> non-terminating input. It does this by correctly recognizing
>>>>>>>> non-terminating behavior patterns.
>>>>>>>
>>>>>>> You did not answer my question: if H() always returns a value,
>>>>>>> why would
>>>>>>> a simulated H() also not always return a value in the simulation?
>>>>>>
>>>>>> I will give you the short answer, the simulated H is never invoked.
>>>>>>
>>>>>>> "Because I defined it so" is not a sufficient answer here.
>>>>>>
>>>>>>
>>>>>> A simulating halt decider (SHD) always bases its halt status
>>>>>> decision on correctly predicting whether or not it must abort the
>>>>>> correct simulation of its input to prevent the infinite execution
>>>>>> of this input.
>>>>>
>>>>> And thus isn't a correct halt decider as its criterion is different
>>>>> from the Halting Criteria.
>>>>>
>>>>>>
>>>>>> A simulating halt decider that does not abort its simulation of
>>>>>> its input performs a correct and complete simulation of this input.
>>>>>
>>>>> Right, and never gives a non-halting answer.
>>>>>
>>>>>>
>>>>>> The definition of a UTM says that any correct and complete
>>>>>> simulation of an input derives the actual behavior of this
>>>>>> simulated input.
>>>>>
>>>>> Right, so a UTM never aborts.
>>>>>
>>>>>>
>>>>>> Thus if the correct and complete simulation of an input never
>>>>>> reaches the final state of this input this means that this input
>>>>>> specifies a non-halting sequence of instructions.
>>>>>
>>>>> Right.
>>>>>
>>>>>>
>>>>>> The fact that the simulation of this input is aborted does not
>>>>>> change the fact that this correctly simulated input cannot
>>>>>> possibly reach its own final state.
>>>>>
>>>>> Right, but note, your arguments above were looking at a P(P) that
>>>>> called an H(P,P) that doesn't abort. Once you CHANGE the behavior
>>>>> of H, you have changed the input, and thus need to re-evaluate.
>>>>>
>>>>>>
>>>>>> Once we know that the correctly simulated cannot possibly reach
>>>>>> its own final state this input can be rejected as non-halting on
>>>>>> the basis of the definition of non-halting: *never reaches its
>>>>>> final state*
>>>>>
>>>>> Except you did your logic wrong, because you intial assumption that
>>>>> the simulation never reached a final state was based on assuming
>>>>> that H never aborts its simulation.
>>>>>
>>>>> Since it does, the logic is unsound.
>>>>>
>>>>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and thus
>>>>> your arguement that it doesn't is untrue.
>>>>>
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>>    int Halt_Status = H(x, x);
>>>>>>    if (Halt_Status)
>>>>>>      HERE: goto HERE;
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> _P()
>>>>>> [000010f2](01)  55             push ebp
>>>>>> [000010f3](02)  8bec           mov ebp,esp
>>>>>> [000010f5](01)  51             push ecx
>>>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>>>> [000010f9](01)  50             push eax       // push P
>>>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>>>> [000010fd](01)  51             push ecx       // push P
>>>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>>>> [00001103](03)  83c408         add esp,+08
>>>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>>>> [0000110d](02)  7402           jz 00001111
>>>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>>>> [00001111](02)  8be5           mov esp,ebp
>>>>>> [00001113](01)  5d             pop ebp
>>>>>> [00001114](01)  c3             ret
>>>>>> Size in bytes:(0035) [00001114]
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>>
>>>>>> This is what happens if H never aborts the simulation of its input:
>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>
>>>>> Right, if H never aborts.
>>>>>
>>>>>>
>>>>>> When P is correctly simulated by H and H does not abort its
>>>>>> simulation of P the first 8 instructions of P are simulated
>>>>>> endlessly.
>>>>>
>>>>> Nope, you built that logic on the assumption that H doesn't abort,
>>>>> thus you can't have H abort.
>>>>
>>>> The only job of H is to correctly determine whether or not its
>>>> correctly simulated input can possibly reach the final state of this
>>>> input.
>>>
>>> Nope, it is to determine if *THE* correctly and completely simulated
>>> input will reach a final state or not. Not *ITS*, because if H aborts
>>> its simulation, that definition is INCORRECT because it doesn't match
>>> the ACTAUL defintion of Halting.
>>>
>>> That is because it is different than determining if a DIFFERENT
>>> version of the decider, when that difference changes the input, would
>>> be halting or not.
>>>
>>> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear meaning of
>>> your words says that Hx was wrong.
>>>
>>>>
>>>> void Px(ptr x)
>>>> {
>>>>   int Halt_Status = Hx(x, x);
>>>>   if (Halt_Status)
>>>>     HERE: goto HERE;
>>>>   return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", Hx(Px, Px));
>>>> }
>>>>
>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>> No function Hx can be defined such that its correct simulation of
>>>> its input Px would reach the final state of this simulated Px in any
>>>> finite number of steps.
>>>>
>>>
>>> So. UTM(Hx,Hx) does Halt, so the correct and complete simulation
>>> halts, so the correct answer is Halting.
>>
>> *You are not paying attention*
>> *Your boiler plate reply does not apply to what I just said*
>>
>> *The above refers to the infinite set of Hx/Px pairs where Hx*
>> *correctly simulates its input Px, some halt others do not*
>>
>
> So, are you saying that UTM(Px,Px) doesn't ever halt when Hx(Px,Px)
> returns 0?
>
*No I specifically said that I am not saying that*
*Hx/Px specifies an infinite set of pairs some halt others do not*

On 9/5/22 3:52 PM, olcott wrote:
> On 9/5/2022 2:48 PM, Richard Damon wrote:
>>
>> On 9/5/22 3:34 PM, olcott wrote:
>>> On 9/5/2022 11:01 AM, Richard Damon wrote:
>>>> On 9/5/22 11:56 AM, olcott wrote:
>>>>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/5/22 10:51 AM, olcott wrote:
>>>>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>> In every case where the simulation of the input by H would never
>>>>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>>>>> Why would a simulation of H() not return a value, once it had
>>>>>>>>>> done
>>>>>>>>>> the same kind of deduction?
>>>>>>>>>
>>>>>>>>> A simulating halt decider must abort the simulation of every
>>>>>>>>> otherwise
>>>>>>>>> non-terminating input. It does this by correctly recognizing
>>>>>>>>> non-terminating behavior patterns.
>>>>>>>>
>>>>>>>> You did not answer my question: if H() always returns a value,
>>>>>>>> why would
>>>>>>>> a simulated H() also not always return a value in the simulation?
>>>>>>>
>>>>>>> I will give you the short answer, the simulated H is never invoked.
>>>>>>>
>>>>>>>> "Because I defined it so" is not a sufficient answer here.
>>>>>>>
>>>>>>>
>>>>>>> A simulating halt decider (SHD) always bases its halt status
>>>>>>> decision on correctly predicting whether or not it must abort the
>>>>>>> correct simulation of its input to prevent the infinite execution
>>>>>>> of this input.
>>>>>>
>>>>>> And thus isn't a correct halt decider as its criterion is
>>>>>> different from the Halting Criteria.
>>>>>>
>>>>>>>
>>>>>>> A simulating halt decider that does not abort its simulation of
>>>>>>> its input performs a correct and complete simulation of this input.
>>>>>>
>>>>>> Right, and never gives a non-halting answer.
>>>>>>
>>>>>>>
>>>>>>> The definition of a UTM says that any correct and complete
>>>>>>> simulation of an input derives the actual behavior of this
>>>>>>> simulated input.
>>>>>>
>>>>>> Right, so a UTM never aborts.
>>>>>>
>>>>>>>
>>>>>>> Thus if the correct and complete simulation of an input never
>>>>>>> reaches the final state of this input this means that this input
>>>>>>> specifies a non-halting sequence of instructions.
>>>>>>
>>>>>> Right.
>>>>>>
>>>>>>>
>>>>>>> The fact that the simulation of this input is aborted does not
>>>>>>> change the fact that this correctly simulated input cannot
>>>>>>> possibly reach its own final state.
>>>>>>
>>>>>> Right, but note, your arguments above were looking at a P(P) that
>>>>>> called an H(P,P) that doesn't abort. Once you CHANGE the behavior
>>>>>> of H, you have changed the input, and thus need to re-evaluate.
>>>>>>
>>>>>>>
>>>>>>> Once we know that the correctly simulated cannot possibly reach
>>>>>>> its own final state this input can be rejected as non-halting on
>>>>>>> the basis of the definition of non-halting: *never reaches its
>>>>>>> final state*
>>>>>>
>>>>>> Except you did your logic wrong, because you intial assumption
>>>>>> that the simulation never reached a final state was based on
>>>>>> assuming that H never aborts its simulation.
>>>>>>
>>>>>> Since it does, the logic is unsound.
>>>>>>
>>>>>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and thus
>>>>>> your arguement that it doesn't is untrue.
>>>>>>
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>    if (Halt_Status)
>>>>>>>      HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [000010f2](01)  55             push ebp
>>>>>>> [000010f3](02)  8bec           mov ebp,esp
>>>>>>> [000010f5](01)  51             push ecx
>>>>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>>>>> [000010f9](01)  50             push eax       // push P
>>>>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>> [000010fd](01)  51             push ecx       // push P
>>>>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>>>>> [00001103](03)  83c408         add esp,+08
>>>>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>>>>> [0000110d](02)  7402           jz 00001111
>>>>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>>>>> [00001111](02)  8be5           mov esp,ebp
>>>>>>> [00001113](01)  5d             pop ebp
>>>>>>> [00001114](01)  c3             ret
>>>>>>> Size in bytes:(0035) [00001114]
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>> }
>>>>>>>
>>>>>>> This is what happens if H never aborts the simulation of its input:
>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>
>>>>>> Right, if H never aborts.
>>>>>>
>>>>>>>
>>>>>>> When P is correctly simulated by H and H does not abort its
>>>>>>> simulation of P the first 8 instructions of P are simulated
>>>>>>> endlessly.
>>>>>>
>>>>>> Nope, you built that logic on the assumption that H doesn't abort,
>>>>>> thus you can't have H abort.
>>>>>
>>>>> The only job of H is to correctly determine whether or not its
>>>>> correctly simulated input can possibly reach the final state of
>>>>> this input.
>>>>
>>>> Nope, it is to determine if *THE* correctly and completely simulated
>>>> input will reach a final state or not. Not *ITS*, because if H
>>>> aborts its simulation, that definition is INCORRECT because it
>>>> doesn't match the ACTAUL defintion of Halting.
>>>>
>>>> That is because it is different than determining if a DIFFERENT
>>>> version of the decider, when that difference changes the input,
>>>> would be halting or not.
>>>>
>>>> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear meaning of
>>>> your words says that Hx was wrong.
>>>>
>>>>>
>>>>> void Px(ptr x)
>>>>> {
>>>>>   int Halt_Status = Hx(x, x);
>>>>>   if (Halt_Status)
>>>>>     HERE: goto HERE;
>>>>>   return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", Hx(Px, Px));
>>>>> }
>>>>>
>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>> No function Hx can be defined such that its correct simulation of
>>>>> its input Px would reach the final state of this simulated Px in
>>>>> any finite number of steps.
>>>>>
>>>>
>>>> So. UTM(Hx,Hx) does Halt, so the correct and complete simulation
>>>> halts, so the correct answer is Halting.
>>>
>>> *You are not paying attention*
>>> *Your boiler plate reply does not apply to what I just said*
>>>
>>> *The above refers to the infinite set of Hx/Px pairs where Hx*
>>> *correctly simulates its input Px, some halt others do not*
>>>
>>
>> So, are you saying that UTM(Px,Px) doesn't ever halt when Hx(Px,Px)
>> returns 0?
>>
> *No I specifically said that I am not saying that*
> *Hx/Px specifies an infinite set of pairs some halt others do not*
>
> The one thing that is the same across *ALL* of these pairs is that the
> input to Hx(Px,Px) correctly simulated by Hx never reaches the final
> state of Px.
>

On 9/5/2022 3:11 PM, Richard Damon wrote:
>
> On 9/5/22 3:52 PM, olcott wrote:
>> On 9/5/2022 2:48 PM, Richard Damon wrote:
>>>
>>> On 9/5/22 3:34 PM, olcott wrote:
>>>> On 9/5/2022 11:01 AM, Richard Damon wrote:
>>>>> On 9/5/22 11:56 AM, olcott wrote:
>>>>>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/5/22 10:51 AM, olcott wrote:
>>>>>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>> In every case where the simulation of the input by H would
>>>>>>>>>>>> never
>>>>>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>>>>>> Why would a simulation of H() not return a value, once it had
>>>>>>>>>>> done
>>>>>>>>>>> the same kind of deduction?
>>>>>>>>>>
>>>>>>>>>> A simulating halt decider must abort the simulation of every
>>>>>>>>>> otherwise
>>>>>>>>>> non-terminating input. It does this by correctly recognizing
>>>>>>>>>> non-terminating behavior patterns.
>>>>>>>>>
>>>>>>>>> You did not answer my question: if H() always returns a value,
>>>>>>>>> why would
>>>>>>>>> a simulated H() also not always return a value in the simulation?
>>>>>>>>
>>>>>>>> I will give you the short answer, the simulated H is never invoked.
>>>>>>>>
>>>>>>>>> "Because I defined it so" is not a sufficient answer here.
>>>>>>>>
>>>>>>>>
>>>>>>>> A simulating halt decider (SHD) always bases its halt status
>>>>>>>> decision on correctly predicting whether or not it must abort
>>>>>>>> the correct simulation of its input to prevent the infinite
>>>>>>>> execution of this input.
>>>>>>>
>>>>>>> And thus isn't a correct halt decider as its criterion is
>>>>>>> different from the Halting Criteria.
>>>>>>>
>>>>>>>>
>>>>>>>> A simulating halt decider that does not abort its simulation of
>>>>>>>> its input performs a correct and complete simulation of this input.
>>>>>>>
>>>>>>> Right, and never gives a non-halting answer.
>>>>>>>
>>>>>>>>
>>>>>>>> The definition of a UTM says that any correct and complete
>>>>>>>> simulation of an input derives the actual behavior of this
>>>>>>>> simulated input.
>>>>>>>
>>>>>>> Right, so a UTM never aborts.
>>>>>>>
>>>>>>>>
>>>>>>>> Thus if the correct and complete simulation of an input never
>>>>>>>> reaches the final state of this input this means that this input
>>>>>>>> specifies a non-halting sequence of instructions.
>>>>>>>
>>>>>>> Right.
>>>>>>>
>>>>>>>>
>>>>>>>> The fact that the simulation of this input is aborted does not
>>>>>>>> change the fact that this correctly simulated input cannot
>>>>>>>> possibly reach its own final state.
>>>>>>>
>>>>>>> Right, but note, your arguments above were looking at a P(P) that
>>>>>>> called an H(P,P) that doesn't abort. Once you CHANGE the behavior
>>>>>>> of H, you have changed the input, and thus need to re-evaluate.
>>>>>>>
>>>>>>>>
>>>>>>>> Once we know that the correctly simulated cannot possibly reach
>>>>>>>> its own final state this input can be rejected as non-halting on
>>>>>>>> the basis of the definition of non-halting: *never reaches its
>>>>>>>> final state*
>>>>>>>
>>>>>>> Except you did your logic wrong, because you intial assumption
>>>>>>> that the simulation never reached a final state was based on
>>>>>>> assuming that H never aborts its simulation.
>>>>>>>
>>>>>>> Since it does, the logic is unsound.
>>>>>>>
>>>>>>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and
>>>>>>> thus your arguement that it doesn't is untrue.
>>>>>>>
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>    if (Halt_Status)
>>>>>>>>      HERE: goto HERE;
>>>>>>>>    return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [000010f2](01)  55             push ebp
>>>>>>>> [000010f3](02)  8bec           mov ebp,esp
>>>>>>>> [000010f5](01)  51             push ecx
>>>>>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>>>>>> [000010f9](01)  50             push eax       // push P
>>>>>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>> [000010fd](01)  51             push ecx       // push P
>>>>>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>>>>>> [00001103](03)  83c408         add esp,+08
>>>>>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>>>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>>>>>> [0000110d](02)  7402           jz 00001111
>>>>>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>>>>>> [00001111](02)  8be5           mov esp,ebp
>>>>>>>> [00001113](01)  5d             pop ebp
>>>>>>>> [00001114](01)  c3             ret
>>>>>>>> Size in bytes:(0035) [00001114]
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> This is what happens if H never aborts the simulation of its input:
>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>
>>>>>>> Right, if H never aborts.
>>>>>>>
>>>>>>>>
>>>>>>>> When P is correctly simulated by H and H does not abort its
>>>>>>>> simulation of P the first 8 instructions of P are simulated
>>>>>>>> endlessly.
>>>>>>>
>>>>>>> Nope, you built that logic on the assumption that H doesn't
>>>>>>> abort, thus you can't have H abort.
>>>>>>
>>>>>> The only job of H is to correctly determine whether or not its
>>>>>> correctly simulated input can possibly reach the final state of
>>>>>> this input.
>>>>>
>>>>> Nope, it is to determine if *THE* correctly and completely
>>>>> simulated input will reach a final state or not. Not *ITS*, because
>>>>> if H aborts its simulation, that definition is INCORRECT because it
>>>>> doesn't match the ACTAUL defintion of Halting.
>>>>>
>>>>> That is because it is different than determining if a DIFFERENT
>>>>> version of the decider, when that difference changes the input,
>>>>> would be halting or not.
>>>>>
>>>>> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear meaning
>>>>> of your words says that Hx was wrong.
>>>>>
>>>>>>
>>>>>> void Px(ptr x)
>>>>>> {
>>>>>>   int Halt_Status = Hx(x, x);
>>>>>>   if (Halt_Status)
>>>>>>     HERE: goto HERE;
>>>>>>   return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ", Hx(Px, Px));
>>>>>> }
>>>>>>
>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>> No function Hx can be defined such that its correct simulation of
>>>>>> its input Px would reach the final state of this simulated Px in
>>>>>> any finite number of steps.
>>>>>>
>>>>>
>>>>> So. UTM(Hx,Hx) does Halt, so the correct and complete simulation
>>>>> halts, so the correct answer is Halting.
>>>>
>>>> *You are not paying attention*
>>>> *Your boiler plate reply does not apply to what I just said*
>>>>
>>>> *The above refers to the infinite set of Hx/Px pairs where Hx*
>>>> *correctly simulates its input Px, some halt others do not*
>>>>
>>>
>>> So, are you saying that UTM(Px,Px) doesn't ever halt when Hx(Px,Px)
>>> returns 0?
>>>
>> *No I specifically said that I am not saying that*
>> *Hx/Px specifies an infinite set of pairs some halt others do not*
>>
>> The one thing that is the same across *ALL* of these pairs is that the
>> input to Hx(Px,Px) correctly simulated by Hx never reaches the final
>> state of Px.
>>
>
> So, are you thus asserting that Hx is NOT a Halt Decider?

On 9/5/22 4:20 PM, olcott wrote:
> On 9/5/2022 3:11 PM, Richard Damon wrote:
>>
>> On 9/5/22 3:52 PM, olcott wrote:
>>> On 9/5/2022 2:48 PM, Richard Damon wrote:
>>>>
>>>> On 9/5/22 3:34 PM, olcott wrote:
>>>>> On 9/5/2022 11:01 AM, Richard Damon wrote:
>>>>>> On 9/5/22 11:56 AM, olcott wrote:
>>>>>>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/5/22 10:51 AM, olcott wrote:
>>>>>>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>> In every case where the simulation of the input by H would
>>>>>>>>>>>>> never
>>>>>>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>>>>>>> Why would a simulation of H() not return a value, once it
>>>>>>>>>>>> had done
>>>>>>>>>>>> the same kind of deduction?
>>>>>>>>>>>
>>>>>>>>>>> A simulating halt decider must abort the simulation of every
>>>>>>>>>>> otherwise
>>>>>>>>>>> non-terminating input. It does this by correctly recognizing
>>>>>>>>>>> non-terminating behavior patterns.
>>>>>>>>>>
>>>>>>>>>> You did not answer my question: if H() always returns a value,
>>>>>>>>>> why would
>>>>>>>>>> a simulated H() also not always return a value in the simulation?
>>>>>>>>>
>>>>>>>>> I will give you the short answer, the simulated H is never
>>>>>>>>> invoked.
>>>>>>>>>
>>>>>>>>>> "Because I defined it so" is not a sufficient answer here.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A simulating halt decider (SHD) always bases its halt status
>>>>>>>>> decision on correctly predicting whether or not it must abort
>>>>>>>>> the correct simulation of its input to prevent the infinite
>>>>>>>>> execution of this input.
>>>>>>>>
>>>>>>>> And thus isn't a correct halt decider as its criterion is
>>>>>>>> different from the Halting Criteria.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> A simulating halt decider that does not abort its simulation of
>>>>>>>>> its input performs a correct and complete simulation of this
>>>>>>>>> input.
>>>>>>>>
>>>>>>>> Right, and never gives a non-halting answer.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The definition of a UTM says that any correct and complete
>>>>>>>>> simulation of an input derives the actual behavior of this
>>>>>>>>> simulated input.
>>>>>>>>
>>>>>>>> Right, so a UTM never aborts.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thus if the correct and complete simulation of an input never
>>>>>>>>> reaches the final state of this input this means that this
>>>>>>>>> input specifies a non-halting sequence of instructions.
>>>>>>>>
>>>>>>>> Right.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The fact that the simulation of this input is aborted does not
>>>>>>>>> change the fact that this correctly simulated input cannot
>>>>>>>>> possibly reach its own final state.
>>>>>>>>
>>>>>>>> Right, but note, your arguments above were looking at a P(P)
>>>>>>>> that called an H(P,P) that doesn't abort. Once you CHANGE the
>>>>>>>> behavior of H, you have changed the input, and thus need to
>>>>>>>> re-evaluate.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Once we know that the correctly simulated cannot possibly reach
>>>>>>>>> its own final state this input can be rejected as non-halting
>>>>>>>>> on the basis of the definition of non-halting: *never reaches
>>>>>>>>> its final state*
>>>>>>>>
>>>>>>>> Except you did your logic wrong, because you intial assumption
>>>>>>>> that the simulation never reached a final state was based on
>>>>>>>> assuming that H never aborts its simulation.
>>>>>>>>
>>>>>>>> Since it does, the logic is unsound.
>>>>>>>>
>>>>>>>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and
>>>>>>>> thus your arguement that it doesn't is untrue.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>    if (Halt_Status)
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [000010f2](01)  55             push ebp
>>>>>>>>> [000010f3](02)  8bec           mov ebp,esp
>>>>>>>>> [000010f5](01)  51             push ecx
>>>>>>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>> [000010f9](01)  50             push eax       // push P
>>>>>>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>> [000010fd](01)  51             push ecx       // push P
>>>>>>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>>>>>>> [00001103](03)  83c408         add esp,+08
>>>>>>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>>>>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>>>>>>> [0000110d](02)  7402           jz 00001111
>>>>>>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>>>>>>> [00001111](02)  8be5           mov esp,ebp
>>>>>>>>> [00001113](01)  5d             pop ebp
>>>>>>>>> [00001114](01)  c3             ret
>>>>>>>>> Size in bytes:(0035) [00001114]
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> This is what happens if H never aborts the simulation of its
>>>>>>>>> input:
>>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>>
>>>>>>>> Right, if H never aborts.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> When P is correctly simulated by H and H does not abort its
>>>>>>>>> simulation of P the first 8 instructions of P are simulated
>>>>>>>>> endlessly.
>>>>>>>>
>>>>>>>> Nope, you built that logic on the assumption that H doesn't
>>>>>>>> abort, thus you can't have H abort.
>>>>>>>
>>>>>>> The only job of H is to correctly determine whether or not its
>>>>>>> correctly simulated input can possibly reach the final state of
>>>>>>> this input.
>>>>>>
>>>>>> Nope, it is to determine if *THE* correctly and completely
>>>>>> simulated input will reach a final state or not. Not *ITS*,
>>>>>> because if H aborts its simulation, that definition is INCORRECT
>>>>>> because it doesn't match the ACTAUL defintion of Halting.
>>>>>>
>>>>>> That is because it is different than determining if a DIFFERENT
>>>>>> version of the decider, when that difference changes the input,
>>>>>> would be halting or not.
>>>>>>
>>>>>> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear meaning
>>>>>> of your words says that Hx was wrong.
>>>>>>
>>>>>>>
>>>>>>> void Px(ptr x)
>>>>>>> {
>>>>>>>   int Halt_Status = Hx(x, x);
>>>>>>>   if (Halt_Status)
>>>>>>>     HERE: goto HERE;
>>>>>>>   return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", Hx(Px, Px));
>>>>>>> }
>>>>>>>
>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>>> No function Hx can be defined such that its correct simulation of
>>>>>>> its input Px would reach the final state of this simulated Px in
>>>>>>> any finite number of steps.
>>>>>>>
>>>>>>
>>>>>> So. UTM(Hx,Hx) does Halt, so the correct and complete simulation
>>>>>> halts, so the correct answer is Halting.
>>>>>
>>>>> *You are not paying attention*
>>>>> *Your boiler plate reply does not apply to what I just said*
>>>>>
>>>>> *The above refers to the infinite set of Hx/Px pairs where Hx*
>>>>> *correctly simulates its input Px, some halt others do not*
>>>>>
>>>>
>>>> So, are you saying that UTM(Px,Px) doesn't ever halt when Hx(Px,Px)
>>>> returns 0?
>>>>
>>> *No I specifically said that I am not saying that*
>>> *Hx/Px specifies an infinite set of pairs some halt others do not*
>>>
>>> The one thing that is the same across *ALL* of these pairs is that
>>> the input to Hx(Px,Px) correctly simulated by Hx never reaches the
>>> final state of Px.
>>>
>>
>> So, are you thus asserting that Hx is NOT a Halt Decider?
>
> I didn't say that. I am saying that in every possible pair of Hx/Px
> combinations where Hx correctly simulates its input Px never halts.
>

On 9/5/2022 3:27 PM, Richard Damon wrote:
>
> On 9/5/22 4:20 PM, olcott wrote:
>> On 9/5/2022 3:11 PM, Richard Damon wrote:
>>>
>>> On 9/5/22 3:52 PM, olcott wrote:
>>>> On 9/5/2022 2:48 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/5/22 3:34 PM, olcott wrote:
>>>>>> On 9/5/2022 11:01 AM, Richard Damon wrote:
>>>>>>> On 9/5/22 11:56 AM, olcott wrote:
>>>>>>>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/5/22 10:51 AM, olcott wrote:
>>>>>>>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>>> In every case where the simulation of the input by H would
>>>>>>>>>>>>>> never
>>>>>>>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>>>>>>>> Why would a simulation of H() not return a value, once it
>>>>>>>>>>>>> had done
>>>>>>>>>>>>> the same kind of deduction?
>>>>>>>>>>>>
>>>>>>>>>>>> A simulating halt decider must abort the simulation of every
>>>>>>>>>>>> otherwise
>>>>>>>>>>>> non-terminating input. It does this by correctly recognizing
>>>>>>>>>>>> non-terminating behavior patterns.
>>>>>>>>>>>
>>>>>>>>>>> You did not answer my question: if H() always returns a
>>>>>>>>>>> value, why would
>>>>>>>>>>> a simulated H() also not always return a value in the
>>>>>>>>>>> simulation?
>>>>>>>>>>
>>>>>>>>>> I will give you the short answer, the simulated H is never
>>>>>>>>>> invoked.
>>>>>>>>>>
>>>>>>>>>>> "Because I defined it so" is not a sufficient answer here.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A simulating halt decider (SHD) always bases its halt status
>>>>>>>>>> decision on correctly predicting whether or not it must abort
>>>>>>>>>> the correct simulation of its input to prevent the infinite
>>>>>>>>>> execution of this input.
>>>>>>>>>
>>>>>>>>> And thus isn't a correct halt decider as its criterion is
>>>>>>>>> different from the Halting Criteria.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A simulating halt decider that does not abort its simulation
>>>>>>>>>> of its input performs a correct and complete simulation of
>>>>>>>>>> this input.
>>>>>>>>>
>>>>>>>>> Right, and never gives a non-halting answer.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The definition of a UTM says that any correct and complete
>>>>>>>>>> simulation of an input derives the actual behavior of this
>>>>>>>>>> simulated input.
>>>>>>>>>
>>>>>>>>> Right, so a UTM never aborts.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thus if the correct and complete simulation of an input never
>>>>>>>>>> reaches the final state of this input this means that this
>>>>>>>>>> input specifies a non-halting sequence of instructions.
>>>>>>>>>
>>>>>>>>> Right.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The fact that the simulation of this input is aborted does not
>>>>>>>>>> change the fact that this correctly simulated input cannot
>>>>>>>>>> possibly reach its own final state.
>>>>>>>>>
>>>>>>>>> Right, but note, your arguments above were looking at a P(P)
>>>>>>>>> that called an H(P,P) that doesn't abort. Once you CHANGE the
>>>>>>>>> behavior of H, you have changed the input, and thus need to
>>>>>>>>> re-evaluate.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Once we know that the correctly simulated cannot possibly
>>>>>>>>>> reach its own final state this input can be rejected as
>>>>>>>>>> non-halting on the basis of the definition of non-halting:
>>>>>>>>>> *never reaches its final state*
>>>>>>>>>
>>>>>>>>> Except you did your logic wrong, because you intial assumption
>>>>>>>>> that the simulation never reached a final state was based on
>>>>>>>>> assuming that H never aborts its simulation.
>>>>>>>>>
>>>>>>>>> Since it does, the logic is unsound.
>>>>>>>>>
>>>>>>>>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and
>>>>>>>>> thus your arguement that it doesn't is untrue.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> _P()
>>>>>>>>>> [000010f2](01)  55             push ebp
>>>>>>>>>> [000010f3](02)  8bec           mov ebp,esp
>>>>>>>>>> [000010f5](01)  51             push ecx
>>>>>>>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>> [000010f9](01)  50             push eax       // push P
>>>>>>>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>> [000010fd](01)  51             push ecx       // push P
>>>>>>>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>>>>>>>> [00001103](03)  83c408         add esp,+08
>>>>>>>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>>>>>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>>>>>>>> [0000110d](02)  7402           jz 00001111
>>>>>>>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>>>>>>>> [00001111](02)  8be5           mov esp,ebp
>>>>>>>>>> [00001113](01)  5d             pop ebp
>>>>>>>>>> [00001114](01)  c3             ret
>>>>>>>>>> Size in bytes:(0035) [00001114]
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> This is what happens if H never aborts the simulation of its
>>>>>>>>>> input:
>>>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>>>
>>>>>>>>> Right, if H never aborts.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When P is correctly simulated by H and H does not abort its
>>>>>>>>>> simulation of P the first 8 instructions of P are simulated
>>>>>>>>>> endlessly.
>>>>>>>>>
>>>>>>>>> Nope, you built that logic on the assumption that H doesn't
>>>>>>>>> abort, thus you can't have H abort.
>>>>>>>>
>>>>>>>> The only job of H is to correctly determine whether or not its
>>>>>>>> correctly simulated input can possibly reach the final state of
>>>>>>>> this input.
>>>>>>>
>>>>>>> Nope, it is to determine if *THE* correctly and completely
>>>>>>> simulated input will reach a final state or not. Not *ITS*,
>>>>>>> because if H aborts its simulation, that definition is INCORRECT
>>>>>>> because it doesn't match the ACTAUL defintion of Halting.
>>>>>>>
>>>>>>> That is because it is different than determining if a DIFFERENT
>>>>>>> version of the decider, when that difference changes the input,
>>>>>>> would be halting or not.
>>>>>>>
>>>>>>> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear meaning
>>>>>>> of your words says that Hx was wrong.
>>>>>>>
>>>>>>>>
>>>>>>>> void Px(ptr x)
>>>>>>>> {
>>>>>>>>   int Halt_Status = Hx(x, x);
>>>>>>>>   if (Halt_Status)
>>>>>>>>     HERE: goto HERE;
>>>>>>>>   return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>    Output("Input_Halts = ", Hx(Px, Px));
>>>>>>>> }
>>>>>>>>
>>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>>>> No function Hx can be defined such that its correct simulation
>>>>>>>> of its input Px would reach the final state of this simulated Px
>>>>>>>> in any finite number of steps.
>>>>>>>>
>>>>>>>
>>>>>>> So. UTM(Hx,Hx) does Halt, so the correct and complete simulation
>>>>>>> halts, so the correct answer is Halting.
>>>>>>
>>>>>> *You are not paying attention*
>>>>>> *Your boiler plate reply does not apply to what I just said*
>>>>>>
>>>>>> *The above refers to the infinite set of Hx/Px pairs where Hx*
>>>>>> *correctly simulates its input Px, some halt others do not*
>>>>>>
>>>>>
>>>>> So, are you saying that UTM(Px,Px) doesn't ever halt when Hx(Px,Px)
>>>>> returns 0?
>>>>>
>>>> *No I specifically said that I am not saying that*
>>>> *Hx/Px specifies an infinite set of pairs some halt others do not*
>>>>
>>>> The one thing that is the same across *ALL* of these pairs is that
>>>> the input to Hx(Px,Px) correctly simulated by Hx never reaches the
>>>> final state of Px.
>>>>
>>>
>>> So, are you thus asserting that Hx is NOT a Halt Decider?
>>
>> I didn't say that. I am saying that in every possible pair of Hx/Px
>> combinations where Hx correctly simulates its input Px never halts.
>>
>
> So, are you saying that it is supposed to meet the requirements of a
> Halt Decider?
>

On 9/5/22 4:44 PM, olcott wrote:
> On 9/5/2022 3:27 PM, Richard Damon wrote:
>>
>> On 9/5/22 4:20 PM, olcott wrote:
>>> On 9/5/2022 3:11 PM, Richard Damon wrote:
>>>>
>>>> On 9/5/22 3:52 PM, olcott wrote:
>>>>> On 9/5/2022 2:48 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/5/22 3:34 PM, olcott wrote:
>>>>>>> On 9/5/2022 11:01 AM, Richard Damon wrote:
>>>>>>>> On 9/5/22 11:56 AM, olcott wrote:
>>>>>>>>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/5/22 10:51 AM, olcott wrote:
>>>>>>>>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>>>> In every case where the simulation of the input by H
>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>>>>>>>>> Why would a simulation of H() not return a value, once it
>>>>>>>>>>>>>> had done
>>>>>>>>>>>>>> the same kind of deduction?
>>>>>>>>>>>>>
>>>>>>>>>>>>> A simulating halt decider must abort the simulation of
>>>>>>>>>>>>> every otherwise
>>>>>>>>>>>>> non-terminating input. It does this by correctly recognizing
>>>>>>>>>>>>> non-terminating behavior patterns.
>>>>>>>>>>>>
>>>>>>>>>>>> You did not answer my question: if H() always returns a
>>>>>>>>>>>> value, why would
>>>>>>>>>>>> a simulated H() also not always return a value in the
>>>>>>>>>>>> simulation?
>>>>>>>>>>>
>>>>>>>>>>> I will give you the short answer, the simulated H is never
>>>>>>>>>>> invoked.
>>>>>>>>>>>
>>>>>>>>>>>> "Because I defined it so" is not a sufficient answer here.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A simulating halt decider (SHD) always bases its halt status
>>>>>>>>>>> decision on correctly predicting whether or not it must abort
>>>>>>>>>>> the correct simulation of its input to prevent the infinite
>>>>>>>>>>> execution of this input.
>>>>>>>>>>
>>>>>>>>>> And thus isn't a correct halt decider as its criterion is
>>>>>>>>>> different from the Halting Criteria.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A simulating halt decider that does not abort its simulation
>>>>>>>>>>> of its input performs a correct and complete simulation of
>>>>>>>>>>> this input.
>>>>>>>>>>
>>>>>>>>>> Right, and never gives a non-halting answer.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The definition of a UTM says that any correct and complete
>>>>>>>>>>> simulation of an input derives the actual behavior of this
>>>>>>>>>>> simulated input.
>>>>>>>>>>
>>>>>>>>>> Right, so a UTM never aborts.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thus if the correct and complete simulation of an input never
>>>>>>>>>>> reaches the final state of this input this means that this
>>>>>>>>>>> input specifies a non-halting sequence of instructions.
>>>>>>>>>>
>>>>>>>>>> Right.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The fact that the simulation of this input is aborted does
>>>>>>>>>>> not change the fact that this correctly simulated input
>>>>>>>>>>> cannot possibly reach its own final state.
>>>>>>>>>>
>>>>>>>>>> Right, but note, your arguments above were looking at a P(P)
>>>>>>>>>> that called an H(P,P) that doesn't abort. Once you CHANGE the
>>>>>>>>>> behavior of H, you have changed the input, and thus need to
>>>>>>>>>> re-evaluate.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Once we know that the correctly simulated cannot possibly
>>>>>>>>>>> reach its own final state this input can be rejected as
>>>>>>>>>>> non-halting on the basis of the definition of non-halting:
>>>>>>>>>>> *never reaches its final state*
>>>>>>>>>>
>>>>>>>>>> Except you did your logic wrong, because you intial assumption
>>>>>>>>>> that the simulation never reached a final state was based on
>>>>>>>>>> assuming that H never aborts its simulation.
>>>>>>>>>>
>>>>>>>>>> Since it does, the logic is unsound.
>>>>>>>>>>
>>>>>>>>>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and
>>>>>>>>>> thus your arguement that it doesn't is untrue.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [000010f2](01)  55             push ebp
>>>>>>>>>>> [000010f3](02)  8bec           mov ebp,esp
>>>>>>>>>>> [000010f5](01)  51             push ecx
>>>>>>>>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>> [000010f9](01)  50             push eax       // push P
>>>>>>>>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>> [000010fd](01)  51             push ecx       // push P
>>>>>>>>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>>>>>>>>> [00001103](03)  83c408         add esp,+08
>>>>>>>>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>>>>>>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>>>>>>>>> [0000110d](02)  7402           jz 00001111
>>>>>>>>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>>>>>>>>> [00001111](02)  8be5           mov esp,ebp
>>>>>>>>>>> [00001113](01)  5d             pop ebp
>>>>>>>>>>> [00001114](01)  c3             ret
>>>>>>>>>>> Size in bytes:(0035) [00001114]
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> This is what happens if H never aborts the simulation of its
>>>>>>>>>>> input:
>>>>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>>>>
>>>>>>>>>> Right, if H never aborts.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> When P is correctly simulated by H and H does not abort its
>>>>>>>>>>> simulation of P the first 8 instructions of P are simulated
>>>>>>>>>>> endlessly.
>>>>>>>>>>
>>>>>>>>>> Nope, you built that logic on the assumption that H doesn't
>>>>>>>>>> abort, thus you can't have H abort.
>>>>>>>>>
>>>>>>>>> The only job of H is to correctly determine whether or not its
>>>>>>>>> correctly simulated input can possibly reach the final state of
>>>>>>>>> this input.
>>>>>>>>
>>>>>>>> Nope, it is to determine if *THE* correctly and completely
>>>>>>>> simulated input will reach a final state or not. Not *ITS*,
>>>>>>>> because if H aborts its simulation, that definition is INCORRECT
>>>>>>>> because it doesn't match the ACTAUL defintion of Halting.
>>>>>>>>
>>>>>>>> That is because it is different than determining if a DIFFERENT
>>>>>>>> version of the decider, when that difference changes the input,
>>>>>>>> would be halting or not.
>>>>>>>>
>>>>>>>> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear
>>>>>>>> meaning of your words says that Hx was wrong.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> void Px(ptr x)
>>>>>>>>> {
>>>>>>>>>   int Halt_Status = Hx(x, x);
>>>>>>>>>   if (Halt_Status)
>>>>>>>>>     HERE: goto HERE;
>>>>>>>>>   return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    Output("Input_Halts = ", Hx(Px, Px));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>>>>> No function Hx can be defined such that its correct simulation
>>>>>>>>> of its input Px would reach the final state of this simulated
>>>>>>>>> Px in any finite number of steps.
>>>>>>>>>
>>>>>>>>
>>>>>>>> So. UTM(Hx,Hx) does Halt, so the correct and complete simulation
>>>>>>>> halts, so the correct answer is Halting.
>>>>>>>
>>>>>>> *You are not paying attention*
>>>>>>> *Your boiler plate reply does not apply to what I just said*
>>>>>>>
>>>>>>> *The above refers to the infinite set of Hx/Px pairs where Hx*
>>>>>>> *correctly simulates its input Px, some halt others do not*
>>>>>>>
>>>>>>
>>>>>> So, are you saying that UTM(Px,Px) doesn't ever halt when
>>>>>> Hx(Px,Px) returns 0?
>>>>>>
>>>>> *No I specifically said that I am not saying that*
>>>>> *Hx/Px specifies an infinite set of pairs some halt others do not*
>>>>>
>>>>> The one thing that is the same across *ALL* of these pairs is that
>>>>> the input to Hx(Px,Px) correctly simulated by Hx never reaches the
>>>>> final state of Px.
>>>>>
>>>>
>>>> So, are you thus asserting that Hx is NOT a Halt Decider?
>>>
>>> I didn't say that. I am saying that in every possible pair of Hx/Px
>>> combinations where Hx correctly simulates its input Px never halts.
>>>
>>
>> So, are you saying that it is supposed to meet the requirements of a
>> Halt Decider?
>>
>
> I didn't say that either.

On 9/5/2022 3:54 PM, Richard Damon wrote:
> On 9/5/22 4:44 PM, olcott wrote:
>> On 9/5/2022 3:27 PM, Richard Damon wrote:
>>>
>>> On 9/5/22 4:20 PM, olcott wrote:
>>>> On 9/5/2022 3:11 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/5/22 3:52 PM, olcott wrote:
>>>>>> On 9/5/2022 2:48 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/5/22 3:34 PM, olcott wrote:
>>>>>>>> On 9/5/2022 11:01 AM, Richard Damon wrote:
>>>>>>>>> On 9/5/22 11:56 AM, olcott wrote:
>>>>>>>>>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/5/22 10:51 AM, olcott wrote:
>>>>>>>>>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>>>>> In every case where the simulation of the input by H
>>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>>>>>>>>>> Why would a simulation of H() not return a value, once it
>>>>>>>>>>>>>>> had done
>>>>>>>>>>>>>>> the same kind of deduction?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A simulating halt decider must abort the simulation of
>>>>>>>>>>>>>> every otherwise
>>>>>>>>>>>>>> non-terminating input. It does this by correctly recognizing
>>>>>>>>>>>>>> non-terminating behavior patterns.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You did not answer my question: if H() always returns a
>>>>>>>>>>>>> value, why would
>>>>>>>>>>>>> a simulated H() also not always return a value in the
>>>>>>>>>>>>> simulation?
>>>>>>>>>>>>
>>>>>>>>>>>> I will give you the short answer, the simulated H is never
>>>>>>>>>>>> invoked.
>>>>>>>>>>>>
>>>>>>>>>>>>> "Because I defined it so" is not a sufficient answer here.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> A simulating halt decider (SHD) always bases its halt status
>>>>>>>>>>>> decision on correctly predicting whether or not it must
>>>>>>>>>>>> abort the correct simulation of its input to prevent the
>>>>>>>>>>>> infinite execution of this input.
>>>>>>>>>>>
>>>>>>>>>>> And thus isn't a correct halt decider as its criterion is
>>>>>>>>>>> different from the Halting Criteria.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> A simulating halt decider that does not abort its simulation
>>>>>>>>>>>> of its input performs a correct and complete simulation of
>>>>>>>>>>>> this input.
>>>>>>>>>>>
>>>>>>>>>>> Right, and never gives a non-halting answer.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The definition of a UTM says that any correct and complete
>>>>>>>>>>>> simulation of an input derives the actual behavior of this
>>>>>>>>>>>> simulated input.
>>>>>>>>>>>
>>>>>>>>>>> Right, so a UTM never aborts.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thus if the correct and complete simulation of an input
>>>>>>>>>>>> never reaches the final state of this input this means that
>>>>>>>>>>>> this input specifies a non-halting sequence of instructions.
>>>>>>>>>>>
>>>>>>>>>>> Right.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The fact that the simulation of this input is aborted does
>>>>>>>>>>>> not change the fact that this correctly simulated input
>>>>>>>>>>>> cannot possibly reach its own final state.
>>>>>>>>>>>
>>>>>>>>>>> Right, but note, your arguments above were looking at a P(P)
>>>>>>>>>>> that called an H(P,P) that doesn't abort. Once you CHANGE the
>>>>>>>>>>> behavior of H, you have changed the input, and thus need to
>>>>>>>>>>> re-evaluate.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Once we know that the correctly simulated cannot possibly
>>>>>>>>>>>> reach its own final state this input can be rejected as
>>>>>>>>>>>> non-halting on the basis of the definition of non-halting:
>>>>>>>>>>>> *never reaches its final state*
>>>>>>>>>>>
>>>>>>>>>>> Except you did your logic wrong, because you intial
>>>>>>>>>>> assumption that the simulation never reached a final state
>>>>>>>>>>> was based on assuming that H never aborts its simulation.
>>>>>>>>>>>
>>>>>>>>>>> Since it does, the logic is unsound.
>>>>>>>>>>>
>>>>>>>>>>> When H(P,P) DOES abort its simulation UTM(P,P) will Halt, and
>>>>>>>>>>> thus your arguement that it doesn't is untrue.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>    return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> _P()
>>>>>>>>>>>> [000010f2](01)  55             push ebp
>>>>>>>>>>>> [000010f3](02)  8bec           mov ebp,esp
>>>>>>>>>>>> [000010f5](01)  51             push ecx
>>>>>>>>>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>>> [000010f9](01)  50             push eax       // push P
>>>>>>>>>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>>> [000010fd](01)  51             push ecx       // push P
>>>>>>>>>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>>>>>>>>>> [00001103](03)  83c408         add esp,+08
>>>>>>>>>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>>>>>>>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>>>>>>>>>> [0000110d](02)  7402           jz 00001111
>>>>>>>>>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>>>>>>>>>> [00001111](02)  8be5           mov esp,ebp
>>>>>>>>>>>> [00001113](01)  5d             pop ebp
>>>>>>>>>>>> [00001114](01)  c3             ret
>>>>>>>>>>>> Size in bytes:(0035) [00001114]
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> This is what happens if H never aborts the simulation of its
>>>>>>>>>>>> input:
>>>>>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>>>>>
>>>>>>>>>>> Right, if H never aborts.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> When P is correctly simulated by H and H does not abort its
>>>>>>>>>>>> simulation of P the first 8 instructions of P are simulated
>>>>>>>>>>>> endlessly.
>>>>>>>>>>>
>>>>>>>>>>> Nope, you built that logic on the assumption that H doesn't
>>>>>>>>>>> abort, thus you can't have H abort.
>>>>>>>>>>
>>>>>>>>>> The only job of H is to correctly determine whether or not its
>>>>>>>>>> correctly simulated input can possibly reach the final state
>>>>>>>>>> of this input.
>>>>>>>>>
>>>>>>>>> Nope, it is to determine if *THE* correctly and completely
>>>>>>>>> simulated input will reach a final state or not. Not *ITS*,
>>>>>>>>> because if H aborts its simulation, that definition is
>>>>>>>>> INCORRECT because it doesn't match the ACTAUL defintion of
>>>>>>>>> Halting.
>>>>>>>>>
>>>>>>>>> That is because it is different than determining if a DIFFERENT
>>>>>>>>> version of the decider, when that difference changes the input,
>>>>>>>>> would be halting or not.
>>>>>>>>>
>>>>>>>>> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the clear
>>>>>>>>> meaning of your words says that Hx was wrong.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void Px(ptr x)
>>>>>>>>>> {
>>>>>>>>>>   int Halt_Status = Hx(x, x);
>>>>>>>>>>   if (Halt_Status)
>>>>>>>>>>     HERE: goto HERE;
>>>>>>>>>>   return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>    Output("Input_Halts = ", Hx(Px, Px));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>>>>>> No function Hx can be defined such that its correct simulation
>>>>>>>>>> of its input Px would reach the final state of this simulated
>>>>>>>>>> Px in any finite number of steps.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So. UTM(Hx,Hx) does Halt, so the correct and complete
>>>>>>>>> simulation halts, so the correct answer is Halting.
>>>>>>>>
>>>>>>>> *You are not paying attention*
>>>>>>>> *Your boiler plate reply does not apply to what I just said*
>>>>>>>>
>>>>>>>> *The above refers to the infinite set of Hx/Px pairs where Hx*
>>>>>>>> *correctly simulates its input Px, some halt others do not*
>>>>>>>>
>>>>>>>
>>>>>>> So, are you saying that UTM(Px,Px) doesn't ever halt when
>>>>>>> Hx(Px,Px) returns 0?
>>>>>>>
>>>>>> *No I specifically said that I am not saying that*
>>>>>> *Hx/Px specifies an infinite set of pairs some halt others do not*
>>>>>>
>>>>>> The one thing that is the same across *ALL* of these pairs is that
>>>>>> the input to Hx(Px,Px) correctly simulated by Hx never reaches the
>>>>>> final state of Px.
>>>>>>
>>>>>
>>>>> So, are you thus asserting that Hx is NOT a Halt Decider?
>>>>
>>>> I didn't say that. I am saying that in every possible pair of Hx/Px
>>>> combinations where Hx correctly simulates its input Px never halts.
>>>>
>>>
>>> So, are you saying that it is supposed to meet the requirements of a
>>> Halt Decider?
>>>
>>
>> I didn't say that either.
>
> Yes, we've noticed. YOu have a problem, either your Hx's ARE Halt
> Deciders and must follow the definition of a Halt Decider, in which case
> the fact that UTM(Px,Px) Halt means they are wrong, or you admit tha t
>
>>
>>> As I have said, it doesn't matter that no Hx ever correct simulates
>>> its input Px to a final state, that just means that no Hx can PROVE
>>> that its input is Halting, not that it isn't halting.
>>>
>>
>> If none of the Hx/Px pairs where Hx correctly simulates Px reaches a
>> final state of Px, then Px does not halt in any of these cases.
>
> Nope. In EVERY case that Hx aborts its simulation (and returns 0) it is
> NOT a source of truth that its input is non-halting, and in fact, as you
> have tactfully agreed by not disagreeing, it has been shown that
> UTM(Px,Px) will Halt, so the input is HALTING.
>
>>
>> We know that all male humans are humans categorically.
>>
>> We know that all inputs that do not halt are non-halting inputs,
>> categorically.
>
> Except tha not reaching a final state in an ABORTED and thus PARTIAL
> simulation does not mean they are non-halting,