On 6/25/2022 11:25 AM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 11:06:12 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 10:59 AM, Mr Flibble wrote:
>>> 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.
>>>
>>> I keep telling you this: the infinite recursion is NOT present when
>>> using a valid halt decider: your H is NOT a valid halt
>>> decider.
>>>
>>> Simulation is an erroneous approach as a simulating halt decider
>>> can not answer in finite time for a non-halting input as there is no
>>> proven general solution for detecting non-halting behaviour.
>>>
>>> /Flibble
>>>
>>
>> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
>> YOU DENY THIS VERIFIABLE FACT:
>>
>> 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.
>
> For [Strachey 1965] (and the proofs based on it) H is NOT a simulating
> halt decider so there is no infinite recursion as there is no emulation.
>
> Valid halt deciders ANALYSE P, they do not EMULATE P.
>
> /Flibble
>

I provide a halt decider H that gets the right answer and your rebuttal
is that H does not get the right answer because there is another
different halt decider named H1 that gets the wrong answer.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer