// 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 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.

And it's impossible for H to correctly answer all questions.

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.

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.

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.

--
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/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.

--
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/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*

--
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/1/24 8:18 PM, 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.
>

But since the halting question isn't, even if you ERRONEOUSLY think it is.

Your problem is that you think that for a SPECIFIC input D (which means
it was built on a SPECIFIC H) can have multiple answers, because you
don't know the difference between a specific item, and the whole class
of similar thngs.

YOuare just proving your stupidity.

On 1/1/24 8:27 PM, 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*
>

So?

The question is NOT about D simulated by H, but about the actual
behavior of D, or the behavior of an actually correct and complete
simulation of the input.

IF H aborts its simulation, its simulation doesn't meet the requirements
to determine the behavior, so we need to look at an ACTUAL "Correct"
(implying complete) simulation does.

If H DOES abort it simulation and returns the non-halting answer, the
the actual complete simulation will finish, and thus H was wrong.

Its error caused by not meeting its requirements.

On 1/1/24 8:19 PM, 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.
>

Nope.

Since H thus DOES abort its simulation, the actual correct simulation of
this input will halt.

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.

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.

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.

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.

--
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/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.

--
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/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*

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