| … | … | @@ -7,6 +7,8 @@ or CUDA. The current prototype accesses the hardware at a low level, |
| 7 | 7 | working with individual vectors. High-level API's, such as commonly |
| 8 | 8 | used in deep learning, are not supported in this interface layer. |
| 9 | 9 | |
| 10 | The Experiment |
| 11 | -------------- |
| 10 | 12 | The experiment, as it is currently evolving, is to understand graph |
| 11 | 13 | rewriting between "natural" descriptions of compute systems. For |
| 12 | 14 | example, the "natural" description of a deep learning transformer is |
| … | … | @@ -48,15 +50,23 @@ external world, and a set of motor actions that can be performed to |
| 48 | 50 | alter the state of the external world. The agent itself is constructed |
| 49 | 51 | from Atomese; the GPU is a part of the external world, to be manipulated. |
| 50 | 52 | |
| 51 | | The abvoe description might feel like excessive anthropomorphising of |
| 53 | The above description might feel like excessive anthropomorphising of |
| 52 | 54 | a mechanical system. But that's kind of the point: to force the issue, |
| 53 | 55 | and explore what happens, when an agentic viewpoint is explicitly |
| 54 | 56 | forced. |
| 55 | 57 | |
| 58 | External Subsystems |
| 59 | ------------------- |
| 56 | 60 | [Atomese](https://wiki.opencog.org/w/Atomese) is the interface language |
| 57 | 61 | for the OpenCog [AtomSpace](https://github.com/opencog/atomspace) |
| 58 | 62 | hypergraph database. It has a variety of different ways of talking to |
| 59 | | external subsystems. These include: |
| 63 | external subsystems. These were developed to solve various practical |
| 64 | application issues that arose in the use of Atomese. These subsystem |
| 65 | interfaces are "well designed" in that they solve the particular issue |
| 66 | that arose. They are not, however, explictly agentic or sensori-motoin |
| 67 | their design. Some shadows and hints of this can be seen, however. |
| 68 | |
| 69 | These external subsystem interfaces include: |
| 60 | 70 | |
| 61 | 71 | * The [GroundedSchemaNode](https://wiki.opencog.org/w/GroundedSchemaNode) |
| 62 | 72 | allows external python, scheme and shared-library functions to be |
| … | … | @@ -75,6 +85,15 @@ external subsystems. These include: |
| 75 | 85 | * The [SQL Bridge](https://github.com/opencog/sql-bridge) allows |
| 76 | 86 | SQL Tables to be mapped into AtomSpace structures, so that updates |
| 77 | 87 | to one are reflected as updates to the other. |
| 88 | * Obsolete gateways to ROS, the Robot Operating System, to Minecraft |
| 89 | (via MineRL & Malmo), to Unity, the game engine, and many more. |
| 90 | These can be found in old, archived |
| 91 | [github repos](https://github.com/opencog/), scrolling down to |
| 92 | the oldest repos having no activity. |
| 93 | |
| 94 | The above "work", but lack an agentic sensori-motor design interface. |
| 95 | To use these interfaces |
| 96 | |
| 78 | 97 | * The [Sensory](https://github.com/opencog/sensory) system, which is |
| 79 | 98 | an experimental effort to understand the generic mathematical theory |
| 80 | 99 | of interfacing Atomese to arbitrary unknown sensory devices, and to |
| … | … | @@ -85,45 +104,14 @@ external subsystems. These include: |
| 85 | 104 | * The [Motor](https://github.com/opencog/motor) system, which attempts |
| 86 | 105 | to define a simpler, more practical and mundane way of using Atomese |
| 87 | 106 | to work with external devices. |
| 88 | | * Obsolete gateways to ROS, the Robot Operating System, to Minecraft |
| 89 | | (via MineRL & Malmo), to Unity, the game engine, and many more. |
| 90 | | |
| 91 | | Interfacing to GPU subsystems, such as CUDA or OpenCL, or any of a large |
| 92 | | variety of systems built on these, such as TensorFlow, offer a |
| 93 | | non-trivial exercise for testing and guiding the Atomese sensori-motor |
| 94 | | interfaces. |
| 95 | | |
| 96 | | The interfaces here simply move vectors to and from GPUs and invoke GPU |
| 97 | | kernels to perform processing on them. Perhaps high-level interfaces |
| 98 | | will be added in the future; they're not here in this prototype. |
| 99 | | |
| 100 | | The main effort is to find a balance between abstract mathematical |
| 101 | | theory and a practical, usable interface. The generic Atomese |
| 102 | | sensorimotor research is being done in the hopes of discovering |
| 103 | | generic abstractions that symbolic (and neuro-symbolic) AI subsystems |
| 104 | | can use. If you are a human programmer, you have a zillion-and-one |
| 105 | | choices for programming languages and APIs that allow you to hack up |
| 106 | | almost anything. If you are a symbolic AI agent, or a DL/NN transformer, |
| 107 | | you do not have this richness of tools. You mostly don't even have much |
| 108 | | of a clue of what "reality" is. In part, that's because you don't have |
| 109 | | a sensori-motor system, beyond some hacked-up robots and in-game avatars |
| 110 | | created for you by *human* engineers. Perhaps with a proper theory, some |
| 111 | | of the hackiness can be refined. |
| 112 | | |
| 113 | | The need for a general sensori-motor theory is underscored by the |
| 114 | | failure of earlier OpenCog projects that attempted create "embodied |
| 115 | | OpenCog agents". These are the systems listed above: interfaces into |
| 116 | | ROS, Unity and Minecraft, to name some of the more advanced efforts. |
| 117 | | These were all sensori-motor "hack jobs", built without giving any |
| 118 | | thought of what it means "to perceive and move". |
| 119 | 107 | |
| 120 | 108 | Status |
| 121 | | ----- |
| 109 | ------ |
| 122 | 110 | ***Version 0.1.0*** -- |
| 123 | 111 | Basic proof-of-concept, showing how to use Atomese to open a connection |
| 124 | | to an OpenCL compute device (i.e. a GPU), load and invoke compute |
| 112 | to an OpenCL compute device (i.e. a GPU), load and invoke GPU compute |
| 125 | 113 | kernels, and have those kernels work with floating-point vector data |
| 126 | | residing in the AtomSpace. |
| 114 | that is moved between the AtomSpace and the GPU. |
| 127 | 115 | |
| 128 | 116 | New in this version: Atomese interface descriptions are now generated |
| 129 | 117 | for OpenCL kernel interfaces. This should allow introspection of the |