> INPUT > ===== > I suggest it should initially include 3 inputs: > 1) vision > The visual input would be the most computationally demanding, > and I suggest to reduce the resolution to as low as 32x32. > 2) text > These text inputs will be passed literally without > understanding. I include this as a separate "sense" in > a standardized AGI framework. > 3) sound > May be added later.
Sound is almost certainly easier sensory data to process than visual, primarily because it is processed as parallel one-dimensional streams (in the brain and often in computers, but a good idea in the abstract) rather than trying to map a 2+ dimensional field like vision. Sound makes a good progression, in terms of complexity, from something like text which is a single one-dimensional stream. The format of sound should be similar to how the human brain gets it, mostly because it makes a lot of sense generally. Take the audio signal and split it into multiple spectral bands at regular intervals, the data to be processed being streams that contain changes in amplitude in a specific spectral band. If you want to make it low cost but still fully capable of handling things like human speech, I would suggest the following: - Low-pass filter the source at 8kHz - 32 to 64 spectral channels - 10ms update intervals You could get good results with even lower resolution than this, but the above should keep things well-above the conversion artifact noise floor for almost any experiment with sound you want to do. Any vaguely modern CPU could do this conversion in realtime without even breaking a sweat, particularly if offloaded to a vector processor. > ATTENTION > ========= > It should also contain an "attention" input which specifies > what kind of information should be focused on. Examples: This is an input? I would think that the point is to grab the attention of the system i.e. play to adaptive (or not so adaptive) biases in its pattern filtering, which I presume all reasonable AGI systems have. > KNOWLEDGE EXCHANGE > ================== > This is a more ambitious feature. I want to create a protocol > for exchanging knowledge that are learned from different robots. > For example one person can train his robot to recognize fruits > and another trains his for faces. Then a web server may provide > tools to maintain a database of such "knowledge" files as well > as tools to merge them, etc. I don't see how this is generally possible, short of playing a source data log forward. I mean, I can merge and share the knowledge of MY systems(1), but any representation I use is reflective of the assumptions and theory of my model and may have no possible or easy or tractable translation into the representation of of another model. This is not an easy problem to work around in a really functional way. The capability to load the "brain" of one system into another is very useful and doable, but it won't translate well outside of a single system design. I expect when AGI-ish technologies start to take off, there will be huge trade and commerce in loadable modules that contain certain classes of experience and knowledge. (1): The other caveat is that any system/representation merge that isn't exhaustive (i.e. summing to systems together in totality) will necessarily lose a lot of pattern context that is probably relevant. On the upside, a fully merged system generally uses fewer resources than the sum of the two independent systems that went into the merged system. Size has its advantages. j. andrew rogers ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
