On 2021-08-30 19:14, olcott wrote:
> On 8/30/2021 5:00 PM, André G. Isaak wrote:
>> On 2021-08-30 11:15, olcott wrote:
>>> On 8/30/2021 11:25 AM, André G. Isaak wrote:
>>>> On 2021-08-30 08:35, olcott wrote:
>>>>> My point is fully proven on the basis of two other points:
>>>>> (1) Verified as true entirely on the basis of the meaning of its
>>>>> words:
>>>>
>>>> Claiming that something is 'verified as true entirely on the basis
>>>> of the meaning of its words' isn't a valid substitute for a proof.
>>>>
>>>
>>> That all cats are animals and all animals are living things is a
>>> perfectly sound deductive proof that all cats are living things.
>>
>> Yes, that's a valid proof. It also contains identifiable premises and
>> a conclusion which can be linked to those premises by accepted rules
>> of logic. It doesn't just say 'verified on the basis of the meaning of
>> the words' which is *not* a valid proof.
>>
>
> We only know that a cat is an animal and that an animal is a living
> thing on the basis of the meaning of those words. We don't know this by
> any other means.

Your grasp of epistemology is clearly wanting. We know that cats are
animals based on observations of cats.

>>> That you fail to comprehend that proofs can be entirely based on the
>>> meaning of words is merely your error based on an incorrectly narrow
>>> minded focus.
>>>
>>>>> A simulating halt decider correctly decides that any input that
>>>>> never halts unless the simulating halt decider aborts its
>>>>> simulation of this input is an input that never halts.
>>>>>
>>>>> (2) It can be verified that the input to H(P,P) never halts unless
>>>>> H aborts it. This is verified on the basis that the execution trace
>>>>> of P meets this criteria:
>>>>>
>>>>> where H = X() and P = Y()
>>>>>
>>>>> Infinite recursion detection criteria:
>>>>> If the execution trace of function X() called by function Y() shows:
>>>>> (a) Function X() is called twice in sequence from the same machine
>>>>> address of Y().
>>>>> (b) With the same parameters to X().
>>>>> (c) With no conditional branch or indexed jump instructions in Y().
>>>>> (d) With no function call returns from X().
>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>
>>>> First off, you simply state the above criteria without actually
>>>> offering any *proof* that these criteria actually work.
>>>>
>>>
>>> They above criteria have been extensively reviewed and critiqued,
>>> none-the-less for the point at hand it is quite obvious to every
>>> honest person that has a sufficient understanding of x86 assembly
>>> language that the simulation of P on input P by H never halts while H
>>> is in pure simulation mode.
>>
>> They have been critiqued, but they haven't been *accepted*. Again, you
>> need to provide a proof that these criteria are valid. You can't just
>> state them.
>>
>
> The criteria are self-evidently true.

No. They are not. You seem to use the phrase 'self-evidently true' as
shorthand, for 'this sounds plausible to me but I'm not sure how to
prove it'.

>>>> And second, even if these criteria are valid, your trace *doesn't*
>>>> actually meet these criteria because you deliberately omit portions
>>>> of the code from your trace (i.e. everything that happens starting
>>>> at address 966).
>>>>
>>>
>>> This is explained on pages 3-4 of my updated paper. That people
>>> continue to ignore sound reasoning is no actual rebuttal at all.
>>
>> People don't merely ignore it. They actively reject it on the grounds
>> that it is not valid reasoning.
>>
>
> The actively reject on the presumption that it seems to be invalid
> reasoning to them when they make sure not follow the details that prove
> it is valid.

They actively reject it because you give an invalid argument to justify
it, as has been repeatedly pointed out.

>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>>> The claim that 'it can be verified that the input to H(P, P) never
>>>> halts unless H aborts it.' Is not verified at all, since it can
>>>> easily shown to be false by simply observing the fact that P(P)
>>>> does, in fact, halt.
>>>>
>>>
>>> Yet again you twist my words. This is the straw-man error. See pages
>>> 3-4 of my paper.
>>>
>>>> You try to get around this by claiming that when you call H(P, P)
>>>> the input magically changes to some *other* computation which isn't
>>>> equivalent to P(P) and that this *other* computation is non-halting,
>>>> but even if such a claim made sense, it means your H is answering
>>>> about the *wrong* computation.
>>>>
>>>
>>> int main() { P(P); } will not be discussed on this thread.
>>> I will no longer tolerate dishonest dodges away from the the point.
>>
>> int main() { P(P); } is *precisely* the computation which H(P, P) is
>> supposed to be evaluating.
>>
>
> int main() { P(P); } will not be discussed on this thread.
> int main() { P(P); } will not be discussed on this thread.
> int main() { P(P); } will not be discussed on this thread.
> int main() { P(P); } will not be discussed on this thread.
>
>> Refusing to discuss this is like refusing to discuss the results of 2
>> + 2 = 4 when trying to justify that sum(2, 2) == 5.
>>
>
> H(P,P)==0 is correct is a necessary consequence of its two premises.
> H(P,P)==0 is correct is a necessary consequence of its two premises.
> H(P,P)==0 is correct is a necessary consequence of its two premises.
> H(P,P)==0 is correct is a necessary consequence of its two premises.

It's premises? What the hell are you talking about. Functions take
*arguments*, not premises.

> Anything outside of this necessary consequence is a dishonest dodge.
>
> Failure to pay enough attention to understand that this is a necessary
> consequence is a dishonest dodge.
>
>>>> And from your recent posts in a different thread, it appears you are
>>>> also claiming that it is not possible to even ask your H about the
>>>> real P(P), which is the case we're really concerned about.
>>>>
>>>
>>> int main() { P(P); } will not be discussed on this thread.
>>> I will no longer tolerate dishonest dodges away from the the point.
>>
>> int main() { P(P); } is what corresponds to Linz's H_Hat(H_Hat).
>>
>
> More precisely:
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
> Ĥ applied to ⟨Ĥ⟩ is
> exactly analogous to int main() { P((u32)P); }
>
> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is exactly analogous to
> H(P,P) called from main() { P((u32)P); }
>
> Ĥ applied to ⟨Ĥ⟩ is a different computation than
> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ because the latter is under the dominion of a
> simulating halt decider
>
> int main() { P((u32)P); } is a different computation than
> H(P,P) because the latter is under the dominion of a simulating halt
> decider

Under the dominion? That's a very peculiar phrasing. P(P) isn't being
computed at all when we run H(P, P). The halting status of P(P) is being
evaluated. And P(P) halts.

Every TM description + input string description identifies a *unique*
computation.

When you pass H the arguments (P, P) it can't just change to some
distinct computation from P(P) because H *by definition* is being asked
about P(P). If it's answer doesn't correspond to the behaviour of P(P)
(== int main() { P(P); }) then it is WRONG.

>> This, according to you, is the *only* case you care about since if
>> your H can solve it you think it would refute Linz.
>>
>> If P(P) magically represents some 'different' computation when it is
>> given as an input to H(P, P) then (putting aside the fact that this
>> illustrates you don't understand what a computation is) it means that
>> H(P, P) is evaluating the *wrong* computation.
>>
>> And the fact that you claim P(P) represents some 'different'
>> computation when it is given as an input to your simulating halt
>> decider, this rather clearly shows that the simulating portion of your
>> decider is *broken*. If it simulates P(P), it must behave as P(P)
>> behaves, not as some 'other' computation.
>>
>> You can't simply ignore the elephant in the room, which is the
>> behaviour of main() { P(P); }.
>>
>> If you think bring this up is a 'dodge', then it means you clearly
>> don't understand what the halting problem is. At all.
>>
>> A halt decider is a program which takes as its argument some other
>> program and the input to that program (whether it be a C program, a
>> TM, or whatever) and determines whether that program halts.
>>
>> H(P, P) *needs* to determine whether the independent program P(P) (i.e
>> main() { P(P); } halts. If it instead answers about what happens when
>> P(P) is simulated by your H in a way that somehow changes the nature
>> of the computation, then it is not answering the the question a halt
>> decider is, by definition, supposed to answer.
>>
>> If it simply reports on the behaviour of P(P) inside a broken
>> simulator, why would that result be of interest to *anyone*. It's a
>> "computation" which only exists inside some specific piece of software.
>>
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0((u32)Infinite_Loop));
>   Infinite_Loop();
> }
>
> The simplest way to see that a computation under the dominion of a
> simulating halt decider can be entirely different than direct execution
> is that line 1 of main halts and line 2 of main never halts.

Of course the halting status of H(Infinite_Loop) and of Infinite_Loop()
are different. But Infinite_Loop doesn't become a halting computation
when passed as an argument to H. That H(Infinite_Loop) halts doesn't
suddenly make Infinite Loop() become a halting computation.
Infinite_Loop() isn't being computed at all when we run H(Infinite_Loop).

Similarly P(P) and H(P, P) are distinct computation with distinct
halting behaviours. When we run H(P, P), P(P) isn't being computed, only
H(P, P) is being computed. but you want to claim that the *input* to
H(P, P) represents some distinct computation from P(P) which is
completely incoherent. That somehow the *input* to H(P, P) is
non-halting despite the fact that the actual computation P(P) is halting.

If your H's answer doesn't match the behaviour of the *actual*
computation P(P), then it is not answering the question it is supposed
to be answering.

>
>>>> If your H can't even be asked about the real P(P), then it isn't
>>>> even answering the question a halt decider is supposed to answer. So
>>>> what's the point of your H?
>>>>
>>>> André
>>>>
>>>
>>> The only thing that will be discussed on this thread is the
>>> [Airtight proof that H(P,P)==0 is correct] on the basis that (1) and
>>> (2) are true. Everything else will be construed as a dishonest dodge.
>>
>> You can't dictate what other people discuss. You want to ignore the
>> elephant in the room. You can't reasonably expect others to go along
>> with your delusion and pretend it isn't there. It is. It needs to be
>> discussed.
>>
>
> I will not tolerate dishonest dodges. I will only discuss that
> H(P,P)==0 is correct is a necessary consequence of its two premises.

> If H(P,P)==0 is a necessary consequence of its two premises and its two
> premises are true then it necessarily makes no difference what
> int main() { P(P); } does. That you cannot understand this proves the
> deficiency of your reasoning.

OF COURSE IT MATTERS, since H(P, P) by the very definition of 'halt
decider' is supposed to determine the halting status of P(P). That is
the *actual*, *independent* computation P(P). And that computation is
what you insist on calling int main() { P(P); }

Inputs to deciders don't *have* halting behaviour. They are just data.
Only *actual* computations have halting behaviour, and the *actual*
computation described by the input to H(P, P) is int main() { P(P); }

> If H(P,P)==0 is a necessary consequence of its two premises and its two
> premises are true then it necessarily makes no difference what

What the hell does the above even mean? H(P,P)==0 doesn't *have*
premises. It has arguments. And the arguments passed to H aren't
booleans so they *can't* be true.

Your H(P, P) gives the result 0 because it uses flawed logic.

The useless traces you insist on constantly repeating show that your
H(P, P) decides that P(P) doesn't halt, but those traces in no way show
that this decision is *correct*. To do that, you'd need to prove that
your underlying logic is sound which it *isn't*.

You need to go take a remedial logic course to learn what proofs
actually are. Then maybe you'd grasp why traces are *not* proofs of
anything. There's a reason why if you flip through computer science
journals you're highly unlikely to ever encounter a trace. Traces are
used for debugging, not for constructing proofs.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.