Closed TonyLo1 closed 8 years ago
There is an exists? function. If when this one returns true, update-element is called, and if false, add-element as usual, the issue does not arise. To not have this logic at caller side, I suggest adding this check in add-element itself.
For completeness, the behavior can be explained by this:
At the stage of adding the new element of existing ID, the bag is full. Which means add-element triggers popping an element (altough the ID exists): It removes one element of the list of lowest priority elements (which are multiple because all have 0.1 priority), in this case it removes the id 4 element, and adds the new element of existing ID ( (add-element bag' element) ).
The real issue now is that we end up with a not sorted priority-index and one element too much removed, the latter happens because of the previous step, and the former because the following happens: priority-index' (conj priority-index (el id priority)) This does not update the order of the existing ID instead it just overwrites its priority.
So two possible solutions are:
Related pull request: https://github.com/opennars/opennars2/pull/38 Will close the issue when this one has be merged.
See this gist for details: https://gist.github.com/TonyLo1/3a461e5e4fd8a3e675298d3a22de59ad
Summary, on full bag adding elements with existing :id causes unrelated elements to be removed. For example adding :id 0 with new :priority causes :id 0 to be updated but :id 2 to be removed (see gist)