On 1/17/2024 5:40 AM, immibis wrote:
> On 1/17/24 02:22, olcott wrote:
>> On 1/16/2024 6:11 PM, immibis wrote:
>>> On 1/16/24 16:54, olcott wrote:
>>>> On 1/16/2024 1:54 AM, immibis wrote:
>>>>> On 1/16/24 01:05, olcott wrote:
>>>>>>
>>>>>> The inner simulations never have enough information to abort.
>>>>>
>>>>> They would if you didn't abort them.
>>>>
>>>> The inner simulations are one recursive simulation away from
>>>> the next outer simulation.
>>>>
>>>> This means that the outermost simulation always has one
>>>> recursive simulation more execution trace data than any
>>>> inner simulation.
>>>>
>>>> The outermost simulation reaches its abort criteria one
>>>> recursive simulation sooner than the next inner one.
>>>>
>>>
>>> The ONLY reason the inner simulation doesn't abort is that the outer
>>> simulation aborts first.
>>>
>>> If the outer simulation didn't abort the inner simulation would abort.
>>
>> You simply don't understand these things well enough.
>>
> I understand perfectly, and you understand nothing.
>
> If the only reason a simulation doesn't reach a final state is that the
> simulation is aborted,

*THAT IS NOT THE ONLY REASON, THUS PROVING YOU ARE CLUELESS*

> the correct return value from the halting decider
> is 1.

--
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/17/24 16:05, olcott wrote:
> On 1/17/2024 5:40 AM, immibis wrote:
>> On 1/17/24 02:22, olcott wrote:
>>> On 1/16/2024 6:11 PM, immibis wrote:
>>>> On 1/16/24 16:54, olcott wrote:
>>>>> On 1/16/2024 1:54 AM, immibis wrote:
>>>>>> On 1/16/24 01:05, olcott wrote:
>>>>>>>
>>>>>>> The inner simulations never have enough information to abort.
>>>>>>
>>>>>> They would if you didn't abort them.
>>>>>
>>>>> The inner simulations are one recursive simulation away from
>>>>> the next outer simulation.
>>>>>
>>>>> This means that the outermost simulation always has one
>>>>> recursive simulation more execution trace data than any
>>>>> inner simulation.
>>>>>
>>>>> The outermost simulation reaches its abort criteria one
>>>>> recursive simulation sooner than the next inner one.
>>>>>
>>>>
>>>> The ONLY reason the inner simulation doesn't abort is that the outer
>>>> simulation aborts first.
>>>>
>>>> If the outer simulation didn't abort the inner simulation would abort.
>>>
>>> You simply don't understand these things well enough.
>>>
>> I understand perfectly, and you understand nothing.
>>
>> If the only reason a simulation doesn't reach a final state is that
>> the simulation is aborted,
>
> *THAT IS NOT THE ONLY REASON, THUS PROVING YOU ARE CLUELESS*

It is the only reason, thus proving you are clueless.

>
>> the correct return value from the halting decider is 1.
>

On 1/17/24 16:02, olcott wrote:
> On 1/17/2024 5:40 AM, immibis wrote:
>> On 1/17/24 03:36, Richard Damon wrote:
>>>
>>> No, YOU don't understand that the problem is about the ACTUAL
>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>
>>> The machine that is being simulated, has a D that calls an H(D,D)
>>> that aborts its simulation and returns to D.
>>>
>>> The H sees its input call H(D,D) and gives up at that point with bad
>>> logic, and thus gets the wrong answer.
>>>
>>> It doesn't matter that the simulation never got to that point, what
>>> matters is what the real machine does, and since it reaches the final
>>> state, that is what matters.
>>>
>>> You are just stuck in your fantasy world.
>>
>> Very good way to put it. The halting problem is about whether or not
>> the direct execution halts. Anything else is dishonest.
>
> If that was true then the halting problem is about D incorrectly
> simulated by H such that H simulates instructions that are not in D
> or H does not simulate instruction that are in D.

The halting problem is about whether or not the direct execution halts.
Anything else is dishonest.

On 1/17/2024 9:46 AM, immibis wrote:
> On 1/17/24 16:02, olcott wrote:
>> On 1/17/2024 5:40 AM, immibis wrote:
>>> On 1/17/24 03:36, Richard Damon wrote:
>>>>
>>>> No, YOU don't understand that the problem is about the ACTUAL
>>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>>
>>>> The machine that is being simulated, has a D that calls an H(D,D)
>>>> that aborts its simulation and returns to D.
>>>>
>>>> The H sees its input call H(D,D) and gives up at that point with bad
>>>> logic, and thus gets the wrong answer.
>>>>
>>>> It doesn't matter that the simulation never got to that point, what
>>>> matters is what the real machine does, and since it reaches the
>>>> final state, that is what matters.
>>>>
>>>> You are just stuck in your fantasy world.
>>>
>>> Very good way to put it. The halting problem is about whether or not
>>> the direct execution halts. Anything else is dishonest.
>>
>> If that was true then the halting problem is about D incorrectly
>> simulated by H such that H simulates instructions that are not in D
>> or H does not simulate instruction that are in D.
>
> The halting problem is about whether or not the direct execution halts.
> Anything else is dishonest.

Just like ZFC corrected the faulty definition of {set}
to eliminate the undecidability of Russell's Paradox
this correction to the definition of the halting problem:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate
normally.

*Eliminates the undecidability of the halting problem*

--
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/17/24 17:16, olcott wrote:
> On 1/17/2024 9:46 AM, immibis wrote:
>> On 1/17/24 16:02, olcott wrote:
>>> On 1/17/2024 5:40 AM, immibis wrote:
>>>> On 1/17/24 03:36, Richard Damon wrote:
>>>>>
>>>>> No, YOU don't understand that the problem is about the ACTUAL
>>>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>>>
>>>>> The machine that is being simulated, has a D that calls an H(D,D)
>>>>> that aborts its simulation and returns to D.
>>>>>
>>>>> The H sees its input call H(D,D) and gives up at that point with
>>>>> bad logic, and thus gets the wrong answer.
>>>>>
>>>>> It doesn't matter that the simulation never got to that point, what
>>>>> matters is what the real machine does, and since it reaches the
>>>>> final state, that is what matters.
>>>>>
>>>>> You are just stuck in your fantasy world.
>>>>
>>>> Very good way to put it. The halting problem is about whether or not
>>>> the direct execution halts. Anything else is dishonest.
>>>
>>> If that was true then the halting problem is about D incorrectly
>>> simulated by H such that H simulates instructions that are not in D
>>> or H does not simulate instruction that are in D.
>>
>> The halting problem is about whether or not the direct execution
>> halts. Anything else is dishonest.
>
> Just like ZFC corrected the faulty definition of {set}
> to eliminate the undecidability of Russell's Paradox
> this correction to the definition of the halting problem:
>
> In computability theory, the halting problem is the problem of
> determining, whether an input finite string pair of program/input
> specifies a computation that would reach a final state and terminate
> normally.

Yes, the halting problem is about whether or not the direct execution
reaches a final state and terminates normally.

>
> *Eliminates the undecidability of the halting problem*
>

On 1/17/24 11:16 AM, olcott wrote:
> On 1/17/2024 9:46 AM, immibis wrote:
>> On 1/17/24 16:02, olcott wrote:
>>> On 1/17/2024 5:40 AM, immibis wrote:
>>>> On 1/17/24 03:36, Richard Damon wrote:
>>>>>
>>>>> No, YOU don't understand that the problem is about the ACTUAL
>>>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>>>
>>>>> The machine that is being simulated, has a D that calls an H(D,D)
>>>>> that aborts its simulation and returns to D.
>>>>>
>>>>> The H sees its input call H(D,D) and gives up at that point with
>>>>> bad logic, and thus gets the wrong answer.
>>>>>
>>>>> It doesn't matter that the simulation never got to that point, what
>>>>> matters is what the real machine does, and since it reaches the
>>>>> final state, that is what matters.
>>>>>
>>>>> You are just stuck in your fantasy world.
>>>>
>>>> Very good way to put it. The halting problem is about whether or not
>>>> the direct execution halts. Anything else is dishonest.
>>>
>>> If that was true then the halting problem is about D incorrectly
>>> simulated by H such that H simulates instructions that are not in D
>>> or H does not simulate instruction that are in D.
>>
>> The halting problem is about whether or not the direct execution
>> halts. Anything else is dishonest.
>
> Just like ZFC corrected the faulty definition of {set}
> to eliminate the undecidability of Russell's Paradox
> this correction to the definition of the halting problem:
>
> In computability theory, the halting problem is the problem of
> determining, whether an input finite string pair of program/input
> specifies a computation that would reach a final state and terminate
> normally.
>
> *Eliminates the undecidability of the halting problem*
>

Nope. Just an admittion that you are a liar.

Note, it has been shown that the actual input D based on the decider H
that you claim is correct when given that D converted to a finite string
that fully represents it in saying it is non-halting, is given to ans
actual correct simulator (which by definition doesn't abort its
simulation) or directly run, will halt.

Your dishonest dodge of looking at a different finite string that uses a
different H is just proven to be what it is, a dishonest dodge that
prove you to be a stupid liar.

On 1/17/24 10:02 AM, olcott wrote:
> On 1/17/2024 5:40 AM, immibis wrote:
>> On 1/17/24 03:36, Richard Damon wrote:
>>>
>>> No, YOU don't understand that the problem is about the ACTUAL
>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>
>>> The machine that is being simulated, has a D that calls an H(D,D)
>>> that aborts its simulation and returns to D.
>>>
>>> The H sees its input call H(D,D) and gives up at that point with bad
>>> logic, and thus gets the wrong answer.
>>>
>>> It doesn't matter that the simulation never got to that point, what
>>> matters is what the real machine does, and since it reaches the final
>>> state, that is what matters.
>>>
>>> You are just stuck in your fantasy world.
>>
>> Very good way to put it. The halting problem is about whether or not
>> the direct execution halts. Anything else is dishonest.
>
> If that was true then the halting problem is about D incorrectly
> simulated by H such that H simulates instructions that are not in D
> or H does not simulate instruction that are in D.

No, the Halting Problem is about H trying to figure out what D actual
does, or what an actual correct simulation of the input would do, even
if it can't do that itself.

>
> D correctly simulated by H cannot possibly halt.
> The directly executed D(D) depends on D correctly
> simulated by H aborting its simulation otherwise
> D(D) remains stuck in recursive simulation.

Which is only applicable if H does correctly simulate its input, which
means it can't abort

>
> In other words D(D) only halts because H recognizes
> the D correctly simulated by H DOES NOT HALT.
>

Except you just had two different H's and D's in that sentence, since H
is talking about a DIFFERENT D based on a DIFFERENT H than itself, as
the H that correctly simulates doesn't abort, so can't be this.

You are just admitting that you are just a pathological liar that would
know a true statement if it tried to bite your nose.