On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to the inputOnce we understand that Turing computable functions are only allowed >>>>> to derived their outputs by applying finite string operations toYouy have your words wrong. They are only ABLE to use finite
their inputs then my claim about the behavior of DD that HHH must
report on is completely proven.
algorithms of finite string operations. The problem they need to
solve do not need to be based on that, but on just general mappings
of finite strings to finite strings that might not be described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly executed DD
thus DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. How did youWhen you try to actually show the actual steps instead of being stuck in utterly baseless rebuttal mode YOU FAIL!
think it works?
When any HHH emulates DD according to the finite string transformationYes, where is that line?
rules specified by the x86 language (the line of demarcation between
correct and incorrect emulation) no emulated DD can possibly reach its
final halt state and halt.
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of being stuck in >>> utterly baseless rebuttal mode YOU FAIL!
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to the input >>>>> to HHH(DD) that derive the behavior of of the directly executed DDOnce we understand that Turing computable functions are only allowed >>>>>>> to derived their outputs by applying finite string operations to >>>>>>> their inputs then my claim about the behavior of DD that HHH must >>>>>>> report on is completely proven.Youy have your words wrong. They are only ABLE to use finite
algorithms of finite string operations. The problem they need to
solve do not need to be based on that, but on just general mappings >>>>>> of finite strings to finite strings that might not be described by a >>>>>> finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of
transformation steps to make that mapping.
thus DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. How did you >>>> think it works?
state from the string description of DD?
When any HHH emulates DD according to the finite string transformationYes, where is that line?
rules specified by the x86 language (the line of demarcation between
correct and incorrect emulation) no emulated DD can possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
On 4/25/2025 5:09 PM, joes wrote:
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to the inputOnce we understand that Turing computable functions are only allowed >>>>> to derived their outputs by applying finite string operations to their >>>>> inputs then my claim about the behavior of DD that HHH must report on >>>>> is completely proven.Youy have your words wrong. They are only ABLE to use finite algorithms >>>> of finite string operations. The problem they need to solve do not need >>>> to be based on that, but on just general mappings of finite strings to >>>> finite strings that might not be described by a finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly executed DD thus
DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. How did you
think it works?
When you try to actually show the actual steps
instead of being stuck in utterly baseless rebuttal
mode YOU FAIL!
_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 any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly
reach its final halt state and halt.
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of being stuck in >>> utterly baseless rebuttal mode YOU FAIL!
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to the input >>>>> to HHH(DD) that derive the behavior of of the directly executed DDOnce we understand that Turing computable functions are only allowed >>>>>>> to derived their outputs by applying finite string operations to >>>>>>> their inputs then my claim about the behavior of DD that HHH must >>>>>>> report on is completely proven.Youy have your words wrong. They are only ABLE to use finite
algorithms of finite string operations. The problem they need to
solve do not need to be based on that, but on just general mappings >>>>>> of finite strings to finite strings that might not be described by a >>>>>> finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of
transformation steps to make that mapping.
thus DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. How did you >>>> think it works?
state from the string description of DD?
When any HHH emulates DD according to the finite string transformationYes, where is that line?
rules specified by the x86 language (the line of demarcation between
correct and incorrect emulation) no emulated DD can possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and contradicted >>>>>> by a good proof.
Some people claim that the unsolvability of the halting problem is >>>>>> unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that proof of the
theorem. There are other proofs that you don't even try to refute.
Not at all. You have simply not been paying enough attention.
Once we understand that Turing computable functions are only
allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
Turing Machine Computable Functions are not allowed
to output anything besides the result of applying
finite string transformations to their input.
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of being
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to the >>>>>>> inputOnce we understand that Turing computable functions are only >>>>>>>>> allowedYouy have your words wrong. They are only ABLE to use finite
to derived their outputs by applying finite string operations to >>>>>>>>> their inputs then my claim about the behavior of DD that HHH must >>>>>>>>> report on is completely proven.
algorithms of finite string operations. The problem they need to >>>>>>>> solve do not need to be based on that, but on just general mappings >>>>>>>> of finite strings to finite strings that might not be described >>>>>>>> by a
finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of >>>>>>>> transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly executed DD >>>>>>> thus DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. How
did you
think it works?
stuck in
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string transformation >>>>> rules specified by the x86 language (the line of demarcation between >>>>> correct and incorrect emulation) no emulated DD can possibly reach its >>>>> final halt state and halt.Yes, where is that line?
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
Several C programmer immediately spotted this
and agree to it.
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a halting >>>>>> state from the string description of DD?
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of being
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to >>>>>>>>> the inputOnce we understand that Turing computable functions are only >>>>>>>>>>> allowedYouy have your words wrong. They are only ABLE to use finite >>>>>>>>>> algorithms of finite string operations. The problem they need to >>>>>>>>>> solve do not need to be based on that, but on just general >>>>>>>>>> mappings
to derived their outputs by applying finite string operations to >>>>>>>>>>> their inputs then my claim about the behavior of DD that HHH >>>>>>>>>>> must
report on is completely proven.
of finite strings to finite strings that might not be
described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of >>>>>>>>>> transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly executed DD >>>>>>>>> thus DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. How >>>>>>>> did you
think it works?
stuck in
utterly baseless rebuttal mode YOU FAIL!
When any HHH emulates DD according to the finite stringYes, where is that line?
transformation
rules specified by the x86 language (the line of demarcation between >>>>>>> correct and incorrect emulation) no emulated DD can possibly
reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a function that
has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a halting >>>>>>>>>> state from the string description of DD?
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of being stuck in
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to the inputOnce we understand that Turing computable functions are only allowedYouy have your words wrong. They are only ABLE to use finite >>>>>>>>>>>>>> algorithms of finite string operations. The problem they need to >>>>>>>>>>>>>> solve do not need to be based on that, but on just general mappings
to derived their outputs by applying finite string operations to
their inputs then my claim about the behavior of DD that HHH must
report on is completely proven.
of finite strings to finite strings that might not be described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of >>>>>>>>>>>>>> transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly executed DD
thus DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. How did you
think it works?
utterly baseless rebuttal mode YOU FAIL!
When any HHH emulates DD according to the finite string transformationYes, where is that line?
rules specified by the x86 language (the line of demarcation between
correct and incorrect emulation) no emulated DD can possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a function that has been defined to be
a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
And again you lie by implying that Sipser agrees with you when it has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
I exchanged emails with him about this. He does not agree with anything
substantive that PO has written. I won't quote him, as I don't have >>>> Â > permission, but he was, let's say... forthright, in his reply to me. >>>>
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to, and your posting the above to
imply that he did is a form of lying.
*He agreed to MY meaning of these words*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 27/04/2025 01:22, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of being stuck in
On 4/25/2025 11:54 AM, Richard Damon wrote:Yes, there are, the operations that the processor executes. How did you
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to the inputOnce we understand that Turing computable functions are only allowedYouy have your words wrong. They are only ABLE to use finite >>>>>>>>>>>>>>> algorithms of finite string operations. The problem they need to
to derived their outputs by applying finite string operations to
their inputs then my claim about the behavior of DD that HHH must
report on is completely proven.
solve do not need to be based on that, but on just general mappings
of finite strings to finite strings that might not be described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string transformationYes, where is that line?
rules specified by the x86 language (the line of demarcation between
correct and incorrect emulation) no emulated DD can possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a function that has been defined to be
a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>
And again you lie by implying that Sipser agrees with you when it has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>  > I exchanged emails with him about this. He does not agree with anything
substantive that PO has written. I won't quote him, as I don't have >>>>> Â > permission, but he was, let's say... forthright, in his reply to me. >>>>>
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to, and your posting the above to
imply that he did is a form of lying.
*He agreed to MY meaning of these words*
He most certainly did not! He presumably agreed to what he /thought/ you meant by the words.
Since there is a natural interpretation of those words which would be correct, and relevant to a
discussion concerning a simulating HD, my GUESS would be that he thought that was what you were
saying:Â basically, the D in the quote below is clearly intended to represent *one* *specific* input
whose halt status is being determined, namely the input D.
There is talk of "would never stop running if not aborted", which is saying that if H were replaced
by a UTM (which never aborts its input) THEN UTM(D) WOULD RUN FOREVER. That amounts to the same
thing as saying that H has determined [through examination of its simulation steps] that D does not
halt [when run directly/natively]. Of course if H has determined that D does not halt, there's no
point in simulating further, and H can just decide "non-halting" straight away.
NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some modified version of D that
reflects changes to the embedded copy of modified H internal to D. The role of D in all this is
/data/ viz the string representing the particular D being discussed. The role of H is /code/, H
being the halt decider deciding the input D. D does not change when applying the "simulated D would
never stop unless aborted", or imagining whatever hypothetical changes to H you are thinking of -
only code of H is being (hypothetically) changed.
To apply Sipser's agreed criterion in the case of your HHH/DDD code, HHH would need to simulate DDD
until it determines that UTM(DDD) would never terminate. Then at that point it can stop simulating
and announce non-halting. But your HHH never does determine that, and in fact we know that your
UTM(DDD) DOES halt, same as running DDD directly. So Sipser's agreed criterion does not apply.
Of course, this is just what I imagine Sipser meant. It would be relevant and correct, and Sipser
is a sensible guy, but I don't wouldn't presume to speak on his behalf! Neither should you.
Best just drop all mention of Sipser from your posts, and of others like Hehner who are not here.
Rather than attempting to shut down discussion with a fallacial appeal to authority, just stick to
arguing your own case!
Mike.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
[..snip further appeal to authority fallacy using Ben's words!..]
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of being
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to the >>>>>>> inputOnce we understand that Turing computable functions are only >>>>>>>>> allowedYouy have your words wrong. They are only ABLE to use finite
to derived their outputs by applying finite string operations to >>>>>>>>> their inputs then my claim about the behavior of DD that HHH must >>>>>>>>> report on is completely proven.
algorithms of finite string operations. The problem they need to >>>>>>>> solve do not need to be based on that, but on just general mappings >>>>>>>> of finite strings to finite strings that might not be described >>>>>>>> by a
finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of >>>>>>>> transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly executed DD >>>>>>> thus DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. How
did you
think it works?
stuck in
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string transformation >>>>> rules specified by the x86 language (the line of demarcation between >>>>> correct and incorrect emulation) no emulated DD can possibly reach its >>>>> final halt state and halt.Yes, where is that line?
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
Several C programmer immediately spotted this
and agree to it.
On 4/26/2025 7:35 PM, dbush wrote:
On 4/26/2025 8:22 PM, olcott wrote:
*He agreed to MY meaning of these words*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*and Ben agreed too*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H...
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it
were not halted. That much is a truism.
And again you lie:
You try to get away saying this without even
attempting to point out a mistake is the kind of
*reckless disregard of the truth*
https://www.merriam-webster.com/legal/ reckless%20disregard%20of%20the%20truth#
*that loses libel cases*
On 27/04/2025 01:22, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a >>>>>>>>>>> halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of >>>>>>>>>>>> being stuck in
On 4/25/2025 11:54 AM, Richard Damon wrote:Yes, there are, the operations that the processor executes. >>>>>>>>>>>>> How did you
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied >>>>>>>>>>>>>> to the inputOnce we understand that Turing computable functions are >>>>>>>>>>>>>>>> only allowedYouy have your words wrong. They are only ABLE to use finite >>>>>>>>>>>>>>> algorithms of finite string operations. The problem they >>>>>>>>>>>>>>> need to
to derived their outputs by applying finite string >>>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD that >>>>>>>>>>>>>>>> HHH must
report on is completely proven.
solve do not need to be based on that, but on just >>>>>>>>>>>>>>> general mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>> algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string >>>>>>>>>>>> transformationYes, where is that line?
rules specified by the x86 language (the line of demarcation >>>>>>>>>>>> between
correct and incorrect emulation) no emulated DD can possibly >>>>>>>>>>>> reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a function >>>>>>> that has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And again you lie by implying that Sipser agrees with you when it
has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>  > I exchanged emails with him about this. He does not agree with
anything
substantive that PO has written. I won't quote him, as I don't have >>>>> Â > permission, but he was, let's say... forthright, in his reply to >>>>> me.
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to, and
your posting the above to imply that he did is a form of lying.
*He agreed to MY meaning of these words*
He most certainly did not! He presumably agreed to what he /thought/
you meant by the words.
I don't think that is the shell game. PO really /has/ an H...
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it
were not halted. That much is a truism.
Since there is a natural interpretation of those words which would be correct, and relevant to a discussion concerning a simulating HD, my
GUESS would be that he thought that was what you were saying:
basically, the D in the quote below is clearly intended to represent
*one* *specific* input whose halt status is being determined, namely the input D.
There is talk of "would never stop running if not aborted", which isYes
saying that if H were replaced by a UTM (which never aborts its input)
THEN UTM(D) WOULD RUN FOREVER. That amounts to the same thing as saying that H has determined [through examination of its simulation steps] that
D does not halt
[when run directly/natively].
Of course if H has
determined that D does not halt, there's no point in simulating further,
and H can just decide "non-halting" straight away.
NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some
modified version of D that reflects changes to the embedded copy of
modified H internal to D. The role of D in all this is /data/ viz the string representing the particular D being discussed. The role of H
is /code/, H being the halt decider deciding the input D. D does not
change when applying the "simulated D would never stop unless aborted",
or imagining whatever hypothetical changes to H you are thinking of -
only code of H is being (hypothetically) changed.
To apply Sipser's agreed criterion in the case of your HHH/DDD code, HHH would need to simulate DDD until it determines that UTM(DDD) would never terminate. Then at that point it can stop simulating and announce non- halting.
But your HHH never does determine that, and in fact we know
that your UTM(DDD) DOES halt, same as running DDD directly. So
Sipser's agreed criterion does not apply.
Of course, this is just what I imagine Sipser meant. It would be
relevant and correct, and Sipser is a sensible guy, but I don't wouldn't presume to speak on his behalf! Neither should you.
Best just drop all mention of Sipser from your posts, and of others like Hehner who are not here. Rather than attempting to shut down discussion
with a fallacial appeal to authority, just stick to arguing your own case!
Mike.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
[..snip further appeal to authority fallacy using Ben's words!..]
On 27/04/2025 04:07, Mike Terry wrote:
On 27/04/2025 01:22, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a >>>>>>>>>>>> halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote:When you try to actually show the actual steps instead of >>>>>>>>>>>>> being stuck in
Yes, there are, the operations that the processorOn 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied >>>>>>>>>>>>>>> to the inputOnce we understand that Turing computable functions are >>>>>>>>>>>>>>>>> only allowedYouy have your words wrong. They are only ABLE to use >>>>>>>>>>>>>>>> finite
to derived their outputs by applying finite string >>>>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD >>>>>>>>>>>>>>>>> that HHH must
report on is completely proven.
algorithms of finite string operations. The problem they >>>>>>>>>>>>>>>> need to
solve do not need to be based on that, but on just >>>>>>>>>>>>>>>> general mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>>> algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>
executes. How did you
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string >>>>>>>>>>>>> transformationYes, where is that line?
rules specified by the x86 language (the line of
demarcation between
correct and incorrect emulation) no emulated DD can
possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a
function that has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And again you lie by implying that Sipser agrees with you when it
has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>  > I exchanged emails with him about this. He does not agree with >>>>>> anything
substantive that PO has written. I won't quote him, as I don't >>>>>> haveto me.
permission, but he was, let's say... forthright, in his reply
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to,
and your posting the above to imply that he did is a form of lying.
*He agreed to MY meaning of these words*
He most certainly did not! He presumably agreed to what he /thought/
you meant by the words.
Since there is a natural interpretation of those words which would be
correct, and relevant to a discussion concerning a simulating HD, my
GUESS would be that he thought that was what you were saying:
basically, the D in the quote below is clearly intended to represent
*one* *specific* input whose halt status is being determined, namely
the input D.
There is talk of "would never stop running if not aborted", which is
saying that if H were replaced by a UTM (which never aborts its input)
THEN UTM(D) WOULD RUN FOREVER. That amounts to the same thing as
saying that H has determined [through examination of its simulation
steps] that D does not halt [when run directly/natively]. Of course
if H has determined that D does not halt, there's no point in
simulating further, and H can just decide "non-halting" straight away.
NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some
modified version of D that reflects changes to the embedded copy of
modified H internal to D. The role of D in all this is /data/ viz the
string representing the particular D being discussed. The role of H
is /code/, H being the halt decider deciding the input D. D does not
change when applying the "simulated D would never stop unless
aborted", or imagining whatever hypothetical changes to H you are
thinking of - only code of H is being (hypothetically) changed.
I suppose I should have made this clear, as you get confused by this
point - The TM description D which is not changing, includes the [TM description of the] embedded copy of [original] H. I.e. H without any
of your hypothetical imagined changes.
Much better still, stop imagining hypothetical changes to things and
phrase things by introducing new objects with new names when required,
so that a given name always means the same thing....
For example:Â rather than saying "DDD emulated by HHH cannot return
whatever number of steps HHH simulates from 1 to oo" or whatever, say:
  "suppose HHH_n is a SHD which simulates its corresponding input
DDD_n for
   n steps before aborting. Then for each n, HHH_n does not simulate DDD_n as far as
   DDD_n's return."
That way it's clear that the DDD_n are all different programs, none of
which is simulated to its return statement. The way you say it above
sounds like you have ONE DDD whose simulation never returns however far
it is simulated! That would be a non-halting DDD, but that's not the situation at all. You don't want to invite deliberate confusion, do
you? (Each DDD_n is different, and each /would/ return if simulated further, e.g. perhaps DDD_2 simulated by HHH_100 simulates as far as its final ret and so on.)
Mike.
To apply Sipser's agreed criterion in the case of your HHH/DDD code,
HHH would need to simulate DDD until it determines that UTM(DDD) would
never terminate. Then at that point it can stop simulating and
announce non-halting. But your HHH never does determine that, and in
fact we know that your UTM(DDD) DOES halt, same as running DDD
directly. So Sipser's agreed criterion does not apply.
Of course, this is just what I imagine Sipser meant. It would be
relevant and correct, and Sipser is a sensible guy, but I don't
wouldn't presume to speak on his behalf! Neither should you.
Best just drop all mention of Sipser from your posts, and of others
like Hehner who are not here. Rather than attempting to shut down
discussion with a fallacial appeal to authority, just stick to arguing
your own case!
Mike.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
[..snip further appeal to authority fallacy using Ben's words!..]
On 4/26/2025 7:35 PM, dbush wrote:
On 4/26/2025 8:22 PM, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a >>>>>>>>>>>> halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote:When you try to actually show the actual steps instead of >>>>>>>>>>>>> being stuck in
Yes, there are, the operations that the processorOn 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied >>>>>>>>>>>>>>> to the inputOnce we understand that Turing computable functions are >>>>>>>>>>>>>>>>> only allowedYouy have your words wrong. They are only ABLE to use >>>>>>>>>>>>>>>> finite
to derived their outputs by applying finite string >>>>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD >>>>>>>>>>>>>>>>> that HHH must
report on is completely proven.
algorithms of finite string operations. The problem they >>>>>>>>>>>>>>>> need to
solve do not need to be based on that, but on just >>>>>>>>>>>>>>>> general mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>>> algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>
executes. How did you
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string >>>>>>>>>>>>> transformationYes, where is that line?
rules specified by the x86 language (the line of
demarcation between
correct and incorrect emulation) no emulated DD can
possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a
function that has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And again you lie by implying that Sipser agrees with you when it
has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>  > I exchanged emails with him about this. He does not agree with >>>>>> anything
substantive that PO has written. I won't quote him, as I don't >>>>>> haveto me.
permission, but he was, let's say... forthright, in his reply
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to,
and your posting the above to imply that he did is a form of lying.
*He agreed to MY meaning of these words*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
And again you lie:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
I exchanged emails with him about this. He does not agree withanything
substantive that PO has written. I won't quote him, as I don't have
permission, but he was, let's say... forthright, in his reply to me.
He did not have the time to even understand
the notion of recursive simulation so he did
not have the time to see the deeper meaning
of my words.
He would agree with me on what correct emulation
means thus his above quoted words to prove that
HHH is correct to reject DD as non-halting.
He never looked at DD specifically. He did not
have the time for this.
On 4/26/2025 9:55 PM, dbush wrote:
On 4/26/2025 10:19 PM, olcott wrote:
On 4/26/2025 7:35 PM, dbush wrote:
On 4/26/2025 8:22 PM, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>> until H correctly determines that its *simulated D would never* >>>>>>>>> *stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And again you lie by implying that Sipser agrees with you when >>>>>>>> it has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>>>  > I exchanged emails with him about this. He does not agree
with anything
substantive that PO has written. I won't quote him, as Idon't have
me.permission, but he was, let's say... forthright, in hisreply to
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to,
and your posting the above to imply that he did is a form of lying. >>>>>>
Let the record show that the above was trimmed from the original
reply, signaling your intent to lie about what was stated.
*He agreed to MY meaning of these words*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
*and Ben agreed too*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H...
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it
were not halted. That much is a truism.
He agreed that your H satisfies your made-up criteria that has nothing
to do with the halting problem criteria:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
Ridiculously stupid trollish reply within the
context that HHH(DD) must apply the finite string
transformation rules specified by the x86 language
to its input DD and this cannot possibly derive
the behavior of the directly executed DD.
On 4/26/2025 9:07 PM, Richard Damon wrote:
On 4/26/25 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of being >>>>>>>>> stuck in
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to >>>>>>>>>>> the inputOnce we understand that Turing computable functions are >>>>>>>>>>>>> only allowedYouy have your words wrong. They are only ABLE to use finite >>>>>>>>>>>> algorithms of finite string operations. The problem they >>>>>>>>>>>> need to
to derived their outputs by applying finite string
operations to
their inputs then my claim about the behavior of DD that >>>>>>>>>>>>> HHH must
report on is completely proven.
solve do not need to be based on that, but on just general >>>>>>>>>>>> mappings
of finite strings to finite strings that might not be
described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite
algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly
executed DD
thus DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. >>>>>>>>>> How did you
think it works?
utterly baseless rebuttal mode YOU FAIL!
halting
state from the string description of DD?
When any HHH emulates DD according to the finite stringYes, where is that line?
transformation
rules specified by the x86 language (the line of demarcation >>>>>>>>> between
correct and incorrect emulation) no emulated DD can possibly >>>>>>>>> reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a function
that has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
No, because the HHH that DD calls DOES abort, so "unless" isn't a
valid word here.
Then why did Professor Sipser and Ben agree to it?
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its *simulated D would never*
   *stop running unless aborted* then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 4/26/2025 10:38 PM, Mike Terry wrote:
On 27/04/2025 04:07, Mike Terry wrote:
On 27/04/2025 01:22, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving >>>>>>>>>>>>> a halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote:When you try to actually show the actual steps instead of >>>>>>>>>>>>>> being stuck in
Yes, there are, the operations that the processor >>>>>>>>>>>>>>> executes. How did youOn 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be >>>>>>>>>>>>>>>> applied to the inputOnce we understand that Turing computable functions >>>>>>>>>>>>>>>>>> are only allowedYouy have your words wrong. They are only ABLE to use >>>>>>>>>>>>>>>>> finite
to derived their outputs by applying finite string >>>>>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD >>>>>>>>>>>>>>>>>> that HHH must
report on is completely proven.
algorithms of finite string operations. The problem >>>>>>>>>>>>>>>>> they need to
solve do not need to be based on that, but on just >>>>>>>>>>>>>>>>> general mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>>>> algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>>
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string >>>>>>>>>>>>>> transformationYes, where is that line?
rules specified by the x86 language (the line of
demarcation between
correct and incorrect emulation) no emulated DD can >>>>>>>>>>>>>> possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a
function that has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never* >>>>>>>> *stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And again you lie by implying that Sipser agrees with you when it >>>>>>> has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>>  > I exchanged emails with him about this. He does not agree with >>>>>>> anything
substantive that PO has written. I won't quote him, as I don't >>>>>>> have
permission, but he was, let's say... forthright, in his reply >>>>>>> to me.
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to,
and your posting the above to imply that he did is a form of lying.
*He agreed to MY meaning of these words*
He most certainly did not! He presumably agreed to what he /thought/
you meant by the words.
Since there is a natural interpretation of those words which would be
correct, and relevant to a discussion concerning a simulating HD, my
GUESS would be that he thought that was what you were saying:
basically, the D in the quote below is clearly intended to represent
*one* *specific* input whose halt status is being determined, namely
the input D.
There is talk of "would never stop running if not aborted", which is
saying that if H were replaced by a UTM (which never aborts its
input) THEN UTM(D) WOULD RUN FOREVER. That amounts to the same thing
as saying that H has determined [through examination of its
simulation steps] that D does not halt [when run directly/natively].
Of course if H has determined that D does not halt, there's no point
in simulating further, and H can just decide "non-halting" straight
away.
NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some
modified version of D that reflects changes to the embedded copy of
modified H internal to D. The role of D in all this is /data/ viz
the string representing the particular D being discussed. The role
of H is /code/, H being the halt decider deciding the input D. D
does not change when applying the "simulated D would never stop
unless aborted", or imagining whatever hypothetical changes to H you
are thinking of - only code of H is being (hypothetically) changed.
I suppose I should have made this clear, as you get confused by this
point - The TM description D which is not changing, includes the [TM
description of the] embedded copy of [original] H. I.e. H without any
of your hypothetical imagined changes.
Much better still, stop imagining hypothetical changes to things and
phrase things by introducing new objects with new names when required,
so that a given name always means the same thing....
For example:Â rather than saying "DDD emulated by HHH cannot return
whatever number of steps HHH simulates from 1 to oo" or whatever, say:
   "suppose HHH_n is a SHD which simulates its corresponding input
DDD_n for
    n steps before aborting. Then for each n, HHH_n does not
simulate DDD_n as far as
    DDD_n's return."
That way it's clear that the DDD_n are all different programs, none of
which is simulated to its return statement. The way you say it above
sounds like you have ONE DDD whose simulation never returns however
far it is simulated! That would be a non-halting DDD, but that's not
the situation at all. You don't want to invite deliberate confusion,
do you? (Each DDD_n is different, and each /would/ return if
simulated further, e.g. perhaps DDD_2 simulated by HHH_100 simulates
as far as its final ret and so on.)
Mike.
People proved to fail to NOT comprehend it when it is
said that way. They get stuck in a shell game.
*This is a better way to say that*
∄HHH ∈ X86 emulators that emulate 0 to ∞ steps of DD |
(DD emulated by HHH reaches its own final halt state)
The category of correct emulator HHH where DD is emulated
by HHH and the emulated DD reaches its final halt state
DOES NOT EXIST.
To apply Sipser's agreed criterion in the case of your HHH/DDD code,
HHH would need to simulate DDD until it determines that UTM(DDD)
would never terminate. Then at that point it can stop simulating and
announce non-halting. But your HHH never does determine that, and in
fact we know that your UTM(DDD) DOES halt, same as running DDD
directly. So Sipser's agreed criterion does not apply.
Of course, this is just what I imagine Sipser meant. It would be
relevant and correct, and Sipser is a sensible guy, but I don't
wouldn't presume to speak on his behalf! Neither should you.
Best just drop all mention of Sipser from your posts, and of others
like Hehner who are not here. Rather than attempting to shut down
discussion with a fallacial appeal to authority, just stick to
arguing your own case!
Mike.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
[..snip further appeal to authority fallacy using Ben's words!..]
On 4/26/2025 10:07 PM, Mike Terry wrote:
On 27/04/2025 01:22, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a >>>>>>>>>>>> halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote:When you try to actually show the actual steps instead of >>>>>>>>>>>>> being stuck in
Yes, there are, the operations that the processorOn 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied >>>>>>>>>>>>>>> to the inputOnce we understand that Turing computable functions are >>>>>>>>>>>>>>>>> only allowedYouy have your words wrong. They are only ABLE to use >>>>>>>>>>>>>>>> finite
to derived their outputs by applying finite string >>>>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD >>>>>>>>>>>>>>>>> that HHH must
report on is completely proven.
algorithms of finite string operations. The problem they >>>>>>>>>>>>>>>> need to
solve do not need to be based on that, but on just >>>>>>>>>>>>>>>> general mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>>> algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>
executes. How did you
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string >>>>>>>>>>>>> transformationYes, where is that line?
rules specified by the x86 language (the line of
demarcation between
correct and incorrect emulation) no emulated DD can
possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a
function that has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And again you lie by implying that Sipser agrees with you when it
has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>  > I exchanged emails with him about this. He does not agree with >>>>>> anything
substantive that PO has written. I won't quote him, as I don't >>>>>> haveto me.
permission, but he was, let's say... forthright, in his reply
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to,
and your posting the above to imply that he did is a form of lying.
*He agreed to MY meaning of these words*
He most certainly did not! He presumably agreed to what he /thought/
you meant by the words.
I know what I meant by my words and rephrased them
so that everyone that says that HHH should report
on the direct execution of DD looks ridiculously foolish.
A Turing Machine computable function is only allowed
to apply the finite string transformation specified by
the x86 language to its input finite string to derive
any outputs including Booleans.
 a function is computable if there exists an algorithm
 that can do the job of the function, i.e. given an input
 of the function domain it can return the corresponding output.
 https://en.wikipedia.org/wiki/Computable_function
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H...
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it
were not halted. That much is a truism.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its simulated D would never
   stop running unless aborted then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
All of the scamming to try to get away with saying the simultion
was incorrect is proven to be bunk.
Since there is a natural interpretation of those words which would be
correct, and relevant to a discussion concerning a simulating HD, my
GUESS would be that he thought that was what you were saying:
basically, the D in the quote below is clearly intended to represent
*one* *specific* input whose halt status is being determined, namely
the input D.
Not at all. That is dumb. Of course I meant every H/D
pair that meets the pattern. H and D are the names of
categorical propositions, AKA the syllogism.
There is talk of "would never stop running if not aborted", which isYes
saying that if H were replaced by a UTM (which never aborts its input)
THEN UTM(D) WOULD RUN FOREVER. That amounts to the same thing as
saying that H has determined [through examination of its simulation
steps] that D does not halt
[when run directly/natively].
No. The finite string transformation rules specified
by the x86 language applied to the input to HHH(DD)
forbid this. If you don't know the x86 language then
just say this, please don't bluff.
Of course if H has determined that D does not halt, there's no point
in simulating further, and H can just decide "non-halting" straight away.
NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some
modified version of D that reflects changes to the embedded copy of
modified H internal to D. The role of D in all this is /data/ viz the
string representing the particular D being discussed. The role of H
is /code/, H being the halt decider deciding the input D. D does not
change when applying the "simulated D would never stop unless
aborted", or imagining whatever hypothetical changes to H you are
thinking of - only code of H is being (hypothetically) changed.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
 int Halt_Status = UTM(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
int main()
{
 UTM(DD);
}
To apply Sipser's agreed criterion in the case of your HHH/DDD code,
HHH would need to simulate DDD until it determines that UTM(DDD) would
never terminate. Then at that point it can stop simulating and
announce non- halting.
DD is emulated by HHH once and then HHH emulates itself
emulating DD at this point HHH has complete proof that DD
would never stop running unless aborted.
I am currently unsure of all of the perfect details
of the proof by mathematical induction.
The induction variable stands for the number of
instructions of DD emulated by HHH. It ends with
the conclusion that an infinite number of instructions
of DD correctly emulated by HHH cannot possibly reach
their own final halt state.
A proof by induction consists of two cases. The first, the base
case, proves the statement for n = 0 without assuming any knowledge
of other cases. The second case, the induction step, proves that
if the statement holds for any given case n = k then it must also
hold for the next case n = k + 1 These two steps establish that the
statement holds for every natural number n. https://en.wikipedia.org/wiki/Mathematical_induction
But your HHH never does determine that, and in fact we know that your
UTM(DDD) DOES halt, same as running DDD directly. So Sipser's agreed
criterion does not apply.
HHH(DD) sees a repeating pattern that cannot possibly
stop running unless aborted.
Of course, this is just what I imagine Sipser meant. It would be
relevant and correct, and Sipser is a sensible guy, but I don't
wouldn't presume to speak on his behalf! Neither should you.
He cannot possibly mean that the correct emulation
of the input to HHH(DD) means anything else besides
applying the finite string transformation rules
specified by the x86 language to the input to HHH(DD).
Best just drop all mention of Sipser from your posts, and of others
like Hehner who are not here. Rather than attempting to shut down
discussion with a fallacial appeal to authority, just stick to arguing
your own case!
Mike.
You cannot correctly point to any mistake to my
Turing Machine computable function specification.
When applied to the x86 language HHH(DD) must emulate
its input according to the finite string transformation
rules of the x86 language. This does include HHH emulating
itself emulating DD.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
[..snip further appeal to authority fallacy using Ben's words!..]
Professor Sipser and Ben do agree. All the nonsense
about correct simulation being the same as direct
execution is proven to be nonsense.
There are no finite string transformation rules specified
by the x86 language that derive the behavior of the directly
executed DD.
Which is just an admission that your HHH's are not actual correct
emulator, and you can only apply that statement in the version of your
claims where you retract your claim about Halt7.c being part of the
system (as then then is one and only one HHH), and thus your DD just is
not a program unless you include HHH as part of it, and thus each is a DIFFFERENT input.
On 4/26/2025 9:55 PM, dbush wrote:
On 4/26/2025 10:19 PM, olcott wrote:
On 4/26/2025 7:35 PM, dbush wrote:
On 4/26/2025 8:22 PM, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>> until H correctly determines that its *simulated D would never* >>>>>>>>> *stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And again you lie by implying that Sipser agrees with you when >>>>>>>> it has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>>>  > I exchanged emails with him about this. He does not agree
with anything
substantive that PO has written. I won't quote him, as Idon't have
me.permission, but he was, let's say... forthright, in hisreply to
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to,
and your posting the above to imply that he did is a form of lying. >>>>>>
Let the record show that the above was trimmed from the original
reply, signaling your intent to lie about what was stated.
*He agreed to MY meaning of these words*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
*and Ben agreed too*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H...
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it
were not halted. That much is a truism.
He agreed that your H satisfies your made-up criteria that has nothing
to do with the halting problem criteria:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
Ridiculously stupid trollish reply within the
context that HHH(DD) must apply the finite string
transformation rules specified by the x86 language
to its input DD and this cannot possibly derive
the behavior of the directly executed DD.
On Sun, 27 Apr 2025 21:06:29 -0400, Richard Damon
<richard@damon-family.org> wrote in <8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>:
Which is just an admission that your HHH's are not actual correct
emulator, and you can only apply that statement in the version of your
claims where you retract your claim about Halt7.c being part of the
system (as then then is one and only one HHH), and thus your DD just is
not a program unless you include HHH as part of it, and thus each is a
DIFFFERENT input.
Sorry to butt in...
Where does one find this Halt7.c?
On 4/26/2025 10:07 PM, Mike Terry wrote:
On 27/04/2025 01:22, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a >>>>>>>>>>>> halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote:When you try to actually show the actual steps instead of >>>>>>>>>>>>> being stuck in
Yes, there are, the operations that the processorOn 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied >>>>>>>>>>>>>>> to the inputOnce we understand that Turing computable functions are >>>>>>>>>>>>>>>>> only allowedYouy have your words wrong. They are only ABLE to use >>>>>>>>>>>>>>>> finite
to derived their outputs by applying finite string >>>>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD >>>>>>>>>>>>>>>>> that HHH must
report on is completely proven.
algorithms of finite string operations. The problem they >>>>>>>>>>>>>>>> need to
solve do not need to be based on that, but on just >>>>>>>>>>>>>>>> general mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>>> algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>
executes. How did you
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string >>>>>>>>>>>>> transformationYes, where is that line?
rules specified by the x86 language (the line of
demarcation between
correct and incorrect emulation) no emulated DD can
possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a
function that has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And again you lie by implying that Sipser agrees with you when it
has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>  > I exchanged emails with him about this. He does not agree with >>>>>> anything
substantive that PO has written. I won't quote him, as I don't >>>>>> haveto me.
permission, but he was, let's say... forthright, in his reply
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to,
and your posting the above to imply that he did is a form of lying.
*He agreed to MY meaning of these words*
He most certainly did not! He presumably agreed to what he /thought/
you meant by the words.
I know what I meant by my words and rephrased them
so that everyone that says that HHH should report
on the direct execution of DD looks ridiculously foolish.
So we agree that no algorithm exists that can determine for all
possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts when
directly executed.
Correct?
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and contradicted >>>>>> by a good proof.
Some people claim that the unsolvability of the halting problem is >>>>>> unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that proof of the
theorem. There are other proofs that you don't even try to refute.
Not at all. You have simply not been paying enough attention.
Once we understand that Turing computable functions are only
allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
Turing Machine Computable Functions are not allowed
to output anything besides the result of applying
finite string transformations to their input.
On 4/27/2025 1:57 PM, dbush wrote:Precious.
On 4/27/2025 2:12 PM, olcott wrote:
On 4/26/2025 9:55 PM, dbush wrote:
On 4/26/2025 10:19 PM, olcott wrote:
On 4/26/2025 7:35 PM, dbush wrote:
On 4/26/2025 8:22 PM, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
</MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>And again you lie by implying that Sipser agrees with you when >>>>>>>>>> it has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse >>>>>>>>>> wrote:
I exchanged emails with him about this. He does not agree >>>>>>>>>> with anythingme.
substantive that PO has written. I won't quote him, as I >>>>>>>>>> don't have
permission, but he was, let's say... forthright, in his >>>>>>>>>>> reply to
I'm sure he understands the notion as a CS prof.That professor Sipser did not have the time to understand the >>>>>>>>> significance of what he agreed to does not entail that he did >>>>>>>>> not agree with my meanings of what he agreed to.
Professor Sipser did not even have the time to understand the >>>>>>>>> notion of recursive emulation. Without this it is impossible to >>>>>>>>> see the significance of my work.
It's unlikely that he agreed to your misinterpretation.Let the record show that the above was trimmed from the originalIn other words, he did not you agree what you think he agreed to, >>>>>>>> and your posting the above to imply that he did is a form of
lying.
reply, signaling your intent to lie about what was stated.
*He agreed to MY meaning of these words*
In fact H does abort, so the hypothetical does not apply. You are*and Ben agreed too*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>> Â > that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were
not halted. That much is a truism.
Until it doesn't anymore.He agreed that your H satisfies your made-up criteria that has
nothing to do with the halting problem criteria:
Both Ben and Professor Sipser agree that HHH(DD)
meet the criteria that derives the conclusion.
PROVEN Simulating halt decider H correctly simulates its input D
until
PROVEN H correctly determines that its simulated D would never stopBut it is aborted!
running unless aborted
THEN HHH can abort its simulation of DD and correctly report that DDNo. Do you think HHH(HHH) halts or not?
specifies a non-halting sequence of configurations.
On Sun, 27 Apr 2025 21:06:29 -0400, Richard Damon
<richard@damon-family.org> wrote in <8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>:
Which is just an admission that your HHH's are not actual correct
emulator, and you can only apply that statement in the version of your
claims where you retract your claim about Halt7.c being part of the
system (as then then is one and only one HHH), and thus your DD just is
not a program unless you include HHH as part of it, and thus each is a
DIFFFERENT input.
Sorry to butt in...
Where does one find this Halt7.c?
On 4/27/2025 1:57 PM, dbush wrote:
On 4/27/2025 2:12 PM, olcott wrote:
On 4/26/2025 9:55 PM, dbush wrote:
On 4/26/2025 10:19 PM, olcott wrote:
On 4/26/2025 7:35 PM, dbush wrote:
On 4/26/2025 8:22 PM, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>>>> until H correctly determines that its *simulated D would never* >>>>>>>>>>> *stop running unless aborted* then
H can abort its simulation of D and correctly report that D >>>>>>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
And again you lie by implying that Sipser agrees with you when >>>>>>>>>> it has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse >>>>>>>>>> wrote:
I exchanged emails with him about this. He does not agree >>>>>>>>>> with anythingme.
substantive that PO has written. I won't quote him, as I >>>>>>>>>> don't have
permission, but he was, let's say... forthright, in his >>>>>>>>>>> reply to
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed
to, and your posting the above to imply that he did is a form of >>>>>>>> lying.
Let the record show that the above was trimmed from the original
reply, signaling your intent to lie about what was stated.
*He agreed to MY meaning of these words*
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
*and Ben agreed too*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H...
(it's trivial to do for this one case) that correctly determines >>>>> Â > that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it
were not halted. That much is a truism.
He agreed that your H satisfies your made-up criteria that has
nothing to do with the halting problem criteria:
Both Ben and Professor Sipser agree that HHH(DD)
meet the criteria that derives the conclusion.
 PROVEN
 Simulating halt decider H correctly simulates its input D until
 PROVEN
 H correctly determines that its simulated D would never stop
 running unless aborted
 THEN
 HHH can abort its simulation of DD and correctly report that DD
 specifies a non-halting sequence of configurations.
On 4/27/2025 1:54 PM, dbush wrote:
On 4/27/2025 2:05 PM, olcott wrote:
On 4/26/2025 7:35 PM, dbush wrote:
On 4/26/2025 8:22 PM, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 4/25/2025 5:09 PM, joes wrote:
Which x86 semantics does a processor violate when deriving >>>>>>>>>>>>>> a haltingAm Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 4/25/25 12:31 PM, olcott wrote:When you try to actually show the actual steps instead of >>>>>>>>>>>>>>> being stuck in
Yes, there are, the operations that the processor >>>>>>>>>>>>>>>> executes. How did youThere are no finite string operations that can be >>>>>>>>>>>>>>>>> applied to the inputOnce we understand that Turing computable functions >>>>>>>>>>>>>>>>>>> are only allowedYouy have your words wrong. They are only ABLE to use >>>>>>>>>>>>>>>>>> finite
to derived their outputs by applying finite string >>>>>>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD >>>>>>>>>>>>>>>>>>> that HHH must
report on is completely proven.
algorithms of finite string operations. The problem >>>>>>>>>>>>>>>>>> they need to
solve do not need to be based on that, but on just >>>>>>>>>>>>>>>>>> general mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>>>>> algorith of
transformation steps to make that mapping. >>>>>>>>>>>>>>>>>>
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>>>
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string >>>>>>>>>>>>>>> transformationYes, where is that line?
rules specified by the x86 language (the line of >>>>>>>>>>>>>>> demarcation between
correct and incorrect emulation) no emulated DD can >>>>>>>>>>>>>>> possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a
function that has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively >>>>>>>>> proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>> until H correctly determines that its *simulated D would never* >>>>>>>>> *stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
And again you lie by implying that Sipser agrees with you when >>>>>>>> it has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>>>  > I exchanged emails with him about this. He does not agree
with anything
substantive that PO has written. I won't quote him, as Idon't have
permission, but he was, let's say... forthright, in his reply >>>>>>>> to me.
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to,
and your posting the above to imply that he did is a form of lying. >>>>>>
*He agreed to MY meaning of these words*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
And again you lie:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
I exchanged emails with him about this. He does not agree withanything
substantive that PO has written. I won't quote him, as I don't have >>>> Â > permission, but he was, let's say... forthright, in his reply to me. >>>>
He did not have the time to even understand
the notion of recursive simulation so he did
not have the time to see the deeper meaning
of my words.
So again, he didn't agree to what you thought he agreed to.
He agreed to my meanings of my words.
He would agree with me on what correct emulation
means thus his above quoted words to prove that
HHH is correct to reject DD as non-halting.
On 4/3/2025 12:25 AM, olcott wrote:
Appeal to authority is an error.c
As with science it is inductively correct.
He never looked at DD specifically. He did not
have the time for this.
On 4/27/2025 2:02 PM, dbush wrote:
On 4/27/2025 3:00 PM, olcott wrote:
On 4/26/2025 9:07 PM, Richard Damon wrote:
On 4/26/25 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a >>>>>>>>>> halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:When you try to actually show the actual steps instead of >>>>>>>>>>> being stuck in
On 4/25/2025 11:54 AM, Richard Damon wrote:
On 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied >>>>>>>>>>>>> to the inputOnce we understand that Turing computable functions are >>>>>>>>>>>>>>> only allowedYouy have your words wrong. They are only ABLE to use finite >>>>>>>>>>>>>> algorithms of finite string operations. The problem they >>>>>>>>>>>>>> need to
to derived their outputs by applying finite string >>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD that >>>>>>>>>>>>>>> HHH must
report on is completely proven.
solve do not need to be based on that, but on just general >>>>>>>>>>>>>> mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>> algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior.
Yes, there are, the operations that the processor executes. >>>>>>>>>>>> How did you
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite stringYes, where is that line?
transformation
rules specified by the x86 language (the line of demarcation >>>>>>>>>>> between
correct and incorrect emulation) no emulated DD can possibly >>>>>>>>>>> reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a function
that has been defined to be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
No, because the HHH that DD calls DOES abort, so "unless" isn't a
valid word here.
Then why did Professor Sipser and Ben agree to it?
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its *simulated D would never* >>>     *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
And *yet again* you lie by implying that Sipser agrees with you when
it has been repeatedly proven that he does not:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
I exchanged emails with him about this. He does not agree withanything
substantive that PO has written. I won't quote him, as I don't have
permission, but he was, let's say... forthright, in his reply to me.
;
Your dishonesty knows no bounds.
His agreement was only needed for the quoted words.
On 4/28/2025 2:33 AM, Richard Heathfield wrote:Yes it can. The input to HHH(DD) is, as it says, DD. HHH does not report whether DD halts.
On 28/04/2025 07:46, Fred. Zwarts wrote:The behavior of the direct execution of DD cannot be derived by applying
So we agree that no algorithm exists that can determine for allCorrect. We can, however, construct such an algorithm just as long as
possible inputs whether the input specifies a program that (according
to the semantics of the machine language) halts when directly
executed. Correct?
we can ignore any input we don't like the look of.
the finite string transformation rules specified by the x86 language to
the input to HHH(DD). This proves that this is the wrong behavior to
measure.
It is the behavior THAT IS derived by applying the finite string transformation rules specified by the x86 language to the input toMore precisely: it is not simulated to halt.
HHH(DD) proves that THE EMULATED DD NEVER HALTS.
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for
all possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts
when directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as
long as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
Let the record show that the above was trimmed from the original
reply, signaling your intent to lie about what was stated.
On 4/28/2025 4:14 AM, Mikko wrote:Yes there is a universally agreed upon definition of TMs. You may pick
On 2025-04-26 15:59:39 +0000, olcott said:
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
Since there is no universally agreed upon definition of the TuringAttempt to deceive by a false claim. The term "computable function" isStrawman deception error of changing the subject away from computableTuring allowed Turing machines to do whatever they can do.Trying to refute. You have not shown any defect in that proof ofNot at all. You have simply not been paying enough attention.
the theorem. There are other proofs that you don't even try to
refute.
Once we understand that Turing computable functions are only allowed
functions.
defined in terms of Turing machines so Turing machines are on topic.
Machine language it is impossible to provide the 100% concrete details
in this Turing Machine language.
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for all
possible inputs whether the input specifies a program that (according
to the semantics of the machine language) halts when directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as long as
we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
On 4/28/2025 10:41 AM, dbush wrote:
On 4/28/2025 11:35 AM, olcott wrote:
On 4/28/2025 10:18 AM, dbush wrote:
On 4/28/2025 11:01 AM, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for all
possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts when
directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as long >>>>>> as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
The assumption that an H exists that meets the below requirements is
false, as shown by Linz and others:
I have just proved that those requirements are stupidly wrong
Category error. The mapping exists
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the
sense that a function is computable if there
exists an algorithm that can do the job of the
function, i.e.
*given an input of the function domain*
*it can return the corresponding output* https://en.wikipedia.org/wiki/Computable_function
There is a mapping from the input to HHH(DD) by applying
the finite string transformation rules specified by the
x86 language to this DD input that derives:
*no correctly emulated DD ever reaches its final halt state*
...
Flibble and I did not solve the Halting Problem
On 4/28/2025 2:58 PM, dbush wrote:
On 4/28/2025 3:45 PM, olcott wrote:
On 4/28/2025 2:07 PM, dbush wrote:
On 4/28/2025 2:58 PM, olcott wrote:
On 4/28/2025 1:46 PM, dbush wrote:
On 4/28/2025 2:30 PM, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:The x86 language is neither here nor there.
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for >>>>>>>>>>> all possible inputs whether the input specifies a program >>>>>>>>>>> that (according to the semantics of the machine language) >>>>>>>>>>> halts when directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as >>>>>>>>>> long as we can ignore any input we don't like the look of. >>>>>>>>>>
The behavior of the direct execution of DD cannot be derived >>>>>>>>> by applying the finite string transformation rules specified >>>>>>>>> by the x86 language to the input to HHH(DD). This proves that >>>>>>>>> this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS. >>>>>>>>
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
And no turing machine exists that can derive the following mapping >>>>>> (i.e. the mapping is not a computable function), as proven by Linz >>>>>> and others:
Because the theory of computation was never previously
elaborated to make it clear that Turing computable
functions are required to derive their output by applying
finite string transformations to their input finite strings.
And no such algorithm can derive this mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
*When we do this then a mapping suddenly appears*
And that mapping is not the halting mapping, therefore the algorithm
is not a halt decider.
DD emulated by HHH according to the finite string
transformation rules of the x86 language DOES NOT HALT.
In other words, HHH doesn't map the halting function.
*a function is computable if there exists an algorithm that can do
the* *job of the function, i.e. given an input of the function
domain it can* *return the corresponding output*.
https://en.wikipedia.org/wiki/Computable_function
And the halting function is not a computable function:
Maybe you have ADD like Richard and can only
pay attention to a point when it is repeated many times
I just proved that your halting function is incorrect.
Category error. The halting function below is fully defined, and this
mapping is not computable *as you have explicitly admitted*.
Neither is the square root of an actual onion computable.
...
Flibble and I did not solve the Halting Problem
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for
all possible inputs whether the input specifies a program
that (according to the semantics of the machine language)
halts when directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as
long as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
The x86 language is neither here nor there.
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output* https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
On 4/28/2025 2:58 PM, dbush wrote:
Category error. The halting function below is fully defined,
and this mapping is not computable *as you have explicitly
admitted*.
Neither is the square root of an actual onion computable.
Turing Computable Functions are required to apply finite
string transformations to their inputs. The function defined
below ignores that requirement PROVING THAT IT IS INCORRECT.
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
Category error. There is no correct answer to "the square root
of an onion"
On 4/28/2025 3:21 PM, Richard Heathfield wrote:
On 28/04/2025 21:03, olcott wrote:
On 4/28/2025 2:58 PM, dbush wrote:
<snip>
Category error. The halting function below is fully defined,
and this mapping is not computable *as you have explicitly
admitted*.
Neither is the square root of an actual onion computable.
Turing Computable Functions are required to apply finite
string transformations to their inputs. The function defined
below ignores that requirement PROVING THAT IT IS INCORRECT.
No, it proves that you agree that it's not a computable
function. QED.
Computing the actual behavior the direct execution
of any input is ALWAYS IMPOSSIBLE.
No halt decider can ever directly see the actual
behavior of any directly executed input.
On 4/26/2025 10:38 PM, Mike Terry wrote:
On 27/04/2025 04:07, Mike Terry wrote:
On 27/04/2025 01:22, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:
On 4/25/2025 5:09 PM, joes wrote:Which x86 semantics does a processor violate when deriving a halting
Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote:When you try to actually show the actual steps instead of being stuck in
Yes, there are, the operations that the processor executes. How did youOn 4/25/25 12:31 PM, olcott wrote:
There are no finite string operations that can be applied to the inputOnce we understand that Turing computable functions are only allowedYouy have your words wrong. They are only ABLE to use finite >>>>>>>>>>>>>>>>> algorithms of finite string operations. The problem they need to
to derived their outputs by applying finite string operations to
their inputs then my claim about the behavior of DD that HHH must
report on is completely proven.
solve do not need to be based on that, but on just general mappings
of finite strings to finite strings that might not be described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of
transformation steps to make that mapping.
to HHH(DD) that derive the behavior of of the directly executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>>
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string transformationYes, where is that line?
rules specified by the x86 language (the line of demarcation between
correct and incorrect emulation) no emulated DD can possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a function that has been defined to
be a specific instance.
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never* >>>>>>>> *stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>>
And again you lie by implying that Sipser agrees with you when it has been proven that he
doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>>  > I exchanged emails with him about this. He does not agree with anything
substantive that PO has written. I won't quote him, as I don't have >>>>>>> Â > permission, but he was, let's say... forthright, in his reply to me.
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to, and your posting the above to
imply that he did is a form of lying.
*He agreed to MY meaning of these words*
He most certainly did not! He presumably agreed to what he /thought/ you meant by the words.
Since there is a natural interpretation of those words which would be correct, and relevant to a
discussion concerning a simulating HD, my GUESS would be that he thought that was what you were
saying: basically, the D in the quote below is clearly intended to represent *one* *specific*
input whose halt status is being determined, namely the input D.
There is talk of "would never stop running if not aborted", which is saying that if H were
replaced by a UTM (which never aborts its input) THEN UTM(D) WOULD RUN FOREVER. That amounts to
the same thing as saying that H has determined [through examination of its simulation steps] that
D does not halt [when run directly/natively]. Of course if H has determined that D does not
halt, there's no point in simulating further, and H can just decide "non-halting" straight away.
NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some modified version of D that
reflects changes to the embedded copy of modified H internal to D. The role of D in all this is
/data/ viz the string representing the particular D being discussed. The role of H is /code/, H
being the halt decider deciding the input D. D does not change when applying the "simulated D
would never stop unless aborted", or imagining whatever hypothetical changes to H you are
thinking of - only code of H is being (hypothetically) changed.
I suppose I should have made this clear, as you get confused by this point - The TM description D
which is not changing, includes the [TM description of the] embedded copy of [original] H. I.e. H
without any of your hypothetical imagined changes.
Much better still, stop imagining hypothetical changes to things and phrase things by introducing
new objects with new names when required, so that a given name always means the same thing....
For example:Â rather than saying "DDD emulated by HHH cannot return whatever number of steps HHH
simulates from 1 to oo" or whatever, say:
   "suppose HHH_n is a SHD which simulates its corresponding input DDD_n for
    n steps before aborting. Then for each n, HHH_n does not simulate DDD_n as far as
    DDD_n's return."
That way it's clear that the DDD_n are all different programs, none of which is simulated to its
return statement. The way you say it above sounds like you have ONE DDD whose simulation never
returns however far it is simulated! That would be a non-halting DDD, but that's not the
situation at all. You don't want to invite deliberate confusion, do you? (Each DDD_n is
different, and each /would/ return if simulated further, e.g. perhaps DDD_2 simulated by HHH_100
simulates as far as its final ret and so on.)
Mike.
People proved to fail to NOT comprehend it when it is
said that way. They get stuck in a shell game.
*This is a better way to say that*
∄HHH ∈ X86 emulators that emulate 0 to ∞ steps of DD |
(DD emulated by HHH reaches its own final halt state)
The category of correct emulator HHH where DD is emulated
by HHH and the emulated DD reaches its final halt state
DOES NOT EXIST.
On 4/28/2025 10:18 AM, dbush wrote:
On 4/28/2025 11:01 AM, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for all
possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts when
directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as long
as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
The assumption that an H exists that meets the below requirements is
false, as shown by Linz and others:
I have just proved that those requirements are stupidly wrong
IT IS UTTERLY MORONIC OR DECEITFUL TO DISAGREE WITH THE X86 LANGUAGE
On 4/28/2025 1:56 PM, dbush wrote:
On 4/28/2025 2:47 PM, olcott wrote:
On 4/28/2025 11:54 AM, dbush wrote:
On 4/28/2025 12:38 PM, olcott wrote:
On 4/28/2025 10:41 AM, dbush wrote:
On 4/28/2025 11:35 AM, olcott wrote:
On 4/28/2025 10:18 AM, dbush wrote:
On 4/28/2025 11:01 AM, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:The assumption that an H exists that meets the below
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for >>>>>>>>>>> all possible inputs whether the input specifies a program >>>>>>>>>>> that (according to the semantics of the machine language) >>>>>>>>>>> halts when directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as >>>>>>>>>> long as we can ignore any input we don't like the look of. >>>>>>>>>>
The behavior of the direct execution of DD cannot be derived >>>>>>>>> by applying the finite string transformation rules specified >>>>>>>>> by the x86 language to the input to HHH(DD). This proves that >>>>>>>>
requirements is false, as shown by Linz and others:
I have just proved that those requirements are stupidly wrong
Category error. The mapping exists
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the
sense that a function is computable if there
exists an algorithm that can do the job of the
function, i.e.
i.e. a computable function is a mathematical mapping for which an
algorithm exists to compute in.
And the halting function below is not a computable function:
It is NEVER a computable function
Let The Record Show:
That Peter Olcott has *explicitly* admitted that the halting function:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
Is not a computable function, as Linz and others have proven, meaning
he has agreed that the Linz halting theorem is *correct*.
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
direct
So what are you doing to do now that you're no longer working on the
halting problem?
The above ignores the requirement that Turing Computable functions
are only allowed to derive their outputs by applying finite string transformations to their inputs.
On 4/28/2025 4:14 AM, Mikko wrote:
On 2025-04-26 15:59:39 +0000, olcott said:
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and
contradicted
by a good proof.
Some people claim that the unsolvability of the halting problem is >>>>>>>> unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that proof of the >>>>>> theorem. There are other proofs that you don't even try to refute.
Not at all. You have simply not been paying enough attention.
Once we understand that Turing computable functions are only
allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
Attempt to deceive by a false claim. The term "computable function" is
defined in terms of Turing machines so Turing machines are on topic.
Since there is no universally agreed upon definition
of the Turing Machine language it is impossible to
provide the 100% concrete details in this Turing
Machine language.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Form bottom of page 2, (encoded more simply) https://www.liarparadox.org/Linz_Proof.pdf
When embedded_H applies the finite string transformation
rules specified by the above template IT IS clear that
the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach is final state
of ⟨Ĥ.qn⟩
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
Because none of the details are shown between state
transitions it is not a clear as the x86 example.
_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 we apply the finite string transformation rules specified
by the x86 language to the input to HHH(DD) WE ONLY GET THAT
DD DOES NOT HALT.
Turing Machine Computable Functions are not allowed
to output anything besides the result of applying
finite string transformations to their input.
A Turing Machine Computable function is allowed and required to output
the value of the function for the given argument and nothing else.
Yes and it must do that by applying finite string
transformation rules to this input.
When we apply the finite string transformation rules specified
by the x86 language to the input to HHH(DD) WE ONLY GET THAT
DD DOES NOT HALT.
On 4/28/2025 11:54 AM, dbush wrote:
On 4/28/2025 12:38 PM, olcott wrote:
On 4/28/2025 10:41 AM, dbush wrote:
On 4/28/2025 11:35 AM, olcott wrote:
On 4/28/2025 10:18 AM, dbush wrote:
On 4/28/2025 11:01 AM, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for all >>>>>>>>> possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts when >>>>>>>>> directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as
long as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
The assumption that an H exists that meets the below requirements
is false, as shown by Linz and others:
I have just proved that those requirements are stupidly wrong
Category error. The mapping exists
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the
sense that a function is computable if there
exists an algorithm that can do the job of the
function, i.e.
i.e. a computable function is a mathematical mapping for which an
algorithm exists to compute in.
And the halting function below is not a computable function:
It is NEVER a computable function because no halt
decider can ever directly see the behavior of
the directly executed DD because this DD IS NOT AN INPUT.
The one that IS AN INPUT SPECIFIES DIFFERENT BEHAVIOR.
I don't understand how you can stupidly disagree with
the x86 language without being a troll having no interest
in truth.
On 4/28/25 11:35 AM, olcott wrote:
On 4/28/2025 10:18 AM, dbush wrote:
On 4/28/2025 11:01 AM, olcott wrote:
The assumption that an H exists that meets the below
requirements is false, as shown by Linz and others:
I have just proved that those requirements are stupidly wrong
IT IS UTTERLY MORONIC OR DECEITFUL TO DISAGREE WITH THE X86
LANGUAGE
No, all you have proved is that you are a stupid liar.
You CLAIM a lot of things, but haven't actually proven anything
you have claimeed.
On 4/28/2025 10:00 PM, dbush wrote:
On 4/28/2025 10:50 PM, olcott wrote:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for all >>>>>>>>> possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts when >>>>>>>>> directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as
long as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
The x86 language is neither here nor there.
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I actually
wrote. I'm not sure you understand what 'reply' means.
Still, I'm prepared to give you another crack at it. Here's what I
wrote before:
What matters is whether a TM can be constructed that can accept an
arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved
that such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Not if it's the behavior of P(D) we want to know about, which it is.
Wanting the square root of a rotten egg would do as well.
When P defines a pathological relationship with H it
is stupidly incorrect to expect the behavior of P to remain the same.
...
Flibble and I did not solve the Halting Problem
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine
for all possible inputs whether the input specifies a
program that (according to the semantics of the machine
language) halts when directly executed.
Correct?
Correct. We can, however, construct such an algorithm just
as long as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER
HALTS.
The x86 language is neither here nor there.
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I
actually wrote. I'm not sure you understand what 'reply' means.
Still, I'm prepared to give you another crack at it. Here's
what I wrote before:
What matters is whether a TM can be constructed that can accept
an arbitrary TM tape P and an arbitrary input tape D and
correctly calculate whether, given D as input, P would halt.
Turing proved that such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Computer science has been wrong about this all of
these years. When I provide the 100% concrete example
of the x86 language there is zero vagueness to slip
through the cracks of understanding.
Even calling the Turing Machine language the Turing
Machine description language make this confusing.
*This is a verified fact*
When DD is emulated by HHH according to the finite
string transformation rules of the x86 language
DD cannot possibly reach its own final state no
matter what HHH does.
Whatever you think you've proved, you haven't solved the
Halting Problem. There are *no* solutions. We know this because
there is a simple well-known proof. So the only way to devise a
solution is to re- define the problem.
It ultimately is only a confused view because key
details about how outputs are made to conform to
inputs:
You aren't paying enough attention because you
are too sure that I am wrong. I proved my point
above.
On 4/28/2025 7:22 PM, Mike Terry wrote:
On 27/04/2025 17:25, olcott wrote:
On 4/26/2025 10:38 PM, Mike Terry wrote:
On 27/04/2025 04:07, Mike Terry wrote:
On 27/04/2025 01:22, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 4/25/2025 5:09 PM, joes wrote:
Which x86 semantics does a processor violate when >>>>>>>>>>>>>>> deriving a haltingAm Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 4/25/25 12:31 PM, olcott wrote:When you try to actually show the actual steps instead >>>>>>>>>>>>>>>> of being stuck in
Yes, there are, the operations that the processor >>>>>>>>>>>>>>>>> executes. How did youThere are no finite string operations that can be >>>>>>>>>>>>>>>>>> applied to the inputOnce we understand that Turing computable functions >>>>>>>>>>>>>>>>>>>> are only allowedYouy have your words wrong. They are only ABLE to use >>>>>>>>>>>>>>>>>>> finite
to derived their outputs by applying finite string >>>>>>>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD >>>>>>>>>>>>>>>>>>>> that HHH must
report on is completely proven.
algorithms of finite string operations. The problem >>>>>>>>>>>>>>>>>>> they need to
solve do not need to be based on that, but on just >>>>>>>>>>>>>>>>>>> general mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>>>>>> algorith of
transformation steps to make that mapping. >>>>>>>>>>>>>>>>>>>
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>>>>
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string >>>>>>>>>>>>>>>> transformationYes, where is that line?
rules specified by the x86 language (the line of >>>>>>>>>>>>>>>> demarcation between
correct and incorrect emulation) no emulated DD can >>>>>>>>>>>>>>>> possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a >>>>>>>>>>> function that has been defined to be a specific instance. >>>>>>>>>>>
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively >>>>>>>>>> proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>>> until H correctly determines that its *simulated D would never* >>>>>>>>>> *stop running unless aborted* then
H can abort its simulation of D and correctly report that D >>>>>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>> 10/13/2022>
And again you lie by implying that Sipser agrees with you when >>>>>>>>> it has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>>>>  > I exchanged emails with him about this. He does not agree >>>>>>>>> with anything
substantive that PO has written. I won't quote him, as I >>>>>>>>> don't havereply to me.
permission, but he was, let's say... forthright, in his
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to, >>>>>>> and your posting the above to imply that he did is a form of lying. >>>>>>>
*He agreed to MY meaning of these words*
He most certainly did not! He presumably agreed to what he /
thought/ you meant by the words.
Since there is a natural interpretation of those words which would
be correct, and relevant to a discussion concerning a simulating
HD, my GUESS would be that he thought that was what you were
saying: basically, the D in the quote below is clearly intended to
represent *one* *specific* input whose halt status is being
determined, namely the input D.
There is talk of "would never stop running if not aborted", which
is saying that if H were replaced by a UTM (which never aborts its
input) THEN UTM(D) WOULD RUN FOREVER. That amounts to the same
thing as saying that H has determined [through examination of its
simulation steps] that D does not halt [when run directly/
natively]. Of course if H has determined that D does not halt,
there's no point in simulating further, and H can just decide "non-
halting" straight away.
NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some
modified version of D that reflects changes to the embedded copy of
modified H internal to D. The role of D in all this is /data/ viz
the string representing the particular D being discussed. The role >>>>> of H is /code/, H being the halt decider deciding the input D. D
does not change when applying the "simulated D would never stop
unless aborted", or imagining whatever hypothetical changes to H
you are thinking of - only code of H is being (hypothetically)
changed.
I suppose I should have made this clear, as you get confused by this
point - The TM description D which is not changing, includes the [TM
description of the] embedded copy of [original] H. I.e. H without
any of your hypothetical imagined changes.
Much better still, stop imagining hypothetical changes to things and
phrase things by introducing new objects with new names when
required, so that a given name always means the same thing....
For example:Â rather than saying "DDD emulated by HHH cannot return
whatever number of steps HHH simulates from 1 to oo" or whatever, say: >>>>
   "suppose HHH_n is a SHD which simulates its corresponding input >>>> DDD_n for
    n steps before aborting. Then for each n, HHH_n does not
simulate DDD_n as far as
    DDD_n's return."
That way it's clear that the DDD_n are all different programs, none
of which is simulated to its return statement. The way you say it
above sounds like you have ONE DDD whose simulation never returns
however far it is simulated! That would be a non-halting DDD, but
that's not the situation at all. You don't want to invite
deliberate confusion, do you? (Each DDD_n is different, and each /
would/ return if simulated further, e.g. perhaps DDD_2 simulated by
HHH_100 simulates as far as its final ret and so on.)
Mike.
People proved to fail to NOT comprehend it when it is
said that way. They get stuck in a shell game.
You often say that you don't express something in a clear way, because
"people get confused" when you say it that way. There is never any
evidence whatsoever that anybody but you is confused about these
points. What you really mean is that when clearly worded your
confusions are more easily seen to be mistakes - which is not in your
interest it seems.
*This is a better way to say that*
∄HHH ∈ X86 emulators that emulate 0 to ∞ steps of DD |
(DD emulated by HHH reaches its own final halt state)
The category of correct emulator HHH where DD is emulated
by HHH and the emulated DD reaches its final halt state
DOES NOT EXIST.
There are a few problems with that wording. :
1)Â The main problem is you are still Using a fixed term DD in a
To refer to a class of computations.
deliberate attempt to suggest there is one single input DD that
however far you simulate it it never halts.
It seems obvious to me that I never said anything like this.
Hey for sure that means DD never halts, right - it's almost the
definition of non-halting! EXCEPT... THERE IS NO SUCH DD. Every HHH
fails to simulate /its corresponding DD/ as far as that DD's halt state,
Because of recursive emulation.
but other simulators can simulate it to its final halt state.
Their input does not have a pathological relationship with them.
That confusion was /the reason/ for my previous post, so for you to
say your wording is better when it ignores that problem is just
nonsense. At best you're just missing the point. I'll say it again:
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
Everyone here has been trying to get away with simply ignoring
the pathological relationship that DD defines with HHH.
You need to make it clear that the DD is dependent on the chosen HHH.
I have slapped people in the face with that for at
least three years.
You might adopt Linz's notation, with a decider HHH having associated
input HHH^, but you would need to explain that notation close to its
use. Better still would be to introduce an operator like
MAKE_NEMESIS , which converts a halt decider H to its nemesis input
MAKE_NEMESIS(H). That seems clearest for emphasising that
MAKE_NEMESIS(HHH) [aka your DD] is a different input for each HHH. Or
(as most maths people would do) just explain clearly in words!
All that we need to know is to correct the gap
in the theory of computation and understand that
Turing Computable functions are requires to derive
their outputs by applying finite string transformations
to their inputs.
When HHH(DD) applies the finite string
transformations specified by the x86
language to its input,THIS INPUT CANNOT
POSSIBLY HALT NO MATTER WHAT HHH DOES.
2) use of "duffer-speak". Duffer-speak is when non-maths people try
to trick readers into thinking they are mathematically literate by
including what they believe is "proper maths notation, like a real
maths person would use". But they lack all understanding of the terms
and when they would actually be used, so the result is an instant
"crank warning" for the reader:
  MAAARP MAAARP MAARP Crank Warning: duffer-speak detected!  :)
Practically everything you say is duffer-speak, so this is not a
problem you can solve in general. But specifically for your "better
wording" example above:
Does this mean that you disagree that Turing
Computable functions must derive outputs by applying
finite string transformations to their inputs ???
- "..that emulate 0 to ∞ steps..". It is not possible for any HHH
to / not/ emulate 0 to ∞ steps, so the phrase should just be omitted
as it adds nothing but potential confusion.
    But I know the real reason you want to keep the phrase is /
because/ it is misleading, again suggesting that there is a single DD
which, no matter how far you simulate it it never halts. As explained
above that is the exact opposite of the actual situation!
What I want to achieve is universal consensus
that HHH is correct to reject DD as not halting.
- Using "silly" maths notation unnecessarily. If you examine maths
texts, you'll see they do not introduce fancy maths notation and
expressions to make simple high level propositions. They explain them
in english. Of course there are some exceptions, but your use of ∄,
∈, and "category" are all examples where it is unnecessary, and
suggest "crank trying to sound how he/she thinks real maths people
talk, so he/ she will be taken more seriously". It has the opposite
effect! Also it's silly using HHH when your other posts already
discuss one specific HHH that you have coded. Why are there 3 Hs?
And 2 Ds?
-------------------
Putting all the above together, how about:
-Â When a simulating halt decider H simulates its corresponding input H^
   [where H^ is constructed from H according to the Linz HP proof
specification],
   H does not simulate H^ as far as H^'s final halt state.
It <IS NOT> that there is something wrong with H.
It has always been that there is something wrong with D.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The simulated ⟨Ĥ⟩ ⟨Ĥ⟩ can never reach its simulated
final state ⟨Ĥ.qn⟩ because it continues to call
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ in recursive emulation.
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
A bit too clear for you I imagine, as there is nothing to mislead
readers into thinking that any particular H^ never halts - only that
its corresponding H never simulates it that far.
The outer H is always one execution trace ahead of the
next inner one. The means that unless the outer H
aborts then none of them do.
Also, everybody here (I believe) understands and agrees with this (or
very similar) wording. Maybe even you agree?? After all, it's just a
rewording of what you said, right?
If you used a similar wording you could stop arguing around points
where everybody agrees, and move on to whatever comes next. But of
course you /want/ the confusion, so will try to claim that /my/
wording confuses people [..because people reading my wording /don't/
get confused in the way that you are.. :) ]
Mike.
On 4/28/2025 10:00 PM, dbush wrote:
On 4/28/2025 10:50 PM, olcott wrote:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine
for all possible inputs whether the input specifies a
program that (according to the semantics of the machine
language) halts when directly executed.
Correct?
Correct. We can, however, construct such an algorithm
just as long as we can ignore any input we don't like the
look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER
HALTS.
The x86 language is neither here nor there.
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I
actually wrote. I'm not sure you understand what 'reply' means.
Still, I'm prepared to give you another crack at it. Here's
what I wrote before:
What matters is whether a TM can be constructed that can
accept an arbitrary TM tape P and an arbitrary input tape D
and correctly calculate whether, given D as input, P would
halt. Turing proved that such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Not if it's the behavior of P(D) we want to know about, which
it is.
Wanting the square root of a rotten egg would do as well.
When P defines a pathological relationship with H it
is stupidly incorrect to expect the behavior of P to remain the
same.
What I want to achieve is universal consensus
that HHH is correct to reject DD as not halting.
On 4/28/2025 3:13 PM, Richard Heathfield wrote:No, H gets P(D) as input, not itself. H is the "measurer", not being
What matters is whether a TM can be constructed that can accept anYet it is H(P,D) and NOT P(D) that must be measured. Computer science
arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved that
such a TM cannot be constructed.
This is what we call the Halting Problem.
has been wrong about this all of these years. When I provide the 100% concrete example of the x86 language there is zero vagueness to slip
through the cracks of understanding.
Even calling the Turing Machine language the Turing Machine description language make this confusing.The what? Who called it that?
*This is a verified fact*DD doesn't do anything, it is just data. HHH is the active part.
When DD is emulated by HHH according to the finite string transformation rules of the x86 language DD cannot possibly reach its own final state
no matter what HHH does.
On 4/28/2025 4:14 AM, Mikko wrote:
On 2025-04-26 15:59:39 +0000, olcott said:
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and contradicted >>>>>>>> by a good proof.
Some people claim that the unsolvability of the halting problem is >>>>>>>> unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that proof of the >>>>>> theorem. There are other proofs that you don't even try to refute.
Not at all. You have simply not been paying enough attention.
Once we understand that Turing computable functions are only
allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
Attempt to deceive by a false claim. The term "computable function" is
defined in terms of Turing machines so Turing machines are on topic.
Since there is no universally agreed upon definition
of the Turing Machine language it is impossible to
provide the 100% concrete details in this Turing
Machine language.
On 4/28/2025 3:21 PM, Richard Heathfield wrote:No, only if the input includes the same simulator. BlooP programs
On 28/04/2025 21:03, olcott wrote:Computing the actual behavior the direct execution of any input is
On 4/28/2025 2:58 PM, dbush wrote:
Category error. The halting function below is fully defined, andNeither is the square root of an actual onion computable.
this mapping is not computable *as you have explicitly admitted*.
Turing Computable Functions are required to apply finite string
transformations to their inputs. The function defined below ignores
that requirement PROVING THAT IT IS INCORRECT.
No, it proves that you agree that it's not a computable function. QED.
ALWAYS IMPOSSIBLE.
No halt decider can ever directly see the actual behavior of any--
directly executed input.
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
On 4/28/2025 10:00 PM, dbush wrote:
On 4/28/2025 10:50 PM, olcott wrote:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for all >>>>>>>>> possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts when >>>>>>>>> directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as
long as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
The x86 language is neither here nor there.
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I actually
wrote. I'm not sure you understand what 'reply' means.
Still, I'm prepared to give you another crack at it. Here's what I
wrote before:
What matters is whether a TM can be constructed that can accept an
arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved
that such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Not if it's the behavior of P(D) we want to know about, which it is.
Wanting the square root of a rotten egg would do as well.
When P defines a pathological relationship with H it
is stupidly incorrect to expect the behavior of P to remain the same.
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for all
possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts when
directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as long >>>>>> as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
The x86 language is neither here nor there.
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I actually
wrote. I'm not sure you understand what 'reply' means.
Still, I'm prepared to give you another crack at it. Here's what I
wrote before:
What matters is whether a TM can be constructed that can accept an
arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved that
such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Computer science has been wrong about this all of
these years. When I provide the 100% concrete example
of the x86 language there is zero vagueness to slip
through the cracks of understanding.
Even calling the Turing Machine language the Turing
Machine description language make this confusing.
*This is a verified fact*
When DD is emulated by HHH according to the finite
string transformation rules of the x86 language
DD cannot possibly reach its own final state no
matter what HHH does.
Whatever you think you've proved, you haven't solved the Halting
Problem. There are *no* solutions. We know this because there is a
simple well-known proof. So the only way to devise a solution is to
re- define the problem.
It ultimately is only a confused view because key
details about how outputs are made to conform to
inputs:
Turing machines apply finite string transformations
to finite string inputs.
And that's fine. If that's what floats your boat, you can re-define it
as much as you like. But any proofs you may devise apply not to the
Halting Problem but to the Olcott problem.
You aren't paying enough attention because you
are too sure that I am wrong. I proved my point
above.
On 4/28/2025 7:22 PM, Mike Terry wrote:
On 27/04/2025 17:25, olcott wrote:
On 4/26/2025 10:38 PM, Mike Terry wrote:
On 27/04/2025 04:07, Mike Terry wrote:
On 27/04/2025 01:22, olcott wrote:
On 4/26/2025 5:31 PM, dbush wrote:
On 4/26/2025 6:28 PM, olcott wrote:
On 4/26/2025 5:11 PM, dbush wrote:
On 4/26/2025 6:09 PM, olcott wrote:
On 4/26/2025 4:04 PM, Richard Damon wrote:
On 4/26/25 4:33 PM, olcott wrote:
On 4/26/2025 1:26 PM, Fred. Zwarts wrote:
Op 26.apr.2025 om 19:29 schreef olcott:
On 4/26/2025 12:16 PM, joes wrote:
Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 4/25/2025 5:09 PM, joes wrote:
Which x86 semantics does a processor violate when >>>>>>>>>>>>>>> deriving a haltingAm Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 4/25/25 12:31 PM, olcott wrote:When you try to actually show the actual steps instead >>>>>>>>>>>>>>>> of being stuck in
Yes, there are, the operations that the processor >>>>>>>>>>>>>>>>> executes. How did youThere are no finite string operations that can be >>>>>>>>>>>>>>>>>> applied to the inputOnce we understand that Turing computable functions >>>>>>>>>>>>>>>>>>>> are only allowedYouy have your words wrong. They are only ABLE to use >>>>>>>>>>>>>>>>>>> finite
to derived their outputs by applying finite string >>>>>>>>>>>>>>>>>>>> operations to
their inputs then my claim about the behavior of DD >>>>>>>>>>>>>>>>>>>> that HHH must
report on is completely proven.
algorithms of finite string operations. The problem >>>>>>>>>>>>>>>>>>> they need to
solve do not need to be based on that, but on just >>>>>>>>>>>>>>>>>>> general mappings
of finite strings to finite strings that might not be >>>>>>>>>>>>>>>>>>> described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>>>>>> algorith of
transformation steps to make that mapping. >>>>>>>>>>>>>>>>>>>
to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>>>>>> executed DD
thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>>>>
think it works?
utterly baseless rebuttal mode YOU FAIL!
state from the string description of DD?
When any HHH emulates DD according to the finite string >>>>>>>>>>>>>>>> transformationYes, where is that line?
rules specified by the x86 language (the line of >>>>>>>>>>>>>>>> demarcation between
correct and incorrect emulation) no emulated DD can >>>>>>>>>>>>>>>> possibly reach its
final halt state and halt.
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
_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]
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
Finite recursion,
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.
No, it doesn't, as you can't have an infinte series of a >>>>>>>>>>> function that has been defined to be a specific instance. >>>>>>>>>>>
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively >>>>>>>>>> proves that
simulated DD would never stop running unless aborted
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>>> until H correctly determines that its *simulated D would never* >>>>>>>>>> *stop running unless aborted* then
H can abort its simulation of D and correctly report that D >>>>>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>> 10/13/2022>
And again you lie by implying that Sipser agrees with you when >>>>>>>>> it has been proven that he doesn't:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>>>>  > I exchanged emails with him about this. He does not agree >>>>>>>>> with anything
substantive that PO has written. I won't quote him, as I >>>>>>>>> don't havereply to me.
permission, but he was, let's say... forthright, in his
That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
In other words, he did not you agree what you think he agreed to, >>>>>>> and your posting the above to imply that he did is a form of lying. >>>>>>>
*He agreed to MY meaning of these words*
He most certainly did not! He presumably agreed to what he /
thought/ you meant by the words.
Since there is a natural interpretation of those words which would
be correct, and relevant to a discussion concerning a simulating
HD, my GUESS would be that he thought that was what you were
saying: basically, the D in the quote below is clearly intended to
represent *one* *specific* input whose halt status is being
determined, namely the input D.
There is talk of "would never stop running if not aborted", which
is saying that if H were replaced by a UTM (which never aborts its
input) THEN UTM(D) WOULD RUN FOREVER. That amounts to the same
thing as saying that H has determined [through examination of its
simulation steps] that D does not halt [when run directly/
natively]. Of course if H has determined that D does not halt,
there's no point in simulating further, and H can just decide "non-
halting" straight away.
NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some
modified version of D that reflects changes to the embedded copy of
modified H internal to D. The role of D in all this is /data/ viz
the string representing the particular D being discussed. The role >>>>> of H is /code/, H being the halt decider deciding the input D. D
does not change when applying the "simulated D would never stop
unless aborted", or imagining whatever hypothetical changes to H
you are thinking of - only code of H is being (hypothetically)
changed.
I suppose I should have made this clear, as you get confused by this
point - The TM description D which is not changing, includes the [TM
description of the] embedded copy of [original] H. I.e. H without
any of your hypothetical imagined changes.
Much better still, stop imagining hypothetical changes to things and
phrase things by introducing new objects with new names when
required, so that a given name always means the same thing....
For example:Â rather than saying "DDD emulated by HHH cannot return
whatever number of steps HHH simulates from 1 to oo" or whatever, say: >>>>
   "suppose HHH_n is a SHD which simulates its corresponding input >>>> DDD_n for
    n steps before aborting. Then for each n, HHH_n does not
simulate DDD_n as far as
    DDD_n's return."
That way it's clear that the DDD_n are all different programs, none
of which is simulated to its return statement. The way you say it
above sounds like you have ONE DDD whose simulation never returns
however far it is simulated! That would be a non-halting DDD, but
that's not the situation at all. You don't want to invite
deliberate confusion, do you? (Each DDD_n is different, and each /
would/ return if simulated further, e.g. perhaps DDD_2 simulated by
HHH_100 simulates as far as its final ret and so on.)
Mike.
People proved to fail to NOT comprehend it when it is
said that way. They get stuck in a shell game.
You often say that you don't express something in a clear way, because
"people get confused" when you say it that way. There is never any
evidence whatsoever that anybody but you is confused about these
points. What you really mean is that when clearly worded your
confusions are more easily seen to be mistakes - which is not in your
interest it seems.
*This is a better way to say that*
∄HHH ∈ X86 emulators that emulate 0 to ∞ steps of DD |
(DD emulated by HHH reaches its own final halt state)
The category of correct emulator HHH where DD is emulated
by HHH and the emulated DD reaches its final halt state
DOES NOT EXIST.
There are a few problems with that wording. :
1)Â The main problem is you are still Using a fixed term DD in a
To refer to a class of computations.
deliberate attempt to suggest there is one single input DD that
however far you simulate it it never halts.
It seems obvious to me that I never said anything like this.
Hey for sure that means DD never halts, right - it's almost the
definition of non-halting! EXCEPT... THERE IS NO SUCH DD. Every HHH
fails to simulate /its corresponding DD/ as far as that DD's halt state,
Because of recursive emulation.
but other simulators can simulate it to its final halt state.
Their input does not have a pathological relationship with them.
That confusion was /the reason/ for my previous post, so for you to
say your wording is better when it ignores that problem is just
nonsense. At best you're just missing the point. I'll say it again:
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
Everyone here has been trying to get away with simply ignoring
the pathological relationship that DD defines with HHH.
You need to make it clear that the DD is dependent on the chosen HHH.
I have slapped people in the face with that for at
least three years.
You might adopt Linz's notation, with a decider HHH having associated
input HHH^, but you would need to explain that notation close to its
use. Better still would be to introduce an operator like
MAKE_NEMESIS , which converts a halt decider H to its nemesis input
MAKE_NEMESIS(H). That seems clearest for emphasising that
MAKE_NEMESIS(HHH) [aka your DD] is a different input for each HHH. Or
(as most maths people would do) just explain clearly in words!
All that we need to know is to correct the gap
in the theory of computation and understand that
Turing Computable functions are requires to derive
their outputs by applying finite string transformations
to their inputs.
When HHH(DD) applies the finite string
transformations specified by the x86
language to its input,THIS INPUT CANNOT
POSSIBLY HALT NO MATTER WHAT HHH DOES.
2) use of "duffer-speak". Duffer-speak is when non-maths people try
to trick readers into thinking they are mathematically literate by
including what they believe is "proper maths notation, like a real
maths person would use". But they lack all understanding of the terms
and when they would actually be used, so the result is an instant
"crank warning" for the reader:
  MAAARP MAAARP MAARP Crank Warning: duffer-speak detected!  :)
Practically everything you say is duffer-speak, so this is not a
problem you can solve in general. But specifically for your "better
wording" example above:
Does this mean that you disagree that Turing
Computable functions must derive outputs by applying
finite string transformations to their inputs ???
- "..that emulate 0 to ∞ steps..". It is not possible for any HHH
to / not/ emulate 0 to ∞ steps, so the phrase should just be omitted
as it adds nothing but potential confusion.
    But I know the real reason you want to keep the phrase is /
because/ it is misleading, again suggesting that there is a single DD
which, no matter how far you simulate it it never halts. As explained
above that is the exact opposite of the actual situation!
What I want to achieve is universal consensus
that HHH is correct to reject DD as not halting.
- Using "silly" maths notation unnecessarily. If you examine maths
texts, you'll see they do not introduce fancy maths notation and
expressions to make simple high level propositions. They explain them
in english. Of course there are some exceptions, but your use of ∄,
∈, and "category" are all examples where it is unnecessary, and
suggest "crank trying to sound how he/she thinks real maths people
talk, so he/ she will be taken more seriously". It has the opposite
effect! Also it's silly using HHH when your other posts already
discuss one specific HHH that you have coded. Why are there 3 Hs?
And 2 Ds?
-------------------
Putting all the above together, how about:
-Â When a simulating halt decider H simulates its corresponding input H^
   [where H^ is constructed from H according to the Linz HP proof
specification],
   H does not simulate H^ as far as H^'s final halt state.
It <IS NOT> that there is something wrong with H.
It has always been that there is something wrong with D.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The simulated ⟨Ĥ⟩ ⟨Ĥ⟩ can never reach its simulated
final state ⟨Ĥ.qn⟩ because it continues to call
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ in recursive emulation.
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
A bit too clear for you I imagine, as there is nothing to mislead
readers into thinking that any particular H^ never halts - only that
its corresponding H never simulates it that far.
The outer H is always one execution trace ahead of the
next inner one. The means that unless the outer H
aborts then none of them do.
Also, everybody here (I believe) understands and agrees with this (or
very similar) wording. Maybe even you agree?? After all, it's just a
rewording of what you said, right?
If you used a similar wording you could stop arguing around points
where everybody agrees, and move on to whatever comes next. But of
course you /want/ the confusion, so will try to claim that /my/
wording confuses people [..because people reading my wording /don't/
get confused in the way that you are.. :) ]
Mike.
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't
halt) when given D as input must be /established/.
No H can possibly see the behavior of P(D)
when-so-ever D has defined a pathological
relationship with H this changes the behavior
of P so that it is not the same as P(D).
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for all >>>>>>>>> possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts when >>>>>>>>> directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as
long as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
The x86 language is neither here nor there.
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I actually
wrote. I'm not sure you understand what 'reply' means.
Still, I'm prepared to give you another crack at it. Here's what I
wrote before:
What matters is whether a TM can be constructed that can accept an
arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved
that such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't halt) when
given D as input must be /established/.
No H can possibly see the behavior of P(D)
when-so-ever D has defined a pathological
relationship with H this
On 4/29/2025 8:46 AM, Richard Heathfield wrote:
On 29/04/2025 14:11, olcott wrote:
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
<snip>
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't
halt) when given D as input must be /established/.
No H can possibly see the behavior of P(D)
It doesn't have to.
IF IT CAN'T SEE IT THENÂ IT CAN'T REPORT ONÂ IT.
On 4/29/2025 2:39 PM, Richard Heathfield wrote:
On 29/04/2025 20:06, olcott wrote:
On 4/29/2025 8:46 AM, Richard Heathfield wrote:
On 29/04/2025 14:11, olcott wrote:
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
<snip>
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't
halt) when given D as input must be /established/.
No H can possibly see the behavior of P(D)
It doesn't have to.
IF IT CAN'T SEE IT THENÂ IT CAN'T REPORT ONÂ IT.
Yes, it can. There is no need to see the behaviour to establish
whether it halts. All the decider has to be able to see is the
code.
THE CODE THAT IT CAN SEE
unequivocally specifies that the INPUT DOES NOT HALT
I, as a decider, do not need to see the following program's
behaviour to determine whether it halts...
int main(void)
{
  while(1);
  return 0;
}
...because I can tell just by reading the code that it enters
an infinite loop and so will not halt. I can report on whether
the program halts without having to execute it.
IT DOES NOT WORK THAT WAY WITH PATHOLOGICAL SELF-REFERENCE.
On 4/29/2025 10:33 AM, Fred. Zwarts wrote:
makes it impossible for H to see the behaviour of P(D).
The behaviour of P(D) does not change, but H does not see it.
H MUST REPORT ON THE BEHAVIOR THAT IT DOES SEE
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
DD <is> the Halting Problem counter-example input to HHH.
for the same reason we can't devise a universally accurate
termination analyser that executes the code to see what happens.
There is no evidence of that.
On 4/29/2025 3:23 PM, Richard Heathfield wrote:
On 29/04/2025 20:57, olcott wrote:
On 4/29/2025 10:33 AM, Fred. Zwarts wrote:
<snip>
makes it impossible for H to see the behaviour of P(D).
The behaviour of P(D) does not change, but H does not see it.
H MUST REPORT ON THE BEHAVIOR THAT IT DOES SEE
H has the whole P tape and the whole D tape at its disposal.
There is nothing it can't inspect.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
When P has a pathological relationship
to H, the input to H(P,D) DOES NOT HALT.
Not being able to see how P behaves in simulation is no excuse
for getting the answer wrong.
THEN...
I am thinking of the sum of two integers
not telling you what these integers are
is no excuse for you not providing their correct sum.
If because of limitations in H it fails to spot behaviour that
would have changed its report on P(D), that just means that H
is broken.
But don't bother trying to fix it. Turing has already proved
that you can't.
You are simply not bothering to pay complete attention.
On 4/29/2025 10:33 AM, Fred. Zwarts wrote:
Op 29.apr.2025 om 15:11 schreef olcott:
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:The x86 language is neither here nor there.
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for >>>>>>>>>>> all possible inputs whether the input specifies a program >>>>>>>>>>> that (according to the semantics of the machine language) >>>>>>>>>>> halts when directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as >>>>>>>>>> long as we can ignore any input we don't like the look of. >>>>>>>>>>
The behavior of the direct execution of DD cannot be derived >>>>>>>>> by applying the finite string transformation rules specified >>>>>>>>> by the x86 language to the input to HHH(DD). This proves that >>>>>>>>> this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS. >>>>>>>>
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I actually >>>>>> wrote. I'm not sure you understand what 'reply' means.
Still, I'm prepared to give you another crack at it. Here's what I >>>>>> wrote before:
What matters is whether a TM can be constructed that can accept an >>>>>> arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved
that such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't halt)
when given D as input must be /established/.
No H can possibly see the behavior of P(D)
when-so-ever D has defined a pathological
relationship with H this
makes it impossible for H to see the behaviour of P(D).
The behaviour of P(D) does not change, but H does not see it.
H MUST REPORT ON THE BEHAVIOR THAT IT DOES SEE
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for all >>>>>>>>> possible inputs whether the input specifies a program that
(according to the semantics of the machine language) halts when >>>>>>>>> directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as
long as we can ignore any input we don't like the look of.
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
The x86 language is neither here nor there.
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I actually
wrote. I'm not sure you understand what 'reply' means.
Still, I'm prepared to give you another crack at it. Here's what I
wrote before:
What matters is whether a TM can be constructed that can accept an
arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved
that such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't halt) when
given D as input must be /established/.
No H can possibly see the behavior of P(D)
when-so-ever D has defined a pathological
relationship with H this changes the behavior
of P so that it is not the same as P(D).
If you can do that by measuring the tape, great! But if you can do it
by parsing the program's symbols and analysing the parse tree, that's
great too. /How/ you do it doesn't matter as long as you express it as
a Turing Machine that can handle any P and any D and produce a result
of either 'halts' or 'doesn't halt'.
Computer science has been wrong about this all of
these years. When I provide the 100% concrete example
of the x86 language there is zero vagueness to slip
through the cracks of understanding.
Computer science is way ahead of you, as the proof long pre-dates the
x86 chip family.
Even calling the Turing Machine language the Turing
Machine description language make this confusing.
I've never called it that.
*This is a verified fact*
When DD is emulated by HHH according to the finite
string transformation rules of the x86 language
DD cannot possibly reach its own final state no
matter what HHH does.
Your claim is that DD never halts? Fine. You could have proved that by
rewriting DD to have a while(1); at the end of main()..
Whatever you think you've proved, you haven't solved the Halting
Problem. There are *no* solutions. We know this because there is a
simple well-known proof. So the only way to devise a solution is to
re- define the problem.
It ultimately is only a confused view because key
details about how outputs are made to conform to
inputs:
How outputs are made to conform to inputs is neither here nor there.
What matters is whether incomputable functions exist.
When you wrote this: "Computing the actual behavior the direct
execution of any input is ALWAYS IMPOSSIBLE" you conceded the point by
admitting the existence of computations that cannot be performed.
You aren't paying enough attention because you
are too sure that I am wrong. I proved my point
above.
Word salad is not a proof. You can talk till you're blue in the face,
but you can't (correctly) prove that 2 + 2 = 5.
Yes, I'm sure you're wrong. So are you, it seems. Turing's proof
proved that incomputable functions exist. "Computing the actual
behavior the direct execution of any input is ALWAYS IMPOSSIBLE"
concedes the point by admitting the existence of computations that
cannot be performed.
Now, let me paint that in some more.
Turing's proof is about as rigorous as Pythagoras, and it is difficult
to imagine any way in which a flaw could have lasted through 90-odd
years of computer science, but I suppose we must accept that it took
us 300+ years to confirm FLT, so it's /not/ inconceivable that one day
someone might show a minor error in the proof.
What /is/ inconceivable, however, is that Turing's conclusion - 'not
all functions are computable' - is flawed. You yourself conceded the
point when you wrote: "Computing the actual behavior the direct
execution of any input is ALWAYS IMPOSSIBLE."
If there is anything to overturn it's his conclusion, but you have
already accepted the conclusion. Game over.
On 4/29/25 3:57 PM, olcott wrote:
On 4/29/2025 10:33 AM, Fred. Zwarts wrote:
Op 29.apr.2025 om 15:11 schreef olcott:
No H can possibly see the behavior of P(D)
when-so-ever D has defined a pathological
relationship with H this
makes it impossible for H to see the behaviour of P(D).
The behaviour of P(D) does not change, but H does not see it.
H MUST REPORT ON THE BEHAVIOR THAT IT DOES SEE
No, it must report on the behavior that exists.
It is only ABLE to correctly report on behavior it can "see", but
there is no structural restriction that says we can't ask it
about something that it can't see.
On 4/29/2025 10:33 AM, Fred. Zwarts wrote:
Op 29.apr.2025 om 15:11 schreef olcott:
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:The x86 language is neither here nor there.
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for >>>>>>>>>>> all possible inputs whether the input specifies a program >>>>>>>>>>> that (according to the semantics of the machine language) >>>>>>>>>>> halts when directly executed.
Correct?
Correct. We can, however, construct such an algorithm just as >>>>>>>>>> long as we can ignore any input we don't like the look of. >>>>>>>>>>
The behavior of the direct execution of DD cannot be derived >>>>>>>>> by applying the finite string transformation rules specified >>>>>>>>> by the x86 language to the input to HHH(DD). This proves that >>>>>>>>> this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS. >>>>>>>>
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I actually >>>>>> wrote. I'm not sure you understand what 'reply' means.
Still, I'm prepared to give you another crack at it. Here's what I >>>>>> wrote before:
What matters is whether a TM can be constructed that can accept an >>>>>> arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved
that such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't halt)
when given D as input must be /established/.
No H can possibly see the behavior of P(D)
when-so-ever D has defined a pathological
relationship with H this
makes it impossible for H to see the behaviour of P(D).
The behaviour of P(D) does not change, but H does not see it.
H MUST REPORT ON THE BEHAVIOR THAT IT DOES SEE
On 4/29/2025 3:23 PM, Richard Heathfield wrote:
On 29/04/2025 20:57, olcott wrote:
On 4/29/2025 10:33 AM, Fred. Zwarts wrote:
<snip>
makes it impossible for H to see the behaviour of P(D).
The behaviour of P(D) does not change, but H does not see it.
H MUST REPORT ON THE BEHAVIOR THAT IT DOES SEE
H has the whole P tape and the whole D tape at its disposal. There is
nothing it can't inspect.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
When P has a pathological relationship
to H, the input to H(P,D) DOES NOT HALT.
Not being able to see how P behaves in simulation is no excuse for
getting the answer wrong.
THEN...
I am thinking of the sum of two integers
not telling you what these integers are
is no excuse for you not providing their correct sum.
If because of limitations in H it fails to spot behaviour that would
have changed its report on P(D), that just means that H is broken.
But don't bother trying to fix it. Turing has already proved that you
can't.
You are simply not bothering to pay complete attention.
On 4/29/2025 2:39 PM, Richard Heathfield wrote:
On 29/04/2025 20:06, olcott wrote:
On 4/29/2025 8:46 AM, Richard Heathfield wrote:
On 29/04/2025 14:11, olcott wrote:
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
<snip>
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't halt)
when given D as input must be /established/.
No H can possibly see the behavior of P(D)
It doesn't have to.
IF IT CAN'T SEE IT THENÂ IT CAN'T REPORT ONÂ IT.
Yes, it can. There is no need to see the behaviour to establish
whether it halts. All the decider has to be able to see is the code.
THE CODE THAT IT CAN SEE
unequivocally specifies that the INPUT DOES NOT HALT
On 4/29/2025 8:46 AM, Richard Heathfield wrote:
On 29/04/2025 14:11, olcott wrote:
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
<snip>
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't halt)
when given D as input must be /established/.
No H can possibly see the behavior of P(D)
It doesn't have to.
IF IT CAN'T SEE IT THENÂ IT CAN'T REPORT ONÂ IT.
On 4/29/2025 3:06 PM, Richard Heathfield wrote:
On 29/04/2025 20:56, olcott wrote:
On 4/29/2025 2:39 PM, Richard Heathfield wrote:
On 29/04/2025 20:06, olcott wrote:
On 4/29/2025 8:46 AM, Richard Heathfield wrote:
On 29/04/2025 14:11, olcott wrote:
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
<snip>
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't
halt) when given D as input must be /established/.
No H can possibly see the behavior of P(D)
It doesn't have to.
IF IT CAN'T SEE IT THENÂ IT CAN'T REPORT ONÂ IT.
Yes, it can. There is no need to see the behaviour to establish
whether it halts. All the decider has to be able to see is the code.
THE CODE THAT IT CAN SEE
unequivocally specifies that the INPUT DOES NOT HALT
Fine. Either it's right or it's wrong.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
On 4/30/2025 1:05 AM, Richard Heathfield wrote:
Nor is there any restriction that says it can't deduce
behaviour it can't see, simply by reading the tapes.
It is ONLY allowed to derive its output by
applying finite string transformations to its input.
For the HHH/DD pair these must be the finite string
transformations specified by the x86 language.
Turing machine computable functions must apply
finite string transformation rues to inputs
to derive outputs.
This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }
On 4/29/2025 5:01 AM, Mikko wrote:Yes it is, for all inputs.
Irrelevant. There is sufficient agreement what Turing machines are.
Turing machine computable functions must apply finite string
transformation rues to inputs to derive outputs.
This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't.
The domain of HHH is DD.
If it isn't, it's irrelevant to the Halting Problem,
It correctly refutes the conventional proof of the
Halting Problem proofs.
The "impossible" input specifies
non-halting behavior and the contradictory part of DD
is unreachable code.
Have you ever done any actual programming?
Am Wed, 30 Apr 2025 10:09:45 -0500 schrieb olcott:
On 4/29/2025 5:01 AM, Mikko wrote:
Yes it is, for all inputs.Irrelevant. There is sufficient agreement what Turing machines are.
Turing machine computable functions must apply finite string
transformation rues to inputs to derive outputs.
This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }
On 4/30/2025 10:46 AM, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it
isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott
Problem, which is of interest to nobody but you.
Because you don't pay any attention at all
you did not bother to notice that I have never been
attacking the Halting Problem only the conventional
Halting Problem proof.
THE IMPOSSIBLE INPUT IS REJECTED AS NON-HALTING.
On 30/04/2025 16:15, olcott wrote:
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott Problem, which is of interest to nobody
but you.
Am Mon, 28 Apr 2025 21:50:03 -0500 schrieb olcott:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
No, H gets P(D) as input, not itself. H is the "measurer", not being measured.What matters is whether a TM can be constructed that can accept anYet it is H(P,D) and NOT P(D) that must be measured. Computer science
arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved that
such a TM cannot be constructed.
This is what we call the Halting Problem.
has been wrong about this all of these years. When I provide the 100%
concrete example of the x86 language there is zero vagueness to slip
through the cracks of understanding.
On 4/30/2025 10:46 AM, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott Problem,
which is of interest to nobody but you.
Because you don't pay any attention at all
you did not bother to notice that I have never been
attacking the Halting Problem only the conventional
Halting Problem proof.
THE IMPOSSIBLE INPUT IS REJECTED AS NON-HALTING.
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't.
The domain of HHH is DD.
If it isn't, it's irrelevant to the Halting Problem,
It correctly refutes the conventional proof of the
Halting Problem proofs. The "impossible" input specifies
non-halting behavior and the contradictory part of DD
is unreachable code.
Have you ever done any actual programming?
and we can ignore it. If it is, however, then we know that it doesn't
work for all inputs, even if (as you claim) it works for one.
<snip>
DD <is> the Halting Problem counter-example input to HHH.
for the same reason we can't devise a universally accurate
termination analyser that executes the code to see what happens.
There is no evidence of that.
Sure there is. Not just evidence, but an actual, rigorous,
mathematical proof.
On 4/30/2025 1:30 PM, Mike Terry wrote:
On 30/04/2025 16:46, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott Problem,
which is of interest to nobody but you.
It would be (if correct) attacking the common proof for HP theorem as
it occurs for instance in the Linz book which PO links to from time to
time.
The proof proceeds by assuming H is a halt decider. Then it
constructs from H a new TM H^ by modify H in a prescribed manner. The
proof shows that H fails to correctly decide input (<H^>,<H^>):Â if
H(<H^>,<H^>) = halts, then H^(<H^>) never halts, while if H(<H^>,<H^>)
= neverhalts then H^(<H^>) halts. So H is in fact NOT a halt decider.
(Alternatively the proof could be taken as proving that every halt
decider H decides at least one input [viz H^] incorrectly.
PO claimed to have constructed a TM H, and its corresponding TM H^,
such that H /correctly/ decides input (<H^>,<H^>). Since the Linz
(and similar) proof shows H /incorrectly/ decides that input, there
would clearly be some problem with proof, assuming PO's claims to be
correct.
This is not a Turing computable function to calculate sum
because it ignores its inputs thus does not transform them
according to the transformation rules of arithmetic.
int sum(int x, int y) { return 5; }
A halt decider is not allowed to compute halting on
the basis of direct execution. It is only allowed to
transform inputs into outputs.
There are ONLY finite string transformations according
to the x86 language from the input to HHH(DD) to non
halting behavior.
So PO's H does not need to correctly decide every input - PO does not
claim to have a valid halt decider. His claim is that the Linz and
similar proofs are invalid, so his H just has to decide that one input
(<H^>,<H^>) correctly.
Well by now you must be on the edge of your seat! How did it all turn
out? Did PO in fact have the TMs he claimed? What actually happens
when you run those TMs???? !  (LOL)
You'll be highly disappointed (but not too surprised) to learn:
1)Â PO didn't have any TMs, and didn't know what a TM was.
That is stupidly incorrect.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
2)Â PO was trying to make C program analogs of the TMs, but he didn't
have those either
    (at the time he claimed to have them)
3)Â Eventually PO did produce some code in the form of his H and H^,
but when you ran them:
    -  H^(<H^>) halts
    -  H(<H^>,<H^>) decided neverhalts
    Exactly in line with the Linz proof. (PO's names differ from
what I've used.)
All the current threads are variations of PO trying to claim that H is
"correct" in some wacky PO-sense, when it decides neverhalts for input
(<H^>,<H^>), despite the acknowledged fact that H^(<H^>) actually halts.
Mike.
On 4/30/2025 1:05 AM, Richard Heathfield wrote:
On 30/04/2025 03:45, Richard Damon wrote:
On 4/29/25 3:57 PM, olcott wrote:
On 4/29/2025 10:33 AM, Fred. Zwarts wrote:
Op 29.apr.2025 om 15:11 schreef olcott:
<snip>
No H can possibly see the behavior of P(D)
when-so-ever D has defined a pathological
relationship with H this
makes it impossible for H to see the behaviour of P(D).
The behaviour of P(D) does not change, but H does not see it.
H MUST REPORT ON THE BEHAVIOR THAT IT DOES SEE
No, it must report on the behavior that exists.
It is only ABLE to correctly report on behavior it can "see", but
there is no structural restriction that says we can't ask it about
something that it can't see.
Nor is there any restriction that says it can't deduce behaviour it
can't see, simply by reading the tapes.
It is ONLY allowed to derive its output by
applying finite string transformations to its input.
For the HHH/DD pair these must be the finite string
transformations specified by the x86 language.]
For the embedded_H / ⟨Ĥ⟩ ⟨Ĥ⟩ pair these
transformations are specified by the Linz template.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Above adapted from bottom of page 2 https://www.liarparadox.org/Linz_Proof.pdf
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
Mr Olcott seems unable to recognise this possibility. Having built his
hammer, he is determined to see the Halting Problem as a nail that
cannot withstand being pounded hard enough.
Unfortunately for him, the problem is more like a 16 puzzle with two
tiles swapped. If he plays by the rules there is no solution, no
matter how hard he hits it.
This is why he keeps trying to change the rules, with word salad like
'pathological self-reference', when self-reference is the whole reason
the proof works.
On 4/29/2025 5:00 AM, joes wrote:
Am Mon, 28 Apr 2025 21:50:03 -0500 schrieb olcott:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
What matters is whether a TM can be constructed that can accept anYet it is H(P,D) and NOT P(D) that must be measured. Computer science
arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved that
such a TM cannot be constructed.
This is what we call the Halting Problem.
has been wrong about this all of these years. When I provide the 100%
concrete example of the x86 language there is zero vagueness to slip
through the cracks of understanding.
No, H gets P(D) as input, not itself. H is the "measurer", not being
measured.
H NEVER gets P(D) as input.
H always gets finite strings P and D as inputs.
On 4/30/2025 4:04 AM, Fred. Zwarts wrote:
Op 29.apr.2025 om 21:57 schreef olcott:
On 4/29/2025 10:33 AM, Fred. Zwarts wrote:
Op 29.apr.2025 om 15:11 schreef olcott:
On 4/29/2025 2:10 AM, Richard Heathfield wrote:
On 29/04/2025 03:50, olcott wrote:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:
On 28/04/2025 19:30, olcott wrote:
On 4/28/2025 11:38 AM, Richard Heathfield wrote:
On 28/04/2025 16:01, olcott wrote:
On 4/28/2025 2:33 AM, Richard Heathfield wrote:The x86 language is neither here nor there.
On 28/04/2025 07:46, Fred. Zwarts wrote:
<snip>
So we agree that no algorithm exists that can determine for >>>>>>>>>>>>> all possible inputs whether the input specifies a program >>>>>>>>>>>>> that (according to the semantics of the machine language) >>>>>>>>>>>>> halts when directly executed.
Correct?
Correct. We can, however, construct such an algorithm just >>>>>>>>>>>> as long as we can ignore any input we don't like the look of. >>>>>>>>>>>>
The behavior of the direct execution of DD cannot be derived >>>>>>>>>>> by applying the finite string transformation rules specified >>>>>>>>>>> by the x86 language to the input to HHH(DD). This proves that >>>>>>>>>>> this is the wrong behavior to measure.
It is the behavior THAT IS derived by applying the finite >>>>>>>>>>> string transformation rules specified by the x86 language >>>>>>>>>>> to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS. >>>>>>>>>>
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Outputs must correspond to inputs*
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.
In your reply to my article, you forgot to address what I
actually wrote. I'm not sure you understand what 'reply' means. >>>>>>>>
Still, I'm prepared to give you another crack at it. Here's what >>>>>>>> I wrote before:
What matters is whether a TM can be constructed that can accept >>>>>>>> an arbitrary TM tape P and an arbitrary input tape D and
correctly calculate whether, given D as input, P would halt.
Turing proved that such a TM cannot be constructed.
This is what we call the Halting Problem.
Yet it is H(P,D) and NOT P(D) that must be measured.
Nothing /has/ to be measured. P's behaviour (halts, doesn't halt)
when given D as input must be /established/.
No H can possibly see the behavior of P(D)
when-so-ever D has defined a pathological
relationship with H this
makes it impossible for H to see the behaviour of P(D).
The behaviour of P(D) does not change, but H does not see it.
H MUST REPORT ON THE BEHAVIOR THAT IT DOES SEE
That is your error. H must report on the behaviour specified in the
input.
HHH DOES APPLY the finite string transformations
specified by the x86 language TO ITS INPUT and this
DOES SPECIFY THAT DD DOES NOT HALT.
Bugs in H do not change the behaviour specified in the input.
H just fails to see it.
On 4/29/2025 5:01 AM, Mikko wrote:
On 2025-04-28 16:27:56 +0000, olcott said:
On 4/28/2025 4:14 AM, Mikko wrote:
On 2025-04-26 15:59:39 +0000, olcott said:
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:Not at all. You have simply not been paying enough attention.
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and
contradicted
by a good proof.
Some people claim that the unsolvability of the halting
problem is
unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that proof of >>>>>>>> the
theorem. There are other proofs that you don't even try to refute. >>>>>>>
Once we understand that Turing computable functions are only
allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
Attempt to deceive by a false claim. The term "computable function" is >>>> defined in terms of Turing machines so Turing machines are on topic.
Since there is no universally agreed upon definition
of the Turing Machine language it is impossible to
provide the 100% concrete details in this Turing
Machine language.
Irrelevant. There is sufficient agreement what Turing machines are.
Turing machine computable functions must apply
finite string transformation rues to inputs
to derive outputs.
This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }
And that agreement does not restrict what Turing machines are allowed
to do, only what they can do.
olcott <polcott333@gmail.com> writes:
On 4/30/2025 2:46 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
Because you don't pay any attention at all[...]
you did not bother to notice that I have never been
attacking the Halting Problem only the conventional
Halting Problem proof.
That's some interesting news, at least to me.
I was under the impression that you had explicitly claimed to have
solved the Halting Problem. I don't read most of what you write,
and I don't remember all of what I've read, so my impression may
have been mistaken.
Now you're saying that you're only attacking the conventional proof.
That is ALL that I have been saying for several years.
Anyone can figure that out simply on the basis of
actually paying attention to my proof.
HHH(DD) does correctly report that the halting problem
proof's impossible input DOES NOT HALT SO THE PROOF
IS WRONG.
So your only claim is that the commonly known Halting Problem proof
is flawed. (Others who have paid more attention might choose to
comment on that.)
Do you have anything to say about whether the Halting Problem
is solvable? (You snipped this question in your previous response.)
On 29/04/2025 11:00, joes wrote:
Am Mon, 28 Apr 2025 21:50:03 -0500 schrieb olcott:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:No, H gets P(D) as input, not itself. H is the "measurer", not being
What matters is whether a TM can be constructed that can accept anYet it is H(P,D) and NOT P(D) that must be measured. Computer science
arbitrary TM tape P and an arbitrary input tape D and correctly
calculate whether, given D as input, P would halt. Turing proved that
such a TM cannot be constructed.
This is what we call the Halting Problem.
has been wrong about this all of these years. When I provide the 100%
concrete example of the x86 language there is zero vagueness to slip
through the cracks of understanding.
measured.
Mr Olcott has contradicted you, and even though he's wrong about almost everything else I don't think he's wrong about this.
Let's drop HHH and DD and so on, and stick to:
U is a universal termination analysis program, taking two tapes, P and
D. If P(D) would halt, U(P,D) returns true; else false. No matter what program P is, U always reports either true or false, and never makes a mistake.
P is an arbitrary (but syntactically correct) program.
If we can write U, it's easy enough to write V, which differs from U only
in that instead of reporting, V reacts to an unending program by halting
and to a halting program by looping forever.
Then we make two copies of the V tape and ask V about itself. What would
U(V, V) tell us?
U (my universal analogue of Mr Olcott's H^3) doesn't get V(V) as its input, but V and V. U(V(V)) would suggest that V(V) is executed and the result passed to U, but in fact there is no need to execute V if the analysis can
be performed statically.
Whether it's executed or not, however, the answer is that V(V) halts only
if it doesn't and loops forever only if it doesn't.
You've added a problem that should not be there.
On 30/04/2025 16:46, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it
isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott
Problem, which is of interest to nobody but you.
It would be (if correct) attacking the common proof for HP
theorem as it occurs for instance in the Linz book which PO links
to from time to time.
On 4/30/2025 5:04 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 4/30/2025 2:46 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
Because you don't pay any attention at all[...]
you did not bother to notice that I have never been
attacking the Halting Problem only the conventional
Halting Problem proof.
That's some interesting news, at least to me.
I was under the impression that you had explicitly claimed to have
solved the Halting Problem. I don't read most of what you write,
and I don't remember all of what I've read, so my impression may
have been mistaken.
Now you're saying that you're only attacking the conventional proof.
That is ALL that I have been saying for several years.
Anyone can figure that out simply on the basis of
actually paying attention to my proof.
HHH(DD) does correctly report that the halting problem
proof's impossible input DOES NOT HALT SO THE PROOF
IS WRONG.
So your only claim is that the commonly known Halting Problem proof
is flawed. (Others who have paid more attention might choose to
comment on that.)
Do you have anything to say about whether the Halting Problem
is solvable? (You snipped this question in your previous response.)
The proof that the Halting Problem is not solvable
has been proven to be incorrect.
It turns out the the entire category of undecidable
decision problem instances is vacuous. The whole
notion of undecidability is merely a confused view.
It is easy to eliminate undecidability in formal
systems simply by only allowing semantic logical
entailment from a set of basic facts that have been
stipulated to be true.
On 4/30/2025 9:01 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 4/30/2025 5:04 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 4/30/2025 2:46 PM, Keith Thompson wrote:So your only claim is that the commonly known Halting Problem proof
olcott <polcott333@gmail.com> writes:That is ALL that I have been saying for several years.
[...]
Because you don't pay any attention at all[...]
you did not bother to notice that I have never been
attacking the Halting Problem only the conventional
Halting Problem proof.
That's some interesting news, at least to me.
I was under the impression that you had explicitly claimed to have >>>>>> solved the Halting Problem. I don't read most of what you write, >>>>>> and I don't remember all of what I've read, so my impression may
have been mistaken.
Now you're saying that you're only attacking the conventional proof. >>>>>
Anyone can figure that out simply on the basis of
actually paying attention to my proof.
HHH(DD) does correctly report that the halting problem
proof's impossible input DOES NOT HALT SO THE PROOF
IS WRONG.
is flawed. (Others who have paid more attention might choose to
comment on that.)
Do you have anything to say about whether the Halting Problem
is solvable? (You snipped this question in your previous response.)
The proof that the Halting Problem is not solvable
has been proven to be incorrect.
It turns out the the entire category of undecidable
decision problem instances is vacuous. The whole
notion of undecidability is merely a confused view.
It is easy to eliminate undecidability in formal
systems simply by only allowing semantic logical
entailment from a set of basic facts that have been
stipulated to be true.
That's nice.
Do you have anything to say about whether the Halting Problem
is solvable? Refuting one proof doesn't address that question.
After people acknowledge that I have correctly refuting
the conventional proof will I tolerate change of subject.
Ben wasted 15 years of my life with his change of subject
form of rebuttal.
Once one proof is refuted thenn (then and only then) we
move onto the next proof.
There's some discussion of other proofs of the undecidability of
the Halting Problem here:
    https://cstheory.stackexchange.com/q/2853/7906
I don't have the time or mathematical background necessary to
understand it, but others here might.
I expect you'll continue to evade the question. If so, I'll go
back to ignoring you.
On 4/30/2025 7:53 PM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/04/2025 11:00, joes wrote:
Am Mon, 28 Apr 2025 21:50:03 -0500 schrieb olcott:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:No, H gets P(D) as input, not itself. H is the "measurer", not being
What matters is whether a TM can be constructed that can accept an >>>>>> arbitrary TM tape P and an arbitrary input tape D and correctlyYet it is H(P,D) and NOT P(D) that must be measured. Computer science >>>>> has been wrong about this all of these years. When I provide the 100% >>>>> concrete example of the x86 language there is zero vagueness to slip >>>>> through the cracks of understanding.
calculate whether, given D as input, P would halt. Turing proved that >>>>>> such a TM cannot be constructed.
This is what we call the Halting Problem.
measured.
Mr Olcott has contradicted you, and even though he's wrong about almost
everything else I don't think he's wrong about this.
Let's drop HHH and DD and so on, and stick to:
U is a universal termination analysis program, taking two tapes, P and
D. If P(D) would halt, U(P,D) returns true; else false. No matter what
program P is, U always reports either true or false, and never makes a
mistake.
P is an arbitrary (but syntactically correct) program.
If we can write U, it's easy enough to write V, which differs from U
only
in that instead of reporting, V reacts to an unending program by halting >>> and to a halting program by looping forever.
Then we make two copies of the V tape and ask V about itself. What would >>> U(V, V) tell us?
U (my universal analogue of Mr Olcott's H^3) doesn't get V(V) as its
input,
but V and V. U(V(V)) would suggest that V(V) is executed and the result
passed to U, but in fact there is no need to execute V if the
analysis can
be performed statically.
Whether it's executed or not, however, the answer is that V(V) halts
only
if it doesn't and loops forever only if it doesn't.
You've added a problem that should not be there. Your U is a two-tape TM
and so therefore is V. U(P,D) reports on the halting of P(D) but U(V,V)
is ill-defined because V(V) is not a two-tape computation. Even P(D) is
not well-formed because what does it mean to apply a tape to a tape?
(Yes, I know P(D) means the execution of the TM encoded on the tape P
when run on tape D but this should be spelled out.)
The proof is simpler to get right if all the models are the same: U is a
one-tape TM decider of one-tape computations. And we should clearly
distinguish between TMs, encodings of TMs and encodings of TM/data
pairs. Many years ago I urged PO is use a notation such as:
  P    A Turing machine with some alphabet Sigma.
  P(i) The computation that results from P running with initial tape i. >>   [P]  the encoding of a TM in the alphabet Sigma.
  <x,y> the encoding of a pair of strings over Sigma using only symbols >>         in Sigma.
A halt decider, H, would then be a TM (over Sigma) that accepts all
inputs of the form <[P],d> where P(d) halts and that rejects all other
inputs.
It never has been my misunderstanding.
It is that everyone else was not acutely
aware that inputs my bed transformed into output
by a specific set of transformation rules.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
There is no way that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
by embedded_H can possibly get to ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
THEREFORE THE INPUT TO embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ DOES NOT HALT.
Linz is using the wrong measure.
But then PO never really understood TMs and soon ditched them altogether
in favour of a model of computation that, ironically, has decidable
halting! Mind you, despite his IO-free x86 model having decidable
halting, he has not demonstrated halt decider for it. (Aside: I don't
mean that a halt decider is possible in the model, just that halting in
his model is TM-decidable.)
On 4/30/2025 7:07 PM, Mike Terry wrote:
On 30/04/2025 23:04, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
On 4/30/2025 2:46 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
Because you don't pay any attention at all[...]
you did not bother to notice that I have never been
attacking the Halting Problem only the conventional
Halting Problem proof.
That's some interesting news, at least to me.
I was under the impression that you had explicitly claimed to have
solved the Halting Problem. I don't read most of what you write,
and I don't remember all of what I've read, so my impression may
have been mistaken.
Now you're saying that you're only attacking the conventional proof.
That is ALL that I have been saying for several years.
Anyone can figure that out simply on the basis of
actually paying attention to my proof.
HHH(DD) does correctly report that the halting problem
proof's impossible input DOES NOT HALT SO THE PROOF
IS WRONG.
So your only claim is that the commonly known Halting Problem proof
is flawed. (Others who have paid more attention might choose to
comment on that.)
My recollection is that PO does not claim to have a solution to the
halting problem.
I made a recent post here (Wed, 30 Apr 2025 19:30:46 +0100) with some
background, since another poster also seemed to think PO was claiming
to have "solved the HP".
Several people [starting years ago with Ben] have explained to PO that
there are multiple alternative proofs, including one in the Linz book
which PO might be expected to have read, but PO blanks such
discussions. He wouldn't understand those proofs, of course.
 and
A single minded focus of 22 years has correctly
refuted the conventional halting problem proof.
This would have been fully acknowledged years ago if
people understood that HHH/DD is analogous (thus isomorphic)
to Linz and Functions computed by Turing Machines are ONLY
allowed to derive outputs by applying finite string transformations
to inputs.
This requirement forbids HHH to report on DD(DD)
because the mapping from the input to HHH(DD)
specifies something else.'
You can't simply guess the mapping that you want
and then assume that it exists.
Do you have anything to say about whether the Halting Problem
is solvable? (You snipped this question in your previous response.)
I'm actually not sure what PO would say! I imagine he would sidestep
the question by denying the validity of the "conventional" HP
statement in some way.
Mike.
On 4/30/2025 7:53 PM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 29/04/2025 11:00, joes wrote:
Am Mon, 28 Apr 2025 21:50:03 -0500 schrieb olcott:
On 4/28/2025 3:13 PM, Richard Heathfield wrote:No, H gets P(D) as input, not itself. H is the "measurer", not being
What matters is whether a TM can be constructed that can accept an >>>>>> arbitrary TM tape P and an arbitrary input tape D and correctlyYet it is H(P,D) and NOT P(D) that must be measured. Computer science >>>>> has been wrong about this all of these years. When I provide the 100% >>>>> concrete example of the x86 language there is zero vagueness to slip >>>>> through the cracks of understanding.
calculate whether, given D as input, P would halt. Turing proved that >>>>>> such a TM cannot be constructed.
This is what we call the Halting Problem.
measured.
Mr Olcott has contradicted you, and even though he's wrong about almost
everything else I don't think he's wrong about this.
Let's drop HHH and DD and so on, and stick to:
U is a universal termination analysis program, taking two tapes, P and
D. If P(D) would halt, U(P,D) returns true; else false. No matter what
program P is, U always reports either true or false, and never makes a
mistake.
P is an arbitrary (but syntactically correct) program.
If we can write U, it's easy enough to write V, which differs from U
only
in that instead of reporting, V reacts to an unending program by halting >>> and to a halting program by looping forever.
Then we make two copies of the V tape and ask V about itself. What would >>> U(V, V) tell us?
U (my universal analogue of Mr Olcott's H^3) doesn't get V(V) as its
input,
but V and V. U(V(V)) would suggest that V(V) is executed and the result
passed to U, but in fact there is no need to execute V if the
analysis can
be performed statically.
Whether it's executed or not, however, the answer is that V(V) halts
only
if it doesn't and loops forever only if it doesn't.
You've added a problem that should not be there. Your U is a two-tape TM
and so therefore is V. U(P,D) reports on the halting of P(D) but U(V,V)
is ill-defined because V(V) is not a two-tape computation. Even P(D) is
not well-formed because what does it mean to apply a tape to a tape?
(Yes, I know P(D) means the execution of the TM encoded on the tape P
when run on tape D but this should be spelled out.)
The proof is simpler to get right if all the models are the same: U is a
one-tape TM decider of one-tape computations. And we should clearly
distinguish between TMs, encodings of TMs and encodings of TM/data
pairs. Many years ago I urged PO is use a notation such as:
  P    A Turing machine with some alphabet Sigma.
  P(i) The computation that results from P running with initial tape i. >>   [P]  the encoding of a TM in the alphabet Sigma.
  <x,y> the encoding of a pair of strings over Sigma using only symbols >>         in Sigma.
A halt decider, H, would then be a TM (over Sigma) that accepts all
inputs of the form <[P],d> where P(d) halts and that rejects all other
inputs.
It never has been my misunderstanding.
It is that everyone else was not acutely
aware that inputs my bed transformed into output
by a specific set of transformation rules.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
There is no way that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
by embedded_H can possibly get to ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
THEREFORE THE INPUT TO embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ DOES NOT HALT.
Linz is using the wrong measure.
On 30/04/2025 19:30, Mike Terry wrote:
On 30/04/2025 16:46, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:It would be (if correct) attacking the common proof for HP theorem as it
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott Problem,
which is of interest to nobody but you.
occurs for instance in the Linz book which PO links to from time to time.
Yes. That's what I call the Olcott Problem.
De gustibus non est disputandum, but I venture to suggest that (correctly) overturning Turing's proof would be of cosmos-rocking interest to the world of computer science, compared to which pointing out a minor flaw in a minor[1] proof would, even if correct, have no more effect on our field
than lobbing a pebble into the swash at high tide.
I suspect that the only reason we bother to argue with Mr Olcott so much is because (even if he does so unwittingly) he manages to convey the
appearance of attacking the Halting Problem, and arguing about the Halting Problem is a lot more fun than arguing about the Olcott Problem.
To be of any interest, solving the Olcott Problem would have to have important consequences. But does it? Let's see.
Dr Linz Theorem 12.1 (Halting Problem is Undecidable): There does not exist any Turing machine H that behaves as required by Linz Definition 12.1. Thus the halting problem is undecidable.
Dr Linz has a proof for this claim, which can be found here: <https://john.cs.olemiss.edu/~hcc/csci311/notes/chap12/ch12.pdf>
If the proof is flawless, the conclusion stands and Mr Olcott is simply wrong.
If the proof is flawed through some error of reasoning, *either* it merely fails to correctly support its conclusion *or* a duly corrected proof /overturns/ the conclusion.
The latter would be /extremely/ interesting, but it would also mean that we have two proofs proving opposite things, and so it would effectively be a cataclysmic sideways attack on Turing's reasoning.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 30/04/2025 19:30, Mike Terry wrote:
On 30/04/2025 16:46, Richard Heathfield wrote:Yes. That's what I call the Olcott Problem.
On 30/04/2025 16:15, olcott wrote:It would be (if correct) attacking the common proof for HP theorem as it >>> occurs for instance in the Linz book which PO links to from time to time. >>
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott Problem,
which is of interest to nobody but you.
De gustibus non est disputandum, but I venture to suggest that (correctly) >> overturning Turing's proof would be of cosmos-rocking interest to the world >> of computer science, compared to which pointing out a minor flaw in a
minor[1] proof would, even if correct, have no more effect on our field
than lobbing a pebble into the swash at high tide.
I suspect that the only reason we bother to argue with Mr Olcott so much is >> because (even if he does so unwittingly) he manages to convey the
appearance of attacking the Halting Problem, and arguing about the Halting >> Problem is a lot more fun than arguing about the Olcott Problem.
To be of any interest, solving the Olcott Problem would have to have
important consequences. But does it? Let's see.
Dr Linz Theorem 12.1 (Halting Problem is Undecidable): There does not exist >> any Turing machine H that behaves as required by Linz Definition 12.1. Thus >> the halting problem is undecidable.
Dr Linz has a proof for this claim, which can be found here:
<https://john.cs.olemiss.edu/~hcc/csci311/notes/chap12/ch12.pdf>
If the proof is flawless, the conclusion stands and Mr Olcott is simply
wrong.
There is peculiar irony here. The proof is /not/ flawless. It has, in
fact, a flaw that PO pointed out (although in passing). PO does not
care about the flaw because it is easily fixed, but it's there none the less[1].
Anyway, Linz only gives this argument because it is of historical
interest. His "real" proof immediately follows this argument (in the
book) and is a trivial corollary of the fact, proved in chapter 11, that
not all recursively enumerable languages are recursive. But no crank
ever addresses that proof. I wonder why...
If the proof is flawed through some error of reasoning, *either* it merely >> fails to correctly support its conclusion *or* a duly corrected proof
/overturns/ the conclusion.
... or a duly corrected proof /supports/ the conclusion. Maybe you
intended this possibility to be include in your first "merely fails to support" alternative.
The latter would be /extremely/ interesting, but it would also mean that we >> have two proofs proving opposite things, and so it would effectively be a
cataclysmic sideways attack on Turing's reasoning.
It would be a cataclysmic attack on all of conventional mathematics and
logic as two proofs, one of T and another of ~T, makes the system of
proof oneself inconsistent (and everything becomes a theorem).
[1] It centres on the naming of states in H and the derived machines H'
and H^. Details available if you really care.
On 5/1/2025 10:32 AM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 30/04/2025 19:30, Mike Terry wrote:
On 30/04/2025 16:46, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:It would be (if correct) attacking the common proof for HP theorem
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:The domain of HHH is DD.
<snip>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't. >>>>>>
Then it is attacking not the Halting Problem but the Olcott Problem, >>>>> which is of interest to nobody but you.
as it
occurs for instance in the Linz book which PO links to from time to
time.
Yes. That's what I call the Olcott Problem.
De gustibus non est disputandum, but I venture to suggest that
(correctly)
overturning Turing's proof would be of cosmos-rocking interest to the
world
of computer science, compared to which pointing out a minor flaw in a
minor[1] proof would, even if correct, have no more effect on our field
than lobbing a pebble into the swash at high tide.
I suspect that the only reason we bother to argue with Mr Olcott so
much is
because (even if he does so unwittingly) he manages to convey the
appearance of attacking the Halting Problem, and arguing about the
Halting
Problem is a lot more fun than arguing about the Olcott Problem.
To be of any interest, solving the Olcott Problem would have to have
important consequences. But does it? Let's see.
Dr Linz Theorem 12.1 (Halting Problem is Undecidable): There does not
exist
any Turing machine H that behaves as required by Linz Definition
12.1. Thus
the halting problem is undecidable.
Dr Linz has a proof for this claim, which can be found here:
<https://john.cs.olemiss.edu/~hcc/csci311/notes/chap12/ch12.pdf>
If the proof is flawless, the conclusion stands and Mr Olcott is simply
wrong.
There is peculiar irony here. The proof is /not/ flawless. It has, in
fact, a flaw that PO pointed out (although in passing). PO does not
care about the flaw because it is easily fixed, but it's there none the
less[1].
Anyway, Linz only gives this argument because it is of historical
interest. His "real" proof immediately follows this argument (in the
book) and is a trivial corollary of the fact, proved in chapter 11, that
not all recursively enumerable languages are recursive. But no crank
ever addresses that proof. I wonder why...
You wasted fifteen years of my life by your change-the-subject
form of rebuttal so I no longer tolerate that from an anyone.
The flaw in all of the conventional proofs is that the
mapping they they DO specify IS NOT the direct execution
of their input.
Everyone moronically ignores how the pathological relationship
between the INPUT and its TERMINATION ANALYZER CHANGES the
behavior OF THE INPUT.
*When HHH emulates DD correctly the emulated DD cannot possibly halt*
THIS IS THE BEHAVIOR OF THE FREAKING INPUT.
That you saw Bill's identical twin brother rob a liquor
store DOES NOT PROVE THAT BILL IS GUILTY.
If anyone would pay any freaking attention THEY WOULD
ALL KNOW THAT I HAVE BEEN CORRECT ABOUT THIS FOR SEVERAL YEARS.
If the proof is flawed through some error of reasoning, *either* it
merely
fails to correctly support its conclusion *or* a duly corrected proof
/overturns/ the conclusion.
... or a duly corrected proof /supports/ the conclusion. Maybe you
intended this possibility to be include in your first "merely fails to
support" alternative.
The latter would be /extremely/ interesting, but it would also mean
that we
have two proofs proving opposite things, and so it would effectively
be a
cataclysmic sideways attack on Turing's reasoning.
It would be a cataclysmic attack on all of conventional mathematics and
logic as two proofs, one of T and another of ~T, makes the system of
proof oneself inconsistent (and everything becomes a theorem).
[1] It centres on the naming of states in H and the derived machines H'
and H^. Details available if you really care.
On 5/1/2025 2:51 AM, Richard Heathfield wrote:
On 30/04/2025 19:30, Mike Terry wrote:
On 30/04/2025 16:46, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott Problem,
which is of interest to nobody but you.
It would be (if correct) attacking the common proof for HP theorem as
it occurs for instance in the Linz book which PO links to from time
to time.
Yes. That's what I call the Olcott Problem.
De gustibus non est disputandum, but I venture to suggest that
(correctly) overturning Turing's proof would be of cosmos-rocking
interest to the world of computer science, compared to which pointing
out a minor flaw in a minor[1] proof would, even if correct, have no
more effect on our field than lobbing a pebble into the swash at high
tide.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
DD correctly simulated by HHH according to the rules of
the x86 language CANNOT POSSIBLY REACH ITS FINAL HALT
STATE NO MATTER WHAT HHH DOES.
Unless we have DD correctly simulated by HHH we do
not have the actual correct mapping of the actual
input to the actual behavior of this actual input.
Unless we have DD correctly simulated by HHH we do
not have the actual correct mapping of the actual
input to the actual behavior of this actual input.
Unless we have DD correctly simulated by HHH we do
not have the actual correct mapping of the actual
input to the actual behavior of this actual input.
Unless we have DD correctly simulated by HHH we do
not have the actual correct mapping of the actual
input to the actual behavior of this actual input.
On 5/1/2025 2:51 AM, Richard Heathfield wrote:
On 30/04/2025 19:30, Mike Terry wrote:
On 30/04/2025 16:46, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it
isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott
Problem, which is of interest to nobody but you.
It would be (if correct) attacking the common proof for HP
theorem as it occurs for instance in the Linz book which PO
links to from time to time.
Yes. That's what I call the Olcott Problem.
De gustibus non est disputandum, but I venture to suggest that
(correctly) overturning Turing's proof would be of
cosmos-rocking interest to the world of computer science,
compared to which pointing out a minor flaw in a minor[1] proof
would, even if correct, have no more effect on our field than
lobbing a pebble into the swash at high tide.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
DD correctly simulated by HHH
according to the rules of
the x86 language CANNOT POSSIBLY REACH ITS FINAL HALT
STATE NO MATTER WHAT HHH DOES.
On 5/1/2025 10:32 AM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 30/04/2025 19:30, Mike Terry wrote:
On 30/04/2025 16:46, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:It would be (if correct) attacking the common proof for HP theorem
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:The domain of HHH is DD.
<snip>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't. >>>>>>
Then it is attacking not the Halting Problem but the Olcott Problem, >>>>> which is of interest to nobody but you.
as it
occurs for instance in the Linz book which PO links to from time to
time.
Yes. That's what I call the Olcott Problem.
De gustibus non est disputandum, but I venture to suggest that
(correctly)
overturning Turing's proof would be of cosmos-rocking interest to the
world
of computer science, compared to which pointing out a minor flaw in a
minor[1] proof would, even if correct, have no more effect on our field
than lobbing a pebble into the swash at high tide.
I suspect that the only reason we bother to argue with Mr Olcott so
much is
because (even if he does so unwittingly) he manages to convey the
appearance of attacking the Halting Problem, and arguing about the
Halting
Problem is a lot more fun than arguing about the Olcott Problem.
To be of any interest, solving the Olcott Problem would have to have
important consequences. But does it? Let's see.
Dr Linz Theorem 12.1 (Halting Problem is Undecidable): There does not
exist
any Turing machine H that behaves as required by Linz Definition
12.1. Thus
the halting problem is undecidable.
Dr Linz has a proof for this claim, which can be found here:
<https://john.cs.olemiss.edu/~hcc/csci311/notes/chap12/ch12.pdf>
If the proof is flawless, the conclusion stands and Mr Olcott is simply
wrong.
There is peculiar irony here. The proof is /not/ flawless. It has, in
fact, a flaw that PO pointed out (although in passing). PO does not
care about the flaw because it is easily fixed, but it's there none the
less[1].
Anyway, Linz only gives this argument because it is of historical
interest. His "real" proof immediately follows this argument (in the
book) and is a trivial corollary of the fact, proved in chapter 11, that
not all recursively enumerable languages are recursive. But no crank
ever addresses that proof. I wonder why...
You wasted fifteen years of my life by your change-the-subject
form of rebuttal so I no longer tolerate that from an anyone.
The flaw in all of the conventional proofs is that the
mapping they they DO specify IS NOT the direct execution
of their input.
Everyone moronically ignores how the pathological relationship
between the INPUT and its TERMINATION ANALYZER CHANGES the
behavior OF THE INPUT.
*When HHH emulates DD correctly the emulated DD cannot possibly halt*
THIS IS THE BEHAVIOR OF THE FREAKING INPUT.
On 5/1/2025 2:51 AM, Richard Heathfield wrote:Repeating meaningless word salad does not prove anything.
On 30/04/2025 19:30, Mike Terry wrote:
On 30/04/2025 16:46, Richard Heathfield wrote:
On 30/04/2025 16:15, olcott wrote:
On 4/29/2025 5:03 PM, Richard Heathfield wrote:
On 29/04/2025 22:38, olcott wrote:
<snip>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.
You're going round the same loop again.
Either your HHH() is a universal termination analyser or it isn't.
The domain of HHH is DD.
Then it is attacking not the Halting Problem but the Olcott Problem,
which is of interest to nobody but you.
It would be (if correct) attacking the common proof for HP theorem as
it occurs for instance in the Linz book which PO links to from time
to time.
Yes. That's what I call the Olcott Problem.
De gustibus non est disputandum, but I venture to suggest that
(correctly) overturning Turing's proof would be of cosmos-rocking
interest to the world of computer science, compared to which pointing
out a minor flaw in a minor[1] proof would, even if correct, have no
more effect on our field than lobbing a pebble into the swash at high
tide.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
DD correctly simulated by HHH according to the rules of
the x86 language CANNOT POSSIBLY REACH ITS FINAL HALT
STATE NO MATTER WHAT HHH DOES.
On 4/29/2025 5:01 AM, Mikko wrote:
On 2025-04-28 16:27:56 +0000, olcott said:
On 4/28/2025 4:14 AM, Mikko wrote:
On 2025-04-26 15:59:39 +0000, olcott said:
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:Not at all. You have simply not been paying enough attention.
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and contradicted
by a good proof.
Some people claim that the unsolvability of the halting problem is >>>>>>>>>> unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that proof of the >>>>>>>> theorem. There are other proofs that you don't even try to refute. >>>>>>>
Once we understand that Turing computable functions are only
allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
Attempt to deceive by a false claim. The term "computable function" is >>>> defined in terms of Turing machines so Turing machines are on topic.
Since there is no universally agreed upon definition
of the Turing Machine language it is impossible to
provide the 100% concrete details in this Turing
Machine language.
Irrelevant. There is sufficient agreement what Turing machines are.
Turing machine computable functions must apply
finite string transformation rues to inputs
to derive outputs.
This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }
On 5/1/2025 10:32 AM, Ben Bacarisse wrote:
Anyway, Linz only gives this argument because it is of historical
interest. His "real" proof immediately follows this argument (in the
book) and is a trivial corollary of the fact, proved in chapter 11, that
not all recursively enumerable languages are recursive. But no crank
ever addresses that proof. I wonder why...
You wasted fifteen years of my life by your change-the-subject
form of rebuttal so I no longer tolerate that from an anyone.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
Changing my words then rebutting these changed
words is dishonest.
Functions computed by Turing Machines require INPUTS
and produce OUTPUTS DERIVED FROM THESE INPUTS.
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN IT
Changing my words then rebutting these changed words is dishonest.
Functions computed by Turing Machines require INPUTS and produce
OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to require an
input.
IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function
given an input of the function domain it can return the corresponding
output.
given an input of the function domain it can return the corresponding
output.
given an input of the function domain it can return the corresponding
output.
*Computer science is ONLY concerned with computable functions*
The function is neither computable nor incomputable because there is no function at all, just a category error.
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:
Changing my words then rebutting these changed
words is dishonest.
Functions computed by Turing Machines require INPUTS
and produce OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any
input whatsoever.
As Mikko rightly said: a Turing machine does not need to
require an input.
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in
computability theory. Computable functions are the formalized
analogue of the intuitive notion of algorithms, in the sense that
a function is computable if there exists an algorithm that can do
the job of the function, i.e. given an input of the function
domain it can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function
*Computer science is ONLY concerned with computable functions*
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is dishonest.
Functions computed by Turing Machines require INPUTS and produce
OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to require an
input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable.
From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN IT
IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the
corresponding output. https://en.wikipedia.org/wiki/Computable_function
That's a very second-rate summary of computability. Turing was far more interested in whether a computation was possible than whether it needed inputs. Do most computations need inputs? Most useful ones that we care about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one incomputable function.
On 5/2/2025 4:16 AM, Mikko wrote:
On 2025-04-30 15:09:45 +0000, olcott said:
On 4/29/2025 5:01 AM, Mikko wrote:
On 2025-04-28 16:27:56 +0000, olcott said:
On 4/28/2025 4:14 AM, Mikko wrote:
On 2025-04-26 15:59:39 +0000, olcott said:Since there is no universally agreed upon definition
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and >>>>>>>>>>>> contradicted
by a good proof.
Some people claim that the unsolvability of the halting >>>>>>>>>>>> problem is
unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that proof >>>>>>>>>> of the
theorem. There are other proofs that you don't even try to >>>>>>>>>> refute.
Not at all. You have simply not been paying enough attention. >>>>>>>>>
Once we understand that Turing computable functions are only >>>>>>>>> allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
Attempt to deceive by a false claim. The term "computable
function" is
defined in terms of Turing machines so Turing machines are on topic. >>>>>
of the Turing Machine language it is impossible to
provide the 100% concrete details in this Turing
Machine language.
Irrelevant. There is sufficient agreement what Turing machines are.
Turing machine computable functions must apply
finite string transformation rues to inputs
to derive outputs.
A Turing machine does not need to require an input.
Changing my words then rebutting these changed
words is dishonest.
Functions computed by Turing Machines require INPUTS
and produce OUTPUTS DERIVED FROM THESE INPUTS.
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:
Changing my words then rebutting these changed
words is dishonest.
Functions computed by Turing Machines require INPUTS
and produce OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to require an
input.
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
given an input of the function domain it can return the corresponding
output.
given an input of the function domain it can return the corresponding
output.
given an input of the function domain it can return the corresponding
output.
*Computer science is ONLY concerned with computable functions*
On 04/05/2025 23:34, Mr Flibble wrote:
The function is neither computable nor incomputable because there is no
function at all, just a category error.
It's a point of view.
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and contradicted >>>>>> by a good proof.
Some people claim that the unsolvability of the halting problem is >>>>>> unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that proof of the
theorem. There are other proofs that you don't even try to refute.
Not at all. You have simply not been paying enough attention.
Once we understand that Turing computable functions are only
allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
On 5/4/2025 5:27 PM, Mr Flibble wrote:
On Sun, 04 May 2025 17:15:04 -0500, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN IT
Changing my words then rebutting these changed words is dishonest.
Functions computed by Turing Machines require INPUTS and produce
OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to require an
input.
IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the
corresponding output. https://en.wikipedia.org/wiki/Computable_function
given an input of the function domain it can return the corresponding
output.
given an input of the function domain it can return the corresponding
output.
given an input of the function domain it can return the corresponding
output.
*Computer science is ONLY concerned with computable functions*
Computer science is also concerned with intractable problems.
/Flibble
I think the computability aspect of computer science
is only concerned with computable functions.
On 5/2/2025 4:16 AM, Mikko wrote:
On 2025-04-30 15:09:45 +0000, olcott said:
On 4/29/2025 5:01 AM, Mikko wrote:
On 2025-04-28 16:27:56 +0000, olcott said:
On 4/28/2025 4:14 AM, Mikko wrote:
On 2025-04-26 15:59:39 +0000, olcott said:Since there is no universally agreed upon definition
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:Not at all. You have simply not been paying enough attention. >>>>>>>>>
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and contradicted
by a good proof.
Some people claim that the unsolvability of the halting problem is >>>>>>>>>>>> unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that proof of the >>>>>>>>>> theorem. There are other proofs that you don't even try to refute. >>>>>>>>>
Once we understand that Turing computable functions are only >>>>>>>>> allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
Attempt to deceive by a false claim. The term "computable function" is >>>>>> defined in terms of Turing machines so Turing machines are on topic. >>>>>
of the Turing Machine language it is impossible to
provide the 100% concrete details in this Turing
Machine language.
Irrelevant. There is sufficient agreement what Turing machines are.
Turing machine computable functions must apply
finite string transformation rues to inputs
to derive outputs.
A Turing machine does not need to require an input.
Changing my words then rebutting these changed
words is dishonest.
Functions computed by Turing Machines require INPUTS
and produce OUTPUTS DERIVED FROM THESE INPUTS.
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is dishonest.
Functions computed by Turing Machines require INPUTS and produce
OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to require an
input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable.
From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is computable. >>
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN IT
IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the
corresponding output. https://en.wikipedia.org/wiki/Computable_function
That's a very second-rate summary of computability. Turing was far more
interested in whether a computation was possible than whether it needed
inputs. Do most computations need inputs? Most useful ones that we care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one incomputable
function.
The function is neither computable nor incomputable because there is no function at all, just a category error.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 04/05/2025 23:34, Mr Flibble wrote:
The function is neither computable nor incomputable because there is no
function at all, just a category error.
It's a point of view.
It's a point of view only in the sense that there is no opinion so daft
that it's not someone's point of view.
On 5/4/2025 9:00 PM, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 04/05/2025 23:34, Mr Flibble wrote:
The function is neither computable nor incomputable because there is no >>>>> function at all, just a category error.
It's a point of view.
It's a point of view only in the sense that there is no opinion so daft
that it's not someone's point of view. The technical-sounding waffle
about it being a "category error" is simply addressed by asking where
the supposed category error is in other perfectly straightforward
undecidable problems. For example, whether or not a context-free
grammar is ambiguous or not, or the very simple to pose Post
correspondence problem.
There's a program called "cksum" that computes a checksum of its input
(not a very secure one, but that's irrelevant). I wonder if Mr Flibble
would consider applying cksum to its own source code, or to its own
executable file, would be a "category error". (The second number is the
size in bytes of the input.)
$ cksum /usr/bin/cksum
1102087032 104984 /usr/bin/cksum
$ cksum src/cksum.c
1844242843 7449 src/cksum.c
There is self-reference and then there is pathological self-reference.
My primary research focus for the last 22 years is the latter.
This sentence has five words. // Is true and not pathological
This sentence is not true. // Is neither true nor false
// because it <is> pathological
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is dishonest. >>>>>>
Functions computed by Turing Machines require INPUTS and produce
OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input >>>>> whatsoever.
As Mikko rightly said: a Turing machine does not need to require an
input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable.
From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is computable. >>>
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN IT >>>> IS NOT COMPUTING FUNCTION THENThat's a very second-rate summary of computability. Turing was far more
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the >>>> corresponding output. https://en.wikipedia.org/wiki/Computable_function >>>
interested in whether a computation was possible than whether it needed
inputs. Do most computations need inputs? Most useful ones that we care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one incomputable
function.
The function is neither computable nor incomputable because there is no
function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
On 5/4/2025 7:21 PM, Richard Damon wrote:
On 5/4/25 6:15 PM, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:
Changing my words then rebutting these changed
words is dishonest.
Functions computed by Turing Machines require INPUTS
and produce OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to require an input. >>>>
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
Right, not all Turing Machine compute Functions, they all do perform
Computations.
Even those that know this pretend that they don't.
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the
corresponding output.
https://en.wikipedia.org/wiki/Computable_function
given an input of the function domain it can return the corresponding output.
Right, and the input to a Halt Decider is the representation of a Program,
Not exactly. It is a 100% specific precise sequence of encoded steps.
Not at all the same as a mere description.
On 5/4/2025 5:27 PM, Mr Flibble wrote:
On Sun, 04 May 2025 17:15:04 -0500, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN IT
Changing my words then rebutting these changed words is dishonest.
Functions computed by Turing Machines require INPUTS and produce
OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to require an
input.
IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the
corresponding output. https://en.wikipedia.org/wiki/Computable_function
given an input of the function domain it can return the corresponding
output.
given an input of the function domain it can return the corresponding
output.
given an input of the function domain it can return the corresponding
output.
*Computer science is ONLY concerned with computable functions*
Computer science is also concerned with intractable problems.
/Flibble
I think the computability aspect of computer science
is only concerned with computable functions.
Computing the mapping from INPUTS to OUTPUTS on
the basis of finite string transformation rules
specified by an algorithm.
The assembly language version of DD is the same
sort of state transition directed graph as the
Linz proof, thus zero vagueness or ambiguity.
DD correctly emulated by HHH CANNOT POSSIBLY
REACH ITS OWN FINAL STATE. Many dozens of
people have been STUPIDLY disagreeing with this
for several years.
On 5/4/2025 7:21 PM, Richard Damon wrote:
On 5/4/25 6:15 PM, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:
Changing my words then rebutting these changed
words is dishonest.
Functions computed by Turing Machines require INPUTS
and produce OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to require an
input.
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
Right, not all Turing Machine compute Functions, they all do perform
Computations.
Even those that know this pretend that they don't.
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return
the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
given an input of the function domain it can return the corresponding
output.
Right, and the input to a Halt Decider is the representation of a
Program,
Not exactly. It is a 100% specific precise sequence of encoded steps.
Not at all the same as a mere description.
and the correct output is based on the behavior of that progrma when run.
It typically precisely coincides with the exact same
behavior as the direct execution.
My idea of a simulating termination analyzer
conclusively proves to all those with great
expertise in programming that this is not
always the case. You seem to lack sufficient
expertise in programming
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
DD correctly simulated by HHH cannot possibly
return anywhere. Most every expert C programmer
knows this.
On 5/4/2025 7:18 PM, Richard Damon wrote:
On 5/4/25 1:55 PM, olcott wrote:
On 5/2/2025 4:16 AM, Mikko wrote:
On 2025-04-30 15:09:45 +0000, olcott said:
On 4/29/2025 5:01 AM, Mikko wrote:
On 2025-04-28 16:27:56 +0000, olcott said:Turing machine computable functions must apply
On 4/28/2025 4:14 AM, Mikko wrote:
On 2025-04-26 15:59:39 +0000, olcott said:
On 4/26/2025 3:19 AM, Mikko wrote:
On 2025-04-25 16:31:58 +0000, olcott said:
On 4/25/2025 3:46 AM, Mikko wrote:
On 2025-04-24 15:11:13 +0000, olcott said:
On 4/23/2025 3:52 AM, Mikko wrote:
On 2025-04-21 23:52:15 +0000, olcott said:
Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.
Others can see that their justification is defective and >>>>>>>>>>>>>> contradicted
by a good proof.
Some people claim that the unsolvability of the halting >>>>>>>>>>>>>> problem is
unproven but nobody has solved the problem.
For the last 22 years I have only been refuting the
conventional Halting Problem proof.
Trying to refute. You have not shown any defect in that >>>>>>>>>>>> proof of the
theorem. There are other proofs that you don't even try to >>>>>>>>>>>> refute.
Not at all. You have simply not been paying enough attention. >>>>>>>>>>>
Once we understand that Turing computable functions are only >>>>>>>>>>> allowed
Turing allowed Turing machines to do whatever they can do.
Strawman deception error of changing the subject away
from computable functions.
Attempt to deceive by a false claim. The term "computable
function" is
defined in terms of Turing machines so Turing machines are on
topic.
Since there is no universally agreed upon definition
of the Turing Machine language it is impossible to
provide the 100% concrete details in this Turing
Machine language.
Irrelevant. There is sufficient agreement what Turing machines are. >>>>>
finite string transformation rues to inputs
to derive outputs.
A Turing machine does not need to require an input.
Changing my words then rebutting these changed
words is dishonest.
Functions computed by Turing Machines require INPUTS
and produce OUTPUTS DERIVED FROM THESE INPUTS.
Right, and for the Turing Machine to correctly compute a Function, its
computed mapping must match the mapping defined by the function.
That is correct. You and I agree more on these aspects
than anyone else. You seems to be very intelligent
in some very important things.
THe Halting Function, which a Halting Decider is to compute, is the
mapping of a Program (or its representation) to whether that Program
will Halt when run.
That is not the way that these mappings work.
They ONLY works on finite string inputs. They
never ever work directly on any executable program.
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is dishonest. >>>>>>
Functions computed by Turing Machines require INPUTS and produce
OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input >>>>> whatsoever.
As Mikko rightly said: a Turing machine does not need to require an
input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable.
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN IT >>>> IS NOT COMPUTING FUNCTION THENThat's a very second-rate summary of computability. Turing was far more
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the >>>> corresponding output. https://en.wikipedia.org/wiki/Computable_function >>>
interested in whether a computation was possible than whether it needed
inputs. Do most computations need inputs? Most useful ones that we care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one incomputable
function.
The function is neither computable nor incomputable because there is no
function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
On 5/5/2025 8:19 PM, Richard Damon wrote:
On 5/4/25 8:35 PM, olcott wrote:
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is dishonest. >>>>>>>>
Functions computed by Turing Machines require INPUTS and produce >>>>>>>> OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input >>>>>>> whatsoever.
As Mikko rightly said: a Turing machine does not need to require an >>>>>>> input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable.
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION
THEN IT
IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in computability >>>>>> theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the >>>>>> function, i.e. given an input of the function domain it can return >>>>>> the
corresponding output. https://en.wikipedia.org/wiki/
Computable_function
That's a very second-rate summary of computability. Turing was far
more
interested in whether a computation was possible than whether it
needed
inputs. Do most computations need inputs? Most useful ones that we
care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one incomputable >>>>> function.
The function is neither computable nor incomputable because there is no >>>> function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
Except that isn't the question that is being asked.
In fact, that question has a trivial answer, as we can make an H0 that
just aborts its emulation and returns 0 and it is correct by your
definition,
No that is stupidly wrong as I have said at least 100 times recently.
The termination analyzer must compute the mapping from the input
on the basis of the behavior that this input actually specifies.
On 5/5/2025 8:19 PM, Richard Damon wrote:
On 5/4/25 8:35 PM, olcott wrote:
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is dishonest. >>>>>>>>
Functions computed by Turing Machines require INPUTS and produce >>>>>>>> OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input >>>>>>> whatsoever.
As Mikko rightly said: a Turing machine does not need to require an >>>>>>> input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable.
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN IT >>>>>> IS NOT COMPUTING FUNCTION THENThat's a very second-rate summary of computability. Turing was far more >>>>> interested in whether a computation was possible than whether it needed >>>>> inputs. Do most computations need inputs? Most useful ones that we care >>>>> about, sure. But all? By no means.
Computable functions are the basic objects of study in computability >>>>>> theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the >>>>>> function, i.e. given an input of the function domain it can return the >>>>>> corresponding output. https://en.wikipedia.org/wiki/ Computable_function >>>>>
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one incomputable >>>>> function.
The function is neither computable nor incomputable because there is no >>>> function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
Except that isn't the question that is being asked.
In fact, that question has a trivial answer, as we can make an H0 that
just aborts its emulation and returns 0 and it is correct by your
definition,
No that is stupidly wrong as I have said at least 100 times recently.
The termination analyzer must compute the mapping from the input
on the basis of the behavior that this input actually specifies.
On 5/5/2025 8:19 PM, Richard Damon wrote:
On 5/4/25 8:35 PM, olcott wrote:
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is dishonest. >>>>>>>>
Functions computed by Turing Machines require INPUTS and produce >>>>>>>> OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input >>>>>>> whatsoever.
As Mikko rightly said: a Turing machine does not need to require an >>>>>>> input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable.
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION
THEN IT
IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in computability >>>>>> theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the >>>>>> function, i.e. given an input of the function domain it can return >>>>>> the
corresponding output. https://en.wikipedia.org/wiki/
Computable_function
That's a very second-rate summary of computability. Turing was far
more
interested in whether a computation was possible than whether it
needed
inputs. Do most computations need inputs? Most useful ones that we
care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one incomputable >>>>> function.
The function is neither computable nor incomputable because there is no >>>> function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
Except that isn't the question that is being asked.
In fact, that question has a trivial answer, as we can make an H0 that
just aborts its emulation and returns 0 and it is correct by your
definition,
No that is stupidly wrong as I have said at least 100 times recently.
The termination analyzer must compute the mapping from the input
on the basis of the behavior that this input actually specifies.
On 5/6/2025 6:29 AM, Richard Damon wrote:And the actual input specifies a halting program, as is proven when
On 5/5/25 10:32 PM, olcott wrote:
On 5/5/2025 8:19 PM, Richard Damon wrote:
On 5/4/25 8:35 PM, olcott wrote:
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is
dishonest.
Functions computed by Turing Machines require INPUTS and produce >>>>>>>>>> OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any >>>>>>>>> input
whatsoever.
As Mikko rightly said: a Turing machine does not need to
require an
input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable. >>>>>>>
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is >>>>>>> computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION >>>>>>>> THEN IT
IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in
computability
theory. Computable functions are the formalized analogue of the >>>>>>>> intuitive notion of algorithms, in the sense that a function is >>>>>>>> computable if there exists an algorithm that can do the job of the >>>>>>>> function, i.e. given an input of the function domain it can
return the
corresponding output. https://en.wikipedia.org/wiki/
Computable_function
That's a very second-rate summary of computability. Turing was
far more
interested in whether a computation was possible than whether it >>>>>>> needed
inputs. Do most computations need inputs? Most useful ones that
we care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one
incomputable
function.
The function is neither computable nor incomputable because there
is no
function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
Except that isn't the question that is being asked.
In fact, that question has a trivial answer, as we can make an H0
that just aborts its emulation and returns 0 and it is correct by
your definition,
No that is stupidly wrong as I have said at least 100 times recently.
The termination analyzer must compute the mapping from the input
on the basis of the behavior that this input actually specifies.
Which *IS* by the DEFINITION of the problem, the behavior of the
program the input represents when run.
That is not how it actually works.
A function computed by a model of
computation must compute the mapping
FROM THE ACTUAL INPUT.
On 5/6/2025 6:29 AM, Richard Damon wrote:
On 5/5/25 10:32 PM, olcott wrote:
On 5/5/2025 8:19 PM, Richard Damon wrote:
On 5/4/25 8:35 PM, olcott wrote:
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is
dishonest.
Functions computed by Turing Machines require INPUTS and produce >>>>>>>>>> OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any >>>>>>>>> input
whatsoever.
As Mikko rightly said: a Turing machine does not need to
require an
input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable. >>>>>>>
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is >>>>>>> computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION >>>>>>>> THEN IT
IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in
computability
theory. Computable functions are the formalized analogue of the >>>>>>>> intuitive notion of algorithms, in the sense that a function is >>>>>>>> computable if there exists an algorithm that can do the job of the >>>>>>>> function, i.e. given an input of the function domain it can
return the
corresponding output. https://en.wikipedia.org/wiki/
Computable_function
That's a very second-rate summary of computability. Turing was
far more
interested in whether a computation was possible than whether it >>>>>>> needed
inputs. Do most computations need inputs? Most useful ones that
we care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one
incomputable
function.
The function is neither computable nor incomputable because there
is no
function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
Except that isn't the question that is being asked.
In fact, that question has a trivial answer, as we can make an H0
that just aborts its emulation and returns 0 and it is correct by
your definition,
No that is stupidly wrong as I have said at least 100 times recently.
The termination analyzer must compute the mapping from the input
on the basis of the behavior that this input actually specifies.
Which *IS* by the DEFINITION of the problem, the behavior of the
program the input represents when run.
That is not how it actually works.
A function computed by a model of
computation must compute the mapping
FROM THE ACTUAL INPUT.
If the definition of the problem says
differently THEN IT IS WRONG!
On 5/6/2025 3:24 AM, Mikko wrote:
On 2025-05-06 02:32:01 +0000, olcott said:
On 5/5/2025 8:19 PM, Richard Damon wrote:
On 5/4/25 8:35 PM, olcott wrote:
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is
dishonest.
Functions computed by Turing Machines require INPUTS and produce >>>>>>>>>> OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any >>>>>>>>> input
whatsoever.
As Mikko rightly said: a Turing machine does not need to
require an
input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable. >>>>>>>
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is >>>>>>> computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION >>>>>>>> THEN IT
IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in
computability
theory. Computable functions are the formalized analogue of the >>>>>>>> intuitive notion of algorithms, in the sense that a function is >>>>>>>> computable if there exists an algorithm that can do the job of the >>>>>>>> function, i.e. given an input of the function domain it can
return the
corresponding output. https://en.wikipedia.org/wiki/
Computable_function
That's a very second-rate summary of computability. Turing was
far more
interested in whether a computation was possible than whether it >>>>>>> needed
inputs. Do most computations need inputs? Most useful ones that
we care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one
incomputable
function.
The function is neither computable nor incomputable because there
is no
function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
Except that isn't the question that is being asked.
In fact, that question has a trivial answer, as we can make an H0
that just aborts its emulation and returns 0 and it is correct by
your definition,
No that is stupidly wrong as I have said at least 100 times recently.
The termination analyzer must compute the mapping from the input
on the basis of the behavior that this input actually specifies.
You often say so and you often say otherwise. More specifically, you
have said that is correct to call the actual input non-halting if a
hypothetical non-decider would correctly decide that a hypthetical
input would not halt.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its
   input D until H correctly determines that its simulated D
   *would never stop running unless aborted* then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*would never stop running unless aborted*
looks at the actual input D and reports on the basis
of a hypothetical H/D pair where H does not abort.
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
_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]
DD emulated by HHH according to the rules of the
x86 language cannot possibly reach past its own
machine address [0000213c].
On 5/6/2025 2:01 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 19:34 schreef olcott:
On 5/6/2025 6:29 AM, Richard Damon wrote:And the actual input specifies a halting program,
On 5/5/25 10:32 PM, olcott wrote:
On 5/5/2025 8:19 PM, Richard Damon wrote:
On 5/4/25 8:35 PM, olcott wrote:
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is >>>>>>>>>>>> dishonest.
Functions computed by Turing Machines require INPUTS and >>>>>>>>>>>> produce
OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without >>>>>>>>>>> any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to >>>>>>>>>>> require an
input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is
computable.
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is >>>>>>>>> computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION >>>>>>>>>> THEN IT
IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in
computability
theory. Computable functions are the formalized analogue of the >>>>>>>>>> intuitive notion of algorithms, in the sense that a function is >>>>>>>>>> computable if there exists an algorithm that can do the job of >>>>>>>>>> the
function, i.e. given an input of the function domain it can >>>>>>>>>> return the
corresponding output. https://en.wikipedia.org/wiki/
Computable_function
That's a very second-rate summary of computability. Turing was >>>>>>>>> far more
interested in whether a computation was possible than whether >>>>>>>>> it needed
inputs. Do most computations need inputs? Most useful ones that >>>>>>>>> we care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions* >>>>>>>>>Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function. >>>>>>>>> Therefore computer science is concerned with at least one
incomputable
function.
The function is neither computable nor incomputable because
there is no
function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
Except that isn't the question that is being asked.
In fact, that question has a trivial answer, as we can make an H0
that just aborts its emulation and returns 0 and it is correct by
your definition,
No that is stupidly wrong as I have said at least 100 times recently. >>>>> The termination analyzer must compute the mapping from the input
on the basis of the behavior that this input actually specifies.
Which *IS* by the DEFINITION of the problem, the behavior of the
program the input represents when run.
That is not how it actually works.
A function computed by a model of
computation must compute the mapping
FROM THE ACTUAL INPUT.
Counter-factual
That you don't have a clue about the x86 language
is far less than no rebuttal at all.
On 5/6/2025 3:24 AM, Mikko wrote:
On 2025-05-06 02:32:01 +0000, olcott said:
On 5/5/2025 8:19 PM, Richard Damon wrote:
On 5/4/25 8:35 PM, olcott wrote:
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is dishonest. >>>>>>>>>>
Functions computed by Turing Machines require INPUTS and produce >>>>>>>>>> OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without any input >>>>>>>>> whatsoever.
As Mikko rightly said: a Turing machine does not need to require an >>>>>>>>> input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is computable. >>>>>>>
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION THEN IT >>>>>>>> IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in computability >>>>>>>> theory. Computable functions are the formalized analogue of the >>>>>>>> intuitive notion of algorithms, in the sense that a function is >>>>>>>> computable if there exists an algorithm that can do the job of the >>>>>>>> function, i.e. given an input of the function domain it can return the >>>>>>>> corresponding output. https://en.wikipedia.org/wiki/ Computable_function
That's a very second-rate summary of computability. Turing was far more >>>>>>> interested in whether a computation was possible than whether it needed >>>>>>> inputs. Do most computations need inputs? Most useful ones that we care >>>>>>> about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions*
Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function.
Therefore computer science is concerned with at least one incomputable >>>>>>> function.
The function is neither computable nor incomputable because there is no >>>>>> function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
Except that isn't the question that is being asked.
In fact, that question has a trivial answer, as we can make an H0 that >>>> just aborts its emulation and returns 0 and it is correct by your
definition,
No that is stupidly wrong as I have said at least 100 times recently.
The termination analyzer must compute the mapping from the input
on the basis of the behavior that this input actually specifies.
You often say so and you often say otherwise. More specifically, you
have said that is correct to call the actual input non-halting if a
hypothetical non-decider would correctly decide that a hypthetical
input would not halt.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*would never stop running unless aborted*
looks at the actual input D and reports on the basis
of a hypothetical H/D pair where H does not abort.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
_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]
DD emulated by HHH according to the rules of the
x86 language cannot possibly reach past its own
machine address [0000213c].
On 5/6/2025 2:01 PM, Fred. Zwarts wrote:No relevant information. No rebuttal.
Op 06.mei.2025 om 19:34 schreef olcott:
On 5/6/2025 6:29 AM, Richard Damon wrote:And the actual input specifies a halting program,
On 5/5/25 10:32 PM, olcott wrote:
On 5/5/2025 8:19 PM, Richard Damon wrote:
On 5/4/25 8:35 PM, olcott wrote:
On 5/4/2025 5:34 PM, Mr Flibble wrote:
On Sun, 04 May 2025 23:30:54 +0100, Richard Heathfield wrote:
On 04/05/2025 23:15, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:IT IS NOT COMPUTING FUNCTION THEN
Changing my words then rebutting these changed words is >>>>>>>>>>>> dishonest.
Functions computed by Turing Machines require INPUTS and >>>>>>>>>>>> produce
OUTPUTS DERIVED FROM THESE INPUTS.
Counter-example: a Turing Machine can calculate pi without >>>>>>>>>>> any input
whatsoever.
As Mikko rightly said: a Turing machine does not need to >>>>>>>>>>> require an
input.
Quoth Alan Turing:
(viii) The limit of a computably convergent sequence is
computable.
 From (viii) and TT— 4(1—i-|--i—...) we deduce that TT is >>>>>>>>> computable.
No input required.
IT IS NOT COMPUTING FUNCTION THEN IT IS NOT COMPUTING FUNCTION >>>>>>>>>> THEN IT
IS NOT COMPUTING FUNCTION THEN
Computable functions are the basic objects of study in
computability
theory. Computable functions are the formalized analogue of the >>>>>>>>>> intuitive notion of algorithms, in the sense that a function is >>>>>>>>>> computable if there exists an algorithm that can do the job of >>>>>>>>>> the
function, i.e. given an input of the function domain it can >>>>>>>>>> return the
corresponding output. https://en.wikipedia.org/wiki/
Computable_function
That's a very second-rate summary of computability. Turing was >>>>>>>>> far more
interested in whether a computation was possible than whether >>>>>>>>> it needed
inputs. Do most computations need inputs? Most useful ones that >>>>>>>>> we care
about, sure. But all? By no means.
*Computer science is ONLY concerned with computable functions* >>>>>>>>>Computer science is concerned with the Halting Problem.
The Halting Problem is concerned with an incomputable function. >>>>>>>>> Therefore computer science is concerned with at least one
incomputable
function.
The function is neither computable nor incomputable because
there is no
function at all, just a category error.
/Flibble
You can look at it that way or you can look
at it as simulating termination analyzer HHH(DD)
does correctly determine that DD cannot possibly
reach its own final state, thus is correctly
rejected as non-halting.
Except that isn't the question that is being asked.
In fact, that question has a trivial answer, as we can make an H0
that just aborts its emulation and returns 0 and it is correct by
your definition,
No that is stupidly wrong as I have said at least 100 times recently. >>>>> The termination analyzer must compute the mapping from the input
on the basis of the behavior that this input actually specifies.
Which *IS* by the DEFINITION of the problem, the behavior of the
program the input represents when run.
That is not how it actually works.
A function computed by a model of
computation must compute the mapping
FROM THE ACTUAL INPUT.
Counter-factual
That you don't have a clue about the x86 language
is far less than no rebuttal at all.
On 28/04/2025 06:22, vallor wrote:
On Sun, 27 Apr 2025 21:06:29 -0400, Richard Damon
<richard@damon-family.org> wrote in
<8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>:
Which is just an admission that your HHH's are not actual correct
emulator, and you can only apply that statement in the version of your
claims where you retract your claim about Halt7.c being part of the
system (as then then is one and only one HHH), and thus your DD just
is not a program unless you include HHH as part of it, and thus each
is a DIFFFERENT input.
Sorry to butt in...
Where does one find this Halt7.c?
<https://github.com/plolcott/x86utm>
(If you're expecting something amazing, prepare yourself for a disappointment.)
On Mon, 28 Apr 2025 07:40:12 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote in <vun7sc$2fjjl$3@dont-email.me>:
On 28/04/2025 06:22, vallor wrote:
On Sun, 27 Apr 2025 21:06:29 -0400, Richard Damon
<richard@damon-family.org> wrote in
<8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>:
Which is just an admission that your HHH's are not actual correct
emulator, and you can only apply that statement in the version of your >>>> claims where you retract your claim about Halt7.c being part of the
system (as then then is one and only one HHH), and thus your DD just
is not a program unless you include HHH as part of it, and thus each
is a DIFFFERENT input.
Sorry to butt in...
Where does one find this Halt7.c?
<https://github.com/plolcott/x86utm>
(If you're expecting something amazing, prepare yourself for a
disappointment.)
Thank you.
Looks complicated. Appears to obfuscate the issue.
On Mon, 28 Apr 2025 07:40:12 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote in <vun7sc$2fjjl$3@dont-email.me>:
On 28/04/2025 06:22, vallor wrote:
On Sun, 27 Apr 2025 21:06:29 -0400, Richard Damon
<richard@damon-family.org> wrote in
<8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>:
Which is just an admission that your HHH's are not actual correct
emulator, and you can only apply that statement in the version of
your claims where you retract your claim about Halt7.c being part of
the system (as then then is one and only one HHH), and thus your DD
just is not a program unless you include HHH as part of it, and thus
each is a DIFFFERENT input.
Sorry to butt in...
Where does one find this Halt7.c?
<https://github.com/plolcott/x86utm>
(If you're expecting something amazing, prepare yourself for a
disappointment.)
Thank you.
Looks complicated. Appears to obfuscate the issue.
On 13/05/2025 11:32, vallor wrote:
On Mon, 28 Apr 2025 07:40:12 +0100, Richard Heathfield
<rjh@cpax.org.uk>
wrote in <vun7sc$2fjjl$3@dont-email.me>:
On 28/04/2025 06:22, vallor wrote:
On Sun, 27 Apr 2025 21:06:29 -0400, Richard Damon
<richard@damon-family.org> wrote in
<8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>:
Which is just an admission that your HHH's are not actual correct
emulator, and you can only apply that statement in the version of
your claims where you retract your claim about Halt7.c being part of >>>>> the system (as then then is one and only one HHH), and thus your DD
just is not a program unless you include HHH as part of it, and thus >>>>> each is a DIFFFERENT input.
Sorry to butt in...
Where does one find this Halt7.c?
<https://github.com/plolcott/x86utm>
(If you're expecting something amazing, prepare yourself for a
disappointment.)
Thank you.
Looks complicated. Appears to obfuscate the issue.
It is and it does, but it turns out not to matter.
What might be rather more interesting is... Well, maybe I'll complete
that thought offline.
On Tue, 13 May 2025 10:32:48 -0000 (UTC), vallor <vallor@cultnix.org>
wrote in <vvv74g$1mff2$1@dont-email.me>:
On Mon, 28 Apr 2025 07:40:12 +0100, Richard Heathfield <rjh@cpax.org.uk>
wrote in <vun7sc$2fjjl$3@dont-email.me>:
On 28/04/2025 06:22, vallor wrote:
On Sun, 27 Apr 2025 21:06:29 -0400, Richard Damon
<richard@damon-family.org> wrote in
<8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>:
Which is just an admission that your HHH's are not actual correct
emulator, and you can only apply that statement in the version of
your claims where you retract your claim about Halt7.c being part of >>>>> the system (as then then is one and only one HHH), and thus your DD
just is not a program unless you include HHH as part of it, and thus >>>>> each is a DIFFFERENT input.
Sorry to butt in...
Where does one find this Halt7.c?
<https://github.com/plolcott/x86utm>
(If you're expecting something amazing, prepare yourself for a
disappointment.)
Thank you.
Looks complicated. Appears to obfuscate the issue.
So to get it to compile -m32 with its included headers, I have to
do this:
*DON'T DO THIS*
On 5/13/2025 5:32 AM, vallor wrote:
On Mon, 28 Apr 2025 07:40:12 +0100, Richard Heathfield <rjh@cpax.org.uk>
wrote in <vun7sc$2fjjl$3@dont-email.me>:
On 28/04/2025 06:22, vallor wrote:
On Sun, 27 Apr 2025 21:06:29 -0400, Richard Damon
<richard@damon-family.org> wrote in
<8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>:
Which is just an admission that your HHH's are not actual correct
emulator, and you can only apply that statement in the version of your >>>>> claims where you retract your claim about Halt7.c being part of the
system (as then then is one and only one HHH), and thus your DD just >>>>> is not a program unless you include HHH as part of it, and thus each >>>>> is a DIFFFERENT input.
Sorry to butt in...
Where does one find this Halt7.c?
<https://github.com/plolcott/x86utm>
(If you're expecting something amazing, prepare yourself for a
disappointment.)
Thank you.
Looks complicated. Appears to obfuscate the issue.
The x86utm operating system allows any C function
to emulate the x86 machine code of any other C
function in debug step mode.
Halt7.c uses the x86utm operating system
to derive several termination analyzers.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 166:57:42 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,529 |