On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>> Linz and others were aware that: 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.
>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>>> ever before.
>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>
>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>>
>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>>
>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>>
>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>
>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>>> has rather far-reaching consequences.
>>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>> what's going on.
>>>>>>>
>>>>>> I'm a scientists, not a mathematician.
>>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>>> You work how much they use on running about, lactating, maintaining their
>>>>>> body temperature, and so on.
>>>>>>
>>>>>> Now let's say that you find that all results are within a few percentage points
>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>
>>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>>
>>>>>> Now let's say that the result show that tigers use more energy than they
>>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>>> energy must be incorrect?
>>>>>>
>>>>>> The third is what PO is doing.
>>>>> I have no idea what parts of this analogy map to the current situation.
>>>>> PO has no contradictory results about anything. There's no conflict
>>>>> with any established facts in anything he is doing.
>>>>>
>>>> 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.
>>>>
>>>> So something odd is going on there that needs an explanation.
>>> Then I don't know what you mean by "dry-run" and what needs an
>>> explanation (for me) is your description of what he's doing. Nothing in
>>> what PO is doing needs to be explained as far as I can see.
>>>
>> "Dry run" means that a human programmer looks at the code, and determines
>> what it does, without actually executing it.
>
> OK. So what value does it have in this case? Do you think PO is
> competent to "dry run" any code at all?
>
> 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. Anyone who eyeballs some case and concludes that
> it does not do what it down when actually run has just made a mistake.
> Do you think it's interesting to find out what mistake PO has made when
> guessing what the code does? If so have fun trying to get the code from
> him...
>
> The more interesting (at least at one time) is fact that H is not
> correct since, by definition, H(X,Y) should report on the "halting" of
> the call X(Y).
>
>> It's a very important technique, because it's not always practical or even
>> possible to run a debugger. Even where a debugger is available, often
>> dry-running will reveal bugs in a fraction of the time.
>
> In this case, we have the undisputed fact that P(P) halts, so there's
> really no value in a "dry run" from a debugging perspective.
>
>> In this case, PO has dry run P(P).
>
> And, if that is indeed what he's done (and I don't think it is) he knows
> he's made some mistake in his "dry run".
>
>> That is, he has looked at the source, and
>> worked out what it will do.
>
> But, I hope you agree, he's made some mistake or he's been lying when re
> reports that P(P) halts.
>
>> Which is to run an infinite sequence of nested
>> emulations. So it won't halt.
>
> The execution of P(P) does not represent an infinite sequence of nested
> simulations. We know that because P(P) halts.
>
>> H(P,P) also reports "non-halting". So this is
>> powerful evidence that H is correct.
>
> Eh? How is some code eyeballing more compelling evidence than the 100%
> undisputed fact that P(P) halts? How is the opinion of someone who
> can't write a parity checking TM powerful evidence of anything?
>
>> However when he actually executes P(P) on hardware, it terminates.
>> Something isn't right.
>
> Yes.
>
>> PO's explanation is that P(P) has different correct behaviour when run and
>> when emulated by H.
>
> That can't be an explanation of anything because, according to you, he
> is wrong about the dry run of P(P) and an actual run of P(P). Both the
> dry run and the actual run must take account of the fact that H is
> (partially) emulating P(P).
>
>> I can think of an obvious alternative explanation which is much
>> simpler and much less far-reaching in its implications. However
>> despite a lot of coaxing, no-one else seems to have arrived at it.
>
> There is nothing here with any far-reaching implications and since I've
> never shared your explanation, I'm not going to look for an alternative.
>
> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
> relying on sophistry. H "aborts" so P never reaches its "ret"
> instruction. That's why P(P) and "the simulation of the inputs to
> H(P,P)" are different. 18 years of work for what? An H that, on the
> basis of his own words, obviously gets the wrong answer.
>

On 6/24/2022 5:23 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> You say that "H(P,P) is required to to correctly determine that its
>> correct and complete x86 emulation of its input would never reach the
>> "ret" instruction of this input".
>
> Can I just check that you know this is not what H is supposed to do? PO
> has been searching for some from of words that can stir up enough mud
> that the fact that H is wrong can be to some extent obscured. He seems
> to have hit pay dirt with this latest phrasing.
>
> Everyone seem happy to talk to PO on his own terms (and that's fine --
> it's what he posts for), but in the C-function version of the problem,
> H(X,Y) != 0 if and only if X(Y) "halts". I lost interest when he
> stopped talking about this problem which he knows in not decidable.
>

It is common knowledge (in computer science) that a halt decider must
compute the mapping from actual its inputs to an accept or reject state
on the basis of the actual behavior that is actually specified by its
actual inputs.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.

THERE IS NO ESCAPE FROM THIS BECAUSE IT IS A TAUTOLOGY.

--
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 Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
> On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >
> >> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
> >>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>
> >>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
> >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>
> >>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
> >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>
> >>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
> >>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
> >>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
> >>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
> >>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
> >>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
> >>>>>>>>>>> Linz and others were aware that: 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.
> >>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
> >>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
> >>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
> >>>>>>>>>>> this because no one previously fully examined a simulating halt decider
> >>>>>>>>>>> ever before.
> >>>>>>>>>>>> especially if that is what P calls
> >>>>>>>>>>>> and P is claimed to be built by the Linz template.
> >>>>>>>>>>>>
> >>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
> >>>>>>>>>>>
> >>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
> >>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
> >>>>>>>>>>
> >>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
> >>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
> >>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
> >>>>>>>>>
> >>>>>>>>> That is an actual immutable verified fact.
> >>>>>>>>>
> >>>>>>>> That's your conclusion from your observations and reasoning. You've
> >>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
> >>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
> >>>>>>>> explanation is the one you've given but, as I said, that explanation
> >>>>>>>> has rather far-reaching consequences.
> >>>>>>> There is only one explanation. What you call the "dry-run" is not that
> >>>>>>> same as the P(P). We've known this since the "line 15 commented out"
> >>>>>>> days. There are two computations -- one that is not stopped and one
> >>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
> >>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
> >>>>>>> what's going on.
> >>>>>>>
> >>>>>> I'm a scientists, not a mathematician.
> >>>>>> The example I always use is that you are doing an energy budget for tigers.
> >>>>>> You work how much they use on running about, lactating, maintaining their
> >>>>>> body temperature, and so on.
> >>>>>>
> >>>>>> Now let's say that you find that all results are within a few percentage points
> >>>>>> of a similar budget done for lions. You'd instantly accept this data.
> >>>>>>
> >>>>>> Now let's say that the results are wildly different from a previous budget done
> >>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
> >>>>>> understand the reasons tigers spend far less energy on movement than lions.
> >>>>>>
> >>>>>> Now let's say that the result show that tigers use more energy than they
> >>>>>> take in food. Would you instantly conclude that the law of conservation of
> >>>>>> energy must be incorrect?
> >>>>>>
> >>>>>> The third is what PO is doing.
> >>>>> I have no idea what parts of this analogy map to the current situation.
> >>>>> PO has no contradictory results about anything. There's no conflict
> >>>>> with any established facts in anything he is doing.
> >>>>>
> >>>> 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.
> >>>>
> >>>> So something odd is going on there that needs an explanation.
> >>> Then I don't know what you mean by "dry-run" and what needs an
> >>> explanation (for me) is your description of what he's doing. Nothing in
> >>> what PO is doing needs to be explained as far as I can see.
> >>>
> >> "Dry run" means that a human programmer looks at the code, and determines
> >> what it does, without actually executing it.
> >
> > OK. So what value does it have in this case? Do you think PO is
> > competent to "dry run" any code at all?
> >
> > 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. Anyone who eyeballs some case and concludes that
> > it does not do what it down when actually run has just made a mistake.
> > Do you think it's interesting to find out what mistake PO has made when
> > guessing what the code does? If so have fun trying to get the code from
> > him...
> >
> > The more interesting (at least at one time) is fact that H is not
> > correct since, by definition, H(X,Y) should report on the "halting" of
> > the call X(Y).
> >
> >> It's a very important technique, because it's not always practical or even
> >> possible to run a debugger. Even where a debugger is available, often
> >> dry-running will reveal bugs in a fraction of the time.
> >
> > In this case, we have the undisputed fact that P(P) halts, so there's
> > really no value in a "dry run" from a debugging perspective.
> >
> >> In this case, PO has dry run P(P).
> >
> > And, if that is indeed what he's done (and I don't think it is) he knows
> > he's made some mistake in his "dry run".
> >
> >> That is, he has looked at the source, and
> >> worked out what it will do.
> >
> > But, I hope you agree, he's made some mistake or he's been lying when re
> > reports that P(P) halts.
> >
> >> Which is to run an infinite sequence of nested
> >> emulations. So it won't halt.
> >
> > The execution of P(P) does not represent an infinite sequence of nested
> > simulations. We know that because P(P) halts.
> >
> >> H(P,P) also reports "non-halting". So this is
> >> powerful evidence that H is correct.
> >
> > Eh? How is some code eyeballing more compelling evidence than the 100%
> > undisputed fact that P(P) halts? How is the opinion of someone who
> > can't write a parity checking TM powerful evidence of anything?
> >
> >> However when he actually executes P(P) on hardware, it terminates.
> >> Something isn't right.
> >
> > Yes.
> >
> >> PO's explanation is that P(P) has different correct behaviour when run and
> >> when emulated by H.
> >
> > That can't be an explanation of anything because, according to you, he
> > is wrong about the dry run of P(P) and an actual run of P(P). Both the
> > dry run and the actual run must take account of the fact that H is
> > (partially) emulating P(P).
> >
> >> I can think of an obvious alternative explanation which is much
> >> simpler and much less far-reaching in its implications. However
> >> despite a lot of coaxing, no-one else seems to have arrived at it.
> >
> > There is nothing here with any far-reaching implications and since I've
> > never shared your explanation, I'm not going to look for an alternative.
> >
> > I don't think he's done a "dry run" at all. He knows P(P) halts so he's
> > relying on sophistry. H "aborts" so P never reaches its "ret"
> > instruction. That's why P(P) and "the simulation of the inputs to
> > H(P,P)" are different. 18 years of work for what? An H that, on the
> > basis of his own words, obviously gets the wrong answer.
> >
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
> That your understanding of the semantics of the x86 language is
> insufficient to directly confirm this is less than no rebuttal at all.

On 6/24/2022 6:58 PM, dklei...@gmail.com wrote:
> On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
>> On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>> Linz and others were aware that: 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.
>>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>>>>
>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>
>>>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>>>> what's going on.
>>>>>>>>>
>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>>>>> You work how much they use on running about, lactating, maintaining their
>>>>>>>> body temperature, and so on.
>>>>>>>>
>>>>>>>> Now let's say that you find that all results are within a few percentage points
>>>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>>>
>>>>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>>>>
>>>>>>>> Now let's say that the result show that tigers use more energy than they
>>>>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>>>>> energy must be incorrect?
>>>>>>>>
>>>>>>>> The third is what PO is doing.
>>>>>>> I have no idea what parts of this analogy map to the current situation.
>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>> with any established facts in anything he is doing.
>>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> So something odd is going on there that needs an explanation.
>>>>> Then I don't know what you mean by "dry-run" and what needs an
>>>>> explanation (for me) is your description of what he's doing. Nothing in
>>>>> what PO is doing needs to be explained as far as I can see.
>>>>>
>>>> "Dry run" means that a human programmer looks at the code, and determines
>>>> what it does, without actually executing it.
>>>
>>> OK. So what value does it have in this case? Do you think PO is
>>> competent to "dry run" any code at all?
>>>
>>> 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. Anyone who eyeballs some case and concludes that
>>> it does not do what it down when actually run has just made a mistake.
>>> Do you think it's interesting to find out what mistake PO has made when
>>> guessing what the code does? If so have fun trying to get the code from
>>> him...
>>>
>>> The more interesting (at least at one time) is fact that H is not
>>> correct since, by definition, H(X,Y) should report on the "halting" of
>>> the call X(Y).
>>>
>>>> It's a very important technique, because it's not always practical or even
>>>> possible to run a debugger. Even where a debugger is available, often
>>>> dry-running will reveal bugs in a fraction of the time.
>>>
>>> In this case, we have the undisputed fact that P(P) halts, so there's
>>> really no value in a "dry run" from a debugging perspective.
>>>
>>>> In this case, PO has dry run P(P).
>>>
>>> And, if that is indeed what he's done (and I don't think it is) he knows
>>> he's made some mistake in his "dry run".
>>>
>>>> That is, he has looked at the source, and
>>>> worked out what it will do.
>>>
>>> But, I hope you agree, he's made some mistake or he's been lying when re
>>> reports that P(P) halts.
>>>
>>>> Which is to run an infinite sequence of nested
>>>> emulations. So it won't halt.
>>>
>>> The execution of P(P) does not represent an infinite sequence of nested
>>> simulations. We know that because P(P) halts.
>>>
>>>> H(P,P) also reports "non-halting". So this is
>>>> powerful evidence that H is correct.
>>>
>>> Eh? How is some code eyeballing more compelling evidence than the 100%
>>> undisputed fact that P(P) halts? How is the opinion of someone who
>>> can't write a parity checking TM powerful evidence of anything?
>>>
>>>> However when he actually executes P(P) on hardware, it terminates.
>>>> Something isn't right.
>>>
>>> Yes.
>>>
>>>> PO's explanation is that P(P) has different correct behaviour when run and
>>>> when emulated by H.
>>>
>>> That can't be an explanation of anything because, according to you, he
>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the
>>> dry run and the actual run must take account of the fact that H is
>>> (partially) emulating P(P).
>>>
>>>> I can think of an obvious alternative explanation which is much
>>>> simpler and much less far-reaching in its implications. However
>>>> despite a lot of coaxing, no-one else seems to have arrived at it.
>>>
>>> There is nothing here with any far-reaching implications and since I've
>>> never shared your explanation, I'm not going to look for an alternative.
>>>
>>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
>>> relying on sophistry. H "aborts" so P never reaches its "ret"
>>> instruction. That's why P(P) and "the simulation of the inputs to
>>> H(P,P)" are different. 18 years of work for what? An H that, on the
>>> basis of his own words, obviously gets the wrong answer.
>>>
>> The ordinary semantics of standard C and the conventional x86 language
>> are the entire semantics required to conclusively prove that H(P,P) does
>> correctly determine that its correct and complete x86 emulation of its
>> input would never reach the "ret" instruction (final state) of this
>> input thus never halts.
>> That your understanding of the semantics of the x86 language is
>> insufficient to directly confirm this is less than no rebuttal at all.
>
> I assume the semantics of C are defined by the 1989 Standard. The
> semantics of x86 assembly language are described (not actually
> authoritatively defined) in other documents. The mapping of C onto
> the assembly language is far from unique (every compiler could be
> different) PO appears to using a version of Microsoft's C# compiler.
>

On 6/24/22 8:12 PM, olcott wrote:
> On 6/24/2022 6:58 PM, dklei...@gmail.com wrote:
>> On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
>>> On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P)
>>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>>> Linz and others were aware that: 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.
>>>>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>>>>> behavior that
>>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>>>>> decider is not
>>>>>>>>>>>>>> the same as the direct execution of these inputs. They
>>>>>>>>>>>>>> were unaware of
>>>>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight,
>>>>>>>>>>>>>>> or H is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the
>>>>>>>>>>>>> halt decider H
>>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume
>>>>>>>>>>>>> that H is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>>>>> That "the
>>>>>>>>>>>>> actual behaviour that is actually specified by the inputs
>>>>>>>>>>>>> to a simulating
>>>>>>>>>>>>> halt decider is not the same as the direct execution of
>>>>>>>>>>>>> these inputs"?
>>>>>>>>>>>>
>>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>>
>>>>>>>>>>> That's your conclusion from your observations and reasoning.
>>>>>>>>>>> You've
>>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>>> explanation is the one you've given but, as I said, that
>>>>>>>>>>> explanation
>>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>>> There is only one explanation. What you call the "dry-run" is
>>>>>>>>>> not that
>>>>>>>>>> same as the P(P). We've known this since the "line 15
>>>>>>>>>> commented out"
>>>>>>>>>> days. There are two computations -- one that is not stopped
>>>>>>>>>> and one
>>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the
>>>>>>>>>> input to
>>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that
>>>>>>>>>> hide
>>>>>>>>>> what's going on.
>>>>>>>>>>
>>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>>> The example I always use is that you are doing an energy budget
>>>>>>>>> for tigers.
>>>>>>>>> You work how much they use on running about, lactating,
>>>>>>>>> maintaining their
>>>>>>>>> body temperature, and so on.
>>>>>>>>>
>>>>>>>>> Now let's say that you find that all results are within a few
>>>>>>>>> percentage points
>>>>>>>>> of a similar budget done for lions. You'd instantly accept this
>>>>>>>>> data.
>>>>>>>>>
>>>>>>>>> Now let's say that the results are wildly different from a
>>>>>>>>> previous budget done
>>>>>>>>> for lions. You wouldn't just accept that data. You'd check.
>>>>>>>>> You'd want to
>>>>>>>>> understand the reasons tigers spend far less energy on movement
>>>>>>>>> than lions.
>>>>>>>>>
>>>>>>>>> Now let's say that the result show that tigers use more energy
>>>>>>>>> than they
>>>>>>>>> take in food. Would you instantly conclude that the law of
>>>>>>>>> conservation of
>>>>>>>>> energy must be incorrect?
>>>>>>>>>
>>>>>>>>> The third is what PO is doing.
>>>>>>>> I have no idea what parts of this analogy map to the current
>>>>>>>> situation.
>>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>>> with any established facts in anything he is doing.
>>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> So something odd is going on there that needs an explanation.
>>>>>> Then I don't know what you mean by "dry-run" and what needs an
>>>>>> explanation (for me) is your description of what he's doing.
>>>>>> Nothing in
>>>>>> what PO is doing needs to be explained as far as I can see.
>>>>>>
>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>> determines
>>>>> what it does, without actually executing it.
>>>>
>>>> OK. So what value does it have in this case? Do you think PO is
>>>> competent to "dry run" any code at all?
>>>>
>>>> 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. Anyone who eyeballs some case and concludes that
>>>> it does not do what it down when actually run has just made a mistake.
>>>> Do you think it's interesting to find out what mistake PO has made when
>>>> guessing what the code does? If so have fun trying to get the code from
>>>> him...
>>>>
>>>> The more interesting (at least at one time) is fact that H is not
>>>> correct since, by definition, H(X,Y) should report on the "halting" of
>>>> the call X(Y).
>>>>
>>>>> It's a very important technique, because it's not always practical
>>>>> or even
>>>>> possible to run a debugger. Even where a debugger is available, often
>>>>> dry-running will reveal bugs in a fraction of the time.
>>>>
>>>> In this case, we have the undisputed fact that P(P) halts, so there's
>>>> really no value in a "dry run" from a debugging perspective.
>>>>
>>>>> In this case, PO has dry run P(P).
>>>>
>>>> And, if that is indeed what he's done (and I don't think it is) he
>>>> knows
>>>> he's made some mistake in his "dry run".
>>>>
>>>>> That is, he has looked at the source, and
>>>>> worked out what it will do.
>>>>
>>>> But, I hope you agree, he's made some mistake or he's been lying
>>>> when re
>>>> reports that P(P) halts.
>>>>
>>>>> Which is to run an infinite sequence of nested
>>>>> emulations. So it won't halt.
>>>>
>>>> The execution of P(P) does not represent an infinite sequence of nested
>>>> simulations. We know that because P(P) halts.
>>>>
>>>>> H(P,P) also reports "non-halting". So this is
>>>>> powerful evidence that H is correct.
>>>>
>>>> Eh? How is some code eyeballing more compelling evidence than the 100%
>>>> undisputed fact that P(P) halts? How is the opinion of someone who
>>>> can't write a parity checking TM powerful evidence of anything?
>>>>
>>>>> However when he actually executes P(P) on hardware, it terminates.
>>>>> Something isn't right.
>>>>
>>>> Yes.
>>>>
>>>>> PO's explanation is that P(P) has different correct behaviour when
>>>>> run and
>>>>> when emulated by H.
>>>>
>>>> That can't be an explanation of anything because, according to you, he
>>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the
>>>> dry run and the actual run must take account of the fact that H is
>>>> (partially) emulating P(P).
>>>>
>>>>> I can think of an obvious alternative explanation which is much
>>>>> simpler and much less far-reaching in its implications. However
>>>>> despite a lot of coaxing, no-one else seems to have arrived at it.
>>>>
>>>> There is nothing here with any far-reaching implications and since I've
>>>> never shared your explanation, I'm not going to look for an
>>>> alternative.
>>>>
>>>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
>>>> relying on sophistry. H "aborts" so P never reaches its "ret"
>>>> instruction. That's why P(P) and "the simulation of the inputs to
>>>> H(P,P)" are different. 18 years of work for what? An H that, on the
>>>> basis of his own words, obviously gets the wrong answer.
>>>>
>>> The ordinary semantics of standard C and the conventional x86 language
>>> are the entire semantics required to conclusively prove that H(P,P) does
>>> correctly determine that its correct and complete x86 emulation of its
>>> input would never reach the "ret" instruction (final state) of this
>>> input thus never halts.
>>> That your understanding of the semantics of the x86 language is
>>> insufficient to directly confirm this is less than no rebuttal at all.
>>
>> I assume the semantics of C are defined by the 1989 Standard. The
>> semantics of x86 assembly language are described (not actually
>> authoritatively defined) in other documents. The mapping of C onto
>> the assembly language is far from unique (every compiler could be
>> different) PO appears to using a version of Microsoft's C# compiler.
>>
>
> The COFF object file generated by most any Microsoft C compiler.
> I used Visual Studio 2017 Community Edition.
>
> x86 Instruction Set Reference: https://c9x.me/x86/
>
>> Then we must define how a Turing machine is emulated by a C
>> program. All that is needed of C is the struct  concept and
>> assignment. In that case using C seems unadvisable.
>
> No we don't need this at all. We only need to know that a C function
> that is a pure function of its inputs is Turing equivalent.
>
> https://en.wikipedia.org/wiki/Pure_function
>
> By not using C my five page halt decider becomes hundreds of thousands
> of indecipherable pages of TM description.
>

On 6/24/22 6:58 PM, olcott wrote:
> On 6/24/2022 5:23 PM, Ben Bacarisse wrote:
>> Paul N <gw7rib@aol.com> writes:
>>
>>> You say that "H(P,P) is required to to correctly determine that its
>>> correct and complete x86 emulation of its input would never reach the
>>> "ret" instruction of this input".
>>
>> Can I just check that you know this is not what H is supposed to do?  PO
>> has been searching for some from of words that can stir up enough mud
>> that the fact that H is wrong can be to some extent obscured.  He seems
>> to have hit pay dirt with this latest phrasing.
>>
>> Everyone seem happy to talk to PO on his own terms (and that's fine --
>> it's what he posts for), but in the C-function version of the problem,
>> H(X,Y) != 0 if and only if X(Y) "halts".  I lost interest when he
>> stopped talking about this problem which he knows in not decidable.
>>
>
> It is common knowledge (in computer science) that a halt decider must
> compute the mapping from actual its inputs to an accept or reject state
> on the basis of the actual behavior that is actually specified by its
> actual inputs.
>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
>
> THERE IS NO ESCAPE FROM THIS BECAUSE IT IS A TAUTOLOGY.
>

Wrong. If H(P,P) does the correct and complete x86 emulation of its
input, i9t never gives an answer for H(P,P).

Maybe in your mind it makes the dertemination but not return it, but
that isn't the defintion of a decider determinng.

If H(P,P) does make a determination about its simulation of H(P,P) being
non-halting, it does so based on unsound logic, as your logic has it
presume that H DOES a complete and correct emulation, but if it makes
such a determination and returns the non-halting answer, it never did a
complete and correct emulation, so the premise it based its logic on is
refuted.

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.

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

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.

On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> 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.
>
> 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. 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.
>
> 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.

I already proved that the dry run is correct.

--
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 Friday, June 24, 2022 at 5:12:57 PM UTC-7, olcott wrote:
> On 6/24/2022 6:58 PM, dklei...@gmail.com wrote:
> > On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
> >> On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
> >>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>
> >>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
> >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>
> >>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
> >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>
> >>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
> >>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>
> >>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
> >>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
> >>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
> >>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
> >>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
> >>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
> >>>>>>>>>>>>> Linz and others were aware that: 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.
> >>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
> >>>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
> >>>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
> >>>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
> >>>>>>>>>>>>> ever before.
> >>>>>>>>>>>>>> especially if that is what P calls
> >>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
> >>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
> >>>>>>>>>>>>
> >>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
> >>>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
> >>>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
> >>>>>>>>>>>
> >>>>>>>>>>> That is an actual immutable verified fact.
> >>>>>>>>>>>
> >>>>>>>>>> That's your conclusion from your observations and reasoning. You've
> >>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
> >>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
> >>>>>>>>>> explanation is the one you've given but, as I said, that explanation
> >>>>>>>>>> has rather far-reaching consequences.
> >>>>>>>>> There is only one explanation. What you call the "dry-run" is not that
> >>>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
> >>>>>>>>> days. There are two computations -- one that is not stopped and one
> >>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
> >>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
> >>>>>>>>> what's going on.
> >>>>>>>>>
> >>>>>>>> I'm a scientists, not a mathematician.
> >>>>>>>> The example I always use is that you are doing an energy budget for tigers.
> >>>>>>>> You work how much they use on running about, lactating, maintaining their
> >>>>>>>> body temperature, and so on.
> >>>>>>>>
> >>>>>>>> Now let's say that you find that all results are within a few percentage points
> >>>>>>>> of a similar budget done for lions. You'd instantly accept this data.
> >>>>>>>>
> >>>>>>>> Now let's say that the results are wildly different from a previous budget done
> >>>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
> >>>>>>>> understand the reasons tigers spend far less energy on movement than lions.
> >>>>>>>>
> >>>>>>>> Now let's say that the result show that tigers use more energy than they
> >>>>>>>> take in food. Would you instantly conclude that the law of conservation of
> >>>>>>>> energy must be incorrect?
> >>>>>>>>
> >>>>>>>> The third is what PO is doing.
> >>>>>>> I have no idea what parts of this analogy map to the current situation.
> >>>>>>> PO has no contradictory results about anything. There's no conflict
> >>>>>>> with any established facts in anything he is doing.
> >>>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> So something odd is going on there that needs an explanation.
> >>>>> Then I don't know what you mean by "dry-run" and what needs an
> >>>>> explanation (for me) is your description of what he's doing. Nothing in
> >>>>> what PO is doing needs to be explained as far as I can see.
> >>>>>
> >>>> "Dry run" means that a human programmer looks at the code, and determines
> >>>> what it does, without actually executing it.
> >>>
> >>> OK. So what value does it have in this case? Do you think PO is
> >>> competent to "dry run" any code at all?
> >>>
> >>> 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. Anyone who eyeballs some case and concludes that
> >>> it does not do what it down when actually run has just made a mistake.
> >>> Do you think it's interesting to find out what mistake PO has made when
> >>> guessing what the code does? If so have fun trying to get the code from
> >>> him...
> >>>
> >>> The more interesting (at least at one time) is fact that H is not
> >>> correct since, by definition, H(X,Y) should report on the "halting" of
> >>> the call X(Y).
> >>>
> >>>> It's a very important technique, because it's not always practical or even
> >>>> possible to run a debugger. Even where a debugger is available, often
> >>>> dry-running will reveal bugs in a fraction of the time.
> >>>
> >>> In this case, we have the undisputed fact that P(P) halts, so there's
> >>> really no value in a "dry run" from a debugging perspective.
> >>>
> >>>> In this case, PO has dry run P(P).
> >>>
> >>> And, if that is indeed what he's done (and I don't think it is) he knows
> >>> he's made some mistake in his "dry run".
> >>>
> >>>> That is, he has looked at the source, and
> >>>> worked out what it will do.
> >>>
> >>> But, I hope you agree, he's made some mistake or he's been lying when re
> >>> reports that P(P) halts.
> >>>
> >>>> Which is to run an infinite sequence of nested
> >>>> emulations. So it won't halt.
> >>>
> >>> The execution of P(P) does not represent an infinite sequence of nested
> >>> simulations. We know that because P(P) halts.
> >>>
> >>>> H(P,P) also reports "non-halting". So this is
> >>>> powerful evidence that H is correct.
> >>>
> >>> Eh? How is some code eyeballing more compelling evidence than the 100%
> >>> undisputed fact that P(P) halts? How is the opinion of someone who
> >>> can't write a parity checking TM powerful evidence of anything?
> >>>
> >>>> However when he actually executes P(P) on hardware, it terminates.
> >>>> Something isn't right.
> >>>
> >>> Yes.
> >>>
> >>>> PO's explanation is that P(P) has different correct behaviour when run and
> >>>> when emulated by H.
> >>>
> >>> That can't be an explanation of anything because, according to you, he
> >>> is wrong about the dry run of P(P) and an actual run of P(P). Both the
> >>> dry run and the actual run must take account of the fact that H is
> >>> (partially) emulating P(P).
> >>>
> >>>> I can think of an obvious alternative explanation which is much
> >>>> simpler and much less far-reaching in its implications. However
> >>>> despite a lot of coaxing, no-one else seems to have arrived at it.
> >>>
> >>> There is nothing here with any far-reaching implications and since I've
> >>> never shared your explanation, I'm not going to look for an alternative.
> >>>
> >>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
> >>> relying on sophistry. H "aborts" so P never reaches its "ret"
> >>> instruction. That's why P(P) and "the simulation of the inputs to
> >>> H(P,P)" are different. 18 years of work for what? An H that, on the
> >>> basis of his own words, obviously gets the wrong answer.
> >>>
> >> The ordinary semantics of standard C and the conventional x86 language
> >> are the entire semantics required to conclusively prove that H(P,P) does
> >> correctly determine that its correct and complete x86 emulation of its
> >> input would never reach the "ret" instruction (final state) of this
> >> input thus never halts.
> >> That your understanding of the semantics of the x86 language is
> >> insufficient to directly confirm this is less than no rebuttal at all.
> >
> > I assume the semantics of C are defined by the 1989 Standard. The
> > semantics of x86 assembly language are described (not actually
> > authoritatively defined) in other documents. The mapping of C onto
> > the assembly language is far from unique (every compiler could be
> > different) PO appears to using a version of Microsoft's C# compiler.
> >
> The COFF object file generated by most any Microsoft C compiler.
> I used Visual Studio 2017 Community Edition.
>
> x86 Instruction Set Reference: https://c9x.me/x86/
> > Then we must define how a Turing machine is emulated by a C
> > program. All that is needed of C is the struct concept and
> > assignment. In that case using C seems unadvisable.
> >
> No we don't need this at all. We only need to know that a C function
> that is a pure function of its inputs is Turing equivalent.
>
> https://en.wikipedia.org/wiki/Pure_function

Click here to read the complete article

On 6/24/2022 11:50 PM, dklei...@gmail.com wrote:
> On Friday, June 24, 2022 at 5:12:57 PM UTC-7, olcott wrote:
>> On 6/24/2022 6:58 PM, dklei...@gmail.com wrote:
>>> On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
>>>> On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>>>> Linz and others were aware that: 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.
>>>>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>>>
>>>>>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>>>>>> what's going on.
>>>>>>>>>>>
>>>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>>>>>>> You work how much they use on running about, lactating, maintaining their
>>>>>>>>>> body temperature, and so on.
>>>>>>>>>>
>>>>>>>>>> Now let's say that you find that all results are within a few percentage points
>>>>>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>>>>>
>>>>>>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>>>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>>>>>>
>>>>>>>>>> Now let's say that the result show that tigers use more energy than they
>>>>>>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>>>>>>> energy must be incorrect?
>>>>>>>>>>
>>>>>>>>>> The third is what PO is doing.
>>>>>>>>> I have no idea what parts of this analogy map to the current situation.
>>>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>>>> with any established facts in anything he is doing.
>>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> So something odd is going on there that needs an explanation.
>>>>>>> Then I don't know what you mean by "dry-run" and what needs an
>>>>>>> explanation (for me) is your description of what he's doing. Nothing in
>>>>>>> what PO is doing needs to be explained as far as I can see.
>>>>>>>
>>>>>> "Dry run" means that a human programmer looks at the code, and determines
>>>>>> what it does, without actually executing it.
>>>>>
>>>>> OK. So what value does it have in this case? Do you think PO is
>>>>> competent to "dry run" any code at all?
>>>>>
>>>>> 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. Anyone who eyeballs some case and concludes that
>>>>> it does not do what it down when actually run has just made a mistake.
>>>>> Do you think it's interesting to find out what mistake PO has made when
>>>>> guessing what the code does? If so have fun trying to get the code from
>>>>> him...
>>>>>
>>>>> The more interesting (at least at one time) is fact that H is not
>>>>> correct since, by definition, H(X,Y) should report on the "halting" of
>>>>> the call X(Y).
>>>>>
>>>>>> It's a very important technique, because it's not always practical or even
>>>>>> possible to run a debugger. Even where a debugger is available, often
>>>>>> dry-running will reveal bugs in a fraction of the time.
>>>>>
>>>>> In this case, we have the undisputed fact that P(P) halts, so there's
>>>>> really no value in a "dry run" from a debugging perspective.
>>>>>
>>>>>> In this case, PO has dry run P(P).
>>>>>
>>>>> And, if that is indeed what he's done (and I don't think it is) he knows
>>>>> he's made some mistake in his "dry run".
>>>>>
>>>>>> That is, he has looked at the source, and
>>>>>> worked out what it will do.
>>>>>
>>>>> But, I hope you agree, he's made some mistake or he's been lying when re
>>>>> reports that P(P) halts.
>>>>>
>>>>>> Which is to run an infinite sequence of nested
>>>>>> emulations. So it won't halt.
>>>>>
>>>>> The execution of P(P) does not represent an infinite sequence of nested
>>>>> simulations. We know that because P(P) halts.
>>>>>
>>>>>> H(P,P) also reports "non-halting". So this is
>>>>>> powerful evidence that H is correct.
>>>>>
>>>>> Eh? How is some code eyeballing more compelling evidence than the 100%
>>>>> undisputed fact that P(P) halts? How is the opinion of someone who
>>>>> can't write a parity checking TM powerful evidence of anything?
>>>>>
>>>>>> However when he actually executes P(P) on hardware, it terminates.
>>>>>> Something isn't right.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> PO's explanation is that P(P) has different correct behaviour when run and
>>>>>> when emulated by H.
>>>>>
>>>>> That can't be an explanation of anything because, according to you, he
>>>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the
>>>>> dry run and the actual run must take account of the fact that H is
>>>>> (partially) emulating P(P).
>>>>>
>>>>>> I can think of an obvious alternative explanation which is much
>>>>>> simpler and much less far-reaching in its implications. However
>>>>>> despite a lot of coaxing, no-one else seems to have arrived at it.
>>>>>
>>>>> There is nothing here with any far-reaching implications and since I've
>>>>> never shared your explanation, I'm not going to look for an alternative.
>>>>>
>>>>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
>>>>> relying on sophistry. H "aborts" so P never reaches its "ret"
>>>>> instruction. That's why P(P) and "the simulation of the inputs to
>>>>> H(P,P)" are different. 18 years of work for what? An H that, on the
>>>>> basis of his own words, obviously gets the wrong answer.
>>>>>
>>>> The ordinary semantics of standard C and the conventional x86 language
>>>> are the entire semantics required to conclusively prove that H(P,P) does
>>>> correctly determine that its correct and complete x86 emulation of its
>>>> input would never reach the "ret" instruction (final state) of this
>>>> input thus never halts.
>>>> That your understanding of the semantics of the x86 language is
>>>> insufficient to directly confirm this is less than no rebuttal at all.
>>>
>>> I assume the semantics of C are defined by the 1989 Standard. The
>>> semantics of x86 assembly language are described (not actually
>>> authoritatively defined) in other documents. The mapping of C onto
>>> the assembly language is far from unique (every compiler could be
>>> different) PO appears to using a version of Microsoft's C# compiler.
>>>
>> The COFF object file generated by most any Microsoft C compiler.
>> I used Visual Studio 2017 Community Edition.
>>
>> x86 Instruction Set Reference: https://c9x.me/x86/
>>> Then we must define how a Turing machine is emulated by a C
>>> program. All that is needed of C is the struct concept and
>>> assignment. In that case using C seems unadvisable.
>>>
>> No we don't need this at all. We only need to know that a C function
>> that is a pure function of its inputs is Turing equivalent.
>>
>> https://en.wikipedia.org/wiki/Pure_function
>
> You are jumping too far in one step. What I am asking is equivalent to:
> Given a Turing Machine how do its steps map into C and thence into x86?
> No C functions are involved.
>

On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> > 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.
> >
> > 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. 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.
> >
> > 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.
>
> I already proved that the dry run is correct.
>
Someone reports that tigers use more energy than they take in, and concludes that
the energy conservation law is incorrect.
Naturally, everyone is going to say "There must be some mistake. How were your
measurements taken? Show us your calculations, maybe you've got your sums wrong."

Now if they are also uncooperative about sharing the details of the investigation,
those reservations will be magnified. There can be legitimate reasons. Tigers are
rare and need to be conserved, you can't let anyone who wants have access to the
tigers to try to repeat the measurements. But there's also a common illegitimate
reason put forwards by people who make extraordinary claims. If the claims were
unexceptional, such as that tigers have a similar energy budget to lions, then no-one
would be saying "Show me your notebooks. How do you know that calorimeter was
calibrated accurately? What's the name of the person who took that measurement
and can I interview them?" Extraordinary claims are put through the wringer in a way
that ordinary ones are not. I've seen complaints about this from parapsychologists.
But if you're going to claim to have discovered a new physical principle, you need
to present rock solid evidence.

In this case, we can't see H. We can only suggest explanations for its behaviour.

On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>> 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.
>>>
>>> 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. 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.
>>>
>>> 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.
>>
>> I already proved that the dry run is correct.
>>
> Someone reports that tigers use more energy than they take in, and concludes that
> the energy conservation law is incorrect.
> Naturally, everyone is going to say "There must be some mistake. How were your
> measurements taken? Show us your calculations, maybe you've got your sums wrong."
>
> Now if they are also uncooperative about sharing the details of the investigation,
> those reservations will be magnified. There can be legitimate reasons. Tigers are
> rare and need to be conserved, you can't let anyone who wants have access to the
> tigers to try to repeat the measurements. But there's also a common illegitimate
> reason put forwards by people who make extraordinary claims. If the claims were
> unexceptional, such as that tigers have a similar energy budget to lions, then no-one
> would be saying "Show me your notebooks. How do you know that calorimeter was
> calibrated accurately? What's the name of the person who took that measurement
> and can I interview them?" Extraordinary claims are put through the wringer in a way
> that ordinary ones are not. I've seen complaints about this from parapsychologists.
> But if you're going to claim to have discovered a new physical principle, you need
> to present rock solid evidence.
>
> In this case, we can't see H. We can only suggest explanations for its behaviour.

It seems that you simply lack the technical competence.
Go back and look at my proof again.

--
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 Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> > On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> >> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>> 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.
> >>>
> >>> 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. 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.
> >>>
> >>> 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.
> >>
> >> I already proved that the dry run is correct.
> >>
> > Someone reports that tigers use more energy than they take in, and concludes that
> > the energy conservation law is incorrect.
> > Naturally, everyone is going to say "There must be some mistake. How were your
> > measurements taken? Show us your calculations, maybe you've got your sums wrong."
> >
> > Now if they are also uncooperative about sharing the details of the investigation,
> > those reservations will be magnified. There can be legitimate reasons. Tigers are
> > rare and need to be conserved, you can't let anyone who wants have access to the
> > tigers to try to repeat the measurements. But there's also a common illegitimate
> > reason put forwards by people who make extraordinary claims. If the claims were
> > unexceptional, such as that tigers have a similar energy budget to lions, then no-one
> > would be saying "Show me your notebooks. How do you know that calorimeter was
> > calibrated accurately? What's the name of the person who took that measurement
> > and can I interview them?" Extraordinary claims are put through the wringer in a way
> > that ordinary ones are not. I've seen complaints about this from parapsychologists.
> > But if you're going to claim to have discovered a new physical principle, you need
> > to present rock solid evidence.
> >
> > In this case, we can't see H. We can only suggest explanations for its behaviour.
> It seems that you simply lack the technical competence.
> Go back and look at my proof again.
>
Sorry no. I've been programming since I was a boy and I have a PhD in a computational-
related subject. I'm confident of my technical abilities. What I can't do of course
is tell you exactly what is going on in code I cannot see. I've got a pretty good idea,
but I can only reconstruct on the basis of what you tell me. Ben thinks that I've
got it wrong and in fact there are no nested emulations at all. I've no way of actually
disproving that idea without seeing H.

On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
> On 6/24/2022 3:05 PM, Paul N wrote:
> > On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:
> >> On 6/22/2022 9:23 PM, Dennis Bush wrote:
> >>> On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
> >>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
> >>>>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
> >>>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
> >>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
> >>>>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
> >>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
> >>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>>>>>> #define u32 uint32_t
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
> >>>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
> >>>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
> >>>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
> >>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
> >>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
> >>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
> >>>>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
> >>>>>>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
> >>>>>>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
> >>>>>>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> If H does correctly determine that this is the case in a finite
> >>>>>>>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
> >>>>>>>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
> >>>>>>>>>>>>>>>>>> steps.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> typedef struct Decoded
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> u32 Address;
> >>>>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
> >>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
> >>>>>>>>>>>>>>>>>> u32 NumBytes;
> >>>>>>>>>>>>>>>>>> u32 Simplified_Opcode;
> >>>>>>>>>>>>>>>>>> u32 Decode_Target;
> >>>>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>>>>>>>> address address data code language
> >>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
> >>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
> >>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
> >>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
> >>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
> >>>>>>>>>>>>>>>>>> u32 H(u32 P, u32 I)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> HERE:
> >>>>>>>>>>>>>>>>>> u32 End_Of_Code;
> >>>>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
> >>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
> >>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> >>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
> >>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
> >>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>>>>>>>>>> Registers* slave_state = (Registers*)
> >>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
> >>>>>>>>>>>>>>>>>> u32 execution_trace =
> >>>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> >>>>>>>>>>>>>>>>>> * 1000);
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
> >>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
> >>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
> >>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
> >>>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
> >>>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> >>>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
> >>>>>>>>>>>>>>>>>> execution_trace);
> >>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
> >>>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>>>>>>>>>>>>>> goto END_OF_CODE;
> >>>>>>>>>>>>>>>>>> return 0; // Does not halt
> >>>>>>>>>>>>>>>>>> END_OF_CODE:
> >>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
> >>>>>>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
> >>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
> >>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
> >>>>>>>>>>>>>>>>>> infinitely recursive emulation.
> >>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Technically competent software engineers may not know this computer
> >>>>>>>>>>>>>>>>>> science:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
> >>>>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> >>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
> >>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>>>>>>>>>>>>>>>> Input_Halts = 0
> >>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
> >>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
> >>>>>>>>>>>>>>>>> QED.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You and Richard are insufficiently technically competent at software
> >>>>>>>>>>>>>>>> engineering not meeting these specs:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> A software engineer must be an expert in: the C programming language,
> >>>>>>>>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
> >>>>>>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
> >>>>>>>>>>>>>>>> language level. No knowledge of the halting problem is required.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
> >>>>>>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
> >>>>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
> >>>>>>>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
> >>>>>>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
> >>>>>>>>>>>>>>> omnishambles:
> >>>>>>>>>>>>>> If you are competent then you already know this is true and lie about it:
> >>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
> >>>>>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>>>>>>>>>>>> would never reach the "ret" instruction of P because both H and P would
> >>>>>>>>>>>>>> remain stuck in infinitely recursive emulation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
> >>>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>>>>>>>>>> would never reach the "ret" instruction of Px because both H and Px
> >>>>>>>>>>>> would remain stuck in infinitely recursive emulation.
> >>>>>>>>>>>
> >>>>>>>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
> >>>>>>>>>> Your entire basis and all of assumptions was incorrect so when I
> >>>>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
> >>>>>>>>>> you simply dodged it. That is a smart move for a dishonest person that
> >>>>>>>>>> is only interested in rebuttal.
> >>>>>>>>>>
> >>>>>>>>>> I dare you to go back to the prior post and find any error in my
> >>>>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
> >>>>>>>>>> admission of defeat.
> >>>>>>>>>
> >>>>>>>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
> >>>>>>>> I never claimed that H(P,P) performs a complete and correct emulation of
> >>>>>>>> its input so your rebuttal is the strawman deception.
> >>>>>>>>
> >>>>>>>> I claimed that H(P,P) correctly predicts that its complete and correct
> >>>>>>>> x86 emulation of its input would never reach the "ret" instruction of P.
> >>>>>>>
> >>>>>>> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
> >>>>>> _Infinite_Loop()
> >>>>>> [00001082](01) 55 push ebp
> >>>>>> [00001083](02) 8bec mov ebp,esp
> >>>>>> [00001085](02) ebfe jmp 00001085
> >>>>>> [00001087](01) 5d pop ebp
> >>>>>> [00001088](01) c3 ret
> >>>>>> Size in bytes:(0007) [00001088]
> >>>>>>
> >>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
> >>>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
> >>>>>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
> >>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> >>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> >>>>>> Infinite Loop Detected Simulation Stopped
> >>>>>>
> >>>>>> On the basis of this exact same utterly moronic reasoning because H
> >>>>>> *can't* do a correct and complete emulation of its input, H cannot
> >>>>>> possibly determine that _Infinite_Loop() never halts.
> >>>>>
> >>>>> Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right.. B
> >>>> You just said that H(P,P) cannot correctly predict that the correct and
> >>>> complete x86 emulation of its input would never reach the "ret"
> >>>> instruction of P without a compete x86 emulation of its input. I just
> >>>> proved that is a very stupid thing to say.
> >>>
> >>> You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,P), would do. And it fails to do that.
> >> From a purely software engineering perspective H(P,P) is required to to
> >> correctly determine that its correct and complete x86 emulation of its
> >> input would never reach the "ret" instruction of this input and H must
> >> do this in a finite number of steps.
> >>
> >> The ordinary semantics of standard C and the conventional x86 language
> >> are the entire semantics required to conclusively prove that H(P,P) does
> >> correctly determine that its correct and complete x86 emulation of its
> >> input would never reach the "ret" instruction.
> >>
> >> That you disagree with easily verified software engineering when you
> >> already know that this software engineering is correct speaks loads
> >> about your character.
> >>
> >> The only computer science that need be added to this is that the "ret"
> >> instruction is the final state of P and that a sequence of
> >> configurations that cannot possibly reach its final state is a
> >> non-halting sequence.
> >
> > You say that "H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input". You seem to be assuming that H does an emulation of P, that this emulation includes emulating the call to H, that this call to H would start emulating the call to P, etc, etc, and so the call to P does not terminate.
> >
> Thanks for continuing to review this.
>
> No assumptions two years of software development derived fully
> operational software that conclusively proves this.

On 6/25/22 12:33 AM, olcott wrote:
> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>> 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.
>>
>> 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. 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.
>>
>> 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.
>
> I already proved that the dry run is correct.
>
>

No, becasue the H in the dry run isn't the H in the final, thus your P's
are different computations (even if they have the same partial source code).

As you have said, the behavior of P(p) is dependent on the behavior of
the behavior of H(P,P), so if you change the latter, you have changed
the former, and thus your dry run was looking at the WRONG P.

On 6/25/2022 6:56 AM, Paul N wrote:
> On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
>> On 6/24/2022 3:05 PM, Paul N wrote:
>>> On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:
>>>> On 6/22/2022 9:23 PM, Dennis Bush wrote:
>>>>> On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
>>>>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
>>>>>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>>>>>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>>>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
>>>>>>>>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>>>>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
>>>>>>>>>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
>>>>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>>>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> HERE:
>>>>>>>>>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>>>>>>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Technically competent software engineers may not know this computer
>>>>>>>>>>>>>>>>>>>> science:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>>>>>>>>>>>>>>>>>> QED.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You and Richard are insufficiently technically competent at software
>>>>>>>>>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A software engineer must be an expert in: the C programming language,
>>>>>>>>>>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
>>>>>>>>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
>>>>>>>>>>>>>>>>>> language level. No knowledge of the halting problem is required.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
>>>>>>>>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
>>>>>>>>>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
>>>>>>>>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>>>>>>>>>>>> omnishambles:
>>>>>>>>>>>>>>>> If you are competent then you already know this is true and lie about it:
>>>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>>>>>>>>>> would never reach the "ret" instruction of P because both H and P would
>>>>>>>>>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>>>>>>>> would never reach the "ret" instruction of Px because both H and Px
>>>>>>>>>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
>>>>>>>>>>>> Your entire basis and all of assumptions was incorrect so when I
>>>>>>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
>>>>>>>>>>>> you simply dodged it. That is a smart move for a dishonest person that
>>>>>>>>>>>> is only interested in rebuttal.
>>>>>>>>>>>>
>>>>>>>>>>>> I dare you to go back to the prior post and find any error in my
>>>>>>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
>>>>>>>>>>>> admission of defeat.
>>>>>>>>>>>
>>>>>>>>>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
>>>>>>>>>> I never claimed that H(P,P) performs a complete and correct emulation of
>>>>>>>>>> its input so your rebuttal is the strawman deception.
>>>>>>>>>>
>>>>>>>>>> I claimed that H(P,P) correctly predicts that its complete and correct
>>>>>>>>>> x86 emulation of its input would never reach the "ret" instruction of P.
>>>>>>>>>
>>>>>>>>> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
>>>>>>>> _Infinite_Loop()
>>>>>>>> [00001082](01) 55 push ebp
>>>>>>>> [00001083](02) 8bec mov ebp,esp
>>>>>>>> [00001085](02) ebfe jmp 00001085
>>>>>>>> [00001087](01) 5d pop ebp
>>>>>>>> [00001088](01) c3 ret
>>>>>>>> Size in bytes:(0007) [00001088]
>>>>>>>>
>>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
>>>>>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
>>>>>>>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
>>>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>>>>>> Infinite Loop Detected Simulation Stopped
>>>>>>>>
>>>>>>>> On the basis of this exact same utterly moronic reasoning because H
>>>>>>>> *can't* do a correct and complete emulation of its input, H cannot
>>>>>>>> possibly determine that _Infinite_Loop() never halts.
>>>>>>>
>>>>>>> Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
>>>>>> You just said that H(P,P) cannot correctly predict that the correct and
>>>>>> complete x86 emulation of its input would never reach the "ret"
>>>>>> instruction of P without a compete x86 emulation of its input. I just
>>>>>> proved that is a very stupid thing to say.
>>>>>
>>>>> You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,P), would do. And it fails to do that.
>>>> From a purely software engineering perspective H(P,P) is required to to
>>>> correctly determine that its correct and complete x86 emulation of its
>>>> input would never reach the "ret" instruction of this input and H must
>>>> do this in a finite number of steps.
>>>>
>>>> The ordinary semantics of standard C and the conventional x86 language
>>>> are the entire semantics required to conclusively prove that H(P,P) does
>>>> correctly determine that its correct and complete x86 emulation of its
>>>> input would never reach the "ret" instruction.
>>>>
>>>> That you disagree with easily verified software engineering when you
>>>> already know that this software engineering is correct speaks loads
>>>> about your character.
>>>>
>>>> The only computer science that need be added to this is that the "ret"
>>>> instruction is the final state of P and that a sequence of
>>>> configurations that cannot possibly reach its final state is a
>>>> non-halting sequence.
>>>
>>> You say that "H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input". You seem to be assuming that H does an emulation of P, that this emulation includes emulating the call to H, that this call to H would start emulating the call to P, etc, etc, and so the call to P does not terminate.
>>>
>> Thanks for continuing to review this.
>>
>> No assumptions two years of software development derived fully
>> operational software that conclusively proves this.
>
> It might help people's understanding if we had a few more examples. Suppose, in addition to the normal P and H, we have two more functions as follows:
>
> void Q(void)
> {
> if (H(P, P))
> H2: goto H2;
> return;
> }
>
> void R(void)
> {
> H(P, P);
> return;
> }
>
> Will Q return? Will R return?
>

On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>> 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.
>>>>>
>>>>> 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. 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.
>>>>>
>>>>> 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.
>>>>
>>>> I already proved that the dry run is correct.
>>>>
>>> Someone reports that tigers use more energy than they take in, and concludes that
>>> the energy conservation law is incorrect.
>>> Naturally, everyone is going to say "There must be some mistake. How were your
>>> measurements taken? Show us your calculations, maybe you've got your sums wrong."
>>>
>>> Now if they are also uncooperative about sharing the details of the investigation,
>>> those reservations will be magnified. There can be legitimate reasons. Tigers are
>>> rare and need to be conserved, you can't let anyone who wants have access to the
>>> tigers to try to repeat the measurements. But there's also a common illegitimate
>>> reason put forwards by people who make extraordinary claims. If the claims were
>>> unexceptional, such as that tigers have a similar energy budget to lions, then no-one
>>> would be saying "Show me your notebooks. How do you know that calorimeter was
>>> calibrated accurately? What's the name of the person who took that measurement
>>> and can I interview them?" Extraordinary claims are put through the wringer in a way
>>> that ordinary ones are not. I've seen complaints about this from parapsychologists.
>>> But if you're going to claim to have discovered a new physical principle, you need
>>> to present rock solid evidence.
>>>
>>> In this case, we can't see H. We can only suggest explanations for its behaviour.
>> It seems that you simply lack the technical competence.
>> Go back and look at my proof again.
>>
> Sorry no. I've been programming since I was a boy and I have a PhD in a computational-
> related subject. I'm confident of my technical abilities. What I can't do of course
> is tell you exactly what is going on in code I cannot see. I've got a pretty good idea,
> but I can only reconstruct on the basis of what you tell me. Ben thinks that I've
> got it wrong and in fact there are no nested emulations at all. I've no way of actually
> disproving that idea without seeing H.
>

To fully understand this a software engineer must be an expert in:
(a) The C programming language,
(b) The x86 programming language,
(c) Exactly how C translates into x86 and,
(d) The ability to recognize infinite recursion at the x86 assembly
language level.

Anyone having the above credentials can validate my work, if you cannot
validate my work then you do not sufficiently have the above credentials.

Exactly how C translates into x86 is mandatory. If you don't know how
the C calling conventions are implemented in x86 you cannot validate my
work.

From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.

The correct and complete x86 emulation of its input by H(P,P) would
never reach the "ret" instruction of P because both H and P would remain
stuck in infinitely nested emulation.

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

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

_P()
[00001202](01) 55 push ebp
[00001203](02) 8bec mov ebp,esp
[00001205](03) 8b4508 mov eax,[ebp+08]
[00001208](01) 50 push eax
[00001209](03) 8b4d08 mov ecx,[ebp+08]
[0000120c](01) 51 push ecx
[0000120d](05) e820feffff call 00001032
[00001212](03) 83c408 add esp,+08
[00001215](02) 85c0 test eax,eax
[00001217](02) 7402 jz 0000121b
[00001219](02) ebfe jmp 00001219
[0000121b](01) 5d pop ebp
[0000121c](01) c3 ret
Size in bytes:(0027) [0000121c]

_main()
[00001222](01) 55 push ebp
[00001223](02) 8bec mov ebp,esp
[00001225](05) 6802120000 push 00001202
[0000122a](05) 6802120000 push 00001202
[0000122f](05) e8fefdffff call 00001032
[00001234](03) 83c408 add esp,+08
[00001237](01) 50 push eax
[00001238](05) 68b3030000 push 000003b3
[0000123d](05) e8c0f1ffff call 00000402
[00001242](03) 83c408 add esp,+08
[00001245](02) 33c0 xor eax,eax
[00001247](01) 5d pop ebp
[00001248](01) c3 ret
Size in bytes:(0039) [00001248]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001222][0010200f][00000000] 55 push ebp
[00001223][0010200f][00000000] 8bec mov ebp,esp
[00001225][0010200b][00001202] 6802120000 push 00001202 // push P
[0000122a][00102007][00001202] 6802120000 push 00001202 // push P
[0000122f][00102003][00001234] e8fefdffff call 00001032 // call executed H

Begin Simulation Execution Trace Stored at:2120c3
Address_of_H:1032
[00001202][002120af][002120b3] 55 push ebp
[00001203][002120af][002120b3] 8bec mov ebp,esp
[00001205][002120af][002120b3] 8b4508 mov eax,[ebp+08]
[00001208][002120ab][00001202] 50 push eax // push P
[00001209][002120ab][00001202] 8b4d08 mov ecx,[ebp+08]
[0000120c][002120a7][00001202] 51 push ecx // push P
[0000120d][002120a3][00001212] e820feffff call 00001032 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.

[00001234][0010200f][00000000] 83c408 add esp,+08
[00001237][0010200b][00000000] 50 push eax
[00001238][00102007][000003b3] 68b3030000 push 000003b3
[0000123d][00102007][000003b3] e8c0f1ffff call 00000402
Input_Halts = 0
[00001242][0010200f][00000000] 83c408 add esp,+08
[00001245][0010200f][00000000] 33c0 xor eax,eax
[00001247][00102013][00100000] 5d pop ebp
[00001248][00102017][00000004] c3 ret
Number of Instructions Executed(870) / 67 = 13 pages

On Sat, 25 Jun 2022 09:10:41 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 6:56 AM, Paul N wrote:
> > On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
> >> On 6/24/2022 3:05 PM, Paul N wrote:
> >>> On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:
> >>>> On 6/22/2022 9:23 PM, Dennis Bush wrote:
> >>>>> On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
> >>>>>
> >>>>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott
> >>>>>>> wrote:
> >>>>>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
> >>>>>>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott
> >>>>>>>>> wrote:
> >>>>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4,
> >>>>>>>>>>>>>>> olcott wrote:
> >>>>>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
> >>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
> >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>>>>>>>> #define u32 uint32_t
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
> >>>>>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
> >>>>>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
> >>>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
> >>>>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
> >>>>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
> >>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Every sufficiently competent software engineer
> >>>>>>>>>>>>>>>>>>>> can easily verify that the complete and correct
> >>>>>>>>>>>>>>>>>>>> x86 emulation of the input to H(P,P) by H would
> >>>>>>>>>>>>>>>>>>>> never reach the "ret" instruction of P because
> >>>>>>>>>>>>>>>>>>>> both H and P would remain stuck in infinitely
> >>>>>>>>>>>>>>>>>>>> recursive emulation.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> If H does correctly determine that this is the
> >>>>>>>>>>>>>>>>>>>> case in a finite number of steps then H could
> >>>>>>>>>>>>>>>>>>>> reject its input on this basis. Here are the
> >>>>>>>>>>>>>>>>>>>> details of exactly how H does this in a finite
> >>>>>>>>>>>>>>>>>>>> number of steps.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> typedef struct Decoded
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> u32 Address;
> >>>>>>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
> >>>>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
> >>>>>>>>>>>>>>>>>>>> u32 NumBytes;
> >>>>>>>>>>>>>>>>>>>> u32 Simplified_Opcode;
> >>>>>>>>>>>>>>>>>>>> u32 Decode_Target;
> >>>>>>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>>>>>>>>>> address address data code language
> >>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========> >>>>>>>>>>>>>>>>>>>> ============= [000010d2][00211e8a][00211e8e] 55
> >>>>>>>>>>>>>>>>>>>> push ebp [000010d3][00211e8a][00211e8e] 8bec mov
> >>>>>>>>>>>>>>>>>>>> ebp,esp [000010d5][00211e8a][00211e8e] 8b4508
> >>>>>>>>>>>>>>>>>>>> mov eax,[ebp+08] [000010d8][00211e86][000010d2]
> >>>>>>>>>>>>>>>>>>>> 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov
> >>>>>>>>>>>>>>>>>>>> ecx,[ebp+08] [000010dc][00211e82][000010d2] 51
> >>>>>>>>>>>>>>>>>>>> push ecx // push P
> >>>>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call
> >>>>>>>>>>>>>>>>>>>> 00000f02 // call H Infinitely Recursive
> >>>>>>>>>>>>>>>>>>>> Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> // actual fully operational code in the x86utm
> >>>>>>>>>>>>>>>>>>>> operating system u32 H(u32 P, u32 I)
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> HERE:
> >>>>>>>>>>>>>>>>>>>> u32 End_Of_Code;
> >>>>>>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
> >>>>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
> >>>>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded > >>>>>>>>>>>>>>>>>>>> (Decoded_Line_Of_Code*)
> >>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
> >>>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
> >>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); Registers*
> >>>>>>>>>>>>>>>>>>>> slave_state = (Registers*)
> >>>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers)); u32* slave_stack > >>>>>>>>>>>>>>>>>>>> Allocate(0x10000); // 64k; u32 execution_trace > >>>>>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> >>>>>>>>>>>>>>>>>>>> * 1000);
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
> >>>>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
> >>>>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
> >>>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
> >>>>>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); //
> >>>>>>>>>>>>>>>>>>>> 2022-06-11 Init_slave_state(P, I, End_Of_Code,
> >>>>>>>>>>>>>>>>>>>> slave_state, slave_stack); Output("\nBegin
> >>>>>>>>>>>>>>>>>>>> Simulation Execution Trace Stored at:",
> >>>>>>>>>>>>>>>>>>>> execution_trace); if
> >>>>>>>>>>>>>>>>>>>> (Decide_Halting(&execution_trace, &decoded,
> >>>>>>>>>>>>>>>>>>>> code_end, &master_state, &slave_state,
> >>>>>>>>>>>>>>>>>>>> &slave_stack, Address_of_H, P, I)) goto
> >>>>>>>>>>>>>>>>>>>> END_OF_CODE; return 0; // Does not halt
> >>>>>>>>>>>>>>>>>>>> END_OF_CODE: return 1; // Input has normally
> >>>>>>>>>>>>>>>>>>>> terminated }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this
> >>>>>>>>>>>>>>>>>>>> basis it can easily examine its stored
> >>>>>>>>>>>>>>>>>>>> execution_trace of P and determine: (a) P is
> >>>>>>>>>>>>>>>>>>>> calling H with the same arguments that H was
> >>>>>>>>>>>>>>>>>>>> called with. (b) No instructions in P could
> >>>>>>>>>>>>>>>>>>>> possibly escape this otherwise infinitely
> >>>>>>>>>>>>>>>>>>>> recursive emulation. (c) H aborts its emulation
> >>>>>>>>>>>>>>>>>>>> of P before its call to H is invoked.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Technically competent software engineers may not
> >>>>>>>>>>>>>>>>>>>> know this computer science:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will
> >>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state.
> >>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal
> >>>>>>>>>>>>>>>>>>>> Languages and Automata. Lexington/Toronto: D. C.
> >>>>>>>>>>>>>>>>>>>> Heath and Company. (317-320)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add
> >>>>>>>>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50 push
> >>>>>>>>>>>>>>>>>>> eax ...[000013ec][0010234f][00000427] 6827040000
> >>>>>>>>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427]
> >>>>>>>>>>>>>>>>>>> e880f0ffff call 00000476 Input_Halts = 0
> >>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add
> >>>>>>>>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
> >>>>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
> >>>>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 ret
> >>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been
> >>>>>>>>>>>>>>>>>>> decided correctly. QED.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You and Richard are insufficiently technically
> >>>>>>>>>>>>>>>>>> competent at software engineering not meeting
> >>>>>>>>>>>>>>>>>> these specs:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> A software engineer must be an expert in: the C
> >>>>>>>>>>>>>>>>>> programming language, the x86 programming
> >>>>>>>>>>>>>>>>>> language, exactly how C translates into x86 and
> >>>>>>>>>>>>>>>>>> the ability to recognize infinite recursion at the
> >>>>>>>>>>>>>>>>>> x86 assembly language level. No knowledge of the
> >>>>>>>>>>>>>>>>>> halting problem is required.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++
> >>>>>>>>>>>>>>>>> experience; I also have C and x86 assembly
> >>>>>>>>>>>>>>>>> experience (I once wrote a Zilog Z80A CPU emulator
> >>>>>>>>>>>>>>>>> in 80286 assembly) and I can recognize an infinite
> >>>>>>>>>>>>>>>>> recursion; the problem is that you cannot recognize
> >>>>>>>>>>>>>>>>> the fact that the infinite recursion only manifests
> >>>>>>>>>>>>>>>>> as part of your invalid simulation-based
> >>>>>>>>>>>>>>>>> omnishambles:
> >>>>>>>>>>>>>>>> If you are competent then you already know this is
> >>>>>>>>>>>>>>>> true and lie about it: Every sufficiently competent
> >>>>>>>>>>>>>>>> software engineer can easily verify that the
> >>>>>>>>>>>>>>>> complete and correct x86 emulation of the input to
> >>>>>>>>>>>>>>>> H(Px,Px) by H would never reach the "ret"
> >>>>>>>>>>>>>>>> instruction of P because both H and P would remain
> >>>>>>>>>>>>>>>> stuck in infinitely recursive emulation.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> H (if it was constructed correctly) is a computation,
> >>>>>>>>>>>>>>> and a computation *always* gives the same output for
> >>>>>>>>>>>>>>> a given input. So it doesn't make sense to say what
> >>>>>>>>>>>>>>> it "would" do. It either does or does not perform a
> >>>>>>>>>>>>>>> complete and correct emulation. And because H
> >>>>>>>>>>>>>>> contains code to abort, and does abort, it does not
> >>>>>>>>>>>>>>> do a complete emulation.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So the input must be given to a UTM, which by
> >>>>>>>>>>>>>>> definition does a correct and complete simulation, to
> >>>>>>>>>>>>>>> see what the actual behavior is. UTM(Px,Px) halts,
> >>>>>>>>>>>>>>> therefore H(Px,Px)==0 is wrong.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Every sufficiently competent software engineer can
> >>>>>>>>>>>>>> easily verify that the complete and correct x86
> >>>>>>>>>>>>>> emulation of the input to H(Px,Px) by H would never
> >>>>>>>>>>>>>> reach the "ret" instruction of Px because both H and
> >>>>>>>>>>>>>> Px would remain stuck in infinitely recursive
> >>>>>>>>>>>>>> emulation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So you just repeated what you said instead of
> >>>>>>>>>>>>> explaining why I'm wrong. In other words you provided
> >>>>>>>>>>>>> no rebuttal, which can only be taken to mean that you
> >>>>>>>>>>>>> have none.
> >>>>>>>>>>>> Your entire basis and all of assumptions was incorrect
> >>>>>>>>>>>> so when I provided an infallible one to that cannot
> >>>>>>>>>>>> possibly be correctly refuted you simply dodged it. That
> >>>>>>>>>>>> is a smart move for a dishonest person that is only
> >>>>>>>>>>>> interested in rebuttal.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I dare you to go back to the prior post and find any
> >>>>>>>>>>>> error in my airtight correct reasoning. Another dodge
> >>>>>>>>>>>> will be construed as a tacit admission of defeat.
> >>>>>>>>>>>
> >>>>>>>>>>> As stated before H (or more accurately Ha) does not
> >>>>>>>>>>> perform a complete and correct emulation because it
> >>>>>>>>>>> aborts. So by definition it cannot be complete.
> >>>>>>>>>> I never claimed that H(P,P) performs a complete and
> >>>>>>>>>> correct emulation of its input so your rebuttal is the
> >>>>>>>>>> strawman deception.
> >>>>>>>>>>
> >>>>>>>>>> I claimed that H(P,P) correctly predicts that its complete
> >>>>>>>>>> and correct x86 emulation of its input would never reach
> >>>>>>>>>> the "ret" instruction of P.
> >>>>>>>>>
> >>>>>>>>> But since H, or more accurately Ha, *can't* do a correct
> >>>>>>>>> and complete emulation of its input, your point is moot.
> >>>>>>>> _Infinite_Loop()
> >>>>>>>> [00001082](01) 55 push ebp
> >>>>>>>> [00001083](02) 8bec mov ebp,esp
> >>>>>>>> [00001085](02) ebfe jmp 00001085
> >>>>>>>> [00001087](01) 5d pop ebp
> >>>>>>>> [00001088](01) c3 ret
> >>>>>>>> Size in bytes:(0007) [00001088]
> >>>>>>>>
> >>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
> >>>>>>>> at:211e8f ...[00001082][00211e7f][00211e83] 55 push ebp
> >>>>>>>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
> >>>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> >>>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> >>>>>>>> Infinite Loop Detected Simulation Stopped
> >>>>>>>>
> >>>>>>>> On the basis of this exact same utterly moronic reasoning
> >>>>>>>> because H *can't* do a correct and complete emulation of its
> >>>>>>>> input, H cannot possibly determine that _Infinite_Loop()
> >>>>>>>> never halts.
> >>>>>>>
> >>>>>>> Now who's using the strawman error? Just because H can
> >>>>>>> determine that _Infinite_Loop does not halt doesn't mean that
> >>>>>>> it gets other cases right. B
> >>>>>> You just said that H(P,P) cannot correctly predict that the
> >>>>>> correct and complete x86 emulation of its input would never
> >>>>>> reach the "ret" instruction of P without a compete x86
> >>>>>> emulation of its input. I just proved that is a very stupid
> >>>>>> thing to say.
> >>>>>
> >>>>> You said that H can predict what *its* correct and complete
> >>>>> emulation would do, and I said that doesn't make sense because
> >>>>> H does not do correct and complete emulation. What H *must* do
> >>>>> is predict what *the* correct and complete emulation, i.e.
> >>>>> UTM(P,P), would do. And it fails to do that.
> >>>> From a purely software engineering perspective H(P,P) is
> >>>> required to to correctly determine that its correct and complete
> >>>> x86 emulation of its input would never reach the "ret"
> >>>> instruction of this input and H must do this in a finite number
> >>>> of steps.
> >>>>
> >>>> The ordinary semantics of standard C and the conventional x86
> >>>> language are the entire semantics required to conclusively prove
> >>>> that H(P,P) does correctly determine that its correct and
> >>>> complete x86 emulation of its input would never reach the "ret"
> >>>> instruction.
> >>>>
> >>>> That you disagree with easily verified software engineering when
> >>>> you already know that this software engineering is correct
> >>>> speaks loads about your character.
> >>>>
> >>>> The only computer science that need be added to this is that the
> >>>> "ret" instruction is the final state of P and that a sequence of
> >>>> configurations that cannot possibly reach its final state is a
> >>>> non-halting sequence.
> >>>
> >>> You say that "H(P,P) is required to to correctly determine that
> >>> its correct and complete x86 emulation of its input would never
> >>> reach the "ret" instruction of this input". You seem to be
> >>> assuming that H does an emulation of P, that this emulation
> >>> includes emulating the call to H, that this call to H would start
> >>> emulating the call to P, etc, etc, and so the call to P does not
> >>> terminate.
> >> Thanks for continuing to review this.
> >>
> >> No assumptions two years of software development derived fully
> >> operational software that conclusively proves this.
> >
> > It might help people's understanding if we had a few more examples.
> > Suppose, in addition to the normal P and H, we have two more
> > functions as follows:
> >
> > void Q(void)
> > {
> > if (H(P, P))
> > H2: goto H2;
> > return;
> > }
> >
> > void R(void)
> > {
> > H(P, P);
> > return;
> > }
> >
> > Will Q return? Will R return?
> >
>
> Yes they both return.
>
> void Q(void)
> {
> if (H(P, P))
> H2: goto H2;
> return;
> }
>
> void R(void)
> {
> H(P, P);
> return;
> }
>
> _P()
> [000011f0](01) 55 push ebp
> [000011f1](02) 8bec mov ebp,esp
> [000011f3](03) 8b4508 mov eax,[ebp+08]
> [000011f6](01) 50 push eax
> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> [000011fa](01) 51 push ecx
> [000011fb](05) e820feffff call 00001020
> [00001200](03) 83c408 add esp,+08
> [00001203](02) 85c0 test eax,eax
> [00001205](02) 7402 jz 00001209
> [00001207](02) ebfe jmp 00001207
> [00001209](01) 5d pop ebp
> [0000120a](01) c3 ret
> Size in bytes:(0027) [0000120a]
>
> _Q()
> [00001210](01) 55 push ebp
> [00001211](02) 8bec mov ebp,esp
> [00001213](05) 68f0110000 push 000011f0
> [00001218](05) 68f0110000 push 000011f0
> [0000121d](05) e8fefdffff call 00001020
> [00001222](03) 83c408 add esp,+08
> [00001225](02) 85c0 test eax,eax
> [00001227](02) 7402 jz 0000122b
> [00001229](02) ebfe jmp 00001229
> [0000122b](01) 5d pop ebp
> [0000122c](01) c3 ret
> Size in bytes:(0029) [0000122c]
>
> _main()
> [00001250](01) 55 push ebp
> [00001251](02) 8bec mov ebp,esp
> [00001253](05) e8b8ffffff call 00001210
> [00001258](02) 33c0 xor eax,eax
> [0000125a](01) 5d pop ebp
> [0000125b](01) c3 ret
> Size in bytes:(0012) [0000125b]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= ============> ...[00001250][00102048][00000000] 55 push ebp
> ...[00001251][00102048][00000000] 8bec mov ebp,esp
> ...[00001253][00102044][00001258] e8b8ffffff call 00001210
> ...[00001210][00102040][00102048] 55 push ebp
> ...[00001211][00102040][00102048] 8bec mov ebp,esp
> ...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
> ...[00001218][00102038][000011f0] 68f0110000 push 000011f0
> ...[0000121d][00102034][00001222] e8fefdffff call 00001020
>
> Begin Simulation Execution Trace Stored at:2120fc
> Address_of_H:1020
> ...[000011f0][002120e8][002120ec] 55 push ebp
> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
> ...[000011f6][002120e4][000011f0] 50 push eax
> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
> ...[000011fa][002120e0][000011f0] 51 push ecx
> ...[000011fb][002120dc][00001200] e820feffff call 00001020
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> ...[00001222][00102040][00102048] 83c408 add esp,+08
> ...[00001225][00102040][00102048] 85c0 test eax,eax
> ...[00001227][00102040][00102048] 7402 jz 0000122b
> ...[0000122b][00102044][00001258] 5d pop ebp
> ...[0000122c][00102048][00000000] c3 ret
> ...[00001258][00102048][00000000] 33c0 xor eax,eax
> ...[0000125a][0010204c][00100000] 5d pop ebp
> ...[0000125b][00102050][00000000] c3 ret
> Number of Instructions Executed(874)
>
> Above is:
> int main()
> {
> Q();
> //R();
> }
>
> ---
>
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= ============> ...[00001250][00102048][00000000] 55 push ebp
> ...[00001251][00102048][00000000] 8bec mov ebp,esp
> ...[00001253][00102044][00001258] e8d8ffffff call 00001230
> ...[00001230][00102040][00102048] 55 push ebp
> ...[00001231][00102040][00102048] 8bec mov ebp,esp
> ...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
> ...[00001238][00102038][000011f0] 68f0110000 push 000011f0
> ...[0000123d][00102034][00001242] e8defdffff call 00001020
>
> Begin Simulation Execution Trace Stored at:2120fc
> Address_of_H:1020
> ...[000011f0][002120e8][002120ec] 55 push ebp
> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
> ...[000011f6][002120e4][000011f0] 50 push eax
> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
> ...[000011fa][002120e0][000011f0] 51 push ecx
> ...[000011fb][002120dc][00001200] e820feffff call 00001020
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> ...[00001242][00102040][00102048] 83c408 add esp,+08
> ...[00001245][00102044][00001258] 5d pop ebp
> ...[00001246][00102048][00000000] c3 ret
> ...[00001258][00102048][00000000] 33c0 xor eax,eax
> ...[0000125a][0010204c][00100000] 5d pop ebp
> ...[0000125b][00102050][00000000] c3 ret
> Number of Instructions Executed(872)
>
> Above is:
> int main()
> {
> //Q();
> R();
> }

On 6/25/2022 9:28 AM, olcott wrote:
> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>> 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.
>>>>>>
>>>>>> 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. 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.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> I already proved that the dry run is correct.
>>>>>
>>>> Someone reports that tigers use more energy than they take in, and
>>>> concludes that
>>>> the energy conservation law is incorrect.
>>>> Naturally, everyone is going to say "There must be some mistake. How
>>>> were your
>>>> measurements taken? Show us your calculations, maybe you've got your
>>>> sums wrong."
>>>>
>>>> Now if they are also uncooperative about sharing the details of the
>>>> investigation,
>>>> those reservations will be magnified. There can be legitimate
>>>> reasons. Tigers are
>>>> rare and need to be conserved, you can't let anyone who wants have
>>>> access to the
>>>> tigers to try to repeat the measurements. But there's also a common
>>>> illegitimate
>>>> reason put forwards by people who make extraordinary claims. If the
>>>> claims were
>>>> unexceptional, such as that tigers have a similar energy budget to
>>>> lions, then no-one
>>>> would be saying "Show me your notebooks. How do you know that
>>>> calorimeter was
>>>> calibrated accurately? What's the name of the person who took that
>>>> measurement
>>>> and can I interview them?" Extraordinary claims are put through the
>>>> wringer in a way
>>>> that ordinary ones are not. I've seen complaints about this from
>>>> parapsychologists.
>>>> But if you're going to claim to have discovered a new physical
>>>> principle, you need
>>>> to present rock solid evidence.
>>>>
>>>> In this case, we can't see H. We can only suggest explanations for
>>>> its behaviour.
>>> It seems that you simply lack the technical competence.
>>> Go back and look at my proof again.
>>>
>> Sorry no. I've been programming since I was a boy and I have a PhD in
>> a computational-
>> related subject. I'm confident of my technical abilities. What I can't
>> do of course
>> is tell you exactly what is going on in code I cannot see. I've got a
>> pretty good idea,
>> but I can only reconstruct on the basis of what you tell me. Ben
>> thinks that I've
>> got it wrong and in fact there are no nested emulations at all. I've
>> no way of actually
>> disproving that idea without seeing H.
>>
>
> To fully understand this a software engineer must be an expert in:
> (a) The C programming language,
> (b) The x86 programming language,
> (c) Exactly how C translates into x86 and,
> (d) The ability to recognize infinite recursion at the x86 assembly
> language level.
>
> Anyone having the above credentials can validate my work, if you cannot
> validate my work then you do not sufficiently have the above credentials.
>
> Exactly how C translates into x86 is mandatory. If you don't know how
> the C calling conventions are implemented in x86 you cannot validate my
> work.
>
> From a purely software engineering perspective H(P,P) is required to to
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction of this input and H must
> do this in a finite number of steps.
>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
>
> The correct and complete x86 emulation of its input by H(P,P) would
> never reach the "ret" instruction of P because both H and P would remain
> stuck in infinitely nested emulation.
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001202](01)  55              push ebp
> [00001203](02)  8bec            mov ebp,esp
> [00001205](03)  8b4508          mov eax,[ebp+08]
> [00001208](01)  50              push eax
> [00001209](03)  8b4d08          mov ecx,[ebp+08]
> [0000120c](01)  51              push ecx
> [0000120d](05)  e820feffff      call 00001032
> [00001212](03)  83c408          add esp,+08
> [00001215](02)  85c0            test eax,eax
> [00001217](02)  7402            jz 0000121b
> [00001219](02)  ebfe            jmp 00001219
> [0000121b](01)  5d              pop ebp
> [0000121c](01)  c3              ret
> Size in bytes:(0027) [0000121c]
>
> _main()
> [00001222](01)  55              push ebp
> [00001223](02)  8bec            mov ebp,esp
> [00001225](05)  6802120000      push 00001202
> [0000122a](05)  6802120000      push 00001202
> [0000122f](05)  e8fefdffff      call 00001032
> [00001234](03)  83c408          add esp,+08
> [00001237](01)  50              push eax
> [00001238](05)  68b3030000      push 000003b3
> [0000123d](05)  e8c0f1ffff      call 00000402
> [00001242](03)  83c408          add esp,+08
> [00001245](02)  33c0            xor eax,eax
> [00001247](01)  5d              pop ebp
> [00001248](01)  c3              ret
> Size in bytes:(0039) [00001248]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001222][0010200f][00000000] 55         push ebp
> [00001223][0010200f][00000000] 8bec       mov ebp,esp
> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call executed H
>
> Begin Simulation   Execution Trace Stored at:2120c3
> Address_of_H:1032
> [00001202][002120af][002120b3] 55         push ebp
> [00001203][002120af][002120b3] 8bec       mov ebp,esp
> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
> [00001208][002120ab][00001202] 50         push eax      // push P
> [00001209][002120ab][00001202] 8b4d08     mov ecx,[ebp+08]
> [0000120c][002120a7][00001202] 51         push ecx      // push P
> [0000120d][002120a3][00001212] e820feffff call 00001032 // call emulated H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily
> examine its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.
> (c) H aborts its emulation of P before its call to H is emulated.
>

On Sat, 25 Jun 2022 10:03:17 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 9:28 AM, olcott wrote:
> > On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> >>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>> 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.
> >>>>>>
> >>>>>> 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. 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.
> >>>>>>
> >>>>>> 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.
> >>>>>
> >>>>> I already proved that the dry run is correct.
> >>>>>
> >>>> Someone reports that tigers use more energy than they take in,
> >>>> and concludes that
> >>>> the energy conservation law is incorrect.
> >>>> Naturally, everyone is going to say "There must be some mistake.
> >>>> How were your
> >>>> measurements taken? Show us your calculations, maybe you've got
> >>>> your sums wrong."
> >>>>
> >>>> Now if they are also uncooperative about sharing the details of
> >>>> the investigation,
> >>>> those reservations will be magnified. There can be legitimate
> >>>> reasons. Tigers are
> >>>> rare and need to be conserved, you can't let anyone who wants
> >>>> have access to the
> >>>> tigers to try to repeat the measurements. But there's also a
> >>>> common illegitimate
> >>>> reason put forwards by people who make extraordinary claims. If
> >>>> the claims were
> >>>> unexceptional, such as that tigers have a similar energy budget
> >>>> to lions, then no-one
> >>>> would be saying "Show me your notebooks. How do you know that
> >>>> calorimeter was
> >>>> calibrated accurately? What's the name of the person who took
> >>>> that measurement
> >>>> and can I interview them?" Extraordinary claims are put through
> >>>> the wringer in a way
> >>>> that ordinary ones are not. I've seen complaints about this from
> >>>> parapsychologists.
> >>>> But if you're going to claim to have discovered a new physical
> >>>> principle, you need
> >>>> to present rock solid evidence.
> >>>>
> >>>> In this case, we can't see H. We can only suggest explanations
> >>>> for its behaviour.
> >>> It seems that you simply lack the technical competence.
> >>> Go back and look at my proof again.
> >>>
> >> Sorry no. I've been programming since I was a boy and I have a PhD
> >> in a computational-
> >> related subject. I'm confident of my technical abilities. What I
> >> can't do of course
> >> is tell you exactly what is going on in code I cannot see. I've
> >> got a pretty good idea,
> >> but I can only reconstruct on the basis of what you tell me. Ben
> >> thinks that I've
> >> got it wrong and in fact there are no nested emulations at all.
> >> I've no way of actually
> >> disproving that idea without seeing H.
> >>
> >
> > To fully understand this a software engineer must be an expert in:
> > (a) The C programming language,
> > (b) The x86 programming language,
> > (c) Exactly how C translates into x86 and,
> > (d) The ability to recognize infinite recursion at the x86 assembly
> > language level.
> >
> > Anyone having the above credentials can validate my work, if you
> > cannot validate my work then you do not sufficiently have the above
> > credentials.
> >
> > Exactly how C translates into x86 is mandatory. If you don't know
> > how the C calling conventions are implemented in x86 you cannot
> > validate my work.
> >
> > From a purely software engineering perspective H(P,P) is required
> > to to correctly determine that its correct and complete x86
> > emulation of its input would never reach the "ret" instruction of
> > this input and H must do this in a finite number of steps.
> >
> > The ordinary semantics of standard C and the conventional x86
> > language are the entire semantics required to conclusively prove
> > that H(P,P) does correctly determine that its correct and complete
> > x86 emulation of its input would never reach the "ret" instruction
> > (final state) of this input thus never halts.
> >
> > The correct and complete x86 emulation of its input by H(P,P) would
> > never reach the "ret" instruction of P because both H and P would
> > remain stuck in infinitely nested emulation.
> >
> > void P(u32 x)
> > {
> >   if (H(x, x))
> >     HERE: goto HERE;
> >   return;
> > }
> >
> > int main()
> > {
> >   Output("Input_Halts = ", H((u32)P, (u32)P));
> > }
> >
> > _P()
> > [00001202](01)  55              push ebp
> > [00001203](02)  8bec            mov ebp,esp
> > [00001205](03)  8b4508          mov eax,[ebp+08]
> > [00001208](01)  50              push eax
> > [00001209](03)  8b4d08          mov ecx,[ebp+08]
> > [0000120c](01)  51              push ecx
> > [0000120d](05)  e820feffff      call 00001032
> > [00001212](03)  83c408          add esp,+08
> > [00001215](02)  85c0            test eax,eax
> > [00001217](02)  7402            jz 0000121b
> > [00001219](02)  ebfe            jmp 00001219
> > [0000121b](01)  5d              pop ebp
> > [0000121c](01)  c3              ret
> > Size in bytes:(0027) [0000121c]
> >
> > _main()
> > [00001222](01)  55              push ebp
> > [00001223](02)  8bec            mov ebp,esp
> > [00001225](05)  6802120000      push 00001202
> > [0000122a](05)  6802120000      push 00001202
> > [0000122f](05)  e8fefdffff      call 00001032
> > [00001234](03)  83c408          add esp,+08
> > [00001237](01)  50              push eax
> > [00001238](05)  68b3030000      push 000003b3
> > [0000123d](05)  e8c0f1ffff      call 00000402
> > [00001242](03)  83c408          add esp,+08
> > [00001245](02)  33c0            xor eax,eax
> > [00001247](01)  5d              pop ebp
> > [00001248](01)  c3              ret
> > Size in bytes:(0039) [00001248]
> >
> >  machine   stack     stack     machine    assembly
> >  address   address   data      code       language
> >  ========  ========  ========  =========  ============> > [00001222][0010200f][00000000] 55         push ebp
> > [00001223][0010200f][00000000] 8bec       mov ebp,esp
> > [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
> > [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
> > [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
> > executed H
> >
> > Begin Simulation   Execution Trace Stored at:2120c3
> > Address_of_H:1032
> > [00001202][002120af][002120b3] 55         push ebp
> > [00001203][002120af][002120b3] 8bec       mov ebp,esp
> > [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
> > [00001208][002120ab][00001202] 50         push eax      // push P
> > [00001209][002120ab][00001202] 8b4d08     mov ecx,[ebp+08]
> > [0000120c][002120a7][00001202] 51         push ecx      // push P
> > [0000120d][002120a3][00001212] e820feffff call 00001032 // call
> > emulated H Infinitely Recursive Simulation Detected Simulation
> > Stopped
> >
> > H knows its own machine address and on this basis it can easily
> > examine its stored execution_trace of P (see above) to determine:
> > (a) P is calling H with the same arguments that H was called with.
> > (b) No instructions in P could possibly escape this otherwise
> > infinitely recursive emulation.
> > (c) H aborts its emulation of P before its call to H is emulated.
> >
>
> When you know that H simply implements the above algorithm there is
> no need to see its source code. I am reserving the publication of the
> 5 pages of the source code of the halt decider for journal
> publication.

On 6/25/2022 10:09 AM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 10:03:17 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 9:28 AM, olcott wrote:
>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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. 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> I already proved that the dry run is correct.
>>>>>>>
>>>>>> Someone reports that tigers use more energy than they take in,
>>>>>> and concludes that
>>>>>> the energy conservation law is incorrect.
>>>>>> Naturally, everyone is going to say "There must be some mistake.
>>>>>> How were your
>>>>>> measurements taken? Show us your calculations, maybe you've got
>>>>>> your sums wrong."
>>>>>>
>>>>>> Now if they are also uncooperative about sharing the details of
>>>>>> the investigation,
>>>>>> those reservations will be magnified. There can be legitimate
>>>>>> reasons. Tigers are
>>>>>> rare and need to be conserved, you can't let anyone who wants
>>>>>> have access to the
>>>>>> tigers to try to repeat the measurements. But there's also a
>>>>>> common illegitimate
>>>>>> reason put forwards by people who make extraordinary claims. If
>>>>>> the claims were
>>>>>> unexceptional, such as that tigers have a similar energy budget
>>>>>> to lions, then no-one
>>>>>> would be saying "Show me your notebooks. How do you know that
>>>>>> calorimeter was
>>>>>> calibrated accurately? What's the name of the person who took
>>>>>> that measurement
>>>>>> and can I interview them?" Extraordinary claims are put through
>>>>>> the wringer in a way
>>>>>> that ordinary ones are not. I've seen complaints about this from
>>>>>> parapsychologists.
>>>>>> But if you're going to claim to have discovered a new physical
>>>>>> principle, you need
>>>>>> to present rock solid evidence.
>>>>>>
>>>>>> In this case, we can't see H. We can only suggest explanations
>>>>>> for its behaviour.
>>>>> It seems that you simply lack the technical competence.
>>>>> Go back and look at my proof again.
>>>>>
>>>> Sorry no. I've been programming since I was a boy and I have a PhD
>>>> in a computational-
>>>> related subject. I'm confident of my technical abilities. What I
>>>> can't do of course
>>>> is tell you exactly what is going on in code I cannot see. I've
>>>> got a pretty good idea,
>>>> but I can only reconstruct on the basis of what you tell me. Ben
>>>> thinks that I've
>>>> got it wrong and in fact there are no nested emulations at all.
>>>> I've no way of actually
>>>> disproving that idea without seeing H.
>>>>
>>>
>>> To fully understand this a software engineer must be an expert in:
>>> (a) The C programming language,
>>> (b) The x86 programming language,
>>> (c) Exactly how C translates into x86 and,
>>> (d) The ability to recognize infinite recursion at the x86 assembly
>>> language level.
>>>
>>> Anyone having the above credentials can validate my work, if you
>>> cannot validate my work then you do not sufficiently have the above
>>> credentials.
>>>
>>> Exactly how C translates into x86 is mandatory. If you don't know
>>> how the C calling conventions are implemented in x86 you cannot
>>> validate my work.
>>>
>>> From a purely software engineering perspective H(P,P) is required
>>> to to correctly determine that its correct and complete x86
>>> emulation of its input would never reach the "ret" instruction of
>>> this input and H must do this in a finite number of steps.
>>>
>>> The ordinary semantics of standard C and the conventional x86
>>> language are the entire semantics required to conclusively prove
>>> that H(P,P) does correctly determine that its correct and complete
>>> x86 emulation of its input would never reach the "ret" instruction
>>> (final state) of this input thus never halts.
>>>
>>> The correct and complete x86 emulation of its input by H(P,P) would
>>> never reach the "ret" instruction of P because both H and P would
>>> remain stuck in infinitely nested emulation.
>>>
>>> void P(u32 x)
>>> {
>>>   if (H(x, x))
>>>     HERE: goto HERE;
>>>   return;
>>> }
>>>
>>> int main()
>>> {
>>>   Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00001202](01)  55              push ebp
>>> [00001203](02)  8bec            mov ebp,esp
>>> [00001205](03)  8b4508          mov eax,[ebp+08]
>>> [00001208](01)  50              push eax
>>> [00001209](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000120c](01)  51              push ecx
>>> [0000120d](05)  e820feffff      call 00001032
>>> [00001212](03)  83c408          add esp,+08
>>> [00001215](02)  85c0            test eax,eax
>>> [00001217](02)  7402            jz 0000121b
>>> [00001219](02)  ebfe            jmp 00001219
>>> [0000121b](01)  5d              pop ebp
>>> [0000121c](01)  c3              ret
>>> Size in bytes:(0027) [0000121c]
>>>
>>> _main()
>>> [00001222](01)  55              push ebp
>>> [00001223](02)  8bec            mov ebp,esp
>>> [00001225](05)  6802120000      push 00001202
>>> [0000122a](05)  6802120000      push 00001202
>>> [0000122f](05)  e8fefdffff      call 00001032
>>> [00001234](03)  83c408          add esp,+08
>>> [00001237](01)  50              push eax
>>> [00001238](05)  68b3030000      push 000003b3
>>> [0000123d](05)  e8c0f1ffff      call 00000402
>>> [00001242](03)  83c408          add esp,+08
>>> [00001245](02)  33c0            xor eax,eax
>>> [00001247](01)  5d              pop ebp
>>> [00001248](01)  c3              ret
>>> Size in bytes:(0039) [00001248]
>>>
>>>  machine   stack     stack     machine    assembly
>>>  address   address   data      code       language
>>>  ========  ========  ========  =========  =============
>>> [00001222][0010200f][00000000] 55         push ebp
>>> [00001223][0010200f][00000000] 8bec       mov ebp,esp
>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
>>> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
>>> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
>>> executed H
>>>
>>> Begin Simulation   Execution Trace Stored at:2120c3
>>> Address_of_H:1032
>>> [00001202][002120af][002120b3] 55         push ebp
>>> [00001203][002120af][002120b3] 8bec       mov ebp,esp
>>> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
>>> [00001208][002120ab][00001202] 50         push eax      // push P
>>> [00001209][002120ab][00001202] 8b4d08     mov ecx,[ebp+08]
>>> [0000120c][002120a7][00001202] 51         push ecx      // push P
>>> [0000120d][002120a3][00001212] e820feffff call 00001032 // call
>>> emulated H Infinitely Recursive Simulation Detected Simulation
>>> Stopped
>>>
>>> H knows its own machine address and on this basis it can easily
>>> examine its stored execution_trace of P (see above) to determine:
>>> (a) P is calling H with the same arguments that H was called with.
>>> (b) No instructions in P could possibly escape this otherwise
>>> infinitely recursive emulation.
>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>
>>
>> When you know that H simply implements the above algorithm there is
>> no need to see its source code. I am reserving the publication of the
>> 5 pages of the source code of the halt decider for journal
>> publication.
>
> Your H is not a pure function as it behaves differently depending on
> what is invoking it (it returns a decision answer to main() but not
> to P()) and it has side effects (aborting a simulation).
>
> /Flibble
>

On Sat, 25 Jun 2022 10:19:02 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 10:09 AM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 10:03:17 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 9:28 AM, olcott wrote:
> >>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> >>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> 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. 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.
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>> I already proved that the dry run is correct.
> >>>>>>>
> >>>>>> Someone reports that tigers use more energy than they take in,
> >>>>>> and concludes that
> >>>>>> the energy conservation law is incorrect.
> >>>>>> Naturally, everyone is going to say "There must be some
> >>>>>> mistake. How were your
> >>>>>> measurements taken? Show us your calculations, maybe you've got
> >>>>>> your sums wrong."
> >>>>>>
> >>>>>> Now if they are also uncooperative about sharing the details of
> >>>>>> the investigation,
> >>>>>> those reservations will be magnified. There can be legitimate
> >>>>>> reasons. Tigers are
> >>>>>> rare and need to be conserved, you can't let anyone who wants
> >>>>>> have access to the
> >>>>>> tigers to try to repeat the measurements. But there's also a
> >>>>>> common illegitimate
> >>>>>> reason put forwards by people who make extraordinary claims. If
> >>>>>> the claims were
> >>>>>> unexceptional, such as that tigers have a similar energy budget
> >>>>>> to lions, then no-one
> >>>>>> would be saying "Show me your notebooks. How do you know that
> >>>>>> calorimeter was
> >>>>>> calibrated accurately? What's the name of the person who took
> >>>>>> that measurement
> >>>>>> and can I interview them?" Extraordinary claims are put through
> >>>>>> the wringer in a way
> >>>>>> that ordinary ones are not. I've seen complaints about this
> >>>>>> from parapsychologists.
> >>>>>> But if you're going to claim to have discovered a new physical
> >>>>>> principle, you need
> >>>>>> to present rock solid evidence.
> >>>>>>
> >>>>>> In this case, we can't see H. We can only suggest explanations
> >>>>>> for its behaviour.
> >>>>> It seems that you simply lack the technical competence.
> >>>>> Go back and look at my proof again.
> >>>>>
> >>>> Sorry no. I've been programming since I was a boy and I have a
> >>>> PhD in a computational-
> >>>> related subject. I'm confident of my technical abilities. What I
> >>>> can't do of course
> >>>> is tell you exactly what is going on in code I cannot see. I've
> >>>> got a pretty good idea,
> >>>> but I can only reconstruct on the basis of what you tell me. Ben
> >>>> thinks that I've
> >>>> got it wrong and in fact there are no nested emulations at all.
> >>>> I've no way of actually
> >>>> disproving that idea without seeing H.
> >>>>
> >>>
> >>> To fully understand this a software engineer must be an expert in:
> >>> (a) The C programming language,
> >>> (b) The x86 programming language,
> >>> (c) Exactly how C translates into x86 and,
> >>> (d) The ability to recognize infinite recursion at the x86
> >>> assembly language level.
> >>>
> >>> Anyone having the above credentials can validate my work, if you
> >>> cannot validate my work then you do not sufficiently have the
> >>> above credentials.
> >>>
> >>> Exactly how C translates into x86 is mandatory. If you don't know
> >>> how the C calling conventions are implemented in x86 you cannot
> >>> validate my work.
> >>>
> >>> From a purely software engineering perspective H(P,P) is
> >>> required to to correctly determine that its correct and complete
> >>> x86 emulation of its input would never reach the "ret"
> >>> instruction of this input and H must do this in a finite number
> >>> of steps.
> >>>
> >>> The ordinary semantics of standard C and the conventional x86
> >>> language are the entire semantics required to conclusively prove
> >>> that H(P,P) does correctly determine that its correct and complete
> >>> x86 emulation of its input would never reach the "ret" instruction
> >>> (final state) of this input thus never halts.
> >>>
> >>> The correct and complete x86 emulation of its input by H(P,P)
> >>> would never reach the "ret" instruction of P because both H and P
> >>> would remain stuck in infinitely nested emulation.
> >>>
> >>> void P(u32 x)
> >>> {
> >>>   if (H(x, x))
> >>>     HERE: goto HERE;
> >>>   return;
> >>> }
> >>>
> >>> int main()
> >>> {
> >>>   Output("Input_Halts = ", H((u32)P, (u32)P));
> >>> }
> >>>
> >>> _P()
> >>> [00001202](01)  55              push ebp
> >>> [00001203](02)  8bec            mov ebp,esp
> >>> [00001205](03)  8b4508          mov eax,[ebp+08]
> >>> [00001208](01)  50              push eax
> >>> [00001209](03)  8b4d08          mov ecx,[ebp+08]
> >>> [0000120c](01)  51              push ecx
> >>> [0000120d](05)  e820feffff      call 00001032
> >>> [00001212](03)  83c408          add esp,+08
> >>> [00001215](02)  85c0            test eax,eax
> >>> [00001217](02)  7402            jz 0000121b
> >>> [00001219](02)  ebfe            jmp 00001219
> >>> [0000121b](01)  5d              pop ebp
> >>> [0000121c](01)  c3              ret
> >>> Size in bytes:(0027) [0000121c]
> >>>
> >>> _main()
> >>> [00001222](01)  55              push ebp
> >>> [00001223](02)  8bec            mov ebp,esp
> >>> [00001225](05)  6802120000      push 00001202
> >>> [0000122a](05)  6802120000      push 00001202
> >>> [0000122f](05)  e8fefdffff      call 00001032
> >>> [00001234](03)  83c408          add esp,+08
> >>> [00001237](01)  50              push eax
> >>> [00001238](05)  68b3030000      push 000003b3
> >>> [0000123d](05)  e8c0f1ffff      call 00000402
> >>> [00001242](03)  83c408          add esp,+08
> >>> [00001245](02)  33c0            xor eax,eax
> >>> [00001247](01)  5d              pop ebp
> >>> [00001248](01)  c3              ret
> >>> Size in bytes:(0039) [00001248]
> >>>
> >>>  machine   stack     stack     machine    assembly
> >>>  address   address   data      code       language
> >>>  ========  ========  ========  =========  ============> >>> [00001222][0010200f][00000000] 55         push ebp
> >>> [00001223][0010200f][00000000] 8bec       mov ebp,esp
> >>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
> >>> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
> >>> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
> >>> executed H
> >>>
> >>> Begin Simulation   Execution Trace Stored at:2120c3
> >>> Address_of_H:1032
> >>> [00001202][002120af][002120b3] 55         push ebp
> >>> [00001203][002120af][002120b3] 8bec       mov ebp,esp
> >>> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
> >>> [00001208][002120ab][00001202] 50         push eax      // push P
> >>> [00001209][002120ab][00001202] 8b4d08     mov ecx,[ebp+08]
> >>> [0000120c][002120a7][00001202] 51         push ecx      // push P
> >>> [0000120d][002120a3][00001212] e820feffff call 00001032 // call
> >>> emulated H Infinitely Recursive Simulation Detected Simulation
> >>> Stopped
> >>>
> >>> H knows its own machine address and on this basis it can easily
> >>> examine its stored execution_trace of P (see above) to determine:
> >>> (a) P is calling H with the same arguments that H was called with.
> >>> (b) No instructions in P could possibly escape this otherwise
> >>> infinitely recursive emulation.
> >>> (c) H aborts its emulation of P before its call to H is emulated.
> >>>
> >>
> >> When you know that H simply implements the above algorithm there is
> >> no need to see its source code. I am reserving the publication of
> >> the 5 pages of the source code of the halt decider for journal
> >> publication.
> >
> > Your H is not a pure function as it behaves differently depending on
> > what is invoking it (it returns a decision answer to main() but not
> > to P()) and it has side effects (aborting a simulation).
> >
> > /Flibble
> >
>
> Finally a critique that has a reasonable basis.
>
> When I transformed H into a pure function of its inputs it always has
> the same behavior no matter how it is invoked.
>
> The x86 emulation of P is aborted before P invokes H.

Click here to read the complete article

On 6/25/2022 10:21 AM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 10:19:02 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>>> On Sat, 25 Jun 2022 10:03:17 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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. 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.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> I already proved that the dry run is correct.
>>>>>>>>>
>>>>>>>> Someone reports that tigers use more energy than they take in,
>>>>>>>> and concludes that
>>>>>>>> the energy conservation law is incorrect.
>>>>>>>> Naturally, everyone is going to say "There must be some
>>>>>>>> mistake. How were your
>>>>>>>> measurements taken? Show us your calculations, maybe you've got
>>>>>>>> your sums wrong."
>>>>>>>>
>>>>>>>> Now if they are also uncooperative about sharing the details of
>>>>>>>> the investigation,
>>>>>>>> those reservations will be magnified. There can be legitimate
>>>>>>>> reasons. Tigers are
>>>>>>>> rare and need to be conserved, you can't let anyone who wants
>>>>>>>> have access to the
>>>>>>>> tigers to try to repeat the measurements. But there's also a
>>>>>>>> common illegitimate
>>>>>>>> reason put forwards by people who make extraordinary claims. If
>>>>>>>> the claims were
>>>>>>>> unexceptional, such as that tigers have a similar energy budget
>>>>>>>> to lions, then no-one
>>>>>>>> would be saying "Show me your notebooks. How do you know that
>>>>>>>> calorimeter was
>>>>>>>> calibrated accurately? What's the name of the person who took
>>>>>>>> that measurement
>>>>>>>> and can I interview them?" Extraordinary claims are put through
>>>>>>>> the wringer in a way
>>>>>>>> that ordinary ones are not. I've seen complaints about this
>>>>>>>> from parapsychologists.
>>>>>>>> But if you're going to claim to have discovered a new physical
>>>>>>>> principle, you need
>>>>>>>> to present rock solid evidence.
>>>>>>>>
>>>>>>>> In this case, we can't see H. We can only suggest explanations
>>>>>>>> for its behaviour.
>>>>>>> It seems that you simply lack the technical competence.
>>>>>>> Go back and look at my proof again.
>>>>>>>
>>>>>> Sorry no. I've been programming since I was a boy and I have a
>>>>>> PhD in a computational-
>>>>>> related subject. I'm confident of my technical abilities. What I
>>>>>> can't do of course
>>>>>> is tell you exactly what is going on in code I cannot see. I've
>>>>>> got a pretty good idea,
>>>>>> but I can only reconstruct on the basis of what you tell me. Ben
>>>>>> thinks that I've
>>>>>> got it wrong and in fact there are no nested emulations at all.
>>>>>> I've no way of actually
>>>>>> disproving that idea without seeing H.
>>>>>>
>>>>>
>>>>> To fully understand this a software engineer must be an expert in:
>>>>> (a) The C programming language,
>>>>> (b) The x86 programming language,
>>>>> (c) Exactly how C translates into x86 and,
>>>>> (d) The ability to recognize infinite recursion at the x86
>>>>> assembly language level.
>>>>>
>>>>> Anyone having the above credentials can validate my work, if you
>>>>> cannot validate my work then you do not sufficiently have the
>>>>> above credentials.
>>>>>
>>>>> Exactly how C translates into x86 is mandatory. If you don't know
>>>>> how the C calling conventions are implemented in x86 you cannot
>>>>> validate my work.
>>>>>
>>>>> From a purely software engineering perspective H(P,P) is
>>>>> required to to correctly determine that its correct and complete
>>>>> x86 emulation of its input would never reach the "ret"
>>>>> instruction of this input and H must do this in a finite number
>>>>> of steps.
>>>>>
>>>>> The ordinary semantics of standard C and the conventional x86
>>>>> language are the entire semantics required to conclusively prove
>>>>> that H(P,P) does correctly determine that its correct and complete
>>>>> x86 emulation of its input would never reach the "ret" instruction
>>>>> (final state) of this input thus never halts.
>>>>>
>>>>> The correct and complete x86 emulation of its input by H(P,P)
>>>>> would never reach the "ret" instruction of P because both H and P
>>>>> would remain stuck in infinitely nested emulation.
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>   if (H(x, x))
>>>>>     HERE: goto HERE;
>>>>>   return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>   Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001202](01)  55              push ebp
>>>>> [00001203](02)  8bec            mov ebp,esp
>>>>> [00001205](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001208](01)  50              push eax
>>>>> [00001209](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [0000120c](01)  51              push ecx
>>>>> [0000120d](05)  e820feffff      call 00001032
>>>>> [00001212](03)  83c408          add esp,+08
>>>>> [00001215](02)  85c0            test eax,eax
>>>>> [00001217](02)  7402            jz 0000121b
>>>>> [00001219](02)  ebfe            jmp 00001219
>>>>> [0000121b](01)  5d              pop ebp
>>>>> [0000121c](01)  c3              ret
>>>>> Size in bytes:(0027) [0000121c]
>>>>>
>>>>> _main()
>>>>> [00001222](01)  55              push ebp
>>>>> [00001223](02)  8bec            mov ebp,esp
>>>>> [00001225](05)  6802120000      push 00001202
>>>>> [0000122a](05)  6802120000      push 00001202
>>>>> [0000122f](05)  e8fefdffff      call 00001032
>>>>> [00001234](03)  83c408          add esp,+08
>>>>> [00001237](01)  50              push eax
>>>>> [00001238](05)  68b3030000      push 000003b3
>>>>> [0000123d](05)  e8c0f1ffff      call 00000402
>>>>> [00001242](03)  83c408          add esp,+08
>>>>> [00001245](02)  33c0            xor eax,eax
>>>>> [00001247](01)  5d              pop ebp
>>>>> [00001248](01)  c3              ret
>>>>> Size in bytes:(0039) [00001248]
>>>>>
>>>>>  machine   stack     stack     machine    assembly
>>>>>  address   address   data      code       language
>>>>>  ========  ========  ========  =========  =============
>>>>> [00001222][0010200f][00000000] 55         push ebp
>>>>> [00001223][0010200f][00000000] 8bec       mov ebp,esp
>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
>>>>> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
>>>>> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
>>>>> executed H
>>>>>
>>>>> Begin Simulation   Execution Trace Stored at:2120c3
>>>>> Address_of_H:1032
>>>>> [00001202][002120af][002120b3] 55         push ebp
>>>>> [00001203][002120af][002120b3] 8bec       mov ebp,esp
>>>>> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
>>>>> [00001208][002120ab][00001202] 50         push eax      // push P
>>>>> [00001209][002120ab][00001202] 8b4d08     mov ecx,[ebp+08]
>>>>> [0000120c][002120a7][00001202] 51         push ecx      // push P
>>>>> [0000120d][002120a3][00001212] e820feffff call 00001032 // call
>>>>> emulated H Infinitely Recursive Simulation Detected Simulation
>>>>> Stopped
>>>>>
>>>>> H knows its own machine address and on this basis it can easily
>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>> infinitely recursive emulation.
>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>
>>>>
>>>> When you know that H simply implements the above algorithm there is
>>>> no need to see its source code. I am reserving the publication of
>>>> the 5 pages of the source code of the halt decider for journal
>>>> publication.
>>>
>>> Your H is not a pure function as it behaves differently depending on
>>> what is invoking it (it returns a decision answer to main() but not
>>> to P()) and it has side effects (aborting a simulation).
>>>
>>> /Flibble
>>>
>>
>> Finally a critique that has a reasonable basis.
>>
>> When I transformed H into a pure function of its inputs it always has
>> the same behavior no matter how it is invoked.
>>
>> The x86 emulation of P is aborted before P invokes H.
>
> Nope. Preventing a call to H is equivalent to H behaving differently
> for same inputs. Aborting a simulation is a side effect: pure functions
> do not have side effects.
>
> /Flibble
>

On Sat, 25 Jun 2022 10:54:13 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 10:21 AM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 10:19:02 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 10:09 AM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 10:03:17 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 9:28 AM, olcott wrote:
> >>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> >>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> 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. 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.
> >>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> I already proved that the dry run is correct.
> >>>>>>>>>
> >>>>>>>> Someone reports that tigers use more energy than they take
> >>>>>>>> in, and concludes that
> >>>>>>>> the energy conservation law is incorrect.
> >>>>>>>> Naturally, everyone is going to say "There must be some
> >>>>>>>> mistake. How were your
> >>>>>>>> measurements taken? Show us your calculations, maybe you've
> >>>>>>>> got your sums wrong."
> >>>>>>>>
> >>>>>>>> Now if they are also uncooperative about sharing the details
> >>>>>>>> of the investigation,
> >>>>>>>> those reservations will be magnified. There can be legitimate
> >>>>>>>> reasons. Tigers are
> >>>>>>>> rare and need to be conserved, you can't let anyone who wants
> >>>>>>>> have access to the
> >>>>>>>> tigers to try to repeat the measurements. But there's also a
> >>>>>>>> common illegitimate
> >>>>>>>> reason put forwards by people who make extraordinary claims.
> >>>>>>>> If the claims were
> >>>>>>>> unexceptional, such as that tigers have a similar energy
> >>>>>>>> budget to lions, then no-one
> >>>>>>>> would be saying "Show me your notebooks. How do you know that
> >>>>>>>> calorimeter was
> >>>>>>>> calibrated accurately? What's the name of the person who took
> >>>>>>>> that measurement
> >>>>>>>> and can I interview them?" Extraordinary claims are put
> >>>>>>>> through the wringer in a way
> >>>>>>>> that ordinary ones are not. I've seen complaints about this
> >>>>>>>> from parapsychologists.
> >>>>>>>> But if you're going to claim to have discovered a new
> >>>>>>>> physical principle, you need
> >>>>>>>> to present rock solid evidence.
> >>>>>>>>
> >>>>>>>> In this case, we can't see H. We can only suggest
> >>>>>>>> explanations for its behaviour.
> >>>>>>> It seems that you simply lack the technical competence.
> >>>>>>> Go back and look at my proof again.
> >>>>>>>
> >>>>>> Sorry no. I've been programming since I was a boy and I have a
> >>>>>> PhD in a computational-
> >>>>>> related subject. I'm confident of my technical abilities. What
> >>>>>> I can't do of course
> >>>>>> is tell you exactly what is going on in code I cannot see. I've
> >>>>>> got a pretty good idea,
> >>>>>> but I can only reconstruct on the basis of what you tell me.
> >>>>>> Ben thinks that I've
> >>>>>> got it wrong and in fact there are no nested emulations at all.
> >>>>>> I've no way of actually
> >>>>>> disproving that idea without seeing H.
> >>>>>>
> >>>>>
> >>>>> To fully understand this a software engineer must be an expert
> >>>>> in: (a) The C programming language,
> >>>>> (b) The x86 programming language,
> >>>>> (c) Exactly how C translates into x86 and,
> >>>>> (d) The ability to recognize infinite recursion at the x86
> >>>>> assembly language level.
> >>>>>
> >>>>> Anyone having the above credentials can validate my work, if you
> >>>>> cannot validate my work then you do not sufficiently have the
> >>>>> above credentials.
> >>>>>
> >>>>> Exactly how C translates into x86 is mandatory. If you don't
> >>>>> know how the C calling conventions are implemented in x86 you
> >>>>> cannot validate my work.
> >>>>>
> >>>>> From a purely software engineering perspective H(P,P) is
> >>>>> required to to correctly determine that its correct and complete
> >>>>> x86 emulation of its input would never reach the "ret"
> >>>>> instruction of this input and H must do this in a finite number
> >>>>> of steps.
> >>>>>
> >>>>> The ordinary semantics of standard C and the conventional x86
> >>>>> language are the entire semantics required to conclusively prove
> >>>>> that H(P,P) does correctly determine that its correct and
> >>>>> complete x86 emulation of its input would never reach the "ret"
> >>>>> instruction (final state) of this input thus never halts.
> >>>>>
> >>>>> The correct and complete x86 emulation of its input by H(P,P)
> >>>>> would never reach the "ret" instruction of P because both H and
> >>>>> P would remain stuck in infinitely nested emulation.
> >>>>>
> >>>>> void P(u32 x)
> >>>>> {
> >>>>>   if (H(x, x))
> >>>>>     HERE: goto HERE;
> >>>>>   return;
> >>>>> }
> >>>>>
> >>>>> int main()
> >>>>> {
> >>>>>   Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>> }
> >>>>>
> >>>>> _P()
> >>>>> [00001202](01)  55              push ebp
> >>>>> [00001203](02)  8bec            mov ebp,esp
> >>>>> [00001205](03)  8b4508          mov eax,[ebp+08]
> >>>>> [00001208](01)  50              push eax
> >>>>> [00001209](03)  8b4d08          mov ecx,[ebp+08]
> >>>>> [0000120c](01)  51              push ecx
> >>>>> [0000120d](05)  e820feffff      call 00001032
> >>>>> [00001212](03)  83c408          add esp,+08
> >>>>> [00001215](02)  85c0            test eax,eax
> >>>>> [00001217](02)  7402            jz 0000121b
> >>>>> [00001219](02)  ebfe            jmp 00001219
> >>>>> [0000121b](01)  5d              pop ebp
> >>>>> [0000121c](01)  c3              ret
> >>>>> Size in bytes:(0027) [0000121c]
> >>>>>
> >>>>> _main()
> >>>>> [00001222](01)  55              push ebp
> >>>>> [00001223](02)  8bec            mov ebp,esp
> >>>>> [00001225](05)  6802120000      push 00001202
> >>>>> [0000122a](05)  6802120000      push 00001202
> >>>>> [0000122f](05)  e8fefdffff      call 00001032
> >>>>> [00001234](03)  83c408          add esp,+08
> >>>>> [00001237](01)  50              push eax
> >>>>> [00001238](05)  68b3030000      push 000003b3
> >>>>> [0000123d](05)  e8c0f1ffff      call 00000402
> >>>>> [00001242](03)  83c408          add esp,+08
> >>>>> [00001245](02)  33c0            xor eax,eax
> >>>>> [00001247](01)  5d              pop ebp
> >>>>> [00001248](01)  c3              ret
> >>>>> Size in bytes:(0039) [00001248]
> >>>>>
> >>>>>  machine   stack     stack     machine    assembly
> >>>>>  address   address   data      code       language
> >>>>>  ========  ========  ========  =========  ============> >>>>> [00001222][0010200f][00000000] 55         push ebp
> >>>>> [00001223][0010200f][00000000] 8bec       mov ebp,esp
> >>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push
> >>>>> P [0000122a][00102007][00001202] 6802120000 push 00001202 //
> >>>>> push P [0000122f][00102003][00001234] e8fefdffff call 00001032
> >>>>> // call executed H
> >>>>>
> >>>>> Begin Simulation   Execution Trace Stored at:2120c3
> >>>>> Address_of_H:1032
> >>>>> [00001202][002120af][002120b3] 55         push ebp
> >>>>> [00001203][002120af][002120b3] 8bec       mov ebp,esp
> >>>>> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
> >>>>> [00001208][002120ab][00001202] 50         push eax      // push
> >>>>> P [00001209][002120ab][00001202] 8b4d08     mov ecx,[ebp+08]
> >>>>> [0000120c][002120a7][00001202] 51         push ecx      // push
> >>>>> P [0000120d][002120a3][00001212] e820feffff call 00001032 //
> >>>>> call emulated H Infinitely Recursive Simulation Detected
> >>>>> Simulation Stopped
> >>>>>
> >>>>> H knows its own machine address and on this basis it can easily
> >>>>> examine its stored execution_trace of P (see above) to
> >>>>> determine: (a) P is calling H with the same arguments that H
> >>>>> was called with. (b) No instructions in P could possibly escape
> >>>>> this otherwise infinitely recursive emulation.
> >>>>> (c) H aborts its emulation of P before its call to H is
> >>>>> emulated.
> >>>>
> >>>> When you know that H simply implements the above algorithm there
> >>>> is no need to see its source code. I am reserving the
> >>>> publication of the 5 pages of the source code of the halt
> >>>> decider for journal publication.
> >>>
> >>> Your H is not a pure function as it behaves differently depending
> >>> on what is invoking it (it returns a decision answer to main()
> >>> but not to P()) and it has side effects (aborting a simulation).
> >>>
> >>> /Flibble
> >>>
> >>
> >> Finally a critique that has a reasonable basis.
> >>
> >> When I transformed H into a pure function of its inputs it always
> >> has the same behavior no matter how it is invoked.
> >>
> >> The x86 emulation of P is aborted before P invokes H.
> >
> > Nope. Preventing a call to H is equivalent to H behaving differently
> > for same inputs. Aborting a simulation is a side effect: pure
> > functions do not have side effects.
> >
> > /Flibble
> >
>
> In other words you are saying that a halt decider is simply not
> allowed to report when it correctly detects that it is being called
> in infinitely recursive simulation.