-
Notifications
You must be signed in to change notification settings - Fork 234
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
Stop using SetLink for search results! #1502
Comments
👍 coincidentally I could use "the AtomSpace itself to a special kind of MemberLink" for implementing an elegant as well as efficient URE-based pattern miner (EDIT: along with outputting pattern matcher results with member links, of course). |
This now appears to be off-topic. The |
See also #1507 |
See #1967 for details on AtomSpaceLink |
To avoid cluttering the atomspace with "useless" anonymous SetLinks, one could implement a SetLink so that, when it has no incoming links, i.e. has been orphaned, then it is also removed from the atomspace. This will avoid a lot of the general clutter associated with anonymous SetLinks (they are anonymous, because they are un-named. Since there is no name, there is no way to refer to them. If they don't have any incoming set, then they really are unreferenced, and thus kind-of dead.) |
It is possible to pass child atomspace to execute_atom thus avoiding cluttering |
There's no mechanism for that. If one has |
Just to be clear: the above example actually is "realistic"; its how the robot behaviors were being done some years ago. Its actually quite natural, and fits well with time-line editors, behavior trees, drag-n-drop GUI's etc. You just "connect the dots" to get things done, and all of that nesting was just a way of flowing data through the graph. Now that we have Values, we have an alternative way of flowing data through the graph... |
There is mismatch between scheme and python api. Python api requires to pass atomspace to cog-execute and cog-evaluate. We are using it a lot. I made context manager to conveniently create and set as default child atomspaces to define query in temporary atomspace too: |
The python api is abandonware and I'm exhausted trying to fix the infinite number of bugs in it. I want to punch the people who created it, they have caused me huge amounts of pain. You can certainly do temporary work in child atomspaces - that is what they were created for. However, at some point, you have to move the desired results back into the main atomspace. (since the main atomspace is what you are saving to disk, when you power-off; its also typically the atomspace you share with other machines, when doing distributed processing.) ... In principle you could save child atomspaces also, but that is currently not implemented in the postgres backend. (and since the distributed atomspace depends on postgres, you also cannot have a distributed-child-atomspace) Anyway, the whole point of the |
Do you still use this approach? Is there example of implementing main loop in atomese? I would certainly look more into it to use this approach in the future. Code that i linked is intended to be released for general machine learning community. It is kind-of code generator for building neural networks during inference along the lines of #1970. It's quite hard to write in atomese, at least harder than in general purpose programming language. We don't even have a language tutorial yet. That's why main loop is in python and not in atomese. There is example of training on sum of two digits from mnist https://github.com/singnet/semantic-vision/blob/2681f93cf12ee0e5c1a53faef28a815d9e9c857c/experiments/opencog/cog_module/mnist.py bottom line |
It seems we need atomese operators to manipulate atomspaces e.g. create and delete child atomspaces. Then it will be easier to port some code from python/schema to atomese |
Yes. Hit bug opencog/opencog#3433 only a week ago, when I broke tail recursion during the cleanup.
Yes. |
Well, as I stated repeatedly there, I think that using the grounded schema node is a deep and fundamental mistake. Last summer, during very long and detailed email conversations with @Necr0x0Der Alexey Potapov, we worked out, in considerable detail, exactly how to map neural nets into the atomspace. I was rather unhappy that you decided to throw these plans away, without any discussion, without any warning, for no particular reason, and create something completely new, different and incompatible with any sort of long-term roadmaps. I still do not understand why the original plan for neural nets was thrown away. I think it was a decent plan, a good plan. And I'm still deeply unhappy with the GroundedSchema design, for all the reasons that I already explained.
Atomese is not supposed to be written by human beings. That's the whole point. Only code generators should read and write Atomese. Not humans. This means that all of the code generators need to be compatible with each-other. The original neural-net design was compatible with the existing code generators (the chainers, the miner, PLN, openpsi, ghost) The grounded-schema design is incompatible with the code generators.
For which language? There are 27 tutorials for atomese in |
Can you open a new issue to discuss this topic? I don't understand why this is needed. |
#2105 - new issue |
OK, I'm thinking that now is a good time to move forward on this. (Yes, @noskill the temp-atomspace idea works too; but there are also other reasons to change the API too -- e.g. parallelism) I think I found a simple solution. Create a new link, call it To provide backwards-compat, every New users will be encouraged to use By running |
examples and language tutorial/introduction are different things. Otherwise you would name that directory "tutorial" and not examples. I personally look for information in opencog wiki, and update it sometimes. And actually our design is somewhat compatible with pln. I need to rewrite Implication and fuzzy conjunction rules yet. This in turn will give up learnable weights for links. Currently there is not way to backpropagate error to these weights. |
The examples directory is the de-facto best, clearest and most complete language tutorial. We could trivially rename that directory "tutorials", if that makes you happier. The "tutorials" on the wiki are in terrible condition. First, out of the 50-or-so examples/tutorials in the examples directory, the wiki pages cover maybe 3 or 4 of them. Those were written by someone who was trying to learn the atomspace for the first time ever. And worse -- they had no long-term plan to actually do anything with the atomspace, so no motivation to make the tutorials "meaningful", illustrating how certain kinds of problems can be solved in certain ways in the atomspace. The net result is that the quality of the "tutorials" on the wiki is very low. |
Thanks Linas, we'll get in contact with Misgana for knowledge sharing. |
I agree on what are you saying about distinction between values and atoms. We did not use any new atom types yet. Vitaly implemented ptrvalue, so that pyobject can be attached to atom. Everything neural network related is stored in values. This value type is incompatible with other atomese datatype, but that is the price of backpropagation. It can be converted to float if needed. |
Well, I think you understand what I've been trying to say. Perhaps its time for me to review the ptrvalue thing again. Are you saying that you're actually doing backpropagation in the atomspace itself ? I was assuming that you're just wrapping code that does computation elsewhere (i.e. on gpu's) anyway, we should have this discussion on some other github issue, or mailing list, not here. |
All that is discussed here is related to the issue #1970, i'll update it instead of creating new one |
I just want to consider the option where SetLink is replaced by MemeberLink with AnchorNode.
The current result for GetLink is:
And the result of PutLink is:
If I understand correctly the new proposed design suggests:
What is expected behavior of PutLink in this case? Could such functionality be added in two steps:
|
Yes, more or less. AnchorNode is also an imperfect solution; thus I'm interested in a publish-subscribe system. #1750 which is meant to be better than AnchorNodes. One problem with Anchor nodes is that if there are two users (two threads) each grabbing one atom (dettaching it from the Anchor Node, and then "processing" it) then there are race conditions where the two threads might both get the same atom. Maybe we can fix this with a There are other possible solutions: maybe the results of a Get/Bind should be attached to a Value, somewhere, instead of a MemberLink. So maybe have a
Backwards-compatible, in some way. It should "do the right thing", whatever that is. It is not always clear what the "right thing" is, and so some careful thinking and design and prototyping is needed. I like things that are small, simple, and have little or no negative impact on the performance of existing systems. I don't want 99% of the users to run slower, just so that 1% of the users can use some new whiz-bang feature.
Maybe. If you are really interested in this, put together a detailed design (in some other github issue) that shows exactly how this might work. I'm kind-of interested in solutions that solve big problems -- i.e. not just get/put, but also bindlink, also the queueing/dequeueing problem. The SetLink alone is itself not all that terrible -- its really a symptom of the bigger problem of "how does the data flow around?" that needs to be solved, that needs to have better solutions. |
I just want to summarize problems related to SetLink to have a deeper view on this question.
Possible solution could be using MemberLink. For example using AnchorNode:
or a set can be marked by some specialized node like SetNode:
Control flows:
PutLink can work as busy loop which checks for new results or this can be implemented as publisher/subscriber system where GetLink notifies subscribers that a new result is available Results of GetLink can be stored in AtomSpace as MemberLink or it can be internally implemented program objects which are directly used by PutLink. Possible solution where results are stored in MemberLinks:
results:
PutLink uses SetNode as argument to know where to retrieve results from:
(Just a curious question. Why PutLink mentions its argument as the last atom after the body? Is not more naturally to place the argument after the variable list and before the body? ) SetNode can contain its control information as values:
When GetLink finishes it sets SetNode "done" value to true. MemberLink has "lock" value. If someone needs to delete an element of the set it needs to lock the MemberLink link to not allow to read/delete it by other subscribers. Another option is to not put results of GetLink into AtomSpace. In this case different program primitive like promise/future, queue or publish/subscribe systems can be used.
There should be a unified way to remove links which are used only to pass results from one place to another. May be some ArgumentLink which means that PutLink passes values from ArgumentLink to LambdaLink and then removes the LambdaLink.
The current PutLink implementation first executes its arguments and then puts it to body. In this case PutLink description should be revisited so it is not just a beta redex. |
FYI: please note: issue #1750 describes both a |
Pull req #2500 implements the initial idea discussed at the very top, that began this long conversation. It's simple (very simple, actually) and it works. ... ... but in some senses, its incomplete. The above discusses the need for a To provide more details: the pull req #2500 allows this:
and the search results will be attached with |
FYI, The following updates are relevant:
|
This partly resolves issues opencog#2530 and opencog#1502
Summary and state of affairs.
|
Closing. Replaced by #2911 |
SetLink
has a number of technical issues with respect to the core concept of atoms and how atoms should be used. Basically, SetLink is a bad citizen. The only answer I can find is to simply excommunicate, banish SetLink from the Kingdom. The correct solution is to useMemberLink
instead. (See however, other ideas below.)Unfortunately,
BindLink
andGetLink
, when executed, returnSetLink
's containing the search results. This needs to be replaced byMemberLink
, and specifically, I think the following form might work best:and then have
cog-execute!
return theAnchorNode
-- all search results can then be found, attached to this anchor.Q: Why is SetLink bad?
A: See the wiki page for it. https://wiki.opencog.org/w/SetLink
Q: Why AnchorNode?
A: It seems like the best kind of node for this job.
Q: What other benefits (besides avoiding SetLink)?
A1: Search results can be reported incrementally, as the search proceeds, instead of waiting for one big glob to appear at the end.
A2: The SetLinks that get returned glom up the atomspace, and people usually forget to delete them. They are hard to delete - you have to actually have them in your hand to delete them - searching for them later on is really hard or impossible. By contrast, finding and deleting the AnchoreNodes is easy, and can be done at any time.
A3: Its a baby-step to converting the AtomSpace itself to a special kind of MemberLink and/or ContextLink. Having to pass the AtomSpace around in various methods is a real pain, and causes a lot of programming issues. It would be nice to just get rid of the atomspace entirely, and instead declare membership as:
This or something like this could solve a lot of technical problems, and nuking
SetLink
is a natural first step.I believe that this will simplify creating a distributed atomspace. We could layer everything on top of (for example Redis or Riak and have that do all the work of distributing atoms.I don't believe this any longer. TheStorageNode
is a superior solution for distributed atomspaces.A4: If we do the above or something like it, we could merge MapLink/BindLink, since they both do almost the same thing, just that MapLink does it for its arguments, while BindLink does it for the entire atomspace. Similarly GetLink/FilterLink...
Q: Is this a lot of work?
A: You bet. BindLinks are used all over the place.
The text was updated successfully, but these errors were encountered: