Re: Simplifying and Rearranging Expressions

*To*: mathgroup at smc.vnet.net*Subject*: [mg96014] Re: Simplifying and Rearranging Expressions*From*: David Bailey <dave at removedbailey.co.uk>*Date*: Sun, 1 Feb 2009 04:41:28 -0500 (EST)*References*: <gls1u8$hjl$1@smc.vnet.net>

David Park wrote: > I want to start a thread on this because I believe many MathGroup people > will have some useful things to say. > > > > A common task for Mathematica users is to obtain an expression that is in a > particular form. For students and teachers this may often be a textbook > form, or there may be other reasons that a particular form is desired. > > > > It might be thought that this should be an easy task but quite often it can > be a very difficult task, even involving mathematical derivation and many of > the capabilities of Mathematica. Not obtaining a specific form may be a > matter of not knowing how to solve the problem in the first place. > > > > Nevertheless, even simple rearrangement can be difficult. I sometimes think > of it as doing surgery on expressions. I believe it is generally desirable > to use Mathematica to rearrange an expression and not retype the expression. > Retyping is too error prone. > > > > Simplify and FullSimplify are amazingly useful but it is difficult to > control them and obtain a precise result. One will often have to do > additional piecemeal operations. One downside of Simplify and FullSimplify > is that they can return different forms with different Mathematica versions. > Then any additional operations in an old notebook may no longer work. It > would be nice if there was a method of using these commands that would be > more version independent. > > > > Various routines such as Together, Apart, Factor, TrigReduce, TrigFactor, > TrigExpand, TrigToExp, GroebnerBasis etc., can be useful in getting a > specific form. MapAt is very useful for doing surgery on specific parts of > an expression. Mathematica often gets two factors that have extra minus > signs. You can correct that by mapping Minus onto the two factors. For > integrals in the wrong form you could cheat by trying to find the constant > by which they differ by subtracting and simplifying, and then use that in > the derivation. > > > > Over the years I've collected a number of routines that aid in manipulating > expressions and have included them in the Presentations package. Some of > these are: CompleteTheSquare, FactorOut (any 'factor' expression with > ability to hold results such as factoring from a matrix), MultiplyByOne (a > common mathematical technique), LinearBreakout, PushOnto (much better than > Through), HoldOp (hold a specific operation but evaluate the arguments), > CreateSubexpression (creates a tooltip and holds expressions together with a > tag so they won't get split by routines like Simplify), > ReleaseSubexpressions, MaplevelParts (apply an operation to a subset of > level parts, for example Factor three out of five terms in a sum), > MapLevelPatterns, EvaluateAt (evaluate specific parts of held expressions), > EvaluateAtPattern. SymbolsToPatterns, LHSSymbolsToPatterns (convert specific > derived rules to general patterned rules). > > > > It is very useful to get Mathematica generated expressions into the form > that one wants. I believe that this is probably a sticking point with many > users. In general it is not a trivial topic. Others may have some good > general ideas that I don't know about. Someday someone may even write a good > tutorial on it. > > > > > > David Park > > djmpark at comcast.net > > <http://home.comcast.net/~djmpark> http://home.comcast.net/~djmpark/ > > I very much agree that this capability would greatly enhance the range of tasks that can be handled by Mathematica. Some years ago (version 3.1) I developed the "Coloured Expressions" package to attack this problem. My idea was that in many real world cases, expressions can be large and heterogeneous - you absolutely need to be able to direct an operation such as Together at one particular part of an expression. The package had a palette, and when you selected a subexpression and pressed a button, the selected expression was wrapped in Red[] (in those days Red was not a built-in symbol) and MakeBoxes rules were used to make this display as a red expression. Several colours were available, together with a set of functions that could apply a function such as Together, or a transformation such as Sin[x]->x-x^3/6 to the coloured parts of the total expression. Essentially this was a more visual way of achieving what David Park's MaplevelParts function does (we discussed this privately some time ago). Those who used the package seemed to like it. It seems to me that with version 6/7 a better approach might be to expand an expression by recursively wrapping each box in a structure that would flash as the mouse passed over it and would have a tooltip specifying a tag - something like "1.3.2.1" (the first box of the second box of the third box of the first box of the total expression). Such a string could be fed to a modified version of MaplevelParts. Of course, given an expression such as a+b+c+d, it was possible to colour (say) b and d - forcing these to be treated as a single subexpression, whereas the actual BoxForm uses a flat representation of such an expression - so a little more subtlety might be required - perhaps "1.3.2.1(2,4)" In manipulating an expression, I think it is important to distinguish between universally valid mathematical operations, operations with restricted validity, such as the Sin expansion example above, and totally arbitrary operations (such as a transformation rule) that can destroy the mathematical integrity of an expression completely (e.g. Cox[x]->x-x^3/6). A great deal of the value of such an expression manipulation system would be that it would provide something akin to an audit trail. Thus you don't want most of the steps to rely on transformation steps that depend on the user rather than on Mathematica or a stock of validated expressions. David Bailey http://www.dbaileyconsultancy.co.uk