MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

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


  • Prev by Date: Re: Simplifying and Rearranging Expressions
  • Next by Date: Re: Re: Re: ListCurvePathPlot
  • Previous by thread: Re: Simplifying and Rearranging Expressions
  • Next by thread: Re: Simplifying and Rearranging Expressions