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