Hi Stanley. I understand what you're saying. This question I referred to is the one of developing an AGI services platform, which would include my views on abstraction/deabstraction.
Regards Rob ________________________________ From: Stanley Nilsen <[email protected]> Sent: Monday, 29 October 2018 6:05 PM To: [email protected] Subject: Re: [agi] Abstraction is not simple response's below On 10/29/18 1:32 AM, Nanograte Knowledge Technologies via AGI wrote: The question is, how should such a component of abstraction/deabstraction be successfully engineered as a component of an AGI service? Considering what you shared about your architecture, I would understand you are saying that you would develop the blueprint by virtue of moving from an abstraction of information, to a codable (deabstraction) of said information "text". If so, that is in compliance with the classical SDLC where analysis and design moved from conceptual- to logical- to physical, architectural layers. The concept I see fitting into AGI doesn't involve de-abstraction. Once abstraction occurs, there is no way to go back the other way. The abstraction has the purpose of being able to compare two things that are not easily compared. The "information" that was used in the abstraction process is replaced by a less specific representation that doesn't reveal anything about it's past (except that it came from a specific promoter which is our tie back into the choice.) Not sure what classical SDLC is. (IBM had a communications protocol SDLC, but I'm sure that isn't what you're referring to :) Such a choice-based exercise is fairly straight forward. But it seems you were alluding to another aspect of abstraction as well, one that is less "simple", where information is "floated" as an outcome of the component in action, then "discovered" by the system (obviously by a generic, a scanning/locating function) to be used within the informational context of the overall system? Floated, in the sense of the "best" coming to the top and being visible? When a promoter "wins" the comparison of the moment, the promoter is id'd and can be tied back to the opportunity that the promoter was designed to support. Referral back to what the promoter was promoting for, is what makes the unit work toward the best action for the moment. (the opportunity has a corresponding action to be taken.) In short then, would emerge another systems value chain; Making (in the sense of abstracting/deabstracting), Finding (locating the floated value), Framing (abstracting the floated value to systemic relative reality), and Sharing (Presenting the compressed value intra and extra systemically in feedback loops). Not sure about value chain. To get back to "value" in my architecture, we put a value on an "action" that can be taken (a recipe) knowing that the action has expected value if conditions are suitable for the action. The promoter is essentially watching the conditions, and when conditions are satisfied, the promoter gives a bid that is based on the value of the action - an action that was related to this promoter. So in a simple sense, the promoter, when activated says "hey, I'm promoter 472346 and my benefit bid is 14." If there is no promoted benefit higher than 14 then the promoter's action will be initiated. The abstracted value of 14 compares with other promoters whose calculations are virtually unrelated to how this promoter came to 14. The "relatedness" comes from all promoters being set up by a common abstractor. Suppose this value chain I stated was slotted in architecturally as a vector function between your version of "abstractor" and "promoter"? Would it be possible to consider that a generic, "X Value Chain" would become the thread that all AGI functionality would flow from in an architectural sense? My suggestion would be that, within an AGI system, there exists is no more up or down progression within the system, but rather an architecture resembling an "instantaneous" informational starburst. The promoting system does produce near instantaneous bursts. Every millisecond or so, the decision making process can react to conditions that change. Naturally, there has to be a fast global distribution of changing conditions, and these promoters must be programmed prior to usage. Again, the hard part is building the abstractor, which is where the intelligence exists. Build a strong abstractor, and you have a capable general intelligence. As far as threads (in a processor context) it isn't necessary to devote one thread to one promoter. With the speed of processor today, a single thread could do the promotion for hundreds of simple promoters. Hundreds or thousands of promoters could exist on multiple processors and communicate via a fast network. I know, this would probably play havoc with linear and component-based programming techniques, as it should. I think the simplest reason for this is that AGI functionality probably is not a teachable construct. Would we need a different programming approach? Probably. Would this approach be derived from an AGI-services architecture? Probably. Which leaves the question; what would the SDLC for an AGI-services architecture look like? Programming approach is fairly straight forward for most of the system, but the "magic sauce" is in the abstractor. One can think of the system as built on assertion of facts which become "conditions." Conditions are distributed to promoters who use the data to make simple calculations. The action of asserting a fact is itself the result of the unit taking an action that was promoted - or on a lower level, sensors could assert a fact of some condition. The hard programming is building an abstractor, and the abstractor is likely the last part of the system to mature. The abstractor is tasked with setting a value for an expected outcome and having that value be comparable to values for other outcomes. It's complicated, but the advantage is that we know what we are trying to achieve as we build the code that does abstraction. The rest of the system is not mysterious. I'm meeting up with one of the ghurus in Systems- and Information engineering in South Africa next week to hopefully try and discuss this question. Mr. Viljoen pioneered IE methodology in the 1980's, which IBM Global acquired in the early 1990's for their future use. I hope to be able to share my views and be enlightened by his mind. Rob what was "this question"? Stan Artificial General Intelligence List<https://agi.topicbox.com/latest> / AGI / see discussions<https://agi.topicbox.com/groups/agi> + participants<https://agi.topicbox.com/groups/agi/members> + delivery options<https://agi.topicbox.com/groups/agi/subscription> Permalink<https://agi.topicbox.com/groups/agi/T586df509299da774-Me16d9684b525456affdc8b37> ------------------------------------------ Artificial General Intelligence List: AGI Permalink: https://agi.topicbox.com/groups/agi/T586df509299da774-Maf250c16f530fdb3f281fdec Delivery options: https://agi.topicbox.com/groups/agi/subscription
