[Date Index]
[Thread Index]
[Author Index]
Re: Locating common subexpressions
*To*: mathgroup at smc.vnet.net
*Subject*: [mg69465] Re: Locating common subexpressions
*From*: p-valko at tamu.edu
*Date*: Wed, 13 Sep 2006 04:02:27 -0400 (EDT)
*References*: <ee645p$5d4$1@smc.vnet.net>
R = (3 + 3*a^2 + Sqrt[5 + 6*a + 5*a^2] + a*(4 + Sqrt[5 + 6*a +
5*a^2]))/6 ;
Experimental`OptimizeExpression[R]
???
carlos at colorado.edu wrote:
> The strangest thing about the behvior of Simplify in my
> previous post can be seen at a glance:
>
> R = (3 + 3*a^2 + Sqrt[5 + 6*a + 5*a^2] + a*(4 + Sqrt[5 + 6*a +
> 5*a^2]))/6
> R = Simplify[R,a>=0]
> (3 + 3*a^2 + Sqrt[5 + 6*a + 5*a^2] + a*(4 + Sqrt[5 + 6*a + 5*a^2]))/6
>
> The subexpression Sqrt[5 + 6*a + 5*a^2] is not located. Ideally
> Simplify should right away replace that by a temp, say t$, and
> get to work on
>
> (3 + 3*a^2 + t$ + a*(4 + t$))/6
>
> where from the assumptions, t$>0 and real. Of course the leaf count
> of t$ should influence subsequent transformations.
> This initial pass is useful in complicated expressions that come, eg,
> from an equation solver since messy subexpressions like the
> discriminant may appear in several places. I had some of those
> with leaf counts in the tens of thousands.
>
> Locating common subs is of course an key task of optimizing
> compilers. Simplification and compilation share some objectives,
> although compilers have to deal with timing and side effects. In fact
> I wouldnt mind at all if Simplify would return a compound expression:
>
> Block [{t$}, t$=Sqrt[5 + 6*a + 5*a^2]; (3 + 4*a + 3*a^2 + (1 +
> a)*t$)/6 ]
>
> since this is perfect for documentation, or conversion to low-level
> code.
Prev by Date:
**Re: General--Different Results**
Next by Date:
**Re: General--Different Results**
Previous by thread:
**Re: Locating common subexpressions**
Next by thread:
**Known recursion link to Hermite polynomials not solved in Mathematica**
| |