On 6/24/22 12:52 PM, olcott wrote:
> On 6/24/2022 11:32 AM, olcott wrote:
>> On 6/24/2022 11:09 AM, Malcolm McLean wrote:
>>> On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
>>>> On 6/24/2022 8:34 AM, Malcolm McLean wrote:
>>>>> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>>>>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>>>>> 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.
>>>>>>
>>>>>> I already fully addressed that in my reply to you yesterday. P(P)
>>>>>> has a
>>>>>> dependency relationship on the return value of H(P,P) that the
>>>>>> correctly
>>>>>> emulated input to H(P,P) does not have. This changes their behavior
>>>>>> relative to each other.
>>>>>>
>>>>> I can see an alternative explanation. I was going to say "it is
>>>>> obvious" but
>>>>> no-one else has stepped in to point it out. Maybe because it's too
>>>>> obvious
>>>>> and they want to give other posters a chance.
>>>> To what exact extent do you have this mandatory prerequisite knowledge?
>>>> To fully understand this code 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.
>>>> 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 of P.
>>>> The halt decider and its input are written in C compiled with a
>>>> Microsoft C compiler that generates a standard COFF object file. This
>>>> file is the input to the x86utm operating system that runs on both
>>>> Microsoft Windows and Linux.
>>>>
>>> I'm a C programmer and I have done machine code programming, though not
>>> with the x86 chip. But I'd dispute your requirements.
>>
>>
>> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
>> DISAGREEMENT IS INHERENTLY INCORRECT.
>>
>>  From a purely software engineering perspective H is correctly defined
>> to correctly determine that its correct and complete x86 emulation of
>> its input would never reach the "ret" instruction of this input and it
>> is proven that H does do this correctly in a finite number of steps.
>>
>
> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
> DISAGREEMENT IS INHERENTLY INCORRECT.

STIPULTING that something is correct is inherently incorrect.

>
> 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.
>
> It is proven that H does meet this requirement.

No, because you said *ITS* correct and complete x86 emulation was
showing something when it didn't do one. Thus, H has FAILED to meet its
requirements.

Until you can show how H can do a COMPLETE emulation of a non-halting
input in finite time (not just 'prove' that it doesn't halt, that wasn't
the requrement, it was DO the emulation) your H just fails to meet you
software specifications for it.

Note, a Halt Decider isn't normally required to do a complete emulation
of its input, but that is because it isn't also the test of its answer
being correct, that is done by the INDEPENDENT running or complete
emulation of the input, which allow the decider to correct answer at
least some non-halting inputs. (Because it can find patterns that are
proven to be non-halting for the test machine).

Your removal of the allowance of a separate test operation, that CAN be
infinite in operation while the decider stays finite in operation dooms
your decider to either not meet its requriment to show non-halting, or
not meet its requirement to answer in finite time.

Note, your H fails to meet YOUR requirements when deciding on
Infinite_Loop, even though it can give the correct answer by the normal
requirements, because it never showed by its own complete and correct
emulation that the input doesn't halt (only by referencing another
emulation that does, which isn't YOUR stated requirement).
>
>
>>> To re-tread the analogy,
>>> our measurements show that tigers use more energy than they take in.
>>> Now you could construct an very complicated explanation for that using
>>> advanced quantum mechanics and other concepts. And you do need to have
>>> a rudimentary understanding of physics to see where the difficulty lies.
>>
>>> But you don't need more than the rudimentary understanding to suggest
>>> the
>>> alternative explanation, and to realise that it is overwhelmingly
>>> more likely.
>>
>> It seems that you may be saying that it is OK to disbelieve verified
>> facts some of the time. I vehemently disagree and this position could
>> cause both the end of Democracy in the USA and the extinction of
>> humanity in the world through lack of climate change action.
>>
>> Ordinary software engineering conclusively proves that all of my
>> claims that I just stated are easily verified as factually correct.
>>
>> Anyone that disagrees with claims that are verified as factually
>> correct is either insufficiently technically competent or less than
>> totally honest. Someone that refuses to acknowledge that claims are
>> correct when they know that these claims are correct is less than
>> totally honest.
>>
>> I believe that you are as honest as you can be and the issue is that
>> you have a lack of sufficient understanding.
>>
>
>