Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2009

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

Search the Archive

Re: Re: Simplifying and Rearranging Expressions

  • To: mathgroup at smc.vnet.net
  • Subject: [mg95979] Re: [mg95956] Re: Simplifying and Rearranging Expressions
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Sat, 31 Jan 2009 01:14:48 -0500 (EST)
  • References: <gls1u8$hjl$1@smc.vnet.net> <200901301047.FAA06653@smc.vnet.net>

To my amazement I have found something that I agree here. I do agree  
that it is largely a pointless waste of time to use computer algebra,  
which relies on pretty complex algorithms (like Groebner basis) to  
make this **look** the way you want them to look, for reasons that  
have no particular relation to these algorithms. Its a waste of  
computing resources, the effort of mathematicians and programmers and  
most of all the user, who could much more easily achieve this effect  
in other ways, one of which is TeX (even better was, in my opinion,  
was David Bailey's clever idea to use color to manipulate Mathematica  
expressions almost as one does by hand - unfortunately this appears to  
have been abandoned due to lack of interest).
I don't think however there is any chance whatever of WRI  
incorporating TeX into Mathematica, for two reasons. One is that it  
would be going against their principal idea of having all Mathematica  
expressions fully controllable by means of the Mathematica programming  
language. Clearly this would not be true of TeX strings, if they were  
meant to be interpreted for display. Secondly, because other CAS  
systems have essentially tried to do this sort of thing with very  
little to show for it in terms of market success. You seem to be  
completely unaware of how tiny the TeX users community is compared  
with the community of users of programs like Mathematica.
This reminds me also that a lot of suggestions which you have made  
about the way Mathematica ought to be (simple, cheap, computation  
engine, no fancy staff) has already been tried by WRI and clearly  
failed. It was called something like The Computation Center, and  
limited version of Mathematica, that Wolfram once sold for a fraction  
of the price of the full thing. The only problem was that hardly  
anyone bought it (I suspect you did not either).
Not surprisingly WRI is likely to be pretty skeptical of bright ideas  
that remind them of things that they or others have already tired and  
have been shown not to work.

Andrzej Kozlowski

On 30 Jan 2009, at 11:47, AES wrote:

> In article <gls1u8$hjl$1 at smc.vnet.net>,
> "David Park" <djmpark at comcast.net> wrote:
>
>> I want to start a thread on this because I believe many MathGroup  
>> people
>> will have some useful things to say.
>
> I'll bite, because I've done a bit of thinking on this.
>
>
>> 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.
>
> Just to add a bit of specificity to this, let's consider expressions
> that arise in optics and e-m theory, which generally involve a set of
> physical quantities (velocity of light, propagation constant,
> permeabilities, index of refraction, frequency, wavelength,
> characteristics impedance, critical angle of refraction, and multiple
> others) that are conventionally written as
>
>   c, k, (or beta), mu, epsilon, n, f (or omega), lambda,
>   eta or z_0, thetaCrit, and so on
>
> **each of which is directly linked or coupled to (that is, can be
> calculated from) several others in the same set**.
>
> [You have to put up with a side story at this point.  The  
> distinguished
> physicist W. K. H. Panofsky, who just recently died, early in his  
> career
> co-authored with Melba Phillips a small but excellent text on  
> classical
> e-m, colloquially known as "Panofsky and Phillips", from which I and
> many others studied.  This was long enough ago that cgs and mks units
> were still fighting it out in the physics community.]
>
> [P and P beautifully sidestepped this issue by, as they noted in the
> Preface to their book, writing every equation in their book using an
> appropriate (but generally different) subset of the above symbols,  
> such
> that every equation was valid in mks units as it stood, **and could be
> instantly converted to be exactly valid in cgs units as well, simply  
> by
> replacing any factor of epsilon that appeared in any of these  
> equations
> by 1/ 4 pi **.]
>
>
>> 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.
>
> It may not be just a difficult task;  in fact, **it may be an  
> impossible
> task** -- not to mention **an unnecessary and undesirable task**.
>
> 1)  As already noted above, you may want to write expressions that
> contain some subset of a linked set of variables in different ways at
> different points in an exposition, because these different ways are
> conventional in the field, and/or make the physical meaning clearer.
>
> For example, you may want to write the space-time variation of a  
> phasor
> wave amplitude as Exp[ I k z - I omega t] because that's neat, simple,
> and conventional.
>
> But then, in discussing a waveguide mode where a factor k d (d =
> waveguide width) appears, you may want to write that factor instead in
> the form 2 pi d/lambda to emphasize that it's the width in wavelengths
> that's important.
>
> But if at some point in your notebook you're going to insert any of  
> the
> dependences within this set -- e.g., k := 2 pi / lambda -- then you're
> stuck with this from then on.
>
> 2)  A second point:  My experience has been that useful identities  
> that
> often arise in analyses -- for example, with suitable qualifications  
> the
> infinite integral of Exp[- a x^2 + b x] == Exp[b^2/4a] -- sometime  
> just
> won't fall out (i.e., won't be explicitly evaluated by Mathematica  
> if a
> and b are actually more complicated expressions.
>
> 3)  More generally, one very often wants to do the eventual numerical
> calculations using only one or another form of dimensionless or
> normalized variables, because that's numerically efficient as well as
> physically and practically useful in expressing the results.
>
> And, if at some point in an exposition you're going to convert your
> analytical and expositional formulas into dimensionless formulas for
> numerical calculation purposes -- **at that point you really don't  
> care
> how Mathematica arranges the resulting expression**.
>
>
>> 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.
>
> Last sentence is true; immediately preceding sentence may be true as
> phrased -- but is a mistaken belief.  Comments on this below.
>
>
>> 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.
>
> Let's say it like it is:  It's not just "difficult" for ordinary users
> to use and control many of these advanced tools:  It's basically
> **impossible** for the average user to learn what some of these tools
> do, because they're so complex and the results can depend so  
> critically
> on what you put into them; all you end up doing is thrashing around
> endlessly, trying to get them to produce the results you want.
>
> The more powerful they get, the less they're worth trying to learn.
>
>
>> 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.
>
> My bottom lines are instead:
>
> 1)  Accept that "Retyping is...error prone" -- and more generally that
> "To err is human..." -- and to the extent that you have to do any form
> of retyping, do a _lot_ of checking, rechecking, testing with simple
> cases, and looking to see that results are physically meaningful.
>
> 2)  Nonetheless, in general, "It is GENERALLY NOT very useful to get
> Mathematica generated expressions into the form that one wants" -- at
> least, not very often, and not if it involves any significant amount  
> of
> effort.  It's wasted energy, and can add its own errors, or divert one
> from seeing one's own errors.
>
> 3)  Instead, if what you're doing is a complex analysis and/or
> exposition, tackle the analysis portion initially with paper, pencil,
> and a good soft eraser, the way God intended analysis to be done.
>
> 4)  When and if certain calculations (series expansions, etc.) get
> messy, run separate Mathematica symbolic calculations in auxiliary
> notebooks to carry them out.
>
> 5)  When it comes time for exposition, do the exposition using a tool
> that's designed for exposition (e.g., TeX),  while doing the numerical
> calculations and graphing using a tool that's good at those things --
> and while doing this repeat item 1) multiple times.
>
>
>> Someday someone may even write a good tutorial on it.
>
> How about instead someone **imbedding real TeX in Mathematica**, as  
> part
> of Mathematica's basic capabilities?
>
> That is:
>
> *  TeX is (I believe) totally open source, free, highly stable, and
> widely known and studied -- and it's full source code is very compact.
>
> *  So how about building the TeX source code into Mathematica's  
> already
> immense repertoire of rules and stuff, and allowing one to include at
> any point in a "text portion" (I.e., a "non-evaluation portion") of a
> Mathematica notebook cell the syntax
>
>      TeX[ ---any valid TeX syntax---]
>
> such as TeX[$\alpha = \beta / \gamma^2$] to get that bit of inline  
> math
> into a Text or Header cell, or TeX[$$\alpha = \left( \beta /over
> \gamma^2 \right)$$] to insert a display equation,
>
> and just having Mathematica display the typeset box produced by TeX
> using that syntax into the Mathematica notebook at that point, with  
> the
> stuff inside the [ ] brackets having no other evaluational function or
> effect in Mathematica itself, except to be displayed?
>
> Is there some reason this would be conceptually impossible?  Would  
> it be
> that difficult to accomplish? Could it at least be implemented with  
> some
> reasonable subset of TeX syntax and capabilities?
>
> If your goal is to have Mathematica notebooks serve simultaneously as
> "exposition documents" and "calculation performing documents", might
> this be a lot easier than endless fighting with option-laden and
> temporally unstable Mathematica expressions like "Together, Apart,
> Factor, TrigReduce, TrigFactor, TrigExpand, TrigToExp, GroebnerBasis"
> and all their even more arcane extensions?
>





  • Prev by Date: Re: Taking sums across indices of a SparseArray efficiently
  • Next by Date: Re: Re: Simplifying and Rearranging Expressions
  • Previous by thread: Re: Re: Simplifying and Rearranging Expressions
  • Next by thread: Re: Re: Simplifying and Rearranging Expressions