On 6/24/22 4:35 PM, olcott wrote:
> On 6/24/2022 3:25 PM, Malcolm McLean wrote:
>> 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.
>> 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, PO has dry run P(P). That is, he has looked at the
>> source, and
>> worked out what it will do. Which is to run an infinite sequence of
>> nested
>> emulations. So it won't halt. H(P,P) also reports "non-halting". So
>> this is
>> powerful evidence  that H is correct.
>
> Great!
>

Except, of course, that the "Dry-run" didn't evalute H as what H
actually ends up being, but by what H was specifed to be, that is a
comptation that completely em

>> However when he actually executes P(P) on hardware, it terminates.
>> Something isn't right.
>
> None-the-less when everyone in the entire universe disagrees with a
> verified fact then they are all necessarily incorrect.
>
> 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.
>
>> PO's explanation is that P(P) has different correct behaviour when run
>> and
>> when emulated by H.
>
> It is very easily proven as an established fact that the correctly
> emulated input to H(P,P) would never halt and P(P) halts.

Only if you accept that P isn't requred to be the H^ of Linz.

Remember, THAT machine, by definition, makes a call that asks H to
evalute what it will do when applie to its input.

If H(P,P) doesn't mean that, then P isn't the impossible program example
of Linz but something else, so we haven't countered his example.

>
>> 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.
>
> I think that most of my reviewers are only interested in rebuttal at the
> expense of an actual honest dialogue. You are certainly the exception to
> this.
>