Ok, I'm starting to see now. Missed the second mail from Andreas there,
and therefor I didn't know the point was to avoid duplicates. This is a
all other problem then the one I was describing. In CHR this one's
called achieving set semantics and in some implementations (like the
Chameleon internal engine) it in fact is standard behaviour. So I agree
with you that this could be an interesting option for Drools. Most
implementations of CHR I know of though have it standard switched off
and you have to add a rule like
triple(R, P, O) \ triple(R, P, O) <=> true.
to have the same effect (this rule removes duplicate triple-constraints
(read: facts)). The motivation is that in some cases you do want to have
bag semantics (where multiple copies of the same fact can exist). More
mature systems will then detect intended set semantics (by analysing the
program and detecting rules like the one above) and produce specialized
code for them. This is in fact what declarative programming is all about!
p.s.: I realize now that I drifted somewhat away from production rules
to constraint handling rules (CHR), since this is my field of expertise
and I cannot program all that well in Drools yet, but they are in fact
not that different...
Michael Neale wrote:
> well not really. If someone has a rule where they declare they want 2
> objects of type A,
> Then most of the time, they just want the "interesting" permutations from
> matching objects in working memory. A hashcode is just an arbitrary way of
> providing an order (refer to
> http://www.redhillconsulting.com.au/blogs/simon/archives/000213.html
> <http://www.redhillconsulting.com.au/blogs/simon/archives/000213.html>for an
> example in SQL using an id field, which is really just as arbitrary in the
> database world).
>
> I think it does need to be an option for people to use, the question is to
> make it default or not. It just seems that whenever someone writes rules
> that take multiple same type parameters, they get into trouble when they
> didn't really need all those extra combinations to start with.
>
> The fact that the hash code changes with each run (possibly) doesn't matter
> in this case, unless you magically expect certain objects to appear bound to
> parameters based on their order, which doesn't even make any sense anyway.
> In this case he was saying that he didn't need the extra combinations, and
> identity is a efficient way to achieve this.
>
> Michael.
>
>
>
> On 1/23/06, Peter Van Weert <[EMAIL PROTECTED]> wrote:
>
>>Michael Neale wrote:
>>
>>>Hi Andreas.
>>>
>>>The Combination monster strikes again !
>>>
>>
>>A monster indeed ;-)
>>
>>
>>>Add this as your first condition:
>>> <java:condition>System.identityHashCode(Y) >
>>>System.identityHashCode (X)</java:condition>
>>>
>>>This will ensure that only "useful" combinations are added. When I add
>>
>>that,
>>
>>>9 tuples took about 14milliseconds, and 20 took about 1 second (!) -
>>
>>your
>>
>>>mileage may vary. Before that I was getting worse times then you (my
>>
>>machine
>>
>>>in more humble, it would seem?). Perhaps you can confirm that this is
>>
>>what
>>
>>>you need?
>>
>>Personally, I doubt it. Its a difficult question to answar what are the
>>useful combinations. In constraint programming this translates in the
>>question of what to propagate. There is a lot of knowledge that can be
>>derived from a given knowledge base, but infering it all is in general
>>not a very good idea. Indeed, *every* rule that fires in this particular
>>test introduces redundant information. The extra constraints you are
>>posing on the information infered by simple transitivity here is based
>>on their identity hash-codes? How can that be a measure of usefulness?
>>Besides, every run of your program will give different (indeterministic)
>>results...
>>
>>But hey, that's just my idea...
>>
>>Chears,
>>Pé
>>
>>
>
>
