// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 H(D,D);
15 }

The question:
Does directly executed D(D) halt? is contradicted by D for every H

The halting problem proofs merely show that self-contradictory questions
have no correct answer thus place no actual limit on computation

From the above source-code we see that there cannot possibly exist any
H that can return a value corresponding to the direct execution of D(D).

The reason for this is that D has been intentionally defined to do
the opposite of whatever value that H returns. This makes the question:
Does D(D) halt? A self-contradictory (thus incorrect) question for H.

Linguistics understands that the same word-for-word question sometimes
has a different answer depending on who is asked. Are you a little girl?
Is a concrete example of such a question.

When H1 is asked the same question: Does D(D) halt? It can correctly
answer, thus proving that the same word-for-word question has a
different meaning depending on who is asked.

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

On 12/28/23 8:27 PM, olcott wrote:
> // The following is written in C
> //
> 01 typedef int (*ptr)(); // pointer to int function
> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
> 03
> 04 int D(ptr x)
> 05 {
> 06   int Halt_Status = H(x, x);
> 07   if (Halt_Status)
> 08     HERE: goto HERE;
> 09   return Halt_Status;
> 10 }
> 11
> 12 void main()
> 13 {
> 14   H(D,D);
> 15 }
>
> The question:
> Does directly executed D(D) halt? is contradicted by D for every H

Huh? The question doesn't refer to what H says, so how is there a
contradiction?

>
> The halting problem proofs merely show that self-contradictory questions
> have no correct answer thus place no actual limit on computation

No, there IS a correct answer, H just doesn't give it.

>
> From the above source-code we see that there cannot possibly exist any
> H that can return a value corresponding to the direct execution of D(D).

Ok, so you AGREE with the statement of the Halting Theorem, that there
can not exist a Halt Decider that can give the correct answer for every
possible program/input combination. This is proven as we an make an
input that any given decider gets wrong.

Do yo somehow think that the D defined in the proof isn't actually "A
Program?".

Since it is built by a simple modification of the code of H, that means
your H isn't a program (and thus can't be a "Halt Decider Program".

Or, can you show a step in the modification that isn't actually allowed
by the definition of a "program"

>
> The reason for this is that D has been intentionally defined to do
> the opposite of whatever value that H returns. This makes the question:
> Does D(D) halt? A self-contradictory (thus incorrect) question for H.

No, not self-contradictory, H-Contradictory, (and D is not H). It just
makes H wrong, not some makes it so there is no correct answer to the
question.

>
> Linguistics understands that the same word-for-word question sometimes
> has a different answer depending on who is asked. Are you a little girl?
> Is a concrete example of such a question.

Yes, if the question asks something that depends on the context, which
the halting quesiton doesn't.

Asking about "You" can make it context sensitive, asking about something
specific (like the behavior of a given D) doesn't.

>
> When H1 is asked the same question: Does D(D) halt? It can correctly
> answer, thus proving that the same word-for-word question has a
> different meaning depending on who is asked.
>

No, it shows that a correct answer existed, and thus H was just wrong.

How does who you ask affect the behavoir of the machine being decided on?

That is like saying "Is Jill a little girl?" changes its answer based on
who you are asking the quesiton to.

Or, "Who Won the 2020 Presidential Election?" isn't based on the actual
ballot counts, but who you ask.

It seems your idea of "Truth" doesn't actually look at the actual facts,
but the belief of the thing asked.

I guess you beleive the MAGA propoganda and support their right to make
their claims.

If not, your whole theory just just a sham, because that is the sort of
truth it is based on.

On 12/28/2023 7:27 PM, olcott wrote:
> // The following is written in C
> //
> 01 typedef int (*ptr)(); // pointer to int function
> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
> 03
> 04 int D(ptr x)
> 05 {
> 06   int Halt_Status = H(x, x);
> 07   if (Halt_Status)
> 08     HERE: goto HERE;
> 09   return Halt_Status;
> 10 }
> 11
> 12 void main()
> 13 {
> 14   H(D,D);
> 15 }
>
> The question:
> Does directly executed D(D) halt? is contradicted by D for every H
>
> The halting problem proofs merely show that self-contradictory questions
> have no correct answer thus place no actual limit on computation
>
> From the above source-code we see that there cannot possibly exist any
> H that can return a value corresponding to the direct execution of D(D).
>
> The reason for this is that D has been intentionally defined to do
> the opposite of whatever value that H returns. This makes the question:
> Does D(D) halt? A self-contradictory (thus incorrect) question for H.
>
> Linguistics understands that the same word-for-word question sometimes
> has a different answer depending on who is asked. Are you a little girl?
> Is a concrete example of such a question.
>
> When H1 is asked the same question: Does D(D) halt? It can correctly
> answer, thus proving that the same word-for-word question has a
> different meaning depending on who is asked.
>

*H/D is precisely isomorphic to Jack's question posed to Jack*
Can Jack correctly answer “no” to this [yes/no] question?
When posed to Jack both {yes,no} are the wrong answer.

The proof that we can't ignore the context of who is asked the
question is that {yes,no} are the wrong answer when posed to
Jack and {no} is the correct answer when posed to anyone else.

There really is such a thing of linguistic context. Who is
asked a question <is> an aspect of linguistic context.

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

On 12/28/2023 8:27 PM, olcott wrote:

> // The following is written in C
> //
> 01 typedef int (*ptr)(); // pointer to int function
> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
> 03
> 04 int D(ptr x)
> 05 {
> 06   int Halt_Status = H(x, x);
> 07   if (Halt_Status)
> 08     HERE: goto HERE;
> 09   return Halt_Status;
> 10 }
> 11
> 12 void main()
> 13 {
> 14   H(D,D);
> 15 }

It's conceivable that
you (PO) don't know what lime numbers are for.
Perhaps you think that's
how programs are supposed to look.

https://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era
Computer programming in the punched card era

Punched cards

A punched card is a flexible write-once medium
that encodes data, most commonly 80 characters.
Groups or "decks" of cards form programs and
collections of data.

Identification and sequence

Columns 73-80 were ignored by the compilers and
could be used for identification or a sequence
number so that if the card deck was dropped
it could be restored to its proper order
using a card sorter.

----
I can't imagine
a program.related.reason that,
in 2023,
someone would be mimicking punched card.
I also can't imagine someone doing it
accidentally.

But here you are.
I can ask.

Why line numbers?

On 12/28/23 11:27 PM, olcott wrote:
> On 12/28/2023 7:27 PM, olcott wrote:
>> // The following is written in C
>> //
>> 01 typedef int (*ptr)(); // pointer to int function
>> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
>> 03
>> 04 int D(ptr x)
>> 05 {
>> 06   int Halt_Status = H(x, x);
>> 07   if (Halt_Status)
>> 08     HERE: goto HERE;
>> 09   return Halt_Status;
>> 10 }
>> 11
>> 12 void main()
>> 13 {
>> 14   H(D,D);
>> 15 }
>>
>> The question:
>> Does directly executed D(D) halt? is contradicted by D for every H
>>
>> The halting problem proofs merely show that self-contradictory questions
>> have no correct answer thus place no actual limit on computation
>>
>>  From the above source-code we see that there cannot possibly exist any
>> H that can return a value corresponding to the direct execution of D(D).
>>
>> The reason for this is that D has been intentionally defined to do
>> the opposite of whatever value that H returns. This makes the question:
>> Does D(D) halt? A self-contradictory (thus incorrect) question for H.
>>
>> Linguistics understands that the same word-for-word question sometimes
>> has a different answer depending on who is asked. Are you a little girl?
>> Is a concrete example of such a question.
>>
>> When H1 is asked the same question: Does D(D) halt? It can correctly
>> answer, thus proving that the same word-for-word question has a
>> different meaning depending on who is asked.
>>
>
> *H/D is precisely isomorphic to Jack's question posed to Jack*
> Can Jack correctly answer “no” to this [yes/no] question?
> When posed to Jack both {yes,no} are the wrong answer.

Nope, Because (I you can't seem to understand) H's answer is fixed by
its program, while Jack is a volitional Being.

>
> The proof that we can't ignore the context of who is asked the
> question is that {yes,no} are the wrong answer when posed to
> Jack and {no} is the correct answer when posed to anyone else.
>
> There really is such a thing of linguistic context. Who is
> asked a question <is> an aspect of linguistic context.
>

So, you REALLY think that programs have the power of "Choice" and can
give what ever answer they "want", reguardless of there programming?

I guess you don't understand what free will or determinism actually means.

This must mean that you are nothing but a robot that is stuck in its
programming but thinks it is alive and doesn't undestand the difference.

In other words, your IQ is exactly ZERO.

On 12/28/23 11:27 PM, olcott wrote:

> *H/D is precisely isomorphic to Jack's question posed to Jack*
> Can Jack correctly answer “no” to this [yes/no] question?
> When posed to Jack both {yes,no} are the wrong answer.

Note, the contradiction in Jacks question is due to the answer being
directly based on Jack's answer. The isomorphic question for H would be:

Accept this program if H will Reject it.

Yes, THAT sort of question is somewhat self-contradictory when asked of
H, as the QUESTION includes a reference to H. But even then, since H is
a deterministic Machine, its acceptance or rejection is fixed by its
code, and thus a correct answer does exist.

The Question of the Halting Problem doesn't include that sort of
explicit reference, so the problem you are trying to claim isn't in the
question.

The fact that we can make a program "powerful" enough to encode that
sort of behavior in it, is one thing that makes Turing Complete
langugage impossible to make complete deciders on.

Just like the mathematics of Natural Numbers is powerful enough to make
its system have properties that can not be proven, and thus system that
support them "Incomplete" (With "Completeness" defined as the ability to
prove every true statement in the system).

>
> The proof that we can't ignore the context of who is asked the
> question is that {yes,no} are the wrong answer when posed to
> Jack and {no} is the correct answer when posed to anyone else.
>
> There really is such a thing of linguistic context. Who is
> asked a question <is> an aspect of linguistic context.
>

You are just "Proving" that you don't know how to do logic, or
understand its basic principles.

You just don't understand what it means for something to be "True",
perhaps because lying is just your natural nature.

On 12/29/2023 2:41 AM, Jim Burns wrote:
> On 12/28/2023 8:27 PM, olcott wrote:
>
>> // The following is written in C
>> //
>> 01 typedef int (*ptr)(); // pointer to int function
>> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
>> 03
>> 04 int D(ptr x)
>> 05 {
>> 06   int Halt_Status = H(x, x);
>> 07   if (Halt_Status)
>> 08     HERE: goto HERE;
>> 09   return Halt_Status;
>> 10 }
>> 11
>> 12 void main()
>> 13 {
>> 14   H(D,D);
>> 15 }
>
> It's conceivable that
> you (PO) don't know what lime numbers are for.
> Perhaps you think that's
> how programs are supposed to look.
>

I kept the line numbers because my other paper requires them to
show the execution trace of H simulating D with an x86 emulator.

> https://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era
> Computer programming in the punched card era
>
> Punched cards
>
> A punched card is a flexible write-once medium
> that encodes data, most commonly 80 characters.
> Groups or "decks" of cards form programs and
> collections of data.
>
> Identification and sequence
>
> Columns 73-80 were ignored by the compilers and
> could be used for identification or a sequence
> number so that if the card deck was dropped
> it could be restored to its proper order
> using a card sorter.
>
> ----
> I can't imagine
> a program.related.reason that,
> in 2023,
> someone would be mimicking punched card.
> I also can't imagine someone doing it
> accidentally.
>
> But here you are.
> I can ask.
>
> Why line numbers?

*Execution Trace*
Line 14: main() invokes H(D,D);

*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 06.

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

On 12/29/2023 9:29 AM, olcott wrote:
> On 12/29/2023 2:41 AM, Jim Burns wrote:
>> On 12/28/2023 8:27 PM, olcott wrote:
>>
>>> // The following is written in C
>>> //
>>> 01 typedef int (*ptr)(); // pointer to int function
>>> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
>>> 03
>>> 04 int D(ptr x)
>>> 05 {
>>> 06   int Halt_Status = H(x, x);
>>> 07   if (Halt_Status)
>>> 08     HERE: goto HERE;
>>> 09   return Halt_Status;
>>> 10 }
>>> 11
>>> 12 void main()
>>> 13 {
>>> 14   H(D,D);
>>> 15 }
>>
>> It's conceivable that
>> you (PO) don't know what lime numbers are for.
>> Perhaps you think that's
>> how programs are supposed to look.
>>
>
> I kept the line numbers because my other paper requires them to
> show the execution trace of H simulating D with an x86 emulator.
>
>> https://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era
>> Computer programming in the punched card era
>>
>> Punched cards
>>
>> A punched card is a flexible write-once medium
>> that encodes data, most commonly 80 characters.
>> Groups or "decks" of cards form programs and
>> collections of data.
>>
>> Identification and sequence
>>
>> Columns 73-80 were ignored by the compilers and
>> could be used for identification or a sequence
>> number so that if the card deck was dropped
>> it could be restored to its proper order
>> using a card sorter.
>>
>> ----
>> I can't imagine
>> a program.related.reason that,
>> in 2023,
>> someone would be mimicking punched card.
>> I also can't imagine someone doing it
>> accidentally.
>>
>> But here you are.
>> I can ask.
>>
>> Why line numbers?
>
> *Execution Trace*
> Line 14: main() invokes H(D,D);
>
> *keeps repeating* (unless aborted)
> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
> *Simulation invariant*
> D correctly simulated by H cannot possibly reach past its own line 06.
>

This is the actual x86utm operating system that I wrote
based on an open source x86 emulator.

https://github.com/plolcott/x86utm

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

On 12/29/23 10:29 AM, olcott wrote:
> On 12/29/2023 2:41 AM, Jim Burns wrote:
>> On 12/28/2023 8:27 PM, olcott wrote:
>>
>>> // The following is written in C
>>> //
>>> 01 typedef int (*ptr)(); // pointer to int function
>>> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
>>> 03
>>> 04 int D(ptr x)
>>> 05 {
>>> 06   int Halt_Status = H(x, x);
>>> 07   if (Halt_Status)
>>> 08     HERE: goto HERE;
>>> 09   return Halt_Status;
>>> 10 }
>>> 11
>>> 12 void main()
>>> 13 {
>>> 14   H(D,D);
>>> 15 }
>>
>> It's conceivable that
>> you (PO) don't know what lime numbers are for.
>> Perhaps you think that's
>> how programs are supposed to look.
>>
>
> I kept the line numbers because my other paper requires them to
> show the execution trace of H simulating D with an x86 emulator.
>
>> https://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era
>> Computer programming in the punched card era
>>
>> Punched cards
>>
>> A punched card is a flexible write-once medium
>> that encodes data, most commonly 80 characters.
>> Groups or "decks" of cards form programs and
>> collections of data.
>>
>> Identification and sequence
>>
>> Columns 73-80 were ignored by the compilers and
>> could be used for identification or a sequence
>> number so that if the card deck was dropped
>> it could be restored to its proper order
>> using a card sorter.
>>
>> ----
>> I can't imagine
>> a program.related.reason that,
>> in 2023,
>> someone would be mimicking punched card.
>> I also can't imagine someone doing it
>> accidentally.
>>
>> But here you are.
>> I can ask.
>>
>> Why line numbers?
>
> *Execution Trace*
> Line 14: main() invokes H(D,D);
>
> *keeps repeating* (unless aborted)
> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
> *Simulation invariant*
> D correctly simulated by H cannot possibly reach past its own line 06.
>

No, wrong conclusion. The actual answer is that H can not "Correctly
Simulate" this input ang give the required answer.

Since this H DOEN'T "Correctly simulate" its input, the criteria of
"Correct Simulation by H" is merely a FALSE CRITERIA.

On 12/29/23 10:33 AM, olcott wrote:
> On 12/29/2023 9:29 AM, olcott wrote:
>> On 12/29/2023 2:41 AM, Jim Burns wrote:
>>> On 12/28/2023 8:27 PM, olcott wrote:
>>>
>>>> // The following is written in C
>>>> //
>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
>>>> 03
>>>> 04 int D(ptr x)
>>>> 05 {
>>>> 06   int Halt_Status = H(x, x);
>>>> 07   if (Halt_Status)
>>>> 08     HERE: goto HERE;
>>>> 09   return Halt_Status;
>>>> 10 }
>>>> 11
>>>> 12 void main()
>>>> 13 {
>>>> 14   H(D,D);
>>>> 15 }
>>>
>>> It's conceivable that
>>> you (PO) don't know what lime numbers are for.
>>> Perhaps you think that's
>>> how programs are supposed to look.
>>>
>>
>> I kept the line numbers because my other paper requires them to
>> show the execution trace of H simulating D with an x86 emulator.
>>
>>> https://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era
>>> Computer programming in the punched card era
>>>
>>> Punched cards
>>>
>>> A punched card is a flexible write-once medium
>>> that encodes data, most commonly 80 characters.
>>> Groups or "decks" of cards form programs and
>>> collections of data.
>>>
>>> Identification and sequence
>>>
>>> Columns 73-80 were ignored by the compilers and
>>> could be used for identification or a sequence
>>> number so that if the card deck was dropped
>>> it could be restored to its proper order
>>> using a card sorter.
>>>
>>> ----
>>> I can't imagine
>>> a program.related.reason that,
>>> in 2023,
>>> someone would be mimicking punched card.
>>> I also can't imagine someone doing it
>>> accidentally.
>>>
>>> But here you are.
>>> I can ask.
>>>
>>> Why line numbers?
>>
>> *Execution Trace*
>> Line 14: main() invokes H(D,D);
>>
>> *keeps repeating* (unless aborted)
>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>
>> *Simulation invariant*
>> D correctly simulated by H cannot possibly reach past its own line 06.
>>
>
> This is the actual x86utm operating system that I wrote
> based on an open source x86 emulator.
>
> https://github.com/plolcott/x86utm
>

Which shows that the ACTUAL "Correct Simulation" of D(D) Halts.

Thus, either you are Lying that H does a "Correct Simulation" of D(D),
or that you believe that "Correct" isn't based on actual facts, but on
point of view.

That means you think MAGA is "Correct" in its assertion that the
"Correct winner" of the 2020 Presidential Election was Trump due to the
"Wide Spread" voter fraud.

THat is an inescapable conclusion from your arguments, despite your
claims that this is what you are trying to prove false. You just don't
understand the logic you are using.

On 1/2/2024 9:30 AM, immibis wrote:
> On 1/2/24 05:19, olcott wrote:
>> On 1/1/2024 9:56 PM, immibis wrote:
>>> On 1/2/24 02:18, olcott wrote:
>>>> On 1/1/2024 5:32 PM, immibis wrote:
>>>>> On 12/29/23 05:27, olcott wrote:
>>>>>>
>>>>>> *H/D is precisely isomorphic to Jack's question posed to Jack*
>>>>>> Can Jack correctly answer “no” to this [yes/no] question?
>>>>>> When posed to Jack both {yes,no} are the wrong answer.
>>>>>>
>>>>>
>>>>> You have proven that it's impossible for Jack to correctly answer
>>>>> all questions.
>>>>>
>>>>
>>>> If I ask you: What time is it (yes or no)?
>>>> you cannot provide the correct answer because the question is
>>>> incorrect.
>>>>
>>>> It is the same with self-contradictory questions that contradict both
>>>> {yes,no} answers.
>>>>
>>>
>>> If I ask you: What time is it (morning or night)?
>>>
>>> and you say MORNING but the time is NIGHT then you are simply wrong.
>>
>> The point is that question is wrong:
>> What time is it (yes or no)?
>>
>> Thus proving that some questions cannot be answered because
>> they are incorrect. It is the same thing for self-contradictory
>> questions that contradict both {yes,no} answers.
>>
>
> And you are wrong, because the halting question is not incorrect or
> self-contradictory.

Can Jack correctly answer “no” to this [yes/no] question?
What answer of [yes/no] can Jack correctly provide?

If the answer is neither then this conclusively proves
that Jack's question is self contradictory.

What return value of [0/1] can H(D,D) correctly provide?
If the answer is neither then this conclusively proves
that the input to H(D,D) is self contradictory.

ZFC recognizes these issues with Russell's Paradox
and rejects Russell's Paradox as unsound.

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

On 1/2/24 18:51, olcott wrote:
> On 1/2/2024 9:30 AM, immibis wrote:
>> On 1/2/24 05:19, olcott wrote:
>>> On 1/1/2024 9:56 PM, immibis wrote:
>>>> On 1/2/24 02:18, olcott wrote:
>>>>> On 1/1/2024 5:32 PM, immibis wrote:
>>>>>> On 12/29/23 05:27, olcott wrote:
>>>>>>>
>>>>>>> *H/D is precisely isomorphic to Jack's question posed to Jack*
>>>>>>> Can Jack correctly answer “no” to this [yes/no] question?
>>>>>>> When posed to Jack both {yes,no} are the wrong answer.
>>>>>>>
>>>>>>
>>>>>> You have proven that it's impossible for Jack to correctly answer
>>>>>> all questions.
>>>>>>
>>>>>
>>>>> If I ask you: What time is it (yes or no)?
>>>>> you cannot provide the correct answer because the question is
>>>>> incorrect.
>>>>>
>>>>> It is the same with self-contradictory questions that contradict both
>>>>> {yes,no} answers.
>>>>>
>>>>
>>>> If I ask you: What time is it (morning or night)?
>>>>
>>>> and you say MORNING but the time is NIGHT then you are simply wrong.
>>>
>>> The point is that question is wrong:
>>> What time is it (yes or no)?
>>>
>>> Thus proving that some questions cannot be answered because
>>> they are incorrect. It is the same thing for self-contradictory
>>> questions that contradict both {yes,no} answers.
>>>
>>
>> And you are wrong, because the halting question is not incorrect or
>> self-contradictory.
>
> Can Jack correctly answer “no” to this [yes/no] question?

The halting question is not self-referential.

On 1/2/2024 9:33 AM, immibis wrote:
> On 1/2/24 05:21, olcott wrote:
>> On 1/1/2024 9:57 PM, immibis wrote:
>>> On 1/2/24 02:27, olcott wrote:
>>>> On 1/1/2024 5:34 PM, immibis wrote:
>>>>> On 12/29/23 16:33, olcott wrote:
>>>>>>
>>>>>> This is the actual x86utm operating system that I wrote
>>>>>> based on an open source x86 emulator.
>>>>>>
>>>>>> https://github.com/plolcott/x86utm
>>>>>>
>>>>>
>>>>> As we discussed on Stack Overflow, this has a bug that causes
>>>>> incorrect simulation.
>>>>
>>>> There is no bug that anyone can report because there is no bug.
>>>> Also you just admitted that there is no bug in your other reply.
>>>> *D simulated by H cannot possibly terminate normally*
>>>>
>>>
>>> My other answer is about a simulating halt decider, not your halt
>>> decider.
>>
>> H <is> a fully operational simulating termination analyzer
>> on a subset of all inputs.
>>
>
> H is an incorrect simulator because it assumes that H does not halt
> although H halts.

D has a verifiably different execution trace for H(D,D)
than it has for H1(D,D).

The outer recursive simulation of D by H1(D,D) need
not abort its simulation because the inner simulation
of D by H(D,D) aborts its simulation of its different D.

The inner and outer D are different instances of D thus
actually do not have the same behavior.

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

On 1/2/24 19:08, olcott wrote:
> On 1/2/2024 9:33 AM, immibis wrote:
>>
>> H is an incorrect simulator because it assumes that H does not halt
>> although H halts.
> > D has a verifiably different execution trace for H(D,D)
> than it has for H1(D,D).
>

This sentence violates linguistics. There is no such thing as "an
execution trade for D for H(D,D)" and "an execution trade for D for H1(D,D)"

On 1/2/2024 9:34 AM, immibis wrote:
> On 1/2/24 05:23, olcott wrote:
>> On 1/1/2024 9:58 PM, immibis wrote:
>>> On 1/2/24 02:19, olcott wrote:
>>>> On 1/1/2024 5:33 PM, immibis wrote:
>>>>> On 12/29/23 16:29, olcott wrote:
>>>>>>
>>>>>> *Execution Trace*
>>>>>> Line 14: main() invokes H(D,D);
>>>>>>
>>>>>> *keeps repeating* (unless aborted)
>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>
>>>>>> *Simulation invariant*
>>>>>> D correctly simulated by H cannot possibly reach past its own line
>>>>>> 06.
>>>>>>
>>>>>
>>>>> *Actual result*
>>>>> The simulation runs forever because there is no point where the
>>>>> simulation can stop.
>>>>
>>>> Thus aborting the simulation and reporting non-halting is the correct
>>>> answer.
>>>>
>>>
>>> If the simulation aborts then it halts.
>>
>> *There is a subtlety that you are missing*
>>
>> A program only halts when it reaches its
>> own final state and terminates normally.
>> *This is impossible for the D of H/D*
>>
>
> No programs halt. Proof:
>
> bool halts(ptr program, ptr input) {
>     begin_simulation(program, input);
>     abort_simulation();
>     return false;
> }

Ridiculous nonsense.

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

On 1/2/24 19:12, olcott wrote:
> On 1/2/2024 9:34 AM, immibis wrote:
>> On 1/2/24 05:23, olcott wrote:
>>> On 1/1/2024 9:58 PM, immibis wrote:
>>>> On 1/2/24 02:19, olcott wrote:
>>>>> On 1/1/2024 5:33 PM, immibis wrote:
>>>>>> On 12/29/23 16:29, olcott wrote:
>>>>>>>
>>>>>>> *Execution Trace*
>>>>>>> Line 14: main() invokes H(D,D);
>>>>>>>
>>>>>>> *keeps repeating* (unless aborted)
>>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>>
>>>>>>> *Simulation invariant*
>>>>>>> D correctly simulated by H cannot possibly reach past its own
>>>>>>> line 06.
>>>>>>>
>>>>>>
>>>>>> *Actual result*
>>>>>> The simulation runs forever because there is no point where the
>>>>>> simulation can stop.
>>>>>
>>>>> Thus aborting the simulation and reporting non-halting is the correct
>>>>> answer.
>>>>>
>>>>
>>>> If the simulation aborts then it halts.
>>>
>>> *There is a subtlety that you are missing*
>>>
>>> A program only halts when it reaches its
>>> own final state and terminates normally.
>>> *This is impossible for the D of H/D*
>>>
>>
>> No programs halt. Proof:
>>
>> bool halts(ptr program, ptr input) {
>>      begin_simulation(program, input);
>>      abort_simulation();
>>      return false;
>> }
>
> Ridiculous nonsense.
>

program correctly simulated by halts cannot possibly reach past its own
line 1.

On 1/2/2024 12:07 PM, immibis wrote:
> On 1/2/24 18:51, olcott wrote:
>> On 1/2/2024 9:30 AM, immibis wrote:
>>> On 1/2/24 05:19, olcott wrote:
>>>> On 1/1/2024 9:56 PM, immibis wrote:
>>>>> On 1/2/24 02:18, olcott wrote:
>>>>>> On 1/1/2024 5:32 PM, immibis wrote:
>>>>>>> On 12/29/23 05:27, olcott wrote:
>>>>>>>>
>>>>>>>> *H/D is precisely isomorphic to Jack's question posed to Jack*
>>>>>>>> Can Jack correctly answer “no” to this [yes/no] question?
>>>>>>>> When posed to Jack both {yes,no} are the wrong answer.
>>>>>>>>
>>>>>>>
>>>>>>> You have proven that it's impossible for Jack to correctly answer
>>>>>>> all questions.
>>>>>>>
>>>>>>
>>>>>> If I ask you: What time is it (yes or no)?
>>>>>> you cannot provide the correct answer because the question is
>>>>>> incorrect.
>>>>>>
>>>>>> It is the same with self-contradictory questions that contradict both
>>>>>> {yes,no} answers.
>>>>>>
>>>>>
>>>>> If I ask you: What time is it (morning or night)?
>>>>>
>>>>> and you say MORNING but the time is NIGHT then you are simply wrong.
>>>>
>>>> The point is that question is wrong:
>>>> What time is it (yes or no)?
>>>>
>>>> Thus proving that some questions cannot be answered because
>>>> they are incorrect. It is the same thing for self-contradictory
>>>> questions that contradict both {yes,no} answers.
>>>>
>>>
>>> And you are wrong, because the halting question is not incorrect or
>>> self-contradictory.
>>
>> Can Jack correctly answer “no” to this [yes/no] question?
>
> The halting question is not self-referential.

int D(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

void main()
{ H(D,D);
}

That D contradicts both values that H returns proves
that H/D is self-referential.

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

On 1/2/2024 12:09 PM, immibis wrote:
> On 1/2/24 19:08, olcott wrote:
>> On 1/2/2024 9:33 AM, immibis wrote:
>>>
>>> H is an incorrect simulator because it assumes that H does not halt
>>> although H halts.
>>  > D has a verifiably different execution trace for H(D,D)
>> than it has for H1(D,D).
>>
>
> This sentence violates linguistics. There is no such thing as "an
> execution trade for D for H(D,D)" and "an execution trade for D for
> H1(D,D)"
>

You can't even get the word right: "execution trace".

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

On 1/2/2024 12:18 PM, immibis wrote:
> On 1/2/24 19:12, olcott wrote:
>> On 1/2/2024 9:34 AM, immibis wrote:
>>> On 1/2/24 05:23, olcott wrote:
>>>> On 1/1/2024 9:58 PM, immibis wrote:
>>>>> On 1/2/24 02:19, olcott wrote:
>>>>>> On 1/1/2024 5:33 PM, immibis wrote:
>>>>>>> On 12/29/23 16:29, olcott wrote:
>>>>>>>>
>>>>>>>> *Execution Trace*
>>>>>>>> Line 14: main() invokes H(D,D);
>>>>>>>>
>>>>>>>> *keeps repeating* (unless aborted)
>>>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates
>>>>>>>> D(D)
>>>>>>>>
>>>>>>>> *Simulation invariant*
>>>>>>>> D correctly simulated by H cannot possibly reach past its own
>>>>>>>> line 06.
>>>>>>>>
>>>>>>>
>>>>>>> *Actual result*
>>>>>>> The simulation runs forever because there is no point where the
>>>>>>> simulation can stop.
>>>>>>
>>>>>> Thus aborting the simulation and reporting non-halting is the correct
>>>>>> answer.
>>>>>>
>>>>>
>>>>> If the simulation aborts then it halts.
>>>>
>>>> *There is a subtlety that you are missing*
>>>>
>>>> A program only halts when it reaches its
>>>> own final state and terminates normally.
>>>> *This is impossible for the D of H/D*
>>>>
>>>
>>> No programs halt. Proof:
>>>
>>> bool halts(ptr program, ptr input) {
>>>      begin_simulation(program, input);
>>>      abort_simulation();
>>>      return false;
>>> }
>>
>> Ridiculous nonsense.
>>
>
> program correctly simulated by halts cannot possibly reach past its own
> line 1.

I don't understand why you are motivated to say
things that are very obviously counter-factual.
You must be a mere troll.

https://github.com/plolcott/x86utm/blob/master/Halt7.c

u32 Add3(u32 x)
{ return x + 3;
}

int main()
{ Output((char*)"Input_Halts = ", H((ptr)Add3, (ptr)8));
}

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

On 1/2/24 19:56, olcott wrote:
>>
>> The halting question is not self-referential.
>
> int D(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return Halt_Status;
> }
>
> void main()
> {
>   H(D,D);
> }
>
> That D contradicts both values that H returns proves
> that H/D is self-referential.
>

H only returns one value

On 1/2/24 19:59, olcott wrote:
> On 1/2/2024 12:09 PM, immibis wrote:
>> On 1/2/24 19:08, olcott wrote:
>>> On 1/2/2024 9:33 AM, immibis wrote:
>>>>
>>>> H is an incorrect simulator because it assumes that H does not halt
>>>> although H halts.
>>>  > D has a verifiably different execution trace for H(D,D)
>>> than it has for H1(D,D).
>>>
>>
>> This sentence violates linguistics. There is no such thing as "an
>> execution trade for D for H(D,D)" and "an execution trade for D for
>> H1(D,D)"
>>
>
> You can't even get the word right: "execution trace".
>
Must have some type of mental auto-correct enabled. No matter. There's
still no such thing as "an execution trace of D for H(D,D)". That isn't
something that exists. There's an execution trace of D, and there are
incorrect simulations of it which do not correspond to the execution trace.

On 1/2/24 20:07, olcott wrote:
> On 1/2/2024 12:18 PM, immibis wrote:
>> On 1/2/24 19:12, olcott wrote:
>>> On 1/2/2024 9:34 AM, immibis wrote:
>>>> On 1/2/24 05:23, olcott wrote:
>>>>>
>>>>> *There is a subtlety that you are missing*
>>>>>
>>>>> A program only halts when it reaches its
>>>>> own final state and terminates normally.
>>>>> *This is impossible for the D of H/D*
>>>>>
>>>>
>>>> No programs halt. Proof:
>>>>
>>>> bool halts(ptr program, ptr input) {
>>>>      begin_simulation(program, input);
>>>>      abort_simulation();
>>>>      return false;
>>>> }
>>>
>>> Ridiculous nonsense.
>>>
>>
>> program correctly simulated by halts cannot possibly reach past its
>> own line 1.
>
> I don't understand why you are motivated to say
> things that are very obviously counter-factual.
> You must be a mere troll.
>
> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>
> u32 Add3(u32 x)
> {
>   return x + 3;
> }
>
> int main()
> {
>   Output((char*)"Input_Halts = ", H((ptr)Add3, (ptr)8));
> }
>

It is impossible for the correct simulation of halts(Add3,8) to reach
the return instruction, so it doesn't halt.

On 1/2/24 1:08 PM, olcott wrote:
> On 1/2/2024 9:33 AM, immibis wrote:
>> On 1/2/24 05:21, olcott wrote:
>>> On 1/1/2024 9:57 PM, immibis wrote:
>>>> On 1/2/24 02:27, olcott wrote:
>>>>> On 1/1/2024 5:34 PM, immibis wrote:
>>>>>> On 12/29/23 16:33, olcott wrote:
>>>>>>>
>>>>>>> This is the actual x86utm operating system that I wrote
>>>>>>> based on an open source x86 emulator.
>>>>>>>
>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>
>>>>>>
>>>>>> As we discussed on Stack Overflow, this has a bug that causes
>>>>>> incorrect simulation.
>>>>>
>>>>> There is no bug that anyone can report because there is no bug.
>>>>> Also you just admitted that there is no bug in your other reply.
>>>>> *D simulated by H cannot possibly terminate normally*
>>>>>
>>>>
>>>> My other answer is about a simulating halt decider, not your halt
>>>> decider.
>>>
>>> H <is> a fully operational simulating termination analyzer
>>> on a subset of all inputs.
>>>
>>
>> H is an incorrect simulator because it assumes that H does not halt
>> although H halts.
>
> D has a verifiably different execution trace for H(D,D)
> than it has for H1(D,D).

The show the ACTUAL CORRECT trace where it differs.

Note, this means you need to actually simulate what H does when D calls
it, not just hypotocate a behavior that doesn't match what H actually does.

>
> The outer recursive simulation of D by H1(D,D) need
> not abort its simulation because the inner simulation
> of D by H(D,D) aborts its simulation of its different D.
>
> The inner and outer D are different instances of D thus
> actually do not have the same behavior.
>

And H1 shows therefore that a "correct simulation" of the input halts,
and H didn't actually see anything different up to the point that it
aborted its simulation.

H makes the error in presuming a behavior of the H it sees that isn't
actually the behavior of H.

And your last statement means you think that the two copies of the exact
same code, given the exact same input can result in different behavior.

What is the first instruction executed that acted diffferently? (Note,
having its simulation aborted at a point is NOT a difference of behavior
of the actual program.

All you are doing is proving you are just a pathological liar.

On 1/2/24 1:12 PM, olcott wrote:
> On 1/2/2024 9:34 AM, immibis wrote:
>> On 1/2/24 05:23, olcott wrote:
>>> On 1/1/2024 9:58 PM, immibis wrote:
>>>> On 1/2/24 02:19, olcott wrote:
>>>>> On 1/1/2024 5:33 PM, immibis wrote:
>>>>>> On 12/29/23 16:29, olcott wrote:
>>>>>>>
>>>>>>> *Execution Trace*
>>>>>>> Line 14: main() invokes H(D,D);
>>>>>>>
>>>>>>> *keeps repeating* (unless aborted)
>>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>>
>>>>>>> *Simulation invariant*
>>>>>>> D correctly simulated by H cannot possibly reach past its own
>>>>>>> line 06.
>>>>>>>
>>>>>>
>>>>>> *Actual result*
>>>>>> The simulation runs forever because there is no point where the
>>>>>> simulation can stop.
>>>>>
>>>>> Thus aborting the simulation and reporting non-halting is the correct
>>>>> answer.
>>>>>
>>>>
>>>> If the simulation aborts then it halts.
>>>
>>> *There is a subtlety that you are missing*
>>>
>>> A program only halts when it reaches its
>>> own final state and terminates normally.
>>> *This is impossible for the D of H/D*
>>>
>>
>> No programs halt. Proof:
>>
>> bool halts(ptr program, ptr input) {
>>      begin_simulation(program, input);
>>      abort_simulation();
>>      return false;
>> }
>
> Ridiculous nonsense.
>

So, you agree that premature aborting doesn't make a program non-halting.

Thus, H is just wrong, as its input, when fully simulated does halt, it
just that H can't do it.

You are just proving yourself to be the lying idiot.

On 1/2/2024 2:30 PM, immibis wrote:
> On 1/2/24 19:56, olcott wrote:
>>>
>>> The halting question is not self-referential.
>>
>> int D(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return Halt_Status;
>> }
>>
>> void main()
>> {
>>    H(D,D);
>> }
>>
>> That D contradicts both values that H returns proves
>> that H/D is self-referential.
>>
>
> H only returns one value

Of every possible H that can possibly exist for the
above D no H can possibly return any value corresponding
to the behavior of the direct execution of D(D).

This makes the question:
Does the directly executed D(D) halt?
an incorrect question for H.

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