From: Ernest Friedman-Hill <[EMAIL PROTECTED]>
> I think Osvaldo Pinali Doederlein wrote:
> > 2. Is it a good idea to have those unique ID codes to do references
between
> > things (I'm using deftemplates for all stuff). My objects are a complex
> > graph and there's no way I can generate the facts using references for
the
> > fact-IDs in a single pass; I would need to do some postprocessing in the
> > fact database in order to have that but it's an option. Basically, I
need
> > to have tons of pointers btw facts and I have forward references,
cycles,
> > every damn thing.
> This is a classic complaint about the CLIPS fact model. Have you
> looked, by the way, at using defclasses and Beans instead of
> deftemplates? That's a better technique for object-like things.
Yes I saw that, but I thought it wouldn't be a great idea in my case as a
1-1 translation of my Java objects wouldn't cut it, I use lots of JDK
collections, and there's the reflection-from-Jess overhead too. But I have
a friend starting with Jess and he will be doing some parsing of Java with
JavaCC/JJTree and use its automatically generated AST's output as facts, I
think the beans thing would be great there.
> It's very similar to RDBMSs. In fact, there was (and is) a lot of
> overlap between the people who developed this sort of ES technology
> and who developed heavy-duty relational database technology. Many
> folks (David Miranker is a a good example) continue to blur the
distinction.
Thanks :) Good that I don't need to rewrite this, look!!
http://student.vub.ac.be/~opinalid/thesislides-1/index.htm
http://student.vub.ac.be/~opinalid/thesis.htm
Jess has fit perfectly in this work, I've got all Java/Jess bridging
infrastructure and my first inference results working in one week. My first
such code of any kind since a little bit of LISP&OPS5 in my graduation years
ago -- and I sweared to forget that and never back. ;)
> > This code works, but it will detect twice all my sibling classes, e.g.
if I
> > have A and B derived from the same base class, I'll get "Found siblings:
A,
> > B" and also "Found siblings: B, A". I fully understand why this
happens,
> > but not how to prevent it :)
> The most common solution is to put a note onto the fact-list
> (defrule siblings "Finds sibling classes in the inheritance tree"
> (Generalization (parent ?parent-code) (child ?child-code-1))
> (Generalization (parent ?parent-code) (child ?child-code-2))
> (test (neq ?child-code-1 ?child-code-2))
> (not (done ?child-code-2 ?child-code-1))
> (Class (code ?child-code-1) (name ?child-name-1))
> (Class (code ?child-code-2) (name ?child-name-2))
> =>
> (printout t "Found siblings: " ?child-name-1 ", " ?child-name-1 crlf)
> (assert (done ?child-code-2 ?child-code-1))
> )
Good. So I "reivented" another whell, I did the same but I only have the
assert there and I put the printout or whatever other "client" code in a
different rule; so I have a "find-siblings" and a "print-siblings" rule, and
a "siblings" fact.
Is there a magic, "standard" quick way to create a very big number of facts,
say 10,000 or even 50,000? I'm already doing my own Fact object creation
bypassing the assertString()'s use of parser, but creation is still dead
slow. Well I profiled everything and all time was taken by assert()'s
checking of duplicate facts. I wrote my own version of the assert(), just
removing the checks - and also those token and event generation, and this
alone slashed by fact creation business from 33 seconds to 0,721s !!! :-)
Maybe this is dangerous, but I'm generating the facts in batch mode before
any rules are running and the fact-making code is guaranteed to not generate
any duplicates (I checked that by inserting debug printlns in assert()).
This is the streamlined version, added to the Rete class, you may want to
have something like that to help people doing lots of facts in the same
fashion as I do. Unfortunately I can't extend Rete cleanly with inheritance
because m_facts is private! So I will keep polluting your code :)
public int assertQuick (ValueVector f) throws ReteException
{
synchronized (m_compiler)
{
// insert the new fact
f.set(new Value(nextFactId(), RU.FACT_ID), RU.ID);
m_facts.addElement(f);
return f.get(RU.ID).factIDValue();
}
}
A+
Osvaldo
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
