| … | … | @@ -17,8 +17,8 @@ a kind of wiring diagram, indicating where data flows. By contrast, the |
| 17 | 17 | prototypes. How can one perform the rewrite from the high-level |
| 18 | 18 | description to the low-level description? Normally, this is done "brute |
| 19 | 19 | force": a human programmer sits down and writes a large pile of GPU |
| 20 | | code, creating systems like PyTorch or TensorFlow. The experiment here |
| 21 | | is to automate the glueing together from high-level to low-level |
| 20 | code, creating systems such as PyTorch or TensorFlow. The experiment |
| 21 | here is to automate the conversion from high-level to low-level |
| 22 | 22 | descriptions. |
| 23 | 23 | |
| 24 | 24 | Such automation resembles what compilers do. For example, a C++ compiler |
| … | … | @@ -34,26 +34,38 @@ and suitably complicated example target. |
| 34 | 34 | |
| 35 | 35 | A different way of thinking of this experiment is as an exploration of |
| 36 | 36 | the agency of sensori-motor systems. The GPU is a "thing out there" that |
| 37 | | can be manipulated by an agent to "do things". How does one perceive the |
| 38 | | "thing out there", and describe it's properties? How can one control it |
| 39 | | and perform actions on it? To extert motor control on that "thing out |
| 40 | | there"? How does one perceive the results of those motor actions? |
| 37 | can be manipulated by an agent to "do things". How does an agent |
| 38 | perceive the "thing out there", and "understand" it's properties? |
| 39 | How can the agent control the "thing out there", and perform actions |
| 40 | on it? To extert motor control on that "thing out there"? How does |
| 41 | the agent perceive the results of those motor actions? |
| 41 | 42 | |
| 42 | 43 | In the present experiment, the "agent" is is a collection of graphs |
| 43 | 44 | (properly, hypergraphs), represented using |
| 44 | 45 | [Atomese](https://wiki.opencog.org/w/Atomese), |
| 45 | 46 | and "living" in the OpenCog |
| 46 | 47 | [AtomSpace](https://github.com/opencog/atomspace). |
| 47 | | That is, the subjective inner form of the agent is a world-model, |
| 48 | | consisting of abstractions derived from sensory perceptions of the |
| 49 | | external world, and a set of motor actions that can be performed to |
| 50 | | alter the state of the external world. The agent itself is constructed |
| 51 | | from Atomese; the GPU is a part of the external world, to be manipulated. |
| 48 | Thhe subjective inner form of the agent is a world-model, consisting of |
| 49 | abstractions derived from sensory perceptions of the external world, and |
| 50 | the knowledge of a set of motor actions that can be performed to alter |
| 51 | the state of the external world. The agent itself is represented in |
| 52 | Atomese; the GPU is a part of the external world, to be manipulated. |
| 53 | |
| 54 | An important part of the challenge is understanding how assembly, and |
| 55 | sepcifically, how self-assembly works. That is, the agent is meant to |
| 56 | be a collection of pieces-parts, a collection of transformation rules. |
| 57 | These rules are to be assembled to "get things done". The assembly is |
| 58 | meant to be self-assembly, and is preseumed to live at the edge of a |
| 59 | critical phase transition. The phrase "critical phase transition" is |
| 60 | meant to invoke the conventional idea of a critical phase transition, |
| 61 | such as that seen in Per Bak's critical sandpile. The difference here |
| 62 | is that the dynamical system consists of a collection of rewrite rules, |
| 63 | instead of abstract sand-grains. |
| 52 | 64 | |
| 53 | 65 | The above description might feel like excessive anthropomorphising of |
| 54 | 66 | a mechanical system. But that's kind of the point: to force the issue, |
| 55 | 67 | and explore what happens, when an agentic viewpoint is explicitly |
| 56 | | forced. |
| 68 | forced, and given the attributes of a dynamical system. |
| 57 | 69 | |
| 58 | 70 | External Subsystems |
| 59 | 71 | ------------------- |
| … | … | @@ -62,9 +74,10 @@ for the OpenCog [AtomSpace](https://github.com/opencog/atomspace) |
| 62 | 74 | hypergraph database. It has a variety of different ways of talking to |
| 63 | 75 | external subsystems. These were developed to solve various practical |
| 64 | 76 | 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, explicitly agentic or sensori-motoin |
| 67 | | their design. Some shadows and hints of this can be seen, however. |
| 77 | interfaces are "well designed", in that they solve the particular issue |
| 78 | that arose. Human progammers have used them to construct various kinds |
| 79 | of systems. However, these interfaces lack what is needed for a |
| 80 | dyanmical, sensori-motor, agential point of view. |
| 68 | 81 | |
| 69 | 82 | These external subsystem interfaces include: |
| 70 | 83 | |
| … | … | @@ -86,10 +99,13 @@ These external subsystem interfaces include: |
| 86 | 99 | SQL Tables to be mapped into AtomSpace structures, so that updates |
| 87 | 100 | to one are reflected as updates to the other. |
| 88 | 101 | * Obsolete gateways to ROS, the Robot Operating System, to Minecraft |
| 89 | | (via MineRL & Malmo), to Unity, the game engine, and many more. |
| 102 | (via MineRL & Malmo), to Unity, the game engine, and more. |
| 90 | 103 | These can be found in old, archived |
| 91 | 104 | [github repos](https://github.com/opencog/), scrolling down to |
| 92 | | the oldest repos having no activity. |
| 105 | the oldest repos having no activity. There's also a collection |
| 106 | of youtube videos showing these in operation; seee e.g. the |
| 107 | [Virtual Dog](https://www.youtube.com/watch?v=FEmpGRLwbqE) demo, |
| 108 | and, of course, the Hanson Robotics Sophia demos. |
| 93 | 109 | |
| 94 | 110 | The above "work", and provide Atomese interfaces to the described |
| 95 | 111 | systems. However, they all lack an Atomese interface description, |