- The key aspects of x86utm are now finally complete [ defining a non-halting decider ] - 7 Updates
- Architectural design of a halting problem solution - 12 Updates
- SOLUTION TO THE HALTING PROBLEM! - 1 Update
- A non-halting decider is defined - 5 Updates
| olcott <NoOne@NoWhere.com>: Oct 28 06:31PM -0500 On 10/28/2020 4:57 AM, Malcolm McLean wrote: > to deciders which are Turing machines. And it's possible to trivially modify > the proof to show that the halt-decider element of the almost-halt decider > has a case it can't decide. I defined a NON_HALTING decider that always Accepts NON_HALTING input and Rejects HALTING input. The NON_HALTING decider UTM executes its subordinate UTM one state transition at a time until it detects non-halting behavior or its subordinate UTM has terminated normally. If the halt decider UTM detects non-halting behavior of its subordinate UTM it simply stops executing the subordinate and transitions to its own final state of ABORTED_NON_TERMINATING_BEHAVIOR. If the subordinate UTM terminates normally the halt decider UTM transitions to its own final state of SUBORDINATE_HAS_TERMINATED. > Linz, or if it is a component of H. We haven't actually had a H, H_Hat pair. I've > suggested stubbing Aborted_Beacuse_Non_Halting_Behaviour_Detected, but the > suggestion hasn't been taken up. Maybe my latest words are easier to understand (see above). >> machines [...] and encoded pairs <...>.) > Two actual Turing machines would be more impressive. If you make H subtly > different from a Turing machine, then Linz's proof doesn't apply. Not having random access makes Turing machines much more tedious than mowing five acres of grass with finger nail clippers. x86 language ≡ von Neumann architecture ≡ UTM -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 27 01:36PM -0500 On 10/27/2020 11:53 AM, Malcolm McLean wrote: > Do you agree that AbortedBecauseNonHaltingBehaviourDetected() can be > stubbed to deal only with the input H_Hat, H_Hat? Or does this change > somethin fundamental? It is no good to merely stub this function when the complete description of the execution trace showing exactly how (H_Hat, H_Hat) is decided correctly has already been provided. Instead of a stub function we could simply assume that: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M); always returns a correct result meaning that it: "only aborts its input and returns true when it detects the non halting behavior of its input" and otherwise returns false. Then we try to do the same thing as the conventional halting problem proofs and see if there is any input that it cannot correctly decide. -- Copyright 2020 Pete Olcott |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 27 12:53PM -0600 On 2020-10-27 09:20, olcott wrote: > Here is what I can commit to: > There is no input to this function that can be shown to be undecidable: > bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) Are you attempting to answer my first question or my third question here? Saying no input is undecidable would seem to be an answer to my third question. It doesn't seem to have any relevance to my first question. > terminate. H_Hat(H_Hat) is yet another example where > bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) > decides its input correctly. So when we consider H(H_Hat, H_HAT) what are you claiming is the output of: (1) Your ABNHBD contained in H (2) Your ABNHBD contained in the outermost instance of H_Hat? > bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) > is a partial WOULD_NOT_HALT decider that will initially only decide > (H_Hat, H_Hat). This contradicts your earlier claim that no input to this function can be undecidable. Are you here claiming that there *are* inputs that aren't decidable, or that there are currently inputs that are not *correctly* decidable? André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 27 02:44PM -0500 On 10/27/2020 2:05 PM, Malcolm McLean wrote: >> proofs and see if there is any input that it cannot correctly decide. > As I understand it, instead of HALTS / RUNSFOREVER it returns > HALTS / ABORTED. We can explore the difference. New thread: (explores the difference) [Architectural design of a halting problem solution] -- Copyright 2020 Pete Olcott |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 27 01:57PM -0600 On 2020-10-27 10:05, olcott wrote: > show one architectural design of a halt decider that gets the wrong > answer some of the time. My architectural design of a halt decider > cannot be shown to get the wrong answer any of the time. Linz doesn't specify anything at all about the 'architectural design' of H. All he does is claim that H is a halt decider; it's internal workings are left entirely unspecified. He shows that for *any* given H it is possible to derive a second TM, H_Hat, such that if the description of H_Hat is used as the input to H, H will not be able to correctly decide whether H_Hat halts. There's absolutely *no* assumptions made about the internal workings / 'architectural design' of H. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| Mostowski Collapse <janburse@fastmail.fm>: Oct 27 09:07PM +0100 In what parallel universum does your nonsense have anything to do with Prolog? You fucking inhibited cross posting moron? No need to post responses on comp.lang.prolog. olcott schrieb: |
| olcott <NoOne@NoWhere.com>: Oct 29 07:55AM -0500 On 10/28/2020 7:02 PM, Ben Bacarisse wrote: >> and Rejects HALTING input. > And again you are vague! It's not clear if this is deliberate or simply > a consequence of the fact that you have trouble being precise. This is not vague: Intuitively, a decider should be a Turing machine that given an input, halts and either accepts or rejects, relaying its answer in one of many equivalent ways, such as halting at an ACCEPT or REJECT state, or leaving its answer on the output tape.Yuval Filmus https://cs.stackexchange.com/questions/84433/what-is-decider Yuval Filmus top 0.04% overall Assistant Professor in the Department of Computer Science at the Technion. A non-halting decider can be defined that always Accepts NON_HALTING input and Rejects HALTING input as follows: The NON_HALTING decider UTM executes its subordinate TM/UTM one state transition at a time until it detects non-halting behavior or its subordinate UTM has terminated normally. If the halt decider UTM detects non-halting behavior of its subordinate TM/UTM it simply stops executing the subordinate and transitions to its own final state of NON_TERMINATING_BEHAVIOR_DETECTED. If the subordinate TM/UTM terminates normally the halt decider UTM transitions to its own final state of SUBORDINATE_HAS_TERMINATED. > and the third could be true of an x86 program but is not true for yours. > (And you are using the equivalence symbol poetically. While the x86 is > a von Neumann architecture, the reverse is not true.) x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine The RASP is a random-access machine (RAM) model that, unlike the RAM, has its program in its "registers" together with its input. The registers are unbounded (infinite in capacity); whether the number of registers is finite is model-specific. Thus the RASP is to the RAM as the Universal Turing machine is to the Turing machine. The RASP is an example of the von Neumann architecture whereas the RAM is an example of the Harvard architecture. https://en.wikipedia.org/wiki/Random-access_stored-program_machine -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 28 09:09PM -0500 On 10/28/2020 12:55 AM, André G. Isaak wrote: > the outmost H_Hat does indeed halt, so if the ABNHBD invoked in H > returns ABORTED then it is getting the wrong answer! > André This function can not be shown to have any undecidable inputs: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) int main() { H_Hat(H_Hat); } Can you tell that the outer H_Hat(H_Hat) in main() is not an input to: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) ??? When H_Hat(H_Hat) invokes: Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) it would never terminate unless the H_Hat input to H_Hat was aborted. So this statement is literally true: This function can not be shown to have any undecidable inputs: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) because the outer H_Hat in main() IS NOT AN INPUT !!! -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 28 12:31AM -0500 On 10/28/2020 12:25 AM, André G. Isaak wrote: >> invocation. > So the answer to (2) is that it returns ABORTED. > That doesn't answer my question (1). What does your ABNHBD in H return? bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) always returns true in the outermost instance of its recursive invocation. Do you think that always means once in a while? -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 27 03:13PM -0500 On 10/27/2020 3:03 PM, Mike Terry wrote: > decidable, including many whose domain is the same as that halting > problem's. Possibly if you made the definition of the your decision > well defined, it could be one of those... I have redefined the impossible halt decider into a NON_HALTING_DECIDER that divides all of its inputs into: (a) INPUT_PROGRAM_ABORTED_BECAUSE_NON_HALTING_BEHAVIOR_DETECTED (b) INPUT_PROGRAM_HAS_TERMINATED As you can see from (b) the NON_HALTING_DECIDER is still a halt decider. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 27 04:23PM -0500 On 10/27/2020 3:34 PM, André G. Isaak wrote: > If your (a) and (b) are simply new names for 'doesn't halt' and 'halts', > then this is just as subject to Linz's proof as any other purported halt > decider. I dared anyone to show this and they absolutely could not because it is impossible. > If they are not, and there are cases where 'aborted' and 'halted' don't > mean exactly the same thing, then what you have isn't a halt decider at > all. The above two sets are the exact same sets that a correct halt decider would decide. > A halt decider determines if a particular TM, T, will halt for input I. Apparently it is much easier to decide the cases that would not halt unless aborted and leave the halting cases as those that are left over. > IOW, it tells us something about the behaviour of T when confronted with > input I. bool Aborted_Because_Non_Halting_Behavior_Detected(u32 T, u32 I) Try and find a (T, I) pair that the above function cannot correctly decide. By correctly decide what I mean is the totally obvious: The above function returns true and this sentence is true: "T was aborted because non halting behavior was detected." bool Aborted_Because_Non_Halting_Behavior_Detected(u32 T, u32 I) would be incorrect when it returns true and: (a) The input program was not aborted. (b) Non-halting behavior was not detected. (c) Non-halting behavior was erronesously reported. (d) The input program was aborted and the halt decider correctly detected non-halting behavior of the input program, yet the input program was aborted for some other reason besides the fact that non-halting behavior was detected. > already run T(I). That still tells us that T(I) halts, but we could have > just run T(I) ourselves to make this determination, so your > 'redefinition' doesn't provide us with any useful information in this case. You must not have through that one through very well. The NON_HALTING_DECIDER screens out all of the infinite executions. > have done it in some sort of specialized environment E in which it is > possible to force things to abort. Therefore, your 'revision' is asking > how T behaves when confronted with input I IN ENVIRONMENT E. No, not really, not at all. bool Aborted_Because_Non_Halting_Behavior_Detected(u32 T, u32 I) only aborts the execution of programs that would not otherwise halt. If H_Hat(H_Hat) did not have any of its otherwise infinitely recursive invocations terminated it would never stop running. void H_Hat(u32 M) { if (Aborted_Because_Non_Halting_Behavior_Detected(M, M)) MOV_EAX_1 // Execution of M(M) has been aborted else { MOV_EAX_0 // M(M) has halted HERE: goto HERE; } HALT } int main() { u32 M = (u32)H_Hat; H_Hat(M); HALT } > us about T or about E in cases where the input is forced to terminate. > What you have isn't analogous to a halt decider. It is a > How-does-this-TM-behave-in-environment-E decider. No, not at all, not in the least. bool Aborted_Because_Non_Halting_Behavior_Detected(u32 T, u32 I) only aborts the execution of programs that would not otherwise halt. > behave in environment E (or environment E at all, for that matter), this > isn't something that is of interest. > André The following definition shows that it is not any specialied environment it is merely the conventional notion of a UTM. The redefined halt decider UTM executes its subordinate UTM one state transition at a time until it detects non-halting behavior or its subordinate UTM has terminated normally. If the halt decider UTM detects non-halting behavior of its subordinate UTM it simply stops executing the subordinate and transitions to its own final state of ABORTED_NON_TERMINATING_BEHAVIOR. If the subordinate UTM terminates normally the halt decider UTM transitions to its own final state of SUBORDINATE_HAS_TERMINATED. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 27 04:54PM -0500 On 10/27/2020 4:44 PM, Malcolm McLean wrote: >> input has already halted. > So write a stub for bool Aborted_Because_Non_Halting_Behavior_Detected > that just works on the input H_Hat, H_Hat. That would be no better than telling people that I must be correct because I really know that I am right, the same petitio principii logical fallacy that they are using in their utterly vacuous rebuttals. I simply have to finish writing the actual halt deciding code for bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat). I already totally explained (2018-12-13 solution) exactly how this works. -- Copyright 2020 Pete Olcott |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 27 01:46PM -0600 On 2020-10-27 13:30, olcott wrote: > The halt decider divides all of its inputs into: > (a) HALTS > (b) DOES_NOT_HALT That isn't an 'architectural design'. That's simply a definition of what a halt decider does. Anything which does not do the above is not a halt decider. The above says nothing whatsoever about 'architectural design'. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 27 02:30PM -0500 Intuitively, a decider should be a Turing machine that given an input, halts and either accepts or rejects, relaying its answer in one of many equivalent ways, such as halting at an ACCEPT or REJECT state, or leaving its answer on the output tape.Yuval Filmus https://cs.stackexchange.com/questions/84433/what-is-decider Yuval Filmus top 0.04% overall Assistant Professor in the Department of Computer Science at the Technion. It is common knowledge that a halt decider with the following architectural design can be thwarted by an input program that does the opposite of whatever the halt decider decides: The halt decider divides all of its inputs into: (a) HALTS (b) DOES_NOT_HALT This brand new architectural design cannot be thwarted by the conventional self-referential halting problem trick. With this design there is no input that can be shown to be undecidable: The halt decider that divides all of its inputs into: (a) INPUT_PROGRAM_ABORTED_BECAUSE_NON_HALTING_BEHAVIOR_DETECTED (b) INPUT_PROGRAM_HAS_TERMINATED The redefined halt decider UTM executes its subordinate UTM one state transition at a time until it detects non-halting behavior or its subordinate UTM has terminated normally. If the halt decider UTM detects non-halting behavior of its subordinate UTM it simply stops executing the subordinate and transitions to its own final state of ABORTED_NON_TERMINATING_BEHAVIOR. If the subordinate UTM terminates normally the halt decider UTM transitions to its own final state of SUBORDINATE_HAS_TERMINATED. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 27 03:02PM -0500 On 10/27/2020 2:46 PM, André G. Isaak wrote: >> (b) DOES_NOT_HALT > That isn't an 'architectural design'. That's simply a definition of what > a halt decider does. Then my solution can be called a redefinition: The halt decider that divides all of its inputs into: (a) INPUT_PROGRAM_ABORTED_BECAUSE_NON_HALTING_BEHAVIOR_DETECTED (b) INPUT_PROGRAM_HAS_TERMINATED > Anything which does not do the above is not a halt > decider. The above says nothing whatsoever about 'architectural design'. > André Then we can call it the definition of a NON_HALTING_DECIDER. None of its inputs would halt unless it aborts their execution and all of the rest of its inputs would halt. -- Copyright 2020 Pete Olcott |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 27 02:34PM -0600 On 2020-10-27 14:13, olcott wrote: > (a) INPUT_PROGRAM_ABORTED_BECAUSE_NON_HALTING_BEHAVIOR_DETECTED > (b) INPUT_PROGRAM_HAS_TERMINATED > As you can see from (b) the NON_HALTING_DECIDER is still a halt decider. If your (a) and (b) are simply new names for 'doesn't halt' and 'halts', then this is just as subject to Linz's proof as any other purported halt decider. If they are not, and there are cases where 'aborted' and 'halted' don't mean exactly the same thing, then what you have isn't a halt decider at all. A halt decider determines if a particular TM, T, will halt for input I. IOW, it tells us something about the behaviour of T when confronted with input I. Part (b) of your 'redefinition' presupposes that we have actually already run T(I). That still tells us that T(I) halts, but we could have just run T(I) ourselves to make this determination, so your 'redefinition' doesn't provide us with any useful information in this case. Part (a) of your redefinition is where things really get mucked up since it presupposes that we have already attempted to run T(I); moreover, we have done it in some sort of specialized environment E in which it is possible to force things to abort. Therefore, your 'revision' is asking how T behaves when confronted with input I IN ENVIRONMENT E. Whereas the actual definition of a halt decider tells us about T, in your 'revised' version we have no way of knowing whether it is telling us about T or about E in cases where the input is forced to terminate. What you have isn't analogous to a halt decider. It is a How-does-this-TM-behave-in-environment-E decider. Unless you can provide some reason why I should care about how things behave in environment E (or environment E at all, for that matter), this isn't something that is of interest. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 29 07:18AM -0500 On 10/29/2020 1:45 AM, André G. Isaak wrote: > answer. > André > [groups trimmed] On the top of page 320 H_Hat is applied to itself: http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 29 07:28AM -0500 On 10/29/2020 1:59 AM, Alan Mackenzie wrote: >> It cannot be shown that it ever decides its input incorrectly. > You're like a loop of tape. You're all output with no input. Why don't > you actually consider the points people are making? All but one of the points that people are making have been shown to be incorrect and people simply ignored that they have been proved wrong. I am showing that the remaining unaddressed point is incorrect too (see below). > returns a wrong answer, there are cases in which it will return _no_ > answer at all; it will carry on executing without ever stopping or > displaying "non-halting behaviour" (whatever that means). This cannot be proven. If a machine is proven to never repeat the same state and this machine is also proven to never terminate a very smart halt decider could replicate the proof of non-termination, stop executing its input and report non-halting. Alternatively it cannot be proven that there is any program that meets those specs thus it cannot be proven that a counter-example exists. > no such examples, complex or not. This will necessarily involve you > getting to know some mathematics. Hint: this has been shown not to be > possible. My categorical has already been provided. I just addressed the last unaddressed point. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 29 07:35AM -0500 On 10/29/2020 7:28 AM, olcott wrote: > executing its input and report non-halting. > Alternatively it cannot be proven that there is any program that meets > those specs thus it cannot be proven that a counter-example exists. If it can be proved that such a counter-example exists then it is not a counter-example, otherwise it cannot be proved that such a counter example exists. Any program that can be proved does not halt can be decided on the basis of this proof. Every counter-example must be provably undecidable. >> possible. > My categorical has already been provided. I just addressed the last > unaddressed point. My categorical PROOF has already been provided. I just addressed the last unaddressed point. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 29 07:14AM -0500 On 10/29/2020 1:13 AM, Graham Cooper wrote: > loops(loops) > if halt( loops loops)-X then loops(loops) > halt doesn't return TRUE or FALSE though, it goes into an infinite loop at X I spent a man year developing the x86utm operating system so that I could show every single detailed step of exactly how and why the Linz halt decider halts in its ((qn)) state. x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine The reason that a halt decider can actually decide that the Linz H_Hat does not halt is based on the fact that it gets stuck in infinite recursion before it ever reaches its undecidable states. We can tell that it gets stuck in infinite recursion because it invokes the halt decider a second time from the same machine address without any conditional instructions in its execution trace in-between that would terminate this otherwise infinite recursion. I derived this solution 2018-12-13 @ 7:00 PM. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 28 06:43PM -0500 Intuitively, a decider should be a Turing machine that given an input, halts and either accepts or rejects, relaying its answer in one of many equivalent ways, such as halting at an ACCEPT or REJECT state, or leaving its answer on the output tape.Yuval Filmus https://cs.stackexchange.com/questions/84433/what-is-decider Yuval Filmus top 0.04% overall Assistant Professor in the Department of Computer Science at the Technion. A non-halting decider can be defined that always Accepts NON_HALTING input and Rejects HALTING input as follows: The NON_HALTING decider UTM executes its subordinate UTM one state transition at a time until it detects non-halting behavior or its subordinate UTM has terminated normally. If the halt decider UTM detects non-halting behavior of its subordinate UTM it simply stops executing the subordinate and transitions to its own final state of NON_TERMINATING_BEHAVIOR_DETECTED. If the subordinate UTM terminates normally the halt decider UTM transitions to its own final state of SUBORDINATE_HAS_TERMINATED. -- Copyright 2020 Pete Olcott |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 28 06:43PM -0700 On Wednesday, October 28, 2020 at 7:43:31 PM UTC-4, olcott wrote: > Intuitively, a decider should be a Turing machine that given an input, > halts Also intuitively, olcott should be smart enough to know how to stop cross posting to comp.lang.c++, but it seems that this is not so ... Daniel |
| olcott <NoOne@NoWhere.com>: Oct 29 12:00AM -0500 > Also intuitively, olcott should be smart enough to know how to stop > cross posting to comp.lang.c++, but it seems that this is not so ... > Daniel My following has tripled because of my cross-posting. I just solved the halting problem thus changing a basic foundation of computer science. I need my work vetted before I can present it at a higher level. As soon as this work is confirmed or refuted I will quit cross-posting. -- Copyright 2020 Pete Olcott |
| David Brown <david.brown@hesbynett.no>: Oct 29 08:37AM +0100 On 29/10/2020 06:00, olcott wrote: >> cross posting to comp.lang.c++, but it seems that this is not so ... >> Daniel > My following has tripled because of my cross-posting. The number of people who get irritated and have to ignore your ridiculous unwanted and off-topic ramblings has more than tripled since your cross-posting. Here's a clue for you and your fantasies about having a "following" - when the most likely person to respond to your posts is /you/, it's time to realise you are an antisocial fanatic with an obsession not shared by others. There is an appropriate way to handle this. Get a /blog/. It's simple and free. You can reach a vastly wider audience - not just the old greybeards that still use Usenet, but everyone that can use Google. You get the space to expand on your ideas, maybe add diagrams, organise your thoughts. You don't have to keep repeating yourself on each post. I look forward to seeing a /single/ thread in the future with the simple message, "I've got a blog here ... ". Your followers will follow you, and the rest of Usenet can be a little happier. Everyone wins. > I just solved the halting problem thus changing a basic foundation of > computer science. That should be worth a good deal of fame and fortune. It would certainly be worth a doctorate. Contact a university. Write a real paper on it, and put it on your blog. I for one would read such a paper - but not your Usenet threads where every thought in your head dribbles out in a random order. If you have come up with a proof that is so significant to the entire field, deal with it /properly/. > I need my work vetted before I can present it at a higher level. This is not the place to do it. This is a group for C++ programmers (and comp.lang.c is for C programmers), not theoretical computer scientists. Even for those with theoretical training and interest (including me), this is a useless medium for something like this. You want to talk to academics in an appropriate university department, not people who'd rather discuss the legality of "void main();". > As soon as this work is confirmed or refuted I will quit cross-posting. You are making some extraordinary claims. Extraordinary claims require extraordinary evidence. You can't present such evidence in this medium. Write a paper - call it a draft. Put it on a blog. Ask for comments in comp.theory, and work from there. But /please/ stop cross-posting. It does not help you in any way, and it most certainly irritates other people. |
| olcott <NoOne@NoWhere.com>: Oct 29 07:04AM -0500 On 10/29/2020 2:37 AM, David Brown wrote: > comp.theory, and work from there. > But /please/ stop cross-posting. It does not help you in any way, and > it most certainly irritates other people. It really seems to me that my claim is either so obviously correct that it can be readily accepted as true or so obviously incorrect that it can be easily refuted. All it takes is one of these and I will stop cross-posting. -- Copyright 2020 Pete Olcott |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment