Hi Linas, Thank you for your interest and I’m sorry for not presenting more complete descriptions. I’m trying to figure things out.
Besides speculation about Hyperon I want to support current development concretely by doing realistic large atomspace experiments with memory-mapped files and distribution, getting acquainted with Opencog AGI platform, capabilities, challenges, requirements along the way, experience which should be valuable in whatever direction Hyperon development goes on. > On Aug 5, 2020, at 01:51, Linas Vepstas <[email protected]> wrote: > > Each subsystem is function F from [past] GenericAtomSpace -> [future] > GenericAtomSpace. Internally there will be functions which are ~ inverse of > F. Subsystem categories are mapped to GenericAtomSpace in their own way, in > separate processes. > > I don't understand what you are trying to say, above. GenericAtomSpace is renamed to UniversalAtomSpace (UAS). Function Fstep: UAS -> UAS is in UAS and it’s total (in Idris REPL, :total Fstep prints Opencog.Fstep is Total). It maps past state of UAS to the future state of UAS. Core runtime engine is applying Fstep in the infinite loop. Since new Atomese and UAS are probabilistic linear dependently-typed, resource usage is fixed and terms/atoms represent superposition of possibilities. That’s why I assumed that core engine will benefit by having working set of fixed-size and fixed-size data structures for atomic operations. I know that atoms in AtomSpace right now are higher level knowledge representations. What if in our design we mirror abstraction hierarchy of the universe as we understand it. First there is something like atoms in the sense of quantum physics, that are forming molecules, more complex patterns where cogistric phenomena could take place, next there are alife structures manifesting Rosennean complexity, all the way up to cognitive level where system has sophisticated self-model(s), existing in perfect harmony or perfect disharmony?! We manually encode prior implementation of Fstep and maybe derive ~ inverse of Fstep in initial state of UAS. Existing algorithms and theory from current Opencog codebase like PLN, MOSES, URE…, Opencog Background Publications BgPub <https://wiki.opencog.org/w/Background_Publications> and parts of GTGI <https://multiverseaccordingtoben.blogspot.com/2020/05/gtgi-general-theory-of-general.html> body of work are translated to new Atomese EDSL as prior knowledge to bootstrap the system using intelligent not-yet-AGI tools. Ultimate preferred mode of interaction with the system is at cognitive level with appropriate interfaces like screen, audio for voice, TCP, HTTP… for internet, web and let’s not forget published SignularityNET services with other cognitive agents elsewhere). I guess that development of narrow-AGI applications will happen on the sub-cognitive level. If we look at “High Level Mind Diagram” from EGI1 <https://www.amazon.com/Engineering-General-Intelligence-Part-Cognitive/dp/9462390266> page 146, we will be able to excerpt control on this level, to intercept, inspect and modulate what’s going on between these components. We will inspect mechanistic low level structures of UAS only for the system diagnostics and optimization of distribution strategies but not for efficient communication with the cognitive system. For rapid engineering of OCP Hyperon and for mutual understanding between OCP Hyperon and humans, all science knowledge, mathematics and especially, as Ben’s paper “Toward Formal Model of Cognitive Synergy” BenCS <https://arxiv.org/abs/1703.04361> suggests, category theory (CT) should be encoded in the Fstep. I’m complete newbie in CT. In this regard BaezRS <http://math.ucr.edu/home/baez/rosetta/rose3.pdf> is pretty cool illumination of analogues from physics, topology, logic and computation demonstrating the unifying power of CT. Some projects already try to encode CT concepts, apart from many examples from the Haskell’s ecosystem, there are LeanCT <https://leanprover-community.github.io/mathlib_docs/category_theory/category/default.html> and CoqCT <https://github.com/jwiegley/category-theory>. Robert Rossen’s (M,R)-systems are also described in CT terms RossMR <http://www.people.vcu.edu/~mikuleck/PPRISS3.html>. I was also looking at flat concatenative languages as low-level language (LLL) for the stochastic runtime. In that case new Atomese may be decompilation of LLL. I can see how pattern-mining may look like on LLL. It could be very simple built-in functionality to automatically refactor executed sub-sequences of LLL words. People say that concatenative languages are too low level for normal software development. They complain about having to do stack manipulation by hand. What if LLL permeates all layers of the cognitive stack including external use of natural language. In that case, some LLL words could be natural language words auto refactored/pattern-mined to satisfy limited bandwidth between intelligent organisms. If you wonder how non-deterministic concatenative language execution a la Prolog could look like, there is a post JoyND <https://concatenative.yahoogroups.narkive.com/u6NhOdt5/stack-concatenative-logic-programs#post4> from the author of language Joy <http://joy-lang.org/>. For explanation of equivalence between linear language and stack machine (LLL) see “Linear Logic and Permutation Stacks” BakerLL <https://web.archive.org/web/20200610223140/http://home.pipeline.com/~hbaker1/ForthStack.html>. LLL words could act as operators. For people who code in Haskell “Compiling to categories” may be interesting ConalC2C <http://conal.net/papers/compiling-to-categories/>. And also GHC is getting linear types LinHS <https://www.youtube.com/watch?v=t0mhvd3-60Y>. For relation between linear logic and linear algebra (~ GPU/TPU acceleration) see LinLA <https://www.cs.bham.ac.uk/~drg/bll/steve.pdf>. [BgPub]: https://wiki.opencog.org/w/Background_Publications <https://wiki.opencog.org/w/Background_Publications> [GTGI]: https://multiverseaccordingtoben.blogspot.com/2020/05/gtgi-general-theory-of-general.html <https://multiverseaccordingtoben.blogspot.com/2020/05/gtgi-general-theory-of-general.html> [EGI1]: https://www.amazon.com/Engineering-General-Intelligence-Part-Cognitive/dp/9462390266 <https://www.amazon.com/Engineering-General-Intelligence-Part-Cognitive/dp/9462390266> [BenCS]: https://arxiv.org/abs/1703.04361 <https://arxiv.org/abs/1703.04361> [BaezRS]: http://math.ucr.edu/home/baez/rosetta/rose3.pdf <http://math.ucr.edu/home/baez/rosetta/rose3.pdf> [LeanCT]: https://leanprover-community.github.io/mathlib_docs/category_theory/category/default.html <https://leanprover-community.github.io/mathlib_docs/category_theory/category/default.html> [CoqCT]: https://github.com/jwiegley/category-theory <https://github.com/jwiegley/category-theory> [RossMR]: http://www.people.vcu.edu/~mikuleck/PPRISS3.html <http://www.people.vcu.edu/~mikuleck/PPRISS3.html> [JoyND]: https://concatenative.yahoogroups.narkive.com/u6NhOdt5/stack-concatenative-logic-programs#post4 <https://concatenative.yahoogroups.narkive.com/u6NhOdt5/stack-concatenative-logic-programs#post4> [Joy]: http://joy-lang.org/ <http://joy-lang.org/> [BakerLL]: https://web.archive.org/web/20200610223140/http://home.pipeline.com/~hbaker1/ForthStack.html <https://web.archive.org/web/20200610223140/http://home.pipeline.com/~hbaker1/ForthStack.html> [ConalC2C]: http://conal.net/papers/compiling-to-categories/ <http://conal.net/papers/compiling-to-categories/> [LinHS]: https://www.youtube.com/watch?v=t0mhvd3-60Y <https://www.youtube.com/watch?v=t0mhvd3-60Y> [LinLA]: https://www.cs.bham.ac.uk/~drg/bll/steve.pdf <https://www.cs.bham.ac.uk/~drg/bll/steve.pdf> Getting back to more practical matters. > periodically clone the whole system state (for example, every day) to > external storage for backup. > > Keep in mind that every now and then, the RAM layout of the AtomSpace > changes. This may be due to bug fixes, new features, or simply that a new > compiler decided to pack things differently (e.g. c++ std library changes, > e.g. for strings, vectors, mutexes, etc). Of course. If compiler changes data layout, export/import (backup/restore) mentioned in my previous email will have to be performed. I hope these compiler changes are not happening frequently. Best regards, Pedja -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/2E96C0F6-70F8-4ED1-97D8-B84D79EE04E9%40crackleware.nu.
