On Sat, 25 Jun 2022 14:39:29 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 2:24 PM, Ben Bacarisse wrote:
> > Paul N <gw7rib@aol.com> writes:
> >
> >> If P(P) returns, then a CORRECT emulation of it will reach the ret
> >> instruction. An emulation that runs forever, when P(P) does not, is
> >> not a correct emulation.
> >
> > You have missed the magic words. We know a few things for certain
> > about PO's ever-so-secret code. One is that whatever it is the
> > latest mantra means "the correct simulation of the input to H(P,P)"
> > is not the same as the correct simulation of P(P). Why? Well PO
> > is explicitly not talking about an H that answers the halting
> > problem, as translated into the language of C functions returning.
> >
> > He hasn't been talking about that for years, but in the past he was
> > too clear. He used to say things like "P(P) only halts because..."
> > as if the reason excused the wrong answer. He used to say that
> > P(P) halts but it would not halt is H didn't stop it (famously "if
> > line 15 were commented out"). All was too obvious.
> >
> > The latest wording is proving more effective at sucking people down
> > the rabbit hole.
> >
>
> A halt decider must compute the mapping from its inputs to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> It is provable that the behavior of the correct and complete x86
> emulation of the input to H(P,P) never halts and the direct execution
> of P(P) halts. H is required to decide on the basis of the former and
> not allowed to decide on the basis of the latter unless it is the
> same as the former.

Richard Damon says:

Which means that P isn't the "impossible program" required by the proof.

P needs to ask H about itself applied to its input.

If H(P,P) isn't that for P(P), then either P isn't defined right to ask
H the proper question, of H isn't interpreeting (sic) its input
correctly.

Either way, you LIE that you are doing things according to the proof.

/Flibble

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > "Dry run" means that a human programmer looks at the code, and determines
>> > what it does, without actually executing it.
>>
>> Going back, now, to what you think needs to be resolved:
>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>> The obvious conclusion is that PO's dry run (if he has indeed done such
>> a thing) is incorrect.
>>
> Exactly.
> We do our little energy budget on tigers, and find that tigers spend
> more energy than they take in. Well potentially this is dynamite. One
> explanation is that the law of conservation of energy is wrong.
> Except, before we countenance that explanation, we need to rule out a
> much simpler explanation. Which is that our measurements are wrong.

Obviously.

> Similarly, PO has worked out what he thinks P(P) should be doing, by
> dry-running it, and then actually run P(P) and obtained a different
> result. He also found that H agreed with the dry run. It's hard to
> paraphrase his conclusion, but it is extensive and far-reaching in its
> implications.

He is just waffling. There is no conclusion, just a constant twisting
and turning to find some why to persuade people that the wrong answer is
the right one. He's being doing this for years with various degrees of
obfuscation.

H does not report the correct result for P(P) and PO is putting up
anything he can think of to keep the discussion going. It should simply
have stopped once he'd been clear that H(P,P) == 0 is correct "even
though P(P) halts" but the traces and the verbiage is keeping people keen.

> The behaviour of code when run is different from the
> correct behaviour of the code when simulated. If that's true, then it
> has similar implications for computer science that disproving the
> conservation law has for physics.

When a student comes to me and says that her program to add 5 and 6
gives 12, I don't, even for a moment, imagine that the laws of logic and
mathematics are in doubt.

> But the obvious explanation is that the dry-run was incorrect. Lots of
> people have suggested why it is incorrect. But they can't actually see
> the code. PO needs to understand that no-one will accept the
> complicated, far-reaching explanation, until the simple explanation
> has been ruled out.

For what it's worth, I don't think there is any "dry run" going on here
at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
knew (correctly) that H could spot what would happen if H did not
"intervene". Everything since then -- the "it only halt because...",
the "it wouldn't halt if line 15 were commented out" and the rather less
explicitly stated "H_Hat does not get to its ret instruction because a
non top-level H aborts" are just the various attempt at after-the-fact
justification.

I agree it's never quite so simple because PO is usually fractally
wrong, so he's not correct about almost everything he says at almost
every level. For example, at one level he now admits that a halt
decider is impossible because H(X,Y) must report "on its input" and the
call X(Y) is not an input! He did this to explain why H(P,P) is
permitted to return 0 "even though P(P) halts", but it also makes it
clear that what he one thought was that halting problem is not solvable.

--
Ben.

On 6/25/22 7:28 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>
> Not to diminish the achievement of getting any clear statements from PO,
> but that's not new. I made a note on June 13th that he'd come clean
> about this:
>
> "Before my research no one was aware of the possibility that the
> correctly simulated input to H(P,P) could possibly have behavior that
> is different than the directly executed P(P)."
>

Which, As I have started to point out, means that his P isn't defined
correctly (and maybe H has limits so it can't be written correctly).

The issue is the actual definition of what P (or H^) needs to b setup to
do is ask H what it will do given its input. This is most often notated
with simething like H(P,P) or H <H^> <H^> or the similar, but these are
just mechanical notations based on how H is expected to interprete its
input, but ultimately, P needs to ask H what P(P) will do.

If it isn't H(P,P), then P needs to be changed to make that request.

If H can't be asked that, then H has just proved it isn't the needed
halt decider, as the needed Halt Decider needs to be able to answer for
ALL Machines (not just all inputs that can be represented to it).

Note also, the question in the requirements is self-referential,
refering by name to the machine to be decided on and the halt decider it
is to use, but in the actual implementation, because Turing machies
don't really support that sort of self-reference, we are actually
running a computation that just happens (by design) ask about the
machine that is the "impossible" machine, built on the Halt Decider that
we just happen to be using.

On 6/25/2022 6:28 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>
> Not to diminish the achievement of getting any clear statements from PO,
> but that's not new. I made a note on June 13th that he'd come clean
> about this:
>
> "Before my research no one was aware of the possibility that the
> correctly simulated input to H(P,P) could possibly have behavior that
> is different than the directly executed P(P)."
>

I still stand by that as most probably true.

(a) What I stand by as absolutely true is that the complete and correct
x86 emulation of the input to H(P,P) by H never reaches the "ret"
instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.

(c) A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.

When we know that (a)(b) and (c) are true then it necessarily follows
that anyone saying that H must decide on the basis of the behavior of
P(P) is necessarily incorrect.

--
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/25/2022 6:28 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>
> Not to diminish the achievement of getting any clear statements from PO,
> but that's not new. I made a note on June 13th that he'd come clean
> about this:
>
> "Before my research no one was aware of the possibility that the
> correctly simulated input to H(P,P) could possibly have behavior that
> is different than the directly executed P(P)."
>

I still stand by that as most probably true.

(a) What I stand by as absolutely true is that the complete and correct
x86 emulation of the input to H(P,P) by H never reaches the "ret"
instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.

(c) A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.

When we know that (a)(b) and (c) are true then it necessarily follows
that anyone saying that H must decide on the basis of the behavior of
P(P) is necessarily incorrect.

--
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/25/2022 6:28 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>
> Not to diminish the achievement of getting any clear statements from PO,
> but that's not new. I made a note on June 13th that he'd come clean
> about this:
>
> "Before my research no one was aware of the possibility that the
> correctly simulated input to H(P,P) could possibly have behavior that
> is different than the directly executed P(P)."
>

I still stand by that as most probably true.

(a) What I stand by as absolutely true is that the complete and correct
x86 emulation of the input to H(P,P) by H never reaches the "ret"
instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.

(c) A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.

When we know that (a)(b) and (c) are true then it necessarily follows
that anyone saying that H must decide on the basis of the behavior of
P(P) is necessarily incorrect.

--
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/25/2022 6:28 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>
> Not to diminish the achievement of getting any clear statements from PO,
> but that's not new. I made a note on June 13th that he'd come clean
> about this:
>
> "Before my research no one was aware of the possibility that the
> correctly simulated input to H(P,P) could possibly have behavior that
> is different than the directly executed P(P)."
>

I still stand by that as most probably true.

(a) What I stand by as absolutely true is that the complete and correct
x86 emulation of the input to H(P,P) by H never reaches the "ret"
instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.

(c) A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.

When we know that (a)(b) and (c) are true then it necessarily follows
that anyone saying that H must decide on the basis of the behavior of
P(P) is necessarily incorrect.

--
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/25/2022 6:55 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> "Dry run" means that a human programmer looks at the code, and determines
>>>> what it does, without actually executing it.
>>>
>>> Going back, now, to what you think needs to be resolved:
>>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>>> The obvious conclusion is that PO's dry run (if he has indeed done such
>>> a thing) is incorrect.
>>>
>> Exactly.
>> We do our little energy budget on tigers, and find that tigers spend
>> more energy than they take in. Well potentially this is dynamite. One
>> explanation is that the law of conservation of energy is wrong.
>> Except, before we countenance that explanation, we need to rule out a
>> much simpler explanation. Which is that our measurements are wrong.
>
> Obviously.
>
>> Similarly, PO has worked out what he thinks P(P) should be doing, by
>> dry-running it, and then actually run P(P) and obtained a different
>> result. He also found that H agreed with the dry run. It's hard to
>> paraphrase his conclusion, but it is extensive and far-reaching in its
>> implications.
>
> He is just waffling. There is no conclusion, just a constant twisting
> and turning to find some why to persuade people that the wrong answer is
> the right one. He's being doing this for years with various degrees of
> obfuscation.
>
> H does not report the correct result for P(P) and PO is putting up
> anything he can think of to keep the discussion going. It should simply
> have stopped once he'd been clear that H(P,P) == 0 is correct "even
> though P(P) halts" but the traces and the verbiage is keeping people keen.
>
>> The behaviour of code when run is different from the
>> correct behaviour of the code when simulated. If that's true, then it
>> has similar implications for computer science that disproving the
>> conservation law has for physics.
>
> When a student comes to me and says that her program to add 5 and 6
> gives 12, I don't, even for a moment, imagine that the laws of logic and
> mathematics are in doubt.
>
>> But the obvious explanation is that the dry-run was incorrect. Lots of
>> people have suggested why it is incorrect. But they can't actually see
>> the code. PO needs to understand that no-one will accept the
>> complicated, far-reaching explanation, until the simple explanation
>> has been ruled out.
>
> For what it's worth, I don't think there is any "dry run" going on here
> at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
> knew (correctly) that H could spot what would happen if H did not
> "intervene". Everything since then -- the "it only halt because...",
> the "it wouldn't halt if line 15 were commented out" and the rather less
> explicitly stated "H_Hat does not get to its ret instruction because a
> non top-level H aborts" are just the various attempt at after-the-fact
> justification.
>
> I agree it's never quite so simple because PO is usually fractally
> wrong, so he's not correct about almost everything he says at almost
> every level. For example, at one level he now admits that a halt
> decider is impossible because H(X,Y) must report "on its input" and the
> call X(Y) is not an input! He did this to explain why H(P,P) is
> permitted to return 0 "even though P(P) halts", but it also makes it
> clear that what he one thought was that halting problem is not solvable.
>

(a) and (b) are proven to be verified facts entirely on the basis of the
semantics of the x86 language. (Most people here do not seem to "believe
in" the semantics of the x86 language otherwise they would have no basis
to disagree).

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

(b) The direct execution of P(P) does reach its "ret" instruction.

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

P(P) is provably not the actual behavior of the actual 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 Sat, 25 Jun 2022 20:07:04 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >
> >> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
> >>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>
> >>>> "Dry run" means that a human programmer looks at the code, and
> >>>> determines what it does, without actually executing it.
> >>>
> >>> Going back, now, to what you think needs to be resolved:
> >>> | He's dry-run P(P) and established that it doesn't halt. He's
> >>> invoked H | on it and H reports that it doesn't halt. He's run
> >>> P(P) and it halts. The obvious conclusion is that PO's dry run
> >>> (if he has indeed done such a thing) is incorrect.
> >>>
> >> Exactly.
> >> We do our little energy budget on tigers, and find that tigers
> >> spend more energy than they take in. Well potentially this is
> >> dynamite. One explanation is that the law of conservation of
> >> energy is wrong. Except, before we countenance that explanation,
> >> we need to rule out a much simpler explanation. Which is that our
> >> measurements are wrong.
> >
> > Obviously.
> >
> >> Similarly, PO has worked out what he thinks P(P) should be doing,
> >> by dry-running it, and then actually run P(P) and obtained a
> >> different result. He also found that H agreed with the dry run.
> >> It's hard to paraphrase his conclusion, but it is extensive and
> >> far-reaching in its implications.
> >
> > He is just waffling. There is no conclusion, just a constant
> > twisting and turning to find some why to persuade people that the
> > wrong answer is the right one. He's being doing this for years
> > with various degrees of obfuscation.
> >
> > H does not report the correct result for P(P) and PO is putting up
> > anything he can think of to keep the discussion going. It should
> > simply have stopped once he'd been clear that H(P,P) == 0 is
> > correct "even though P(P) halts" but the traces and the verbiage is
> > keeping people keen.
> >> The behaviour of code when run is different from the
> >> correct behaviour of the code when simulated. If that's true, then
> >> it has similar implications for computer science that disproving
> >> the conservation law has for physics.
> >
> > When a student comes to me and says that her program to add 5 and 6
> > gives 12, I don't, even for a moment, imagine that the laws of
> > logic and mathematics are in doubt.
> >
> >> But the obvious explanation is that the dry-run was incorrect.
> >> Lots of people have suggested why it is incorrect. But they can't
> >> actually see the code. PO needs to understand that no-one will
> >> accept the complicated, far-reaching explanation, until the simple
> >> explanation has been ruled out.
> >
> > For what it's worth, I don't think there is any "dry run" going on
> > here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
> > because he knew (correctly) that H could spot what would happen if
> > H did not "intervene". Everything since then -- the "it only halt
> > because...", the "it wouldn't halt if line 15 were commented out"
> > and the rather less explicitly stated "H_Hat does not get to its
> > ret instruction because a non top-level H aborts" are just the
> > various attempt at after-the-fact justification.
> >
> > I agree it's never quite so simple because PO is usually fractally
> > wrong, so he's not correct about almost everything he says at almost
> > every level. For example, at one level he now admits that a halt
> > decider is impossible because H(X,Y) must report "on its input" and
> > the call X(Y) is not an input! He did this to explain why H(P,P) is
> > permitted to return 0 "even though P(P) halts", but it also makes it
> > clear that what he one thought was that halting problem is not
> > solvable.
>
> (a) and (b) are proven to be verified facts entirely on the basis of
> the semantics of the x86 language. (Most people here do not seem to
> "believe in" the semantics of the x86 language otherwise they would
> have no basis to disagree).
>
> (a) The complete and correct x86 emulation of the input to H(P,P) by
> H never reaches the "ret" instruction of P.
>
> (b) The direct execution of P(P) does reach its "ret" instruction.
>
> A halt decider must compute the mapping from its inputs to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> P(P) is provably not the actual behavior of the actual input.
(a) is false as the reason the ret instruction is not reached is
incorrect: the ret instruction should not be reached due to the
infinite loop in P and not because you abort the simulation before the
infinite loop is reached. Your H is incorrect in its assumption that P
is pathological because it calls H.

/Flibble

On 6/25/2022 8:16 PM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 20:07:04 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>> determines what it does, without actually executing it.
>>>>>
>>>>> Going back, now, to what you think needs to be resolved:
>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>> (if he has indeed done such a thing) is incorrect.
>>>>>
>>>> Exactly.
>>>> We do our little energy budget on tigers, and find that tigers
>>>> spend more energy than they take in. Well potentially this is
>>>> dynamite. One explanation is that the law of conservation of
>>>> energy is wrong. Except, before we countenance that explanation,
>>>> we need to rule out a much simpler explanation. Which is that our
>>>> measurements are wrong.
>>>
>>> Obviously.
>>>
>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>> by dry-running it, and then actually run P(P) and obtained a
>>>> different result. He also found that H agreed with the dry run.
>>>> It's hard to paraphrase his conclusion, but it is extensive and
>>>> far-reaching in its implications.
>>>
>>> He is just waffling. There is no conclusion, just a constant
>>> twisting and turning to find some why to persuade people that the
>>> wrong answer is the right one. He's being doing this for years
>>> with various degrees of obfuscation.
>>>
>>> H does not report the correct result for P(P) and PO is putting up
>>> anything he can think of to keep the discussion going. It should
>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>> correct "even though P(P) halts" but the traces and the verbiage is
>>> keeping people keen.
>>>> The behaviour of code when run is different from the
>>>> correct behaviour of the code when simulated. If that's true, then
>>>> it has similar implications for computer science that disproving
>>>> the conservation law has for physics.
>>>
>>> When a student comes to me and says that her program to add 5 and 6
>>> gives 12, I don't, even for a moment, imagine that the laws of
>>> logic and mathematics are in doubt.
>>>
>>>> But the obvious explanation is that the dry-run was incorrect.
>>>> Lots of people have suggested why it is incorrect. But they can't
>>>> actually see the code. PO needs to understand that no-one will
>>>> accept the complicated, far-reaching explanation, until the simple
>>>> explanation has been ruled out.
>>>
>>> For what it's worth, I don't think there is any "dry run" going on
>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>> because he knew (correctly) that H could spot what would happen if
>>> H did not "intervene". Everything since then -- the "it only halt
>>> because...", the "it wouldn't halt if line 15 were commented out"
>>> and the rather less explicitly stated "H_Hat does not get to its
>>> ret instruction because a non top-level H aborts" are just the
>>> various attempt at after-the-fact justification.
>>>
>>> I agree it's never quite so simple because PO is usually fractally
>>> wrong, so he's not correct about almost everything he says at almost
>>> every level. For example, at one level he now admits that a halt
>>> decider is impossible because H(X,Y) must report "on its input" and
>>> the call X(Y) is not an input! He did this to explain why H(P,P) is
>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>> clear that what he one thought was that halting problem is not
>>> solvable.
>>
>> (a) and (b) are proven to be verified facts entirely on the basis of
>> the semantics of the x86 language. (Most people here do not seem to
>> "believe in" the semantics of the x86 language otherwise they would
>> have no basis to disagree).
>>
>> (a) The complete and correct x86 emulation of the input to H(P,P) by
>> H never reaches the "ret" instruction of P.
>>
>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>
>> A halt decider must compute the mapping from its inputs to an accept
>> or reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>>
>> P(P) is provably not the actual behavior of the actual input.
>
> (a) is false as the reason the ret instruction is not reached is
> incorrect: the ret instruction should not be reached due to the
> infinite loop in P and not because you abort the simulation before the
> infinite loop is reached. Your H is incorrect in its assumption that P
> is pathological because it calls H.
>
> /Flibble
>

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

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

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

--
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/25/22 8:57 PM, olcott wrote:
> On 6/25/2022 6:28 PM, Ben Bacarisse wrote:
>> Paul N <gw7rib@aol.com> writes:
>>
>>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>>
>>>> The latest wording is proving more effective at sucking people down the
>>>> rabbit hole.
>>>
>>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>>
>>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>>> behavior that is provably different than the the direct execution of
>>>>> P(P).
>>
>> Not to diminish the achievement of getting any clear statements from PO,
>> but that's not new.  I made a note on June 13th that he'd come clean
>> about this:
>>
>>    "Before my research no one was aware of the possibility that the
>>    correctly simulated input to H(P,P) could possibly have behavior that
>>    is different than the directly executed P(P)."
>>
>
> I still stand by that as most probably true.

but it means that P wasn't built right. Remember P with the special
input given to it is supposed to ask H what P does when given that input.

If H(P,P) doesn't ask what P(P) does, (by that being the behavior of the
input to H(P,P)], then P calling H(P,P) says it was designed wrong, and
you need to change that call in P.

If you can't ask H that question, then H just plain fails, as H is
supposed to be able to be asked about ANY computation (Machine/Input
Combination), and not just what H allows its input to represent.

>
> (a) What I stand by as absolutely true is that the complete and correct
> x86 emulation of the input to H(P,P) by H never reaches the "ret"
> instruction of P.

But only if H actaully DOES a complete and correct x86 emulation of that
input. Which means it can't 'abort' its emulation, and thus can't answer
in finite time until you can show how to do an infinite emulation in
finite steos.

When H aborts its emulation and returns 0, then an actual complete and
correct emulation done by an independent emulator shows it will reach
teh ret instruction, just like P(P) does.

>
> (b) The direct execution of P(P) does reach its "ret" instruction.
>
> The above two are proven to be verified facts entirely on the basis of
> the semantics of the x86 language.
>
> (c) A halt decider must compute the mapping from its inputs to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>

No, a Halt Decider must compute the Halting Mapping, from the
computation represented by its input based on the behavior of that
actual machine specified by its input.

> When we know that (a)(b) and (c) are true then it necessarily follows
> that anyone saying that H must decide on the basis of the behavior of
> P(P) is necessarily incorrect.
>

WHY? You have (c) somewhat backwards. The decider determines the way to
specify the input, but once you accept that the input actually specifies
that machine in question, the behavior of the actual machine is controlling.

Part of your problem is that you keep on trying to define an input that
doesn't actually fully specify the machine. Remember the Computation is
more than just the "C function", but includes all of the algorithms of
everything it calls. Thus by your x86 representation, you need to
include the x86 code of everything it calls.

On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> "Dry run" means that a human programmer looks at the code, and determines
>>>> what it does, without actually executing it.
>>>
>>> Going back, now, to what you think needs to be resolved:
>>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>>> The obvious conclusion is that PO's dry run (if he has indeed done such
>>> a thing) is incorrect.
>>>
>> Exactly.
>> We do our little energy budget on tigers, and find that tigers spend
>> more energy than they take in. Well potentially this is dynamite. One
>> explanation is that the law of conservation of energy is wrong.
>> Except, before we countenance that explanation, we need to rule out a
>> much simpler explanation. Which is that our measurements are wrong.
>
> Obviously.
>
>> Similarly, PO has worked out what he thinks P(P) should be doing, by
>> dry-running it, and then actually run P(P) and obtained a different
>> result. He also found that H agreed with the dry run. It's hard to
>> paraphrase his conclusion, but it is extensive and far-reaching in its
>> implications.
>
> He is just waffling. There is no conclusion, just a constant twisting
> and turning to find some why to persuade people that the wrong answer is
> the right one. He's being doing this for years with various degrees of
> obfuscation.
>
> H does not report the correct result for P(P) and PO is putting up
> anything he can think of to keep the discussion going. It should simply
> have stopped once he'd been clear that H(P,P) == 0 is correct "even
> though P(P) halts" but the traces and the verbiage is keeping people keen.
>
>> The behaviour of code when run is different from the
>> correct behaviour of the code when simulated. If that's true, then it
>> has similar implications for computer science that disproving the
>> conservation law has for physics.
>
> When a student comes to me and says that her program to add 5 and 6
> gives 12, I don't, even for a moment, imagine that the laws of logic and
> mathematics are in doubt.
>
>> But the obvious explanation is that the dry-run was incorrect. Lots of
>> people have suggested why it is incorrect. But they can't actually see
>> the code. PO needs to understand that no-one will accept the
>> complicated, far-reaching explanation, until the simple explanation
>> has been ruled out.
>
> For what it's worth, I don't think there is any "dry run" going on here
> at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
> knew (correctly) that H could spot what would happen if H did not
> "intervene". Everything since then -- the "it only halt because...",
> the "it wouldn't halt if line 15 were commented out" and the rather less
> explicitly stated "H_Hat does not get to its ret instruction because a
> non top-level H aborts" are just the various attempt at after-the-fact
> justification.
>
> I agree it's never quite so simple because PO is usually fractally
> wrong, so he's not correct about almost everything he says at almost
> every level. For example, at one level he now admits that a halt
> decider is impossible because H(X,Y) must report "on its input" and the
> call X(Y) is not an input! He did this to explain why H(P,P) is
> permitted to return 0 "even though P(P) halts", but it also makes it
> clear that what he one thought was that halting problem is not solvable.
>

YOU KNOW THAT THIS IS TRUE
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.

YOU ARE THE ONE FUDGING WITH THE TRUTH

--
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 Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >
> >> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
> >>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>
> >>>> "Dry run" means that a human programmer looks at the code, and
> >>>> determines what it does, without actually executing it.
> >>>
> >>> Going back, now, to what you think needs to be resolved:
> >>> | He's dry-run P(P) and established that it doesn't halt. He's
> >>> invoked H | on it and H reports that it doesn't halt. He's run
> >>> P(P) and it halts. The obvious conclusion is that PO's dry run
> >>> (if he has indeed done such a thing) is incorrect.
> >>>
> >> Exactly.
> >> We do our little energy budget on tigers, and find that tigers
> >> spend more energy than they take in. Well potentially this is
> >> dynamite. One explanation is that the law of conservation of
> >> energy is wrong. Except, before we countenance that explanation,
> >> we need to rule out a much simpler explanation. Which is that our
> >> measurements are wrong.
> >
> > Obviously.
> >
> >> Similarly, PO has worked out what he thinks P(P) should be doing,
> >> by dry-running it, and then actually run P(P) and obtained a
> >> different result. He also found that H agreed with the dry run.
> >> It's hard to paraphrase his conclusion, but it is extensive and
> >> far-reaching in its implications.
> >
> > He is just waffling. There is no conclusion, just a constant
> > twisting and turning to find some why to persuade people that the
> > wrong answer is the right one. He's being doing this for years
> > with various degrees of obfuscation.
> >
> > H does not report the correct result for P(P) and PO is putting up
> > anything he can think of to keep the discussion going. It should
> > simply have stopped once he'd been clear that H(P,P) == 0 is
> > correct "even though P(P) halts" but the traces and the verbiage is
> > keeping people keen.
> >> The behaviour of code when run is different from the
> >> correct behaviour of the code when simulated. If that's true, then
> >> it has similar implications for computer science that disproving
> >> the conservation law has for physics.
> >
> > When a student comes to me and says that her program to add 5 and 6
> > gives 12, I don't, even for a moment, imagine that the laws of
> > logic and mathematics are in doubt.
> >
> >> But the obvious explanation is that the dry-run was incorrect.
> >> Lots of people have suggested why it is incorrect. But they can't
> >> actually see the code. PO needs to understand that no-one will
> >> accept the complicated, far-reaching explanation, until the simple
> >> explanation has been ruled out.
> >
> > For what it's worth, I don't think there is any "dry run" going on
> > here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
> > because he knew (correctly) that H could spot what would happen if
> > H did not "intervene". Everything since then -- the "it only halt
> > because...", the "it wouldn't halt if line 15 were commented out"
> > and the rather less explicitly stated "H_Hat does not get to its
> > ret instruction because a non top-level H aborts" are just the
> > various attempt at after-the-fact justification.
> >
> > I agree it's never quite so simple because PO is usually fractally
> > wrong, so he's not correct about almost everything he says at almost
> > every level. For example, at one level he now admits that a halt
> > decider is impossible because H(X,Y) must report "on its input" and
> > the call X(Y) is not an input! He did this to explain why H(P,P) is
> > permitted to return 0 "even though P(P) halts", but it also makes it
> > clear that what he one thought was that halting problem is not
> > solvable.
>
> YOU KNOW THAT THIS IS TRUE
> A halt decider must compute the mapping from its inputs to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> BECAUSE THIS IS PROVABLY TRUE
> P(P) is provably not the actual behavior of the actual input.
>
> YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the pathological
input at issue here are YOUR PATHOLOGICAL LIES, Olcott.

/Flibble

On Sunday, 26 June 2022 at 00:56:03 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> > "Dry run" means that a human programmer looks at the code, and determines
> >> > what it does, without actually executing it.
> >>
> >> Going back, now, to what you think needs to be resolved:
> >> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
> >> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
> >> The obvious conclusion is that PO's dry run (if he has indeed done such
> >> a thing) is incorrect.
> >>
> > Exactly.
> > We do our little energy budget on tigers, and find that tigers spend
> > more energy than they take in. Well potentially this is dynamite. One
> > explanation is that the law of conservation of energy is wrong.
> > Except, before we countenance that explanation, we need to rule out a
> > much simpler explanation. Which is that our measurements are wrong.
> Obviously.
If the tiger experimenters kick up a fuss about showing you their
notebooks, when the notebooks are available and there's no logistical
reason for the refusal, then you can dismiss the idea that they've disproved
the law of conservation of energy out of hand. The two things, together,
an impossible claim and a shifty, evasive attitude make up an overwhelming
case against.
If they are genuinely co-operative and try to help you, then of course it's
different. It's still likely that the explanation is an error, but you keep an open
mind and, if it turns out to be something simple, you try to be as diplomatic
as possible.
>
> I agree it's never quite so simple because PO is usually fractally
> wrong, so he's not correct about almost everything he says at almost
> every level. For example, at one level he now admits that a halt
> decider is impossible because H(X,Y) must report "on its input" and the
> call X(Y) is not an input! He did this to explain why H(P,P) is
> permitted to return 0 "even though P(P) halts", but it also makes it
> clear that what he one thought was that halting problem is not solvable.
>
I think he's tied himself in knots trying to avoid the obvious. Which will happen
if you try to insist that something is true, against all the evidence.

On 6/25/2022 9:03 PM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 20:58:23 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>> determines what it does, without actually executing it.
>>>>>
>>>>> Going back, now, to what you think needs to be resolved:
>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>> (if he has indeed done such a thing) is incorrect.
>>>>>
>>>> Exactly.
>>>> We do our little energy budget on tigers, and find that tigers
>>>> spend more energy than they take in. Well potentially this is
>>>> dynamite. One explanation is that the law of conservation of
>>>> energy is wrong. Except, before we countenance that explanation,
>>>> we need to rule out a much simpler explanation. Which is that our
>>>> measurements are wrong.
>>>
>>> Obviously.
>>>
>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>> by dry-running it, and then actually run P(P) and obtained a
>>>> different result. He also found that H agreed with the dry run.
>>>> It's hard to paraphrase his conclusion, but it is extensive and
>>>> far-reaching in its implications.
>>>
>>> He is just waffling. There is no conclusion, just a constant
>>> twisting and turning to find some why to persuade people that the
>>> wrong answer is the right one. He's being doing this for years
>>> with various degrees of obfuscation.
>>>
>>> H does not report the correct result for P(P) and PO is putting up
>>> anything he can think of to keep the discussion going. It should
>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>> correct "even though P(P) halts" but the traces and the verbiage is
>>> keeping people keen.
>>>> The behaviour of code when run is different from the
>>>> correct behaviour of the code when simulated. If that's true, then
>>>> it has similar implications for computer science that disproving
>>>> the conservation law has for physics.
>>>
>>> When a student comes to me and says that her program to add 5 and 6
>>> gives 12, I don't, even for a moment, imagine that the laws of
>>> logic and mathematics are in doubt.
>>>
>>>> But the obvious explanation is that the dry-run was incorrect.
>>>> Lots of people have suggested why it is incorrect. But they can't
>>>> actually see the code. PO needs to understand that no-one will
>>>> accept the complicated, far-reaching explanation, until the simple
>>>> explanation has been ruled out.
>>>
>>> For what it's worth, I don't think there is any "dry run" going on
>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>> because he knew (correctly) that H could spot what would happen if
>>> H did not "intervene". Everything since then -- the "it only halt
>>> because...", the "it wouldn't halt if line 15 were commented out"
>>> and the rather less explicitly stated "H_Hat does not get to its
>>> ret instruction because a non top-level H aborts" are just the
>>> various attempt at after-the-fact justification.
>>>
>>> I agree it's never quite so simple because PO is usually fractally
>>> wrong, so he's not correct about almost everything he says at almost
>>> every level. For example, at one level he now admits that a halt
>>> decider is impossible because H(X,Y) must report "on its input" and
>>> the call X(Y) is not an input! He did this to explain why H(P,P) is
>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>> clear that what he one thought was that halting problem is not
>>> solvable.
>>
>> YOU KNOW THAT THIS IS TRUE
>> A halt decider must compute the mapping from its inputs to an accept
>> or reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>>
>> BECAUSE THIS IS PROVABLY TRUE
>> P(P) is provably not the actual behavior of the actual input.
>>
>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>
> The issue is what constitutes a pathological input: the pathological
> input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
>
> /Flibble
>

Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the intuitive
notion of
algorithms, in the sense that a function is computable if there
exists an algorithm
that can do the job of the function, i.e. given an input of the
function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function

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

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

That you reject that the above proves that H and P have a pathological
relationship to each other seem to be your lack of technical competence
rather than dishonesty.

--
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/26/2022 5:14 AM, Malcolm McLean wrote:
> On Sunday, 26 June 2022 at 00:56:03 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> "Dry run" means that a human programmer looks at the code, and determines
>>>>> what it does, without actually executing it.
>>>>
>>>> Going back, now, to what you think needs to be resolved:
>>>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
>>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>>>> The obvious conclusion is that PO's dry run (if he has indeed done such
>>>> a thing) is incorrect.
>>>>
>>> Exactly.
>>> We do our little energy budget on tigers, and find that tigers spend
>>> more energy than they take in. Well potentially this is dynamite. One
>>> explanation is that the law of conservation of energy is wrong.
>>> Except, before we countenance that explanation, we need to rule out a
>>> much simpler explanation. Which is that our measurements are wrong.
>> Obviously.
> If the tiger experimenters kick up a fuss about showing you their
> notebooks, when the notebooks are available and there's no logistical
> reason for the refusal, then you can dismiss the idea that they've disproved
> the law of conservation of energy out of hand. The two things, together,
> an impossible claim and a shifty, evasive attitude make up an overwhelming
> case against.

So basically you are utterly clueless that I conclusively proved that
the correct and complete x86 emulation of the input to H(P,P) by H would
never reach its "ret" instruction and the direct execution of P(P) does
reach it "ret" instruction.

You really really believe that I must be wrong yet simply lack the
technical skill to understand the proof that I am right.

I speak verified facts and you and Ben switch to mere rhetoric.

> If they are genuinely co-operative and try to help you, then of course it's
> different. It's still likely that the explanation is an error, but you keep an open
> mind and, if it turns out to be something simple, you try to be as diplomatic
> as possible.
>>
>> I agree it's never quite so simple because PO is usually fractally
>> wrong, so he's not correct about almost everything he says at almost
>> every level. For example, at one level he now admits that a halt
>> decider is impossible because H(X,Y) must report "on its input" and the
>> call X(Y) is not an input! He did this to explain why H(P,P) is
>> permitted to return 0 "even though P(P) halts", but it also makes it
>> clear that what he one thought was that halting problem is not solvable.
>>
> I think he's tied himself in knots trying to avoid the obvious. Which will happen
> if you try to insist that something is true, against all the evidence.

I stick with the verified facts to find the truth and others move toward
mere rhetoric because their purpose is rebuttal and not truth.

A mere lack of software engineering technical competence should result
in questions rather than dogmatic assertions.

--
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 Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 9:03 PM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 20:58:23 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>
> >>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
> >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>
> >>>>>> "Dry run" means that a human programmer looks at the code, and
> >>>>>> determines what it does, without actually executing it.
> >>>>>
> >>>>> Going back, now, to what you think needs to be resolved:
> >>>>> | He's dry-run P(P) and established that it doesn't halt. He's
> >>>>> invoked H | on it and H reports that it doesn't halt. He's run
> >>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
> >>>>> (if he has indeed done such a thing) is incorrect.
> >>>>>
> >>>> Exactly.
> >>>> We do our little energy budget on tigers, and find that tigers
> >>>> spend more energy than they take in. Well potentially this is
> >>>> dynamite. One explanation is that the law of conservation of
> >>>> energy is wrong. Except, before we countenance that explanation,
> >>>> we need to rule out a much simpler explanation. Which is that our
> >>>> measurements are wrong.
> >>>
> >>> Obviously.
> >>>
> >>>> Similarly, PO has worked out what he thinks P(P) should be doing,
> >>>> by dry-running it, and then actually run P(P) and obtained a
> >>>> different result. He also found that H agreed with the dry run.
> >>>> It's hard to paraphrase his conclusion, but it is extensive and
> >>>> far-reaching in its implications.
> >>>
> >>> He is just waffling. There is no conclusion, just a constant
> >>> twisting and turning to find some why to persuade people that the
> >>> wrong answer is the right one. He's being doing this for years
> >>> with various degrees of obfuscation.
> >>>
> >>> H does not report the correct result for P(P) and PO is putting up
> >>> anything he can think of to keep the discussion going. It should
> >>> simply have stopped once he'd been clear that H(P,P) == 0 is
> >>> correct "even though P(P) halts" but the traces and the verbiage
> >>> is keeping people keen.
> >>>> The behaviour of code when run is different from the
> >>>> correct behaviour of the code when simulated. If that's true,
> >>>> then it has similar implications for computer science that
> >>>> disproving the conservation law has for physics.
> >>>
> >>> When a student comes to me and says that her program to add 5 and
> >>> 6 gives 12, I don't, even for a moment, imagine that the laws of
> >>> logic and mathematics are in doubt.
> >>>
> >>>> But the obvious explanation is that the dry-run was incorrect.
> >>>> Lots of people have suggested why it is incorrect. But they can't
> >>>> actually see the code. PO needs to understand that no-one will
> >>>> accept the complicated, far-reaching explanation, until the
> >>>> simple explanation has been ruled out.
> >>>
> >>> For what it's worth, I don't think there is any "dry run" going on
> >>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
> >>> because he knew (correctly) that H could spot what would happen if
> >>> H did not "intervene". Everything since then -- the "it only halt
> >>> because...", the "it wouldn't halt if line 15 were commented out"
> >>> and the rather less explicitly stated "H_Hat does not get to its
> >>> ret instruction because a non top-level H aborts" are just the
> >>> various attempt at after-the-fact justification.
> >>>
> >>> I agree it's never quite so simple because PO is usually fractally
> >>> wrong, so he's not correct about almost everything he says at
> >>> almost every level. For example, at one level he now admits that
> >>> a halt decider is impossible because H(X,Y) must report "on its
> >>> input" and the call X(Y) is not an input! He did this to explain
> >>> why H(P,P) is permitted to return 0 "even though P(P) halts", but
> >>> it also makes it clear that what he one thought was that halting
> >>> problem is not solvable.
> >>
> >> YOU KNOW THAT THIS IS TRUE
> >> A halt decider must compute the mapping from its inputs to an
> >> accept or reject state on the basis of the actual behavior that is
> >> actually specified by these inputs.
> >>
> >> BECAUSE THIS IS PROVABLY TRUE
> >> P(P) is provably not the actual behavior of the actual input.
> >>
> >> YOU ARE THE ONE FUDGING WITH THE TRUTH
> >
> > The issue is what constitutes a pathological input: the pathological
> > input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
> >
> > /Flibble
> >
>
> Computable functions are the basic objects of study in
> computability theory.
> Computable functions are the formalized analogue of the
> intuitive notion of
> algorithms, in the sense that a function is computable if there
> exists an algorithm
> that can do the job of the function, i.e. given an input of the
> function domain it
> can return the corresponding output.
> https://en.wikipedia.org/wiki/Computable_function
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> That you reject that the above proves that H and P have a
> pathological relationship to each other seem to be your lack of
> technical competence rather than dishonesty.
There is nothing wrong with my technical competence however yours *is*
suspect.

Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program"; the problem is you
are redefining what H means such that P no longer calls H as you prevent
that call which is equivalent to H behaving differently depending on
what is calling it: valid halt deciders don't do that. Your H is
erroneous and certainly *not* a pure function as you claim.

Your basic error (which you keep repeating) is your assumption that a
program that calls H is always pathological.

/Flibble

On 6/26/2022 6:15 AM, Mr Flibble wrote:
> On Sun, 26 Jun 2022 05:31:53 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 9:03 PM, Mr Flibble wrote:
>>> On Sat, 25 Jun 2022 20:58:23 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>
>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>>>> determines what it does, without actually executing it.
>>>>>>>
>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>>>> (if he has indeed done such a thing) is incorrect.
>>>>>>>
>>>>>> Exactly.
>>>>>> We do our little energy budget on tigers, and find that tigers
>>>>>> spend more energy than they take in. Well potentially this is
>>>>>> dynamite. One explanation is that the law of conservation of
>>>>>> energy is wrong. Except, before we countenance that explanation,
>>>>>> we need to rule out a much simpler explanation. Which is that our
>>>>>> measurements are wrong.
>>>>>
>>>>> Obviously.
>>>>>
>>>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>>>> by dry-running it, and then actually run P(P) and obtained a
>>>>>> different result. He also found that H agreed with the dry run.
>>>>>> It's hard to paraphrase his conclusion, but it is extensive and
>>>>>> far-reaching in its implications.
>>>>>
>>>>> He is just waffling. There is no conclusion, just a constant
>>>>> twisting and turning to find some why to persuade people that the
>>>>> wrong answer is the right one. He's being doing this for years
>>>>> with various degrees of obfuscation.
>>>>>
>>>>> H does not report the correct result for P(P) and PO is putting up
>>>>> anything he can think of to keep the discussion going. It should
>>>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>>>> correct "even though P(P) halts" but the traces and the verbiage
>>>>> is keeping people keen.
>>>>>> The behaviour of code when run is different from the
>>>>>> correct behaviour of the code when simulated. If that's true,
>>>>>> then it has similar implications for computer science that
>>>>>> disproving the conservation law has for physics.
>>>>>
>>>>> When a student comes to me and says that her program to add 5 and
>>>>> 6 gives 12, I don't, even for a moment, imagine that the laws of
>>>>> logic and mathematics are in doubt.
>>>>>
>>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>>> Lots of people have suggested why it is incorrect. But they can't
>>>>>> actually see the code. PO needs to understand that no-one will
>>>>>> accept the complicated, far-reaching explanation, until the
>>>>>> simple explanation has been ruled out.
>>>>>
>>>>> For what it's worth, I don't think there is any "dry run" going on
>>>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>>>> because he knew (correctly) that H could spot what would happen if
>>>>> H did not "intervene". Everything since then -- the "it only halt
>>>>> because...", the "it wouldn't halt if line 15 were commented out"
>>>>> and the rather less explicitly stated "H_Hat does not get to its
>>>>> ret instruction because a non top-level H aborts" are just the
>>>>> various attempt at after-the-fact justification.
>>>>>
>>>>> I agree it's never quite so simple because PO is usually fractally
>>>>> wrong, so he's not correct about almost everything he says at
>>>>> almost every level. For example, at one level he now admits that
>>>>> a halt decider is impossible because H(X,Y) must report "on its
>>>>> input" and the call X(Y) is not an input! He did this to explain
>>>>> why H(P,P) is permitted to return 0 "even though P(P) halts", but
>>>>> it also makes it clear that what he one thought was that halting
>>>>> problem is not solvable.
>>>>
>>>> YOU KNOW THAT THIS IS TRUE
>>>> A halt decider must compute the mapping from its inputs to an
>>>> accept or reject state on the basis of the actual behavior that is
>>>> actually specified by these inputs.
>>>>
>>>> BECAUSE THIS IS PROVABLY TRUE
>>>> P(P) is provably not the actual behavior of the actual input.
>>>>
>>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>>>
>>> The issue is what constitutes a pathological input: the pathological
>>> input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
>>>
>>> /Flibble
>>>
>>
>> Computable functions are the basic objects of study in
>> computability theory.
>> Computable functions are the formalized analogue of the
>> intuitive notion of
>> algorithms, in the sense that a function is computable if there
>> exists an algorithm
>> that can do the job of the function, i.e. given an input of the
>> function domain it
>> can return the corresponding output.
>> https://en.wikipedia.org/wiki/Computable_function
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> That you reject that the above proves that H and P have a
>> pathological relationship to each other seem to be your lack of
>> technical competence rather than dishonesty.
>
> There is nothing wrong with my technical competence however yours *is*
> suspect.
>
> Nobody is denying that P is pathological input as its comes
> from [Strachey, 1965]'s "Impossible Program";

// rec routine P
// §L :if T[P] go to L
// Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{ L:if (T(Strachey_P))
goto L;
return;
}

int main()
{ Output("Input_Halts = ", T(Strachey_P));
}

_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015ba](05) e813fdffff call 000012d2 // call T
[000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]

_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015da](05) e8f3fcffff call 000012d2 // call T
[000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push Strachey_P
[000015da][001025be][000015df] e8f3fcffff call 000012d2 // call T

On 6/25/22 9:36 PM, olcott wrote:
> On 6/25/2022 8:16 PM, Mr Flibble wrote:
>> On Sat, 25 Jun 2022 20:07:04 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>>> determines what it does, without actually executing it.
>>>>>>
>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>>> (if he has indeed done such a thing) is incorrect.
>>>>> Exactly.
>>>>> We do our little energy budget on tigers, and find that tigers
>>>>> spend more energy than they take in. Well potentially this is
>>>>> dynamite. One explanation is that the law of conservation of
>>>>> energy is wrong. Except, before we countenance that explanation,
>>>>> we need to rule out a much simpler explanation. Which is that our
>>>>> measurements are wrong.
>>>>
>>>> Obviously.
>>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>>> by dry-running it, and then actually run P(P) and obtained a
>>>>> different result. He also found that H agreed with the dry run.
>>>>> It's hard to paraphrase his conclusion, but it is extensive and
>>>>> far-reaching in its implications.
>>>>
>>>> He is just waffling.  There is no conclusion, just a constant
>>>> twisting and turning to find some why to persuade people that the
>>>> wrong answer is the right one.  He's being doing this for years
>>>> with various degrees of obfuscation.
>>>>
>>>> H does not report the correct result for P(P) and PO is putting up
>>>> anything he can think of to keep the discussion going.  It should
>>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>>> correct "even though P(P) halts" but the traces and the verbiage is
>>>> keeping people keen.
>>>>> The behaviour of code when run is different from the
>>>>> correct behaviour of the code when simulated. If that's true, then
>>>>> it has similar implications for computer science that disproving
>>>>> the conservation law has for physics.
>>>>
>>>> When a student comes to me and says that her program to add 5 and 6
>>>> gives 12, I don't, even for a moment, imagine that the laws of
>>>> logic and mathematics are in doubt.
>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>> Lots of people have suggested why it is incorrect. But they can't
>>>>> actually see the code. PO needs to understand that no-one will
>>>>> accept the complicated, far-reaching explanation, until the simple
>>>>> explanation has been ruled out.
>>>>
>>>> For what it's worth, I don't think there is any "dry run" going on
>>>> here at all.  PO decide years ago that H(H_Hat, H_Hat) would be 0
>>>> because he knew (correctly) that H could spot what would happen if
>>>> H did not "intervene".  Everything since then -- the "it only halt
>>>> because...", the "it wouldn't halt if line 15 were commented out"
>>>> and the rather less explicitly stated "H_Hat does not get to its
>>>> ret instruction because a non top-level H aborts" are just the
>>>> various attempt at after-the-fact justification.
>>>>
>>>> I agree it's never quite so simple because PO is usually fractally
>>>> wrong, so he's not correct about almost everything he says at almost
>>>> every level.  For example, at one level he now admits that a halt
>>>> decider is impossible because H(X,Y) must report "on its input" and
>>>> the call X(Y) is not an input!  He did this to explain why H(P,P) is
>>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>>> clear that what he one thought was that halting problem is not
>>>> solvable.
>>>
>>> (a) and (b) are proven to be verified facts entirely on the basis of
>>> the semantics of the x86 language. (Most people here do not seem to
>>> "believe in" the semantics of the x86 language otherwise they would
>>> have no basis to disagree).
>>>
>>> (a) The complete and correct x86 emulation of the input to H(P,P) by
>>> H never reaches the "ret" instruction of P.
>>>
>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>
>>> A halt decider must compute the mapping from its inputs to an accept
>>> or reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>>
>>> P(P) is provably not the actual behavior of the actual input.
>> (a) is false as the reason the ret instruction is not reached is
>> incorrect: the ret instruction should not be reached due to the
>> infinite loop in P and not because you abort the simulation before the
>> infinite loop is reached.  Your H is incorrect in its assumption that P
>> is pathological because it calls H.
>>
>> /Flibble
>>
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
>

The problem is that your "proof" of (a) is based on an "H" that ONLY
does a complete and correct emulation of its input, before making a
halting decision.

Yes, for such an H, the P built on it will be non-halting, that that H
can't report that fact, and in fact, NEVER reports that ANY non-halting
input is non-halting. That makes it not a decider.

When you fix that problem, by having your new H abort its processing, it
is a DIFFERENT H than the one above. That difference matter, and you new
H is incorrect to consider that its input P, built on it is the same as
the P that was built on the other input H. You seem to be confused
becaue they are both called H.

You claim to be working under the intrepretaton of the C languge. The C
language PROHIBITS the presence of two functions by the same name in one
translation unit, or with global scope in the same program, sine there
is no "H with static scope listed in the file for P, it MUST be a
global scope H, and thus the only H that P can call is the one deciding
on it, which if you claim your H (P,P) is returning 0, must be the one
that aborts, and thus NOT the one that does the complete and correct
emulation and gets stuck in the infinite recursion.

It is also clear that you are lying about H doing a correct x86
emulation of its input, because at the x86 level, the call to H should
create an emulation of the x86 CODE of H, not reverting to some
"functional equivalent" converting it to a notation that it is emulating
P again. Maybe that just shows that YOU don't understand what x86
assembly code actually does. "Call H" does NOT do a emulataion at the
x86 level, it runs an emulator that it should be tracing.

THe fact that (b) shows the x86 assembly code actually does reach its
"ret" instruction means you need to point out where the emulation of the
input and the direct execution diverge, which is at the call H
instruction, which the emulation DOES'T correctly process as pointed
above, and thus your claim of a is shown to be a LIE.

On 6/25/22 9:58 PM, olcott wrote:
> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>> determines
>>>>> what it does, without actually executing it.
>>>>
>>>> Going back, now, to what you think needs to be resolved:
>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>> invoked H
>>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>>>> The obvious conclusion is that PO's dry run (if he has indeed done such
>>>> a thing) is incorrect.
>>>>
>>> Exactly.
>>> We do our little energy budget on tigers, and find that tigers spend
>>> more energy than they take in. Well potentially this is dynamite. One
>>> explanation is that the law of conservation of energy is wrong.
>>> Except, before we countenance that explanation, we need to rule out a
>>> much simpler explanation. Which is that our measurements are wrong.
>>
>> Obviously.
>>
>>> Similarly, PO has worked out what he thinks P(P) should be doing, by
>>> dry-running it, and then actually run P(P) and obtained a different
>>> result. He also found that H agreed with the dry run. It's hard to
>>> paraphrase his conclusion, but it is extensive and far-reaching in its
>>> implications.
>>
>> He is just waffling.  There is no conclusion, just a constant twisting
>> and turning to find some why to persuade people that the wrong answer is
>> the right one.  He's being doing this for years with various degrees of
>> obfuscation.
>>
>> H does not report the correct result for P(P) and PO is putting up
>> anything he can think of to keep the discussion going.  It should simply
>> have stopped once he'd been clear that H(P,P) == 0 is correct "even
>> though P(P) halts" but the traces and the verbiage is keeping people
>> keen.
>>
>>> The behaviour of code when run is different from the
>>> correct behaviour of the code when simulated. If that's true, then it
>>> has similar implications for computer science that disproving the
>>> conservation law has for physics.
>>
>> When a student comes to me and says that her program to add 5 and 6
>> gives 12, I don't, even for a moment, imagine that the laws of logic and
>> mathematics are in doubt.
>>
>>> But the obvious explanation is that the dry-run was incorrect. Lots of
>>> people have suggested why it is incorrect. But they can't actually see
>>> the code. PO needs to understand that no-one will accept the
>>> complicated, far-reaching explanation, until the simple explanation
>>> has been ruled out.
>>
>> For what it's worth, I don't think there is any "dry run" going on here
>> at all.  PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
>> knew (correctly) that H could spot what would happen if H did not
>> "intervene".  Everything since then -- the "it only halt because...",
>> the "it wouldn't halt if line 15 were commented out" and the rather less
>> explicitly stated "H_Hat does not get to its ret instruction because a
>> non top-level H aborts" are just the various attempt at after-the-fact
>> justification.
>>
>> I agree it's never quite so simple because PO is usually fractally
>> wrong, so he's not correct about almost everything he says at almost
>> every level.  For example, at one level he now admits that a halt
>> decider is impossible because H(X,Y) must report "on its input" and the
>> call X(Y) is not an input!  He did this to explain why H(P,P) is
>> permitted to return 0 "even though P(P) halts", but it also makes it
>> clear that what he one thought was that halting problem is not solvable.
>>
>
> YOU KNOW THAT THIS IS TRUE
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> BECAUSE THIS IS PROVABLY TRUE
> P(P) is provably not the actual behavior of the actual input.
>
> YOU ARE THE ONE FUDGING WITH THE TRUTH
>

Then you are lying that P and H are defined as required.

P is defined, that when given a description of itself, to ask H about
itself applied to its input. Since you say P calls H(P,P), it that
doesn't mean H is to decide on P(P), then P wasn't defined correctly,
and YOU made the error.

If H can't be asked about P(P), then H is proven to be defined
incorrectly as H must be able to be asked about ANY compuputation, that
being a program with any input, and P is a program, at least as long as
H meets the requriements for being a program.

Thus, if the input to H(P,P) is proved to have different behaviot than
P(P, you have just proved that your "counter example" fails to meet the
requirements, and thus isn't a counter example.

Thus YOU are the one shown to be not being Truthful, since your own
proof just proves that you lied about other things.

FAIL.

LIAR.

On Sun, 26 Jun 2022 14:40:26 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 6/25/22 9:36 PM, olcott wrote:
> > On 6/25/2022 8:16 PM, Mr Flibble wrote:
> >> On Sat, 25 Jun 2022 20:07:04 -0500
> >> olcott <NoOne@NoWhere.com> wrote:
> >>
> >>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
> >>>>>
> >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>> "Dry run" means that a human programmer looks at the code, and
> >>>>>>> determines what it does, without actually executing it.
> >>>>>>
> >>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
> >>>>>> invoked H | on it and H reports that it doesn't halt. He's run
> >>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
> >>>>>> (if he has indeed done such a thing) is incorrect.
> >>>>> Exactly.
> >>>>> We do our little energy budget on tigers, and find that tigers
> >>>>> spend more energy than they take in. Well potentially this is
> >>>>> dynamite. One explanation is that the law of conservation of
> >>>>> energy is wrong. Except, before we countenance that explanation,
> >>>>> we need to rule out a much simpler explanation. Which is that
> >>>>> our measurements are wrong.
> >>>>
> >>>> Obviously.
> >>>>> Similarly, PO has worked out what he thinks P(P) should be
> >>>>> doing, by dry-running it, and then actually run P(P) and
> >>>>> obtained a different result. He also found that H agreed with
> >>>>> the dry run. It's hard to paraphrase his conclusion, but it is
> >>>>> extensive and far-reaching in its implications.
> >>>>
> >>>> He is just waffling.  There is no conclusion, just a constant
> >>>> twisting and turning to find some why to persuade people that the
> >>>> wrong answer is the right one.  He's being doing this for years
> >>>> with various degrees of obfuscation.
> >>>>
> >>>> H does not report the correct result for P(P) and PO is putting
> >>>> up anything he can think of to keep the discussion going.  It
> >>>> should simply have stopped once he'd been clear that H(P,P) == 0
> >>>> is correct "even though P(P) halts" but the traces and the
> >>>> verbiage is keeping people keen.
> >>>>> The behaviour of code when run is different from the
> >>>>> correct behaviour of the code when simulated. If that's true,
> >>>>> then it has similar implications for computer science that
> >>>>> disproving the conservation law has for physics.
> >>>>
> >>>> When a student comes to me and says that her program to add 5
> >>>> and 6 gives 12, I don't, even for a moment, imagine that the
> >>>> laws of logic and mathematics are in doubt.
> >>>>> But the obvious explanation is that the dry-run was incorrect.
> >>>>> Lots of people have suggested why it is incorrect. But they
> >>>>> can't actually see the code. PO needs to understand that no-one
> >>>>> will accept the complicated, far-reaching explanation, until
> >>>>> the simple explanation has been ruled out.
> >>>>
> >>>> For what it's worth, I don't think there is any "dry run" going
> >>>> on here at all.  PO decide years ago that H(H_Hat, H_Hat) would
> >>>> be 0 because he knew (correctly) that H could spot what would
> >>>> happen if H did not "intervene".  Everything since then -- the
> >>>> "it only halt because...", the "it wouldn't halt if line 15 were
> >>>> commented out" and the rather less explicitly stated "H_Hat does
> >>>> not get to its ret instruction because a non top-level H aborts"
> >>>> are just the various attempt at after-the-fact justification.
> >>>>
> >>>> I agree it's never quite so simple because PO is usually
> >>>> fractally wrong, so he's not correct about almost everything he
> >>>> says at almost every level.  For example, at one level he now
> >>>> admits that a halt decider is impossible because H(X,Y) must
> >>>> report "on its input" and the call X(Y) is not an input!  He did
> >>>> this to explain why H(P,P) is permitted to return 0 "even though
> >>>> P(P) halts", but it also makes it clear that what he one thought
> >>>> was that halting problem is not solvable.
> >>>
> >>> (a) and (b) are proven to be verified facts entirely on the basis
> >>> of the semantics of the x86 language. (Most people here do not
> >>> seem to "believe in" the semantics of the x86 language otherwise
> >>> they would have no basis to disagree).
> >>>
> >>> (a) The complete and correct x86 emulation of the input to H(P,P)
> >>> by H never reaches the "ret" instruction of P.
> >>>
> >>> (b) The direct execution of P(P) does reach its "ret" instruction.
> >>>
> >>> A halt decider must compute the mapping from its inputs to an
> >>> accept or reject state on the basis of the actual behavior that
> >>> is actually specified by these inputs.
> >>>
> >>> P(P) is provably not the actual behavior of the actual input.
> >> (a) is false as the reason the ret instruction is not reached is
> >> incorrect: the ret instruction should not be reached due to the
> >> infinite loop in P and not because you abort the simulation before
> >> the infinite loop is reached.  Your H is incorrect in its
> >> assumption that P is pathological because it calls H.
> >>
> >> /Flibble
> >>
> >
> >      For any program H that might determine if programs halt, a
> > "pathological"
> >      program P, called with some input, can pass its own source
> > and its input to
> >      H and then specifically do the opposite of what H predicts P
> > will do. No H
> >      can exist that handles this case.
> > https://en.wikipedia.org/wiki/Halting_problem
> >
> >
> > void P(u32 x)
> > {
> >   if (H(x, x))
> >     HERE: goto HERE;
> >   return;
> > }
> >
> > int main()
> > {
> >   Output("Input_Halts = ", H((u32)P, (u32)P));
> > }
> >
> >
>
> The problem is that your "proof" of (a) is based on an "H" that ONLY
> does a complete and correct emulation of its input, before making a
> halting decision.
>
> Yes, for such an H, the P built on it will be non-halting, that that
> H can't report that fact, and in fact, NEVER reports that ANY
> non-halting input is non-halting. That makes it not a decider.
>
> When you fix that problem, by having your new H abort its processing,
> it is a DIFFERENT H than the one above. That difference matter, and
> you new H is incorrect to consider that its input P, built on it is
> the same as the P that was built on the other input H. You seem to be
> confused becaue they are both called H.
>
> You claim to be working under the intrepretaton of the C languge. The
> C language PROHIBITS the presence of two functions by the same name
> in one translation unit, or with global scope in the same program,
> sine there is no "H with static scope listed in the file for P, it
> MUST be a global scope H, and thus the only H that P can call is the
> one deciding on it, which if you claim your H (P,P) is returning 0,
> must be the one that aborts, and thus NOT the one that does the
> complete and correct emulation and gets stuck in the infinite
> recursion.
>
> It is also clear that you are lying about H doing a correct x86
> emulation of its input, because at the x86 level, the call to H
> should create an emulation of the x86 CODE of H, not reverting to
> some "functional equivalent" converting it to a notation that it is
> emulating P again. Maybe that just shows that YOU don't understand
> what x86 assembly code actually does. "Call H" does NOT do a
> emulataion at the x86 level, it runs an emulator that it should be
> tracing.
>
> THe fact that (b) shows the x86 assembly code actually does reach its
> "ret" instruction means you need to point out where the emulation of
> the input and the direct execution diverge, which is at the call H
> instruction, which the emulation DOES'T correctly process as pointed
> above, and thus your claim of a is shown to be a LIE.

On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/26/2022 6:15 AM, Mr Flibble wrote:
> > On Sun, 26 Jun 2022 05:31:53 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 9:03 PM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 20:58:23 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>>
> >>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
> >>>>>> wrote:
> >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>
> >>>>>>>> "Dry run" means that a human programmer looks at the code,
> >>>>>>>> and determines what it does, without actually executing it.
> >>>>>>>
> >>>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
> >>>>>>> invoked H | on it and H reports that it doesn't halt. He's run
> >>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
> >>>>>>> (if he has indeed done such a thing) is incorrect.
> >>>>>>>
> >>>>>> Exactly.
> >>>>>> We do our little energy budget on tigers, and find that tigers
> >>>>>> spend more energy than they take in. Well potentially this is
> >>>>>> dynamite. One explanation is that the law of conservation of
> >>>>>> energy is wrong. Except, before we countenance that
> >>>>>> explanation, we need to rule out a much simpler explanation.
> >>>>>> Which is that our measurements are wrong.
> >>>>>
> >>>>> Obviously.
> >>>>>
> >>>>>> Similarly, PO has worked out what he thinks P(P) should be
> >>>>>> doing, by dry-running it, and then actually run P(P) and
> >>>>>> obtained a different result. He also found that H agreed with
> >>>>>> the dry run. It's hard to paraphrase his conclusion, but it is
> >>>>>> extensive and far-reaching in its implications.
> >>>>>
> >>>>> He is just waffling. There is no conclusion, just a constant
> >>>>> twisting and turning to find some why to persuade people that
> >>>>> the wrong answer is the right one. He's being doing this for
> >>>>> years with various degrees of obfuscation.
> >>>>>
> >>>>> H does not report the correct result for P(P) and PO is putting
> >>>>> up anything he can think of to keep the discussion going. It
> >>>>> should simply have stopped once he'd been clear that H(P,P) => >>>>> 0 is correct "even though P(P) halts" but the traces and the
> >>>>> verbiage is keeping people keen.
> >>>>>> The behaviour of code when run is different from the
> >>>>>> correct behaviour of the code when simulated. If that's true,
> >>>>>> then it has similar implications for computer science that
> >>>>>> disproving the conservation law has for physics.
> >>>>>
> >>>>> When a student comes to me and says that her program to add 5
> >>>>> and 6 gives 12, I don't, even for a moment, imagine that the
> >>>>> laws of logic and mathematics are in doubt.
> >>>>>
> >>>>>> But the obvious explanation is that the dry-run was incorrect.
> >>>>>> Lots of people have suggested why it is incorrect. But they
> >>>>>> can't actually see the code. PO needs to understand that
> >>>>>> no-one will accept the complicated, far-reaching explanation,
> >>>>>> until the simple explanation has been ruled out.
> >>>>>
> >>>>> For what it's worth, I don't think there is any "dry run" going
> >>>>> on here at all. PO decide years ago that H(H_Hat, H_Hat) would
> >>>>> be 0 because he knew (correctly) that H could spot what would
> >>>>> happen if H did not "intervene". Everything since then -- the
> >>>>> "it only halt because...", the "it wouldn't halt if line 15
> >>>>> were commented out" and the rather less explicitly stated
> >>>>> "H_Hat does not get to its ret instruction because a non
> >>>>> top-level H aborts" are just the various attempt at
> >>>>> after-the-fact justification.
> >>>>>
> >>>>> I agree it's never quite so simple because PO is usually
> >>>>> fractally wrong, so he's not correct about almost everything he
> >>>>> says at almost every level. For example, at one level he now
> >>>>> admits that a halt decider is impossible because H(X,Y) must
> >>>>> report "on its input" and the call X(Y) is not an input! He
> >>>>> did this to explain why H(P,P) is permitted to return 0 "even
> >>>>> though P(P) halts", but it also makes it clear that what he one
> >>>>> thought was that halting problem is not solvable.
> >>>>
> >>>> YOU KNOW THAT THIS IS TRUE
> >>>> A halt decider must compute the mapping from its inputs to an
> >>>> accept or reject state on the basis of the actual behavior that
> >>>> is actually specified by these inputs.
> >>>>
> >>>> BECAUSE THIS IS PROVABLY TRUE
> >>>> P(P) is provably not the actual behavior of the actual input.
> >>>>
> >>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
> >>>
> >>> The issue is what constitutes a pathological input: the
> >>> pathological input at issue here are YOUR PATHOLOGICAL LIES,
> >>> Olcott.
> >>>
> >>> /Flibble
> >>>
> >>
> >> Computable functions are the basic objects of study in
> >> computability theory.
> >> Computable functions are the formalized analogue of the
> >> intuitive notion of
> >> algorithms, in the sense that a function is computable if
> >> there exists an algorithm
> >> that can do the job of the function, i.e. given an input of
> >> the function domain it
> >> can return the corresponding output.
> >> https://en.wikipedia.org/wiki/Computable_function
> >>
> >> void P(u32 x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H((u32)P, (u32)P));
> >> }
> >>
> >> That you reject that the above proves that H and P have a
> >> pathological relationship to each other seem to be your lack of
> >> technical competence rather than dishonesty.
> >
> > There is nothing wrong with my technical competence however yours
> > *is* suspect.
> >
> > Nobody is denying that P is pathological input as its comes
> > from [Strachey, 1965]'s "Impossible Program";
>
> // rec routine P
> // §L :if T[P] go to L
> // Return §
> // https://academic.oup.com/comjnl/article/7/4/313/354243
> void Strachey_P()
> {
> L:if (T(Strachey_P))
> goto L;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", T(Strachey_P));
> }
>
> _Strachey_P()
> [000015b2](01) 55 push ebp
> [000015b3](02) 8bec mov ebp,esp
> [000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
> [000015ba](05) e813fdffff call 000012d2 // call T
> [000015bf](03) 83c404 add esp,+04
> [000015c2](02) 85c0 test eax,eax
> [000015c4](02) 7402 jz 000015c8
> [000015c6](02) ebed jmp 000015b5
> [000015c8](01) 5d pop ebp
> [000015c9](01) c3 ret
> Size in bytes:(0024) [000015c9]
>
> _main()
> [000015d2](01) 55 push ebp
> [000015d3](02) 8bec mov ebp,esp
> [000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
> [000015da](05) e8f3fcffff call 000012d2 // call T
> [000015df](03) 83c404 add esp,+04
> [000015e2](01) 50 push eax
> [000015e3](05) 6833040000 push 00000433
> [000015e8](05) e895eeffff call 00000482
> [000015ed](03) 83c408 add esp,+08
> [000015f0](02) 33c0 xor eax,eax
> [000015f2](01) 5d pop ebp
> [000015f3](01) c3 ret
> Size in bytes:(0034) [000015f3]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= ============> [000015d2][001025c6][00000000] 55 push ebp
> [000015d3][001025c6][00000000] 8bec mov ebp,esp
> [000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
> Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2 //
> call T
>
> Begin Simulation Execution Trace Stored at:21267a
> Address_of_T:12d2
> [000015b2][0021266a][0021266e] 55 push ebp
> [000015b3][0021266a][0021266e] 8bec mov ebp,esp
> [000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
> Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2 //
> call T Infinitely Recursive Simulation Detected Simulation Stopped
>
> T knows its own machine address and on this basis it can easily
> examine its stored execution_trace of Strachey_P (see above) to
> determine: (a) Strachey_P is calling T with the same arguments that T
> was called with. (b) No instructions in Strachey_P could possibly
> escape this otherwise infinitely recursive emulation.

On Sun, 26 Jun 2022 14:56:02 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 6/25/22 9:58 PM, olcott wrote:
> > On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>
> >>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
> >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>
> >>>>> "Dry run" means that a human programmer looks at the code, and
> >>>>> determines
> >>>>> what it does, without actually executing it.
> >>>>
> >>>> Going back, now, to what you think needs to be resolved:
> >>>> | He's dry-run P(P) and established that it doesn't halt. He's
> >>>> invoked H
> >>>> | on it and H reports that it doesn't halt. He's run P(P) and it
> >>>> halts. The obvious conclusion is that PO's dry run (if he has
> >>>> indeed done such a thing) is incorrect.
> >>>>
> >>> Exactly.
> >>> We do our little energy budget on tigers, and find that tigers
> >>> spend more energy than they take in. Well potentially this is
> >>> dynamite. One explanation is that the law of conservation of
> >>> energy is wrong. Except, before we countenance that explanation,
> >>> we need to rule out a much simpler explanation. Which is that our
> >>> measurements are wrong.
> >>
> >> Obviously.
> >>
> >>> Similarly, PO has worked out what he thinks P(P) should be doing,
> >>> by dry-running it, and then actually run P(P) and obtained a
> >>> different result. He also found that H agreed with the dry run.
> >>> It's hard to paraphrase his conclusion, but it is extensive and
> >>> far-reaching in its implications.
> >>
> >> He is just waffling.  There is no conclusion, just a constant
> >> twisting and turning to find some why to persuade people that the
> >> wrong answer is the right one.  He's being doing this for years
> >> with various degrees of obfuscation.
> >>
> >> H does not report the correct result for P(P) and PO is putting up
> >> anything he can think of to keep the discussion going.  It should
> >> simply have stopped once he'd been clear that H(P,P) == 0 is
> >> correct "even though P(P) halts" but the traces and the verbiage
> >> is keeping people keen.
> >>
> >>> The behaviour of code when run is different from the
> >>> correct behaviour of the code when simulated. If that's true,
> >>> then it has similar implications for computer science that
> >>> disproving the conservation law has for physics.
> >>
> >> When a student comes to me and says that her program to add 5 and 6
> >> gives 12, I don't, even for a moment, imagine that the laws of
> >> logic and mathematics are in doubt.
> >>
> >>> But the obvious explanation is that the dry-run was incorrect.
> >>> Lots of people have suggested why it is incorrect. But they can't
> >>> actually see the code. PO needs to understand that no-one will
> >>> accept the complicated, far-reaching explanation, until the
> >>> simple explanation has been ruled out.
> >>
> >> For what it's worth, I don't think there is any "dry run" going on
> >> here at all.  PO decide years ago that H(H_Hat, H_Hat) would be 0
> >> because he knew (correctly) that H could spot what would happen if
> >> H did not "intervene".  Everything since then -- the "it only halt
> >> because...", the "it wouldn't halt if line 15 were commented out"
> >> and the rather less explicitly stated "H_Hat does not get to its
> >> ret instruction because a non top-level H aborts" are just the
> >> various attempt at after-the-fact justification.
> >>
> >> I agree it's never quite so simple because PO is usually fractally
> >> wrong, so he's not correct about almost everything he says at
> >> almost every level.  For example, at one level he now admits that
> >> a halt decider is impossible because H(X,Y) must report "on its
> >> input" and the call X(Y) is not an input!  He did this to explain
> >> why H(P,P) is permitted to return 0 "even though P(P) halts", but
> >> it also makes it clear that what he one thought was that halting
> >> problem is not solvable.
> >
> > YOU KNOW THAT THIS IS TRUE
> > A halt decider must compute the mapping from its inputs to an
> > accept or reject state on the basis of the actual behavior that is
> > actually specified by these inputs.
> >
> > BECAUSE THIS IS PROVABLY TRUE
> > P(P) is provably not the actual behavior of the actual input.
> >
> > YOU ARE THE ONE FUDGING WITH THE TRUTH
> >
>
> Then you are lying that P and H are defined as required.
>
> P is defined, that when given a description of itself, to ask H about
> itself applied to its input. Since you say P calls H(P,P), it that
> doesn't mean H is to decide on P(P), then P wasn't defined correctly,
> and YOU made the error.
>
> If H can't be asked about P(P), then H is proven to be defined
> incorrectly as H must be able to be asked about ANY compuputation,
> that being a program with any input, and P is a program, at least as
> long as H meets the requriements for being a program.
>
> Thus, if the input to H(P,P) is proved to have different behaviot
> than P(P, you have just proved that your "counter example" fails to
> meet the requirements, and thus isn't a counter example.
>
> Thus YOU are the one shown to be not being Truthful, since your own
> proof just proves that you lied about other things.
>
> FAIL.
>
> LIAR.

If I reply to you Olcott will see your post. :)

/Flibble

On 6/26/22 6:31 AM, olcott wrote:
> On 6/25/2022 9:03 PM, Mr Flibble wrote:
>> On Sat, 25 Jun 2022 20:58:23 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>>>> determines what it does, without actually executing it.
>>>>>>
>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>>> (if he has indeed done such a thing) is incorrect.
>>>>> Exactly.
>>>>> We do our little energy budget on tigers, and find that tigers
>>>>> spend more energy than they take in. Well potentially this is
>>>>> dynamite. One explanation is that the law of conservation of
>>>>> energy is wrong. Except, before we countenance that explanation,
>>>>> we need to rule out a much simpler explanation. Which is that our
>>>>> measurements are wrong.
>>>>
>>>> Obviously.
>>>>> Similarly, PO has worked out what he thinks P(P) should be doing,
>>>>> by dry-running it, and then actually run P(P) and obtained a
>>>>> different result. He also found that H agreed with the dry run.
>>>>> It's hard to paraphrase his conclusion, but it is extensive and
>>>>> far-reaching in its implications.
>>>>
>>>> He is just waffling.  There is no conclusion, just a constant
>>>> twisting and turning to find some why to persuade people that the
>>>> wrong answer is the right one.  He's being doing this for years
>>>> with various degrees of obfuscation.
>>>>
>>>> H does not report the correct result for P(P) and PO is putting up
>>>> anything he can think of to keep the discussion going.  It should
>>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>>> correct "even though P(P) halts" but the traces and the verbiage is
>>>> keeping people keen.
>>>>> The behaviour of code when run is different from the
>>>>> correct behaviour of the code when simulated. If that's true, then
>>>>> it has similar implications for computer science that disproving
>>>>> the conservation law has for physics.
>>>>
>>>> When a student comes to me and says that her program to add 5 and 6
>>>> gives 12, I don't, even for a moment, imagine that the laws of
>>>> logic and mathematics are in doubt.
>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>> Lots of people have suggested why it is incorrect. But they can't
>>>>> actually see the code. PO needs to understand that no-one will
>>>>> accept the complicated, far-reaching explanation, until the simple
>>>>> explanation has been ruled out.
>>>>
>>>> For what it's worth, I don't think there is any "dry run" going on
>>>> here at all.  PO decide years ago that H(H_Hat, H_Hat) would be 0
>>>> because he knew (correctly) that H could spot what would happen if
>>>> H did not "intervene".  Everything since then -- the "it only halt
>>>> because...", the "it wouldn't halt if line 15 were commented out"
>>>> and the rather less explicitly stated "H_Hat does not get to its
>>>> ret instruction because a non top-level H aborts" are just the
>>>> various attempt at after-the-fact justification.
>>>>
>>>> I agree it's never quite so simple because PO is usually fractally
>>>> wrong, so he's not correct about almost everything he says at almost
>>>> every level.  For example, at one level he now admits that a halt
>>>> decider is impossible because H(X,Y) must report "on its input" and
>>>> the call X(Y) is not an input!  He did this to explain why H(P,P) is
>>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>>> clear that what he one thought was that halting problem is not
>>>> solvable.
>>>
>>> YOU KNOW THAT THIS IS TRUE
>>> A halt decider must compute the mapping from its inputs to an accept
>>> or reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>>
>>> BECAUSE THIS IS PROVABLY TRUE
>>> P(P) is provably not the actual behavior of the actual input.
>>>
>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>> The issue is what constitutes a pathological input: the pathological
>> input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
>>
>> /Flibble
>>
>
>      Computable functions are the basic objects of study in
> computability theory.
>      Computable functions are the formalized analogue of the intuitive
> notion of
>      algorithms, in the sense that a function is computable if there
> exists an algorithm
>      that can do the job of the function, i.e. given an input of the
> function domain it
>      can return the corresponding output.
>      https://en.wikipedia.org/wiki/Computable_function
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> That you reject that the above proves that H and P have a pathological
> relationship to each other seem to be your lack of technical competence
> rather than dishonesty.
>
>

And what is "Pathological" about the relationship of these code pieces?

P is perfectly valid code, the only pathology about it is that it kills
the concept that Halting could be computable.

Maybe if it was the ONLY program that was't decidable you might be able
to make an argument, but other programs exist (but are more complicated)
which don't need this sort of contrary interaction.

On 6/26/2022 2:00 PM, Mr Flibble wrote:
> On Sun, 26 Jun 2022 11:27:06 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/26/2022 6:15 AM, Mr Flibble wrote:
>>> On Sun, 26 Jun 2022 05:31:53 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 9:03 PM, Mr Flibble wrote:
>>>>> On Sat, 25 Jun 2022 20:58:23 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>
>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>> wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> "Dry run" means that a human programmer looks at the code,
>>>>>>>>>> and determines what it does, without actually executing it.
>>>>>>>>>
>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>>>>>>> invoked H | on it and H reports that it doesn't halt. He's run
>>>>>>>>> P(P) and it halts. The obvious conclusion is that PO's dry run
>>>>>>>>> (if he has indeed done such a thing) is incorrect.
>>>>>>>>>
>>>>>>>> Exactly.
>>>>>>>> We do our little energy budget on tigers, and find that tigers
>>>>>>>> spend more energy than they take in. Well potentially this is
>>>>>>>> dynamite. One explanation is that the law of conservation of
>>>>>>>> energy is wrong. Except, before we countenance that
>>>>>>>> explanation, we need to rule out a much simpler explanation.
>>>>>>>> Which is that our measurements are wrong.
>>>>>>>
>>>>>>> Obviously.
>>>>>>>
>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>> doing, by dry-running it, and then actually run P(P) and
>>>>>>>> obtained a different result. He also found that H agreed with
>>>>>>>> the dry run. It's hard to paraphrase his conclusion, but it is
>>>>>>>> extensive and far-reaching in its implications.
>>>>>>>
>>>>>>> He is just waffling. There is no conclusion, just a constant
>>>>>>> twisting and turning to find some why to persuade people that
>>>>>>> the wrong answer is the right one. He's being doing this for
>>>>>>> years with various degrees of obfuscation.
>>>>>>>
>>>>>>> H does not report the correct result for P(P) and PO is putting
>>>>>>> up anything he can think of to keep the discussion going. It
>>>>>>> should simply have stopped once he'd been clear that H(P,P) ==
>>>>>>> 0 is correct "even though P(P) halts" but the traces and the
>>>>>>> verbiage is keeping people keen.
>>>>>>>> The behaviour of code when run is different from the
>>>>>>>> correct behaviour of the code when simulated. If that's true,
>>>>>>>> then it has similar implications for computer science that
>>>>>>>> disproving the conservation law has for physics.
>>>>>>>
>>>>>>> When a student comes to me and says that her program to add 5
>>>>>>> and 6 gives 12, I don't, even for a moment, imagine that the
>>>>>>> laws of logic and mathematics are in doubt.
>>>>>>>
>>>>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>>>>> Lots of people have suggested why it is incorrect. But they
>>>>>>>> can't actually see the code. PO needs to understand that
>>>>>>>> no-one will accept the complicated, far-reaching explanation,
>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>
>>>>>>> For what it's worth, I don't think there is any "dry run" going
>>>>>>> on here at all. PO decide years ago that H(H_Hat, H_Hat) would
>>>>>>> be 0 because he knew (correctly) that H could spot what would
>>>>>>> happen if H did not "intervene". Everything since then -- the
>>>>>>> "it only halt because...", the "it wouldn't halt if line 15
>>>>>>> were commented out" and the rather less explicitly stated
>>>>>>> "H_Hat does not get to its ret instruction because a non
>>>>>>> top-level H aborts" are just the various attempt at
>>>>>>> after-the-fact justification.
>>>>>>>
>>>>>>> I agree it's never quite so simple because PO is usually
>>>>>>> fractally wrong, so he's not correct about almost everything he
>>>>>>> says at almost every level. For example, at one level he now
>>>>>>> admits that a halt decider is impossible because H(X,Y) must
>>>>>>> report "on its input" and the call X(Y) is not an input! He
>>>>>>> did this to explain why H(P,P) is permitted to return 0 "even
>>>>>>> though P(P) halts", but it also makes it clear that what he one
>>>>>>> thought was that halting problem is not solvable.
>>>>>>
>>>>>> YOU KNOW THAT THIS IS TRUE
>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>> accept or reject state on the basis of the actual behavior that
>>>>>> is actually specified by these inputs.
>>>>>>
>>>>>> BECAUSE THIS IS PROVABLY TRUE
>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>
>>>>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>>>>>
>>>>> The issue is what constitutes a pathological input: the
>>>>> pathological input at issue here are YOUR PATHOLOGICAL LIES,
>>>>> Olcott.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Computable functions are the basic objects of study in
>>>> computability theory.
>>>> Computable functions are the formalized analogue of the
>>>> intuitive notion of
>>>> algorithms, in the sense that a function is computable if
>>>> there exists an algorithm
>>>> that can do the job of the function, i.e. given an input of
>>>> the function domain it
>>>> can return the corresponding output.
>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> That you reject that the above proves that H and P have a
>>>> pathological relationship to each other seem to be your lack of
>>>> technical competence rather than dishonesty.
>>>
>>> There is nothing wrong with my technical competence however yours
>>> *is* suspect.
>>>
>>> Nobody is denying that P is pathological input as its comes
>>> from [Strachey, 1965]'s "Impossible Program";
>>
>> // rec routine P
>> // §L :if T[P] go to L
>> // Return §
>> // https://academic.oup.com/comjnl/article/7/4/313/354243
>> void Strachey_P()
>> {
>> L:if (T(Strachey_P))
>> goto L;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", T(Strachey_P));
>> }
>>
>> _Strachey_P()
>> [000015b2](01) 55 push ebp
>> [000015b3](02) 8bec mov ebp,esp
>> [000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
>> [000015ba](05) e813fdffff call 000012d2 // call T
>> [000015bf](03) 83c404 add esp,+04
>> [000015c2](02) 85c0 test eax,eax
>> [000015c4](02) 7402 jz 000015c8
>> [000015c6](02) ebed jmp 000015b5
>> [000015c8](01) 5d pop ebp
>> [000015c9](01) c3 ret
>> Size in bytes:(0024) [000015c9]
>>
>> _main()
>> [000015d2](01) 55 push ebp
>> [000015d3](02) 8bec mov ebp,esp
>> [000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
>> [000015da](05) e8f3fcffff call 000012d2 // call T
>> [000015df](03) 83c404 add esp,+04
>> [000015e2](01) 50 push eax
>> [000015e3](05) 6833040000 push 00000433
>> [000015e8](05) e895eeffff call 00000482
>> [000015ed](03) 83c408 add esp,+08
>> [000015f0](02) 33c0 xor eax,eax
>> [000015f2](01) 5d pop ebp
>> [000015f3](01) c3 ret
>> Size in bytes:(0034) [000015f3]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [000015d2][001025c6][00000000] 55 push ebp
>> [000015d3][001025c6][00000000] 8bec mov ebp,esp
>> [000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
>> Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2 //
>> call T
>>
>> Begin Simulation Execution Trace Stored at:21267a
>> Address_of_T:12d2
>> [000015b2][0021266a][0021266e] 55 push ebp
>> [000015b3][0021266a][0021266e] 8bec mov ebp,esp
>> [000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
>> Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2 //
>> call T Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> T knows its own machine address and on this basis it can easily
>> examine its stored execution_trace of Strachey_P (see above) to
>> determine: (a) Strachey_P is calling T with the same arguments that T
>> was called with. (b) No instructions in Strachey_P could possibly
>> escape this otherwise infinitely recursive emulation.
>
> There is no recursion in [Strachey, 1965] or the proofs based on it
> that you are attempting to refute. Fail.
>
> /Flibble
>