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.

Many journals will refuse to publish material that is already "out
there". I will publish the current 41 pages of source-code for the
x86utm operating system as open source.

It took many months to figure out how to avoid the need of static local
data to transform H into a pure function of its inputs. The algorithm
shown above has this transformation.

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

--
Copyright 2022 Pete Olcott

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