| … | … | @@ -29,4 +29,22 @@ never taken, for two reasons: |
| 29 | 29 | all be Atomese. Solving that problem give rise to this github repo |
| 30 | 30 | that this design file is in right now. |
| 31 | 31 | |
| 32 | | * The matri |
| 32 | * The recursive step of "repeat and do it again" stumbled on the design |
| 33 | of the "matrix" code base. (Split out of the atomspace repo and now |
| 34 | located at https://github.com/opencog/matrix). That code-base was |
| 35 | written to be quite general, so that it could handle generic |
| 36 | structures. The problem was that it was written in scheme. That means |
| 37 | it integrated poorly and awkwardly with Atomese, and did not integrate |
| 38 | at all with a sensori-motor design. |
| 39 | |
| 40 | The solution to that stumbling block was to develop the concept of |
| 41 | "flows" in Atomese: of flowng data that travels through networks |
| 42 | defined declaratively in Atomese. This required lots of low-level |
| 43 | grunt-work: defining Atoms that could add, multiply, accumulate, |
| 44 | take dot-products, mask bits, transpose columns and tows, but also |
| 45 | could stream data, and also sort data... Lots of low-level grunt work, |
| 46 | mostly completed. |
| 47 | |
| 48 | So given that the primary issues were resolved in the two bullet points |
| 49 | above, I am now ready to try again. But, before starting, some |
| 50 | critiques, some planning, some day-dreaming. |