On 6/22/22 1:58 PM, olcott wrote:
>
> My words are perfectly clear and correct thus leaving the only possible
> rebuttal of changing the words and forming a rebuttal on the basis of
> these changed words.

No, they aren't because they don't match the definitons of the problem
you claim to be working on.

Start with wrong definitions, and NOTHING that follows is valid. or correct.

H applied to M, x needs to accept this input if M applied to x reaches a
final state in a finite number of steps and reject this input if M
applied to x will NEVER, after an unbounded number of steps, reach a
final state.

Since when P applied to P uses H applied to P, P and then does the
opposite gets the reject answer from H it Halts, then H applied to P,P
rejecting this input can't be correct.

PERIOD.

DEFINITION.

The fact that you try to twist the requirements and definitions to try
to show something else, just proves that you are either dishonest or
ignorant.

You will NEVER be right, because your ideas are just WRONG.

On 6/22/2022 6:01 PM, Mr Flibble wrote:
> On Wed, 22 Jun 2022 16:58:24 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/22/2022 4:49 PM, Mr Flibble wrote:
>>> On Wed, 22 Jun 2022 16:41:43 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> #include <stdint.h>
>>>>>>>> #define u32 uint32_t
>>>>>>>>
>>>>>>>> #include <stdint.h>
>>>>>>>> typedef void (*ptr)();
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>> [000010ec](01) c3 ret
>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>
>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>> verify that the complete and correct x86 emulation of the
>>>>>>>> input to H(P,P) by H would never reach the "ret" instruction
>>>>>>>> of P because both H and P would remain stuck in infinitely
>>>>>>>> recursive emulation.
>>>>>>>>
>>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>>> number of steps then H could reject its input on this basis.
>>>>>>>> Here are the details of exactly how H does this in a finite
>>>>>>>> number of steps.
>>>>>>>>
>>>>>>>> typedef struct Decoded
>>>>>>>> {
>>>>>>>> u32 Address;
>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>> u32 NumBytes;
>>>>>>>> u32 Simplified_Opcode;
>>>>>>>> u32 Decode_Target;
>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>
>>>>>>>> machine stack stack machine assembly
>>>>>>>> address address data code language
>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax //
>>>>>>>> push P [000010d9][00211e86][000010d2] 8b4d08 mov
>>>>>>>> ecx,[ebp+08] [000010dc][00211e82][000010d2] 51 push
>>>>>>>> ecx // push P [000010dd][00211e7e][000010e2] e820feffff
>>>>>>>> call 00000f02 // call H Infinitely Recursive Simulation
>>>>>>>> Detected Simulation Stopped
>>>>>>>>
>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>> {
>>>>>>>> HERE:
>>>>>>>> u32 End_Of_Code;
>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>> u32* slave_stack = Allocate(0x10000); //
>>>>>>>> 64k; u32 execution_trace =
>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>> * 1000);
>>>>>>>>
>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>
>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state,
>>>>>>>> slave_stack); Output("\nBegin Simulation Execution Trace
>>>>>>>> Stored at:", execution_trace);
>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>> goto END_OF_CODE;
>>>>>>>> return 0; // Does not halt
>>>>>>>> END_OF_CODE:
>>>>>>>> return 1; // Input has normally terminated
>>>>>>>> }
>>>>>>>>
>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>> examine its stored execution_trace of P and 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
>>>>>>>> invoked.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Technically competent software engineers may not know this
>>>>>>>> computer science:
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> computation that halts … the Turing machine will halt whenever
>>>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>>>
>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>
>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>
>>>>>>>
>>>>>>> void Px(u32 x)
>>>>>>> {
>>>>>>> H(x, x);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>> }
>>>>>>>
>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>> Input_Halts = 0
>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>> Number of Instructions Executed(16120)
>>>>>>>
>>>>>>> It gets the answer wrong, i.e. input has not been decided
>>>>>>> correctly. QED.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> You and Richard are insufficiently technically competent at
>>>>>> software engineering not meeting these specs:
>>>>>>
>>>>>> 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. No knowledge of the halting problem
>>>>>> is required.
>>>>>
>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I
>>>>> also have C and x86 assembly experience (I once wrote a Zilog Z80A
>>>>> CPU emulator in 80286 assembly) and I can recognize an infinite
>>>>> recursion; the problem is that you cannot recognize the fact that
>>>>> the infinite recursion only manifests as part of your invalid
>>>>> simulation-based omnishambles:
>>>>
>>>> If you are competent then you already know this is true and lie
>>>> about it:
>>>>
>>>> Every sufficiently competent software engineer can easily verify
>>>> that the complete and correct x86 emulation of the input to
>>>> H(Px,Px) by H would never reach the "ret" instruction of P because
>>>> both H and P would remain stuck in infinitely recursive emulation.
>>>>
>>>> Otherwise you are incompetent.
>>>>
>>>>> the recursion simply isn't there for a "valid" halt
>>>>> decider, that being a halt decider that can return an answer in
>>>>> finite time to ALL invokers: H needs to return an answer to Px to
>>>>> be considered a valid halt decider.
>>>>>
>>>>> /Flibble
>>>
>>> Why did you ignore the second part? Again:
>>>
>>> The problem is that you cannot recognize the fact that the infinite
>>> recursion only manifests as part of your invalid simulation-based
>>
>> It is easily provably correct. That you lack the technical competence
>> to verify that the x86 emulated behavior of the x86 emulation of the
>> input to H(P,P) by H precisely matches the behavior specified by P is
>> far less than no rebuttal at all.
>
> Your H doesn't return a value to its invoker, Px in this case, so isn't
> a valid halt decider.

On 6/22/2022 6:05 PM, Richard Damon wrote:
> On 6/22/22 10:55 AM, olcott wrote:
>> On 6/22/2022 7:53 AM, olcott wrote:
>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>> 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. In these circumstances, the sensible
>>>> scientist (or I suppose mathematician, though I'm a scientist and not a
>>>> mathematician) looks for alternative explanations which aren't quite as
>>>> consequential.
>>>
>>> That is like looking for alternatives to 5 > 3
>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>
>>>>>> That would have far-reaching consequences. Before going there, maybe
>>>>>> think up some simpler, alternative explanations and eliminate them.
>>>>> There are no alternatives to immutable verified facts. H(P,P) halts
>>>>> only
>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>
>>>>> Technically competent software engineers would agree. On the basis of
>>>>> the much more complete details that I provided in my original post.
>>>>>
>>>>> When P(P) is called from main its behavior depends on the return value
>>>>> of H. When H is called from main P(P) cannot possibly depend on the
>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>
>>>> That would be one consequence of going with your explanation. We'd
>>>> have to
>>>> say the behaviour of P(P) differs depending on caller. As I said,
>>>> try simpler,
>>>> less far-reaching explanations first.
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>>   H(P,P)==0 is provably correct
>>> H1(P,P)==1 is provably correct.
>>> H1(P,P) reports on the behavior of P(P).
>>>
>>
>> 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. The actual behavior of the actual input to
>> H(P,P) is non halting thus rejecting its input is necessarily correct.
>>
>>
>
> You have this wrong.
>
> A decider must compute the mapping that represents the FUNCTION it is
> deciding, there is actually nothing about "behavior" in the definition.
>
> For a HALTING decider, that mapping is based on the HALTING Behavior of
> the machine the input REPRESENTS.

If you construe this as the actual behavior that the actual input
specifies then this is correct otherwise this is incorrect.

People that actually understand these things deeply on the basis of all
of the deep connected meanings will agree. People that understand these
things only by the rote memorization of what textbooks say may get
confused.

This is computer science that I wrote that is verifiably correct and
clarifies the misconceptions of what a halt decider must do:

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. Copyright Olcott 2021

--
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/22/2022 6:11 PM, Richard Damon wrote:
> On 6/22/22 1:58 PM, olcott wrote:
>>
>> My words are perfectly clear and correct thus leaving the only
>> possible rebuttal of changing the words and forming a rebuttal on the
>> basis of these changed words.
>
> No, they aren't because they don't match the definitons of the problem
> you claim to be working on.

That is an entirely separate issue that cannot possibly be correctly
addressed until after my words are totally agreed to in the precise
context that they are specified.

--
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/22/22 7:39 PM, olcott wrote:
> On 6/22/2022 6:05 PM, Richard Damon wrote:
>> On 6/22/22 10:55 AM, olcott wrote:
>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>> 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. In these circumstances, the sensible
>>>>> scientist (or I suppose mathematician, though I'm a scientist and
>>>>> not a
>>>>> mathematician) looks for alternative explanations which aren't
>>>>> quite as
>>>>> consequential.
>>>>
>>>> That is like looking for alternatives to 5 > 3
>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>
>>>>>>> That would have far-reaching consequences. Before going there, maybe
>>>>>>> think up some simpler, alternative explanations and eliminate them.
>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>> halts only
>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>
>>>>>> Technically competent software engineers would agree. On the basis of
>>>>>> the much more complete details that I provided in my original post.
>>>>>>
>>>>>> When P(P) is called from main its behavior depends on the return
>>>>>> value
>>>>>> of H. When H is called from main P(P) cannot possibly depend on the
>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>>
>>>>> That would be one consequence of going with your explanation. We'd
>>>>> have to
>>>>> say the behaviour of P(P) differs depending on caller. As I said,
>>>>> try simpler,
>>>>> less far-reaching explanations first.
>>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>>   H(P,P)==0 is provably correct
>>>> H1(P,P)==1 is provably correct.
>>>> H1(P,P) reports on the behavior of P(P).
>>>>
>>>
>>> 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. The actual behavior of the actual input to
>>> H(P,P) is non halting thus rejecting its input is necessarily correct.
>>>
>>>
>>
>> You have this wrong.
>>
>> A decider must compute the mapping that represents the FUNCTION it is
>> deciding, there is actually nothing about "behavior" in the definition.
>>
>> For a HALTING decider, that mapping is based on the HALTING Behavior
>> of the machine the input REPRESENTS.
>
> If you construe this as the actual behavior that the actual input
> specifies then this is correct otherwise this is incorrect.

If it isn't the acutual behavior, then it just isn't a Halt Decider, but
maybe your POOP decider.

DEFINITIONS, you know.

>
> People that actually understand these things deeply on the basis of all
> of the deep connected meanings will agree. People that understand these
> things only by the rote memorization of what textbooks say may get
> confused.
>
> This is computer science that I wrote that is verifiably correct and
> clarifies the misconceptions of what a halt decider must do:
>
> 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. Copyright Olcott 2021
>

Which isn't correct unless that actual behavior matches that defined by
the definition of an ACTUAL Halt Decider, which is the behavior of the
machine the input represents.

You don't get to change definitions.

Note, you also don't get to copyright definitions, just your artistic
representation of them.

I guess due to your degree of artistic license you take with
definitions, you might be able to claim copyright on your versions.

After all, they are a work of fiction. (maybe just semi-fiction).

On 6/22/22 8:00 PM, olcott wrote:
> On 6/22/2022 6:11 PM, Richard Damon wrote:
>> On 6/22/22 1:58 PM, olcott wrote:
>>>
>>> My words are perfectly clear and correct thus leaving the only
>>> possible rebuttal of changing the words and forming a rebuttal on the
>>> basis of these changed words.
>>
>> No, they aren't because they don't match the definitons of the problem
>> you claim to be working on.
>
> That is an entirely separate issue that cannot possibly be correctly
> addressed until after my words are totally agreed to in the precise
> context that they are specified.
>

If you start with the wrong definitions, why do people need (or even
want to) agree with them.

Your whole argument STARTS with a misunderstanding of the basic terms,
therefore the full thing is just garbage.

I wll note, that when you get ready to try to publish, the FIRST thing
that the publisher is going to want to see is your list of refences for
where you get your basics from.

The fact that they are just your own misunderstanding of the
fundamentals means you are going to get a foot into the door.

On 6/22/2022 7:22 PM, Richard Damon wrote:
> On 6/22/22 7:39 PM, olcott wrote:
>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>> On 6/22/22 10:55 AM, olcott wrote:
>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>> 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. In these circumstances, the
>>>>>> sensible
>>>>>> scientist (or I suppose mathematician, though I'm a scientist and
>>>>>> not a
>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>> quite as
>>>>>> consequential.
>>>>>
>>>>> That is like looking for alternatives to 5 > 3
>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>
>>>>>>>> That would have far-reaching consequences. Before going there,
>>>>>>>> maybe
>>>>>>>> think up some simpler, alternative explanations and eliminate them.
>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>> halts only
>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>
>>>>>>> Technically competent software engineers would agree. On the
>>>>>>> basis of
>>>>>>> the much more complete details that I provided in my original post.
>>>>>>>
>>>>>>> When P(P) is called from main its behavior depends on the return
>>>>>>> value
>>>>>>> of H. When H is called from main P(P) cannot possibly depend on the
>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>>>
>>>>>> That would be one consequence of going with your explanation. We'd
>>>>>> have to
>>>>>> say the behaviour of P(P) differs depending on caller. As I said,
>>>>>> try simpler,
>>>>>> less far-reaching explanations first.
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>>   H(P,P)==0 is provably correct
>>>>> H1(P,P)==1 is provably correct.
>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>
>>>>
>>>> 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. The actual behavior of the actual input
>>>> to H(P,P) is non halting thus rejecting its input is necessarily
>>>> correct.
>>>>
>>>>
>>>
>>> You have this wrong.
>>>
>>> A decider must compute the mapping that represents the FUNCTION it is
>>> deciding, there is actually nothing about "behavior" in the definition.
>>>
>>> For a HALTING decider, that mapping is based on the HALTING Behavior
>>> of the machine the input REPRESENTS.
>>
>> If you construe this as the actual behavior that the actual input
>> specifies then this is correct otherwise this is incorrect.
>
> If it isn't the acutual behavior, then it just isn't a Halt Decider, but
> maybe your POOP decider.
>
The behavior of P(P) is provably not the actual behavior of the actual
input to H(P,P). That you are insufficiently technically competent to
verify this is far less than no rebuttal at all.

--
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/22/22 4:27 PM, olcott wrote:
> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>> On Tue, 21 Jun 2022 21:38:56 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> void P(ptr x)
>>> {
>>>     if (H(x, x))
>>>       HERE: goto HERE;
>>>     return;
>>> }
>>>
>>> int main()
>>> {
>>>     Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> _P()
>>> [000010d2](01)  55              push ebp
>>> [000010d3](02)  8bec            mov ebp,esp
>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>> [000010d8](01)  50              push eax
>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>> [000010dc](01)  51              push ecx
>>> [000010dd](05)  e820feffff      call 00000f02
>>> [000010e2](03)  83c408          add esp,+08
>>> [000010e5](02)  85c0            test eax,eax
>>> [000010e7](02)  7402            jz 000010eb
>>> [000010e9](02)  ebfe            jmp 000010e9
>>> [000010eb](01)  5d              pop ebp
>>> [000010ec](01)  c3              ret
>>> Size in bytes:(0027) [000010ec]
>>>
>>> Every sufficiently competent software engineer can easily verify that
>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>> would never reach the "ret" instruction of P because both H and P
>>> would remain stuck in infinitely recursive emulation.
>>>
>>> If H does correctly determine that this is the case in a finite
>>> number of steps then H could reject its input on this basis. Here are
>>> the details of exactly how H does this in a finite number of steps.
>>>
>>> typedef struct Decoded
>>> {
>>>     u32 Address;
>>>     u32 ESP;          // Current value of ESP
>>>     u32 TOS;          // Current value of Top of Stack
>>>     u32 NumBytes;
>>>     u32 Simplified_Opcode;
>>>     u32 Decode_Target;
>>> } Decoded_Line_Of_Code;
>>>
>>>    machine   stack     stack     machine    assembly
>>>    address   address   data      code       language
>>>    ========  ========  ========  =========  =============
>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> // actual fully operational code in the x86utm operating system
>>> u32 H(u32 P, u32 I)
>>> {
>>> HERE:
>>>     u32 End_Of_Code;
>>>     u32 Address_of_H;              // 2022-06-17
>>>     u32 code_end                  = get_code_end(P);
>>>     Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>     Registers*  master_state      = (Registers*)
>>> Allocate(sizeof(Registers));
>>>     Registers*  slave_state       = (Registers*)
>>> Allocate(sizeof(Registers));
>>>     u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>     u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>> * 1000);
>>>
>>>     __asm lea eax, HERE             // 2022-06-18
>>>     __asm sub eax, 6                // 2022-06-18
>>>     __asm mov Address_of_H, eax     // 2022-06-18
>>>     __asm mov eax, END_OF_CODE
>>>     __asm mov End_Of_Code, eax
>>>
>>>     Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>     Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>     Output("\nBegin Simulation   Execution Trace Stored at:",
>>> execution_trace);
>>>     if (Decide_Halting(&execution_trace, &decoded, code_end,
>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>         goto END_OF_CODE;
>>>     return 0;  // Does not halt
>>> END_OF_CODE:
>>>     return 1; // Input has normally terminated
>>> }
>>>
>>> H knows its own machine address and on this basis it can easily
>>> examine its stored execution_trace of P and 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 invoked.
>>>
>>>
>>>
>>>
>>> Technically competent software engineers may not know this computer
>>> science:
>>>
>>> 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.
>>>
>>> computation that halts … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> The "ret" instruction of P is its final state.
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>
>>
>> void Px(u32 x)
>> {
>>     H(x, x);
>>     return;
>> }
>>
>> int main()
>> {
>>     Output("Input_Halts = ", H((u32)Px, (u32)Px));
>> }
>>
>> ...[000013e8][00102357][00000000] 83c408          add esp,+08
>> ...[000013eb][00102353][00000000] 50              push eax
>> ...[000013ec][0010234f][00000427] 6827040000      push 00000427
>> ---[000013f1][0010234f][00000427] e880f0ffff      call 00000476
>> Input_Halts = 0
>> ...[000013f6][00102357][00000000] 83c408          add esp,+08
>> ...[000013f9][00102357][00000000] 33c0            xor eax,eax
>> ...[000013fb][0010235b][00100000] 5d              pop ebp
>> ...[000013fc][0010235f][00000004] c3              ret
>> Number of Instructions Executed(16120)
>>
>> It gets the answer wrong, i.e. input has not been decided correctly.
>> QED.
>>
>> /Flibble
>>
>
> You and Richard are insufficiently technically competent at software
> engineering not meeting these specs:
>
> 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. No knowledge of the halting problem is required.
>
>

Except that I am probably at least as much of an expert on those fields
as you are. My one problem is that I do have knowledge of the halting
problem, that seems to make me resistant to your lies.

You might have more experiance with x86, but only because I work on a
number of different architectures, but your argument really isn't x86
specific, that is just the case you are working in.

(I was producing 'production' assembly routines 50 years ago, so I have
seen a number of different types of machines)

On 6/22/2022 7:25 PM, Richard Damon wrote:
> On 6/22/22 8:00 PM, olcott wrote:
>> On 6/22/2022 6:11 PM, Richard Damon wrote:
>>> On 6/22/22 1:58 PM, olcott wrote:
>>>>
>>>> My words are perfectly clear and correct thus leaving the only
>>>> possible rebuttal of changing the words and forming a rebuttal on
>>>> the basis of these changed words.
>>>
>>> No, they aren't because they don't match the definitons of the
>>> problem you claim to be working on.
>>
>> That is an entirely separate issue that cannot possibly be correctly
>> addressed until after my words are totally agreed to in the precise
>> context that they are specified.
>>
>
> If you start with the wrong definitions, why do people need (or even
> want to) agree with them.
>

First you agree that my words are perfectly correct within their
specified context then after this we can proceed with your objection
that they do not meet the definitions.

It is required that we have incremental closure on sub-points or full
closure will be impossible to achieve.

--
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/22/2022 7:32 PM, Richard Damon wrote:
> On 6/22/22 4:27 PM, olcott wrote:
>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> void P(ptr x)
>>>> {
>>>>     if (H(x, x))
>>>>       HERE: goto HERE;
>>>>     return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>     Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> _P()
>>>> [000010d2](01)  55              push ebp
>>>> [000010d3](02)  8bec            mov ebp,esp
>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>> [000010d8](01)  50              push eax
>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>> [000010dc](01)  51              push ecx
>>>> [000010dd](05)  e820feffff      call 00000f02
>>>> [000010e2](03)  83c408          add esp,+08
>>>> [000010e5](02)  85c0            test eax,eax
>>>> [000010e7](02)  7402            jz 000010eb
>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>> [000010eb](01)  5d              pop ebp
>>>> [000010ec](01)  c3              ret
>>>> Size in bytes:(0027) [000010ec]
>>>>
>>>> Every sufficiently competent software engineer can easily verify that
>>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>>> would never reach the "ret" instruction of P because both H and P
>>>> would remain stuck in infinitely recursive emulation.
>>>>
>>>> If H does correctly determine that this is the case in a finite
>>>> number of steps then H could reject its input on this basis. Here are
>>>> the details of exactly how H does this in a finite number of steps.
>>>>
>>>> typedef struct Decoded
>>>> {
>>>>     u32 Address;
>>>>     u32 ESP;          // Current value of ESP
>>>>     u32 TOS;          // Current value of Top of Stack
>>>>     u32 NumBytes;
>>>>     u32 Simplified_Opcode;
>>>>     u32 Decode_Target;
>>>> } Decoded_Line_Of_Code;
>>>>
>>>>    machine   stack     stack     machine    assembly
>>>>    address   address   data      code       language
>>>>    ========  ========  ========  =========  =============
>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> // actual fully operational code in the x86utm operating system
>>>> u32 H(u32 P, u32 I)
>>>> {
>>>> HERE:
>>>>     u32 End_Of_Code;
>>>>     u32 Address_of_H;              // 2022-06-17
>>>>     u32 code_end                  = get_code_end(P);
>>>>     Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>     Registers*  master_state      = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>     Registers*  slave_state       = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>     u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>     u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>> * 1000);
>>>>
>>>>     __asm lea eax, HERE             // 2022-06-18
>>>>     __asm sub eax, 6                // 2022-06-18
>>>>     __asm mov Address_of_H, eax     // 2022-06-18
>>>>     __asm mov eax, END_OF_CODE
>>>>     __asm mov End_Of_Code, eax
>>>>
>>>>     Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>     Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>     Output("\nBegin Simulation   Execution Trace Stored at:",
>>>> execution_trace);
>>>>     if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>         goto END_OF_CODE;
>>>>     return 0;  // Does not halt
>>>> END_OF_CODE:
>>>>     return 1; // Input has normally terminated
>>>> }
>>>>
>>>> H knows its own machine address and on this basis it can easily
>>>> examine its stored execution_trace of P and 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 invoked.
>>>>
>>>>
>>>>
>>>>
>>>> Technically competent software engineers may not know this computer
>>>> science:
>>>>
>>>> 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.
>>>>
>>>> computation that halts … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> The "ret" instruction of P is its final state.
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>
>>>
>>> void Px(u32 x)
>>> {
>>>     H(x, x);
>>>     return;
>>> }
>>>
>>> int main()
>>> {
>>>     Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>> }
>>>
>>> ...[000013e8][00102357][00000000] 83c408          add esp,+08
>>> ...[000013eb][00102353][00000000] 50              push eax
>>> ...[000013ec][0010234f][00000427] 6827040000      push 00000427
>>> ---[000013f1][0010234f][00000427] e880f0ffff      call 00000476
>>> Input_Halts = 0
>>> ...[000013f6][00102357][00000000] 83c408          add esp,+08
>>> ...[000013f9][00102357][00000000] 33c0            xor eax,eax
>>> ...[000013fb][0010235b][00100000] 5d              pop ebp
>>> ...[000013fc][0010235f][00000004] c3              ret
>>> Number of Instructions Executed(16120)
>>>
>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>> QED.
>>>
>>> /Flibble
>>>
>>
>> You and Richard are insufficiently technically competent at software
>> engineering not meeting these specs:
>>
>> 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. No knowledge of the halting problem is required.
>>
>>
>
> Except that I am probably at least as much of an expert on those fields
> as you are. My one problem is that I do have knowledge of the halting
> problem, that seems to make me resistant to your lies.
>
> You might have more experiance with x86, but only because I work on a
> number of different architectures, but your argument really isn't x86
> specific, that is just the case you are working in.
>
> (I was producing 'production' assembly routines 50 years ago, so I have
> seen a number of different types of machines)

On 6/22/22 8:37 PM, olcott wrote:
> On 6/22/2022 7:32 PM, Richard Damon wrote:
>> On 6/22/22 4:27 PM, olcott wrote:
>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>>     return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [000010d2](01)  55              push ebp
>>>>> [000010d3](02)  8bec            mov ebp,esp
>>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>>> [000010d8](01)  50              push eax
>>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [000010dc](01)  51              push ecx
>>>>> [000010dd](05)  e820feffff      call 00000f02
>>>>> [000010e2](03)  83c408          add esp,+08
>>>>> [000010e5](02)  85c0            test eax,eax
>>>>> [000010e7](02)  7402            jz 000010eb
>>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>>> [000010eb](01)  5d              pop ebp
>>>>> [000010ec](01)  c3              ret
>>>>> Size in bytes:(0027) [000010ec]
>>>>>
>>>>> Every sufficiently competent software engineer can easily verify that
>>>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>>>> would never reach the "ret" instruction of P because both H and P
>>>>> would remain stuck in infinitely recursive emulation.
>>>>>
>>>>> If H does correctly determine that this is the case in a finite
>>>>> number of steps then H could reject its input on this basis. Here are
>>>>> the details of exactly how H does this in a finite number of steps.
>>>>>
>>>>> typedef struct Decoded
>>>>> {
>>>>>     u32 Address;
>>>>>     u32 ESP;          // Current value of ESP
>>>>>     u32 TOS;          // Current value of Top of Stack
>>>>>     u32 NumBytes;
>>>>>     u32 Simplified_Opcode;
>>>>>     u32 Decode_Target;
>>>>> } Decoded_Line_Of_Code;
>>>>>
>>>>>    machine   stack     stack     machine    assembly
>>>>>    address   address   data      code       language
>>>>>    ========  ========  ========  =========  =============
>>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>
>>>>> // actual fully operational code in the x86utm operating system
>>>>> u32 H(u32 P, u32 I)
>>>>> {
>>>>> HERE:
>>>>>     u32 End_Of_Code;
>>>>>     u32 Address_of_H;              // 2022-06-17
>>>>>     u32 code_end                  = get_code_end(P);
>>>>>     Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>     Registers*  master_state      = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>     Registers*  slave_state       = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>     u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>>     u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>> * 1000);
>>>>>
>>>>>     __asm lea eax, HERE             // 2022-06-18
>>>>>     __asm sub eax, 6                // 2022-06-18
>>>>>     __asm mov Address_of_H, eax     // 2022-06-18
>>>>>     __asm mov eax, END_OF_CODE
>>>>>     __asm mov End_Of_Code, eax
>>>>>
>>>>>     Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>     Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>     Output("\nBegin Simulation   Execution Trace Stored at:",
>>>>> execution_trace);
>>>>>     if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>         goto END_OF_CODE;
>>>>>     return 0;  // Does not halt
>>>>> END_OF_CODE:
>>>>>     return 1; // Input has normally terminated
>>>>> }
>>>>>
>>>>> H knows its own machine address and on this basis it can easily
>>>>> examine its stored execution_trace of P and 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 invoked.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Technically competent software engineers may not know this computer
>>>>> science:
>>>>>
>>>>> 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.
>>>>>
>>>>> computation that halts … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>>
>>>>> The "ret" instruction of P is its final state.
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>
>>>>
>>>> void Px(u32 x)
>>>> {
>>>>     H(x, x);
>>>>     return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>     Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>> }
>>>>
>>>> ...[000013e8][00102357][00000000] 83c408          add esp,+08
>>>> ...[000013eb][00102353][00000000] 50              push eax
>>>> ...[000013ec][0010234f][00000427] 6827040000      push 00000427
>>>> ---[000013f1][0010234f][00000427] e880f0ffff      call 00000476
>>>> Input_Halts = 0
>>>> ...[000013f6][00102357][00000000] 83c408          add esp,+08
>>>> ...[000013f9][00102357][00000000] 33c0            xor eax,eax
>>>> ...[000013fb][0010235b][00100000] 5d              pop ebp
>>>> ...[000013fc][0010235f][00000004] c3              ret
>>>> Number of Instructions Executed(16120)
>>>>
>>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>>> QED.
>>>>
>>>> /Flibble
>>>>
>>>
>>> You and Richard are insufficiently technically competent at software
>>> engineering not meeting these specs:
>>>
>>> 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. No knowledge of the halting problem is required.
>>>
>>>
>>
>> Except that I am probably at least as much of an expert on those
>> fields as you are. My one problem is that I do have knowledge of the
>> halting problem, that seems to make me resistant to your lies.
>>
>> You might have more experiance with x86, but only because I work on a
>> number of different architectures, but your argument really isn't x86
>> specific, that is just the case you are working in.
>>
>> (I was producing 'production' assembly routines 50 years ago, so I
>> have seen a number of different types of machines)
>
> First you agree that my words are perfectly correct within their
> specified context

On 6/22/22 8:30 PM, olcott wrote:
> On 6/22/2022 7:22 PM, Richard Damon wrote:
>> On 6/22/22 7:39 PM, olcott wrote:
>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>> 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. In these circumstances, the
>>>>>>> sensible
>>>>>>> scientist (or I suppose mathematician, though I'm a scientist and
>>>>>>> not a
>>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>>> quite as
>>>>>>> consequential.
>>>>>>
>>>>>> That is like looking for alternatives to 5 > 3
>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>
>>>>>>>>> That would have far-reaching consequences. Before going there,
>>>>>>>>> maybe
>>>>>>>>> think up some simpler, alternative explanations and eliminate
>>>>>>>>> them.
>>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>>> halts only
>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>
>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>> basis of
>>>>>>>> the much more complete details that I provided in my original post.
>>>>>>>>
>>>>>>>> When P(P) is called from main its behavior depends on the return
>>>>>>>> value
>>>>>>>> of H. When H is called from main P(P) cannot possibly depend on the
>>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>>>>
>>>>>>> That would be one consequence of going with your explanation.
>>>>>>> We'd have to
>>>>>>> say the behaviour of P(P) differs depending on caller. As I said,
>>>>>>> try simpler,
>>>>>>> less far-reaching explanations first.
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>    if (H(x, x))
>>>>>>      HERE: goto HERE;
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>>   H(P,P)==0 is provably correct
>>>>>> H1(P,P)==1 is provably correct.
>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>
>>>>>
>>>>> 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. The actual behavior of the
>>>>> actual input to H(P,P) is non halting thus rejecting its input is
>>>>> necessarily correct.
>>>>>
>>>>>
>>>>
>>>> You have this wrong.
>>>>
>>>> A decider must compute the mapping that represents the FUNCTION it
>>>> is deciding, there is actually nothing about "behavior" in the
>>>> definition.
>>>>
>>>> For a HALTING decider, that mapping is based on the HALTING Behavior
>>>> of the machine the input REPRESENTS.
>>>
>>> If you construe this as the actual behavior that the actual input
>>> specifies then this is correct otherwise this is incorrect.
>>
>> If it isn't the acutual behavior, then it just isn't a Halt Decider,
>> but maybe your POOP decider.
>>
> The behavior of P(P) is provably not the actual behavior of the actual
> input to H(P,P). That you are insufficiently technically competent to
> verify this is far less than no rebuttal at all.
>

THen prove it. You know state the established basis in the field that
you start your argument from, and the step by step logic to get to that
answer.

Be prepared to give sources for your claimed "established basises".

Since for the Halting Problem, it is definitional, this will be hard to do.

It may well be that YOUR H shows a different behavior, but that just
shows it isn't actually a Halt Decider.

Remember the Definition:

H applied to M, w must accept if M applied to x halts in a finite number
of steps, and reject if M applied to x will not halt even when taken to
an unbounded number of steps.

DEFINITION.

H^ / P is DEFINED in the Linz proof to be asking H about P applied to
its own input.

Thus if P uses H applied to P, P, then for P to have been built
correctly, that input must refer to P applied to P.

Thus if P(P) isn't what H(P,P) is actually asking about, then either H
or P has been not defined correctly.

YOU FAIL.

You can't claim conformance to the requirements of the proof you are
countering and have H(P,P) not be looking at the behavor of P(P).

On 6/22/2022 7:48 PM, Richard Damon wrote:
> On 6/22/22 8:37 PM, olcott wrote:

>> First you agree that my words are perfectly correct within their
>> specified context
>
> Since you haven't actualy defined you context, and imply that it is the
> halting problem, where they can not be correct, that is not possible.
>>
First you agree that these words are 100% correct within the context of
software engineering totally ignoring the context of the halting problem.

#include <stdint.h>
#define u32 uint32_t

#include <stdint.h>
typedef void (*ptr)();

void P(ptr x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H(P, P));
}

_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]

Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H would
never reach the "ret" instruction of P because both H and P would remain
stuck in infinitely recursive emulation.

If H does correctly determine that this is the case in a finite number
of steps then H could reject its input on this basis. Here are the
details of exactly how H does this in a finite number of steps.

typedef struct Decoded
{ u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00211e8a][00211e8e] 55 push ebp
[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
[000010d8][00211e86][000010d2] 50 push eax // push P
[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
[000010dc][00211e82][000010d2] 51 push ecx // push P
[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
Infinitely Recursive Simulation Detected Simulation Stopped

// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{ HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*) Allocate(sizeof(Registers));
Registers* slave_state = (Registers*) Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
1000);

__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax

Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}

H knows its own machine address and on this basis it can easily examine
its stored execution_trace of P and 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 invoked.

--
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/22/2022 7:56 PM, Richard Damon wrote:
> On 6/22/22 8:30 PM, olcott wrote:
>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>> On 6/22/22 7:39 PM, olcott wrote:
>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>>> 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. In these circumstances, the
>>>>>>>> sensible
>>>>>>>> scientist (or I suppose mathematician, though I'm a scientist
>>>>>>>> and not a
>>>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>>>> quite as
>>>>>>>> consequential.
>>>>>>>
>>>>>>> That is like looking for alternatives to 5 > 3
>>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>>
>>>>>>>>>> That would have far-reaching consequences. Before going there,
>>>>>>>>>> maybe
>>>>>>>>>> think up some simpler, alternative explanations and eliminate
>>>>>>>>>> them.
>>>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>>>> halts only
>>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>>
>>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>>> basis of
>>>>>>>>> the much more complete details that I provided in my original
>>>>>>>>> post.
>>>>>>>>>
>>>>>>>>> When P(P) is called from main its behavior depends on the
>>>>>>>>> return value
>>>>>>>>> of H. When H is called from main P(P) cannot possibly depend on
>>>>>>>>> the
>>>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>>>> continues to remain stuck in infinite emulation until H aborts it.
>>>>>>>>>
>>>>>>>> That would be one consequence of going with your explanation.
>>>>>>>> We'd have to
>>>>>>>> say the behaviour of P(P) differs depending on caller. As I
>>>>>>>> said, try simpler,
>>>>>>>> less far-reaching explanations first.
>>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>    if (H(x, x))
>>>>>>>      HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>>   H(P,P)==0 is provably correct
>>>>>>> H1(P,P)==1 is provably correct.
>>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>>
>>>>>>
>>>>>> 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. The actual behavior of the
>>>>>> actual input to H(P,P) is non halting thus rejecting its input is
>>>>>> necessarily correct.
>>>>>>
>>>>>>
>>>>>
>>>>> You have this wrong.
>>>>>
>>>>> A decider must compute the mapping that represents the FUNCTION it
>>>>> is deciding, there is actually nothing about "behavior" in the
>>>>> definition.
>>>>>
>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>> Behavior of the machine the input REPRESENTS.
>>>>
>>>> If you construe this as the actual behavior that the actual input
>>>> specifies then this is correct otherwise this is incorrect.
>>>
>>> If it isn't the acutual behavior, then it just isn't a Halt Decider,
>>> but maybe your POOP decider.
>>>
>> The behavior of P(P) is provably not the actual behavior of the actual
>> input to H(P,P). That you are insufficiently technically competent to
>> verify this is far less than no rebuttal at all.
>>
>
> THen prove it.

I have proved it dozens of times and every fake "rebuttal" simply
ignores the proof.

--
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/22/22 8:34 PM, olcott wrote:
> On 6/22/2022 7:25 PM, Richard Damon wrote:
>> On 6/22/22 8:00 PM, olcott wrote:
>>> On 6/22/2022 6:11 PM, Richard Damon wrote:
>>>> On 6/22/22 1:58 PM, olcott wrote:
>>>>>
>>>>> My words are perfectly clear and correct thus leaving the only
>>>>> possible rebuttal of changing the words and forming a rebuttal on
>>>>> the basis of these changed words.
>>>>
>>>> No, they aren't because they don't match the definitons of the
>>>> problem you claim to be working on.
>>>
>>> That is an entirely separate issue that cannot possibly be correctly
>>> addressed until after my words are totally agreed to in the precise
>>> context that they are specified.
>>>
>>
>> If you start with the wrong definitions, why do people need (or even
>> want to) agree with them.
>>
>
> First you agree that my words are perfectly correct within their
> specified context then after this we can proceed with your objection
> that they do not meet the definitions.
>
> It is required that we have incremental closure on sub-points or full
> closure will be impossible to achieve.
>
>

I will not agree that Falshoods are correct.

IF you make that a precondition, you might as well give up.

The Journal reviews will not accept that either.

You need to break down your first points to show that they actually are
correct. This will require you to CLEARLY define your terms in terms of
what the standard theory uses.

You are hamstringing yourself by moving away from the simplicity of
Turing Macines into stored program machines, as you are going to first
need to show that you can actually properly express the problem in that
space.

Note, the "C Function" P that you show, by itself, is not something that
Computation Theory talks much about, as it doesn't express a complete
algorithm without a PROPER definition of H.

You clearly don't know the field well enough to provide that, since you
haven't yet.

An ACTUAL source code of H, and everything it calls, would be such a
definition, PROVIDED that code obeys the requriements of being a
computation (which is close to, but not identical to, a 'Pure Function'
that you have been talking about).

On 6/22/22 8:55 PM, olcott wrote:
> On 6/22/2022 7:48 PM, Richard Damon wrote:
>> On 6/22/22 8:37 PM, olcott wrote:
>
>>> First you agree that my words are perfectly correct within their
>>> specified context
>>
>> Since you haven't actualy defined you context, and imply that it is
>> the halting problem, where they can not be correct, that is not possible.
>>>
> First you agree that these words are 100% correct within the context of
> software engineering totally ignoring the context of the halting problem.
>
> #include <stdint.h>
> #define u32 uint32_t
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [000010d2](01)  55              push ebp
> [000010d3](02)  8bec            mov ebp,esp
> [000010d5](03)  8b4508          mov eax,[ebp+08]
> [000010d8](01)  50              push eax
> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
> [000010dc](01)  51              push ecx
> [000010dd](05)  e820feffff      call 00000f02
> [000010e2](03)  83c408          add esp,+08
> [000010e5](02)  85c0            test eax,eax
> [000010e7](02)  7402            jz 000010eb
> [000010e9](02)  ebfe            jmp 000010e9
> [000010eb](01)  5d              pop ebp
> [000010ec](01)  c3              ret
> Size in bytes:(0027) [000010ec]
>
> Every sufficiently competent software engineer can easily verify that
> the complete and correct x86 emulation of the input to H(P,P) by H would
> never reach the "ret" instruction of P because both H and P would remain
> stuck in infinitely recursive emulation.
>

So, if H actually is a program that does a COMPLETE and correct x86
emulation of its input, then YES, as I have said many time before, this
combination is non-halting.

The fact that you need to keep going back to this, and seem to just be
refusing to accept the conditions under which you have proved it just
shows the problems with your thought process.

> If H does correctly determine that this is the case in a finite number
> of steps then H could reject its input on this basis. Here are the
> details of exactly how H does this in a finite number of steps.

Except that NOW H isn't the H we were just talking about, so you are
just proving that you are either lying or an idiot.

Remember, the first analysis had the CONDITION on it that H did a
COMPLETE and correct x86 emulation.

Once you remove that property form H, that conclusion no long holds and
you are shown to be a lying idiot.

>
> typedef struct Decoded
> {
>   u32 Address;
>   u32 ESP;          // Current value of ESP
>   u32 TOS;          // Current value of Top of Stack
>   u32 NumBytes;
>   u32 Simplified_Opcode;
>   u32 Decode_Target;
> } Decoded_Line_Of_Code;
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [000010d2][00211e8a][00211e8e] 55         push ebp
> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
> [000010d8][00211e86][000010d2] 50         push eax        // push P
> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
> [000010dc][00211e82][000010d2] 51         push ecx        // push P
> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> // actual fully operational code in the x86utm operating system
> u32 H(u32 P, u32 I)
> {
> HERE:
>   u32 End_Of_Code;
>   u32 Address_of_H;              // 2022-06-17
>   u32 code_end                  = get_code_end(P);
>   Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> Allocate(sizeof(Decoded_Line_Of_Code));
>   Registers*  master_state      = (Registers*)
> Allocate(sizeof(Registers));
>   Registers*  slave_state       = (Registers*)
> Allocate(sizeof(Registers));
>   u32*        slave_stack       = Allocate(0x10000); // 64k;
>   u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
> 1000);
>
>   __asm lea eax, HERE             // 2022-06-18
>   __asm sub eax, 6                // 2022-06-18
>   __asm mov Address_of_H, eax     // 2022-06-18
>   __asm mov eax, END_OF_CODE
>   __asm mov End_Of_Code, eax
>
>   Output("Address_of_H:", Address_of_H); // 2022-06-11
>   Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>   Output("\nBegin Simulation   Execution Trace Stored at:",
> execution_trace);
>   if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>                      &slave_state, &slave_stack, Address_of_H, P, I))
>       goto END_OF_CODE;
>   return 0;  // Does not halt
> END_OF_CODE:
>   return 1; // Input has normally terminated
> }
>
> H knows its own machine address and on this basis it can easily examine
> its stored execution_trace of P and 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 invoked.
>
>

(b) is NOT a correct rule. Thos has been pointed out before, and you
have ignored it.

Your repeating it, without showing a source that claims it, or some
proof that it is correct, just proves that you are mentally incapable of
doing the task.

FAIL.

You appear to have gaslighted yourself into believing you own lies, or
are just a blatant patholgical liar.

If this is the best you have, you need to just give up and accept that
you are NEVER going to be able to establish your false claims to any
level of acceptance.

You might be able to fool a few people, but they are almost certainly
going to realize their error and snap out of it.

Hopefull, some day, you will to.

On 6/22/2022 8:02 PM, Dennis Bush wrote:
> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> #include <stdint.h>
>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>
>>>>>>>>>> #include <stdint.h>
>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> _P()
>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>
>>>>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>
>>>>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>>>>> number of steps then H could reject its input on this basis. Here
>>>>>>>>>> are the details of exactly how H does this in a finite number of
>>>>>>>>>> steps.
>>>>>>>>>>
>>>>>>>>>> typedef struct Decoded
>>>>>>>>>> {
>>>>>>>>>> u32 Address;
>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>> u32 NumBytes;
>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>
>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>> address address data code language
>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>
>>>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>> {
>>>>>>>>>> HERE:
>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>> u32 execution_trace =
>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>> * 1000);
>>>>>>>>>>
>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>
>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>> execution_trace);
>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>> END_OF_CODE:
>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>> examine its stored execution_trace of P and 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 invoked.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Technically competent software engineers may not know this computer
>>>>>>>>>> science:
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>
>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>
>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void Px(u32 x)
>>>>>>>>> {
>>>>>>>>> H(x, x);
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>> Input_Halts = 0
>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>
>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>>>>>>>> QED.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> You and Richard are insufficiently technically competent at software
>>>>>>>> engineering not meeting these specs:
>>>>>>>>
>>>>>>>> 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. No knowledge of the halting problem is required.
>>>>>>>
>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
>>>>>>> the problem is that you cannot recognize the fact that the infinite
>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>> omnishambles:
>>>>>> If you are competent then you already know this is true and lie about it:
>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>> would never reach the "ret" instruction of P because both H and P would
>>>>>> remain stuck in infinitely recursive emulation.
>>>>>
>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
>>>>>
>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>
>>>> Every sufficiently competent software engineer can easily verify that
>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>> would never reach the "ret" instruction of Px because both H and Px
>>>> would remain stuck in infinitely recursive emulation.
>>>
>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
>> Your entire basis and all of assumptions was incorrect so when I
>> provided an infallible one to that cannot possibly be correctly refuted
>> you simply dodged it. That is a smart move for a dishonest person that
>> is only interested in rebuttal.
>>
>> I dare you to go back to the prior post and find any error in my
>> airtight correct reasoning. Another dodge will be construed as a tacit
>> admission of defeat.
>
> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.

On 6/22/22 9:03 PM, olcott wrote:
> On 6/22/2022 7:56 PM, Richard Damon wrote:
>> On 6/22/22 8:30 PM, olcott wrote:
>>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>>> On 6/22/22 7:39 PM, olcott wrote:
>>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>>>> 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. In these circumstances, the
>>>>>>>>> sensible
>>>>>>>>> scientist (or I suppose mathematician, though I'm a scientist
>>>>>>>>> and not a
>>>>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>>>>> quite as
>>>>>>>>> consequential.
>>>>>>>>
>>>>>>>> That is like looking for alternatives to 5 > 3
>>>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>>>
>>>>>>>>>>> That would have far-reaching consequences. Before going
>>>>>>>>>>> there, maybe
>>>>>>>>>>> think up some simpler, alternative explanations and eliminate
>>>>>>>>>>> them.
>>>>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>>>>> halts only
>>>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>>>
>>>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>>>> basis of
>>>>>>>>>> the much more complete details that I provided in my original
>>>>>>>>>> post.
>>>>>>>>>>
>>>>>>>>>> When P(P) is called from main its behavior depends on the
>>>>>>>>>> return value
>>>>>>>>>> of H. When H is called from main P(P) cannot possibly depend
>>>>>>>>>> on the
>>>>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>>>>> continues to remain stuck in infinite emulation until H aborts
>>>>>>>>>> it.
>>>>>>>>>>
>>>>>>>>> That would be one consequence of going with your explanation.
>>>>>>>>> We'd have to
>>>>>>>>> say the behaviour of P(P) differs depending on caller. As I
>>>>>>>>> said, try simpler,
>>>>>>>>> less far-reaching explanations first.
>>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>>    if (H(x, x))
>>>>>>>>      HERE: goto HERE;
>>>>>>>>    return;
>>>>>>>> }
>>>>>>>>
>>>>>>>>   H(P,P)==0 is provably correct
>>>>>>>> H1(P,P)==1 is provably correct.
>>>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>>>
>>>>>>>
>>>>>>> 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. The actual behavior of the
>>>>>>> actual input to H(P,P) is non halting thus rejecting its input is
>>>>>>> necessarily correct.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> You have this wrong.
>>>>>>
>>>>>> A decider must compute the mapping that represents the FUNCTION it
>>>>>> is deciding, there is actually nothing about "behavior" in the
>>>>>> definition.
>>>>>>
>>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>>> Behavior of the machine the input REPRESENTS.
>>>>>
>>>>> If you construe this as the actual behavior that the actual input
>>>>> specifies then this is correct otherwise this is incorrect.
>>>>
>>>> If it isn't the acutual behavior, then it just isn't a Halt Decider,
>>>> but maybe your POOP decider.
>>>>
>>> The behavior of P(P) is provably not the actual behavior of the
>>> actual input to H(P,P). That you are insufficiently technically
>>> competent to verify this is far less than no rebuttal at all.
>>>
>>
>> THen prove it.
>
> I have proved it dozens of times and every fake "rebuttal" simply
> ignores the proof.
>
>

On 6/22/2022 8:14 PM, Richard Damon wrote:
> On 6/22/22 8:55 PM, olcott wrote:
>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>> On 6/22/22 8:37 PM, olcott wrote:
>>
>>>> First you agree that my words are perfectly correct within their
>>>> specified context
>>>
>>> Since you haven't actualy defined you context, and imply that it is
>>> the halting problem, where they can not be correct, that is not
>>> possible.
>>>>
>> First you agree that these words are 100% correct within the context
>> of software engineering totally ignoring the context of the halting
>> problem.
>>
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> void P(ptr x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(P, P));
>> }
>>
>> _P()
>> [000010d2](01)  55              push ebp
>> [000010d3](02)  8bec            mov ebp,esp
>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>> [000010d8](01)  50              push eax
>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>> [000010dc](01)  51              push ecx
>> [000010dd](05)  e820feffff      call 00000f02
>> [000010e2](03)  83c408          add esp,+08
>> [000010e5](02)  85c0            test eax,eax
>> [000010e7](02)  7402            jz 000010eb
>> [000010e9](02)  ebfe            jmp 000010e9
>> [000010eb](01)  5d              pop ebp
>> [000010ec](01)  c3              ret
>> Size in bytes:(0027) [000010ec]
>>
>> Every sufficiently competent software engineer can easily verify that
>> the complete and correct x86 emulation of the input to H(P,P) by H
>> would never reach the "ret" instruction of P because both H and P
>> would remain stuck in infinitely recursive emulation.
>>
>
> So, if H actually is a program that does a COMPLETE and correct x86
> emulation of its input, then YES, as I have said many time before, this
> combination is non-halting.
>
> The fact that you need to keep going back to this, and seem to just be
> refusing to accept the conditions under which you have proved it just
> shows the problems with your thought process.
>
>> If H does correctly determine that this is the case in a finite number
>> of steps then H could reject its input on this basis. Here are the
>> details of exactly how H does this in a finite number of steps.
>
> Except that NOW H isn't the H we were just talking about, so you are
> just proving that you are either lying or an idiot.
>
> Remember, the first analysis had the CONDITION on it that H did a
> COMPLETE and correct x86 emulation.
>
> Once you remove that property form H, that conclusion no long holds and
> you are shown to be a lying idiot.
>
>>
>> typedef struct Decoded
>> {
>>    u32 Address;
>>    u32 ESP;          // Current value of ESP
>>    u32 TOS;          // Current value of Top of Stack
>>    u32 NumBytes;
>>    u32 Simplified_Opcode;
>>    u32 Decode_Target;
>> } Decoded_Line_Of_Code;
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [000010d2][00211e8a][00211e8e] 55         push ebp
>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>> Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> // actual fully operational code in the x86utm operating system
>> u32 H(u32 P, u32 I)
>> {
>> HERE:
>>    u32 End_Of_Code;
>>    u32 Address_of_H;              // 2022-06-17
>>    u32 code_end                  = get_code_end(P);
>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>> Allocate(sizeof(Decoded_Line_Of_Code));
>>    Registers*  master_state      = (Registers*)
>> Allocate(sizeof(Registers));
>>    Registers*  slave_state       = (Registers*)
>> Allocate(sizeof(Registers));
>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>    u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
>> 1000);
>>
>>    __asm lea eax, HERE             // 2022-06-18
>>    __asm sub eax, 6                // 2022-06-18
>>    __asm mov Address_of_H, eax     // 2022-06-18
>>    __asm mov eax, END_OF_CODE
>>    __asm mov End_Of_Code, eax
>>
>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>> execution_trace);
>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>> &master_state,
>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>        goto END_OF_CODE;
>>    return 0;  // Does not halt
>> END_OF_CODE:
>>    return 1; // Input has normally terminated
>> }
>>
>> H knows its own machine address and on this basis it can easily
>> examine its stored execution_trace of P and 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 invoked.
>>
>>
>
> (b) is NOT a correct rule. Thos has been pointed out before, and you
> have ignored it.
>
That you don't understand what I mean does not mean that it is an
incorrect rule.

Here is an example where P does have instruction that could possibly
escape this otherwise infinitely recursive emulation:

void P(ptr x)
{ static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}

--
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/22/2022 8:19 PM, Richard Damon wrote:
> On 6/22/22 9:03 PM, olcott wrote:
>> On 6/22/2022 7:56 PM, Richard Damon wrote:
>>> On 6/22/22 8:30 PM, olcott wrote:
>>>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>>>> On 6/22/22 7:39 PM, olcott wrote:
>>>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>>>>> 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. In these circumstances, the
>>>>>>>>>> sensible
>>>>>>>>>> scientist (or I suppose mathematician, though I'm a scientist
>>>>>>>>>> and not a
>>>>>>>>>> mathematician) looks for alternative explanations which aren't
>>>>>>>>>> quite as
>>>>>>>>>> consequential.
>>>>>>>>>
>>>>>>>>> That is like looking for alternatives to 5 > 3
>>>>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>>>>
>>>>>>>>>>>> That would have far-reaching consequences. Before going
>>>>>>>>>>>> there, maybe
>>>>>>>>>>>> think up some simpler, alternative explanations and
>>>>>>>>>>>> eliminate them.
>>>>>>>>>>> There are no alternatives to immutable verified facts. H(P,P)
>>>>>>>>>>> halts only
>>>>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>>>>
>>>>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>>>>> basis of
>>>>>>>>>>> the much more complete details that I provided in my original
>>>>>>>>>>> post.
>>>>>>>>>>>
>>>>>>>>>>> When P(P) is called from main its behavior depends on the
>>>>>>>>>>> return value
>>>>>>>>>>> of H. When H is called from main P(P) cannot possibly depend
>>>>>>>>>>> on the
>>>>>>>>>>> return value of H because the correctly emulated input to H(P,P)
>>>>>>>>>>> continues to remain stuck in infinite emulation until H
>>>>>>>>>>> aborts it.
>>>>>>>>>>>
>>>>>>>>>> That would be one consequence of going with your explanation.
>>>>>>>>>> We'd have to
>>>>>>>>>> say the behaviour of P(P) differs depending on caller. As I
>>>>>>>>>> said, try simpler,
>>>>>>>>>> less far-reaching explanations first.
>>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>>    if (H(x, x))
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>   H(P,P)==0 is provably correct
>>>>>>>>> H1(P,P)==1 is provably correct.
>>>>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>>>>
>>>>>>>>
>>>>>>>> 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. The actual behavior of
>>>>>>>> the actual input to H(P,P) is non halting thus rejecting its
>>>>>>>> input is necessarily correct.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> You have this wrong.
>>>>>>>
>>>>>>> A decider must compute the mapping that represents the FUNCTION
>>>>>>> it is deciding, there is actually nothing about "behavior" in the
>>>>>>> definition.
>>>>>>>
>>>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>>>> Behavior of the machine the input REPRESENTS.
>>>>>>
>>>>>> If you construe this as the actual behavior that the actual input
>>>>>> specifies then this is correct otherwise this is incorrect.
>>>>>
>>>>> If it isn't the acutual behavior, then it just isn't a Halt
>>>>> Decider, but maybe your POOP decider.
>>>>>
>>>> The behavior of P(P) is provably not the actual behavior of the
>>>> actual input to H(P,P). That you are insufficiently technically
>>>> competent to verify this is far less than no rebuttal at all.
>>>>
>>>
>>> THen prove it.
>>
>> I have proved it dozens of times and every fake "rebuttal" simply
>> ignores the proof.
>>
>>
>
> Nope, you have claimed it, and given rhetorical arguments.

On 6/22/22 9:29 PM, olcott wrote:
> On 6/22/2022 8:14 PM, Richard Damon wrote:
>> On 6/22/22 8:55 PM, olcott wrote:
>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>
>>>>> First you agree that my words are perfectly correct within their
>>>>> specified context
>>>>
>>>> Since you haven't actualy defined you context, and imply that it is
>>>> the halting problem, where they can not be correct, that is not
>>>> possible.
>>>>>
>>> First you agree that these words are 100% correct within the context
>>> of software engineering totally ignoring the context of the halting
>>> problem.
>>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> void P(ptr x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> _P()
>>> [000010d2](01)  55              push ebp
>>> [000010d3](02)  8bec            mov ebp,esp
>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>> [000010d8](01)  50              push eax
>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>> [000010dc](01)  51              push ecx
>>> [000010dd](05)  e820feffff      call 00000f02
>>> [000010e2](03)  83c408          add esp,+08
>>> [000010e5](02)  85c0            test eax,eax
>>> [000010e7](02)  7402            jz 000010eb
>>> [000010e9](02)  ebfe            jmp 000010e9
>>> [000010eb](01)  5d              pop ebp
>>> [000010ec](01)  c3              ret
>>> Size in bytes:(0027) [000010ec]
>>>
>>> Every sufficiently competent software engineer can easily verify that
>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>> would never reach the "ret" instruction of P because both H and P
>>> would remain stuck in infinitely recursive emulation.
>>>
>>
>> So, if H actually is a program that does a COMPLETE and correct x86
>> emulation of its input, then YES, as I have said many time before,
>> this combination is non-halting.
>>
>> The fact that you need to keep going back to this, and seem to just be
>> refusing to accept the conditions under which you have proved it just
>> shows the problems with your thought process.
>>
>>> If H does correctly determine that this is the case in a finite
>>> number of steps then H could reject its input on this basis. Here are
>>> the details of exactly how H does this in a finite number of steps.
>>
>> Except that NOW H isn't the H we were just talking about, so you are
>> just proving that you are either lying or an idiot.
>>
>> Remember, the first analysis had the CONDITION on it that H did a
>> COMPLETE and correct x86 emulation.
>>
>> Once you remove that property form H, that conclusion no long holds
>> and you are shown to be a lying idiot.
>>
>>>
>>> typedef struct Decoded
>>> {
>>>    u32 Address;
>>>    u32 ESP;          // Current value of ESP
>>>    u32 TOS;          // Current value of Top of Stack
>>>    u32 NumBytes;
>>>    u32 Simplified_Opcode;
>>>    u32 Decode_Target;
>>> } Decoded_Line_Of_Code;
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> // actual fully operational code in the x86utm operating system
>>> u32 H(u32 P, u32 I)
>>> {
>>> HERE:
>>>    u32 End_Of_Code;
>>>    u32 Address_of_H;              // 2022-06-17
>>>    u32 code_end                  = get_code_end(P);
>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>    Registers*  master_state      = (Registers*)
>>> Allocate(sizeof(Registers));
>>>    Registers*  slave_state       = (Registers*)
>>> Allocate(sizeof(Registers));
>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>    u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>> * 1000);
>>>
>>>    __asm lea eax, HERE             // 2022-06-18
>>>    __asm sub eax, 6                // 2022-06-18
>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>    __asm mov eax, END_OF_CODE
>>>    __asm mov End_Of_Code, eax
>>>
>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>> execution_trace);
>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>> &master_state,
>>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>>        goto END_OF_CODE;
>>>    return 0;  // Does not halt
>>> END_OF_CODE:
>>>    return 1; // Input has normally terminated
>>> }
>>>
>>> H knows its own machine address and on this basis it can easily
>>> examine its stored execution_trace of P and 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 invoked.
>>>
>>>
>>
>> (b) is NOT a correct rule. Thos has been pointed out before, and you
>> have ignored it.
>>
> That you don't understand what I mean does not mean that it is an
> incorrect rule.
>
> Here is an example where P does have instruction that could possibly
> escape this otherwise infinitely recursive emulation:
>
>
> void P(ptr x)
> {
> static count = 0;
>   count++;
>   if count > 3)
>     return;
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>

FALLACY of proof by example. I never said that (b) isn't sometimes true,
just it isn't an always true condition. You fail at elementary logic.

The fundamental problem is you don't understand what is 'P' to
computation theory, it isn't just the 'C Function' but includes
EVERYTHING that P calls, and thus includes H.

Thus, the conditional in H that decides to abort its further emulation
is PART of the program P, and thus the 'No Conditional' condition isn't
satisfied.

You just seem to be too ignorant of the basic to be able to reason.

On 6/22/2022 8:21 PM, Dennis Bush wrote:
> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>
>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> _P()
>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>
>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>
>>>>>>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
>>>>>>>>>>>> steps.
>>>>>>>>>>>>
>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>> {
>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>
>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>> address address data code language
>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>
>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>> {
>>>>>>>>>>>> HERE:
>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>
>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>
>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>> examine its stored execution_trace of P and 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 invoked.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Technically competent software engineers may not know this computer
>>>>>>>>>>>> science:
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>
>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>
>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>> H(x, x);
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>
>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>>>>>>>>>> QED.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You and Richard are insufficiently technically competent at software
>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>
>>>>>>>>>> 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. No knowledge of the halting problem is required.
>>>>>>>>>
>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
>>>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>>>> omnishambles:
>>>>>>>> If you are competent then you already know this is true and lie about it:
>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>> would never reach the "ret" instruction of P because both H and P would
>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>
>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
>>>>>>>
>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>
>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>> would never reach the "ret" instruction of Px because both H and Px
>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>
>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
>>>> Your entire basis and all of assumptions was incorrect so when I
>>>> provided an infallible one to that cannot possibly be correctly refuted
>>>> you simply dodged it. That is a smart move for a dishonest person that
>>>> is only interested in rebuttal.
>>>>
>>>> I dare you to go back to the prior post and find any error in my
>>>> airtight correct reasoning. Another dodge will be construed as a tacit
>>>> admission of defeat.
>>>
>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
>> I never claimed that H(P,P) performs a complete and correct emulation of
>> its input so your rebuttal is the strawman deception.
>>
>> I claimed that H(P,P) correctly predicts that its complete and correct
>> x86 emulation of its input would never reach the "ret" instruction of P.
>
> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.

On 6/22/2022 8:36 PM, Richard Damon wrote:
> On 6/22/22 9:29 PM, olcott wrote:
>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>> On 6/22/22 8:55 PM, olcott wrote:
>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>
>>>>>> First you agree that my words are perfectly correct within their
>>>>>> specified context
>>>>>
>>>>> Since you haven't actualy defined you context, and imply that it is
>>>>> the halting problem, where they can not be correct, that is not
>>>>> possible.
>>>>>>
>>>> First you agree that these words are 100% correct within the context
>>>> of software engineering totally ignoring the context of the halting
>>>> problem.
>>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> void P(ptr x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> _P()
>>>> [000010d2](01)  55              push ebp
>>>> [000010d3](02)  8bec            mov ebp,esp
>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>> [000010d8](01)  50              push eax
>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>> [000010dc](01)  51              push ecx
>>>> [000010dd](05)  e820feffff      call 00000f02
>>>> [000010e2](03)  83c408          add esp,+08
>>>> [000010e5](02)  85c0            test eax,eax
>>>> [000010e7](02)  7402            jz 000010eb
>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>> [000010eb](01)  5d              pop ebp
>>>> [000010ec](01)  c3              ret
>>>> Size in bytes:(0027) [000010ec]
>>>>
>>>> Every sufficiently competent software engineer can easily verify
>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>> by H would never reach the "ret" instruction of P because both H and
>>>> P would remain stuck in infinitely recursive emulation.
>>>>
>>>
>>> So, if H actually is a program that does a COMPLETE and correct x86
>>> emulation of its input, then YES, as I have said many time before,
>>> this combination is non-halting.
>>>
>>> The fact that you need to keep going back to this, and seem to just
>>> be refusing to accept the conditions under which you have proved it
>>> just shows the problems with your thought process.
>>>
>>>> If H does correctly determine that this is the case in a finite
>>>> number of steps then H could reject its input on this basis. Here
>>>> are the details of exactly how H does this in a finite number of steps.
>>>
>>> Except that NOW H isn't the H we were just talking about, so you are
>>> just proving that you are either lying or an idiot.
>>>
>>> Remember, the first analysis had the CONDITION on it that H did a
>>> COMPLETE and correct x86 emulation.
>>>
>>> Once you remove that property form H, that conclusion no long holds
>>> and you are shown to be a lying idiot.
>>>
>>>>
>>>> typedef struct Decoded
>>>> {
>>>>    u32 Address;
>>>>    u32 ESP;          // Current value of ESP
>>>>    u32 TOS;          // Current value of Top of Stack
>>>>    u32 NumBytes;
>>>>    u32 Simplified_Opcode;
>>>>    u32 Decode_Target;
>>>> } Decoded_Line_Of_Code;
>>>>
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> // actual fully operational code in the x86utm operating system
>>>> u32 H(u32 P, u32 I)
>>>> {
>>>> HERE:
>>>>    u32 End_Of_Code;
>>>>    u32 Address_of_H;              // 2022-06-17
>>>>    u32 code_end                  = get_code_end(P);
>>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>    Registers*  master_state      = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>    Registers*  slave_state       = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>    u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>> * 1000);
>>>>
>>>>    __asm lea eax, HERE             // 2022-06-18
>>>>    __asm sub eax, 6                // 2022-06-18
>>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>>    __asm mov eax, END_OF_CODE
>>>>    __asm mov End_Of_Code, eax
>>>>
>>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>>> execution_trace);
>>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>> &master_state,
>>>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>>>        goto END_OF_CODE;
>>>>    return 0;  // Does not halt
>>>> END_OF_CODE:
>>>>    return 1; // Input has normally terminated
>>>> }
>>>>
>>>> H knows its own machine address and on this basis it can easily
>>>> examine its stored execution_trace of P and 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 invoked.
>>>>
>>>>
>>>
>>> (b) is NOT a correct rule. Thos has been pointed out before, and you
>>> have ignored it.
>>>
>> That you don't understand what I mean does not mean that it is an
>> incorrect rule.
>>
>> Here is an example where P does have instruction that could possibly
>> escape this otherwise infinitely recursive emulation:
>>
>>
>> void P(ptr x)
>> {
>> static count = 0;
>>    count++;
>>    if count > 3)
>>      return;
>>    if (H(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>
> FALLACY of proof by example. I never said that (b) isn't sometimes true,
> just it isn't an always true condition. You fail at elementary logic.

Try and find a valid counter-example. Every attempt at rebuttal that is
not a valid counter-example is one form of deception or another.

--
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/22/22 9:41 PM, olcott wrote:
> On 6/22/2022 8:36 PM, Richard Damon wrote:
>> On 6/22/22 9:29 PM, olcott wrote:
>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>
>>>>>>> First you agree that my words are perfectly correct within their
>>>>>>> specified context
>>>>>>
>>>>>> Since you haven't actualy defined you context, and imply that it
>>>>>> is the halting problem, where they can not be correct, that is not
>>>>>> possible.
>>>>>>>
>>>>> First you agree that these words are 100% correct within the
>>>>> context of software engineering totally ignoring the context of the
>>>>> halting problem.
>>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [000010d2](01)  55              push ebp
>>>>> [000010d3](02)  8bec            mov ebp,esp
>>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>>> [000010d8](01)  50              push eax
>>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [000010dc](01)  51              push ecx
>>>>> [000010dd](05)  e820feffff      call 00000f02
>>>>> [000010e2](03)  83c408          add esp,+08
>>>>> [000010e5](02)  85c0            test eax,eax
>>>>> [000010e7](02)  7402            jz 000010eb
>>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>>> [000010eb](01)  5d              pop ebp
>>>>> [000010ec](01)  c3              ret
>>>>> Size in bytes:(0027) [000010ec]
>>>>>
>>>>> Every sufficiently competent software engineer can easily verify
>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>> by H would never reach the "ret" instruction of P because both H
>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>
>>>>
>>>> So, if H actually is a program that does a COMPLETE and correct x86
>>>> emulation of its input, then YES, as I have said many time before,
>>>> this combination is non-halting.
>>>>
>>>> The fact that you need to keep going back to this, and seem to just
>>>> be refusing to accept the conditions under which you have proved it
>>>> just shows the problems with your thought process.
>>>>
>>>>> If H does correctly determine that this is the case in a finite
>>>>> number of steps then H could reject its input on this basis. Here
>>>>> are the details of exactly how H does this in a finite number of
>>>>> steps.
>>>>
>>>> Except that NOW H isn't the H we were just talking about, so you are
>>>> just proving that you are either lying or an idiot.
>>>>
>>>> Remember, the first analysis had the CONDITION on it that H did a
>>>> COMPLETE and correct x86 emulation.
>>>>
>>>> Once you remove that property form H, that conclusion no long holds
>>>> and you are shown to be a lying idiot.
>>>>
>>>>>
>>>>> typedef struct Decoded
>>>>> {
>>>>>    u32 Address;
>>>>>    u32 ESP;          // Current value of ESP
>>>>>    u32 TOS;          // Current value of Top of Stack
>>>>>    u32 NumBytes;
>>>>>    u32 Simplified_Opcode;
>>>>>    u32 Decode_Target;
>>>>> } Decoded_Line_Of_Code;
>>>>>
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>
>>>>> // actual fully operational code in the x86utm operating system
>>>>> u32 H(u32 P, u32 I)
>>>>> {
>>>>> HERE:
>>>>>    u32 End_Of_Code;
>>>>>    u32 Address_of_H;              // 2022-06-17
>>>>>    u32 code_end                  = get_code_end(P);
>>>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>    Registers*  master_state      = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>    Registers*  slave_state       = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>>    u32  execution_trace =
>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
>>>>>
>>>>>    __asm lea eax, HERE             // 2022-06-18
>>>>>    __asm sub eax, 6                // 2022-06-18
>>>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>>>    __asm mov eax, END_OF_CODE
>>>>>    __asm mov End_Of_Code, eax
>>>>>
>>>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>>>> execution_trace);
>>>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>> &master_state,
>>>>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>        goto END_OF_CODE;
>>>>>    return 0;  // Does not halt
>>>>> END_OF_CODE:
>>>>>    return 1; // Input has normally terminated
>>>>> }
>>>>>
>>>>> H knows its own machine address and on this basis it can easily
>>>>> examine its stored execution_trace of P and 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 invoked.
>>>>>
>>>>>
>>>>
>>>> (b) is NOT a correct rule. Thos has been pointed out before, and you
>>>> have ignored it.
>>>>
>>> That you don't understand what I mean does not mean that it is an
>>> incorrect rule.
>>>
>>> Here is an example where P does have instruction that could possibly
>>> escape this otherwise infinitely recursive emulation:
>>>
>>>
>>> void P(ptr x)
>>> {
>>> static count = 0;
>>>    count++;
>>>    if count > 3)
>>>      return;
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>
>> FALLACY of proof by example. I never said that (b) isn't sometimes
>> true, just it isn't an always true condition. You fail at elementary
>> logic.
>
> Try and find a valid counter-example. Every attempt at rebuttal that is
> not a valid counter-example is one form of deception or another.
>
>

On 6/22/22 9:33 PM, olcott wrote:
> On 6/22/2022 8:19 PM, Richard Damon wrote:
>> On 6/22/22 9:03 PM, olcott wrote:
>>> On 6/22/2022 7:56 PM, Richard Damon wrote:
>>>> On 6/22/22 8:30 PM, olcott wrote:
>>>>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>>>>> On 6/22/22 7:39 PM, olcott wrote:
>>>>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>>>>> On 6/22/2022 7:53 AM, olcott wrote:
>>>>>>>>>> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>>>>>>>>>>> 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. In these circumstances, the
>>>>>>>>>>> sensible
>>>>>>>>>>> scientist (or I suppose mathematician, though I'm a scientist
>>>>>>>>>>> and not a
>>>>>>>>>>> mathematician) looks for alternative explanations which
>>>>>>>>>>> aren't quite as
>>>>>>>>>>> consequential.
>>>>>>>>>>
>>>>>>>>>> That is like looking for alternatives to 5 > 3
>>>>>>>>>> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>>>>>>>>>>
>>>>>>>>>>>>> That would have far-reaching consequences. Before going
>>>>>>>>>>>>> there, maybe
>>>>>>>>>>>>> think up some simpler, alternative explanations and
>>>>>>>>>>>>> eliminate them.
>>>>>>>>>>>> There are no alternatives to immutable verified facts.
>>>>>>>>>>>> H(P,P) halts only
>>>>>>>>>>>> because H(P,P) correctly determines that its input never halts.
>>>>>>>>>>>>
>>>>>>>>>>>> Technically competent software engineers would agree. On the
>>>>>>>>>>>> basis of
>>>>>>>>>>>> the much more complete details that I provided in my
>>>>>>>>>>>> original post.
>>>>>>>>>>>>
>>>>>>>>>>>> When P(P) is called from main its behavior depends on the
>>>>>>>>>>>> return value
>>>>>>>>>>>> of H. When H is called from main P(P) cannot possibly depend
>>>>>>>>>>>> on the
>>>>>>>>>>>> return value of H because the correctly emulated input to
>>>>>>>>>>>> H(P,P)
>>>>>>>>>>>> continues to remain stuck in infinite emulation until H
>>>>>>>>>>>> aborts it.
>>>>>>>>>>>>
>>>>>>>>>>> That would be one consequence of going with your explanation.
>>>>>>>>>>> We'd have to
>>>>>>>>>>> say the behaviour of P(P) differs depending on caller. As I
>>>>>>>>>>> said, try simpler,
>>>>>>>>>>> less far-reaching explanations first.
>>>>>>>>>>
>>>>>>>>>> void P(u32 x)
>>>>>>>>>> {
>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>   H(P,P)==0 is provably correct
>>>>>>>>>> H1(P,P)==1 is provably correct.
>>>>>>>>>> H1(P,P) reports on the behavior of P(P).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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. The actual behavior of
>>>>>>>>> the actual input to H(P,P) is non halting thus rejecting its
>>>>>>>>> input is necessarily correct.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> You have this wrong.
>>>>>>>>
>>>>>>>> A decider must compute the mapping that represents the FUNCTION
>>>>>>>> it is deciding, there is actually nothing about "behavior" in
>>>>>>>> the definition.
>>>>>>>>
>>>>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>>>>> Behavior of the machine the input REPRESENTS.
>>>>>>>
>>>>>>> If you construe this as the actual behavior that the actual input
>>>>>>> specifies then this is correct otherwise this is incorrect.
>>>>>>
>>>>>> If it isn't the acutual behavior, then it just isn't a Halt
>>>>>> Decider, but maybe your POOP decider.
>>>>>>
>>>>> The behavior of P(P) is provably not the actual behavior of the
>>>>> actual input to H(P,P). That you are insufficiently technically
>>>>> competent to verify this is far less than no rebuttal at all.
>>>>>
>>>>
>>>> THen prove it.
>>>
>>> I have proved it dozens of times and every fake "rebuttal" simply
>>> ignores the proof.
>>>
>>>
>>
>> Nope, you have claimed it, and given rhetorical arguments.
>
> I have provided a complete provably correct execution traces of H(P,P)
> and P(P) that conclusively proves that they really do have different
> behavior yet people rejected it on the basis that they simply do not
> "believe in" the x86 language. This is why I aptly called them
> despicable liars.
>