| olcott <polcott2@gmail.com>: Oct 08 07:18PM -0500 Once one accepts the notion of a simulating halt decider that continues to correctly simulate its input until it correctly determines that the this simulated input would never stop running then the conventional halting problem proofs are refuted. typedef void (*ptr)(); int H(ptr p, ptr i); // simulating halt decider // P does the opposite of whatever H decides void P(ptr x) { int Halt_Status = H(x, x); if (Halt_Status) // if H(P,P) reports that its input halts HERE: goto HERE; // P loops and never halts return; // else P halts } int main() { Output("Input_Halts = ", H(P, P)); } Complete halt deciding system (Visual Studio Project) (a) x86utm operating system (b) x86 emulator adapted from libx86emu to compile under Windows (c) Several halt deciders and their sample inputs contained within Halt7.c https://liarparadox.org/2022_09_07.zip -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Muttley@dastardlyhq.com: Oct 09 09:23AM On Sat, 8 Oct 2022 19:18:40 -0500 >Once one accepts the notion of a simulating halt decider that continues >to correctly simulate its input until it correctly determines that the Oh, its you again. Haven't you found another esoteric hobby horse to bore everyone with by now? |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 09 03:29PM +0200 The halting problem can only be viewed scientifically in fairly simple programs. With any program of worldly size, that no longer makes sense. That's why it's all pretty unworldly nonsense for people who have lost their grip on reality. |
| olcott <polcott2@gmail.com>: Oct 09 02:32PM -0500 On 10/9/2022 8:29 AM, Bonita Montero wrote: > simple programs. With any program of worldly size, that no longer > makes sense. That's why it's all pretty unworldly nonsense for > people who have lost their grip on reality. The halting theorem prevents any serious funding of termination analysis research https://en.wikipedia.org/wiki/Termination_analysis in the same way that the Tarski Undefinability theorem prevents truth conditional semantics from ever being anchored in a formal definition of truth, thus hampering AI research funding. My focus on the halting theorem also simultaneously addresses the analogous 1931 Gödel incompleteness theorem and the Tarski Undefinability theorem. I focus on the HP because it is the only one of the set of three analogous problems that can be exhaustively analyzed within existing formal systems. Both Gödel and Tarski require a paradigm shift in the notion of a formal system before they can be sufficiently analyzed. Wittgenstein's analysis of Gödel provides a glimpse into this paradigm shift when he concludes that Gödel's G is simply untrue within its formal system. https://www.liarparadox.org/Wittgenstein.pdf -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Kaz Kylheku <864-117-4973@kylheku.com>: Oct 09 08:43PM > The halting theorem prevents any serious funding of termination analysis > research https://en.wikipedia.org/wiki/Termination_analysis Even if so, you're not making the best of use of the self-funding you have; your research goes in circles. If you were funded, and they found out you just post volumes on Usenet without going anywhere, it's likely the funding would be swiftly cut off. It's not a probelm of money. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 09 08:33AM -0700 > On Saturday, October 8, 2022 at 2:01:05 AM UTC+3, Tim Rentsch wrote: [...] >> ignore the larger topic of polymorphism with templates.) > Difficulty (for human reader) to find out which of name-sakes is > called at given place. [...] If the different overloadings all provide what is conceptually the same operation, is it important to know which one is called? For example, if we have size_t read_bytes_into( void *out, size_t n, FILE *file ); size_t read_bytes_into( void *out, size_t n, int fd ); should a caller care which of the two functions is called? At some level that seems to be a violation of the principle of information hiding. Of course, if the different overloadings do not all provide the same conceptual operation, that is a problem in program design. Is your objection only for cases in this second category? (A problem with file descriptors being of 'int' type is that any old arithmetic expression can be used, and the argument value may not be a suitable file descriptor. But that problem is inherent is using 'int' file descriptors, regardless of whether there is function overloading.) |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Oct 08 02:56PM +0200 On 7 Oct 2022 11:47, Juha Nieminen wrote: > I have encountered this small dilemma several times. It's a question of > const correctness and proper OO design in C++. > Should a virtual function in a base class be const or not? [snip] Others have already answered this to my mind satisfactorily. However, consider also the case of whether a non-virtual member function should be `const` or not. One possible dilemma is proxy class like the one returned by `std::vector<bool>::operator[]`, where its assignment operator can and in my opinion should be `const` because it doesn't modify /that/ object, class Proxy { public: auto operator=( const bool value ) const -> Proxy; }; But the whole point of assignment is to modify an object, in this case the real `vector`. So I guess a case can be made that the assignment operator should not be `const`. E.g., the state that's observable via this proxy object, changes as a result of an assignment to it. The reason that I think it should be `const` is that the `const` adds a constraint that can be useful for programmers: that /this/ object's internal non-`mutable` state doesn't change. Nothing about "visible" state or that; for this case it's all about internal object state. Then if one doesn't accept that as a universal criterion, and I DON'T, then the question is what is it that makes classes different in this respect? I have no good answer. - Alf |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 04:35PM +0200 There is no general answer or it depends on what you expect from this interface. In individual cases, this question is then easy to answer and therefore I do not know why it has to be discussed. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 08:36PM +0200 Am 08.10.2022 um 20:03 schrieb Michael S: > for interfaces, which typically means abstract classes with no data members. > All other forms of inheritance are known antipattern. > Use aggregation instead. Inheritance might be sometimes more difficult to handle. But if you handle it correctly it's often less work than with pure interfaces. |
| Muttley@dastardlyhq.com: Oct 09 09:19AM On Sat, 8 Oct 2022 11:03:35 -0700 (PDT) >There is a general answer - don't use inheritance except as substitute >for interfaces, which typically means abstract classes with no data members. >All other forms of inheritance are known antipattern. What a load of nonsense. The java system of extending an interface is next to useless compared to proper inheritence. >Use aggregation instead. I don't think you understand the different use cases of inheritence vs aggregation. |
| 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