Sorry for the delay.
I'd say that if the full evaluation of the simulation of some reaction
requires changes
in the representation of the real world in several stages (*) then
Ernest's proposal of
using two engines is best.
(*) Several stages is crucial. If it is just an assessment of the determined
reaction, you don't make any changes to the facts representing the environment,
but I think that's not what you need to do:
Implement determined action on the simulated world facts
Rules fire, causing secondary changes on the simulated world facts
(and so on, until it dies down)
If you do use two engines, you'll need to copy all the facts from the
hot engine to
the simulation engine, at least when you know that they have drifted apart. This
may cause a considerable overhead depending on the number of facts and rules.
Wolfgang
On Fri, Dec 5, 2008 at 9:14 AM, Nick Tinnemeier [EMAIL PROTECTED] wrote:
Wolfgang, thank you for your reply. You are right I should provide some
explanation of the problem I am trying to solve here. Could be that you have
an even better solution. :-)
I have two modules. One module represents the facts about the real world
that is possibly modeled by Java objects, which means that some shadow facts
might be involved. The other module's purpose is to reason about what the
effect of firing some rules would be in the environment, without - and this
is of crucial importance - modifying this real world. This other module does
not contain shadow facts. It is intended to be a dry run. Then, based on
some evaluation of the resulting fact base, I would like to effectuate the
result in the real world or not. A rollback mechanism is not an option
because modifying the Java code might have side effects which cannot be
undone, e.g. sending an e-mail.
One solution I had in mind is to make an exact copy of the modules, i.e.
copying all the deftemplates (mimicking defclasses) and rules. Effectuating
the result of the dry run in the real world then becomes a matter of simply
switching focus to the other module and running it. It seemed to me that
doing exactly the same thing twice would be rather silly and it would be
more appropriate to use the track and redo actions approach I mentioned in
my earlier post. Now I realize that doing this might be a bit tricky, as
retracting and modifying facts depends on a fact id (are these the same in
both modules?).
Hope this information gives some more insight in what I am trying to do
here.
Cheers,
Nick.
Wolfgang Laun wrote:
First, I would not use defadvice. If you call assert in the second
module, you won't want to add the argument to the linked list. I *think*
that event handling would be more appropriate, even though this might mean
that you'll have to write some Java code.
You write that you want to repeat all assert, modify and retract calls in
the second module. It seems that you'll want to have the facts in that
second module to be a copy of the ones in the first module. If that is so,
what is the purpose of this exercise? Saving facts so that they can be
safely restored later on can be achieved easier by, e.g., calling
save-facts.
I hate to give advice without understanding what the other guy is trying
to do; discussing things on a mere technical basis is (mostly) a waste of
time...
Cheers
Wolfgang
On Thu, Dec 4, 2008 at 12:57 PM, [EMAIL PROTECTED] mailto:[EMAIL
PROTECTED]
wrote:
Hi,
I have two modules that are similar. The rules are fired on one
module and
there facts are asserted, modified and retracted. Based on some value
these actions need to performed on the second module. I thought it
might
be a good idea to approach it in this way:
(defglobal ?*acts* = (new LinkedList))
(defadvice before assert
(?*acts* add $?argv)
)
(deffunction makeithappen ( )
(foreach ?a ?*acts*
; call the action
)
)
In words, I store all the actions in the acts list whenever assert is
called. Then, the function makeithappen calls all the functions
again, but
then on the second module. How can I do this? Or is there another way?
Regards,
Nick.
To unsubscribe, send the words 'unsubscribe jess-users
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED].
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
