Re: compound operators

[Jaroslav Hajek]

On Tue, May 13, 2008 at 5:59 AM, John W. Eaton <address@hidden> wrote:
> On  8-May-2008, Jaroslav Hajek wrote:
>
>
> | I hope not. The tree_compound_binary_expression class has a slightly
>  | different philosophy:
>  | it does not "own" the stripped operands, just stores pointers to them
>  | (note that it has no destructor). The orginal operands is still owned
>  | by the parent tree_binary_expression object.
>
>  OK, I see now.
>
>
>  | I thought this would be the best design - the compound operator needs
>  | not be visible to printing code (we want the code to print normally
>  | like `A'*B') or breakpoints, so tree-print-code and tree-breakpoint
>  | need not care. The original expression is retained, because it may
>  | still be useful. For example, we may later want to implement a
>  | simplification that
>  | trace (A*B) evaluates as sum((A.*B)(:)) (this is probably not of much
>  | use, but demonstrates the matter). With my approach, trace (A'*B) will
>  | be properly simplified, because the A'*B expression can still be
>  | identified as a multiplication.
>
>  Will this always work as we want, or could there be problems if we
>  perform additional transformations on the parse tree?
>
>  jwe
>

Currently, the answer is yes, because once a node is constructed, its
operands (subtrees) seem to be immutable. That's why I favored
"evaluation shortcut" to modifying the true expression tree.
If we want some transformations in the future, it should be OK if
they're invoked via virtual function(s) - we simply override to retry
the simplification afterwards, or just invalidate it.

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz