Re: Does everyone agree with this halt status decision?

[olcott]

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.

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.

That you (and others) continue to ignore this obvious difference really
seems dishonest.

Ubiquity, an ACM publication November 2010
http://ubiquity.acm.org 1 ©2010 Association for Computing Machinery
Ubiquity Symposium What is Computation?
Opening Statement by Peter J. Denning

** The standard formal definition of computation, repeated in all the
major textbooks, derives from these early ideas. Computation is defined
as the execution sequences of halting Turing machines (or their
equivalents). An execution sequence is the sequence of total
configurations of the machine, including states of memory and control
unit. https://dl.acm.org/doi/pdf/10.1145/1880066.1880067


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

[olcott]

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:

>>> 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.

[olcott]

On 9/5/2022 5:49 AM, Otto J. Makela wrote:
> olcott <polc...@gmail.com> wrote:
>
>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>> olcott <polc...@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