Re: Re: PEAK-rules question

On Thu, Sep 5, 2013 at 4:08 PM, S=E9bastien de Menten <[email protected]>=
 wrote:
>
> On Tuesday, 3 September 2013, PJ Eby wrote:
>> 2. "Pattern matching" or "compiler" functions -- while one or two
>> parameter types may be involved, the bulk of the rules are predicates,
>> often deeply nested predicates on component objects; often found in
>> compilers or compiler-like systems (such as PEAK-Rules itself) to
>> pattern-match subtrees with complex conditions.
>>
>> In pattern #2, evaluation order may be rather important, but the tree
>> size is fairly limited by the fact that most of the actual predicates
>> exist for only a few rules.  In pattern #1, the bulk of the indexing
>> is for that handful of parameters, so as long as they're
>> freely-orderable (i.e., can be tested independently), you can't get a
>> blowup of tree size.  (And in pattern #1, the tests are usually done
>> directly on the parameters, not on attributes or methods or formulas
>> using the parameters.)
>>
>> >From your vague description, I can't tell if your use case is more
>> like #1 or #2, or some sort of hybrid.  If it's basically #1 but using
>> lots of independent attribute-level checks, and you have very large
>> rulesets, then you may want to promote the attributes to parameters
>> (or access those attributes in different order some of the time), in
>> order to allow PEAK-Rules full tree reordering freedom.  It will not
>> affect the answers you get, only memory usage (and possibly speed).
>> Even then, it's unlikely to do it in the kinds of uses I'm familiar
>> with, but since I'm not familiar with your case, I am being
>> extra-thorough and cautious.  ;-)
>
> It is definitely more the #2 (pattern matching).

Well, that's good; the base algorithm can usually perform at least as
well for that case as a human-optimized decision tree, in the case
where the human doesn't know anything about how often different
branches are taken.  ;-)

(In theory I could add dynamic branch optimizations, but in most
applications it might use more time than it saves.)

> Is there some introspection
> ability on the decision tree PEAK-rules build ?

Not at present, no.

> Otherwise, i'll check first
> the overhead to see if it is penalising or not before optimising.
> Thank you for you detailed description of these mechanisms !

There is even more description in the various .txt files in the
source, which document and test various internals, if you want to know
more.