On 15/06/2022 11:05, Malcolm McLean wrote:
> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> We're dealing with our hands tied behind our backs, because we can't
>>> see H.
>> That's only partly true. A sketch of H was posted and we know that that
>> was wrong. And we know that H is wrong by definition because H(X,Y)
>> does not report on the "halting" of X(Y). There are other detailed
>> errors we can't critique without the actual H, but do you really care
>> about those details?
>>
> The current claim is that the direct execution of P(P) has different
> behavior to the correct simulation of the input to H(P,P).
> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
> But that's not possible if H is hidden. PO seems to think that H doesn't
> matter because its behaviour can be inferred, but here he is wrong.
>
PO recently (yesterday?) posted one of his traces with P(P) halting.

Inside that trace, we see P call H, and immediately after that in the trace we see NOT H trace
entries (all suppressed), but the trace entries from "H simulating the input to H(P,P)" - i.e.
exactly the trace entries PO claims are substantially different from the computation steps of P(P)
[aka "running" P(P) directly].

So, /are/ they substantially different? NOT IN THE SLIGHTEST! (As I've suggested a few times, but
the evidence is there in PO's own post...)

All we see is that H simulating P(P) calculates EXACTLY the same entries as P(P) as expected, UP TO
THE POINT WHERE H STOPS ITS SIMULATION. Not one shred of any evidence of diversion!

Of course, it's true we don't see the suppressed H entries, but I don't see any reason to think
those would be any different if included. PO is simply confused by his own code, and invents silly
PSR explanations to try to justify it all to himself. The explanation is obvious to anyone who's
analysed - H mistakenly decides it sees non-halting behaviour and so stops simulating, whereas the
computation itself (while containing the pattern H spotted - nobody denies that I think) proceeds
further and after a short while halts. (PO's rule is unsound, and why shouldn't it be - he's never
felt the need to offer any /proof/ that it's sound. He just really really really realy thinks it is!)

The most PO could come up with to explain this would be "ok, P(P) and H's simulation of the input to
H(P,P) /are/ identical step for step as far as H simulates, so the difference in computation states
/must/ occur in the computation steps that H never got to!". That's Dumb, Dumb, Dumb thinking, but
it wouldn't surprise me if that's what PO eventually comes up with... (He's not capable of thinking
it through rationally.)

Mike.

> As for should we simply dismiss what PO is saying, it's reasonable to
> do that to all people who claim to have "solved the halting problem" or
> otherwise refuted established results. It's even maybe reasonable to
> dismiss people who post on Usenet claiming to have solved long-
> standing open problems which aren't known to be insoluble. And that
> might be a kindness to the proposer in the long run. But that bridge has
> long since been crossed.
>

On 6/15/2022 6:31 PM, Mike Terry wrote:
> On 15/06/2022 11:05, Malcolm McLean wrote:
>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> We're dealing with our hands tied behind our backs, because we can't
>>>> see H.
>>> That's only partly true. A sketch of H was posted and we know that that
>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>> does not report on the "halting" of X(Y). There are other detailed
>>> errors we can't critique without the actual H, but do you really care
>>> about those details?
>>>
>> The current claim is that the direct execution of P(P) has different
>> behavior to the correct simulation of the input to H(P,P).
>> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
>> But that's not possible if H is hidden. PO seems to think that H doesn't
>> matter because its behaviour can be inferred, but here he is wrong.
>>
> PO recently (yesterday?) posted one of his traces with P(P) halting.
>
> Inside that trace, we see P call H, and immediately after that in the
> trace we see NOT H trace entries (all suppressed), but the trace entries
> from "H simulating the input to H(P,P)" - i.e. exactly the trace entries
> PO claims are substantially different from the computation steps of P(P)
> [aka "running" P(P) directly].
>
> So, /are/ they substantially different?  NOT IN THE SLIGHTEST!  (As I've
> suggested a few times, but the evidence is there in PO's own post...)
>
> All we see is that H simulating P(P) calculates EXACTLY the same entries
> as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS SIMULATION.  Not
> one shred of any evidence of diversion!
>
> Of course, it's true we don't see the suppressed H entries, but I don't
> see any reason to think those would be any different if included.  PO is
> simply confused by his own code, and invents silly PSR explanations to
> try to justify it all to himself.  The explanation is obvious to anyone
> who's analysed - H mistakenly decides it sees non-halting behaviour and
> so stops simulating, whereas the computation itself (while containing
> the pattern H spotted - nobody denies that I think) proceeds further and
> after a short while halts.  (PO's rule is unsound, and why shouldn't it
> be - he's never felt the need to offer any /proof/ that it's sound.  He
> just really really really realy thinks it is!)
>

It is the case that the correct and complete x86 emulation of the input
to H(P,P) never reaches its "ret" instruction and on this basis it is
correct to say that it is non-halting.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

> The most PO could come up with to explain this would be "ok, P(P) and
> H's simulation of the input to H(P,P) /are/ identical step for step as
> far as H simulates, so the difference in computation states /must/ occur
> in the computation steps that H never got to!".

I never say anything like that. It is ridiculously simple for any fully
competent software engineer to easily determine that

the correct and complete x86 emulation of the input to H(P,P) never
reaches its "ret" instruction.

>   That's Dumb, Dumb,
> Dumb thinking, but it wouldn't surprise me if that's what PO eventually
> comes up with... (He's not capable of thinking it through rationally.)
>
>
> Mike.
>
>> As for should we simply dismiss what PO is saying, it's reasonable to
>> do that to all people who claim to have "solved the halting problem" or
>> otherwise refuted established results. It's even maybe reasonable to
>> dismiss people who post on Usenet claiming to have solved long-
>> standing open problems which aren't known to be insoluble. And that
>> might be a kindness to the proposer in the long run. But that bridge has
>> long since been crossed.
>>
>

--
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 6/15/22 7:48 PM, olcott wrote:
> On 6/15/2022 6:31 PM, Mike Terry wrote:
>> On 15/06/2022 11:05, Malcolm McLean wrote:
>>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> We're dealing with our hands tied behind our backs, because we can't
>>>>> see H.
>>>> That's only partly true. A sketch of H was posted and we know that that
>>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>>> does not report on the "halting" of X(Y). There are other detailed
>>>> errors we can't critique without the actual H, but do you really care
>>>> about those details?
>>>>
>>> The current claim is that the direct execution of P(P) has different
>>> behavior to the correct simulation of the input to H(P,P).
>>> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
>>> But that's not possible if H is hidden. PO seems to think that H doesn't
>>> matter because its behaviour can be inferred, but here he is wrong.
>>>
>> PO recently (yesterday?) posted one of his traces with P(P) halting.
>>
>> Inside that trace, we see P call H, and immediately after that in the
>> trace we see NOT H trace entries (all suppressed), but the trace
>> entries from "H simulating the input to H(P,P)" - i.e. exactly the
>> trace entries PO claims are substantially different from the
>> computation steps of P(P) [aka "running" P(P) directly].
>>
>> So, /are/ they substantially different?  NOT IN THE SLIGHTEST!  (As
>> I've suggested a few times, but the evidence is there in PO's own
>> post...)
>>
>> All we see is that H simulating P(P) calculates EXACTLY the same
>> entries as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS
>> SIMULATION.  Not one shred of any evidence of diversion!
>>
>> Of course, it's true we don't see the suppressed H entries, but I
>> don't see any reason to think those would be any different if
>> included.  PO is simply confused by his own code, and invents silly
>> PSR explanations to try to justify it all to himself.  The explanation
>> is obvious to anyone who's analysed - H mistakenly decides it sees
>> non-halting behaviour and so stops simulating, whereas the computation
>> itself (while containing the pattern H spotted - nobody denies that I
>> think) proceeds further and after a short while halts.  (PO's rule is
>> unsound, and why shouldn't it be - he's never felt the need to offer
>> any /proof/ that it's sound.  He just really really really realy
>> thinks it is!)
>>
>
> It is the case that the correct and complete x86 emulation of the input
> to H(P,P) never reaches its "ret" instruction and on this basis it is
> correct to say that it is non-halting.

Except that it DOES if H(P,P) returns 0, as P(P) does, and the
DEFINITION of a correct emulation of a program is to have the same
behavior as the actual program it is emulating.

Thus since P(P) returns when H(P,P) returns 0, the input to H(P,P) in
this case also halts.

You try to claim differently, but that is just junk as it is the
DEFINITION. If H(P,P) isn't refering to P(P), then you have built P
incorrectly, as that is what the Linz "impossible" program is asking for.

If you want to claim it is impossible to ask for, then you H fails just
by that claim.

FAIL.

>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)

Right, THE TURING MACHINE. That is in this model P, with parameter P,
and it Halts if H(P,P) returned 0.

>
>> The most PO could come up with to explain this would be "ok, P(P) and
>> H's simulation of the input to H(P,P) /are/ identical step for step as
>> far as H simulates, so the difference in computation states /must/
>> occur in the computation steps that H never got to!".
>
> I never say anything like that. It is ridiculously simple for any fully
> competent software engineer to easily determine that
>
> the correct and complete x86 emulation of the input to H(P,P) never
> reaches its "ret" instruction.

Nope, it does if H(P,P) aborts its simulation (and thus H doesn't itself
do a correct and complete x86 emulation) and return 0.

You can't have H do BOTH a complete and correct emulation and return 0,

If H(P,P) aborts its simulation, we need to give that exact same input
to an actual correct emulator. Note, this means that P will still call
H, as that is part of the PROBRAM P, which seems to be one of your errors.

>
>>   That's Dumb, Dumb, Dumb thinking, but it wouldn't surprise me if
>> that's what PO eventually comes up with... (He's not capable of
>> thinking it through rationally.)
>>
>>
>> Mike.
>>
>>> As for should we simply dismiss what PO is saying, it's reasonable to
>>> do that to all people who claim to have "solved the halting problem" or
>>> otherwise refuted established results. It's even maybe reasonable to
>>> dismiss people who post on Usenet claiming to have solved long-
>>> standing open problems which aren't known to be insoluble. And that
>>> might be a kindness to the proposer in the long run. But that bridge has
>>> long since been crossed.
>>>
>>
>
>

On 6/14/2022 5:03 AM, Malcolm McLean wrote:
> On Tuesday, 14 June 2022 at 06:04:37 UTC+1, olcott wrote:
>> On 6/13/2022 11:59 PM, André G. Isaak wrote:
>>> On 2022-06-13 21:50, olcott wrote:
>>>> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>>>>> On 2022-06-13 11:51, olcott wrote:
>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>
>>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>>>>> machine address) is able to look though the prior execution trace and
>>>>>>>> see that P is calling H with the same arguments that it was called
>>>>>>>> with and there are no instructions in P that would break this cycle.
>>>>>>> Naive.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>> another forum, thus saying that it is simply Naive carries zero weight.
>>>>>
>>>>> And which forum would that be?
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> That is irrelevant.
>>>
>>> It's certainly relevant to anyone interested in reading those reviews.
>>>
>>> André
>>>
>>>
>> I do appreciate that you are reviewing my work.
>> So you don't feel technically qualified to assess the merits of this
>> directly yourself? The impossibility of finding a valid counter-example
>> disproving the claim counts as proof that the claim is true.
>>
> We're dealing with our hands tied behind our backs, because we can't see H.
> I and other people have suggested an explanation for the results that you
> are seeing. But it can only be a shrewd guess. The behaviour of the program
> depends on how the emulator H is written. If it is in fact an emulator - some
> posters have disputed that. I doubt that they are right and that H is, as you
> describe it, an emulator. But it's impossible to actually prove these people
> wrong.

#include <stdint.h>
typedef void (*ptr)();

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

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

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

(1) It is an easily verified fact that when we assume that H is only an
x86 emulator that the correctly emulated P never reaches its "ret"
instruction.

(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report this.

(3) When the halt status criteria is defined as correctly determining
whether or not an x86 emulated input would ever reach its "ret"
instruction then it becomes an easily verified fact H(P,P) could
correctly reject its input as non-halting.

Correct deductive inference proves that all of these things are true
without any need what-so-ever to see either the source-code or the
execution trace of H.

The one thing that is not proved is whether or not an actual encoded
H(P,P) does indeed correctly determine that its input would never reach
its "ret" instruction as a pure function of its inputs.

--
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 6/15/2022 6:31 PM, Mike Terry wrote:
> On 15/06/2022 11:05, Malcolm McLean wrote:
>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> We're dealing with our hands tied behind our backs, because we can't
>>>> see H.
>>> That's only partly true. A sketch of H was posted and we know that that
>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>> does not report on the "halting" of X(Y). There are other detailed
>>> errors we can't critique without the actual H, but do you really care
>>> about those details?
>>>
>> The current claim is that the direct execution of P(P) has different
>> behavior to the correct simulation of the input to H(P,P).
>> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
>> But that's not possible if H is hidden. PO seems to think that H doesn't
>> matter because its behaviour can be inferred, but here he is wrong.
>>
> PO recently (yesterday?) posted one of his traces with P(P) halting.
>
> Inside that trace, we see P call H, and immediately after that in the
> trace we see NOT H trace entries (all suppressed), but the trace entries
> from "H simulating the input to H(P,P)" - i.e. exactly the trace entries
> PO claims are substantially different from the computation steps of P(P)
> [aka "running" P(P) directly].
>
> So, /are/ they substantially different?  NOT IN THE SLIGHTEST!  (As I've
> suggested a few times, but the evidence is there in PO's own post...)
>
> All we see is that H simulating P(P) calculates EXACTLY the same entries
> as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS SIMULATION.  Not
> one shred of any evidence of diversion!
>
> Of course, it's true we don't see the suppressed H entries, but I don't
> see any reason to think those would be any different if included.  PO is
> simply confused by his own code, and invents silly PSR explanations to
> try to justify it all to himself.  The explanation is obvious to anyone
> who's analysed - H mistakenly decides it sees non-halting behaviour and
> so stops simulating, whereas the computation itself (while containing
> the pattern H spotted - nobody denies that I think) proceeds further and
> after a short while halts.  (PO's rule is unsound, and why shouldn't it
> be - he's never felt the need to offer any /proof/ that it's sound.  He
> just really really really realy thinks it is!)
>
> The most PO could come up with to explain this would be "ok, P(P) and
> H's simulation of the input to H(P,P) /are/ identical step for step as
> far as H simulates, so the difference in computation states /must/ occur
> in the computation steps that H never got to!".   That's Dumb, Dumb,
> Dumb thinking, but it wouldn't surprise me if that's what PO eventually
> comes up with... (He's not capable of thinking it through rationally.)
>
>
> Mike.

#include <stdint.h>
typedef void (*ptr)();

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

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

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

(1) It is an easily verified fact that when we assume that H is only an
x86 emulator that the correctly emulated P never reaches its "ret"
instruction it remains stuck in repeated cycles of emulation.

(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report this.

(3) When the halt status criteria is defined as correctly determining
whether or not an x86 emulated input would ever reach its "ret"
instruction then it becomes an easily verified fact H(P,P) could
correctly reject its input as non-halting.

*technically competent honest reviewers will know that*
Correct deductive inference proves that all of these things are true
without any need what-so-ever to see either the source-code or the
execution trace of H.

The one thing that is not proved is whether or not an actual encoded
H(P,P) does indeed correctly determine that its input would never reach
its "ret" instruction as a pure function of its inputs.

Now that I finally figured out a very simple way to transform H(P,P)==0
into a pure function of its inputs I will be able to provide the
source-code proving this. I refrained from providing the source-code
before because I knew it would be rejected for using static local memory.

Since the above does prove that H(P,P)==0 is correct whether or not H
can compute this and we know that P(P) halts then
*technically competent honest reviewers* will know that the behavior of
the simulated input is not the same as the directly executed input.

--
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 6/16/22 10:31 AM, olcott wrote:
> On 6/15/2022 6:31 PM, Mike Terry wrote:
>> On 15/06/2022 11:05, Malcolm McLean wrote:
>>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> We're dealing with our hands tied behind our backs, because we can't
>>>>> see H.
>>>> That's only partly true. A sketch of H was posted and we know that that
>>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>>> does not report on the "halting" of X(Y). There are other detailed
>>>> errors we can't critique without the actual H, but do you really care
>>>> about those details?
>>>>
>>> The current claim is that the direct execution of P(P) has different
>>> behavior to the correct simulation of the input to H(P,P).
>>> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
>>> But that's not possible if H is hidden. PO seems to think that H doesn't
>>> matter because its behaviour can be inferred, but here he is wrong.
>>>
>> PO recently (yesterday?) posted one of his traces with P(P) halting.
>>
>> Inside that trace, we see P call H, and immediately after that in the
>> trace we see NOT H trace entries (all suppressed), but the trace
>> entries from "H simulating the input to H(P,P)" - i.e. exactly the
>> trace entries PO claims are substantially different from the
>> computation steps of P(P) [aka "running" P(P) directly].
>>
>> So, /are/ they substantially different?  NOT IN THE SLIGHTEST!  (As
>> I've suggested a few times, but the evidence is there in PO's own
>> post...)
>>
>> All we see is that H simulating P(P) calculates EXACTLY the same
>> entries as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS
>> SIMULATION.  Not one shred of any evidence of diversion!
>>
>> Of course, it's true we don't see the suppressed H entries, but I
>> don't see any reason to think those would be any different if
>> included.  PO is simply confused by his own code, and invents silly
>> PSR explanations to try to justify it all to himself.  The explanation
>> is obvious to anyone who's analysed - H mistakenly decides it sees
>> non-halting behaviour and so stops simulating, whereas the computation
>> itself (while containing the pattern H spotted - nobody denies that I
>> think) proceeds further and after a short while halts.  (PO's rule is
>> unsound, and why shouldn't it be - he's never felt the need to offer
>> any /proof/ that it's sound.  He just really really really realy
>> thinks it is!)
>>
>> The most PO could come up with to explain this would be "ok, P(P) and
>> H's simulation of the input to H(P,P) /are/ identical step for step as
>> far as H simulates, so the difference in computation states /must/
>> occur in the computation steps that H never got to!".   That's Dumb,
>> Dumb, Dumb thinking, but it wouldn't surprise me if that's what PO
>> eventually comes up with... (He's not capable of thinking it through
>> rationally.)
>>
>>
>> Mike.
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax              // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx              // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> (1) It is an easily verified fact that when we assume that H is only an
> x86 emulator that the correctly emulated P never reaches its "ret"
> instruction it remains stuck in repeated cycles of emulation.

Right, *IF* H is a pure x86 emulator, P() will not reach the ret
instruciton, but that ONLY applies to a P that calls an H that is
defined to be that.

>
> (2) It is an easily verified fact that if H has been adapted to
> correctly detect (in a finite number of steps) that the correct and
> complete x86 emulation of its input would never each its "ret"
> instruction that H could abort its emulation and return 0 to report this.

Yes, *IF* there actually existed a pattern, that when implemented in H
actually correctly detects that the correct and complete emulation of
the input would never reach its final state, H can abort its emulation
and return. Note, the proof above said that GIVEN this behavior of H,
that the correct an complete emulation by ANOTHER function that is a
pure emulator STILL doesn't reach the return.

THere is no such pattern in P(P), since ANY pattern that H might use and
see in P(P) causes the H called by P(P) to abort its emulaiton and
return 0 to that P which then halts, showing the pattern to be incorrect.

>
> (3) When the halt status criteria is defined as correctly determining
> whether or not an x86 emulated input would ever reach its "ret"
> instruction then it becomes an easily verified fact H(P,P) could
> correctly reject its input as non-halting.

But only if the pattern was correct even if H included that pattern in
its decision. As pointed above, not such pattern actually exists in P(P)
built on the H that has that pattern in it.

>
> *technically competent honest reviewers will know that*
> Correct deductive inference proves that all of these things are true
> without any need what-so-ever to see either the source-code or the
> execution trace of H.

Nope, It has been proved that no pattern exists, thus your "logic" is
incorrect.

>
> The one thing that is not proved is whether or not an actual encoded
> H(P,P) does indeed correctly determine that its input would never reach
> its "ret" instruction as a pure function of its inputs.
>
> Now that I finally figured out a very simple way to transform H(P,P)==0
> into a pure function of its inputs I will be able to provide the
> source-code proving this. I refrained from providing the source-code
> before because I knew it would be rejected for using static local memory.
>
> Since the above does prove that H(P,P)==0 is correct whether or not H
> can compute this and we know that P(P) halts then
> *technically competent honest reviewers* will know that the behavior of
> the simulated input is not the same as the directly executed input.
>
>
>

Nope, just shows you ignorance of the the actual meaning, or that you
are just a liar.

On 6/16/22 9:47 AM, olcott wrote:
> On 6/14/2022 5:03 AM, Malcolm McLean wrote:
>> On Tuesday, 14 June 2022 at 06:04:37 UTC+1, olcott wrote:
>>> On 6/13/2022 11:59 PM, André G. Isaak wrote:
>>>> On 2022-06-13 21:50, olcott wrote:
>>>>> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>>>>>> On 2022-06-13 11:51, olcott wrote:
>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>
>>>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its
>>>>>>>>> own
>>>>>>>>> machine address) is able to look though the prior execution
>>>>>>>>> trace and
>>>>>>>>> see that P is calling H with the same arguments that it was called
>>>>>>>>> with and there are no instructions in P that would break this
>>>>>>>>> cycle.
>>>>>>>> Naive.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>>> another forum, thus saying that it is simply Naive carries zero
>>>>>>> weight.
>>>>>>
>>>>>> And which forum would that be?
>>>>>>
>>>>>> André
>>>>>>
>>>>>>
>>>>>
>>>>> That is irrelevant.
>>>>
>>>> It's certainly relevant to anyone interested in reading those reviews.
>>>>
>>>> André
>>>>
>>>>
>>> I do appreciate that you are reviewing my work.
>>> So you don't feel technically qualified to assess the merits of this
>>> directly yourself? The impossibility of finding a valid counter-example
>>> disproving the claim counts as proof that the claim is true.
>>>
>> We're dealing with our hands tied behind our backs, because we can't
>> see H.
>> I and other people have suggested an explanation for the results that you
>> are seeing. But it can only be a shrewd guess. The behaviour of the
>> program
>> depends on how the emulator H is written. If it is in fact an emulator
>> - some
>> posters have disputed that. I doubt that they are right and that H is,
>> as you
>> describe it, an emulator. But it's impossible to actually prove these
>> people
>> wrong.
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax              // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx              // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> (1) It is an easily verified fact that when we assume that H is only an
> x86 emulator that the correctly emulated P never reaches its "ret"
> instruction.
>
> (2) It is an easily verified fact that if H has been adapted to
> correctly detect (in a finite number of steps) that the correct and
> complete x86 emulation of its input would never each its "ret"
> instruction that H could abort its emulation and return 0 to report this.

And since H is now not the pure x86 emulator, the information from (1)
no longer holds.

>
> (3) When the halt status criteria is defined as correctly determining
> whether or not an x86 emulated input would ever reach its "ret"
> instruction then it becomes an easily verified fact H(P,P) could
> correctly reject its input as non-halting.
>

Such a pattern has been proved to not exist in H's trace of P(P).

> Correct deductive inference proves that all of these things are true
> without any need what-so-ever to see either the source-code or the
> execution trace of H.
>
> The one thing that is not proved is whether or not an actual encoded
> H(P,P) does indeed correctly determine that its input would never reach
> its "ret" instruction as a pure function of its inputs.
>
>

So, you have nothing.