opencog-dev team mailing list archive
-
opencog-dev team
-
Mailing list archive
-
Message #00173
Re: [Bug 235549] Re: unit test tests/AtomSpace/AtomTableUTest.cxxtest fails
There is already a forgetting mechanism through the use of the
ForgettingAgent in dynamics/attention/ForgettingAgent.[ch] - which, if
it isn't sufficient for your needs already, should probably be
extended instead of introducing new forgetting systems (unless using a
significantly different forgetting method).
The forgetting method should also generally be based on the LTI, not
the STI, of an atom.
The ImportanceUpdatingAgent is meant to be used for updating the
STI/LTI of atom. Why is a separate STIDecayingAgent necessary? If the
ImportanceUpdatingAgent is insufficient I can try to incorporate the
decay process (and make it optional when strict economic attention
allocation is required).
J
P.s. I just got back home, so have been trying to catch up on email
etc. Sorry I didn't catch and query this change earlier.
On Thu, May 29, 2008 at 7:13 AM, Gama <gama@xxxxxxxxxxxxx> wrote:
> I don't quite understand what you mean by enhanced. Tipically a unit
> test's scope is... a unit! :-) And, for an oo project, a "unit" will
> tipically be a class.
>
> In this particular case, rev. 635 introduced changes to a couple of classes, so what I did was:
> 1. add a new method to AtomTableUTest to test the feature(s) added to the corresponding class
> 2. add a new unit test, to test a new class (STIDecayingAgent)
>
> I don't think there's anything wrong with that...
>
> Anyway, the problem existed in the first place because the bug on the
> AtomTable was only exposed when USE_TLB_MAP is defined. Should we enable
> it by default? Because, as of right now, if it isn't defined, the tests
> AtomTableUTest, CompositeTruthValueUTest, HandleEntryUTest,
> AtomSpaceUTest, SavingLoadingUTest, NMXmlParserUTest and
> NMXmlExporterUTest break. I'm investigating it at this moment...
>
> And, more importantly, this problem had been fixed by Trent this
> morning, but you reverted his patch when you merged your changes. Was it
> by mistake or did you disagree with his fix? (fyi, I just commited a fix
> which is pretty much identical)
Follow ups