Barring forgetfulness, you only have to figure something out *once *to understand it. After that, you cache that understanding for future rapid reference. There is no escaping combinatorial complexity in finding a needle in a haystack, but once you've found it, you can just remember where it's at and your search consists of going straight to it. That's what the OO paradigm offers us: a way to go right to the information we need, and ignore anything else. It's a caching technique, and I think it's the one that the human mind uses. We classify, group, and order things. These are all computationally intensive procedures which, once done the first time, rarely need to be done again. If I've classified all the objects I've encountered (and bothered to store in my memory), and I want to do a search for a nearby cup to use to pour my drink into, all I have to do is lookup the objects in my immediate vicinity that I've previously classified as "cup". This is a much smaller search space than the space of all possible objects.
What you're trying to do with your Boolean formulas taken piecewise is to find a way around the NP-complete problem. I don't think there really are polynomial algorithms for these problems. Combinatorial complexity is due to the need to literally check every possibility. Trying to bypass that is a dead end. People can't do it either. When something reduces to a combinatorial search procedure, that's exactly what we do... search each possibility, *slowly*. We do not optimize when there is no information available to do so with. We optimize on *repeated *problems, where caching can provide a shortcut to the solution. And OO, due to its ease of use, is a clue as to the form that our own mental caching takes. On Sat, Dec 8, 2012 at 4:23 AM, Jim Bromer <[email protected]> wrote: > I tried to think of a way the OOP model might be used to point to (or as > an analogy for) a solution of complexity. The only thing I could think of > that came near to this was using probability to limit the search space to > try different systems of solutions in Boolean Logic. By examining parts of > a logical formula using a method to narrow the possibilities down you can > narrow the search space to look for possible solutions. This kind of method > can have some practical applications but it is not a general solution to > Boolean Logic complexity. This could be seen as somewhat analogous to OOP > because you are effectively encapsulating the search space using different > logical 'vantages' based on narrowing the range of possible solutions as > can be determined by examining parts of formula that can be determined. > > I don't really see how the OOP model might point to a way to solve > complexity. > > On Fri, Dec 7, 2012 at 11:27 PM, Jim Bromer <[email protected]> wrote: > >> Aaron, >> Well it is true that there is typically an efficiency of organization but >> not of execution in OOP, but you weren't able to finish the line of >> reasoning. For one thing, complexity is an execution problem. >> But to look at something more fundamental, the ease of comprehending an >> OOP is an aspect of human intelligence but does would not work at all for >> non-intelligent entities. The problem is how do we use these ideas to make >> artificial intelligence. The argument that OOPs are easier to understand >> and modify and therefore a proposed AGI program can use them to avoid >> combinatorial complexity is based on a hidden functional identity argument >> used in a circular argument. If an AGI program is intelligent then it could >> use some techniques of OOPs to comprehend something while avoiding >> complexity and therefore this is a good way to make a program intelligent >> (by overcoming complexity which seems like the only obstacle to making AGI.) >> Of course there are times that constraining the search space would be a >> good technique to use in an AGI program. I never said it wasn't. >> The OOP points the way to solving the combinatorial complexity >> problem?!? That doesn't seem very likely. >> >> OOP was originally developed as a proposed AI method. However, when it >> did not pan out some people thought it could be used as a programming >> model. One of the things that I have discovered in these groups is that >> people sometimes blame their programming languages as being an obstacle to >> creating AI. Furthermore, I have read that one of the important aspects of >> encapsulation was that it can be used to protect privileged code >> in corporate settings where you need many programmers with different levels >> of knowledge about the program to work on a project. If at some point some >> private class needed to be changed, a head programmer could rewrite the >> class as being inherited from the original class so that the original >> class could be preserved to be used with existing code that was still >> functioning well. >> >> So while you were right about the efficiency of organization, that does >> not necessarily hold for a less-insightful program. The efficiency of >> organization is based on the way the model can utilize human insight to >> understand certain relations in the classes while hiding implementation >> issues which the human mind is less capable of comprehending. Secondly, >> complexity is an execution issue. Third, Object Oriented Programming >> originated as an AI model, so the idea that this model has not been used to >> try to solve AI problems is almost certainly not true. >> >> Jim Bromer >> On Fri, Dec 7, 2012 at 10:21 PM, Aaron Hosford <[email protected]>wrote: >> >>> I'm talking about efficiency of organization, not efficiency of >>> execution. Object Oriented programs are indeed typically less efficient to >>> execute. The reason people are willing to pay this price is that Object >>> Oriented programs are easier to understand and modify, because interactions >>> are confined locally rather that affecting the system globally. >>> >>> This translates over directly to concepts. If I have a change in my >>> understanding of the relationship between two concepts, this does not >>> propagate its affects to all concepts. If I were to map out my >>> understanding of an OO program, I would find each class to be a hub to a >>> fairly small number of interactions, despite the complexity that might lie >>> under the hood in the class's implementation. This is the reason it's >>> easier to understand and modify an OO program. >>> >>> You pointed out that combinatorial run-time complexity is the bottleneck >>> that prevents AGI from taking off, and that it is a mathematical problem. >>> The Object Oriented paradigm, as a sophisticated means to push our internal >>> mental representations and organization of programs out onto code and >>> thereby limit combinatorial complexity via mechanisms we already use in our >>> heads for that very purpose, points the way to the solution to that >>> mathematical problem. It simply needs to be formalized. >>> >>> >>> On Fri, Dec 7, 2012 at 8:31 PM, Jim Bromer <[email protected]> wrote: >>> >>>> I don't like OOP or (excessive) multiple type templating because they >>>> are too inefficient and multiple type templating is too difficult to debug. >>>> So I do use techniques to limit the search space while programming but they >>>> are done using a guiding meme that is in direct opposition to the one you >>>> have mentioned and another in direct opposition to the seemingly desirable >>>> technique of compacting through massive generalization. However, I have >>>> made this choice through experience not through encapsulated ignorance of >>>> the complications that such analogies and theories pose. I chose to avoid >>>> OOP and excessive type templating in a single template not only because >>>> they were undesirable but because they were unnecessary as well. >>>> Jim Bromer >>>> >>>> On Fri, Dec 7, 2012 at 7:52 PM, Aaron Hosford <[email protected]>wrote: >>>> >>>>> The problem is that a subsystem can be related to a great number of >>>>>> other subsystems and if we agree that the componential model is a >>>>>> fundamental requirement for AGI then this can lead to an immense >>>>>> potential >>>>>> for complexity. I believe that we need better ways to efficiently >>>>>> represent >>>>>> and use massive numbers of possible interrelations. >>>>> >>>>> >>>>> Most OO textbooks and guides will tell you to avoid having a class >>>>> that interrelates with too many other classes, or which has too many >>>>> methods, etc. They suggest rewriting it by splitting it into separate >>>>> pieces. The reasons given are based on complexity, just as you point out >>>>> here. A highly interconnected subsystem would be a no-no for thinking just >>>>> as a highly interconnected class would be for programming. The system >>>>> would >>>>> have to have some sort of algorithm for dealing with this. >>>>> >>>>> There are times we need to expand the search space and one of those >>>>>> times is when we need to think outside the box. We need to be able to >>>>>> reevaluate a situation quickly and this too may be a form of thinking >>>>>> outside the box. >>>>> >>>>> >>>>> I think switching to a different search space or search method, as >>>>> opposed to expanding the search space, would make more sense. I can look >>>>> at >>>>> something in multiple different ways and each way I look at it emphasizes >>>>> different properties of that thing, but those properties come in groups or >>>>> packages. They don't all get thrown into the same toolbox and shuffled >>>>> together. This means that when you're looking at something a certain way, >>>>> you're only searching certain combinations, not all possible combinations, >>>>> and so the combinatorics don't get out of hand.This lines up nicely with >>>>> your idea of flexible boundaries. (I'm sure I'm being vague here, and I'd >>>>> love to give you examples, but I'm in a hurry. I'll have to get back to >>>>> you >>>>> on it.) >>>>> >>>> > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/23050605-2da819ff> | > Modify<https://www.listbox.com/member/?&;>Your Subscription > <http://www.listbox.com> > ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
