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.