On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:It does do that and this behavior does specify
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what >>>>>>>>>> would happen in the hypothetical case that a direct execution >>>>>>>>>> is done.
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language
exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual
instructions are actually executed on an actual x86 processor. >>>>>>>>
A termination analyzer has no access to that.
The input is required to be a complete description of the program
that can be used to determine its full behavior. In the case of
DD, that description is the code of the function DD, the code of
the function HHH, and everything that HHH calls down to the OS level. >>>>>
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy for
direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:It does do that and this behavior does specify
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what >>>>>>>>>> would happen in the hypothetical case that a direct execution >>>>>>>>>> is done.
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language
exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual
instructions are actually executed on an actual x86 processor. >>>>>>>>
A termination analyzer has no access to that.
The input is required to be a complete description of the program
that can be used to determine its full behavior. In the case of
DD, that description is the code of the function DD, the code of
the function HHH, and everything that HHH calls down to the OS level. >>>>>
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy for
direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
Alternatively you don't understand this technology
well enough to understand that this requirement
is counter-factual.
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what would >>>>>>>>>> happen in the hypothetical case that a direct execution is done. >>>>>>>>>>
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language
exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual instructions >>>>>>>> are actually executed on an actual x86 processor.
A termination analyzer has no access to that.
The input is required to be a complete description of the program that >>>>>> can be used to determine its full behavior. In the case of DD, that >>>>>> description is the code of the function DD, the code of the function >>>>>> HHH, and everything that HHH calls down to the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy for
direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
On 3/18/2025 8:55 AM, Mikko wrote:
On 2025-03-18 03:29:18 +0000, olcott said:
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what >>>>>>>>>>>> would happen in the hypothetical case that a direct
execution is done.
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language >>>>>>>>>>> exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual
instructions are actually executed on an actual x86 processor. >>>>>>>>>>
A termination analyzer has no access to that.
The input is required to be a complete description of the
program that can be used to determine its full behavior. In the >>>>>>>> case of DD, that description is the code of the function DD, the >>>>>>>> code of the function HHH, and everything that HHH calls down to >>>>>>>> the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy
for direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
A requirement is neither factual nor counter-factual. A requirement
is a predicate that is true for a solution and false for any other
argument.
It might seem that way until you find a contradictory
requirement.
On 3/18/2025 6:38 AM, Richard Damon wrote:
On 3/17/25 11:29 PM, olcott wrote:
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what >>>>>>>>>>>> would happen in the hypothetical case that a direct
execution is done.
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language >>>>>>>>>>> exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual
instructions are actually executed on an actual x86 processor. >>>>>>>>>>
A termination analyzer has no access to that.
The input is required to be a complete description of the
program that can be used to determine its full behavior. In the >>>>>>>> case of DD, that description is the code of the function DD, the >>>>>>>> code of the function HHH, and everything that HHH calls down to >>>>>>>> the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy
for direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
We could say the same about your claim,
Alternatively you don't understand this technology
well enough to understand that this requirement
is counter-factual.
But it isn't, not by the standard definitions, something you don't
understand because of your stupidity,
I am wrong because I am stupid is lame for even 3rd grade children.
On 3/18/2025 4:10 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 04:29 schreef olcott:
On 3/17/2025 8:25 PM, dbush wrote:A counter factual requirement cannot be fulfilled.
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what >>>>>>>>>>>> would happen in the hypothetical case that a direct
execution is done.
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language >>>>>>>>>>> exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual
instructions are actually executed on an actual x86 processor. >>>>>>>>>>
A termination analyzer has no access to that.
The input is required to be a complete description of the
program that can be used to determine its full behavior. In the >>>>>>>> case of DD, that description is the code of the function DD, the >>>>>>>> code of the function HHH, and everything that HHH calls down to >>>>>>>> the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy
for direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
Great so you now understand that halting can never
ever be computed for any input.
On 3/18/2025 6:38 AM, Richard Damon wrote:
On 3/17/25 11:29 PM, olcott wrote:
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what would
happen in the hypothetical case that a direct execution is done. >>>>>>>>>>>>
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language >>>>>>>>>>> exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.
A termination analyzer has no access to that.
The input is required to be a complete description of the program that >>>>>>>> can be used to determine its full behavior. In the case of DD, that >>>>>>>> description is the code of the function DD, the code of the function >>>>>>>> HHH, and everything that HHH calls down to the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy for >>>> direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
We could say the same about your claim,
Alternatively you don't understand this technology
well enough to understand that this requirement
is counter-factual.
But it isn't, not by the standard definitions, something you don't
understand because of your stupidity,
I am wrong because I am stupid is lame for even 3rd grade children.
On 3/18/2025 8:55 AM, Mikko wrote:
On 2025-03-18 03:29:18 +0000, olcott said:
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what would
happen in the hypothetical case that a direct execution is done. >>>>>>>>>>>>
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language >>>>>>>>>>> exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.
A termination analyzer has no access to that.
The input is required to be a complete description of the program that >>>>>>>> can be used to determine its full behavior. In the case of DD, that >>>>>>>> description is the code of the function DD, the code of the function >>>>>>>> HHH, and everything that HHH calls down to the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy for >>>> direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
A requirement is neither factual nor counter-factual. A requirement
is a predicate that is true for a solution and false for any other
argument.
It might seem that way until you find a contradictory
requirement.
On 3/19/2025 4:22 AM, Fred. Zwarts wrote:
Op 19.mrt.2025 om 02:24 schreef olcott:
On 3/18/2025 4:10 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 04:29 schreef olcott:
On 3/17/2025 8:25 PM, dbush wrote:A counter factual requirement cannot be fulfilled.
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine >>>>>>>>>>>>>> what would happen in the hypothetical case that a direct >>>>>>>>>>>>>> execution is done.
It can only do that when it assumes that the behavior >>>>>>>>>>>>> specified by the semantics of its input machine language >>>>>>>>>>>>> exactly matches this behavior. Its only basis is this >>>>>>>>>>>>> input finite string.
i.e. the semantics of the x86 language when those actual >>>>>>>>>>>> instructions are actually executed on an actual x86 processor. >>>>>>>>>>>>
A termination analyzer has no access to that.
The input is required to be a complete description of the
program that can be used to determine its full behavior. In >>>>>>>>>> the case of DD, that description is the code of the function >>>>>>>>>> DD, the code of the function HHH, and everything that HHH
calls down to the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be >>>>>>>> reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy >>>>>> for direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
Great so you now understand that halting can never
ever be computed for any input.
Again no 'yes' or 'no'. But I think it means:
In other words you have never heard of universal
and existential quantifiers and these ideas are
gibberish to you.
So, we agree that the answer on the question: *"Does an algorithm
exist that for all possible inputs returns whether it describes a
halting program in direct execution"* is 'No'?
Correct?
On 3/19/25 11:57 AM, olcott wrote:
On 3/19/2025 4:22 AM, Fred. Zwarts wrote:
Op 19.mrt.2025 om 02:24 schreef olcott:
On 3/18/2025 4:10 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 04:29 schreef olcott:
On 3/17/2025 8:25 PM, dbush wrote:A counter factual requirement cannot be fulfilled.
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what would
happen in the hypothetical case that a direct execution is done.
It can only do that when it assumes that the behavior >>>>>>>>>>>>>> specified by the semantics of its input machine language >>>>>>>>>>>>>> exactly matches this behavior. Its only basis is this >>>>>>>>>>>>>> input finite string.
i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.
A termination analyzer has no access to that.
The input is required to be a complete description of the program that
can be used to determine its full behavior. In the case of DD, that
description is the code of the function DD, the code of the function
HHH, and everything that HHH calls down to the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be >>>>>>>>> reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy for >>>>>>> direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
Great so you now understand that halting can never
ever be computed for any input.
Again no 'yes' or 'no'. But I think it means:
In other words you have never heard of universal
and existential quantifiers and these ideas are
gibberish to you.
It seems you haven't either as you confuse "any" with "all"
On 3/21/2025 9:44 AM, dbush wrote:
On 3/17/2025 11:29 PM, olcott wrote:
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what >>>>>>>>>>>> would happen in the hypothetical case that a direct
execution is done.
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language >>>>>>>>>>> exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual
instructions are actually executed on an actual x86 processor. >>>>>>>>>>
A termination analyzer has no access to that.
The input is required to be a complete description of the
program that can be used to determine its full behavior. In the >>>>>>>> case of DD, that description is the code of the function DD, the >>>>>>>> code of the function HHH, and everything that HHH calls down to >>>>>>>> the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy
for direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
Category error. Requirements can't be false. They can however be
impossible to satisfy.
When the definition of a decider contradicts the definition
of a decider in the same field of inquiry at least one of
them is incorrect.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When HHH computes the mapping from the input finite
string of machine code of DD to the behavior that
this machine code specifies as measured by HHH
emulating DD according to the semantics of the x86
language then DD cannot possibly reach its own
"ret" instruction final state halt.
On 3/21/2025 9:44 AM, dbush wrote:
On 3/17/2025 11:29 PM, olcott wrote:
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what would
happen in the hypothetical case that a direct execution is done. >>>>>>>>>>>>
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language >>>>>>>>>>> exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.
A termination analyzer has no access to that.
The input is required to be a complete description of the program that >>>>>>>> can be used to determine its full behavior. In the case of DD, that >>>>>>>> description is the code of the function DD, the code of the function >>>>>>>> HHH, and everything that HHH calls down to the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy for >>>> direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
Category error. Requirements can't be false. They can however be
impossible to satisfy.
When the definition of a decider contradicts the definition
of a decider in the same field of inquiry at least one of
them is incorrect.
On 3/21/2025 10:00 AM, olcott wrote:
On 3/21/2025 9:44 AM, dbush wrote:
On 3/17/2025 11:29 PM, olcott wrote:
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what would
happen in the hypothetical case that a direct execution is done. >>>>>>>>>>>>>
It can only do that when it assumes that the behavior
specified by the semantics of its input machine language >>>>>>>>>>>> exactly matches this behavior. Its only basis is this
input finite string.
i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.
A termination analyzer has no access to that.
The input is required to be a complete description of the program that
can be used to determine its full behavior. In the case of DD, that >>>>>>>>> description is the code of the function DD, the code of the function >>>>>>>>> HHH, and everything that HHH calls down to the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be
reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy for >>>>> direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
Category error. Requirements can't be false. They can however be
impossible to satisfy.
When the definition of a [HALT decider] contradicts the definition of a
[decider] in the same field of inquiry at least one of them is
incorrect.
On 3/22/2025 9:57 AM, Mikko wrote:
On 2025-03-21 15:25:09 +0000, olcott said:
On 3/21/2025 10:00 AM, olcott wrote:
On 3/21/2025 9:44 AM, dbush wrote:
On 3/17/2025 11:29 PM, olcott wrote:
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine >>>>>>>>>>>>>>> what would happen in the hypothetical case that a direct >>>>>>>>>>>>>>> execution is done.
It can only do that when it assumes that the behavior >>>>>>>>>>>>>> specified by the semantics of its input machine language >>>>>>>>>>>>>> exactly matches this behavior. Its only basis is this >>>>>>>>>>>>>> input finite string.
i.e. the semantics of the x86 language when those actual >>>>>>>>>>>>> instructions are actually executed on an actual x86 processor. >>>>>>>>>>>>>
A termination analyzer has no access to that.
The input is required to be a complete description of the >>>>>>>>>>> program that can be used to determine its full behavior. In >>>>>>>>>>> the case of DD, that description is the code of the function >>>>>>>>>>> DD, the code of the function HHH, and everything that HHH >>>>>>>>>>> calls down to the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be >>>>>>>>> reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy >>>>>>> for direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
Category error. Requirements can't be false. They can however be >>>>> impossible to satisfy.
When the definition of a [HALT decider] contradicts the definition
of a [decider] in the same field of inquiry at least one of them is
incorrect.
No, there is nothing incorrect there. It simply means a halpt decider
is not a decider,
It has always been stipulated that a [halt decider] is a type
of [decider]. This means that every halt decider only has the
behavior that its finite string input specifies as its only basis.
On 3/22/2025 9:57 AM, Mikko wrote:
On 2025-03-21 15:25:09 +0000, olcott said:
On 3/21/2025 10:00 AM, olcott wrote:
On 3/21/2025 9:44 AM, dbush wrote:
On 3/17/2025 11:29 PM, olcott wrote:
On 3/17/2025 8:25 PM, dbush wrote:
On 3/17/2025 9:18 PM, olcott wrote:
On 3/17/2025 7:48 PM, dbush wrote:
On 3/17/2025 8:44 PM, olcott wrote:
On 3/17/2025 7:22 PM, dbush wrote:
On 3/17/2025 8:18 PM, olcott wrote:
On 3/17/2025 7:00 PM, dbush wrote:
On 3/17/2025 7:51 PM, olcott wrote:
On 3/17/2025 5:15 PM, dbush wrote:
On 3/17/2025 6:10 PM, olcott wrote:
The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.
No one claimed it should. What it must do is determine what would
happen in the hypothetical case that a direct execution is done.
It can only do that when it assumes that the behavior >>>>>>>>>>>>>> specified by the semantics of its input machine language >>>>>>>>>>>>>> exactly matches this behavior. Its only basis is this >>>>>>>>>>>>>> input finite string.
i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.
A termination analyzer has no access to that.
The input is required to be a complete description of the program that
can be used to determine its full behavior. In the case of DD, that
description is the code of the function DD, the code of the function
HHH, and everything that HHH calls down to the OS level.
It does do that and this behavior does specify
Halting behavior when executed directly, which is what is to be >>>>>>>>> reported on as per the requirements:
It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.
False. The input finite string is REQUIRED to be a perfect proxy for >>>>>>> direct execution, as per the requirements:
It looks like you simply don't understand that a
counter-factual requirement is necessarily incorrect.
Category error. Requirements can't be false. They can however be >>>>> impossible to satisfy.
When the definition of a [HALT decider] contradicts the definition of a >>>> [decider] in the same field of inquiry at least one of them is
incorrect.
No, there is nothing incorrect there. It simply means a halpt decider
is not a decider,
It has always been stipulated that a [halt decider] is a type
of [decider]. This means that every halt decider only has the
behavior that its finite string input specifies as its only basis.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 157:13:53 |
| Calls: | 12,093 |
| Calls today: | 1 |
| Files: | 15,000 |
| Messages: | 6,517,750 |