On 4/26/2025 1:26 PM, Fred. Zwarts wrote:No, it doesn't, as you can't have an infinte series of a function that has been defined to be a specific instance.Op 26.apr.2025 om 19:29 schreef olcott:Mathematical induction proves that DD emulated byOn 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: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 youWhen you try to actually show the actual steps instead of being stuck in
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,
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.
And, when you remove that stipulation, you are either talking about the behavior of a non-orogram that doens't have behavior, or each case in your claimed induction is looking at a DIFFERENT input, and thus the induction fails to do what you want, and just proves the point you are trying to refute, that there can not exist a decider based on your HHH template that gets the right answer, no matter how many steps it runs.
Several C programmer immediately spotted thisAnd many more see the errors in the logic and point it out,
and agree to it.
You can't respond to those errors.
| Date | Sujet | # | Auteur | |
| 21 Jul 26 |  … |
Les messages affichés proviennent d'usenet.