-
Notifications
You must be signed in to change notification settings - Fork 725
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reset the atomspace in scheme #3061
Comments
Certainly, you can clear and reload the atomspace. But perhaps this eats up too much CPU/elapsed time? If so, there is another possibility: load the base rules and content into one atomspace, but then use a 'child' atomspace for perceptions and actions. The child atomspace can be discarded, leaving behind the base. No one has yet experimented with this kind of arrangement, and there are likely to be bugs and bizarre, unexpected behavior and side-effects. I think, however, that this is an important long-term direction, and so getting started on it now, rather than later, would be good. |
At the guile prompt:
|
Ok, thanks for the suggestions. I'll try it tomorrow and see how it behaves. |
It crashed. Here's the error report when I try (cog-atomspace-clear (cog-atomspace)): It may be that I need to go over it with @amebel, since this call may or may not be what we need. Essentially we're looking for a simpler way to restart the atomspace for testing purposes that more or less corresponds to how we expect to do this in practice, i.e. when resetting the robot on-site. With ChatScript, we can reset the context of the conversation without rebooting the whole machine. For now I'll just reboot everything to continue testing. |
By using the overlay atomspace introduced in opencog/atomspace#1895 as working atomspace for openpsi and ecan, and introducing a ghost-reset command this could be achieved. |
|
Care should be made when traversing the incoming/outgoing set of atoms in the overlay-atomspace to avoid computing urges, attention-values,... based on values of masked atoms in the base atomspace, since there are no guarantee that their wouldn't be any links between masking and masked atoms. |
Hmm. this now occurs to me: when automatically making a copy of an atom into the overlay, I almost surely need to copy it's entire incoming set, too, which is currently not being done. Without this, pattern matching will be broken (because the ... ugh. I see two or three problems) The masking should be made as perfect as possible, and right now, its not. So sorry @mjsduncan this is not quite usable, just yet. |
@amebel the I also take back my earlier comment above ... maybe traversal is not such a problem. I came up with several fixes, and then realized that I didn't understand the problem I'm fixing. So, advice/request for you and for @mjsduncan -- can you please tentatively try the new new features, per example in In short, I currently don't see why "perfect masking" is needed or desirable; it's not that hard to implement, and probably would have a very small performance penalty, but I don't clearly see why its needed, at the moment. Glimmers, but nothing clear. |
@linas It was after going through the example and playing with the feature that I commented. Will "perfect masking" be required for applying the feature requested by this issue? I don't know. I added the above comments as a note |
... or not. I'm modifying unit tests to work in the new scenario, and some pass, and some unexpectedly fail. Hold your breath. |
Please ignore the remark immediately above. The unit tests work fine, after I fixed a silly little bug in #1902. Basically everything works fine. So, I believe the following usage scenario will work with no surprises, exactly as you might hope it would (?):
That is, you only load ghost once, do all subsequent work in the overlay only, and after each clear, its as if you were back at the beginning. |
... argh. Except I forgot to isolate the attention bank. And also the python bindings. So what I wrote above works, but only if ghost doesn't use the attention bank or python. ;-) Will fix tomorrow. |
For the ghost rules authoring, and more generally, we'd like a function that can return the atomspace to its initial/original state. Effectively like restarting the atomspace process, but through a function in scheme so it's faster for rules authors.
Eventually we'll have more than just the atoms for rules, like those for perceptions and actions, so we really would like all of the atoms to be reset.
The text was updated successfully, but these errors were encountered: