On Saturday, 16 April 2022 at 16:48:51 UTC+1, olcott wrote:
On 4/16/2022 10:35 AM, Malcolm McLean wrote:I suggest you try this site.
On Saturday, 16 April 2022 at 15:42:22 UTC+1, olcott wrote:People that are honest can see that the meaning of my words proves that
On 4/16/2022 8:59 AM, Malcolm McLean wrote:You should try to write a few Turing machines, however. An "even/odd" decider
On Saturday, 16 April 2022 at 14:31:29 UTC+1, B.H. wrote:My big issue with Turing machines is that none of them can move the tape >>>> head more than one position at a time. This makes them intolerably
On Friday, April 15, 2022 at 11:51:24 PM UTC-4, Jeff Barnett wrote: >>>>>>I don't think PO is trolling. He's too persistent for that. And sometimes he
There is absolutely no reason to believe that idiot is dying at an >>>>>>> accelerated rate. He is a troll who lies about everything if it will >>>>>> You think there is no such thing as cancer?it so irritating to you? You would likely be able to generate more threads
drag a dialogue partner along. But I do believe that he is dying of >>>>>>> laughter at all the nonsense threads he can generate and support. It >>>>>> What's wrong with that, why is that a rule, and even if it is a rule, why is
if you didn't look like a cantakerous jerk, although maybe you would prefer
to do it your way. Your way of acting and presenting yourself, regardless
of what you think inwardly in your mind and don't say, isn't up to me, it is
your choice.
sure doesn't mean his brain is actually working; it probably isn't and >>>>>>> he is auto deluded or it is and he is an utter fool.His brain sounds fine to me.
makes errors that that make him look foolish, such as saying that a Turing
machine needs 1000 states to move the head 1000 steps. That goes against >>>>> trollish psychology.
tedious for expressing any significant algorithm.
shouldn't be too tedious to write. It's hard to present youself as an expert on
Turing machines if you've never constructed one.
I am correct. If they are not paying enough attention to the meaning of
my words because they do not believe that I have credibility this too is
dishonesty on their part.
The even odd decider would require me to carefully study this 15 pages
of text: http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
https://turingmachinesimulator.com/
If you've problems with the syntax, I'm sure that there will be plenty of people
here happy to help. It doesn't require reading a lot of instructions.
"B.H." <xlt.pjw@gmail.com> writes:
On Friday, April 15, 2022 at 9:21:53 PM UTC-4, Ben wrote:
"B.H." <xlt...@gmail.com> writes:
On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:It's a typedef name. There was another post where I included the
"B.H." <xlt...@gmail.com> writes:
On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:By returning false. The key case PO obsesses about is H(P,P) with P
It is a sufficient reason to say that H is non-halting, but how would >>>>>> H, the algorithm itself, report that?
defined as, very roughly
void P(ptr x) { if (H(x, x)) while (1); }
PO tells us, contrary to the facts, that H(P,P) == false is correct even >>>>> though P(P) obviously "halts" (i.e. returns in this C formulation).
Although I am not familiar with the idea of inputting functions to
functions in C, and have never seen "ptr" as the syntax for pointers
definition, but since PO uses an integer, the type is not agreed upon.
Hence the "very roughly".
(I don't like pointers and haven't used them in a while, but usually I >>>> used * in school), but you would appear to have said somethingH is supposed to be a halt decider (if only for this one case) so it
incorrect...it looks like P(P) would not halt because H, presumably a
direct simulator of P on P until P halts on its input, would never
halt, thus P would never return at all...it would never halt.
must return. The one thing it can't do is act like a pure simulator.
PO does sometimes flip to claiming that the call to H in P won't return
(while saying that a top-level call will) but that's really just a case
of PO saying what's needed to get out of a bind. H must return the same
result, for the same arguments values, no matter where it is called from. >>>> Ahh, the thrill of victory...it's like playing Pendulum Castle [1],
but easier, from Super Mario once again.What victory?
The victory of accuracy. I won, the concession is implicit; it's a
proof by inspection. You might want to concede to avoid getting
pegged as "an Obama-oid."
I am very happy for you. Do you now see why PO is wrong?
olcott <NoOne@NoWhere.com> writes:
On 4/15/2022 5:31 PM, Ben wrote:
"B.H." <xlt.pjw@gmail.com> writes:
On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:By returning false. The key case PO obsesses about is H(P,P) with P
It is a sufficient reason to say that H is non-halting, but how would
H, the algorithm itself, report that?
defined as, very roughly
void P(ptr x) { if (H(x, x)) while (1); }
PO tells us, contrary to the facts, that H(P,P) == false is correct even >>> though P(P) obviously "halts" (i.e. returns in this C formulation).
The fact that the input to H(P,P) is non-halting is complete proof
that H(P,P)===false is correct by logical necessity.
Changing the words from those of the problem you have claimed to
addressing for 18 years suggests you are up to something. Fortunately
you were clear a few years ago so we know what you are up to.
On Saturday, April 16, 2022 at 11:40:20 PM UTC-4, olcott wrote:
If the input to H(P,P) is non-halting then H(P,P)==false is necessary
correct.
True. *if* the input to H(P,P) is non-halting then H(P,P)==false is correct. But first we must establish whether the input to H(P,P) is non-halting.
We simply hypothesize BOTH cases:
Does anyone have a rebuttal to that one, or do you acknowledge that it
is correct?
You must find an example where {an X is a Y} and Z is incorrect for
reporting {an X is a Y}.
If no one can show that the correctly simulated input to H(P,P) reaches
its final state and halts that proves that it is non-halting.
If I was wrong then the correct simulation of the 27 bytes of machine
code at machine address [000009d6] by H would show some correct
execution trace from machine address [000009d6] ending at machine
address [000009f0].
_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]
Since an H that never aborts is an uninteresting case,
On Sunday, April 17, 2022 at 2:55:12 PM UTC-4, olcott wrote:the input to Hb(Pa,Pa), which is the same as the input to Ha(Pa,Pa), is halting and therefore that Ha is incorrect to reject it.
On 4/17/2022 1:47 PM, Dennis Bush wrote:
On Sunday, April 17, 2022 at 2:43:00 PM UTC-4, olcott wrote:Yes. If the correctly simulated input to a SHD cannot reach its own
On 4/17/2022 1:38 PM, Dennis Bush wrote:
On Sunday, April 17, 2022 at 2:33:01 PM UTC-4, olcott wrote:On 4/17/2022 1:32 PM, olcott wrote:
On 4/17/2022 1:26 PM, Dennis Bush wrote:
On Sunday, April 17, 2022 at 2:07:15 PM UTC-4, olcott wrote:If the correctly simulated input to any simulating halt decider would >>>>>> never reach its own final state then this SHD would always be correct to >>>>>> reject this input.
On 4/17/2022 12:35 PM, Dennis Bush wrote:
On Sunday, April 17, 2022 at 12:23:16 PM UTC-4, olcott wrote: >>>>>>>>>> On 4/17/2022 11:12 AM, Dennis Bush wrote:I have conclusively proved that the correct simulation of the input to >>>>>>>> H(P,P) would never reach its own final state whether or not H aborts the
On Sunday, April 17, 2022 at 12:06:31 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 4/17/2022 10:59 AM, Dennis Bush wrote:That would be the way a God damned liar would say it.
So in other words you're considering the behavior of two separate unrelated computations that deceptively happen to share the same set of function names and happen to live at the same set of addresses when built separately.On Sunday, April 17, 2022 at 11:49:56 AM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 4/17/2022 10:41 AM, Dennis Bush wrote:_P()
On Sunday, April 17, 2022 at 11:25:37 AM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 4/17/2022 10:11 AM, Dennis Bush wrote:No stupid I am not. I am talking about the above fixed P, and two
If you're talking about a fixed P at a fixed address, that means you are also talking about ONE SPECIFIC H at a specific address with a fixed, unchanging algorithm.On Sunday, April 17, 2022 at 12:26:51 AM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>>> On 4/16/2022 11:14 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>> On Saturday, April 16, 2022 at 11:40:20 PM UTC-4, olcott wrote:None-the-less I count this as significant progress. It may have been
I count this as excellent progress.If the input to H(P,P) is non-halting then H(P,P)==false is necessary
correct.
True. *if* the input to H(P,P) is non-halting then H(P,P)==false is correct. But first we must establish whether the input to H(P,P) is non-halting.
This has never been in dispute, by me or anyone else. The fact that you think this shows how poor your reading comprehension is.
nearly the first time that anyone has ever agreed with anything that I
have ever said in this forum.
We really only need to answer this single question: >>>>>>>>>>>>>>>> Is there any case where the correctly simulated input to H(P,P) reaches
Those two cases means you're changing the code of H, which means that P becomes a completely different computation.(a) aborted and
Does anyone have a rebuttal to that one, or do you acknowledge that it
is correct?
You must find an example where {an X is a Y} and Z is incorrect for
reporting {an X is a Y}.
If no one can show that the correctly simulated input to H(P,P) reaches
its final state and halts that proves that it is non-halting.
If I was wrong then the correct simulation of the 27 bytes of machine
code at machine address [000009d6] by H would show some correct
execution trace from machine address [000009d6] ending at machine
address [000009f0].
_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>> [000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>> [000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call // call H >>>>>>>>>>>>>>>>>>>> [000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]
Since an H that never aborts is an uninteresting case, >>>>>>>>>>>>>>>>>> We simply hypothesize BOTH cases:
(b) never aborted
and then see where their execution traces would be. >>>>>>>>>>>>>>>>>
its own machine address of [000009f0]?
H either aborts the simulation of its input or does not abort the
simulation of its input. In either case the execution trace never
extends beyond machine address [000009e1].
Thus we can see that whether or not H aborts the simulation of its input
this simulated input never reaches machine address [000009f0]. >>>>>>>>>>>>>>>
different hypothetical scenarios of H at machine address [00000826].
So you're dishonestly changing the algorithm of H to make two different P's look the same. They are not.
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]
I am considering the behavior of the simulated P under two hypothetical
scenarios:
(1) H at machine address [00000826] aborts its simulation. >>>>>>>>>>>> (2) H at machine address [00000826] does not abort its simulation. >>>>>>>>>>>
I am only considering the actual behavior of the simulated input to >>>>>>>>>> H(P,P) under the two possible scenarios. In each of these two possible
scenarios P never reaches its own final state.
In other words, you're considering whether Hn can simulate Pn to a final state, and *independently* whether Ha can simulate Pa to a final state.
Pn and Pa are not the same. Pn(Pn) does not halt. Pa(Pa) halts. Hn(Pn,Pn) never stops running so it can't answer. The simulation Ha(Pa,Pa) is not simulated to a final state but the simulation Hb(Pa,Pa) *is* simulated to a final state.
Therefore Ha(Pa,Pa) == false is incorrect.
simulation of its input.
FALSE. At most, you have shown that no H can simulate the P built from it to a final state. This is not the same as non-halting. Just because H1(P1,P1)==false and H2(P2,P2)==false and so forth doesn't mean that they all give the correct answer.
So now you're back to "if X then Y" without establishing whether X is true. I.E. you made a non-statement that makes no attempt at refuting what I said.
computation that halts … the Turing machine will haltSure that is what a God damned liar would say when they simply erase the >>>> part that proved my point.
whenever it enters a final state. (Linz:1990:234)
It doesn't prove your point. My point still stands.
If a simulating halt decider simulates its input to a final state, this is conclusive proof that the input is halting.
final state then this input is non-halting.
_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]
The correctly simulated input to H(P,P) continues to execute
instructions from [000009d6] to [000009e1] never reaching [000009f0].
Ha(Pa,Pa) does *not* perform a correct simulation of its input because it aborts too soon. Hb(Pa,Pa) performs a correct simulation of this same input by remaining in UTM mode as it simulates its input to a final state. This conclusively proves that
olcott <NoOne@NoWhere.com> writes:
On 4/18/2022 4:53 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/17/2022 6:43 PM, Ben wrote:Deflection. As I said, if you were right you'd publish the code. You
olcott <NoOne@NoWhere.com> writes:
On 4/17/2022 10:20 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
If I was wrong then the correct simulation of the 27 bytes of machine >>>>>>>> code...
If you were right you'd publish the code.
This is the only relevant code to the question does the correctly
simulated input to H(P,P) halt?
Clearly not. The code for P is not in doubt.
So then you must agree that when H correctly simulates the input to
H(P,P) that it would never reach its own final state.
pointlessly showed P which is not in doubt. I can only assume you know
that if you publish H the game will be well and truly up. You need to
trot out one of your excuses for keeping the flawed code secret.
I am going to continue to present this same point until everyone
reading this forum realizes that the only reason that you dodge it is
because you already know that it is correct.
Everyone here has seen me address it many times and has seen you ignore
what I've said about it many times. Do you really think anyone will
change their option of me just because you keep typing the same vague sentence? And, more to the point, why do you care what people think of
me?
What you need is someone you trust to tell you to do something useful
with your time, not some way to get "everyone reading this forum" to
form your preferred opinion of me. I am not that important.
When the input to H(P,P) is non halting then it is necessarily correct
for H to report that the input to H(P,P) is non halting.
On more time: H(P,P) has no input.
If you mean the two pointer
parameters, say so. That "input" -- those two pointers -- are neither halting nor non halting. Maybe you mean calling the first with the
second as its only argument is non halting?
If you do, you are
(according to other posts of yours) wrong. Say what you mean, or accept
that honest commentators will have to explain your words back to you.
At least you've removed the "would" and you have stopped using the
unclear "it" and "its".
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
You say that P(P) halts, but the correctly simulated input to H(P,P)
does not halt. You've been pretty consistent on this point. But I'm
still mystified. I've made a suggestion that might resolve the obvious
contradiction, but it hasn't been accepted.
PO has reached the stage where his only option is to be unclear.
On Wednesday, 20 April 2022 at 20:49:35 UTC+1, olcott wrote:
On 4/20/2022 2:44 PM, olcott wrote:You have never published H, so we can't verify anything.
On 4/20/2022 2:30 PM, Malcolm McLean wrote:If I smash a Boston cream pie in someones face and they have a
On Wednesday, 20 April 2022 at 19:10:37 UTC+1, olcott wrote:
On 4/20/2022 12:51 PM, Malcolm McLean wrote:You say that P(P) halts, but the correctly simulated input to H(P,P) does >>>> not halt. You've been pretty consistent on this point.
On Wednesday, 20 April 2022 at 18:35:43 UTC+1, olcott wrote:The only relevant point is that the correctly simulated P simulated by H >>>>> cannot possibly reach its own final state under any condition
On 4/19/2022 9:49 AM, Ben wrote:Machine code is tree-like in structure. I particular, in your
olcott <No...@NoWhere.com> writes:According to functional notation the inputs to a function are its >>>>>>> parameters.
On 4/18/2022 4:53 PM, Ben wrote:
olcott <No...@NoWhere.com> writes:I am going to continue to present this same point until everyone >>>>>>>>> reading this forum realizes that the only reason that you dodge >>>>>>>>> it is
On 4/17/2022 6:43 PM, Ben wrote:Deflection. As I said, if you were right you'd publish the code. >>>>>>>>>> You
olcott <No...@NoWhere.com> writes:
On 4/17/2022 10:20 AM, Ben wrote:
olcott <No...@NoWhere.com> writes:
If I was wrong then the correct simulation of the 27 bytes >>>>>>>>>>>>>>> of machine
code...
If you were right you'd publish the code.
This is the only relevant code to the question does the >>>>>>>>>>>>> correctly
simulated input to H(P,P) halt?
Clearly not. The code for P is not in doubt.
So then you must agree that when H correctly simulates the >>>>>>>>>>> input to
H(P,P) that it would never reach its own final state.
pointlessly showed P which is not in doubt. I can only assume >>>>>>>>>> you know
that if you publish H the game will be well and truly up. You >>>>>>>>>> need to
trot out one of your excuses for keeping the flawed code secret. >>>>>>>>>
because you already know that it is correct.
Everyone here has seen me address it many times and has seen you >>>>>>>> ignore
what I've said about it many times. Do you really think anyone will >>>>>>>> change their option of me just because you keep typing the same vague >>>>>>>> sentence? And, more to the point, why do you care what people
think of
me?
What you need is someone you trust to tell you to do something useful >>>>>>>> with your time, not some way to get "everyone reading this forum" to >>>>>>>> form your preferred opinion of me. I am not that important.
When the input to H(P,P) is non halting then it is necessarily >>>>>>>>> correct
for H to report that the input to H(P,P) is non halting.
On more time: H(P,P) has no input.
Function notation is a way to write functions that is easy to read and >>>>>>> understand. Functions have dependent and independent variables, and >>>>>>> when
we use function notation the independent variable is commonly x, >>>>>>> and the
dependent variable is F(x).
https://www.brightstorm.com/math/algebra/graphs-and-functions/function-notation/#:~:text=Function%20notation%20is%20a%20way,variable%20is%20F(x).
When we construe H(P,P) as a computable function then H computes the >>>>>>> mapping from its inputs/parameters to its own accept of reject state, >>>>>>> thus you "rebuttal" is merely double-talk misdirection.
If you mean the two pointerThe finite string of machine code pointed to by P.
parameters, say so. That "input" -- those two pointers -- are neither >>>>>>>> halting nor non halting. Maybe you mean calling the first with the >>>>>>>> second as its only argument is non halting?
system, the "string of
machine code pointed to by P" contains a call to H.
Now are you excluding that code in H from "the input to H(P,P)?".
what-so-ever thus conclusively fails to meet the Linz criteria of a
halting computation thus is definitively determined to be a non-halting >>>>> sequence of configurations.
If {an X is a Y} "the input to H(P,P) is non-halting"
then it is necessarily correct for Z to report that {an X is a Y} "H >>>>> reports that its input is non-halting"
But I'm still mystified. I've made a suggestion that might resolve the >>>> obvious
contradiction, but it hasn't been accepted.
It is an empirically proved verified fact that the input to H(P,P) does
not halt so anyone and anything disagreeing is necessarily incorrect.
fundamental religious belief that there is no such thing as pies the pie
dripping from their face conclusively proves that they are incorrect.
The verified fact that the input to H(P,P) is non-halting is the pie
dripping from the face.
I do believe you
when you say that P(P) halts and H(P,P) reports "non-halting". The question which everyone is asking is how you get from that fact to the claim that
"The input to H(P,P) is non-halting".
As I said, I suspect that the reason is confusion, and the root of the confusion
is that you are using an x86 emulator to make statements about Turing machines.
Using an x86 emulator instead a Turing machine isn't of itself fatal to your project, but it opens the way for all sorts of errors that using Turing machines
themselves would avoid. So really I urge you to learn more about Turing machines.
On 4/21/2022 2:10 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/21/2022 1:08 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/20/2022 7:17 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/20/2022 4:46 PM, Ben wrote:So you won't say? That figures. Not saying what you mean is all you >>>>>> have left...
olcott <NoOne@NoWhere.com> writes:
On 4/20/2022 3:24 PM, Ben wrote:guessing)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:THAT YOU SAY THIS IS UNCLEAR IS A FALSEHOOD IT HAS ZERO AMBIGUITY: >>>>>>>> Of course it's ambiguous. Some people have determined (by
You say that P(P) halts, but the correctly simulated input to >>>>>>>>>>> H(P,P)PO has reached the stage where his only option is to be unclear. >>>>>>>>>
does not halt. You've been pretty consistent on this point. >>>>>>>>>>> But I'm
still mystified. I've made a suggestion that might resolve >>>>>>>>>>> the obvious
contradiction, but it hasn't been accepted.
that you mean that P(P) is non halting. But you reject that and >>>>>>>> anyway
you tell us that P(P) halts so that can't be what you mean. I >>>>>>>> prefer
not to guess because I think you are deliberately not saying
what you
mean by simulating two pointers. Go on, explain it -- what does >>>>>>>> it mean
to simulate the two pointers P and P?
The simulated input to H(P,P) never reaches its last instruction at >>>>>>> machine address [000009f0].
I have already fully proved my point to everyone that is very familiar >>>>> with the interface between C and x86 which is apparently no one here >>>>> besides me.
So what now? Publish? Fame? Fortune? Or keep posting here to chat >>>> with people you think are liars? Let me guess...
That everyone here claims that I am wrong knowing full well that they
have no idea what I am saying because they don't know the first thing
about the x86 language is still a lie.
It seems you won't address even a simple question put to you like "what
now?". I know you think everyone here is ignorant and deliberately
lying, but since that is your view I wonder what your plan is.
Continue to refine my words until one or more qualified reviewers accept
that I am correct.
HERE IS THE INTRO:
To fully understand this paper a software engineer must be an expert in
the C programming language, the x86 programming language, exactly how C translates into x86 and what an x86 process emulator is. No knowledge of
the halting problem is required.
Unbelievably it appears to be to continue to chat away with this bunch
of ignorant liars. How do you think that will help other than satisfy
your apparent desire which is to be chat about your "discoveries"?
I was aiming for the point where my words become so clear that even my
lying reviewers won't lie because it will be far too obvious that they
are lying making their lie unbearably denigrating to themselves.
You pretend to want to publish and be famous, but even you should be
able to see that talking to a bunch of ignorant lairs isn't going to
help you. In fact, it makes your supposed intent seem less that honest.
The fact that it has helped tremendously proves that it was always a
good idea.
olcott <NoOne@NoWhere.com> writes:
On 4/21/2022 4:33 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
Read my addendum.You haven't cited anyone without their permission have you?
THIS IS THE ADDENDUM
On 4/21/2022 2:45 PM, olcott wrote:
If we merely eliminate all of the reviews of my work on comp.theory my
current paper or anything remotely as good would have been infeasible.
Most of the reviewers did initially have a much better understanding of
the halting problem than I had. In the last month or two places have
switched.
A halt decider computes the mapping from its input finite strings to its >>> own accept or reject state on the basis of the actual behavior of its
correctly simulated input.
Unfortunate that you boast like that, but it's to be expected. At least
you don't name anyone as having helped you.
Still, I expect there's a few years more chatting to be done before you
get to an editor's day.
On Friday, 22 April 2022 at 00:19:50 UTC+1, olcott wrote:
On 4/21/2022 6:10 PM, Ben wrote:The halting problem applies to x86 programs as well as to Turing machines,
olcott <No...@NoWhere.com> writes:I am writing it up so that software engineers can validate it without
On 4/21/2022 4:33 PM, Ben wrote:
olcott <No...@NoWhere.com> writes:
Read my addendum.You haven't cited anyone without their permission have you?
THIS IS THE ADDENDUM
On 4/21/2022 2:45 PM, olcott wrote:
If we merely eliminate all of the reviews of my work on comp.theory my >>>>> current paper or anything remotely as good would have been infeasible. >>>>>
Most of the reviewers did initially have a much better understanding of >>>>> the halting problem than I had. In the last month or two places have >>>>> switched.
A halt decider computes the mapping from its input finite strings to its >>>>> own accept or reject state on the basis of the actual behavior of its >>>>> correctly simulated input.
Unfortunate that you boast like that, but it's to be expected. At least
you don't name anyone as having helped you.
Still, I expect there's a few years more chatting to be done before you
get to an editor's day.
any knowledge of the halting problem. I translate the key computer
science terminology into software engineering terms.
To fully understand this paper a software engineer must be an expert in
the C programming language, the x86 programming language, exactly how C
translates into x86 and what an x86 process emulator is. No knowledge of
the halting problem is required.
The computer science term “halting” means that a Turing Machine
terminated normally reaching its last instruction known as its “final
state”. This is the same idea as when a function returns to its caller
as opposed to and contrast with getting stuck in an infinite loop or
infinite recursion.
so it's not inherently an error to work with x86 code. However it can cause confusion, and in fact it is causing confusion. For instance, if you make
H a simulating halt decider, there is no infinite recursion and no simple infinite loop in Linz's H_Hat<H_Hat> system . What you get instead is nested emulation, which may or may not be infinite. Since a Turing machine has no subroutines, if you stick to Turing machines, you are not in danger of making this mistake.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 427 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 35:18:07 |
| Calls: | 9,029 |
| Calls today: | 12 |
| Files: | 13,384 |
| Messages: | 6,008,861 |