In order to avoid re-evaluating programs and sub-programs multiple
times we want to save the results of their evaluations so that if the
interpreter is called again time it only needs to recall the results
rather that recalculate.
For instance if program candidate P is provided to the interpreter
(Plus
(Schema "i1")
(Schema "i2"))
the first time the interpreter will may evaluate it, but the second
time, even if that time P is only a sub-program of another program
P' it may re-use the memorized (cached) values.
then P is a sub-program of P' and shouldn't be re-evaluated.
In order to store the results of these evaluations I suggest to use
the same mechanism for efficiently storing feature values described in
issue #16 . That is upon encountering an atom to evaluate, the first
thing the interpreter would do is to check whether some values are
attached to key
Node "*-AS-MOSES:SchemaValuesKey-*"
if so, then return these values, otherwise proceed with the
calculation.
So note that in order to work well the return C++ type of that atomese
interpreter should be ProtoAtomPtr, not Handle, just like in
Instantiator::execute().
So it goes with saying that in such a case the Atomese interpreter
will simply return a proto atom representing the list of values, not
the representation described in the Section Update the Atomese Interpreter
to Handle Problem Data of issue #3 , but at this point of the development it's fine.
In order to avoid re-evaluating programs and sub-programs multiple times we want to save the results of their evaluations so that if the interpreter is called again time it only needs to recall the results rather that recalculate.
For instance if program candidate
P
is provided to the interpreterthe first time the interpreter will may evaluate it, but the second time, even if that time
P
is only a sub-program of another programP'
it may re-use the memorized (cached) values.For instance if program candidate
P'
isthen
P
is a sub-program ofP'
and shouldn't be re-evaluated.In order to store the results of these evaluations I suggest to use the same mechanism for efficiently storing feature values described in issue #16 . That is upon encountering an atom to evaluate, the first thing the interpreter would do is to check whether some values are attached to key
if so, then return these values, otherwise proceed with the calculation.
So note that in order to work well the return C++ type of that atomese interpreter should be
ProtoAtomPtr
, notHandle
, just like inInstantiator::execute()
.So it goes with saying that in such a case the Atomese interpreter will simply return a proto atom representing the list of values, not the representation described in the Section Update the Atomese Interpreter to Handle Problem Data of issue #3 , but at this point of the development it's fine.