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.

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

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

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

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

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

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

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.

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.

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.

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.

> André
>
>> (1) Verified as true entirely on the basis of the meaning of its words:
>> 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:
>>
>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein