On 6/29/2022 2:54 PM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc> writes:
>
>> If we put to one side the fact that a simulation-based halting decider
>> is invalid* it is a FACT that such a decider, to be considered valid,
>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>> that without invoking "infinite recursion" (or aborting same) then it
>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>> decision on P(P).
>
> There's a reason the theorem is not stated about functions in some
> programming language. Such a description would be just too prone to
> misinterpretation or trickery.
>
> If you have to use C then the halting problem is best expressed in terms
> of programs. A halting decider would be a C program that returns
> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
> whether the C program whose source is given in argv[1] halts or not when
> run with argv[2] as its sole command line argument.
>
> It seemed like the polite thing to do to move away from Turing machines
> (which PO does not understand) to C. But the specification in terms of
> C functions has allowed PO to indulge his penchant for obfuscation to the
> point where no one is really sure exactly what mistake he's made.
>
> He did originally understand that H(X,Y) should report on the "halting"
> of X(Y), but he's long since abandoned that obvious model.
>

C is a little ambiguous across implementation environments, yet C
translated into x86 has precisely specified semantics.

When C is translated into the x86 language we get a complete directed
graph of all control flow.

That people say that I am incorrect on the basis of their lack of
understanding of the semantics of the x86 language is dishonest.

--
Copyright 2022 Pete Olcott

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

On 6/29/22 4:46 PM, olcott wrote:
> On 6/29/2022 2:54 PM, Ben Bacarisse wrote:
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>>> If we put to one side the fact that a simulation-based halting decider
>>> is invalid* it is a FACT that such a decider, to be considered valid,
>>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>>> that without invoking "infinite recursion" (or aborting same) then it
>>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>>> decision on P(P).
>>
>> There's a reason the theorem is not stated about functions in some
>> programming language.  Such a description would be just too prone to
>> misinterpretation or trickery.
>>
>> If you have to use C then the halting problem is best expressed in terms
>> of programs.  A halting decider would be a C program that returns
>> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
>> whether the C program whose source is given in argv[1] halts or not when
>> run with argv[2] as its sole command line argument.
>>
>> It seemed like the polite thing to do to move away from Turing machines
>> (which PO does not understand) to C.  But the specification in terms of
>> C functions has allowed PO to indulge his penchant for obfuscation to the
>> point where no one is really sure exactly what mistake he's made.
>>
>> He did originally understand that H(X,Y) should report on the "halting"
>> of X(Y), but he's long since abandoned that obvious model.
>>
>
> C is a little ambiguous across implementation environments, yet C
> translated into x86 has precisely specified semantics.
>
> When C is translated into the x86 language we get a complete directed
> graph of all control flow.
>
> That people say that I am incorrect on the basis of their lack of
> understanding of the semantics of the x86 language is dishonest.
>
>
>

And you break that control flow by not actually emulating the results of
the call H instruction, but break out of x86 emulation into pseudo code
analysis.

Since H(P,P) is known to return 0, then the call H(P,P) done by P needs
to do the same, or you need to show how the actual x86 emulation of the
code that this calls does what you claim, when it is the identical code
that returned 0 elsewhere.

On 6/30/2022 1:17 PM, dklei...@gmail.com wrote:
> On Wednesday, June 29, 2022 at 4:36:13 PM UTC-7, olcott wrote:
>> On 6/29/2022 6:10 PM, dklei...@gmail.com wrote:
>>> On Wednesday, June 29, 2022 at 1:46:15 PM UTC-7, olcott wrote:
>>>
>>>> C is a little ambiguous across implementation environments, yet C
>>>> translated into x86 has precisely specified semantics.
>>>>
>>> "C translated into x86" is called compilation (assuming x86 means
>>> x86 assembly language).
>>>>
>>>> When C is translated into the x86 language we get a complete directed
>>>> graph of all control flow.
>>>>
>>> Control is usually easier to understand in C than assembler.
>>>>
>>>> That people say that I am incorrect on the basis of their lack of
>>>> understanding of the semantics of the x86 language is dishonest.
>>>>
>>> Just go read comp.lang.c or one of the others. The semantics laid
>>> down in the standards are quite complex and hardly anyone actually
>>> understands them. There is no evidence you do.
>> All of the the conrol flow semantics of the x86 language comes as a
>> ready-made directed graph with integer subscripts.
>>
>> This is much easier for machine processing.
>
> And these alleged control flow structures are ...... ?

[0000117d](05) e8f0fdffff call 00000f72
[00001187](02) 7402 jz 0000118b
[00001189](02) ebfe jmp 00001189
[0000118c](01) c3 ret

--
Copyright 2022 Pete Olcott

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

On 6/30/22 2:22 PM, olcott wrote:
> On 6/30/2022 1:17 PM, dklei...@gmail.com wrote:
>> On Wednesday, June 29, 2022 at 4:36:13 PM UTC-7, olcott wrote:
>>> On 6/29/2022 6:10 PM, dklei...@gmail.com wrote:
>>>> On Wednesday, June 29, 2022 at 1:46:15 PM UTC-7, olcott wrote:
>>>>
>>>>> C is a little ambiguous across implementation environments, yet C
>>>>> translated into x86 has precisely specified semantics.
>>>>>
>>>> "C translated into x86" is called compilation (assuming x86 means
>>>> x86 assembly language).
>>>>>
>>>>> When C is translated into the x86 language we get a complete directed
>>>>> graph of all control flow.
>>>>>
>>>> Control is usually easier to understand in C than assembler.
>>>>>
>>>>> That people say that I am incorrect on the basis of their lack of
>>>>> understanding of the semantics of the x86 language is dishonest.
>>>>>
>>>> Just go read comp.lang.c or one of the others. The semantics laid
>>>> down in the standards are quite complex and hardly anyone actually
>>>> understands them. There is no evidence you do.
>>> All of the the conrol flow semantics of the x86 language comes as a
>>> ready-made directed graph with integer subscripts.
>>>
>>> This is much easier for machine processing.
>>
>> And these alleged control flow structures are ...... ?
>
>
> [0000117d](05)  e8f0fdffff call 00000f72
> [00001187](02)  7402       jz 0000118b
> [00001189](02)  ebfe       jmp 00001189
> [0000118c](01)  c3         ret
>
>

And where is that in the trace of P(P)?

Sounds like you are just serving your Herring Red.