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]
> --------------------------------------------------------------------
>
>


--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to