Basically, you need to have well-formed JavaBeans and
PropertyChangeEvents. The same kinds of things that will cause Jess
to have problems will cause problems for other JavaBeans containers.
Here you have a property (history) whose type is Object[], and you're
sending a PropertyChangeEvent claiming its value is now a Vector,
which of course is wrong. Just leave the old and new values null --
that's fine, Jess can figure it out. But if you mismatch the types,
then yes, there are going to be problems.
Now, as far as matching the contents of vectors and instantiating
objects and such: yes, setting things up so that you have to create
objects just to match to seems potentially wasteful. You normally
wouldn't do it in Java, so don't do it in Jess, either.
Now, as far as what a good way to design this problem would be in
Jess: just have Bid objects, with an index or datestamp for ordering
them, and don't try to hold them in a Vector or array at all. There's
little point in doing so that I can see. If you put the bids
themselves in working memory, then writing your rules should be
vastly simpler.
On Nov 22, 2006, at 1:22 PM, Helge Hartmann wrote:
Hello
I have an Java-Class BiddingHistory containing a vector of abstract
data types (composed of an Enum and an int).
The Vector is only changed by java functions.
At the moment I convert the Vector to a jess List, translating each
entry to a jess symbol. So I can use it easily in rules.
But I think about whether it is better to use the class as a shadow
fact. I then would have a multislot by the method
public Object[] getHistory() {
return vector.toArray();
}
When I do this in jess:
(deftemplate BiddingHistory
(declare (from-class BiddingHistory)))
(bind ?a (new BiddingHistory (PlayerPosition.SOUTH)))
(add ?a)
(facts)
I get this:
f-0 (MAIN::BiddingHistory (class <Java-Object:java.lang.Class>)
(dealer <Java-Object:PlayerPosition>) (history ) (lastNormalBid nil)
(lastPartnerBid nil) (OBJECT <Java-Object:BiddingHistory>))
because the vector is empty.
When I now fill the vector
(bind ?bid (new Bid (Denomination.SPADE) 1))
(call ?a addBid ?bid)
(facts)
I get an error:
Async Error: Jess reported an error in routine
DefinstanceList.updateShadowFact.
Message: Invalid argument.
...
Caused by: java.lang.IllegalArgumentException: Argument is not an
array
...
The addBid-Method looks like this:
public void addBid(Bid bid) {
Vector old = new Vector(this.bids);
this.bids.add(bid);
pcs.firePropertyChange("history", old, bids);
}
Do I something wrong? How can I use Vectors in shadow facts?
I thougt also about the performance. When I want to match the content
of the Vector, I have to create the ADT:
(defrule rulename
"description"
(MAIN::BiddingHistory (history
$?leading
?bid&:(eq ?bid (new (Bid (Denomination.SPADE) 1)))
))
=>
actions
)
So perhaps from a performance viewpoint, it could be better to use
symbols. But I think this is more error-prone than using shadow facts.
I am interested in your opinion about this.
Helge
--------------------------------------------------------------------
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 owner-jess-
[EMAIL PROTECTED]
--------------------------------------------------------------------
---------------------------------------------------------
Ernest Friedman-Hill
Advanced Software Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://www.jessrules.com
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
