[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compound operators
From: |
Jaroslav Hajek |
Subject: |
Re: compound operators |
Date: |
Tue, 13 May 2008 07:15:19 +0200 |
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